README - Frank Knobbe <frank@knobbe.us>
-------------------------------------------------------------------------------


Forthcoming. Please see INSTALL (and the old FAQ). Also, README.conf is useful
for a list of options. Finally, some firewall dependent information is already
available in README.<firewall> files. Others will be added shortly.



-------------------------------------------------------------------------------
$Id: README,v 1.2 2003/01/16 05:54:23 fknobbe Exp $

README.ciscoacl - Ali Basel <alib@sabanciuniv.edu>
-------------------------------------------------------------------------------

THE CISCOACL PLUGIN DOES NOT DOWNLOAD THE CONFIG FILE FROM THE ROUTERS PER
DEFAULT!

The ciscoacl plugin lets you deny the attackers using ACL on the Cisco routers.

In order to use the ciscoacl plugin, first of all, you have to prepare an ACL file which has a special format.
If you already use an ACL, you must add your ACL statements into that ACL file.
Here is the format of that "acl_file":

conf t
interface interfacename  		<--- put your interface name here
no ip access-group test_acl out 	<--- you can use "out" or "in" here. ("test_acl" is the name of your ACL)
exit
no ip access-list extended test_acl  	<--- the name of the acl (named ACLs)
ip access-list extended test_acl
snortsam-ciscoacl-begin  		<--- my plugin will insert the blocking statements here
snortsam-ciscoacl-end
... 					<--- if you already have an ACL, put it here
permit ip any any 			<--- if you don't already have an ACL, use this line instead
exit
interface interfacename
ip access-group test_acl out
end


All the ciscoacl plugin does is to insert (and remove when the blocking time expires) "deny ip host attacker-ip any" statements into the "acl_file" between "snortsam-ciscoacl-begin" and "snortsam-ciscoacl-end" and upload the "acl_file" into the router(s).

In order to use the ciscoacl plugin, you have to supply a simple snortsam.conf config file which must have a "ciscoacl" config-line like the one below:

/etc/snortsam.conf
# ciscoacl plugin is not compatible with the threaded version due to the nature of ACLs.
# DISABLE threads
nothreads
#
accept IP_of_the_host_running_snort
defaultkey secret
ciscoacl IP_of_the_router_which_will_deny_with_ACL username/password enablepassword /full_path/acl_file
logfile /var/log/snortsam.log
loglevel 3


The ciscoacl plugin offers three ways to upload to "acl_file" into the router:
1. The default method: telnet
	When the default telnet method is used, the pluging makes a telnet connection, does the authentication, and issues thecommands on the "acl_file".

2. tftp
	When the present ACL have a lot of lines, it takes long time to upload the "acl_file" using the first method above. I that case, tftp: should be used.
	When this method is used, the ciscoacl plugin makes a telnet connection into the router, does the authentication, and issues the commands on an other file "tftp_file" which has the command "copy tftp: running-config", and the plugin provides the IP address of the tftp server and "acl_file" for the file to upload.
	It takes only a couple of seconds to upload long acl.

3. expect
	All the above methods use telnet when making the connection to routers. Since the telnet protocol isn't encrypted it's not a good idea anymore to use telnet, moreover disableing telnet connection is advised.
	You may use expect interpreter (http://expect.nist.gov/) to automatize definitive tasks.
	By using a simple expect script you may make a secure ssh connection into the router, and issue "copy tftp: running-config" command to uplad the "acl_file".
	A sample expect script is provided at end of that document.



To use the above methods, you have to supply the required definition in your ciscoacl config file.
Here are the config format for these methods:
1. telnet
	This is the default method:
	ciscoacl IP_of_the_router_which_will_deny_with_ACL username/password enablepassword /full_path/acl_file
	When you don't use tftp you must give the "acl_file" name with /full_path !

2. tftp
	ciscoacl IP_of_the_router_which_will_deny_with_ACL username/password enablepassword acl_file|/full_path/tftp_file
	You must append the "tftp_file" at the end with a "|" character.

	THE ACL FILE MUST BE IN the "/tftpboot" folder, and READABLE.
	snortsam must be runned inside the /tftpboot/ folder: "cd /tftpboot; snortsam"


3. expect
	You have to prepare an expect file which makes an ssh connection into the router, and uploads the "acl_file" with tftp.
	ciscoacl IP_of_the_router_which_will_deny_with_ACL username/password enablepassword acl_file|expect:/full_path/expect_file

	THE ACL FILE MUST BE IN the "/tftpboot" folder, and READABLE.
        snortsam must be runned inside the /tftpboot/ folder: "cd /tftpboot; snortsam"



Steps For Using tftp
--------------------
If you have long ACLs you should use tftp: to upload your acl_file into the router.
In order to use this method, you have to follow the steps below:
1. Prepare a file (I call it "tftp_file"):

copy tftp: running-config
IP_of_the_tftp_server

Here tftp: means that you will use tftp: when uploading the ACL file "acl_file".

2. Install and run a tftp server on the snortsam box.

3. Add the tftp_file name (separate with "|", do NOT use any spaces) to the
ciscoacl line in the /etc/snortsam.conf file:

ciscoacl IP_of_the_router_which_will_deny_with_ACL username/password enablepassword acl_file|tftp_file

**********************************************************************************
* THE ACL FILE MUST BE IN the "/tftpboot" folder, and READABLE.                  *
* snortsam must be runned inside the /tftpboot/ folder: "cd /tftpboot; snortsam" *
**********************************************************************************

That's all, from now on, your router will upload your acl_file with tftp, and this will be a lot faster.


Steps For Using Expect:
-----------------------
Using expect is the most versatile method, because you may prepare an script according to your choice and needs.
All the ciscoal plugin does after modifying the "acl_file" is to call your expect script, then the rest is depends to your expect script.
Before using that method, expect package (http://expect.nist.gov) must be installed; most of the linux distributions have that package.
Prepare an expect script and test it by hand before using with snortsam.

Prepare the ciscoacl config line in the snortsam.config file like the one below:
ciscoacl IP_of_the_router_which_will_deny_with_ACL username/password enablepassword acl_file|expect:/full_path/expect_file

THE ACL FILE MUST BE IN the "/tftpboot" folder, and READABLE.
snortsam must be runned inside the /tftpboot/ folder: "cd /tftpboot; snortsam"



Troubleshooting:
-----------------
It is very useful to have a look at the snortsam.log file, to see what happens:

# tail -f /var/log/snortsam.log

If you want to use more than one router for blocking the attackers, you have
to supply another config line and acl-file for each router:

# cat /etc/snortsam.conf
accept IP_of_the_host_running_snort
defaultkey secret
ciscoacl IP_of_the_router_which_will_deny_with_ACL username/password enablepassword /full_path/acl_file
ciscoacl IP_of_the_another_router_which_will_deny_with_ACL username/password enablepassword /full_path/acl_file2
logfile /var/log/snortsam.log
loglevel 3

THE CISCOACL PLUGIN DOES NOT DOWNLOAD THE ACL FROM THE ROUTER!


Example Expect Script:
----------------------
"_upload" MUST BE ADDED TO THE "acl_file" name like below:
username, PASSWORD and ENABLE_PASSWORD must be changed according to your settings.

#!/usr/bin/expect -f
set timeout -1
eval spawn "ssh username@IP_of_the_router\r"
expect  "*assword: "
send -- "PASSWORD\r"
expect  "*>"
send -- "en\r"
expect  "*assword: "
send -- "ENABLE_PASSWORD\r"
expect  "*#"
send -- "copy tftp: running-config\r"
expect  "*[]? "
send -- "IP_of_the_tftp_server\r"
expect  "*[]? "
send -- "ACL_FILE_upload\r"
expect  "*]? "
send -- "running-config\r"
expect  "*#"
send -- "exit\r"
expect eof



Ali BASEL
alib@sabanciuniv.edu



-------------------------------------------------------------------------------
$Id: README.ciscoacl,v 2.4 2005/07/10 21:27:05 fknobbe Exp $

README.conf - Frank Knobbe <frank@knobbe.us>
-------------------------------------------------------------------------------

This is a summary of configuration options in the SnortSam configuration file.
On Windows systems it is called snortsam.cfg by default and is located in the
same directory where SnortSam.exe resides. On Unix systems, the default is
/usr/local/etc/snortsam/snortsam.conf.

The config file is a text file containing one or more of the following lines.


SnortSam specific options:
--------------------------

# a remark

    Lines starting with # or ; are remarks. All text after # (or ;) is
    truncated which means that you can list an # after a valid option as well.
    If you intend to use a # (or ;) as part of an option, you have to escape it
    with a back-slash, for example:

       <option> This is a \# valid char  # But this is a comment

    This would translate after parsing to:

       <option> This is a # valid char



defaultkey <key>

    Set's the default key for ALL allowed hosts to <key>.
    The default key is used when no other key is specified in an ACCEPT option.
    You have to use the same key in the snort.conf file in the
    "output alert_fwsam line". If the keys, or passwords if you will, don't
    match, SnortSam can not decrypt the request from Snort and ignore it.

    Example:   defaultkey mydefaultpassword

    If omitted, SnortSam will use a default key (in which case it would have to
    omitted in snort.conf as well).



port <port>

    This sets the listening port to <port>.

    Example:   port 666

    It defaults to 898 if this line is omitted.



accept <host>/<mask>,<key>

    This option lists Snort sensors that SnortSam is accepting packets from.
    You can specify hostname, IP address, IP address and network mask, and
    optionally an encryption key used configured for that host or network.

    Examples:  accept 10.10.0.0/16, officepassword
               accept snort1, hostpassword
               accept 192.168.1.1

    If the password is omitted, the default key specified with DEFAULTKEY will
    be used. You can only specify one host per line, but you can supply
    unlimited lines.



keyinterval <time>

    This causes the agent to request/create a new encryption key every <time>.
    If this line is omitted, the key lifetime defaults to 4 hours. You can use
    'hours', 'days', 'months', 'weeks', 'years' in the duration.

    Example:   keyinterval 30 minutes



dontblock <host>/<mask>
dontunblock <host>/<mask>

    This adds the host or network to the white-list of hosts/networks that will
    never be blocked or unblocked. Blocking or unblocking request for hosts
    on this list are ignored.

    Examples:  dontblock a.root-servers.net
               dontblock 192.168.10.0/24

    Only one host/network per line can be specified, but you can list unlimited
    lines



onlyblock <host>/<mask>
onlyunblock <host>/<mask>

    If this is specified, Snortsam will only block IP address that match this
    list of IP's or networks. All other block requests are ignored. The same
    applies to unblocks if the "onlyunblock" keyword is specified. Uses for
    the latter might be limited, but it's available. DONTBLOCK still applies
    within this list.

    Examples:  onlyblock 10.0.0.0/8

    Only one host/network per line can be specified, 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... :)

    Examples:  override proxy.aol.com, 5 min
               override 192.168.1.0/24, 10 sec



upperlimit <host>/<mask>,<time>
limit <host>/<mask>,<time>

    This statement allows you to set a maximum time duration for all SID/blocks
    dependent on the reporting sensor. It acts like 'override', but instead of
    setting a new duration, this statement limits the duration to the defined
    maximum blocktime. Note that the host/network refers to a Snort sensor
    (or a forwarding Snortsam station) and does not refer to the IP address to
    be blocked like 'override' does.

    Example:   limit 192.168.1.0/24, 2 weeks



lowerlimit <host>/<mask>,<time>
atleast <host>/<mask>,<time>

    This statement allows you to set a minimum time duration for all SID/blocks
    dependent on the reporting sensor. It is the complement to 'limit', but
    instead of reducing the duration to a maximum limit, it bumps up any
    duration that is lower to this minimum duration.

    Example:   limit 192.168.1.0/24, 1 day



denysidfrom <host>/<mask>: <sid>,<sid>,...

    This statement causes Snortsam to ignore blocking requests for particular
    SID based on a given sensor. Either a single SID or multiple SIDs can be
    listed. When listing multiple SIDs, make sure you separate them with commas
    and not just spaces.

    Examples:  denysidfrom 192.168.1.0/24: 1345
               denysidfrom othersnortsam.someone.net: 1411, 1422, 0, 2002123

    (Note the use of SID 0 which is typically used for manual blocks/unblocks
    when no SID is specified, for example, on the command line when using the
    samtool.)



allowsidfrom <host>/<mask>: <sid>,<sid>,...

    This statement is the invert of 'denysidfrom'. It will cause Snortsam to
    only accept the SIDs listed and by default ignore all other SIDs.
    If a conflict exist by the same SID appearing in an 'allowsidfrom' line and
    a 'denysidfrom' line, the deny takes priority.

    Example:   allowsidfrom 10.0.0.0/8: 3200, 3201, 3203, 4332, 4333, 4334



rollbackhosts <amount>

    This tells SnortSam to keep 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 for rollback purposes.



rollbackthreshold <amount> / <time>

    This 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 requests until the level drops back below the threshold. Using
    this option you can specify an additional time period that SnortSam will
    wait until it starts acting on blocking requests again.

    Example:   rollbacksleeptime 1 minute

    If omitted, and the rollback mechanism is used, it defaults to 15 minutes.



skipinterval <time>

    SnortSam skips repetitive, identical blocking requests (for performance
    reasons). Here you specify the time interval for which blocks are
    considered repetitive.

    Example:   skipinterval 30 secs

    If omitted, SnortSam will use a default time period of 10 seconds in which
    it considers requests to be repetitive.



skiphosts <amount>

    Tells SnortSam how many hosts it should remember for repetitive block
    checks.

    Example:   skiphosts 10

    If omitted, SnortSam will remember a default of 10 hosts.



logfile <filename>

    SnortSam will use this file to log certain events such as program start,
    block/unblock actions performed and error events. If only a file name is
    specified (without a path), the file will be created a) on Windows systems
    in the same directory where SnortSam.exe resides, and b) on Unix systems
    in /var/log.

    Example:   logfile snortsam.log

    No logging occurs if this line is omitted.



loglevel <level>

    The file logging level can be set to 0, 1, 2, or 3:
       0: Quiet - No logging occurs.
       1: Sparse - Only errors are logged.
       2: Normal - Errors and blocks are logged.
       3: Verbose - Additional information (such as connections/disconnections)
          are logged as well.

    Example:   loglevel 2

    If omitted, a level of 2 (normal logging) is assumed.



screenlevel <level>

    The logging level, just like loglevel, but for screen output.
      (See above for values)

    Example:   screenlevel 3

    If omitted, a level of 2 (normal logging) is assumed.



include <file>

    This statement includes another configuration file. Only one level of
    inclusion is supported.

    Example:   include dontblocklist.cfg



statefile <filename>

    SnortSam will use this file name for the state file instead of the default.
    This avoids conflicts on hosts with mutliple Snortsam instances.

    The default of /var/db/snortsam.state (or snortsam.sta on Windows) is used
    if this line is omitted.

    Example:   statefile /var/db/2nd-snortsam.state



avoidstatefile

    Starting with version 2.8, SnortSam will always keep a state file so the
    additions to dontblock-list can be checked against current blocks (and
    unblocked automatically if a host is on the DONTBLOCK list, but had been
    blocked before). If you are using SnortSam only to block on Checkpoint
    firewalls, you could avoid the state file since FW-1 will time-out blocks
    by itself. To do that, just use this statement in the config file.

    Example:   avoidstatefile

    Note that if you load a plugin that requires SnortSam to unblock the
    blocks, and thus requires the state file, it will be created regardless if
    this option is present.



disablereverselookups

    This option turns off reverse name resolution in logging plugins, currently
    only used by the email plugin.

    Example:   disablereverselookups



disablepersistentconnections
disablepersistenttcp

    This option turns off persistent TCP connections for the FORWARD plugin as
    introduced with version 2.51. It also does not use persistent connections
    for connecting hosts like the Snort plugin, a remote forwarder, or the
    samtool. In essence, Snortsam will behave like pre-2.51 versions.
    The default is now to leave persistent-TCP disabled. See also below.

    Example:   disablepersistentconnections



enablepersistentconnections
enablepersistenttcp

    This option turns on persistent TCP connections for the FORWARD plugin as
    introduced with version 2.51. It also accepts persistent connections from
    connecting hosts like the Snort plugin, a remote forwarder, or the samtool.
    In essence, Snortsam will behave like pre-2.51 versions.

    By default, persistens TCP connections are disabled now, and you need this
    option to forcefully enable it. Beware, persistent TCP connections are
    still experimental and may cause problems.

    Example:   enablepersistentconnections



disableseqnocheck

    This option turns off sequence number checking in SnortSam. SeqNo
    violations are currently not punished (by banning the offending Snort
    sensor), but it was planned to do so in the future to increase security.
    Use this option to turn packet sequence number checking off.

    Example:   disableseqnocheck



holdsnort

    This option requires version 1.13 or higher of the Snort plugin. It places
    Snort 'on hold' during processing of the blocking request, and resumes
    Snort once the block is completed.

    Example:   holdsnort

    THIS WILL SLOW SNORT DOWN! USE ONLY FOR TESTING OR IN CONJUNCTION WITH
    BARNYARD!



nothreads

    This option disables the multi-threading capability and causes SnortSam
    not to use thread functions at all. Instead, all plugins are executed
    sequentially within the main process. This makes SnortSam behave like the
    old, single-threaded version 1. It is useful for testing, or if you
    encounter problems with plugins that have problems with POSIX threads.

    Example:   nothreads



forcethreads

    This option forces use of multi-threading capability on systems that have
    it disabled by default, which currently is all Linux versions.

    Example:   forcethreads



daemon

    This option causes Snortsam to turn into a daemon upon startup. It is
    similar to the -D option of many other tools and services.

    Example:   daemon



bindip

    This option causes Snortsam to bind only to one IP address (or interface)
    instead of listening on all interfaces/addresses.

    Example:   bindip 192.168.0.1




Firewall specific options:
--------------------------

fwexec <path/fw.exe>

    If specified, SnortSam will call the fw.exe executable to create the blocks
    on Firewall-1. Normally you would use either 'fwsam' or 'opsec' (see
    below). This line is useful if there are problems with OPSEC or you don't
    want to send packets to the firewall. SnortSam will have to run on the
    FW-1 host of course.

    Example:   fwexec c:\winnt\fw\bin\fw.exe



fwsam <host>

    This statement tells SnortSam to use the self-assembled OPSEC packet to
    initiate blocks. You have to specify the name or IP address of the
    firewall to which to send the block. You can only list one IP address per
    line, but supply unlimited lines (one for each firewall you have).

    Examples:  fwsam 127.0.0.1
               fwsam wanfw.corp.com



fwsamipflip

    The fwsam method should block the correct IP address if SnortSam is run on
    the firewall host itself. However, if SnortSam runs on a small-endian box,
    and FW-1 runs on a big-endian box, it may block the reversed IP address.
    Use this option to flip it back to normal.

    Example:   fwsamipflip



opsec <file>

   This statement tells SnortSam to use the OPSEC API functions of the OPSEC
   plug-in, configured through the <file> config file (opsec.conf is available
   as an example. Also see README.opsec). Use this instead of fwsam for use of
   the official OPSEC API. You can add more than one config to allow more than
   one firewall to execute the block (each firewall would need its own conf
   file). Currently, only clear-text is supported, but you may have luck with
   auth_port or SSL. If so, please let me know.

   Examples:  opsec opsec.conf
              opsec wan_firewall.conf

   In opsec.conf, or whatever your file is named, change the IP of the server
   to reflect your firewalls IP (or leave at 127.0.0.1 if you run SnortSam on
   the firewall itself).


   NOTE TO ABOVE METHODS:

   If you are blocking on Checkpoint Firewall-1, use ONE OF THE THREE METHODS
   listed above. You don't have to specify them all. It is your choice which
   method to use (although I personally recommend fwsam).



pix <ip> <telnetpw> <enablepw>
pix <ip> <username>/<password> <enablepw>

    This statement tells SnortSam to use the PIX plugin. SnortSam will telnet
    into the PIX at address <ip>, log in with the given telnet and enable
    password, and use the SHUN command to block IP addresses. If the second
    parameter contains a /, SnortSam will use the word before the / as the
    username and the remainder as the user password. This is useful when a PIX
    has been configured to use RADIUS or TACACS for login authentication.

    Examples:  pix 1.2.3.4 letmein enableme

    If the enable password is omitted, the telnet password will be used at the
    telnet and enable prompt.



ciscoacl <ip> <telnetpw> <enablepw> <acl_filename>
ciscoacl <ip> <username>/<password> <enablepw> <acl_filename>

    This statement tells SnortSam to use the Cisco ACL plugin to block IP's on
    a Cisco router. SnortSam will telnet into router at address <ip>, log in
    with the <telnetpw> as the password at the telnet prompt, or use
    <username> and <password> if TACACS is used for authentication, and modify
    the Access Control List. You need to supply your baseline configuration
    file <acl_filename> in the configuration line. SnortSam will insert ACL
    statements so that access from and to the intruding IP address is denied,
    and upload the config to the router.

    Example:   ciscoacl 1.2.3.4 telnetpw enablepw myconfig

    If the router is configured to authenticate access with TACACS, you would
    use:
               ciscoacl 1.2.3.4 user/password enablepw myconfig



cisconullroute <ip> <telnetpw> <enablepw>
cisconullroute <ip> <username>/<password> <enablepw>

    This statement tells SnortSam to use the Cisco Null-Route plugin to block
    IP's on a Cisco router. SnortSam will telnet into router at address <ip>,
    log in with the <telnetpw> as the password at the telnet prompt, or use
    <username> and <password> if TACACS is used for authentication, and issue
    a route command that will "null-route" the IP to be blocked. It will then
    save the configuration to memory. Once the block has expired, Snortsam
    again log in and remove the added route, saving the config to memory.

    Example:   cisconullroute 1.2.3.4 telnetpw enablepw

    If the router is configured to authenticate access with TACACS, you would
    use:
               cisconullroute 1.2.3.4 user/password enablepw



cisconullroute2 r=<ip> p=telnetpw e=enablepw
cisconullroute2 r=<ip> p=telnetpw e=enablepw t=<tag>
cisconullroute2 r=<ip> u=username p=password e=enablepw t=<tag> a=y

    This statement tells SnortSam to use the Cisco Null-Route2 plugin to block
    IP's on a Cisco router. This is a more flexible version of the
    Cisco Null-Route plugin (see above) with a few more options.
    You can specify a 'route tag' to mark the route on the router.
    Eg. t=667, would result in 'ip route x.x.x.x 255.255.255.255 Null0 tag 667'.
    You can also set the auto-enable option to y (a=y), if SnortSam should NOT
    run the enable command because it enters directly in eg. priv-level 15

    Parameters:
    r=<router ip> (required)
    u=<username> (optional)
    p=<password> (required)
    e=<enable password> (optional)
    t=<route tag> (optional [1-4294967295])
    a=<auto-enable> (optional, [yn])

    Example:
    cisconullroute2 r=1.2.3.4 u=username p=password e=enablepw t=666 a=y
    cisconullroute2 r=1.2.3.4 p=telnetpw e=enablepw t=666
    cisconullroute2 r=1.2.3.4 p=telnetpw e=enablepw



email <smtpserver>:<port> <recipient> <sender>

    This statement sends an email for every block and unblock event. You
    specify your SMTP server by name or IP address, and the email address you
    want to send the notification to. Only one recipient per line is supported,
    more than one line be be specified. By default, SnortSam will send the
    email from SnortSam@<hostname>, but you can override the sender by adding
    a specific sender after the recipient. Also, you can optionally specify
    a custom port in case you run SMTP on a different port. (Default is 25)

    Example:   email mailserver.mydom.com root@mydom.com
               email 127.0.0.1 admin@mydom.com SnortSam@mydom.com
               email localhost:10025 ops@mydom.com



email-blocks-only <smtpserver>:<port> <recipient> <sender>

    This statement is the same as "email" except that it only sends emails for
    block events, not unblock events. This was easier to implement as a plugin
    since "email" requires the creation of a state file while
    "email-blocks-only" does not (see also "avoidstatefile").

    Example:   email mailserver.mydom.com root@mydom.com



netscreen <ip> <login id> <login password> <optional groupname> <opt zone name>

    This statement will activate the Netscreen plugin. It is similar to the PIX
    plugin in that is telnets into the firewall, but instead of issuing a shun
    command (which the Netscreen doesn't have), it adds the IP to be blocked to
    a group which you can use for a global 'deny' rule. For more info, please
    see README.netscreen.

    Example:   netscreen 10.0.0.1 admin mypassword MyBlockGroup MyZone

    If the group name is omitted, SnortSam will add/remove IP's to/from the
    default group called 'SnortSam'.
    Also, one can override the default zone name with a custom zone name. The
    MyZone parameter is optional. If used, a block group name must also be
    specified.



ipf <adapter> <loglevel>

    This plugin will execute the command ipf locally and block the host by
    adding a rule to the ipf policy. You have to specify the adapter to block
    on (for example, fxp0) and you can optionally add a logging facility
    (default is local7.info).

    Example:   ipf ep0 local7.info



pf <adapter> <logoption>

    This plugin will use an ioctl syscall to control the pf device in order to
    block the host by adding a rule to the active rule set of pf. You have to
    specify the adapter to block on (for example, fxp0) and you can optionally
    add a log option (log, logall).

    Example:   pf dc0 log



pf2 <anchor> <table> <kill>

   This plugin will use an ioctl syscall to control the pf device in order to
   block the host by adding the host IP into a pf table. Additional active pf
   states to/from the host will be killed.

   Example: pf2 anchor=snortsam table=block kill=all



ipchains <adapter> <logoption>

    This plugin will use an setsockopt call to control the ipchains options
    in order to block the host by adding a rule to the active rule set.
    You have to specify the adapter to block on (for example, eth0) and you can
    optionally add a log option (log, logall).

    Example:   ipchains eth0 log



iptables <adapter> <logoption>

    This plugin will call the iptables executable in order to block the host by
    adding a rule to the active rule set. You have to specify the adapter to
    block on (for example, eth0) and you can optionally add a log option.

    Example:   iptables eth0 syslog.info



ebtables <adapter> <logoption>

    This plugin will call the ebtables executable in order to block the host by
    adding a rule to the active rule set. You have to specify the adapter to
    block on (for example, eth0) and you can optionally add a log option.

    Example:   ebtables eth0 syslog.info



watchguard <path/to/fbidsmate> <ip-of-firebox> <configpassword>
watchguard <path/to/fbidsmate> <ip-of-firebox> file <configpassfile>

    This plugin will call the fbidsmate program to block the host on Watchguard
    firewalls. You have to specify the path to the fbidsmate program, the
    IP address of the firewall, and either a clear-text password, or the name
    of a file containing the encrypted password. For more information, please
    see the README.wgrd file.

    Examples: watchguard /bin/fbidsmate 10.1.0.1 mySecretPass
              watchguard /bin/fbidsmate 10.1.0.1 file /etc/fbidsmate.passphrase



8signs <path/dfw.exe> <tarpit>

    SnortSam will call the specified dfw.exe executable to create the block
    on the 8signs firewall. Snortsam will always block IPs without expiration
    (-expiry n) because the 8signs firewall can only block for a day, a week,
    or permanently. Snortsam blocks permanently and then times-out the blocks
    itself, issuing an unban of the IP to 8signs, so that normal time
    intervals are possible (for example, 10 minute blocks).
    Optionally, the word "tarpit" can be appended to cause 8signs to ban and
    tarpit the IP address.

    Examples:  8signs c:\progra~1\8signs~1\dfw.exe
               8signs c:\progra~1\8signs~1\dfw.exe tarpit



isa <log>

    SnortSam will use the API in msfpccom.dll to control the Microsoft ISA
    Server interface in order to add blocking rules to the ISA firewall
    rules.
    Optionally, the word "log" can be appended to cause ISA Server to log
    connection attempts from the blocked IP address.

    Examples:  isa
               isa log



chx-i <path/fltcon.exe> <log>

    SnortSam will call the specified fltcon.exe executable (or just fltcon if
    none is specified, in which case fltcon would need to be in the PATH) to
    create the block on the CHX-I packet filter. Snortsam can only block, and
    can not forcefully unblock IP addresses. In order to frocefully remove
    a blocked host, just restart the CHX-I service and all blocked IP addresses
    are released.
    Optionally, the word "log" can be appended to cause CHX-I to log blocked
    packets.

    Examples:  chx-i c:\somewhere\fltcon.exe
               chx-i fltcon.exe log



ipfw2 <adapter> <inbound-table> <outbound-table>

    This plugin will add/remove IP addresses to be blocked/unblocked into the
    corresponding table(s). Tables are a new feature of ipfw2. You have to set
    up these tables manually before starting Snortsam exactly like this:

          deny ip from any to table(<inbound-table>) via <adapter>
    and:  deny ip from table(<outbound-table>) to any via <adapter>

    If these tables are not present in your ipfw2 rule set, Snortsam will not
    start and report an error. With the tables present, configure Snortsam
    accordingly.

    Example:   ipfw2 ep0 1 2

    With tables rules like:
               00010 deny ip from any to table(1) via ep0
               00011 deny ip from table(2) to any via ep0



forward <snortsam-ip>:<port>/<password>

    This plugin will forward a block/unblock request to another Snortsam agent
    running on this or another host. This allows you link Snortsams in a chain,
    providing for a completely distributed blocking infrastructure. You can
    configure two Snortsam agents to forward to each other. The loop is avoided
    by the repetitive block prevention. IF YOU DISABLE REPETITIVE BLOCK
    SETTINGS, YOU WILL CREATE AN ENDLESS LOOP CAUSING RESOURCE EXHAUSTION OR
    STARVATION OR A DENIAL-OF-SERVICE CONDITION!
    Take note that any white-list or override lists are processed before the
    request is forwarded. The planned "passthrough" plugin will avoid this
    limitation in the future. It is recommended to create separate Snortsam
    instances for "distribution hubs" which don't have white-list or override
    restrictions.

    Example:   forward secondsnortsam.domain.net
               forward other-snortsam.mynet.com/otherpass
               forward 127.0.0.1:890

-------------------------------------------------------------------------------
$Id: README.conf,v 2.30 2009/11/27 01:39:39 fknobbe Exp $

README.iptables - Fabrizio Tivano <fabrizio@sad.it>
-------------------------------------------------------------------------------

The Iptables plugin works on all linux box, iptables installed.


Default configuration is for any linux iptables-firewall with default DROP rule,
and working with 2 interfaces:

eth0 = internal net
eth1 = external net

you can also change the target ethernet card by adding the correct ethX name on
the snortsam.conf file.


The standard block command is:
iptables -I FORWARD -i eth1  -s {ip_addr_to_be_blocked} -j REJECT

The standard unblock command is:
iptables -D FORWARD -i eth1  -s {ip_addr_to_be_unblocked} -j REJECT


To start support for Iptables you have to add one line to the snortsam.conf
like:

iptables eth1 log



You can also make  your iptables block/unblock command by editing the module
ssp_iptables.c (PAY ATTENTION AT THE CORRECT IPTABLES SYNTAX!!!) and then
recompile it.



Fabrizio Tivano
fabrizio@sad.it

-------------------------------------------------------------------------------
$Id: README.iptables,v 1.1 2003/04/13 19:47:33 fknobbe Exp $

README.netscreen - Christopher Lyon <cslyon@netsvcs.com>
-------------------------------------------------------------------------------

Comments, questions, additions, input and constructive criticism are always
welcome.

Please read the entire file and perform a backup of your configuration before
making any changes on your Netscreen. If you don't know how to perform a backup
of your configuration, please obtain a users manual. Just a hint, a 'get config'
command gets the entire configuration from your unit so if you can telnet into
the Netscreen that is the command you need to run. Take the output on your
screen and save it to a text file. We don't assume any reasonability if you
blow up your Netscreen using these commands. We are just trying to help you get
started and we can't take reasonability for anything that you did, haven't done,
or are going to do. So, don't blame us, me or anybody on the SnortSam team.


SnortSam Configuration

Usage for the Netscreen option in the config is:

netscreen <firewall-ip> <login-id> <login-pw> <optional-group-name>


Netscreen Configuration

In order to get this working there are a few things that must be setup first on
the Netscreen. The first thing is to setup a group on the Netscreen.
The default name for the group is called 'SnortSam'. That is unless you change
it in the conf file. The way SnortSam interacts with the Netscreen is that is
adds and removes IP addresses to and from this group on the Netscreen.

Note: We picked groups instead of adding and deleting rules to the policy
because of the way Netscreen does the rules and how they are added, and then
moved when doing them from the CLI. If you are using routed mode you might
need more than one rule to do blocking, depending upon if you have any inbound
services. A group instead of adding rules would be a better fit. Keep in mind
that the Netscreen, like other firewalls, reads the rules from top down. So
you want to keep these rules that we are entering closest to the top, so that
they can be most effective.


Routed and Transparent Mode Considerations

There are two modes that your Netscreen can operate in, routed mode and
transparent mode. Routed mode is when you have separate layer 3 networks on
each interface. Your trusted interface has two modes that it can use, but only
if you are in routed mode. Those two modes are NAT and route. If you are using
private addresses on your trusted interface then it should be set to NAT mode.
Please note that if you are using NAT mode there are special considerations
to make. Since there is only one group support for SnortSam right now, the best
that we can do is block traffic going to your DMZ if you have one. Keep in mind
that there is a default deny rule on your incoming policy, so blocking there
using SnortSam really doesn't do anything. If you have any one-to-one network
address translation going between your trusted and untrusted network, you will
need to pick which is more important to block (for now). If you want to block
on your untrusted interface like the examples below you will need to create a
policy with an explicit deny for each inbound service. SnortSam will add the IP
addresses to the group. The Netscreen 5's or 5xp make great screening walls for
relatively low speed connections. I am talking about less than 3 meg links.
They are cheap and you can still get Netscreen 5's.

If you are using transparent mode then you have dropped the Netscreen in
between your internet router and your hosts or firewall. That would mean that
you have a single IP address for management of the box. Unless you mess up the
default configuration, nobody can get to the Netscreen from the outside in
transparent mode directly. This, in my opinion, is a great way to do a
screening wall. The best configuration is to put your IDS sensor between your
screening wall and your firewall where SnortSam is doing the blocking,
because you will be blocking everything before it hits your firewall. The
configurations below assumes that you are using transparent mode but if you
want to use routed mode there will be a few things that you will need to change.


Netscreen CLI commands (Basic)

The commands below assume that you are using transparent mode. If you are not
using transparent mode, you have to keep in mind that the commands will need to
modified to work. Once you have established a telnet session into the Netscreen,
you should see a -> prompt. The first command is to create a group. If you can't
telnet to the Netscreen, you must make sure that you can, or else SnortSam will
not be able to block. Go to the web GUI, and under the interface tab go to
'trusted'. Make sure that telnet is checked. You might need to reboot the
Netscreen in order for that to take effect.

Group Command:

Set group address untrust "SnortSam" comment "Put your comment here"

Now, the second command depends upon how many incoming rules you have. If you
do a 'get config' at the Netscreen CLI prompt, and look at the set policy
commands, you will see the rules that are currently being used. Note that the
rules are not in order by their id, but in the order of how they are enforced.
Remember, they are read from the top down and the id number is only used to
reposition the rules. So if your policy rules read like the ones below, you will
need to insert a rule before id 1. We don't care about the outgoing policy for
now, just the incoming policy.

Partial 'get config':
set policy id 0 outgoing "Inside Any" "Outside Any" "ANY" Permit log
set policy id 1 incoming "Outside Any" "Inside Any" "ANY" Permit


Policy Rule Command:
set policy before 1 incoming "SnortSam" "Inside Any" "ANY" Deny

By default, the group name 'SnortSam' is used. But if you want to use
something else you can do so via the SnortSam configuration file. Note we use
the 'before 1 incoming' in the rule above. But if your first incoming rule is
id 5, then the command would be 'before 5 incoming'. You can add the following
after the deny if you want, but keep in mind all these take up more memory and
processor resources.

count 		enable counting
log		enable logging
schedule	set scheduler
traffic		traffic parameters

After you have executed the command, your policy rules should look like this:

set policy id 0 outgoing "Inside Any" "Outside Any" "ANY" Permit log
set policy id 2 incoming "SnortSam" "Inside Any" "ANY" Deny
set policy id 1 incoming "Outside Any" "Inside Any" "ANY" Permit

That is it for the Netscreen configuration.

Known Issues:

Some of the Netscreen's, depending upon the code version that you are using,
may only let one person from the same IP address telnet into the box. So, if
you are testing this out and want to see the modifications in real time, either
use the web interface or a different box to view the modifications.

This is more of an FYI than an issue but with the new code 4.x there might be
some issues with this configuration. I am just saying this because I don't
know, I haven't tested it. I should have a chance to test it in a week or two.
The structure in 4.x is a little different so beware.


Regards,
Christopher Lyon
cslyon@netsvcs.com



-------------------------------------------------------------------------------
$Id: README.netscreen,v 1.3 2003/01/16 05:54:23 fknobbe Exp $

README.pf 3.0 - Hector A. Paterno <apaterno@dsnsecurity.com>
-------------------------------------------------------------------------------
For additional notes from Olaf Schreck, see farther below.
-------------------------------------------------------------------------------

1. Description.

This plugin is for IP blocking on different versions of OpenBSD Operating
System and FreeBSD 5.1 with pf4freebsd port installed and working.
Since this lastest release it supports OpenBSD 3.3, 3.4 and FreeBSD 5.1 using
tables, anchors, and rulesets, who recently made available in pf.
It now uses a new kind of configuration options ( option=value option2=value2
etc. ) Please see 3. Options to obtain a full list of available options.
Note : This is not a pf tutorial, please read the pf documentation to understand
the concepts of anchors, tables, rulesets etc. .

2. Compatibility.

This lastest release supports, compiles, works, and has been tested on the
following OS/Versions :

OpenBSD 3.0
OpenBSD 3.1
OpenBSD 3.2
OpenBSD 3.3
OpenBSD 3.4
OpenBSD current ( 12/02/2003 ).
FreeBSD 5.1-RELEASE ( with http://pf4freebsd.love2party.net port ).
FreeBSD 5.1-CURRENT ( with http://pf4freebsd.love2party.net port ).
Now also:
OpenBSD 3.5
OpenBSD 3.6

3. Options.

This is the list of options that you can set in the configuration file :

auto=0/1
log=0/1
anchor=[string]
eth=[string]
(table=[string] - ignored. Listed for historical purposes only)

auto:
The auto option is used to tell the pf plugin to automatically (auto=1)
initialize all the required anchor/tables/rulesets/rules in the packed
filter (no pf.conf or manual modifications needed in the active ruleset).

log:
The rules created by the pf plugin will get the log option if this option is
set to 1 (log=1), so every time a blocked ip try to make a connection,
the correspont pf rule will generate a log entry on the pflog interface.

anchor:
Sets the anchor name used to hold the rulesets/tables/rules.

table:
Now ignored. Before Snortsam 2.30, it used to set the name of the table to
hold the blocked IPs.

eth:
Sets the interface name used when the anchor is created or when
the rules are added.

Example :
 pf auto=1 log=1 anchor=fwsamd table=blockedips eth=le1

All configuration options are parsed, no matter the OS/Version used, but not
all the parsed options are used, that depends on the OS/Version used, see
4. Notes to get a list of used/relevant options in your OS/Version.


4. Notes.

-- OpenBSD 3.0, 3.1 and 3.2 -- :

Under this OS/Versions only the "log", and "eth" options will be used by the pf
plugin, so on every block call, a new entire rule will be created with the
corresponding "log" and "eth" options at the head of the active ruleset.

-- OpenBSD 3.3 -- :

Under this OS/Version the "auto", "log", "eth", "table" options will be used
in the following mode :

Under OpenBSD 3.3 you will need to create 3 tables in the main ruleset
(unless you use the auto=1 option), one for the IN, one for the OUT,
and one for the INOUT.
For example if you wish to call your table "blockedips", then you will
need to create :

blockedipsIN
blockedipsOUT
blockedipsINOUT

tables and specify auto=0 ( the tables are already created by you ), and
table=blockedips ( without the IN, OUT, INOUT ) in the pf section of your
snortsam config file.

You must also create the rules who point to this tables ( unless you use
the auto=1 option ) :

block in from <blockedipsIN> to any
block out from any to <blockedipsOUT>
block in from <blockedipsINOUT> to any
block out from any to <blockedipsINOUT>

The "eth" and "log" options are used in auto=1 mode, when the pf plugin is
in charge of creating the rules. If you don't use the auto=1 mode, then this
parameters can specified in the rules that you must create.

So every block call will add an ip entry in the corresponding table, and
automatically gets blocked by the corresponding rule who blocks that table.
Under OpenBSD 3.3 all of this takes place in the main ruleset, no anchors or
rulesets are used.

-- OpenBSD 3.4, OpenBSD Current, FreeBSD 5.1-RELEASE, FreeBSD 5.1-CURRENT -- :

Under this OS/Versions all the options are used by the pf plugin, It creates (
unless you use auto=0 ) one call to the anchor specified by the "anchor"
option in the main ruleset with the optional "eth" name, and 3 rulesets inside
this "anchor" ( "IN", "OUT" and "INOUT" ), each ruleset has Its own table
( specified by the "table" option ) and Its set of rules with the optional
"log" option.

If you dont wish to use the auto=1 option, you must create this sets of
entries in your pf.conf file or by hand ( using pfctl command ) and set the
choosen parameters in the pf section of the snortsam configuration file.

If you got confused while try to create the anchor and rules to not to use the
auto=1 option, try to use the "auto=1" option at first, and see the
rules/rulesets/anchor/tables added automatically by the pf plugin as an example.



Hector A. Paterno
apaterno@dsnsecurity.com

-------------------------------------------------------------------------------
Note by Frank Knobbe:
FreeBSD support is currently disabled with #ifdef's. If you have loaded the pf
patch under FreeBSD 5.x, you need to remove the "#ifdef OpenBSD" in ssp_pf.c,
ssp_pf.h and plugins.h. Don't forget to remove the corresponding "#endif".
We need to clean this up later so that it doesn't throw errors on FreeBSD
systems without the pf port and Solaris/AIX/whateverix.
(What we really need is a make file... *sigh*)
-------------------------------------------------------------------------------
Updated 01-16-05, Note by Olaf Schreck <chakl@syscall.de>

This is based on Hector's code, read above sections first!

Use the following line in snortsam.conf:

        pf anchor=fwsam auto=1 [ log=... eth=... table=ignored ]

Choose any anchor name you like, I recommend "fwsam".  Use auto=1
unless you really want to do things manually, see below.  Use log
and eth as you did before, no changes to this stuff.  You may still
specify a table name, but it will be _ignored_, see "Changes" below.


Testing
-------

Create snort signatures like this, probably in local.rules:

        alert tcp any any -> $your_ip 11110 (msg:"TEST log 11110/tcp"; \
                sid:1111110;)
        alert tcp any any -> $your_ip 11111 (msg:"TEST block 11111/tcp"; \
                sid:1111111; fwsam:src[in],5min;)

- start snort and snortsam, verify the processes are running, check
  their logfiles for any errors;
- verify that the test sigs fire and that alerting works before
  proceeding.  I like to have snort log via syslog, do a "telnet
  $your_ip 11110" from any remote machine first, and then *expect*
  to see the "TEST log 11110/tcp" in syslog.  If that doesn't work for
  you, *fix your configuration first*, it is pointless to continue
  without working alerting;
- check that anchor, tables and rules exist after snortsam started,
  read the pfctl manpage;
        # pfctl -vsA
        # pftcl -a fwsam -sT
        # pfctl -a fwsam -t blockin -Ts
        # pfctl -a fwsam -t blockin -sr
- test snortsam blocking with "telnet $your_ip 11111" from any remote
  machine.  You should see a "TEST block 11111/tcp" alert in syslog, a
  message "Blocking $src_ip" in snortsam.log, and $src_ip listed in the
  output from "pfctl -a fwsam -t blockin -Ts".  All traffic from $src_ip
  to $your_ip should be blocked now.  After 5 minutes you should see
  "Unblocking $src_ip" in snortsam.log, $src_ip removed from the blockin
  table, and traffic from $src_ip to $your_ip should be allowed again.

At least, that would be *expected* behavior.  Prepare for debugging with
pfctl if it doesn't work out right.


Changes
-------

The last version of ssp_pf was for OpenBSD 3.4.  In 3.6 a change to the
pf ioctl API was introduced for "nested anchors".  Semantically, what
used to be a "named ruleset" within an anchor, is now a sub-anchor to
that anchor, which allows for tree-like ruleset structures.  The hard
part of this patch (for me) was figuring out where to put the anchor
references.

Changed some strcpy()s to strncpy(), deal with PF_MAX_*_SIZE correctly.

Hardcoded the table names to "blockin", "blockout" and "blockinout".
Laziness, what's the point of having configurable table names anyway?

My first approach was to convert the named "IN", "OUT" and "INOUT"
rulesets to sub-anchors.  Didn't work for other reasons, and it smelled
bloated.  After all, we have 4 rules operating on 3 tables, a simple
single anchor should be able to do that job just fine.. :)


Using auto=0
------------

The pf plugin is written for auto=1, if you disable it you'll have to
setup these things manually:

        - the pf anchor "fwsam" inside the main ruleset
        - 3 tables ("blockin", "blockout", "blockinout") inside the
          "fwsam" anchor
        - 4 rules like below inside the "fwsam" anchor
            block in  log quick from <blockin> to any
            block out log quick from any to <blockout>
            block in  log quick from <blockinout> to any
            block out log quick from any to <blockinout>


-------------------------------------------------------------------------------
$Id: README.pf,v 1.2 2005/01/16 22:55:27 fknobbe Exp $

README.pf2 - Olli Hauer <ohauer@gmx.de>
-------------------------------------------------------------------------------

1. Description.

This plugin is for IP blocking on different versions of *BSD Operating System.

The plugin supports anchors and tables, but they will not created for you!

It now uses a new kind of configuration options ( option=value option2=value2
etc. ) Please see 3. Options to obtain a full list of available options.
Note : This is not a pf tutorial, please read the pf documentation to understand
the concepts of anchors, tables, rulesets etc. .


2. Compatibility.

This latest release supports the following OS/Versions :

OpenBSD > 4.0
FreeBSD > 6.0 with pf support (as module or compiled into the kernel)
NetBSD ? with pf support (tested on NetBSD 5.0 i386)


3. Options.

This is the list of pf2 options that you can set in the configuration file:
----------------------------------------------------------------------------
anchor=[string] default: anchor=snortsam

 Sets the anchor name used to hold the tables/rulesets.
 To disable the usage of anchor use anchor=none or anchor=notused.


table=[string] default: table=block, which results in tables blockin and blockout

 The tablename in/outside an anchor.
 In addition to the table name the suffix 'in' and 'out' are added,
 so a table defined table=badip results into 'badipin' and 'badipout'.


kill=[string] default: kill=all

 Kill the pf states from/to the IP address we receive to block,
 else existing connections stay alive.
 Valid options are:
   all : kill all states to/from the IP address
   dir : kill only states alerted with the direction
   no  : kill no states, (keep existing connections open)


Example pf2 config lines in snortsam.cfg:
------------------------------------------
1) pf2 anchor=snortsam table=block
   - the tables blockin and blockout inside the anchor snortsam will be used.
   - kill all existing pf states from/to the IP address.

2) pf2 anchor=notused table=badguy kill=dir
   - the tables badguyin and badguyout outside any anchor will be used.
   - kill only existing pf states in the received direction.

3) pf2 anchor=none kill=no
   - tables blockin and blockout outside any anchor will be used.
   - no pf states will be killed.


pf.conf for examples above:
---------------------------
1)  # filter rules
    anchor snortam
    load config from "/etc/pf.conf.snortsam"

    -- file /etc/pf.conf.snortsam --
    # tables
    table <blockin> persist
    table <blockout> persist
    # filter rules
    block drop in quick log on bge0 from <blockin> to any
    block drop in quick log on bge1 from any to <blockout>


2)  # tables
    table <badguyin> persist
    table <badguyout> persist
    # filter rules
    block drop in quick log on $if_ext from <badguyin> to any
    block drop in quick log on $if_int from any to <badguyout>

3) see example 2) but table names are blockin,blockout (the default)


All configuration options are parsed, no matter the OS/Version used, but not
all the parsed options are used, that depends on the OS/Version used, see
4. Notes to get a list of used/relevant options in your OS/Version.


4. Notes.

The pf2 plugin does not create any rules, it is up to you to write the ruleset
which make usage of the two tables defined.

Testing
-------
The following signature expects snortsam configured with fwsam(in|out) as table
name.

Create snort signatures like this, probably in local.rules:

    alert tcp any any -> $your_ip 11110 (msg:"TEST log 11110/tcp"; \
        sid:1111110;)
    alert tcp any any -> $your_ip 11111 (msg:"TEST block 11111/tcp"; \
        sid:1111111; fwsam:src[in],5min;)


- start snort and snortsam, verify the processes are running, check their
  logfiles for any errors;

- verify that the test sigs fire and that alerting works before proceeding.
  I like to have snort log via syslog, do a "telnet $your_ip 11110" from any
  remote machine first, and then *expect* to see the "TEST log 11110/tcp"
  in syslog. If that doesn't work for you, *fix your configuration first*.
  It is pointless to continue without working alerting;

- check that anchor, tables and rules exist after snortsam started,
  read the pfctl manpage;

    # with anchor
    # pfctl -vsA
    # pftcl -a fwsam -sT
    # pfctl -a fwsam -t blockin -Ts
    # pfctl -a fwsam -t blockin -sr

    # without anchor
    # pftcl -sT
    # pfctl -t blockin -Ts


- test snortsam blocking with "telnet $your_ip 11111" from any remote machine.
  You should see a "TEST block 11111/tcp" alert in syslog, a message
  "Blocking $src_ip" in snortsam.log, and $src_ip listed in the output from
  "pfctl -a <anchor> -t <table> -Ts" or "pfctl -t <table> -Ts"

  All traffic from $src_ip to $your_ip should be blocked now. After 5 minutes
  you should see "Unblocking $src_ip" in snortsam.log, $src_ip removed from the
  <table>, and traffic from $src_ip to $your_ip should be allowed again.

  At least, that would be *expected* behavior.  Prepare for debugging with pfctl
  if it doesn't work out right.

- test yourself the different kill options, for example during a file transfer
  or simple with ping in both directions.

       # pfctl -ss | grep $src_ip
       # tcpdump -net -i pflog0 host $src_ip

-------------------------------------------------------------------------------
$Id: README.pf2,v 1.2 2009/11/27 01:39:39 fknobbe Exp $

README.rules - Frank Knobbe <frank@knobbe.us>
-------------------------------------------------------------------------------

This file explains the syntax of the "fwsam" statement in the Snort rule files.
It is currently just ripped from the old FAQ. I may clean it up later if needed.



Once the snort.conf file is configured, 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;

         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,
                                                                 or connection
              Tells the firewall to block packets INcoming from host, OUTgoing
              to host, EITHERway, or only THIS connection (IP/service pair).
              (If you have a Checkpoint firewall, 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 the firewall how long to block packets from the host.

Examples:

  fwsam: src[either],15min           (blocks to and from source for 15 minutes)
     or  dst[in], 2 days 4 hours     (blocks from dest. for 2 days and 4 hours)
     or  src, 1 hour                 (blocks to and from source for an hour)

Defaults to: src[either],5min

That means "fwsam: dst" will block the destination (right IP in Snort rule)
inbound and outbound for 5 minutes.


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


Instead of modifying the Snort rules, you can also create a file named
sid-block.map which has to be in the same directory as Snort's sid-msg.map
file (typically etc). In this file you can list the fwsam option using
following syntax:

  <sid>:<option>

For example:

   1023: src, 15 min

   Alternatively, you may use a | (pipe) instead of a : (colon).
   This has the same effect as adding "fwsam: src, 15min;" to the Snort rule
   with SID 1023.

   You can specify options in both places (rules and sid-block.map file), but
   the sid file takes priority. The file has to be in the same directory as the
   other Snort config files (ie. sid-msg.map).

-------------------------------------------------------------------------------
$Id: README.rules,v 1.1 2004/06/23 19:48:11 fknobbe Exp $

README.slackware - Joey Moe <family_geek@yahoo.com>
############################################################################
# This Readme file is a walk-through for installing Snort with the SnortSAM
# plugin on a computer running Slackware 10. They do not tell you how to
# configure Snort or SnortSAM, since there is already README files for this
# and every installation is unique, but it will be thorough. This walk-through
# assumes that you are saving these files to /usr/local/src. This is not a
# mandatory location, but it is the most common.
#
#	~ jmoe ~
#
##############################################################################
##########                       DEPENDANCIES                       ##########
##############################################################################
# First there are a few dependancies that you will have to install. These are
# not needed to run Snort, but they will be needed to run SnortSAM later. The
# dependancies need to be installed in the order listed here:
#
# libgpg-error-1.0 (http://bent.latency.net/bent/darcs/libgpg-error-1.0/src)
#
# To install:
#	tar zxvf libgpg-error-1.0.tar.gz
#	change directories to the libgpg-error-1.0 folder
#	./configure
#	make
#	make install
#	make clean
#
# libgcrypt-1.2.0 (http://lists.gnupg.org/pipermail/gnupg-announce/2004q2/000167.html)
#
# To install:
#	tar zxvf libgcrypt-1.2.0.tar.gz
#	change directories to the libgcrypt-1.2.0 folder
#	./configure
#	make
#	make install
#	make clean
#	Restart the computer
#
# gnutls-1.0.24 (http://lists.gnupg.org/pipermail/gnutls-dev/2005-January/000807.html)
#
# To install:
#	tar zxvf gnutls-1.0.24.tar.gz
#	change directories to the gnutils-1.0.24 folder
#	./configure
#	make
#	make install
#	make clean
#	Restart services
#
# libprelude-0.9.0-rc15 (http://www.prelude-ids.org/rubrique.php3?id_rubrique=6)
#
# To install:
#	tar zxvflibprelude-0.9.0-rc15.tar
#	change directories to the libprelude-0.9.0-rc14 folder
#	./configure
#	make
#	make install
#	make clean
#	Restart services
#
# automake-1.9.2 (http://lists.gnu.org/archive/html/autoconf/2004-09/msg00203.html)
#
# To install:
#
#	tar zxvf automake-1.9.2.tar.gz
#	change directories to the automake-1.9.2 folder
#	./configure
#	make
#	make install
#	make clean
#
# 	(You might want to do a "automake --version" to verify that 1.9.2 is
#	 your current version)
#
#
# Now that you have your dependancies installed, now we have to install Snort.
# I configured Snort to log to a MYSQL database, so I will be including this
# in this README file.
##############################################################################
##########                      INSTALLING SNORT                     #########
##############################################################################
#
# Snort-2.4.0 (www.snort.org)
#
# To Install:
#	tar zxvf snort-2.4.0.tar.gz
#	change directories to the Snort-2.4.0 folder
#	./configure --with-mysql=/usr
#	make
#	make install
#	make clean
#
# Snort-2.4.0 does not include the rules folder. You will have to download the
# current rule set. You can et this from www.snort.org. Make sure to copy this
# to your snort-2.4.0 root directory or point your snort.conf file to the location
# where you save it.
#
# With Snort installed we now have to create the MYSQL database. But before we
# we can create the database we need to setup MYSQL. I chose to use the MYSQL
# installation that came with the Slackware distro.
#
# MYSQL (OPTIONALLY: www.mysql.org)
#
# To Configure:
#	su mysql
#	mysql_install_database
#	/usr/bin/mysqld_safe &
#	/usr/bin/mysqladmin -u root password "your password"
#		(DO NOT INCLUDE QUOTES! This sets your MYSQL admin password)
#	mysql -u root -p
#		(You will be prompted for the password you just provided)
#		(Once you enter a password you will be given a MYSQL prompt)
#	create database snort;
#		(you must include the semicolon at the end)
#	connect snort;
#	source /usr/local/src/snort-2.4.0/schemas/create_mysql;
#		(you will see the creation of numerous tables)
#		(as verification, check the tables)
#	show tables;
#
# Next you wan to set permissions for your new snort database. This includes
# both accounts and passwords:
#
#	grant CREATE,INSERT,SELECT,DELETE,UPDATE on snort.* to snort;
#	grant CREATE,INSERT,SELECT,DELETE,UPDATE on snort.* to snort@localhost;
#	grant CREATE,INSERT,SELECT,DELETE,UPDATE on snort.* to root;
#	grant CREATE,INSERT,SELECT,DELETE,UPDATE on snort.* to root@localhost;
#
#	set password for 'snort'@'%'=password('your password');
#	set password for 'root'@'%'=password('your password');
#	set password for 'snort'@'localhost'=password('your mysql password');
#	set password for 'root'@'localhost'=password('your mysql password');
#
#	exit;
#		(you will be brought back to a command line prompt)
#	exit;
#		(you should be brought back to a root prompt)
#
#
# Next we need to download and install a package that is supposed to enhance
# the Snort MYSQL database. This file is snortdb-extra.gz. We need to download
# it to the /snort-2.4.0/contrib folder, (DO NOT UNCOMPRESS IT).
#
#	snortdb-extra.gz (http://cvs.snort.org/viewcvs.cgi/snort/contrib/Attic/snortdb-extra.gz)
#
# 	zcat /usr/local/src/snort-2.4.0/contrib/snortdb-extra.gz | mysql -p snort
#
# Now we have to adjust the snort.conf file to work with the newly configured
# snort database:
#
#	vi /usr/local/src/snort-2.4.0/etc/snort.conf
# 	:set number (this allows you to see the line numbers)
#
# On line 575 you will uncomment the line (remove the proceeding pound sign)
# and make the following changes to the user, password, dbname, and host
# fields:
#	"user"= the account you want to use to access the MYSQL snort database
#	"password"= password for the "user" you selected
#	"dbname"=snort
#	"host"=name of the localhost
#
# From here, you can escape, save, and exit.
#
# You have to create a folder in the /var/log directory for snort to log to,
# or else you will get an error
#
# 	mkdir /var/log/snort
#
# This would be a good time to verify that Snort is working. While there are
# numerous options for snort to use, I am only using the option to log to the
# snort database. -c option takes one argument: the path to the snort.conf
# file.
#
#	snort -c /usr/local/src/snort-2.4.0/etc/snort.conf
#
##############################################################################
##########                  INSTALLING SNORTSAM                     ##########
##############################################################################
# Now that you know snort is working correctly, now it is time to take it up a
# notch. I know there are many different scenarios and even more opinions of
# how to deploy your SnortSAM setup, this README file assumes you are
# installing Snort and SnortSAM on the same machine.
#
# You have to move to the SnortSAM directory and change the permissions on the
# shell script that creates snortsam:
#
#
#	tar zxvf snortsam-src-2.40.tar.gz  (www.snortsam.net/download.html)
#	change directories to the snortsam folder
#	chmod +x makesnortsam.sh
#	./makesnortsam.sh
#
# This creates two programs. (snortsam and snortsam-debug).Move these programs
# to the /usr/local/bin folder.
##############################################################################
##########                     PATCHING SNORT                       ##########
##############################################################################
# This is the last step to getting Snort to work with SnortSAM. It takes a
# little bit of work, but the pay off is huge. We have to first change the
# permissions on the patchsnort.sh file and then run it. The patch takes only
# one argument, the path to the snort-2.4.0 folder:
#
#	tar zxvf snortsam-patch.tar.gz (www.snortsam.net/download.html)
#	rename the folder "snortsam-patch"
#	change directories to the snortsam-patch
#	chmod +x patchsnort.sh
#	./patchsnort.sh /usr/local/src/snort-2.4.0
#
# At this point, you have change directories so you wind up in the snort-2.4.0
# folder. Once in the snort-2.4.0 directory, you have to run the following
# commands in the following order:
#
#	aclocal
#
#	When you run aclocal, you will get a small series of errors. This is
#	a quick run down of the files and modifications you need to make to
#	fix these:
#
#	In the file configure.in you will need to make the following changes:
#
#		- Line 169 originally looks like this:
#		  AC_DEFUN(SN_CHECK_DECL,[
#
#		  Change the line so it reads:
#		  AC_DEFUN([SN_CHECK_DECL],[
#
#		- Line 202 originally looks like this:
#		  AC_DEFUN(SN_CHECK_DECL,
#
#		  Change the line so it reads:
#		  AC_DEFUN([SN_CHECK_DECL],
#
#		- Line 298 originally looks like this:
#		  AC_DEFUN(FAIL_MESSAGE,[
#
#		  Change the line so it reads:
#		  AC_DEFUN([FAIL_MESSAGE],[
#
#
#	In the file /usr/local/share/aclocal/libgcrypt.m4 you  will need to
#	make the following changes:
#
#		- Line 23 originally looks like this:
#		  AC_DEFUN(AM_PATH_LIBGCRYPT,
#
#		  Change the line so it reads:
#		  AC_DEFUN([AM_PATH_LIBGCRYPT],
#
#	Now that aclocal is not reporting any errors you can finish the rest
#	of the snort patch process without any problems:
#
#	autoheader
#	automake --add-missing
#	autoconf
#
# Finally, you have to configure snort the same way you did when when we first
# installed it. Don't forget to include the MYSQL option for database support.
#
# From this point please see the respective README files for configuring Snort
# and SnortSAM. These files will show you how to fine tune your installation
##############################################################################
##############################################################################
$Id: README.slackware,v 1.2 2005/11/10 11:03:47 fknobbe Exp $

README.snmp_interface_down - Ali Basel <ali@basel.name.tr>
-------------------------------------------------------------------------------

This plugin may be used to stop local intruders by shutting-down their switch port.

This plugin uses the database of the trackerd (http://www.basel.name.tr/projects/tracker/index.html), so it must be set up and running.

All the "snmp_interface_down" plugin does is only to call the shell script "trackersnmp" with the IP address to be blocked; so, before using this pluging, you should test that the above script runs without any problem.

So what does trackersnmp ?
--------------------------
Network Tracker builds a table which records which user is connected on which port of a switch by scanning SNMP-enabled devices. It keeps the inventory of these devices up-to-date by scanning the network regularly. Devices are also checked with ping and SNMP, and the user is informed by email when any of the devices is not alive.

trackersnmp first, finds the given IP in that database to obtain the switch IP, SNMP community names, switch port number and ifindex of that port.
Before shutting down the switch port, trackersnmp queries the switch to be sure that the port belongs really to the given IP, and then, shuts down the port using SNMP.
It can also send e-mail which contains all of its output.

For more information about trackersnmp please read its documenation.



To use that plugin add the line below into the snortsam config file:
snmpinterfacedown	/full_path_of_the/trackersnmp



If the given IP couldn't be found in the trackerd database, no things happen.

Using than plugin is a very effective, but do not forget to define your servers in the "dontblock" list of the snortsam config file.


-------------------------------------------------------------------------------
$Id: README.snmp_interface_down,v 2.0 2005/07/10 21:17:05 fknobbe Exp $

README.watchguard - Thomas Maier <Thomas.Maier@arcos.de>
-------------------------------------------------------------------------------

The Watchguard plugin supports all WatchGuard Firebox System 5.0 or later
versions. But NOT the SOHO-Box.

The Watchguard Plugin requires the additional software 'fbidsmate', which is
available from the Watchguard website. Download is only permitted if you have
an active service contract. Perhaps you find similar files elsewhere on the
Internet. There are three different versions depending on the target OS.

ec56fa37eaba84d0a52dd111db76dcf9  fbidsmate.exe (for Windows NT/98/2000)
15245ba11f109d35fddf424aea42afe9  fbidsmate     (for Solaris)
74d0b4842b7149474f23c7ab83a2962c  fbidsmate     (for Linux)

To start support for Watchguard you have to add one line to the snortsam.conf
for each Watchguard you want to initiate the block on. Use the following
syntax:

   watchguard <path/to/fbidsmate> <ip-of-firebox> <configpassword>

Also you can store the configuration passphrase in encrypted form,
so you don't have to leave it in the clear in your snortsam.conf. Then you
can use the following syntax:

   watchguard <path/to/fbidsmate> <ip-of-firebox> file <configpassfile>

To create this configpassfile

   ./fbidsmate import_passphrase <config_passphrase> <filename>

This stores the passphrase in the indicated file with 3DES encryption.
Example:

   ./fbidsmate import_passphrase mySecretPass /etc/fbidsmate.passphrase

Here an example snortsam.conf with viewable password

# cat /etc/snortsam.conf
accept 10.10.0.26
defaultkey secret
watchguard /bin/fbidsmate 10.1.0.1 mySecretPass
logfile /var/log/snortsam.log
loglevel 3

Here the same example snortsam.conf with password encrypted in file

# cat /etc/snortsam.conf
accept 10.10.0.26
defaultkey secret
watchguard /bin/fbidsmate 10.1.0.1 file /etc/fbidsmate.passphrase
logfile /var/log/snortsam.log
loglevel 3

Thomas Maier
Thomas.Maier@arcos.de

-------------------------------------------------------------------------------
$Id: README.wgrd,v 2.1 2003/03/09 23:58:35 fknobbe Exp $