snortrules.c : a snort rules file analyzer (v.0.5)

I wrote some code which is essentially a snort rules file analyzer. With the help of nmap (version > 2.1), it finds 'all' the rules which do not apply to the local network.

Please give me any feedback on its utility, features, and of course bugs (it is _very_ beta after all).

Roman Danyliw
June 13, 2000

What is snortrules?

Snort (or any IDS) for that matter is only useful to the degree that it has the latest signatures for possible exploits. There are two great repositories for Snort rules:

However, the more rules Snort uses, the slower it becomes. This code was written with the motivation to generate a network specific rules file. It essentially uses nmap ( to initially map which services are present. Then with a list of open TCP and UDP ports, snortrules determine which rules do not apply. In the current version, there is no _real_ understanding of the network; a binary view is taken: either the packets are coming from the inside=>outside; or outside=>inside. Those rules which constitute traffic coming from the outside to the inside on ports (outside=>inside) which have no services are determined to be non-applicable (e.g. not running a web server, means all port 80 rules probably don't apply). Of course, nothing can be said about inside=>outside traffic based on a port scan, so those are always deemed applicable. When in doubt (and everything ICMP), snortrules considers a rule applicable.

When a rule is determined to be non-applicable, two actions can be taken. A simple approach is to take the stance that the potential exploit is a non-issue because it is targeted at a non-existent service (i.e. you are not vulnerable). Thus, non-applicable rules can be discarded from the rules list. However, for the more paranoid, it is valuable to know _all_ the attacks which are being attempted against your network. Therefore, snortrules can also merely change the text of the particular alert to indicate that the rule was triggered but does not apply.

The obvious caveat and possible flaw with such as scheme deals with "Trojan/Backdoor"-like programs which might be installed on client machines. For example, you scan the network and parse the rules file. A static determination of the what rules are applicable was made. After doing so, rogue server-software (e.g. BO, NetBus, trin00) gets loaded on one of your boxes. So technically, since this rogue server was not present prior to the scan, snortrules had marked as non-applicable that particular rule used to detect this software. This is a bad thing ... but will I really miss the attack? Well not really. After all the communication will probably be bi-directional. You can catch the illicit server with a rule about its communications with a client. The other moral of the story is run snortrules often to constantly keep your signatures fresh. Stay tuned for more automated ways of including customized rules directly into Snort! They should make this problem a non-issue.