Linux Firewalls - Michael Rash [119]
$IPTABLES -A FWSNORT_FORWARD_ESTAB -p tcp --dport 80 -m string --string
"/Setup.php" --algo bm -m comment --comment "sid:2281; msg: WEB-PHP Setup.php
access; classtype: web-application-activity; reference: bugtraq,9057; rev: 2;
FWS:1.0;" -j LOG --log-ip-options --log-tcp-options --log-prefix "[1] SID2281
ESTAB "
The text in bold is the iptables log prefix. This string is included within iptables log messages triggered when iptables detects the string /Setup.php over a web session. For example, if we execute the same lynx http://71.157.X.X/Setup.php command from the ext_scanner system against the webserver, we get this iptables log message:
Jul 19 23:49:18 iptablesfw kernel: [1] SID2281 ESTAB IN=eth0 OUT=eth1
SRC=144.202.X.X
DST=192.168.10.3 LEN=276 TOS=0x00 PREC=0x00 TTL=63 ID=8317
DF PROTO=TCP SPT=47299 DPT=80 WINDOW=92 RES=0x00 ACK PSH URGP=0 OPT
(0101080A0CA8DB00E9FBEB4A)
Alerting with psad
The attack has been detected by fwsnort, but it has only generated a log message from iptables; it has not performed any whois lookups or sent email alerts, because these are beyond the scope of its functionality.
However, because fwsnort generates an iptables log message, psad can analyze it and apply its alerting and reporting machinery to the event. But first, psad needs to properly handle fwsnort log messages. After all, these messages are generated via the inspection of application layer data, but the data itself is not included in the log messages.
The key to interpreting the log messages is the SNORT_SID_STR variable in the /etc/psad/psad.conf file. This variable describes the portion of the log prefix that psad must see in order to infer that the log message is generated by fwsnort. By default, SNORT_SID_STR is set as follows:
SNORT_SID_STR SID;
Any iptables log message that contains a logging prefix with the SID substring is a message generated by fwsnort, and these are nearly always for application layer attacks.
We now make sure psad is running (execute /etc/init.d/psad start) and then simulate the attack again. This time, psad captures the iptables log message, parses it, and generates the email alert shown below. (We've removed whois information that normally accompanies a psad alert, for brevity.)
Danger level: [3] (out of 5)
Scanned TCP ports: [80: 1 packets]
❶ TCP flags: [ACK PSH: 1 packets]
iptables chain: FWSNORT_FORWARD_ESTAB (prefix ❷"[1] SID2281 ESTAB"), 1 packets
fwsnort rule: 1
Source: 144.202.X.X
DNS: [No reverse dns info available]
OS guess: Linux:2.6:17:Linux 2.6.17 and newer (?)
Destination: 192.168.10.3
DNS: web_server
Overall scan start: Thu Jul 19 23:48:18 2007
Total email alerts: 2
Complete TCP range: [80]
Syslog hostname: iptablesfw
Global stats: chain: interface: TCP: UDP: ICMP:
FORWARD eth0 2 0 0
❸ [+] TCP scan signatures:
"WEB-PHP Setup.php access"
dst port: 80
flags: ACK PSH
content: "/Setup.php"
❹ sid: 2281
chain: FWSNORT_FORWARD_ESTAB
packets: 1
classtype: web-application-activity
reference: (bugtraq) http://www.securityfocus.com/bid/9057
The psad email alert shown above appears fairly normal and includes all of the standard information, such as timestamps, packet counts, TCP flags and ports, and so on. However, several pieces of information in this alert deserve special attention.
TCP Flags
All TCP flags that are present in TCP packets that generate iptables log messages are reported by psad. In the case of the WEB-PHP Setup.php access attack, the particular TCP packet that triggers the fwsnort policy to trigger a log message is part of an established TCP session, and so the ACK and PSH flags are reported as being set at ❶. The prefix [1] SID2281 ESTAB (❷) also clearly indicates that the packet is logged by an fwsnort chain that is making use of state matching to track established TCP connections, so the attacker cannot force fwsnort to generate the log message just by spoofing a TCP ACK packet that contains the /Setup.php string