Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
@Hyppy Thanks, I tried searching but unfortunately there are many poorly named questions/threads. – John Himmelman May 31 '11 at 20:27
up vote 8 down vote accepted

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.

share|improve this answer
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: So I believe only in security mechanisms developed into server software, nor 3rd party utilities... – George Gaál Jun 5 at 13:17

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, until 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 establishe more than three connections within 120 seconds. In case of the forth 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 shh- 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= DST= LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=30948 DF PROTO=TCP SPT=53272 DPT=1785 WINDOW=14600 RES=0x00 SYN URGP=0
share|improve this answer
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
@Smarties89 ... haven't configured his hacker tools correctly ..., probably the configuration is correct ;-) So, stop with the jokes, what tells you that he could login successfully? – My-Name-Is Feb 22 '15 at 21:05
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 8 at 9:58

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


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
share|improve this answer

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.

share|improve this answer
What needed editing? – Timothy Makobu Aug 20 '12 at 20:04
Pretty much the same as: -A INPUT -p tcp -m tcp --dport 22 -m limit --limit 48/hour -j ACCEPT. – Alix Axel Nov 20 '12 at 1:53

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

         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.
share|improve this answer
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

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.