SEP Client Firewall Rules Policies (Network Threat Protection/NTP) for finding clients using non-approved DHCP/DNS servers.

Article:TECH161639  |  Created: 2011-06-06  |  Updated: 2011-06-08  |  Article URL http://www.symantec.com/docs/TECH161639
Article Type
Technical Solution


Issue



A rogue DHCP/DNS server is setup in an environment and it is changing the DNS server in the clients’ TCP/IP settings. How can the Symantec Endpoint Protection (SEP) clients’ Network Threat Protection (NTP) firewall rules be configured to assist in identifying which clients are connecting to the rogue DHCP/DNS server?


Error



Clients are having issues connecting to network resources including, but not limited to; local network resources such as intranet sites, shared drives, and/or external web sites, external DNS servers, etc. In some instances the attempts to connect to these resources are re-directed to a different server or network resource than is expected. Review of clients' Host file does not show any unexpected host entries.

 


Cause



There is another system or router in the network that is serving DHCP/DNS traffic, either do to an unexpected configuration or possibly a risk.


Solution



 

 

Edit the firewall rules policy as follows:
 
First you will want to disable the “Smart DHCP” and “Smart DNS” Filtering. With these features enabled, DHCP and DNS traffic do not require an “Allow” firewall rule and thus we would not be able to log the traffic.
 
1.          Open the Firewall policy for your clients.
2.          On the left select “Smart Traffic Filtering”.
3.          On the right hand side, uncheck the boxes for “Enable Smart DHCP” & “Enabled Smart DNS”.
 
Next we will need to create the specific firewall rules for logging the traffic. To ensure that we are not logging traffic to the known good DHCP/DNS servers we will configure as follows. By not logging the known good DNS/DHCP traffic the logs should be easier to review.
 
1.          From the Firewall policy select “Rules” on the left hand side.
2.          Click the “Add Rule…” button then click “Next”.
3.          For “Select Rule Type” click the radio button for “Network Service” and click “Next”
4.          Check the box for “DHCP Server” and click “Finish”.
 
You will now see a new “Rule 0” listed in the firewall rules policy. Highlighting the rule name will allow specifying a name for the rule, e.g. “Allowed DHCP”. Once you have named the rule click the “Move Up” button to place this at the top of the firewall rules list. Edit the “Host” column and input any known good DHCP servers in the network. Ensure that Action is set to “Allow” and that Logging is set to “None” (unless you desire to log known good DHCP traffic).
 
Now we will configure a rule to log unknown DHCP traffic.
 
1.          Perform the same steps 1-4 as previously done above.
2.          Rename the new “Rule 0”, e.g. “Unknown DHCP”.
3.          Use the “Move Up” button to place this rule under the previously created rule.
4.          Ensure that “Host” is “Any”, “Action” is “Allow” or “Block” (depending on how you want the SEP client to handle the traffic), and that “Logging” is set to “Traffic Log” and/or “Packet Log” (the log being written to determines which log should be reviewed in order to analyse the traffic).
 
The following steps apply to the creation of the same firewall rules, but related to DNS traffic rather than DHCP traffic. This can be useful if there are suspicions that clients are also connecting to a rogue DNS server.
 
1.          From the Firewall policy select “Rules” on the left hand side.
2.          Click the “Add Rule…” button then click “Next”.
3.          For “Select Rule Type” click the radio button for “Network Service” and click “Next”.
4.          Check the box for “DNS Server” and click “Finish”.
5.          You will now see a new “Rule 0” listed in the firewall rules policy. Highlighting the rule name will allow specifying a name for the rule, e.g. “Allowed DNS”.
6.          Once you have named the rule click the “Move Up” button to place this as the second rule of the firewall rules list.
7.          Edit the “Host” column and input any known good DNS servers in the network. Ensure that Action is set to “Allow” and that Logging is set to “None” (unless you desire to log known good DNS traffic).
 
Now we will configure a rule to log unknown DHCP traffic.
 
1.          Perform the same steps 1-4 as previously done above.
2.          Rename the new “Rule 0”, e.g. “Unknown DNS”.
3.          Use the “Move Up” button to place this rule under the previously created rules.
4.          Ensure that “Host” is “Any”, “Action” is “Allow” or “Block” (depending on how you want the SEP client to handle the traffic), and that “Logging” is set to “Traffic Log” and/or “Packet Log” (the log being written to determines which log should be reviewed in order to review the traffic).
 
Once the SEP clients have received this policy they will begin logging and recording traffic according to the created firewall rules. In order to review the log information there are a couple of options.
 
1.          Run a report from within the SEPM from Monitors > Logs > Log type: Network Threat Protection > Log content: Packet or Traffic log (depending on which selection you made during creation of the rule).
2.          You may customize the time frame and select Advanced Settings for more granular report criteria. Click View Log to review the report.
 
Alternatively you may review the logs locally at the SEP client via the User Interface (UI).
 
1.          Open the SEP client.
2.          Click “View logs” on the left.
3.          Click “View Logs” for Network Threat Protection & select either the Packet or Traffic log depending on which selection you made for the firewall rule.
4.          To view past days NTP logs, click “Filter” and select the time period to view.
 
The logs will contain what time the traffic occurred at as well as the Remote Host IP.
You may also view client DNS server information from the SEPM > Clients page if you select "Network Information" from the "View" drop-down menu. Sorting by the "DNS Server" column should allow viewing which clients are not utilizing the correct DNS server.

Special Considerations:
 
Some applications utilize their own DNS server configurations as part of their functionality. As such when reviewing the logs it would be a good idea to verify if any of the DNS traffic is related to any network applications and configure the firewall rules accordingly (such as adding the application to the allowed DNS list) to narrow down the log data to only unexpected DNS servers.
 
You can also manually specify a type of network traffic rather than selecting DHCP/DNS from the “Service” menu. DNS traffic would be “TCP Local Port 53 : Remote Port 53” & “UDP Local Port 53”. DHCP traffic would be “UDP Local Port 67, 68” : “Remote Port 67, 68”.
If you desire to block all unapproved DHCP/DNS traffic, simply leave the Smart DHCP and Smart DNS disabled for SEP clients and have only the Allow rules created for specified DHCP/DNS servers. This configuration would ensure that clients would only be able to communicate with the specified DHCP/DNS servers and thus should omit any clients from connection to any rogue DHCP/DNS server(s).
 
You can also manually specify a type of network traffic rather than selecting DHCP/DNS from the “Service” menu. DNS traffic would be “TCP Local Port 53 : Remote Port 53” & “UDP Local Port 53”. DHCP traffic would be “UDP Local Port 67, 68” : “Remote Port 67, 68”.
 
If you desire to block all unapproved DHCP/DNS traffic, simply leave the Smart DHCP and Smart DNS disabled for SEP clients and have only the Allow rules created for specified DHCP/DNS servers. This configuration would ensure that clients would only be able to communicate with the specified DHCP/DNS servers and thus should omit any clients from connecting to any unspecified DHCP/DNS server(s).

If there are notebook clients, or machines that frequently leave the network, and you have multiple locations with different policies, these above policies should only be applied to clients when they are connected to the onsite network. If this is not considered, users may have issues connecting to DHCP/DNS servers when outside the local network.




Article URL http://www.symantec.com/docs/TECH161639


Terms of use for this information are found in Legal Notices