Blacklisted but not in IPFW table

Create issue
Issue #110 closed
Former user created an issue

Good morning,

I am running SSHGuard 2.2.0 on FreeBSD 11.2. It successfully captures SSH and SMTPauth failures, creating temporary blocks which appear in IPFW table 22.

I have enabled /var/db/sshguard/blacklist.db and by the time it is growing (currently about 1000 records). I can view it via cat. But IPs in the blacklist are not in table 22 - currently the table is empty.

I am pretty sure SSHguard only add its records into defined table, and has no direct access to the firewall itself. So how could be blacklisted IPs disabled permanently, if they are not in the table 22?

What is wrong? Please advise.

Many thanks in advance. Have a nice day :-)

Peter Rosa

Comments (10)

  1. Kevin Zheng

    You're right, it looks like something is wrong. Either SSHGuard isn't loading the blacklisted addresses when it starts up (1), or it's not able to add the entries to the firewall (2). To troubleshoot 2:

    From your shell, run: echo "block 1.2.3.4" | $PREFIX/libexec/sshg-fw-ipfw

    Replacing "1.2.3.4" with an address you don't care about. Make sure that 1.2.3.4 actually appears in your table 22.

  2. Peter Rosa

    OK, I tried following commands:

    # echo "block 160.242.82.229" | /usr/local/libexec/sshg-fw-ipfw
    added: 160.242.82.229/0 0
    
    # ipfw table 22 list
    --- table(22), set(0) ---
    **0.0.0.0/0 0**
    14.176.231.112/32 0
    113.161.33.28/32 0
    190.210.81.237/32 0
    
    # echo "block 160.242.82.229" | /usr/local/libexec/sshg-fw-ipfw
    exists: 160.242.82.229/0 0
    ipfw: Adding record failed: record already exists
    
    # ipfw table 22 list
    --- table(22), set(0) ---
    **0.0.0.0/0 0**
    14.176.231.112/32 0
    113.161.33.28/32 0
    190.210.81.237/32 0
    

    As you can see, it is not there, but "echo "block 160.242.82.229" | /usr/local/libexec/sshg-fw-ipfw" creates 0.0.0.0/0 entry which effectively stops all communication. I double checked - it is really added by above command.

    If I use netmask/32, it is added and shows in the table

    # echo "block 160.242.82.229/32" | /usr/local/libexec/sshg-fw-ipfw
    added: 160.242.82.229/32 0
    # ipfw table 22 list
    --- table(22), set(0) ---
    14.176.231.112/32 0
    93.88.78.97/32 0
    113.161.33.28/32 0
    **160.242.82.229/32 0**
    186.71.49.26/32 0
    186.249.233.130/32 0
    190.210.81.237/32 0
    201.236.155.138/32 0
    
  3. Kevin Zheng

    Sorry, I made a mistake in the command I gave you. It should be:

    $ echo "block 1.2.3.4 4 32" | $PREFIX/libexec/sshg-fw-ipfw

    Where those three fields are address, address type (4 or 6), and the last bit is the address range (e.g. /32). If the new command does the right thing, then it's the blocker not loading from your database at startup.

  4. Peter Rosa

    Ok, understand. Just tried the new comman:

    # echo "block 160.242.82.229 4 32" | /usr/local/libexec/sshg-fw-ipfw
    added: 160.242.82.229/32 0
    # ipfw table 22 list
    --- table(22), set(0) ---
    37.97.187.209/32 0
    41.72.208.130/32 0
    109.92.139.14/32 0
    **160.242.82.229/32 0**
    177.189.204.86/32 0
    185.222.209.202/32 0
    197.14.12.36/32 0
    200.71.147.10/32 0
    

    IP is in the table 22. Now - how to solve this? Saying "it's the blocker not loading from your database at startup." is only the part of the solution. Am I really the only one to whom blacklist is not working? I would like to use blacklist for sure. Guys are trying from same IPs, so lock them down forever...

  5. Kevin Zheng

    Right, so we need more information to debug. Can you start SSHGuard in verbose mode and try to get the messages from sshg-blocker and see what's going on?

  6. Peter Rosa

    OK, I started:

    # env SSHGUARD_DEBUG=foo /usr/local/sbin/sshguard
    sshguard[49561]: whitelist: add IPv4 block: 192.168.1.0 with mask 24.
    sshguard[49561]: blacklist: blocking 544 addresses
    sshguard[49561]: whitelist: add '127.0.0.1' as plain IPv4.
    sshguard[49561]: whitelist: add plain IPv4 127.0.0.1.
    sshguard[49561]: Now monitoring attacks.
    

    it wrote full blacklist onscreen. Then, after Ctrl+C, table 22 was clean again.

    So I restarted sshguard (/usr/local/etc/rc.d/sshguard restart). It wrote: sshguard is not running, check /var/run/sshguard.pid then wrote whole blacklist onscreen and table 22 is now filled.

    Seems like it was not running - but I double checked it via ps ax | grep sshg. There was working sshg, adding temporary blocks and cleaning them away. Only the blacklist is not there.

    I just restarted the machine... Whole blacklist is loaded in the table 22, sshg operates normally. I ran:

    # ps ax | grep sshg
     656  -  Is    0:00.00 /bin/sh /usr/local/sbin/sshguard -b 120:/var/db/sshguard/blacklist.db -i /var/run/sshguard.pid
     660  -  IC    0:00.00 /usr/local/libexec/sshg-parser
     661  -  IC    0:00.00 /usr/local/libexec/sshg-blocker -a 10 -b 120:/var/db/sshguard/blacklist.db -i /var/run/sshguard.pid -p 120 -
     662  -  I     0:00.00 /bin/sh /usr/local/sbin/sshguard -b 120:/var/db/sshguard/blacklist.db -i /var/run/sshguard.pid
     663  -  I     0:00.03 /bin/sh /usr/local/libexec/sshg-fw-ipfw
    # cat /var/run/sshguard.pid
    661
    

    Seems like started twice (656 and 662), but it can be OK, I do not know.

    On monday I will re-check the table and write here the result. Right now it seems like the problem was solved by restart.

  7. Peter Rosa

    Good afternoon,

    it seems table 22 still has its 545 records and number of attacks significantly decreased. So sshguard seems to work properly. But I still do think there is some small error - see my previous post, "So I restarted...". SSHguard was running, but had no PID-file and no blacklist loaded.

    Right now, consider this thread as closed (solved). If I will be able repeat previous error and find out conditions, when it breaks, I will create another one with exact/accurate description.

    Thank you for helping me. Have a nice day.

  8. Kevin Zheng

    The PID file-writer is managed by the sshg-blocker process. I'm not sure what went wrong there, but sometimes the PID file does seem to get out of sync with what sshg-blocker is doing.

    As for the duplicate 'sshguard -b ...', they're actually just subshells spawned by the driver sshguard script (notice the /bin/sh) in the beginning. Right now the driver needs to spawn a subshell to correctly check for a child exit; it doesn't mean that two SSHGuard processes are running.

  9. Log in to comment