So we’ve finally placed BES Relay in the DMZ. The Relay is reporting to the BES Server. We’ve pushed out the BES Relay Setting: Name Override task and clients are registering with the external address as set in the Name Override task. But we have a few questions we’d like to clarify. FWIW, our clients are using dynamic relay selection.
First, is there an easy way to Enable Command Polling only when clients are not on the corporate network or are on the VPN?
Second, is we enable Command Polling, does that turn off the normal client registration behavior?
Third, since we simply just installed the BES Relay service on the client in the DMZ, will clients on the corporate network try to register with it and if so, is there a way to prevent a client that is on the corporate network from registering with BES Relays in the DMZ?
Finally are there any issues / concerns or best practices we should be aware of?
One option for command polling is to set a policy that any computer that is reporting to the relay should enable command polling… You
could
also create another action to set command polling back, but it command polling is relatively low impact on the system if there aren’t too many computers doing it so you can probably leave the computers with command polling enabled.
Most of what I read state that we need these ports and protocols in these directions at the minimum - assuming dynamic relay selection:
Internet -> DMZ - TCP 52311
Internet -> DMZ - ICMP Echo, ICMP Echo Response (Ping)
DMZ -> Corporate - TCP 52311
Recommended but not needed are
Internet <- DMZ - UDP 52311
DMZ <- Corporate - UDP 52311
The link you sent seems to contradict this by stating we need “HTTP port” which I am assuming mean TCP AND UDP:
Internet <-> DMZ - TCP 52311
Internet <-> DMZ - UDP 52311
Internet -> DMZ - ICMP Echo, ICMP Echo Response (Ping)
DMZ <-> Corporate - TCP 52311
DMZ <-> Corporate - UDP 52311
Can you clarify what the exact traffic flow direction, port and protocol are required between the Internet / DMZ and the DMZ / Corporate Networks?
With regards to command polling, how do you enable it only if a client is using the DMZ relay - is there a fixlet / task to do this or is this a custom action? If it is custom, can you provide a starting point?
So I think we have figured out how to apply the Command Polling dynamically based on whether or not the client is talking to the DMZ relay.
Detect client using DMZ relay and not using Command Polling (replace x with ip address):
(name of registration server as string contains “xxx.xxx.xxx.xxx”) AND (not exists setting “_BESClient_Comm_CommandPollEnable” of client)
Is there a way to test the “exists setting “name of registration server as string contains “xxx.xxx.xxx.xxx”” of client” piece? The Relevance Debugger just throws back the error “Error: No inspector context.”
And if anyone can clear up the exact traffic flow direction, port and protocol are required between the Internet / DMZ and the DMZ / Corporate Networks we would be very grateful.
The simplest way to enable command polling for DMZ relays is to create an action from the Task “BES Client Setting: Enable Command Polling” targeted at “ALL Computers” that match “By Relay” and choose the DMZ relay.
For your port questions, you can think of “HTTP port” as “TCP port” (HTTP is built on top of TCP).
Required:
Internet -> DMZ - TCP 52311
DMZ -> Corporate - TCP 52311
Required for autoselection:
Internet -> DMZ - ICMP Echo, ICMP Echo Response (Ping)
Optional for faster responsiveness (otherwise you might need to wait 6 hours+ for agents to figure out that there are new actions/Fixlets):
The best way to configure this type of policy is to use what we call a Dynamic Setting. You can do it through the Edit Settings dialog which you get to by right clicking on a computer. For detailed information, please see my comment (#5) in this post:
{(if (name of registration server as string contains “xxx.xxx.xxx.xxx”) then (“1”) else (“0”))}
There are a couple of problems with the relevance you’ve defined and I don’t think you’ll get the exact behavior you’re looking for if you stick with your custom task.
To your other questions… to evaluate expressions that use inspectors requiring client context, you can either make a retrieved property in the console, or use Lee Wei’s Client API Tester: http://forum.bigfix.com/viewtopic.php?id=2756
Ben / jessewk - thank you. And now I am going to beat a dead horse.
Ben - you stated “Optional for faster responsiveness (otherwise you might need to wait 6 hours+ for agents to figure out that there are new actions/Fixlets)” - I thought that was the point in command polling. Enabling it kept the client up to date. So in addition to that we also need the extra outgoing ports?
jessewk - the problem with what you propose, from what I can tell, is that it is a manual process. Here is what we have done. Can you let us know if it won’t work correctly:
(version of client >= “6.0”) AND (name of registration server as string contains “xxx.xxx.xxx.xxx”) AND (not exists setting “_BESClient_Comm_CommandPollEnable” of client)
Action
setting “_BESClient_Comm_CommandPollEnable”=“1” on “{now}” for client
setting “_BESClient_Comm_CommandPollIntervalSeconds”=“1800” on “{now}” for client
(version of client >= “6.0”) AND (name of registration server as string does not contain “xxx.xxx.xxx.xxx”) AND (exists setting “_BESClient_Comm_CommandPollEnable” of client)
Action
setting delete “_BESClient_Comm_CommandPollEnable” on “{now}” for client
setting delete “_BESClient_Comm_CommandPollIntervalSeconds” on “{now}” for client
Created Policy Action and applied it to a Dynamic Group that contains all laptop computers.
This is the one that will increase responsiveness because the server will be able to contact the relay in the DMZ as soon as an action is issued:
DMZ <- Corporate - TCP 52311
If you enable command polling for the client on the relay you will get a faster response than every 6 hours (default), but it will still be slower than if you punch the hole and allow the server to directly contact the relay in the DMZ at action issue time.
This one won’t usually buy you much as internet clients will rarely successfully receive a UDP ping, but there is not much harm in adding it anyway:
Internet <- DMZ - UDP 52311
Ok, on to the dynamic setting issue. The dynamic setting is not a manual process. All you need to do is make sure you are on the ‘Edit Settings’ dialog for multiple computers. Either select multiple computers before selecting ‘Edit Settings’ from the right-click menu, or click the ‘More Options…’ button in the single computer ‘Edit Settings’ dialog. Once you are on the correct dialog box:
On the Settings tab, select ‘Custom Setting’ and use _BESClient_Comm_CommandPollEnable for the name and the code I posted above for the value.
Choose your targeting criteria on the targeting tab. You will want to select your laptop computers group and make sure you use the second radio button, “All computers with the property value …”
I suggest you try the above but target only one computer. Export the action and look at the source. You’ll find it’s quite a bit different and more complex than the task you’ve posted. Your tasks have a number of issues, both with the relevance that checks for the setting and with the action to toggle the value.
jessewk - thank you and Ben for staying with us on this one. The port issue is clear now. From the time of my last post, we did discover relevance issues. We also implemented some revised relevance:
Remote Network - Enable Polling:
(version of client >= “6.0”) AND (name of registration server as string contains “xxx.xxx.xxx.xxx”) AND (if (exists setting “_BESClient_Comm_CommandPollEnable” of client) then (if (exists value of setting “_BESClient_Comm_CommandPollEnable” of client) then (if (setting “_BESClient_Comm_CommandPollEnable” of client as string contains “1”) then false else true) else true) else true)
or
(version of client >= “6.0”) AND (name of registration server as string contains “xxx.xxx.xxx.xxx”) AND (exists setting “_BESClient_Comm_CommandPollEnable” of client) AND (exists value of setting “_BESClient_Comm_CommandPollEnable” of client) AND (setting “_BESClient_Comm_CommandPollEnable” of client as string contains “1”)
Corporate Network - Disable Polling:
(version of client >= “6.0”) AND (name of registration server as string does not contain “xxx.xxx.xxx.xxx”) AND (if (exists setting “_BESClient_Comm_CommandPollEnable” of client) then (if (exists value of setting “_BESClient_Comm_CommandPollEnable” of client) then (if (setting “_BESClient_Comm_CommandPollEnable” of client as string contains “1”) then true else false) else false) else false)
or
(version of client >= “6.0”) AND (name of registration server as string does not contain “xxx.xxx.xxx.xxx”) AND ((not exists setting “_BESClient_Comm_CommandPollEnable” of client) OR (not exists value of setting “_BESClient_Comm_CommandPollEnable” of client) OR (setting “_BESClient_Comm_CommandPollEnable” of client as string does not contain “1”))
It seems to be working correctly. I do see what you are talking about with the Edit Settings method. We will test that later today to see how it compares. I am curious to see what it the differences are for turning polling on and off - since we pulled those settings from the BigFix provided task. Thanks Again. I’ll post back after we have the results. May I suggest this be made into a best practices whitepaper?
((not exists setting “_BESClient_Comm_CommandPollEnable” of client) OR ((not exists effective date of it) OR ((effective date of it <= universal time “Wed, 02 Dec 2009 20:40:03 +0000”) AND ((not exists value of it) OR (value of it does not equal (((if (name of registration server as string contains “xxx.xxx.xxx.xxx”) then (“1”) else (“0”))) as string))))) of setting “_BESClient_Comm_CommandPollEnable” of client)
And this action:
setting “_BESClient_Comm_CommandPollEnable”="{(if (name of registration server as string contains “xxx.xxx.xxx.xxx”) then (“1”) else (“0”))}" on “Wed, 02 Dec 2009 20:40:03 +0000” for client
My question is, why does it embed the date? Wouldn’t we want the registry date stamp to reflect the actual date the change was made for troubleshooting purposes? And the downside to this method is not being able to change the name of the action or embed it in a baseline - we have naming conventions for policy actions and standard config baselines which provide a single place to look to see what is being applied to the client. In order to do any of this, I need to make a custom action anyhow, correct?
Client settings have an “effective date” which is used to make sure the agent doesn’t revert to an old policy if there are multiple actions that set the same policy. You can change it to whatever date you want, but note that the agent will not apply a setting if the computer already has the setting with a later effective date.
Ben, I should have been more specific. I understand about the use of the date stamp for control. I was wondering why the action hard coded a date time and did not set it dynamically to the time the change was made on the client using “{now}”. This is the way the “BES Client Setting: Enable Command Polling” task works. I was thinking of it from the client side change date / time. But it appears to be being used here as a version control time stamp from when the action was initiated.
To give another example, BigFix also seems to use the field they way I was thinking when you look at the client settings for __Relay_Control_RootServer and __RelayServer1. The seem to get set every time the client makes a change.
I was just curious if there was a reason. We plan to change the script to use “{now}” unless there is something reason not to:
setting “_BESClient_Comm_CommandPollEnable”="{(if (name of registration server as string contains “xxx.xxx.xxx.xxx”) then (“1”) else (“0”))}" on “{now}” for client
Using {now} is actually an issue because it sorta defeats the effective date (because everytime the agent evaluates “now”, it is always later than the last time it evaluated “now” and thus it will always update the setting)… So if you had two settings using “now” then they would “fight” by constantly switching the setting back-and-forth.
You can use “action issue date” instead… for example:
setting “test”=“test” on “{parameter “action issue date” of action}” for client
This will use the time the action was issued instead, which is our best-practice… (but note that I don’t think this trick can be used in the relevance of the action… So you should remove the time part of the relevance or set it manually…)