Please whitelist cPanel in your adblocker so that you’re able to see our version release promotions, thanks!

The Community Forums

Interact with an entire community of cPanel & WHM users!

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

Discussion in 'General Discussion' started by wsherwood, May 21, 2010.

  1. wsherwood

    wsherwood Registered

    May 21, 2010
    Likes Received:
    Trophy Points:
    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
    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
    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.

    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?


    (logs/summary attached below)


    Deny list entry: # lfd: 5 (pop3d) login failures from (IT/Italy/ 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: (IT/Italy/
    Failures: 5 (pop3d)
    Interval: 300 seconds
    Blocked: Yes

    Log entries:

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

    Time: Fri May 14 12:09:28 2010 -0400
    IP: (IT/Italy/
    Failures: 5 (pop3d)
    Interval: 300 seconds
    Blocked: Yes

    Log entries:

    May 14 12:09:01 server2 pop3d: LOGIN FAILED, user=radiomail, ip=[::ffff:]
    May 14 12:09:07 server2 pop3d: LOGIN FAILED, user=harrypotter, ip=[::ffff:]
    May 14 12:09:15 server2 pop3d: LOGIN FAILED, user=divine, ip=[::ffff:]
    May 14 12:09:21 server2 pop3d: LOGIN FAILED, user=popa3d, ip=[::ffff:]
    May 14 12:09:26 server2 pop3d: LOGIN FAILED, user=aptproxy, ip=[::ffff:]
    #1 wsherwood, May 21, 2010
    Last edited: May 21, 2010
  2. Infopro

    Infopro cPanel Sr. Product Evangelist
    Staff Member

    May 20, 2003
    Likes Received:
    Trophy Points:
    cPanel Access Level:
    Root Administrator
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  3. d_t

    d_t Well-Known Member

    Sep 20, 2003
    Likes Received:
    Trophy Points:
    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
  4. crazyaboutlinux

    crazyaboutlinux Well-Known Member

    Nov 3, 2007
    Likes Received:
    Trophy Points:
    Make sure that you have permanently blocked

    # csf -d xx.xx.xx.xx

    then don't forget to restart CSF+LFD

    # csf -r

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice