SnortSam FAQ

Q: What is SnortSam?

A: SnortSam is an intelligent agent that allows the popular open-source Intrusion Detection System called Snort to block intruding connections by reconfiguration of Checkpoint Firewall-1/VPN-1 firewalls. It can also block on Cisco PIX firewalls and Cisco routers.

Q: How does that work?

A: Snort has been extended with an 'output plugin' that notifies the SnortSam agent of blocking requests on a rule basis. Each Snort rule can be extended with a keyword that sends the blocking request.

Q: So Snort itself does the block?

A: Not quite. There is another plugin available that does directly connect to Firewall-1. However, it lacks several important features, and blocks always permanently, which is not a good thing to do. SnortSam is build on a client-agent based concept for several reasons: One is to reduce the workload of the IDS sensor (Snort). The second reason is that using this concept, one can build a comprehensive network of sensors and firewalls. Each Snort sensor can request a block at an unlimited number of firewalls, and each firewall can accept an unlimited number of IDS sensors. SnortSam is the intelligent agent which runs on the firewall itself.

Q: So how does this work?

A: A Snort sensor is configured with the address of the agent, and rules that should request a blocking action are extended with certain parameters. When a rule triggers a block, the Snort sensor sends an encrypted TCP packet to one or more SnortSam agents that are running on the firewalls. The agent performs certain checks, and if allowed, will request the firewall to block the reported IP address.

Q: What makes the agent so smart then?

A: The SnortSam agent on the firewall receives a blocking request packet. First it verifies that the request came form an authorized source. It then decrypts the request. If successful, meaning if the passwords or keys of the Snort sensor and the SnortSam agent match, the agent accepts it as a valid request. SnortSam will then figure out the IP address of the host violating the snort rule. SnortSam then checks if this IP address is in a white-list. A white-list is a list of IP addresses that will never be blocked (for example, you shouldn't block the Internet root DNS servers). Then it checks if the duration of the block that the Snort sensor requested should be overridden with a default duration. Finally it request a block on the firewall host it resides on. This block can be performed either by sending a packet to the OPSEC port for SAM (Suspicious Activity Monitor, port 18183), or by launching the FW executable.

Q: That's it?

A: Almost. Once a block has been performed. SnortSam notes the time and IP address of the block. In the configuration file of SnortSam, a 'rollback threshold' can be configured. This is done by specifying an amount of blocking requests within a certain time period. Should this threshold be exceeded (which usually indicates an unusual or abnormal activity, such as a DoS? attempt against SnortSam), SnortSam will unblock a certain number of the last blocks performed, and then goes into a sleep-mode until the rate of blocking requests falls back below the specified level. Only then will SnortSam start to honor blocking requests again. This is done on a per Snort sensor basis.

Q: Anything else?

A: Not yet, but other features are planned for future releases. One of these is the ability of SnortSam to forward blocking requests to other SnortSam agents. This allows the creation of more comprehensive networks of IDS's and firewalls participating in the automated blocking process.

I just added a plugin structure to SnortSam that will allow it to perform blocks on other firewalls and routers in addition to Checkpoint firewalls. Currently, the OPSEC plug-in is available, which adds true OPSEC compatibility through Checkpoint's OPSEC SDK.

Also, we have a PIX plugin. Run SnortSam on a box close to the PIX firewall and configure it for access to the PIX. It will then block IP addresses on the PIX and expire them by keeping track of the blocks itself (since the PIX can not time out blocks).

Furthermore, we have a Cisco router ACL plugin that downloads the current router config, blocks the offending IP by adding it to the denied ACL, and uploading the configuration back to the router.

Q: You mentioned encryption. What is used and why?

A: The communication between Snort and the SnortSam agent is encrypted with the TwoFish algorithm (256 bit). The encryption keys specified are only initial keys. A key interval can be specified where new keys are generated automatically. This is one part of making this whole setup secure. In addition, the SnortSam agent will only accept connections from specified hosts/networks. Furthermore, the encrypted packet contains a sequence number. Those three facts (list of authorized sensors, encryption of data, sequence number checks) should make it almost impossible to spoof the blocking requests.

Q: How do I configure Snort?

A: Configuration of Snort occurs in two places. One is the snort.conf file, and the other is the rule files.

snort.conf

In order to cause Snort to send a blocking request to the SnortSam agent, that agent has to be listed, including the port it listens on, and the encryption key it is using. The statement for that is:

output alert_fwsam: {SnortSam Station}:{port}/{password} 

  {SnortSam Station}:  IP address or host name of the host where SnortSam is running.
  {port}:              The port the remote SnortSam agent listens on.
  {password}:          The password, or key, used for encryption of the communication to the remote agent.
 

At the very least, the IP address or host name of the host running SnortSam needs to be specified. If the port is omitted, it defaults to TCP port 898. If the password is omitted, it defaults to a preset password (In which case it needs to be omitted on the SnortSam agent as well).

More than one host can be specified, but has to be done on the same line. Just separate them with one or more spaces.

Examples:

output alert_fwsam: firewall/idspassword
output alert_fwsam: fw1.domain.tld:898/mykey
output alert_fwsam: 192.168.0.1/borderfw  192.168.1.254/wanfw

Rule files

Once the agent is listed, you need to modify the rules so that they invoke the blocking request. This is done by adding following statement to the rule:

fwsam: who[how],time;

Examples:

fwsam: src[either],15min or dst[in], 2 days 4 hours or src, 1 hour

(default: src[either],5min)

who: Can be: src, source, dst, dest, destination IP address to be blocked according to snort rule (some rules are reversed, i.e. homenet -> any and you want to block any, so DST would be appropriate)

how: Optional. Can be: In, out, src, dest, either, both, this, conn, connection Tells FW-1 to block packets INcoming from host, OUTgoing to host, EITHERway, or only THIS connection (IP/service pair). See 'fw sam' for more information.

time: Duration of block in seconds. (Accepts 'days', 'months', 'weeks', 'years', 'minutes', 'seconds', 'hours'. Alternatively, a value of 0, or the keyword 'PERManent', 'INFinite', or 'ALWAYS', will block the host permanently. Be very careful with this! Tells FW-1 how long to block packets from the host.

This statement is very dependent on the rule itself. Here are some real Snort example rules:

alert tcp any any -> $HTTP_SERVERS 80 (msg:"WEB-MISC http directory traversal"; flags: A+; content: "..\\";reference:arachnids,298; fwsam: 15 minutes;) 

The rule applies to a connection from any to your servers. That means the source is the attacker, the destination is you. The above fwsam statement will block the source for 15 minutes.

alert tcp $HOME_NET 23 -> any any (msg:"TELNET not on console"; flags: A+; content:"not on system console"; nocase; reference:arachnids,365; fwsam: dest, 1 day;) 

This rule applies to connections from your host to the attacker. The source is your system, the destination is the attacker. That means you would want to block the destination. Above fwsam statement will block the destination for a whole day.

Both examples will block incoming and outgoing connections to the attackers. If you wanted to block only incoming connections, but want to allow outgoing connections to the attacker (maybe for an investigative scan), then the fwsam statements would have to be modified with [in] to explicitly block only incoming connections.

i.e. fwsam: src[in], 15 minutes
     fwsam: dest[in], 1 day

For modifying Snort rules, it is best that you first figure out, who you want to block (which depends on the rule itself). Then you have to decide if you want to completely block the offender, or only block incoming (or perhaps only block outgoing connections). Finally, decide how long you want to block them.

It is recommended that you start with short time intervals for testing purposes and increase the time once the rule is 'tuned'.

I personally don't recommend to block permanently. See discussion at the end of this document.

Q: And how do you configure SnortSam?

A: The agent running on the firewall has to be configured as well. You can start it from a script, or run it as a daemon or service. The agent is run with the name of the config file as the argument. If not specified, it tries to open the config file snortsam.cfg under Windows, and /etc/snortsam.conf under Unix and other platforms. The config file is a text file containing the lines are defined in the file README.conf.

PLEASE SEE SnortSamREADME.conf? FOR A COMPLETE LIST OF CONFIGURATION OPTIONS.

Other statements will be added when those features become available. 'forward' is planned for a future release where one SnortSam agent can forward a blocking request to other SnortSam agents.

Note regarding time values (in Snort rules and the SnortSam config): All time values are basically supplied with their modifier (secs, min). If no modifier is supplied, the value is in seconds. You can add more than one modifier, i.e. 1 day 3 hours 30 mins 10 secs. All these values are summed up. You can abbreviate down to the first character, so 'seconds', 'secs', 'sec', 's' are all the same. The value of 1 month is equal to 30 days.

30 30 seconds 30 secs 30 seconds 30 min 1800 seconds 1 hour 30 min 5400 seconds

Q: Do I need to configure something on the firewall itself?

A: Yes. Unless you are using the 'fwexec' statement, you need to do following:

On the firewall where SnortSam is running, you need to change the file /fw/conf/fwopsec.conf (version 4.0) or /fw1/4.1/conf/fwopsec.conf (version 4.1) or /fw1/ng/conf/fwopsec.conf (Next Generation) as follows:

By default it should contain:

sam_server      auth_port       18183
lea_server      auth_port       18184
# authenticated connections for servers
# server      {server IP}    {service port}      auth_opsec
server        127.0.0.1         18181            auth_opsec
server        127.0.0.1         18182            auth_opsec
sam_allow_remote_requests no

You may already have added other entries. For SnortSam to work properly, you need to change line 1 to

sam_server   auth_port   0
sam_server        port   18183

That will allow clear-text connections to the SAM port which is what SnortSam sends. sam_allow_remote_requests should be set to YES on all firewall modules that you want to send requests to directly (as supposed to proxy mode where requests are sent through the management station). Running SnortSam on the firewall itself can improve blocking speed. In my test I have snort configured to block on ICMP echo's to the firewall. When a box pings the firewall, only the first ping is replied to, the rest already gets filtered.

Further explanation of the threshold mechanism:

Example: rollbackhosts 20 rollbackthreshold 10 / 15 secs rollbacksleeptime 30 secs

When 10 or more blocking requests are received within 15 secs, SnortSam will undo the last 20 blocks and remain inactive as long as the threshold is exceeded. Once the rate of blocking requests drops back below 10 blocks within 15 seconds, SnortSam will wait an additional 30 seconds before allowing blocking requests again. These values can be tuned to avoid DoS? attack conditions. Let's say someone figures out that you are actively reconfiguring your firewall, and starts sending spoofed packets. The amount of blocking requests will rise above a 'normal' level. With these rollback values, SnortSam will detect the attack, undo the already blocked IP's and then wait for the attack to end.

The attack recognition is done per configured sensor. So if you have two snort sensors (say one in front of the firewall, and one behind), and one (i.e. in front) trips the attack detection, SnortSam will ignore requests from that sensor, but still honor requests from the other sensor (i.e. behind the firewall).

If rollbackhosts is not specified, it defaults to 0, which means SnortSam does not keep a history of blocking requests. If rollbackthreshold is 0 / whatever (default if not specified), it will not engage the detection engine and block whatever it is requested to block.

Q: Nice, but why would someone want to block intruders?

A: There are several scenarios where the blocking mechanism comes in very handy:

Port Scans: Let's say your router to the Internet is at IP address x.x.x.1. Your firewall has rules for servers in the DMZ, which have IP address x.x.x.68 through x.x.x.80. Port scans usually occur with an increasing IP address. A scanner would first scan x.x.x.1, then x.x.x.2 and eventually reach x.x.x.68 which could be your DNS server. If you create a Snort rule that gets activated when someone tries to scan x.x.x.2, you can block that scanner for, say, 15 minutes. Since the time period between detection and implementation of the block is relatively short, the scanner will be blocked by the time he scans x.x.x.68. So instead of finding an open DNS port, the scanner does not see anything at all. He is effectively blinded, and does not detect any of the services on your servers.

This applies even to a single host. If a rule blocks when someone scans a host on port 1, by the time the scanner reaches port 80 for example, he may already be blocked.

Hacker Block: Let's say someone uses an exploit tool to check for a web server vulnerability (i.e. Unicode, Code Red, etc). If he uses the tool against your web server, Snort will detect the attack, and can reconfigure your firewall to block that intruder for, say, 4 hours. The first packet (i.e. GET /scripts/../../winnt/system32/ cmd.exe?dir) will enter your web server. Because such attacks can happen quickly, should your web server be vulnerable, the attacker can already launch some code. For example, he may be trying to TFTP some trojan into the web server. If SnortSam blocks the intruder, chances are good that he will not be able to do any further damage (such as downloading trojans) because he will be blocked.

Trojan Block and Policy Block: You can configure Snort rules to block when certain traffic pattern are detected. That can be an outgoing connection from a DDoS? trojan (i.e. Stacheldraht), or just a connection to a file sharing service (i.e. Napster). You can modify the rule so that either the source (your internal machine) will be blocked so that it can not establish any other connections to the Internet, or you can block the destination (i.e. Napster server) so that no one else (including the triggering user) can connect to that destination.

Q: How can I block with a threshold level on one set of rules, but

block with a different threshold level on other rules?

A: Excellent question. If you have an attack threshold configured for incoming attacks (port scans), but you don't want to use an attack threshold for outgoing attacks (DDoS?), you would have to run two different SnortSam configurations on the same firewall, just on different ports. Currently, Snort will send blocking requests to all agents listed. Future versions of the plugin will allow for a more extensive parameter set in the Snort rules that will support tagged agents.

The basic problem is that one can look at parameters from the sensor perspective and from the firewall perspective. I personally don't want to specify too many parameters in the Snort rules, but instead move those (and the intelligent processing) out to a different host, the firewall. These things can be played with and adjusted as the program matures.

The concept of integrating IDS systems and firewalls is still in its infancy. These systems will mature over time, and so will SnortSam.

SnortSam is available through the SnortSam website at http://www.snortsam.net via FTP and CVS. The snort plugin portion will hopefully be included in the CVS tree of Snort shortly. Both are available to further development by the open source community. You may direct any questions, updates, and bug reports directly to me via email.

-- MattJonkman - 09 Mar 2007