Snort mailing list archives
RE: checkpoint fw and snort
From: Frank Knobbe <FKnobbe () KnobbeITS com>
Date: Wed, 15 Aug 2001 19:42:27 -0500
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
-----Original Message----- From: Steve Moran [mailto:steve.moran () csssoftware com] Sent: Wednesday, August 15, 2001 6:06 PM I've heard a rumor that there's a plugin available for snort to allow it to interact with a CPFW. Has anyone else heard this rumor? or have any information on it?
No rumor, it's pretty much done (well, a few things will be added, but it is working great and has past testing). I'm currently working on the website for it. Files are available through FTP and CVS. Below is the draft documentation. Regards, Frank SnortSam Documentation, v 1.0 (draft) - ------------------------------------- This documentation is still a work in progress. I may seperate the FAQ from the rest later, but I think it is worth reading to understand the process. Comments, questions and additions are always welcome. 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. 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 blocks itself? 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 to build a more comprehensive network of IDS's and firewalls that participate in the automated blocking process. 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 are the rules. snort.conf - ---------- In order to cause Snort to send 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: <FW Mgmt Station>:<port>/<password> <FW Mgmt Station>: IP address or host name of the FW-1 management station. <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 FW-1 mgmt station, where SnortSam is running, 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 in 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, we 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 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. 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 example 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. The agent is run with the name of the config file as the argument. You can start it from a script, or run it as a daemon or service. If not specified, it tries to open the config file snortsam.cfg. The config file is a text file containing following lines: # a remark Lines starting with # or ; are remarks. defaultkey <key> Set's the default key for ALL allowed hosts to <key>. Example: defaultkey mydefaultpassword port <port> Set's the listening port to <port>. Defaults to 898 if line is omitted. Example: port 666 accept <host>/<mask>,<key> Lists authorized Snort sensors. You can specify hostname, IP address, IP address and network mask, and the encryption key used configured on that host/network. Example: accept 10.10.0.0/16,office accept snort1,mypass If the password is omitted, the default key will be used. You can only specify one host per line, but you can supply unlimited lines. keyinterval <time> Causes the agent to request/create a new encryption keys every <time>. If line is omitted, it defaults to 4 hours. Again, hours, days, months, weeks, years can be used. Example: keyinterval 30 minutes dontblock <host>/<mask> Adds the host or network to the white-list. Hosts/Networks specified will never be blocked. Example: dontblock a.root-servers.net dontblock 192.168.10.0/24 Only one host/network per line, but you can list unlimited lines override <host>/<mask> <time> Each Snort rule requests its own time interval for the blocking request. Here on the agent, you can override the duration with a specified value. This is good for proxy servers, or other situations, where an attacker 'shares' an IP address with other hosts/users that you don't want to block for long. (You don't want to block ALL of AOL for a week... :) Example: override proxy.aol.com 5 min fwexec <path>fw.exe If specified, SnortSam will call the Firewall-1 executable to create the block. If this line is omitted, SnortSam will send a packet to the localhost on port 18183 in order to create the block. This line is useful if there are problems with OPSEC. Example: fwexec c:\winnt\fw\bin\fw.exe rollbackhosts <amount> Keeps a record of <amount> last blocks for each snort sensor. These blocks will be rolled back, meaning the hosts unblocked, in the event that the blocking threshold is exceeded. Example: rollbackhosts 50 If omitted, SnortSam will not keep a record of the IP addresses that have been blocked. rollbackthreshold <amount> / <time> Specifies the blocking threshold. If the threshold is exceeded (more than <amount> blocking requests in <time>), SnortSam will unblock the last <x> hosts specified by the 'rollbackhosts' statement. Example: rollbackthreshold 20 / 30 secs rollbacksleeptime <time> When the rollback threshold has been exceeded, SnortSam will ignore blocking request until the level drop back below the threshold. Using 'rollbacksleeptime' you can specify an additional time period that SnortSam will wait until it starts acting on blocking requests again. Example: rollbacksleeptime 1 minute Other statements will be added when those features become available. 'logfile' and 'loglevel' will be done shortly. 'forward' is planned for the near future. 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. 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) 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 port 18183 (instead of auth_port). That will allow clear-text connections to the SAM port which is what SnortSam sends. I have noticed that sam_allow_remote_requests does not seem to limit the access, so anyone could potentially send a SAM packet to the firewall. You can and should avoid that by either using a stealth rule, or explicitly denying access with a rule such as 'any / firewall / fw_sam / drop'. Since SnortSam runs on the firewall itself, it can still send packets to the localhost. Using this method improves 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 by sensor. So if you have two snort sensors (say one in front of the firewall, and one inside), and one (i.e. outside) trips the attack detection, SnortSam will ignore requests from that sensor, but still honor requests from the other (i.e. inside) sensor. 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 point of view, and from the firewall side of view. 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 integration IDS systems and firewalls is still in its infancy. These systems will mature over time, and so will SnortSam. SnortSam will be available via its website at <to be announced> :) 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. Regards, Frank (Frank () Knobbe net) -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.8 Comment: PGP or S/MIME encrypted email preferred. iQA/AwUBO3sW8pytSsEygtEFEQKJzQCgiMT+/H4osO52BZKE14sQwPxezHgAoLkB WnLeQelz2jRUGlehOMfpNTRM =u3Oo -----END PGP SIGNATURE----- _______________________________________________ Snort-users mailing list Snort-users () lists sourceforge net Go to this URL to change user options or unsubscribe: http://lists.sourceforge.net/lists/listinfo/snort-users Snort-users list archive: http://www.geocrawler.com/redir-sf.php3?list=snort-users
Current thread:
- checkpoint fw and snort Steve Moran (Aug 15)
- Re: checkpoint fw and snort cm (Aug 16)
- <Possible follow-ups>
- RE: checkpoint fw and snort Frank Knobbe (Aug 15)