Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 3 subscribers
  • Views 6438 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SSH block password guessing not working

hnu
Hi,

I'm having issues setting up the SSH block password guessing feature properly.

In Definitions & Users -> Authentication Services -> Advanced -> Block password guessing I have set attempts to 3, block for 1800 secs, enabled drop packets and ticked SSH access in Facilities. The list of "Never block networks" is empty.

When I try false logins from another (non-local) remote server via SSH, I'm never getting blocked. I got 5 emails from UTM about a failed SSH login (5 is the limit), but I don't get the email stating that the IP has been blocked for 1800 seconds.

The SSH log shows that the device sees the failed logins: 

2015:01:12-11:50:41 gw-2 sshd[19005]: Failed password for root from  port 38604 ssh2

2015:01:12-11:50:42 gw-2 sshd[19005]: Failed password for root from  port 38604 ssh2

2015:01:12-11:50:43 gw-2 sshd[19005]: Failed password for root from  port 38604 ssh2

2015:01:12-11:50:43 gw-2 sshd[19005]: Connection closed by  [preauth]

2015:01:12-11:50:45 gw-2 sshd[19047]: Failed password for root from  port 38605 ssh2

2015:01:12-11:50:46 gw-2 sshd[19047]: Failed password for root from  port 38605 ssh2

2015:01:12-11:50:47 gw-2 sshd[19047]: Failed password for root from  port 38605 ssh2

2015:01:12-11:50:47 gw-2 sshd[19047]: Connection closed by  [preauth]

2015:01:12-11:50:48 gw-2 sshd[19216]: Failed password for root from  port 38606 ssh2

2015:01:12-11:50:49 gw-2 sshd[19216]: Failed password for root from  port 38606 ssh2

2015:01:12-11:50:50 gw-2 sshd[19216]: Failed password for root from  port 38606 ssh2

2015:01:12-11:50:50 gw-2 sshd[19216]: Connection closed by  [preauth]

2015:01:12-11:50:52 gw-2 sshd[19253]: Failed password for root from  port 38607 ssh2

2015:01:12-11:50:52 gw-2 sshd[19253]: Failed password for root from  port 38607 ssh2

2015:01:12-11:50:53 gw-2 sshd[19253]: Failed password for root from  port 38607 ssh2

2015:01:12-11:50:53 gw-2 sshd[19253]: Connection closed by  [preauth]

2015:01:12-11:50:55 gw-2 sshd[19291]: Failed password for root from  port 38608 ssh2

2015:01:12-11:50:56 gw-2 sshd[19291]: Failed password for root from  port 38608 ssh2

2015:01:12-11:50:56 gw-2 sshd[19291]: Failed password for root from  port 38608 ssh2

2015:01:12-11:50:56 gw-2 sshd[19291]: Connection closed by  [preauth]


The weird thing is that from time to time I get emails about some IP being blocked. I just don't seem to be able to block myself...

Thanks for the help.
hubsif.


This thread was automatically locked due to age.
  • 0
    It maybe a bug. I haven't been able to reproduce it on any of my devices. It seems to work as I would expect. Not sure if my expectations are different per se.

    At any rate. If this is something that worries you / keeps you up late at night consider

    Disallowing SSH from external sources
    Change the service port to a higher port number 10k-60k
    Disallow passwords, use certificates instead
    If you have a use case / want to use passwords over certs then simply follow good password policies. Aka very strong passwords, not simply strong, but twice as strong as the min requirements. If strong means 13 chars (A-Za-z0-9) then do 26 chars, etc. 

    Personally I couldn't make any reasonable argument to have SSH services on the firewall outward facing. If you have a need to access the firewall at this level VPN in to the network first then access the SSH service. Yes; I understand that makes it harder, but I understand that it makes it harder. Isn't that what you're really asking for? Security?
  • 0
    As far as I know, fail2ban is not working beyond sending a mail in recent version of UTM. It also fails on SMTP password guessing.
  • 0 in reply to StephaneGROBETY
    Mine worked fine, I got tired of the same address from China trying hack my system, so as suggested elsewhere I removed the SSH access from the external interface, problem solved. I received e-mail for each failed attempt and the block period notification.


    Ian
  • 0
    @Jayson: You're perfectly right about the suggested modifications. I had already moved SSH to a non-standard high port before and allow login with certificates only. But those bots out there seem to always find out sooner or later.
    And I think your suggestion to simply disable (non-VPN) SSH follows a wrong way of argumentation. It would surely increase security, but then you could also say shutting down the device would increase security [:)].

    Anyways, I need to be able to login from external sources without VPN, so simply turning that off is not applicable here. And that's why I was looking into the blocking feature.
    I'm not really worried about someone actually finding his way in, due to certificate logins only. But all these brute force attacks increase the load on the device, spam the log files and most importantly keep the hackers retrying. Since the device offers the ability to get rid of this, I'd like to use that feature.

    Unfortunately, I still wasn't able to get it working. I still get some emails that some China IP has been blocked, and I still am not able to block myself. I keep wondering in what way the blocked attempts are different from the ones that aren't blocked...

    @fulgan: I updated my devices to 9.3 yesterday. I was hoping that this might fix it, but it didn't. What you're saying sounds like it could even have become worse, so that even the random blocks won't work anymore.
    What makes you think that it's not working at all? And how do you know fail2ban is being used for that feature? I can't find any hints of fail2ban on the devices.

    hnu
  • 0 in reply to hnu
    Im with you hnu.

    My email got spammed with huge number of attempted logins. The pad part is, that these bots know their trying to login to a valid device, as their being blocked after number of attempts and then their allowed again after 600 seconds by default.

    I have no idea why such a simple option as blocking/blaclisting IPs is not implemented in the UTM.

    There is a feature request already for that:
    Network Security: Block Malicious/Botnet/Bad IP's using Blacklist "Service"

    But thats about it.

    Many much simpler, even desktop firewalls allow blacklisting...

    I even had a Synology NAS with built in firewall.
    I could setup blocking ips with # of failed login attempts permanently.

    I still will have access from internal network, so that shouldn't be a problem. 

    I am very disappointed Sophos/Astaro.
  • 0
    I would argue that this is clearly a troubleshooting issue and not a Sophos issue. I love giving the Sophos gang a good verbal beating from time to time, but this time I just do see it as justifiable. 

    The argument that the service must be forward facing, but I'm unhappy with it being forward facing because someone might get in is an adaption issue you are going to have to deal with as an admin, not as a service. 

    I have changed the SSH port and gone to cert auth but that's not good enough, is hard to follow as well. I'm guessing the argument is supposed to be that you do not want the alerts that the bots are hopelessly trying to access the device? They're not going to get in so why not simply turn off the alerts? Only alert on successful logins and log everything else. 

    The attempts are a resource hog? I suppose I can see that but at the same time I've seen a 320 box take a 20 GiB DDoS reflection attack and handle it with little to no impact on that production network. Fix the hardware bottle neck if there truly is one. My guess is the hard drive, start there.

    At the end of the day you have to make good, dynamic, adaptive choices...
  • 0
    I agree with Jayson.  For external access, I have two methods using putty and an RSA key for root access:
    [LIST=1]I created A-records for a supportaccess FQDN like the one Sophos Support uses.  In addition to the Sophos FQDN, these are the only public IPs allowed access.
    • 'Allowed networks' also includes the "BAlfson (User Network)" object, so I can VPN in from anywhere and access via that.
    [/LIST]
    I have several customers that leave Shell Access disabled - they enable it from WebAdmin when needed.  None of my clients has had an issue with attempts to SSH into their UTM and all but one use the standard port.

    Cheers - Bob