UNI-FIX Computer

Decouple Snort’s output stage so it can keep pace with the packets.

Snort by itself is fine for monitoring small networks or networks with low amounts of traffic, but it does not scale very well without some additional help. The problem is not with Snort’s detection engine itself, but stems from the fact that Snort is a single-threaded application. Because of this, whenever an alert or log event is triggered, Snort must first send the alert or log entry to its final destination before it can go back to looking at the incoming data stream. This isn’t such a big deal if you’re just having Snort write to a file, but it can become a problem if you are logging to a database, which can cause Snort to wait a relatively long time for the database insert to complete. This of course is exacerbated when you’re having Snort log to a remote database server.

To solve this, another application called Barnyard (http://www.snort.org/dl/barnyard/) was written. Functionally, Barnyard is the equivalent of Snort’s output plug-ins all rolled into one program, with a frontend for reading in files that Snort generates and then sending them to the same database or other destination that you would normally have Snort log to. The only draw back to Barnyard is its limited database support: Barnyard supports only MySQL, whereas Snort supports MySQL, PostgreSQL, Oracle, and ODBC outputs (Barnyard claims to support PostgreSQL, but unfortunately its current support is shaky at best).

After downloading Barnyard and unpacking it, change to the directory it created and run its configure script:

$ ./configure –enable-mysql

This will enable MySQL support when Barnyard is compiled. If you’ve installed your MySQL libraries and include files in a nonstandard place (i.e., underneath the /usr or /usr/local hierarchies), you’ll probably need to add the –with-mysql-includes and –with-mysql-libraries command-line options.

After you’re done with the configure script, you can compile Barnyard by running make. When it finishes compiling, install it by becoming root and running make install.

Before you use Barnyard, you’ll need to configure Snort to use its unified output format. This is a binary format that includes both the alert information and the data for the packet that triggered the alert, and it is the only type of input that Barnyard will understand.

To configure Snort to use the unified output format for both alert and log events, add lines similar to these to your Snort configuration (e.g., /etc/snort/snort.conf or /usr/local/etc/snort/snort.conf):

output alert_unified: filename snort.alert, limit 128

output log_unified: filnemae snort.log, limit 128

The filenames specified here are the basenames for the files that Snort will write its alert and log event information to. When it writes a file, it will append the current Unix timestamp to the end of the basename. In addition, the size of these files will be limited to 128MB.

Now you’ll need to create a configuration file for use with Barnyard. To run Barnyard in daemon mode and have it automatically fork itself into the background, add this line to your configuration file:

config daemon

If you’re going to be logging to a database for use with ACID [Hack #83], you’ll also want to add two lines similar to these:

config hostname: colossus

config interface: eth0

These two lines should be set to the name of the machine that you’re running Barnyard on and the interface that Snort is reading packets from. Next, you’ll need to actually tell Barnyard to read your unified log files.

You can do this for alert events by using this line:

processor dp_alert

Or, if you want to process log events, use this line:

processor dp_log

Note that Barnyard can process only one type of unified log at a time. So, if you want it to process both alert and log events, you’ll need to run an instance of Barnyard for each type.

Now all that’s left to configure is where Barnyard will send the data. If you want to use Snort’s fast alert mode to generate single-line abbreviated alerts, you can use the alert_fast output plug-in:

output alert_fast: fast_alerts.log

Or, if you want Barnyard to generate ASCII packet dumps of the data contained in the unified logs, you can use a line similar to this:

output log_dump: ascii_dump.log

To have Barnyard output to your syslog daemon, you can use the alert_syslog plug-in just like you would in your snort.conf. For instance, if you wanted to send data to the local syslogd and use the auth facility and the alert log level, you could use a line like this:

output alert_syslog: LOG_AUTH LOG_ALERT

Or, if you want to send to a remote syslog daemon, you can use a line similar to this:

output alert_syslog: hostname=loghost, LOG_AUTH LOG_ALERT

You can also have Barnyard create Pcap-formatted files from the data in the unified logs. This is useful for analyzing the data later in tools such as Ethereal. To do this, use the log_pcap plug-in:

output log_pcap: alerts.pcap

Finally, you can also have Barnyard output to a database by using the alert_acid_db plug-in for logging alert events and the log_acid_db for capturing log events.

For instance, this line would send alerts to the SNORT MySQL database running on dbserver using the username snort:

output alert_acid_db: mysql, sensor_id 0, database SNORT, server dbserver, user snort

The sensor_id is the one assigned by ACID to the particular instance of Snort that is gathering the data. You can find what sensor ID to use by clicking on the Sensors link on ACID’s front page [Hack #83], which will show you a list of the sensors that are currently logging to ACID.

The log_acid_db plug-in is similar, except it does not use the sensor_id option:

output log_acid_db: mysql, database SNORT, server dbserver, user snort, detail full

You can start Barnyard by simply using a command similar to the following if Snort’s configuration files are stored in /etc/snort and Snort is set to keep its logs in /var/log/snort:

# barnyard -f snort.alert

Of course, this assumes that you used snort.alert when configuring Snort’s alert_unified plug-in. If your Snort configuration files aren’t stored in /etc/snort, you can specify the locations of all the files that Barnyard needs to access by running a command similar to this one:

# barnyard -c /usr/local/etc/snort/barnyard.conf \

-g /usr/local/etc/snort/gen-msg.map \

-s /usr/local/etc/snort/sid-msg.map -f snort.alert

This would tell Barnyard where to find all the files it needs if they are in /usr/local/etc/snort (and are too stubborn to create a symlink to /etc/snort). If you’re using a directory other than /var/log/snort to store Snort’s logs, you can specify it with the -d option.

Congratulations. With Barnyard running, you should be able to hand

Keep your IDS sensors safe from attack, while still giving yourself access to their data.

Your IDS sensors are the early warning system that can both alert you to an attack and provide needed evidence for investigating a break-in after one has occurred. You should take extra care to protect them and the data that they collect. One way to do this is to run your IDS sensors in stealth mode.

To do this, simply don’t configure an IP address for the interface that your IDS software will be collecting data from. Putting the interface up, but without specifying an IP address, can do this.

For example:

# tcpdump -i eth1

tcpdump: bind: Network is down

# ifconfig eth1 up promisc

# ifconfig eth1

eth1 Link encap:Ethernet HWaddr 00:DE:AD:BE:EF:00

UP BROADCAST PROMISC MULTICAST MTU:1500 Metric:1

RX packets:0 errors:0 dropped:0 overruns:0 frame:0

TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:100

RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

Interrupt:11 Base address:0x1c80

# /usr/sbin/tcpdump -i eth1

tcpdump: WARNING: eth1: no IPv4 address assigned

tcpdump: listening on eth1

After you’ve put the interface up, just start your IDS [Hack #82] . Your IDS will run as normal, but since there is no way to directly access the machine, it is very difficult to attack it.

However, just like potential attackers, you will be unable to access the machine remotely. Therefore, if you want to manage the sensor remotely, you’ll need to put in a second network interface. Of course, if you did this and hooked it up to the same network that the IDS sensor is monitoring, it would totally defeat the purpose of running the other interface without an IP address. To keep the traffic isolated, you should create a separate network for managing the IDS sensors. You can of course attach this network to one that is remotely accessible and then firewall it heavily.

Another approach is to access the box using an alternate channel, such as a serial port connected to another machine that does have a network connection. Just run a console on the serial port, and take care to heavily secure the second machine. You could also connect a modem (remember those?) to an unlisted phone number or, better yet, an unlisted extension on your office’s PBX. Depending on your situation, simply using the console for access may be the simplest and most secure method.

Whichever method you decide to use for remote access is a choice you’ll have to make by weighing the value of increased security against the inconvenience of jumping through hoops to access the machine. Security nearly always involves a trade-off between convenience and confidence.

Use SnortSam to prevent intrusions by putting dynamic firewall rules in place to stop in-progress attacks.

An alternative to running Snort on your firewall and having it activate filtering rules on the machine it’s running on [Hack #87] is to have Snort communicate which filtering rules should be put in place when the an intrusion is detected on an external firewall. To do this, you can use SnortSam (http://www.snortsam.net).

SnortSam uses Snort’s plug-in architecture and extends Snort with the ability to notify a remote firewall, which then dynamically applies filtering rules to stop attacks that are in progress. Unlike Snort_inline, which is highly dependent on Linux, SnortSam supports a wide variety of firewalls, such as Checkpoint, Cisco, Netscreen, Firebox, OpenBSD’s pf, and even Linux’s ipchains and iptables interfaces to Netfilter. SnortSam is made up of two components, a Snort plug-in and a daemon.

To set up SnortSam, first download the source distribution and then unpack it. After you’ve done that, go into the directory it created and run this command:

$ sh makesnortsam.sh

This will build the snortsam binary, which you can then copy to a suitable place in your path (e.g., /usr/bin or /usr/local/bin).

Now download the patch for Snort, which you can get from the same site as SnortSam. After you’ve done that, unpack it:

$ tar xvfz snortsam-patch.tar.gz

NOTE

patchsnort.sh

patchsnort.sh.asc

snortpatch8

snortpatch8.asc

snortpatch9

snortpatch9.asc

snortpatchb

snortpatchb.asc

Next, run patchsnort.sh and specify the directory where you’re keeping Snort’s source:

$ sh patchsnort.sh snort-2.0.5

Patching Snort version 2.0…

patching file spo_alert_fwsam.c

patching file spo_alert_fwsam.h

patching file twofish.c

patching file twofish.h

patching file plugbase.c

Hunk #1 succeeded at 29 with fuzz 2 (offset -73 lines).

Hunk #2 succeeded at 639 with fuzz 2 (offset 77 lines).

Patching Makefiles…

Done

Now compile Snort as you would normally [Hack #82] .

Before running SnortSam, you must create a configuration file for it. SnortSam’s configuration syntax is pretty easy to use, but there are quite a few options, so only a subset of the available ones will be discussed here.

One useful option is accept, which lets you tell SnortSam what Snort sensors are allowed to connect to it. This option can take a CIDR-format address range, a hostname, or a single IP address. You can optionally specify a password as well. If you don’t specify a password, the one specified by the defaultkey option is used.

For example, if you wanted to allow all hosts from the network 192.168.1.0/24 with the password qwijybo, you could put a line like this in your configuration file:

accept 192.168.1.0/24, qwijybo

To specify multiple hosts on network address ranges, you can use multiple accept entries.

Another useful option is dontblock. This enables you to construct a whitelist of hosts and networks that SnortSam will not block under any circumstances. This option takes hostnames, single IP addresses, and CIDR addresses; you can also use multiple dontblock entries, just as you can with accept.

To improve SnortSam’s performance, you may want to use the skipinterval option. This option lets you tell SnortSam how long to skip identical blocking requests before it will resume applying rules for that request. This ensures that SnortSam isn’t constantly requesting the firewall to block the same IP address and port over and over again. The skipinterval option takes a single number as its argument, which specifies how many seconds to wait.

You’ll probably want to keep tabs on what SnortSam’s doing, since you’re allowing it to modify your firewall’s rules. One way is to use the logfile option, which will cause SnortSam to log events such as program start, blocking and unblocking requests, and any errors that were encountered. This option takes a single argument, which is the filename that the logs will be written to. The log file that you specify will be created in /var/log.

A couple of other useful options are daemon and bindip. The daemon option simply tells SnortSam to fork into the background and run as a daemon; it does not take any arguments. The bindip option, on the other hand, allows you to specify which IP address to listen on, which is useful when the machine that SnortSam is running on has multiple addresses available.

For instance, if you wanted SnortSam to listen only on 192.168.1.15, you would use a line like this:

bindip 192.168.1.15

In addition, the default port that SnortSam listens on is 898, but you can change this with the port option.

After you’re done with SnortSam’s options, you’ll need to tell it what kind of firewall to communicate with and how to do it. To use SnortSam with a Checkpoint Ffwexec or fwsamW-1 firewall, you can specify either the fwexec or fwsam keywords. Use fwexec when you when you want to run SnortSam on the host that the firewall is install fwexec or fwsamed on, and use fwsam when you want to communicate with a remote firewall.

The fwexec keyword takes the full pathname to the fw executable as its only argument, whereas the fwsam keyword uses the hostname or IP of the firewall. In addition, you’ll need to modify the fwopsec.conf file on your firewall to include the following line:

sam_server port 1813

To use SnortSam with a PIX firewall, you’ll need to use the pix keyword and specify the IP address of the firewall as well as the Telnet and enable mode passwords.

For example:

pix 192.16.1.2 telnetpw enablepw

Or, if your firewall is set up to do user authentication, you can use user/password in place of the Telnet password.

If you want to use SnortSam with OpenBSD’s PF or Linux’s iptables, you’ll need to use the pf or iptables keywords. For basic usage, all you need to do is specify the interface on which to block packets.

To configure the Snort side of things, you’ll need to add the alert_fwsam output plug-in to the output plug-ins that you’re already using. This plug-in takes a hostname and an optional port to connect to, along with a password. If SnortSam is using the default port, you don’t need to specify the port here.

For example:

output alert_fwsam: firewall/mypassword firewall2:1025/mypassword

Notice that you can list multiple instances of SnortSam to send block requests to by separating them with whitespace.

Any rules that you want to trigger a firewall rule should be modified to use the fwsam rule option. This option takes as its arguments what to block and for how long the block should be in effect. To block the source of the packet that caused the alert, use src; to block the destination, use dst. If you want to block both, use either. For the duration you can use a number along with a modifier specifying what unit it’s in (i.e., seconds, minutes, hours, days, weeks, months, or years), or you can use 0 to specify an indefinite period of time.

For instance, to block the source address of the packet that triggered a rule for five minutes, you could add this to your rule options:

fwsam: src, 5 minutes;

Now that everything is configured, start SnortSam by running a command similar to this:

# snortsam /usr/local/etc/snortsam.conf

Of course, you’ll need to substitute the full path to your configuration file if it’s not /usr/local/etc/snortsam.conf. As for Snort, just start it as you normally would.

For more information on using SnortSam with other types of firewalls, be sure to check out the README files included with the source distribution.

Customize Snort for your own needs quickly and easily by leveraging its flexible rule engine and language.

One of the best features of Snort is its rule engine and language. Snort’s rule engine provides an extensive language that enables you to write your own rules, allowing you to extend it to meet the needs of your own network.

A Snort rule can be broken down into two basic parts, the rule header and options for the rule. The rule header contains the action to perform, the protocol that the rule applies to, and the source and destination addresses and ports. The rule options allow you to create a descriptive message to associate with the rule, as well as check a variety of other packet attributes by making use of Snort’s extensive library of plug-ins.

Here’s the general form of a Snort rule:

action proto src_ip src_port direction dst_ip dst_port (options)

When a packet comes in, its source and destination IP addresses and ports are then compared to the rules in the ruleset. If any of them are applicable to the packet, then the options are compared to the packet. If all of these comparisons return a match, then the specified action is taken.

Snort provides several built-in actions that you can use when crafting your rules. To simply log the packet that matches a rule, use the log action. The alert action generates an alert using the method specified in your configuration file or on the command line, in addition to logging the packet. One nice feature is that you can have very general rules and then create exceptions by writing a rule that uses the pass action. This works especially well when you are using the rules distributed with Snort, but are frequently getting false positives for some of them. If this happens and it’s not a security risk to ignore them, you can simply write a pass rule for it.

The last two built-in rule actions are used together to dynamically modify Snort’s ruleset at runtime. These are the activate and dynamic actions. Rules that use the dynamic action are just like a log rule, except they will be considered only after they have been enabled by an activate rule. To accomplish this, Snort enforces the use of the activates and activated_by rule options in order to know what dynamic rules to enable once an activate rule has been triggered. In addition, dynamic rules are required to specify a count option in order for Snort to limit how many packets the rule will record.

For instance, if you wanted to start recording packets once an exploit of a SSH daemon on 192.168.1.21 was noticed, you could use a couple of rules similar to these:

activate tcp any any -> 192.168.1.21 22 (content:”/bin/sh”; activates:1; \

msg:”Possible SSH buffer overflow”; )

dynamic tcp any any -> 192.168.1.21 22 (activated_by:1; count:100;)

These two rules aren’t completely foolproof, but if someone were to run an exploit with shell code against an SSH daemon, it would most likely send the string /bin/sh in the clear in order to spawn a shell on the system being attacked. In addition, since SSH is encrypted, strings like that wouldn’t be sent to the daemon under normal circumstances. Once the first rule is triggered, it will activate the second one, which will record 100 packets and then stop. This is useful, since you might be able to catch the intruder downloading or installing a root kit within those first few packets and be able to analyze the compromised system much more quickly.

You can also define custom rule actions, in addition to those that Snort has built-in. This is done with the ruletype keyword:

ruletype redalert

{

type alert

output alert_syslog: LOG_AUTH LOG_ALERT

output database: log, mysql, user=snort dbname=snort host=localhost

}

This custom rule action tells Snort that it behaves like the alert rule action, but specifies that the alerts should be sent to the syslog daemon, while the packet will be logged to a database. When defining a custom action, you can use any of Snort’s output plug-ins, just as you would if you were configuring them as your primary output method.

Snort’s detection engine supports several protocols. The proto field is used to specify what protocol your rule applies to. Valid values for this field are ip, icmp, tcp, and udp.

The next fields in a Snort rule are used to specify the source and destination IP addresses and ports of the packet, as well as the direction the packet is traveling. Snort can accept a single IP or a list of addresses. When specifying a list of IP address, you should separate each one with a comma and then enclose the list within square brackets, like this:

[192.168.1.1,192.168.1.45,10.1.1.24]

When doing this, be careful not to use any whitespace. You can also specify ranges of IP addresses using CIDR notation, or even include CIDR ranges within lists. Snort also allows you to apply the logical NOT operator (!) to an IP address or CIDR range to specify that the rule should match all but that address or range of addresses.

As with IP addresses, Snort can accept single ports as well as ranges. To specify a range, use a colon character to separate the lower bound from the upper bound. For example, if you wanted to specify all ports from 1 to 1024, you would do it like this:

1:1024

You can also apply the NOT operator to a port, and you can specify a range of ports without an upper or lower bound.

For instance, if you only wanted to examine ports greater than 1024, you would do it this way:

1024:

Similarly, you could specify ports less than 1024 by doing this:

:1024

If you do not care about the IP address or port, you can simply specify any.

Moving on, the direction field is used to tell Snort which IP address and port is the source and which pair is the destination. In earlier versions of Snort you could use either -> or <- to specify the direction. However, the <- operator was removed since you can make either one equivalent to the other by just switching the IP addresses and port numbers. Snort does have another direction operator in addition to ->, though. Specifying <> as the direction tells Snort that you want the rule to apply bidirectionally. This is especially useful when using log rules or dynamic rules, since you can log both sides of the TCP stream rather than just one direction.

The next part of the rule includes the options. This part lets you specify many other attributes to check against. Each option is implemented through a Snort plug-in. When a rule that specifies an option is triggered, Snort will run through the option’s corresponding plug-in to perform the check against the packet. Snort has over 40 plug-ins—too many to cover in detail in this hack. Here are some of the more useful ones.

The single most useful option is msg. This option allows you to specify a custom message that will be logged in the alert when a packet matching the rule is detected. Without it, most alerts wouldn’t make much sense at first glance. This option takes a string enclosed in quotes as its argument.

For example, this specifies a logical message whenever Snort notices any traffic that is sent from 192.168.1.35:

alert tcp 192.168.1.35 any -> any any (msg:”Traffic from 192.168.1.35″;)

Be sure not to include any escaped quotes within the string. Snort’s parser is a simple one and does not support escaping characters.

Another useful option is content, which allows you to search a packet for a sequence of characters or hexadecimal values. If you are searching for a string, you can just put it in quotes. In addition, if you want it to do a case-insensitive search, you can add nocase; to the end of all your options. However, if you are looking for a sequence of hexadecimal digits, you must enclose them in | characters.

This rule will trigger when it sees the digit 0x90:

alert tcp any any -> any any (msg:”Possible exploit”; content:”|90|”;)

This digit is the hexadecimal equivalent of the NOP instruction on the x86 architecture and is often seen in exploit code since it can be used to make buffer overflow exploits easier to write.

The offset and depth options can be used in conjunction with the content option to limit the searched portion of the data payload to a specific range of bytes.

If you wanted to limit content matches for NOP instructions to between bytes 40 and 75 of the data portion of a packet, you could modify the previously shown rule to look like this:

alert tcp any any -> any any (msg:”Possible exploit”; content:”|90|”; \

offset:40; depth:75;)

You can also match against packets that do not contain the specified sequence by prefixing it with a !. In addition, many shell code payloads can be very large compared to the normal amount of data carried in a packet sent to a particular service. You can check the size of a packet’s data payload by using the dsize option. This option takes a number as an argument. In addition, you can specify an upper bound by using the < operator, or you can choose a lower bound by using the > operator. Upper and lower bounds can be expressed with <>.

For example:

alert tcp any any -> any any (msg:”Possible exploit”; content:”|90|”; \

offset:40; depth:75; dsize: >6000;)

This modifies the previous rule to match only if the data payload’s size is greater than 6000 bytes, in addition to the other options criteria.

To check the TCP flags of a packet, Snort provides the flags option. This option is especially useful for detecting portscans that employ various invalid flag combinations.

For example, this rule will detect when the SYN and FIN flags are set at the same time:

alert any any -> any any (flags: SF,12; msg: “Possible SYN FIN scan”;)

Valid flags are S for SYN, F for FIN, R for RST, P for PSH, A for ACK, and U for URG. In addition, Snort lets you check the values of the two reserved flag bits. You can specify these by using either 1 or 2. You can also match packets that have no flags set by using 0. There are also several operators that the flags option will accept. You can prepend either a + , *, or ! to the flags, to match on all the flags plus any others, any of the flags, or only if none of the flags are set, respectively.

One of the best features of Snort is that it provides many plug-ins that can be used in the options field of a rule. The options discussed here should get you off to a good start. However, if you want to write more complex rules, consult Snort’s excellent rule documentation, which contains full descriptions and examples for each of Snort’s rule options. The Snort User’s Manual is available at http://www.snort.org/docs/writing_rules/.