Monitoring a Network Using Policy-Based IDS

Problem

Can I use Snort to monitor my network based on a network policy?

Solution

Using Snort to monitor your network using policy-based IDS is generally a good idea as a second-layer defense. However, in the age of tunneled applications, when just about every application has an HTTP port, a policy-based solution does not provide as good coverage as normal signature IDS.

Another key point is that using policy-based IDS requires an organization to know a lot about its own network and the services it offers to the outside world. For example, with a policy-based architecture you might be suddenly flooded with alarms about FTP traffic on your web server(s) because your operations staff failed to notify the IDS team of a change in the services offered on those servers.

Finally, you are placing a lot of hope in the idea that attackers to your network won't realize that you, for example, trust all traffic between the outside world and your web server on port 80/tcp and 21/tcp. In such a case, an attacker can install a backdoor application on port 80, such as /backdoor.exe, then wait until your organization looks through its web server logs. Or turn off the FTP service and install an encrypted SSH session on that port so that you are now blind to the information being infiltrated/exfiltrated from your network.

Discussion

What is policy-based IDS? Policy-based IDS is making several assumptions about your network:

• You know your network very well, such as your network segments, IP ranges, and outside connection points.
• You know and have secured your "servers" to provide only the service(s) you want. Web servers serve only HTTP; FTP servers serve only FTP, etc.
• You have an application proxy or other means of securing egress traffic leaving your network.

With this in mind, one of the examples of this would be to configure Snort to be aware of all your servers in the snort.conf file, as in the following:

# Policy-based snort.conf example var HTTP_SERVERS [10.0.4.5/32, 10.0.7-7/32,10.1.3.4/32] var MAIL_SERVERS [10.1.4.6/32,10.0.10.5/32] var FTP_SERVERS [10.1.4.4/32,10.1.3.7/32] # var SSH_SERVER [ ]

Then create several rules to trust that traffic and pass it without analysis, as in the following:

# Create pass rules for the "trusted" traffic pass tcp $EXTERNAL_NET any <> $HTTP_SERVERS $HTTP_PORTS pass tcp $EXTERNAL_NET any <> $MAIL_SERVERS $MAIL_PORTS pass tcp $EXTERNAL_NET any <> $FTP_SERVERS 21 # ETC, etc

To enable Snort to pass the rules first at runtime, enable the -o option to change the rule order to pass/alert/log rules. This means that Snort will process pass rules, then alert rules, and finally, log rules.

/path/to/snort -c /path/to/snort.conf -o -i

Here are several examples of policy-based rules that would be typical to enable on your policy sensors to determine when a policy has been violated:

alert tcp $HTTP_SERVERS any -> any !$HTTP_PORTS (msg:"ODD PORT USE - HTTP SERVER !!"; flow:established; classtype:bad-unknown; rev:1; sid:10777;) alert tcp $MAIL_SERVERS any -> any !MAIL_PORTS (msg:"ODD PORT USE - MAIL SERVER !!"; flow:established; classtype:bad-unknown; rev:1; sid:10778;) alert tcp $FTP_SERVERS any -> any !21 (msg:"ODD PORT USE - FTP SERVER"; flow:established; classtype:bad-unknown; rev:1; sid:10779;)

Hopefully you can see from the previous examples how much knowledge about the network(s) and resources you need to use this type of IDS. To briefly touch on the subject of network profiling, policy-based IDS is very similar. Like network profiling, policy-based IDS works on the principle that once a network is known, changes should be minimal or non-noticeable. However, for today's networks, this is not often the case. One network that we are aware of had as much as 20 percent of the network changing on a given day! However, one of the benefits of this type of IDS can be found when combined with the events from your normal signature IDS. For example, when a compromise occurs, it might not fire an event from your signature IDS. However, if the compromise starts even one odd port connection, the policy-based IDS will have several events!

Finally, when used with keyword searches through your allowed application traffic, such as for HTTP, SMTP, etc., this can provide your organization with some tools to enforce an acceptable use policy. For example, if the corporate policy is worded so that content monitoring is allowed, your analysts now have the clearance to set IDS rules to alarm on content violations, such as porn, discriminatory language, privacy information, or even file-sharing applications in use on the network. This can then be handed to your proper channels, depending on the agency for resolution.

See Also

Snort 2.0 book on policy-based IDS

Application firewalls/proxy servers