Article feb2006.tar

Open Source Network Security Active Response: A Survey

Travis Howard

This article discusses various open source network security tools that perform "active response". A network security event is the occurrence of one or more packets that could be used to perform reconnaissance or could constitute an attack. A network security system conducts an "active response" if it responds to a network security event with an action to mitigate the effectiveness of that event. Such actions can include the dynamic modification of a firewall ruleset to block all traffic from the IP associated with the event, sending TCP Reset or ICMP Port Unreachable packets to tear down any TCP sessions or UDP traffic respectively, or even administratively disabling a switch port to which the attacker is connected (for locally generated attacks).

An intrusion prevention system (IPS) is an active response system that is capable of taking an action that affects the normal processing of the first packet it recognizes as a network event (typically an attack of some kind). The usual decision is to block that "stream", or the source IP of the packet. To do this, the IPS must usually be "in-line"; that is, the packets must traverse the IPS as part of their routing to get to the target system. By contrast, an active response comes at some time after the first packet, and so they cannot stop single-packet attacks.

PortSentry

The first open source program I know of that took an active response was Craig Rowland's PortSentry. It can take a number of steps when it detects a port scan, including logging, adding the remote host to /etc/hosts.deny (for Wietse Venema's TCP Wrappers), creating a bogus route to the remote host (which effectively drops all traffic to it), and making a change to the local firewall rules (ipfw and iptables) to block further packets from this host. An attacker could easily spoof a scan, or perform an "idle scan" from a host you really want to talk to (such as an upstream router, closest DNS server, or a root DNS server), causing a denial of service. However, Craig says a DoS attack of this nature has never been reported "in the wild". (For a full review of the denial-of-service vulnerability, see Chapter 3 in Intrusion Prevention and Active Response by Michael Rash et al., and PortSentry's README.stealth file.)

In Common Intrusion Detection Framework (CIDF) terminology, PortSentry is an "A+E+R box", which means it analyzes events (A), generates event outputs (E), and responds to events (R). It does not appear that PortSentry is under active development, and email to the author bounces.

PortSentry works on the following operating systems:

  • Linux 1.x/2.x
  • BSDI 2.x/3.x
  • OpenBSD 2.x
  • FreeBSD 3.x
  • HPUX 10.20
  • Solaris 2.6+
  • AIX SCO
  • Digital Unix
  • NetBSD OSX

and the following interfaces:

Regular sockets
SOCK_RAW
Maybe netlink in the near future?

with reaction types:

Routing table
Ipfwadm ipchains iptables (Linux)
Ipfw (FreeBSD)
Ipf (old OpenBSD, NetBSD)
Tcpwrappers
Ar bitrary command (parameters available: source host, destination port)

Additionally, PortSentry supports whitelists (on more than one kind of configuration value) and a simple connection attempt threshold.

In the basic modes, packets must actually connect to an open port (which may be PortSentry) for them to be detected. In advanced modes, it opens a raw socket, but unfortunately it is not done at a low enough level that it can see packets blocked by a kernel-level packet filter. There is no native facility for adjusting firewall rules on a remote host, although it could be implemented as a user-defined command.

Port Scan Attack Detector

The Port Scan Attack Detector (psad) parses iptables firewall logs and generates events. However, due to the amount of information that iptables can be configured to log, it is possible to do a great deal of analysis, including OS detection (based on two different techniques: TCP options like p0f, and TOS-based), and detection of various kinds of stealth scans (indeed, nearly all forms of scans), and many of the rules from Snort. It is composed of three daemons, each of which is written in both C and Perl. The author of psad wrote it due to deficiencies in PortSentry.

At startup, psad creates a named pipe to which syslog can send kern.info messages. The kmsgd parses the named pipe information for dropped/rejected packets from iptables and writes them to a separate log file. The PSAD program then reads them and analyzes them, reacts (sending emails and optionally blocking the offender). The third process, psadwatchd, merely makes sure that the others are running every five seconds.

Additionally, psad can be run in forensics mode, where you can analyze scans from old log files. It can also send email alerts containing a great deal of forensic information. It has configurable scan thresholds, can send dshield reports, and can auto-block scanning IPs (should you desire to do so). It can also verify that your iptables rules have a default-deny stance. Overall, this is a fairly impressive program!

psad works on Linux only, as it is iptables-specific.

fwsnort

The fwsnort program is related to psad and parses Snort rules and creates an iptables ruleset that blocks the corresponding attacks. It uses the iptables string match and a new --hex-string option to match application-layer strings associated with the signatures. You can extract only certain classes of Snort rules (such as ddos) or you can pick rules by its sid (snort ID).

SnortSam

SnortSam is a Snort plug-in that lets snort rules trigger blocks on a large variety of firewalls. If you just use snort, just want to block malicious hosts as an active response, and use firewalls other than iptables and pf, then this might be for you. The amount of time a host is blocked can be specified on a per-rule basis. Aside from whitelists (hosts which will never be blocked, such as the root DNS servers), SnortSam also has a neat feature that detects a rapid series of blocks and undoes them and waits for a bit, reducing the ability of an attacker to conduct a DoS against you. It can block in the inbound, outbound, or both directions. The communication between Snort and Snortsam is encrypted to prevent unauthorized block requests. Snortsam also has the ability to forward block requests to other snortsam agents, creating a distributed blocking infrastructure.

SnortSam works with the following firewalls:

  • Checkpoint Firewall-1
  • Cisco PIX firewalls
  • Cisco Routers (using ACLs or Null-Routes)
  • Former Netscreen, now Juniper firewalls
  • IP Filter (ipf), available for various Unix-like operating systems, such as FreeBSD
  • FreeBSD's ipfw2 (in 5.x)
  • OpenBSD's Packet Filter (pf)
  • Linux IPchains
  • Linux IPtables
  • Linux EBtables
  • WatchGuard Firebox firewalls
  • 8signs firewalls for Windows
  • MS ISA Server firewall/proxy for Windows
  • CHX packet filter
  • Ali Basel's Tracker SNMP through the SNMP-Interface-down plugin

Snort

Snort absorbed the snort_inline patches, which allow it to operate in-line (as an intrusion prevention system) via an interface to iptables, known as libipq. This gives Snort the ability to drop or reject the packet. Additionally, a new "replace" option allows you to rewrite a string in the application-layer datastream with another string of equal length. The details of how rejects are handled is somewhat complex, and depends on whether Snort is configured as a bridge (layer 2) or as a normal layer 3 device. There are a number of related tools that may interest a user of snort_inline. One such tool is called SnortConfig. SnortConfig is a Perl script that takes Snort rules and converts them to use the new drop, sdrop, and reject targets. It appears snort_inline only works with Linux/iptables.

DShield

The DShield project allows people to share their firewall log information, giving us an idea of what attackers are doing. There are several clients for various firewalls and operating systems. The reports on the Web site summarize the top 10 attacking IPs, the top 10 destination ports, etc. You could potentially use this to automatically create firewall rules that block the most commonly attacked ports until you have a chance to patch any vulnerable systems.

DFD

The Dynamic Firewall Daemon (DFD) is a system for manipulating your firewall rules in a controlled manner. There are multiple implementations. The dfd_keeper project is the Python/pf implementation, which I will discuss here. The Python/iptables implementation, known as dfd_tbk (The Black Knight) is similar, but has fallen behind (any volunteers to maintain it should email me; I'm sure both implementations would benefit from the cross-pollination).

As it stands, dfd_keeper is a pair of Python modules. End-users write a short Python script that defines which pf rules they want to have and a class that implements a number of commands. When they run their Python script, it listens on a configurable port for TCP connections. A human may connect using netcat or telnet (it understands both end-of-line conventions), and is presented with a command-line prompt, not unlike the Unix shell. The user may then execute the commands defined in the aforementioned script. The commands may take arguments, which are separated from the command by a single space.

Because of the simple communication, it is very easy to set up a program to issue commands that affect the firewall. If a program can execute arbitrary commands, it is trivial to use echo and netcat to issue a command on the firewall. By default, there are some predefined classes to assist you, which can turn certain rules on or off, can add or remove hosts from lists that are used in rules, and so forth.

By default, the daemon provides human-friendly prompts, strings, and error messages, but you may customize them or get rid of them entirely. Additionally, by default it defines some common commands, such as quit, exit, stop, and help. There are a number of clever things in DFD, such as the use of introspection to find the valid commands, the use of dynamic typing and exceptions to error-check arguments to commands, the use of the twisted asynchronous I/O framework to serve multiple clients from one thread (and thus avoid locking issues), and so forth. There are a number of directions in which this can go, but I will save these for other articles.

If you know of any similar products to those discussed here, please email me (solinym@gmail.com). I'm always looking for new ideas.

Resources

DShield -- http://www.dshield.org/

Dynamic Firewall Daemon -- http://www.lightconsulting.com/~travis/dfd/

Fwsnort -- http://www.cipherdyne.org/fwsnort/

Rash, Michael, A.D. Orebaugh, G. Clark, and B. Pinhard. 2005. Intrusion Prevention and Active Response. Syngress. -- http://www.syngress.com/catalog/?pid=3240

Port Scan Attack Detection -- http://www.cipherdyne.com/psad/

PortSentry -- http://sourceforge.net/projects/sentrytools/

Snort -- http://www.snort.org/

snort_inline patches -- http://snort-inline.sourceforge.net/

SnortSam -- http://www.snortsam.net/

TCP Wrappers -- http://www.porcupine.org/

Travis is obsessed with computer security and works in the network security industry. He has written the networking and cryptographic subsystems for a distributed host-based IDS, has held an ecletic mix of past computer-related jobs, and is always looking for an excuse to learn something new.