Preventing - Large Number of Failed Login Attempts from IP

9,398

Solution 1

What I would do is use Fail2Ban & point it to your ssh log file. That way if you get a specified number of failed attempts from the same IP's, fail2ban automatically adds a firewall rule to drop packets from those IP's for a period of time you specify.

Solution 2

Up front one little detail. The log entries you see look like they're coming from hosts.deny, because sshd is "TCP-wrapped" (usually, on Linux). For detailed information check out man tcpd.

Using firewall rules you can fine-tune better what ends up in the (sys)log. So that's the place to whitelist your static IP and blacklist everybody else.

If you wanted to convert your existing rules to iptables you could use the following shell-script (replace the PORTS and MYIP with variables matching your needs):

#!/bin/bash
IPT="echo /sbin/iptables"
MYIP=1.2.3.4
PORTS="22 443 8080"
$IPT -P INPUT DROP
for port in $PORTS; do
        $IPT -I INPUT -p tcp --dport $port -s $MYIP -j ACCEPT
done

... or shorter:

#!/bin/bash
IPT="echo /sbin/iptables"
MYIP=1.2.3.4
PORTS="22 443 8080"
$IPT -P INPUT DROP
$IPT -I INPUT -p tcp -m multiport --dports ${PORTS// /,} -s $MYIP -j ACCEPT

... or in two hardcoded lines:

/sbin/iptables -P INPUT DROP
/sbin/iptables -I INPUT -p tcp -m multiport --dports 22,443,8080 -s 1.2.3.4 -j ACCEPT

Unfortunately there is no nice way of making it deduce the port numbers, so you'll likely end up hardcoding those.

Also keep in mind that you may want to flush your INPUT table before setting the policy, using iptables -X INPUT.

The above, explained in a few words, sets the default policy for the INPUT table to DROP and then allows only TCP connections to the given ports ($PORTS) from the given IP ($MYIP).


You seem to be interested in a very strict lockdown, with the exception of your own static IP, so nothing of the following may be required at all.

I have been using the following netfilter rules, as pointed out in an earlier post by me here on ServerFault: Is it normal to get hundreds of break-in attempts per day?

I am not going to repeat the rules here, because they already exist on this site. However, you have to keep in mind that you are still going to get some log messages until the IP is automatically put into the tarpit. In general I don't think you have to be worried so much about the amount of attempts, given your very sound sshd configuration. Adjust the tarpit times to confine attackers longer or act sooner, but keep in mind not to lock yourself out.

Also, in the recent past I have tested and grown quite fond of sshguard. Although many people compare it to Fail2Ban, I think its scope is much wider (also not limited to sshd). This tool can use various facilities to parse the logs (directly or after your syslog facility puts it into a file) and various facilities to block (e.g. netfilter/iptables).

Whenever people have been tenacious with their attempts, I have put in complete blocks (firewall).

If only the log entries annoy you configure your logcheck (or other tool) to filter those or change the port to which sshd binds. Security-wise, however, I consider this snakeoil.

Solution 3

With that configuration, sshd will still report failed attempts along the lines of:

Dec  3 00:56:35 servername sshd[31242]: refused connect from li471-78.members.linode.com (50.116.13.78)
Dec  3 00:56:40 servername sshd[31244]: refused connect from li471-78.members.linode.com (50.116.13.78)

Perhaps your log alert is triggering on that? Check your logs to verify that this is the case.

You can make this go away by changing the sensitivity/search pattern of your alert function.

You can also make it go away by using the firewall to block all incoming SSH traffic other than from your IP address. If you use the firewall, nothing will hit sshd, and so nothing will appear in your log.

Solution 4

You might have been hacked.

Do a rpm -Vv keyutils-libs as root on your server.

Do you see a 5? If so one of the libs has been substituted by a attacking version.

More details about the attack (probably using cPanel) can be found here.

Solution 5

I use this personnaly to limit access to some ports on my servers:

-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name SSHACCESS --rsource 
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 180 --hitcount 20 --name SSHACCESS --rsource -j DROP

you can play with --seconds and --hitcounts to fit you context.

Also you can use some more comlicated rules like port knocking. in this case you send requests ( could be ping, tcp, telnet or whatever you want ) and then system opens for instance SSH port for a few seconds only for that IP and you can do ssh to server. check this link to implement this with iptables

this is a simple port knocking on port 1000:

-A INPUT -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 1000 -m recent --set --name KNOCKING --rsource
-A INPUT -p tcp -m tcp --dport 22 -m recent --rcheck --seconds 5 --name KNOCKING --rsource -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j DROP

now you can ssh to your server like this:

telnet <ip> 1000 ; ssh <ip>

if you need more help on this please let me know.

Share:
9,398

Related videos on Youtube

Dan
Author by

Dan

Updated on September 18, 2022

Comments

  • Dan
    Dan over 1 year

    I'm running a CentOS 6.3 server and currently receive emails entitled "Large Number of Failed Login Attempts from IP" from my server every 15 minutes or so.

    Surely with the below configured it should mean only the person using the (my static ip) should be able to even try and log in?

    If that's the case where are these remote unknown users trying to log into which is generating these emails?

    Current Security Steps:

    • root login is only allowed without-password
    • StrictModes yes
    • SSH password login is disabled - PasswordAuthentication no
    • SSH public keys are used
    • SSH port has been changed to a number greater than 40k
    • cPHulk is configured and running
    • Logins limited to specific ip address
    • cPanel and WHM limited to my static ip only

    sshd_config

    [email protected]
    

    hosts.allow

    ALL : <Static IP>
    

    hosts.deny

    ALL : ALL
    

    iptables

    iptables -I INPUT -s <Static IP> -p tcp -m tcp --dport 22 -j ACCEPT
    iptables -I INPUT -p tcp -m tcp --dport 22 -j REJECT
    
  • cjc
    cjc over 11 years
    If it's just one IP that's annoying you today, you can do something like iptables -I INPUT -s 1.1.1.1 -j DROP to block, for example, 1.1.1.1. If it's a variety of IP addresses, you can use fail2ban as an automatic way of blocking IPs. If you just want to whitelist, you can do something like (this is untested, so use carefully so you don't lock yourself out) iptables -I INPUT -s (your static ip) -j ACCEPT and then iptables -A INPUT -p tcp --dport 22 -j DROP. You can google around for iptables ssh brute force for more infor.
  • Danie
    Danie over 11 years
    You could always implement rate limiting via iptables. IPtables will block for example 10 tries in one minute. It just depends on the thresholds you want to have. google iptables rate limiting
  • Dan
    Dan about 11 years
    Is that not the same as cphulk?
  • churnd
    churnd about 11 years
    On the surface, they seem to do the same thing, but I'm not sure what cPHulk does underneath to disable the attempt. It may be that cPHulk isn't configured correctly. I know that fail2ban uses iptables which would block access entirely.
  • Dan
    Dan about 11 years
    As I only need one ip for SSH I'm considering iptables -A INPUT -p tcp -s 1.1.1.1 --dport 22 -j ACCEPT would this be the best solution?
  • churnd
    churnd about 11 years
    Yeah I guess, but what if you lose that IP for some reason? I'd hate to have that limitation without another way in. You'd need to follow it with a reject rule so it'll drop the other IP's: iptables -I INPUT -p tcp -m tcp --dport 22 -j REJECT. Fail2Ban takes care of all that for you.
  • Dan
    Dan about 11 years
    The above reject rule doesn't seem to work? It just blocks everything including the allowed ip in the first rule?
  • churnd
    churnd about 11 years
    Do the reject rule first, then the accept.