Linux Firewalls - Michael Rash [63]
TCP connect() Scan
The Nmap TCP connect() scanning mode (-sT) is introduced in Chapter 3, and can be used by non-privileged users on Unix-style operating systems. We illustrate this scan first against the target IP address 71.157.X.X:
[ext_scanner]$ nmap -sT -n 71.157.X.X --;max-rtt-timeout 500
Starting Nmap 4.01 ( http://www.insecure.org/nmap/ ) at 2007-07-08 23:22 EST
Interesting ports on 71.157.X.X:
(The ❶1671 ports scanned but not shown below are in state: ❷filtered)
PORT STATE SERVICE
❸ 80/tcp open http
Nmap finished: 1 IP address (1 host up) scanned in 22.551 seconds
A total of 1671 TCP ports were scanned (❶), and nearly all are being filtered (❷) as expected because iptables is dropping the majority of the connection attempts. Only the HTTP port is open (❸). Once the scan is finished, we examine the /var/log/messages file to see if psad has detected the scan. Indeed, the following syslog message appears there:
Jul 8 23:22:29 iptablesfw psad: scan detected: 144.202.X.X -> 71.157.X.X tcp:
[1-65301] flags: SYN tcp pkts: ❹1532 DL: 4
The psad syslog message shows the source and destination IP addresses, the range of TCP ports that were scanned (1-65301), the flags that were sent (SYN in this case), the total number of packets sent, and the danger level that psad has assigned to the scanner (DL: 4).
In this case, the number of packets monitored by psad is 1532 (see ❹ above) and this exceeds the 1,500 packets required to reach danger level 4 (as defined by the DANGER_LEVEL4 variable in /etc/psad/psad.conf). Email alerts are also generated by psad, and they contain a lot more information than can be packed into a single-line syslog message. (See "psad Email Alerts" on page 108 for a complete example of a psad email alert.)
To see the iptables log messages that psad used to detect the scan, examine the /var/log/psad/fwdata file. (Recall that psad is running, so kmsgsd is receiving iptables log messages via syslog and writing them to the /var/log/psad/fwdata file; more information about kmsgsd can be found in Chapter 5.)
Here are three log messages from the fwdata file:
Jul 8 23:22:04 iptablesfw kernel: DROP IN=eth0 ❶OUT= MAC=00:13:d3:38:b6
:e4:00:30:48:80:4e:37:08:00 ❷SRC=144.202.X.X DST=71.157.X.X LEN=60 TOS=0x00
PREC=0x00 TTL=64 ID=28124 DF ❸PROTO=TCP SPT=55103 DPT=53 WINDOW=5840 RES=0x00
SYN URGP=0 OPT (020405B40402080A31CAD9280000000001030306)
Jul 8 23:22:04 iptablesfw kernel: DROP IN=eth0 OUT= MAC=00:13:d3:38:b6:e4:00
:30:48:80:4e:37:08:00 SRC=144.202.X.X DST=71.157.X.X LEN=60 TOS=0x00
PREC=0x00 TTL=64 ID=53661 DF PROTO=TCP SPT=59480 DPT=256 WINDOW=5840 RES=0x00
SYN URGP=0 OPT (020405B40402080A31CAD9280000000001030306)
Jul 8 23:22:04 iptablesfw kernel: DROP IN=eth0 OUT= MAC=00:13:d3:38:b6:e4:00
:30:48:80:4e:37:08:00 SRC=144.202.X.X DST=71.157.X.X LEN=60 TOS=0x00
PREC=0x00 TTL=64 ID=36136 DF PROTO=TCP SPT=60134 DPT=3389 WINDOW=5840 RES=0x00
SYN URGP=0 OPT (020405B40402080A31CAD9280000000001030306)
Notice that several fields in the log messages appear in bold. The field at ❶ above, which shows that the output interface is blank, is the string OUT=. This tells us that either the packet that generated the log message hits a LOG rule from within the iptables INPUT chain, or it hits a LOG rule in a chain before the routing calculation is made within the kernel (e.g., the PREROUTING chain in the raw table).
Because the iptables logging format does not explicitly include the iptables chain that contains the LOG rule, we can't tell from the log message above whether the packet is logged from the INPUT chain or the PREROUTING chain. However, because it's likely that more iptables policies put default LOG rules within the INPUT,