23

What is the easiest way to setup max login attempts in a LAMP environment (sshd installed via yum)? Is there a package or simple firewall rule?

John Himmelman
  • 833
  • 5
  • 10
  • 18

5 Answers5

58

I don't like to use any third party tools. Hence I used a combination of ssh configuration and firewall settings. With the following solution an attacker is allowed to produce exactly 3 fault logins in 2 minutes, or he will be blocked for 120 seconds.

1) Add the following line to /etc/ssh/sshd_config

MaxAuthTries 1

This will allow only 1 login attempt per connection. Restart the ssh server.

2) Add the following firewall rules

Create a new chain

iptables -N SSHATTACK
iptables -A SSHATTACK -j LOG --log-prefix "Possible SSH attack! " --log-level 7
iptables -A SSHATTACK -j DROP

Block each IP address for 120 seconds which establishes more than three connections within 120 seconds. In case of the fourth connection attempt, the request gets delegated to the SSHATTACK chain, which is responsible for logging the possible ssh attack and finally drops the request.

iptables -A INPUT -i eth0 -p tcp -m state --dport 22 --state NEW -m recent --set
iptables -A INPUT -i eth0 -p tcp -m state --dport 22 --state NEW -m recent --update --seconds 120 --hitcount 4 -j SSHATTACK

3) See log entries of possible ssh attacks in /var/log/syslog

Dec 27 18:01:58 ubuntu kernel: [  510.007570] Possible SSH attack! IN=eth0 OUT= MAC=01:2c:18:47:43:2d:10:c0:31:4d:11:ac:f8:01 SRC=192.168.203.129 DST=192.168.203.128 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=30948 DF PROTO=TCP SPT=53272 DPT=1785 WINDOW=14600 RES=0x00 SYN URGP=0
My-Name-Is
  • 701
  • 1
  • 5
  • 6
  • 2
    Awesome! but I have a problem, some guy/bot in France haven't configured his hacker tools correctly, so he keeps logging in, even though his traffic is dropped. The result, my logs are filled with data every second from this guy. Any way around this? – Smarties89 Feb 22 '15 at 18:30
  • 3
    For less-experienced people like myself: the iptables lines are typed in at the bash prompt, not entered into a file somewhere. – Andrew Swift Mar 08 '16 at 09:58
  • If your setting was longer than 120 seconds and you wanted to unblock an IP because of a mistake. How would you go about this? @my-name-is – ConstantFun Oct 06 '20 at 09:47
  • Exactly what I needed. Thank you! – Fam Aug 09 '21 at 15:43
13

I use Fail2ban; I've used Denyhosts in the past, and it works quite well, too. I favor Fail2ban now because it is more configurable, and more able to handle monitoring multiple different services -- for example, your sshd and you web app's login page simultaneously (provided you log failures).

Another method you might consider is implementing a LIMIT rule in iptables; I unfortunately can't help you with this, unless you want to install Shorewall, and then I'd simply point you toward the excellent documentation on that site for how to configure a LIMIT rule to, well, limit the ability of someone to brute-force your server.

Kromey
  • 3,621
  • 4
  • 24
  • 30
  • I should add that Fail2ban is available in many distros' repositories, so installing it is a breeze; I haven't seen Denyhosts in any, but that doesn't mean it isn't in some, nor that it hasn't been added since the last time I checked. – Kromey May 31 '11 at 20:29
  • I've faced with problem that fail2ban of v0.8.14 didn't correctly work with iptables-multiport command. And this is known issue with fail2ban utility resolved in fresh versions... Here is description: https://github.com/fail2ban/fail2ban/issues/798 So I believe only in security mechanisms developed into server software, nor 3rd party utilities... – George Gaál Jun 05 '16 at 13:17
  • It is pretty sad that SSH does not have this built in, such an essential feature. We need to cobble together other tools to do something that SSH should be able to do by itself. – Markus Bawidamann Oct 26 '20 at 08:44
5

There's not a specific package associated with SSH to set this up. You could however install CSF which is ConfigServer & Firewall.

CSF

Two Configuration changes I'd suggest would be made in the file: /etc/ssh/sshd_config

Limit the maximum number of unauthenticated connections that the ssh server will handle at the same time. The smaller this is, the harder it is for script kiddies to make parallel, coordinated cracking attempts with multiple connections. edit sshd_config and change MaxStartups from the default of "10" to "3:50:10". The colon separated values tells the ssh server to, "allow 3 users to attempt logging in at the same time, and to randomly and increasingly drop connection attempts between 3 and the maximum of 10". Note: this should be increased on servers with substantial numbers of valid ssh users logging in.

  • Default: MaxStartups 10
  • MaxStartups 3:50:10

Reduce the maximum amount of time allowed to successfully login before disconnecting. The default of 2 minutes is too much time to hold open an unauthenticated connection attempt (see above); 30 seconds is more than enough time to log in:

  • Default: LoginGraceTime 2m
  • LoginGraceTime 30
Brendan
  • 401
  • 2
  • 3
5

I use these IPTables rules for this:

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 300 --hitcount 4 --rttl  --name SSH -j DROP

That will only allow 4 TCP/SYN packets to port 22 from an IP address in 5 minutes. If it makes more attempts the door is closed till 5 minutes are over.

Ladadadada
  • 25,847
  • 7
  • 57
  • 90
belteshazzar
  • 292
  • 4
  • 9
2

there is an option that you can put into your sshd_config file for the server:

 MaxAuthTries
         Specifies the maximum number of authentication attempts permitted per
         connection.  Once the number of failures reaches half this value, additional 
         failures are logged.  The default is 6.
mdpc
  • 11,698
  • 28
  • 51
  • 65
  • Useful (especially when combined with other suggestions already made), but doesn't really solve the problem on its own as it's trivial for someone to just keep re-connecting. – Kromey May 31 '11 at 20:32