RE: checkpoint fw and snort

[Frank Knobbe <FKnobbe () KnobbeITS com>]

-----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