Linux Firewalls - Michael Rash [64]
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).
TCP SYN or Half-Open Scan
Now we turn to Nmap's SYN (or half-open) scan method. The SYN scan is Nmap's default scan type when executed by a privileged user. (Indeed, this and all other interesting Nmap scan types require access to raw sockets and so must be executed by a privileged user.)
Because the iptables firewall on the target system has been configured to drop all SYN packets not destined for TCP port 80, the SYN scan looks nearly identical to a regular TCP connect() scan when viewed on the wire, because there are very few SYN/ACK packets for the scanners' TCP stack to respond to. We see SYN packets from the same source address and nothing else.
This reasoning is generally sound in theory, but in practice we see several significant differences between the SYN and connect() scans even when the initial SYN packets are dropped by iptables in both cases. These differences show up in the specific packet header fields for the SYN packets that are sent by Nmap in the SYN scan mode versus those that are sent by the TCP stack itself via the Nmap connect() scan. As discussed in Chapter 3, many more TCP options are sent by the connect() scan than by the SYN scan, but there are other differences as well. The remainder of this section illustrates the specific differences between the SYN packets in each scan, and how you can see these differences in the iptables log messages on the iptablesfw system.
The command below starts a SYN scan against the target IP address 71.157.X.X:
[ext_scanner]# nmap -n 71.157.X.X --max-rtt-timeout 500
Starting Nmap 4.03 ( http://www.insecure.org/nmap/ ) at 2007-07-13 13:58 EDT
Interesting ports on 71.157.X.X:
(The 1672 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.611 seconds
A quick examination