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.
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 detected: 144.202.X.X -> 71.157.X.X tcp=0 udp=66 icmp=0 dangerlevel: 4
Was this article helpful?