CSV Output Module Output Modules

Using BPF Fileters 155

4.2.11 Log Null Output Module

This output plug-in causes alert entries not to be logged. For example, you can create a rule type to send SNMP traps without logging these messages. However, I would not recommend using it. You should always have a record of alerts so that if you want to take any action against intruders, you have some evidence of the IDS activities.

4.3 Using BPF Fileters

Berkley Packet Filter BPF is a mechanism of filtering data packets at the data link layer level. These filters are extensively used with the tcpdump program to filter data that you want to capture. You can use BPF filters with Snort as well. When using BPF filters, Snort rules are applied only to those packets that pass BPF filters. This way you can save some CPU time by not applying Snort rules to packets that are of no inter- est. For example, the BPF filters can be used to compare a particular byte from the start- ing offset of the IP header, TCP header or UDP header. You can place BPF filters in a file and use that file on the command line when starting Snort. Let us suppose you want to apply Snort only on packets for which the Type of Service TOS field in the IP header is not equal to 0. The TOS field is the sec- ond byte in the IP header. For this purpose, you can create a file bpf.txt with the follow- ing line in it: ip[1] = 0 Number 1 is the offset starting from the IP header part of the data packet. The off- set starts from 0, so byte number 1 is the TOS field. For the structure of the IP header, refer to Appendix C. After creating this file, you can use the following command line to start Snort to enable the filter. snort -F bpf.txt -c optsnortetcsnort.conf Only those packets in which the TOS field has some value other than 0 will reach Snort detection engine. A TOS value equal to 0 shows normal data traffic and any other value is used for high priority data packets. 156 Chapter 4 • Plugins, Preprocessors and Output Modules

4.4 References

1. Classless Inter-Domain Routing or CIDR. RFC 1519 at http:www.rfc-edi-

tor.orgrfcrfc1519.txt

2. Transmission Control Protocol RFC 793 at http:www.rfc-editor.orgrfc

rfc793.txt 3. The nmap at it web site http:www.nmap.org 4. The Internet Protocol RFC 791 at http:www.rfc-editor.orgrfcrfc791.txt

5. The Internet Control Message Protocol at http:www.rfc-editor.orgrfc

rfc792.txt 6. The nmap utility at http:www.nmap.org 7. Simple Network Markup Language SNML info at http:www.cert.orgkb snortxml

8. Barnyard at http:sourceforge.netprojectsbarnyard 9. ACID_XML at http:www.maximumunix.org

10. XML at http:www.xml.org 11. Snot at http:www.sec33.comsniph

157 C H A P T E R 5 Using Snort with MySQL ll systems need some type of efficient logging feature, usually using a database at the backend. Snort can be made to work with MySQL, Oracle or any other Open Database Connectivity ODBC com- pliant database. 1 You already know from the discussion of output modules in the previous chapter that you can save logs and alerts to a database. Logging to a database is very useful for maintaining history data, generat- ing reports and analyzing information. By using other tools like Analysis Control for Intrusion Detection ACID, discussed in the next chapter, you can get very useful information from the database about attack patterns. For example, you can get a report about the last fifteen unique attacks, information about hosts that are continuously attacking your network, the distribution of attacks by different protocols, and so on. Since MySQL is a freely available database and works perfectly well on Linux and other operating systems, this is a natural choice for Snort. Some different scenarios for using a database with Snort are: • You can install and run the MySQL database server on the same machine where Snort is running, as shown in Figure 5-1. 1. ODBC provides a standard way for clients to connect to a database. Refer to ODBS FAQ at http: www.ensyncsolutions.comodbc_faq.htm or http:www.odbc.org for more information. A