Linux Firewalls - Michael Rash [85]
psad detects the SYN scan and generates the following two syslog messages, which indicate that the 144.202.X.X IP address has been blocked for 3,600 seconds and that 237 TCP packets in the range of ports from 2 to 32787 were monitored in this particular checking interval:
Mar 5 15:33:46 iptablesfw psad: added iptables auto-block against 144.202.X.X for
3600 seconds
Mar 5 15:33:52 iptablesfw psad: scan detected: 144.202.X.X -> 71.157.X.Xtcp=
[2-32787] SYN tcp=237 udp=0 icmp=0 dangerlevel: 3
psad has indeed blocked the attacker by adding blocking rules into the custom psad chains (defined by the IPT_AUTO_CHAIN{n} variables as discussed earlier), and instead of rummaging through the output of iptables-v -n -L, psad makes it easy for you to see the new blocking rules in the psad chains:
[iptablesfw]# psad --fw-list
[+] Listing chains from IPT_AUTO_CHAIN keywords...
Chain PSAD_BLOCK_INPUT (1 references)
pkts bytes target prot opt in out source destination
1599 70356 DROP all -- * * 144.202.X.X 0.0.0.0/0
Chain PSAD_BLOCK_OUTPUT (1 references)
pkts bytes target prot opt in out source destination
0 0 DROP all -- * * 0.0.0.0/0 144.202.X.X
Chain PSAD_BLOCK_FORWARD (1 references)
pkts bytes target prot opt in out source destination
0 0 DROP all -- * * 0.0.0.0/0 144.202.X.X
0 0 DROP all -- * * 144.202.X.X 0.0.0.0/0
From a status perspective, it is also possible to see how many seconds the blocking rules against an IP address will remain in effect by using the psad --Status command. The complete output of this command is not displayed here, but toward the end of the output, the following two lines are displayed. These lines show that, in this case, the IP 144.202.X.X has a total of 3,445 seconds left to be blocked:
Iptables auto-blocked IPs:
144.202.X.X (3445 seconds remaining)
Lastly, to confirm that the target has now become inaccessible from the attacker's perspective, we can try our scan again. This time, not even port 80 can be reached:
[ext_scanner]# nmap -sS -P0 -n 71.157.X.X
Starting Nmap 4.01 ( http://www.insecure.org/nmap/ ) at 2007-03-05 15:47 EST
All 1672 scanned ports on 71.157.X.X are: filtered
Nmap finished: 1 IP address (1 host up) scanned in 35.906 seconds
UDP Scan Response
After waiting for over an hour, we see via syslog that psad has removed the blocking rules against the 144.202.X.X address:
Mar 5 16:33:56 iptablesfw psad: removed iptables auto-block against 144.202.X.X
Now we'll attempt a UDP scan against the iptables target. Because psad tracks the fact that the attacker's source address (144.202.X.X) has already achieved a danger level of 3, it will renew the blocking rules as soon as the first UDP packet is logged. If the attacker just plays nicely with the firewall and doesn't initiate any network traffic that would cause iptables to generate a log message, then the attacker will regain connectivity to the web- and DNS servers after a period of one hour. In the Nmap output below, the ports are marked as open|filtered. This is because Nmap cannot assume that the remote UDP sockets necessarily respond with any data, and since iptables is preventing any ICMP port unreachable messages from being generated (the UDP stack never even sees the packets because iptables has intercepted them at a lower level within the kernel), it can't deduce that the ports are closed.
[ext_scanner]# nmap -sU -P0 -n 71.157.X.X
Starting Nmap 4.01 ( http://www.insecure.org/nmap/ ) at 2007-03-05 18:55 EST
All 1482 scanned ports on 71.157.X.X are: open|filtered
Nmap finished: 1 IP address (1 host up) scanned in 32.023 seconds
Again, the iptables blocking rules are added against the 144.202.X.X IP address, but this time, 66 UDP packets are monitored in this scan interval by psad before the rules are added. (Remember that by default, psad checks for new iptables log messages every five seconds.)
Mar 5 18:55:55 iptablesfw psad: added iptables auto-block against 144.202.X.X for
3600 seconds
Mar 5 18:56:00 iptablesfw psad: scan