Linux Firewalls - Michael Rash [86]
tcp=0 udp=66 icmp=0 dangerlevel: 4
Nmap Version Scan
After waiting for an additional hour, the attacker is back once again with an Nmap version scan against TCP port 80. The attacker remembers from the SYN scan that there is a server listening on this port, and would therefore like to know more information about this server.
[ext_scanner]# nmap -sV -P0 -p 80 -n 71.157.X.X
Starting Nmap 4.01 ( http://www.insecure.org/nmap/ ) at 2007-03-05 20:40 EST
Interesting ports on 71.157.X.X:
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd
Nmap finished: 1 IP address (1 host up) scanned in 6.957 seconds
The Apache webserver is bound to TCP port 80. The mere act of establishing a TCP connection with the target over port 80 in and of itself does not indicate any suspicious activity. From the transport layer and below, the connection appears benign, and iptables does not log anything. However, blind FIN packets, as we will see in the next example, are a different story.
FIN Scan Response
The attacker, now confident that the target is running an accessible TCP server, may still wish to test how rigorous the active response software is in terms of TCP. For example, the software may not possess a method for tracking the state of TCP connections, and so it may let a blind FIN packet through to the server. This is not the case for iptables; the rules that log and drop packets that match the INVALID state at the beginning of the FORWARD chain (see "Default iptables Policy" on page 20) do not allow the blind FIN packet through to the internal webserver:
[ext_scanner]# nmap -sF -P0 -p 80 -n 71.157.X.X
Starting Nmap 4.01 ( http://www.insecure.org/nmap/ ) at 2007-03-05 20:50 EST
Interesting ports on 71.157.X.X:
PORT STATE SERVICE
80/tcp open|filtered http
Nmap finished: 1 IP address (1 host up) scanned in 0.812 seconds
In this case, Nmap receives zero packets from the targeted TCP stack, and it has to accept this as evidence that the port is either open (an open port does not respond with any packet upon receiving an orphaned FIN packet, as discussed in Chapter 3) or filtered (because a firewall or similar mechanism prevented the stack from responding). iptables does indeed filter this blind FIN packet and, in the process, psad adds the blocking rules against the attacker.
Maliciously Spoofing a Scan
At this point, the attacker is well aware of the fact that an active response mechanism is being used to protect the target network. In addition, there is no edict placed on the attacker not to abuse IP in an effort to make it appear as though a scan originates from, say, an IP address associated with Yahoo!'s network. As long as the local network and/or the local ISP has not deployed an anti-spoofing measure (such as egress filtering against nonlocal IP addresses on appropriately positioned border routers and/or firewalls), then it is exceedingly easy for the attacker to pound arbitrary bits into the source address field in the IP header:
[ext_scanner]# nmap -sS -P0 -S 68.142.X.X -e eth0 -n 71.157.X.X
Starting Nmap 4.01 ( http://www.insecure.org/nmap/ ) at 2007-03-05 21:34 EST
All 1672 scanned ports on 71.157.X.X are: filtered
Nmap finished: 1 IP address (1 host up) scanned in 32.023 seconds
The Nmap process running on the scanning system never sees any packets (either SYN/ACK packets for open ports or RST/ACK packets for closed ports) return from the target for two reasons: first, iptables is intercepting most of them, and second, any packets that are generated by the target are sent to the (spoofed) 68.142.X.X address instead of back to the scanner. Although this results in Nmap listing all of the ports as being filtered, the attacker does not have to care about this; the goal is just to trigger the blocking response on the target. psad sees the scan coming from 68.142.X.X, and blocks it accordingly once the scan reaches DANGER_LEVEL3:
Mar 5 21:34:46 iptablesfw psad: added iptables auto-block against 68.142.X.X for
3600 seconds
Mar 5 21:34:52 iptablesfw