www.Tutorialsforu.info

As we learned before, signatures are attack patterns. It's important to understand how they work, so we can create them on-demand or when a new exploit is discovered. In our examples, we will see how Snort handles its signatures. In the second half of 2001 we observed new and powerful worms on the Net, such as Code Red, Code Red II and Nimda. When these attacks started to happen, Linux users (and I was one of them) felt very lucky because the worms mainly were attached to Microsoft's IIS (Internet Information Server). These worms had some particular patterns, for example, trying to access the cmd.exe file through Microsoft's IIS. By knowing this, we easily could create a Nimda Snort rule as mentioned in the section “IDS types and Models”:

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80
  (msg:"WEB-IIS cmd.exe access"; flags: A+;
  content:"cmd.exe"; nocase;
  classtype:web-application-attack; sid:1002; rev:2;)

Okay, but what does it mean? Snort rules are nothing more than sequential parameters divided in two sections that we use to inform Snort of what we want it to pay attention to. The first section is called rule header and includes everything before the first brackets. The first parameter in this header tells Snort what to do when the packet matches this rule—in this case, “alert” indicates that Snort will generate an alarm and then log the packet. The second parameter tells Snort what kind of protocol we want—in this case, just TCP. The next five parameters indicate the source IP address and port, direction of the packet, destination IP address and port. In this way, we know that a packet from any address outside of our network, with any source port, going to an IP address in our internal network at port 80 (usually web servers listen to this port) will be checked by the internal parameters of the rule, called rule options. The rule option section contains alert messages and information about which parts will be checked in the packet, and then with the result of this inspection, the appropriate action will be taken.

Rule options in our example:

In the Snort Users Manual you can find more than 30 rule options that you can use to satisfy your needs. Too complicated? No, it is not! Let's try to create a simple rule to alert any porn web access attempt from your network using the few rule options above:

alert tcp $INTERNAL_NET any -> $EXTERNAL_NET  80
  (msg: "Web Porn Access Attempt"; content:"Free porn";
   nocase; flags:A+);

A port scan to a service like portmap (port 111), which is known to have various exploits, would be alerted by PortSentry:

Dec 9 03:03:17 flamengo portsentry[701]: attackalert:
  TCP SYN/Normal scan from host:
  200.185.61.132/200.185.61.132 to TCP port: 111

Learning how to interpret log files is one of the most important things that an intrusion or security analyst must learn in order to decide what action to take in a given situation. The excerpt from the PortSentry alert above was obtained from the syslog file. This alert states that on December 9 at 03:03, the host called flamengo, which has PortSentry installed, detected an SYN-flag Normal port scan in the TCP port 111 which, in general, runs the service portmap, from host IP 200.185.61.132.