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: 01532 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 0 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:l3: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:l3: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:l3: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, FORWARD, or OUTPUT chains than in the PREROUTING or POSTROUTING chains, psad assumes that the following rules apply to all iptables log messages:
• Messages that don't contain an output interface are logged within the INPUT chain.
• Messages that don't contain an input interface are logged within the OUTPUT chain.
Messages that contain both an input and output interface are logged within the FORWARD chain.
Hence, for the TCP connect() scan discussed above, psad assumes that the scan is logged via the INPUT chain, which is correct given the iptables policy built by the iptables.sh script. Because the source IP address 144.202. X.X is included within the log messages at ©, psad knows where the scan originated.
NOTE Remember that scans are sometimes deliberately spoofed, so this IP address cannot be completely trusted as the real source of the scan. When executed as root, Nmap can send spoofed scans with the decoy option (-D), and the Idle scan uses IP spoofing as an integral component.
The next three bold strings in the iptables log message at above indicate the protocol and port scanned, as well as the flags used. In this example, the scanner is interested in TCP ports, and the scan packets have only the SYN flag set.
Recall that a total of 1,671 ports were scanned by Nmap in the connect() scan above, but only 1,532 iptables log messages were written to the /var/ log/psad/fwdata file. The difference stems from two factors: the ability of iptables to quickly generate log messages, and SYN packet retransmissions from Nmap. Because iptables logs internally to a ring buffer within the kernel, if the traffic rate is fast enough to overwrite the ring buffer with new messages before the old ones can be written to the /var/lib/psad/psadfifo named pipe, then those messages are simply lost. The trade-off is that your machine stays up and continues to perform at a decent level at the expense of losing a few logging messages (which seems like a good trade-off). Because Nmap typically sends one retry per nonresponding port, Nmap really sent over 3,300 packets for this particular scan (the kernel ring buffer was not able to keep up with this packet rate, so about half of the packets were not logged).
Was this article helpful?