So far we've seen that psad analyzes iptables log messages in order to detect port scans. In this chapter we will extend the theme of attack detection much further; certain attacks that match signatures in the Snort signature set can be detected, and remote operating systems can be fingerprinted in some cases. We will also show how to extract verbose status information from psad, and we'll introduce the DShield reporting capability.
Because the iptables logging format is so complete, psad can detect traffic that matches Snort rules that lack application layer match criteria. For example, consider the following Snort rule, which looks for TCP packets with a source port of 10101, an acknowledgment value of zero, the SYN flag set, and a TTL value in the IP header greater than 220.
alert tcp $EXTERNAL_NET10101-> $HOME_NET any (msg:"SCAN myscan"; flow:stateless;ack:0;flags:S;ttl:>220; reference:arachnids,439; classtype:attempted-recon; sid: 613; rev:6;)
There are no tests in this Snort rule that examine application layer data, and there are about 150 such rules in the Snort ruleset. Modified versions of all of these rules are imported by psad from the /etc/psad/signatures file.[44] If you look at a random signature in the /etc/psad/signatures file, such as the BAD-TRAFFIC data in TCP SYN packet signature (shown below), you can see that psad has extended the usual Snort rules syntax with some additional keywords shown at ❶, ❷, and ❸):
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"BAD-TRAFFIC data in TCP SYN packet; ❶psad_dsize:>20; flags:S; reference:url,www.cert.org/incident_notes/IN-99-07. html;classtype:misc-activity; sid:207; ❷psad_id:100000; ❸psad_dl:2;)
These keyword additions add specific information to the signature that makes the signature compatible with psad. Here are the definitions of all psad keyword additions to Snort rules:
psad_idThis keyword defines a unique ID number so that signatures can be tracked and new signatures can be added to psad. The
psad_idfield is analogous to the Snortsidfield. Allpsad_idvalues are six digits long, and they begin at 10,000 in order to distinguish them from Snortsidvalues. This method of defining custom ID values is similar to the Bleeding Snort project (http://www.bleedingsnort.com) where signature ID values are seven digits long and generally begin with the year the signature is created.psad_dlThis keyword specifies the danger level that psad should assign to an IP address that triggers the signature. The
psad_dlfield accepts a value between 1 and 5.psad_dsizeThis keyword specifies match criteria for the size of a packet payload by subtracting the header length from the value of the iptables
LENfield. This option is analogous to the Snortdsizekeyword, but because theLENfield of iptables log messages is the total length of the logged packet, including the IP header, psad must subtract out the header length. Thepsad_dsizekeyword supports range matches of the formn:m,<n, and>n. For example, to test whether the payload size is greater than 1,000 bytes, you could addpsad_dsize:>1000to a signature.psad_derived_sidsThis keyword allows psad to track original Snort
sidvalues from which a psad signature is derived. Some psad signatures are built up from several Snort rules, and this keyword tracks which ones.psad_ip_lenThis keyword specifies match criteria for the
LENfield of an iptables log message (this is similar to thepsad_dsizekeyword, but it does not subtract the length of the network and transport layer headers). Like thepsad_dsizekeyword, thepsad_ip_lenkeyword also supports range matches of the formn:m,<n, and>n. For example, to test whether theLENfield is greater than 100 bytes but less than 200 bytes, you could addpsad_ip_len: 100:200to a signature.
Next, we highlight a selection of specific Snort rules to show how psad can detect the traffic represented by these rules. Taking automated response measures against IP addresses that trigger Snort rules is covered in Chapter 11.
The ipEye port scanner (http://ntsecurity.nu/toolbox/ipeye) is a piece of software that allows the user to port scan a remote host. In this sense, ipEye is similar to Nmap (although not nearly as feature-rich), and it runs on Windows systems. Snort rule ID 622 detects when the ipEye scanner is being used on a network:
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"SCAN ipEye SYN scan"; flags:S;
seq:1958810375; reference:arachnids,236; classtype:attempted-recon; sid:622; psad_id:
100197; psad_dl:2;)
The above Snort rule does not require the use of any application layer tests; instead, it just detects whether the SYN flag and a specific TCP sequence number 1958810375 are set in the TCP header (these tests are shown in bold above).
To detect instances of the ipEye scanner with psad, the --log-tcp-sequence option must be given on the iptables command line to have iptables include TCP sequence numbers in log messages when a packet hits a LOG rule. Any iptables log message that contains the SYN flag and the sequence number 1958810375 (shown in bold below) will trigger the signature match in psad:
Jul 11 20:28:21 iptablesfw kernel: DROP IN=eth1 OUT= MAC=00:13:46:3a:41:4b:00:a0:cc: 28:42:5a:08:00 SRC=192.168.10.3 DST=192.168.10.1 LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID= 3970 DF PROTO=TCP SPT=45664 DPT=15324SEQ=1958810375ACK=0 WINDOW=5840 RES=0x00SYNURGP=0
With psad running, the following syslog message with the words signature match appears in /var/log/messages indicating that psad has detected the ipEye scanner:
Jul 11 20:28:25 iptablesfw psad: src: 192.168.10.3 signature match: "SCAN ipEye SYN scan" (sid: 622) tcp port: 15324
The LAND attack is an old classic. It is a Denial of Service attack targeted against Windows systems, and it involves crafting a TCP SYN packet that has the same source IP address as its own destination IP address. In the Snort signature set, the key to detecting the LAND attack is the sameip packet header test. A modified version of Snort rule ID 527 (originally in the Snort bad-traffic.rules file) allows psad to detect this attack in iptables logs (see the sameip test shown in bold):
alert ip any any -> any any (msg:"BAD-TRAFFIC same SRC/DST"; sameip; reference:
bugtraq,2666; reference:cve,1999-0016; reference:url,www.cert.org/advisories/CA-1997-
28.
html; classtype:bad-unknown; sid:527; psad_id:100103; psad_dl:2;)
psad incorporates the sameip test by checking to see if the SRC and DST fields in iptables logs are identical. However, in order to reduce false positives, traffic that is logged over the loopback interface is excluded from this check.
Because the SRC and DST fields are always included within iptables log messages, no special command-line arguments to iptables are required when building the LOG rule in order for psad to detect traffic associated with the LAND attack. The following lines represent an iptables log message generated by the LAND attack (note the source and destination IP addresses are the same) followed by a corresponding psad syslog alert:
Jul 11 20:31:35 iptablesfw kernel: DROP IN=eth0 OUT= MAC=00:13:d3:38:b6:e4:00:13:46:
c2:60:44:08:00 SRC=192.168.10.3 DST=192.168.10.3 LEN=60 TOS=0x10 PREC=0x00 TTL=63
ID=46699 DF PROTO=TCP SPT=57278 DPT=15001 WINDOW=5840 RES=0x00 SYN URGP=0 Jul 11 20:
31:38
iptables psad: src: 192.168.10.3 signature match: "BAD-TRAFFIC same SRC/DST" (sid:
527)ip
Although legitimate TCP connections do not travel over port 0, nothing prevents someone from putting a TCP packet on the wire that is destined for port 0. Indeed, Nmap gained the ability to scan port 0 in the 3.50 release.
The original Snort rule ID 524 (notice the port value shown in bold) detects TCP packets that are sent to destination port 0, and there is a similar rule for UDP port 0:
alert tcp $EXTERNAL_NET any <> $HOME_NET 0 (msg:"BAD-TRAFFIC tcp port 0 traffic";
classtype:misc-activity; sid:524; psad_id:100101; psad_dl:2;)
An iptables log message that contains the value 0 in the DPT field will trigger this signature in psad, containing DPT=0, as shown in bold:
Jul 11 21:02:07 iptablesfw kernel: DROP IN=eth1 OUT= MAC=00:13:d3:38:b6:e4:00:13:46:
c2:
60:44:08:00 SRC=192.168.10.3 DST=192.168.10.1 LEN=44 TOS=0x00 PREC=0x00 TTL=41 ID=
43697 PROTO=TCP SPT=29121 DPT=0 WINDOW=3072 RES=0x00 SYN URGP=0 Jul 11 21:02:11
iptablesfw psad: src: 192.168.10.3 signature match: "BAD-TRAFFIC tcp port 0 traffic"
(sid: 524)tcp port: 0
As with TCP and UDP port 0, it is possible to put a packet on the wire with a zero TTL value. Although such a packet should never be forwarded by a device that routes IP packets, a system can send such packets against any other system that is connected by means of a layer two device (such as a switch or bridge).
Snort rule ID 1321 detects IP packets that have the TTL value set to zero (shown in bold), and a corresponding iptables message appears below, as shown here:
alert ip $EXTERNAL_NET any -> $HOME_NET any (msg:"BAD-TRAFFIC 0 ttl"; ttl:0;
reference:url,support.microsoft.com/default.aspx?scid=kb;EN-US;q138268; reference:
url, www.isi.edu/in-notes/rfc1122.txt; classtype:misc-activity; sid:1321; psad_id:
100104;psad_dl:2;)
An iptables log message that contains the value 0 in the TTL field will trigger this signature in psad, containing TTL=0, as shown in bold:
Jul 14 15:33:28 iptables kernel: IN=eth1 OUT= MAC=00:13:46:3a:41:4b:00:13:46:c2:60:44:
08:00 SRC=192.168.10.3 DST=192.168.10.1 LEN=104 TOS=0x00 PREC=0x00 TTL=0 ID=0 DF
PROTO=ICMP TYPE=8 CODE=0 ID=1830 SEQ=15412 Jul 14 15:33:31 iptablesfw psad: src:
192.168.10.3 signature match: "BAD-TRAFFIC 0 ttl" (sid: 1321) ip
The Naptha Denial of Service tool is designed to flood a targeted TCP stack with so many SYN packets that the system cannot service legitimate requests. According to Snort rule ID 275, the Naptha tool creates packets that contain an IP ID value of 413, and a TCP sequence number of 6060842, as shown in bold here:
alert tcp $EXTERNAL_NET any <> $HOME_NET any (msg:"DOS NAPTHA"; flags:S; id:413; seq:
6060842; reference:bugtraq,2022; reference:cve,2000-1039; reference:url,razor.
bindview.com/publish/advisories/adv_NAPTHA.html; reference:url,www.cert.org/advisories
/
CA-2000-21.html; reference:url,www.microsoft.com/technet/security/bulletin/MS00-091.ms
px;
classtype:attempted-dos; sid:275; psad_id:100111; psad_dl:2;)
The following iptables log message triggers the Naptha rule in psad (notice the IP ID value of 413 at ❶, the TCP sequence number 6060842 at ❷, and the SYN flag set at ❸):
Jul 11 20:28:21 iptablesfw kernel: DROP IN=eth1 OUT= MAC=00:13:46:3a:41:4b:00:a0:cc:28 :42:5a:08:00 SRC=192.168.10.3 DST=192.168.10.1 LEN=60 TOS=0x10 PREC=0x00 TTL=64 ❶ID= 413DF PROTO=TCP SPT=45664 DPT=15304 ❷SEQ=6060842ACK=0 WINDOW=5840 RES=0x00 ❸SYNURGP=0Jul 14 15:35:26 iptablesfw psad: src: 192.168.10.3 signature match: "DOS NAPTHA" (sid: 275) tcp port: 15304
Source routing is a technique supported by the IPv4 protocol by which an adversary can attempt to route packets through networks that would otherwise be inaccessible. Source routing options are included within the options portion of the IP header, and Snort rule ID 500 detects loose source routing attempts with the ipopts IP header test (shown in bold):
alert ip $EXTERNAL_NET any -> $HOME_NET any (msg:"MISC source route lssr"; ipopts:
lsrr; reference:arachnids,418; reference:bugtraq,646; reference:cve,1999-0909;
classtype:bad-unknown; sid:500; psad_id:100199; psad_dl:2;);
Because it is only possible to issue loose source routing directives when using IP options, psad can only detect this type of traffic if the LOG rule is built within the --log-ip-options command-line argument to iptables. When iptables logs an IP packet that contains IP options, the log message includes the options as an argument to the OPT string like OPT (830708C0A80A0300). According to RFC 791, the loose source routing option is defined as option number 131 (hex 83) and has a variable length. The following iptables log message contains an OPT string generated by an IP packet that contains the loose source routing option (shown in bold):
Jul 13 19:39:53 iptablesfw kernel: IN=eth1 OUT= SRC=192.168.10.3 DST=192.168.10.1 LEN=
48 TOS=0x00 PREC=0x00 TTL=64 ID=10096 OPT (830708C0A80A0300) PROTO=TCP SPT=3017 DPT=
0 WINDOW=512 RES=0x00 URGP=0
psad notices the source routing attempt:
Jul 13 19:39:56 iptablesfw psad: src: 192.168.10.3 signature match: "MISC source
route lssr" (sid: 500) ip
Spam is a pervasive problem on the Internet, and we are all feeling the effects of this scourge. One common way that spammers try to have their spam viewed by more people is by sending it directly through the Windows Messenger service. Although it is pretty useless to detect this traffic when it's coming from external networks (because each spam message can be spoofed and only a single UDP packet is required to transmit it unless the message is large), it can be important to detect it when it's coming from your internal network. Any system that is generating such traffic on your intranet may have been compromised and used to send spam by someone controlling the system from afar.
Because psad treats packets that are logged in the INPUT chain as having been directed at the home network (regardless of whether they come from internal addresses), the following signature detects Windows pop-up spam attempts when they are directed at the firewall (note at ❶ the UDP with a destination port range from 1026 to 1029 at ❷ and an application layer data size greater than 100 bytes with the psad_dsize test at ❸).
alert ❶udp$EXTERNAL_NET any -> $HOME_NET ❷1026:1029(msg:"MISC Windows popup spam attempt"; classtype:misc-activity; reference:url,www.linklogger.com/UDP1026.htm; ❸psad_dsize:>100; psad_id:100196; psad_dl:2;)
The log message shows how iptables sees a pop-up spam message attempt (note that the destination port is 1026 and the size of the UDP packet, including the 8-byte UDP header, is 516 bytes):
Jul 14 15:03:24 iptablesfw kernel: DROP IN=eth0 OUT= MAC=00:13:d3:38:b6:e4:00:90:1a: a0:1c:ec:08:00 SRC=65.182.197.125 DST=71.157.X.XLEN=536 TOS=0x00 PREC=0x00 TTL= 117 ID=6090 PROTO=UDP SPT=3515DPT=1026 LEN=516
psad notices the traffic and generates a syslog alert:
Jul 14 15:03:29 iptablesfw psad: src: 65.182.197.125 signature match: "MISC Windows
popup spam attempt" (sid: 100196) udp port: 1026
Note
Although the previous examples have highlighted psad's Snort rule detection capability with an emphasis on rules that test packet headers, running fwsnort provides a huge improvement: The detection capabilities of psad are extended to include application layer data, as you'll see in detail in Chapter 11.
[44] 1 The ability to test the application layer is, of course, very important when attempting to detect the majority of today's attacks, and psad offers this capability when combined with fwsnort (which uses the Netfilter string match extension). For more detail, see Chapter 11.