LFD firewall (linux LAMP server) allows IP thru after blocking

[wsherwood]

LFD firewall still allowing IP addresses thru that were already blocked

I've noticed several separate instances recently, two typical ones are described here.


1. i had manually added an IP address due to web form spam. Then we got several MORE from the same IP address that had been manually blocked. The web form uses the env var REMOTE_ADDR for capturing the IP address. I used a mask range
200.143.0.0/16
which format seems to have worked in the past.
(No examples shown below)
The evidence of access subsequent to the posting of the block was that web forms came thru, with the REMOTE_ADDR env var showing the IP within the blocked range.


2. Separately, blocked and then continued to get thru: In looking over server logs, i see that the firewall detector did its job in blocking the example below 81.208.30.34
However in the subsequent hours and days, there were hundreds MORE blocks issued (groups of five failures from dictionary attack).
(see the WHM> Deny list entry below, followed by two random excerpts from the log emails i receive). I thought once an IP was blocked, that was the end of it, that the firewall prevented from even getting that far again to be blocked again.

QUESTIONS:
A. Are IP env vars spoofable? (and thus it's blocking the wrong address)

B -- or-- the real question: how could subsequent accesses make it thru (and in the latter case, be blocked again)

C an aside question. My "landlord" says that using the CIDR mask syntax for the block deny list takes up an inordinate amount of CPU time to spin thru each of 2**16 IP addresses. I thought that a simple boolean bitwise logic equation was used to literally mask the needed part of the IP addr and just do a simple = compare for that part.
What's your take on using CIDR masks in the deny list?

THANKS!

(logs/summary attached below)



LOG

___________________________________
Deny list entry:
81.208.30.34 # lfd: 5 (pop3d) login failures from 81.208.30.34 (IT/Italy/81-208-30-34.ip.fastwebnet.it) in the last 300 secs - Fri May 14 11:51:09 2010

____________________________________
two examples of emailed logs from LFD (SUBSEQUENT to the block list entry)
(it appears to be a dictionary attack)


Time: Fri May 14 11:54:20 2010 -0400
IP: 81.208.30.34 (IT/Italy/81-208-30-34.ip.fastwebnet.it)
Failures: 5 (pop3d)
Interval: 300 seconds
Blocked: Yes

Log entries:

May 14 11:54:15 server2 pop3d: LOGIN FAILED, user=tony, ip=[::ffff:81.208.30.34]
May 14 11:54:17 server2 pop3d: LOGIN FAILED, user=cyrus, ip=[::ffff:81.208.30.34]
May 14 11:54:18 server2 pop3d: LOGIN FAILED, user=pgsql, ip=[::ffff:81.208.30.34]
May 14 11:54:20 server2 pop3d: LOGIN FAILED, user=info, ip=[::ffff:81.208.30.34]
May 14 11:54:20 server2 pop3d: LOGIN FAILED, user=named, ip=[::ffff:81.208.30.34]

Time: Fri May 14 12:09:28 2010 -0400
IP: 81.208.30.34 (IT/Italy/81-208-30-34.ip.fastwebnet.it)
Failures: 5 (pop3d)
Interval: 300 seconds
Blocked: Yes

Log entries:

May 14 12:09:01 server2 pop3d: LOGIN FAILED, user=radiomail, ip=[::ffff:81.208.30.34]
May 14 12:09:07 server2 pop3d: LOGIN FAILED, user=harrypotter, ip=[::ffff:81.208.30.34]
May 14 12:09:15 server2 pop3d: LOGIN FAILED, user=divine, ip=[::ffff:81.208.30.34]
May 14 12:09:21 server2 pop3d: LOGIN FAILED, user=popa3d, ip=[::ffff:81.208.30.34]
May 14 12:09:26 server2 pop3d: LOGIN FAILED, user=aptproxy, ip=[::ffff:81.208.30.34]

[Infopro]

LFD/CSF is not supported by cPanel, it's an addon and support for it is found on the ConfigServer forums. ConfigServer Scripts Forum - Powered by vBulletin

[d_t]

1. maybe blocked was just temporary, check entire ldf.log and config
2. how did you "manually blocked" IPs? if you block them by adding in csf.deny you must restart csf. You can also block with

csf -d IP

[crazyaboutlinux]

Make sure that you have permanently blocked

# csf -d xx.xx.xx.xx

then don't forget to restart CSF+LFD

# csf -r