Ne pas bloquer la force brute ssh avec iptables

J'essaie de bloquer (ralentir) les attaques par force brute sur mon serveur sshd. Je suis ce guide http://www.rackaid.com/resources/how-to-block-ssh-brute-force-attacks/ qui dit essentiellement que je dois simplement entrer les 2 commandes ci-dessous.

sudo iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
sudo iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent  --update --seconds 60 --hitcount 4 -j DROP

Mon port sshd est 6622, donc j'ai changé les entrées de "22" en "6622", et j'ai mis ces commandes. Ensuite, j'ai essayé de simplement tester les nouveaux iptables. Je suis allé sur un autre PC et j'ai volontairement entré le mauvais mot de passe de connexion plusieurs fois. Malheureusement, les nouvelles règles ne semblent pas m'empêcher d'essayer autant que je veux. Voici mes règles actuelles. Qu'est-ce que je fais mal?

# iptables --list

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
DROP       tcp  --  anywhere             anywhere             tcp dpt:6622 state NEW recent: UPDATE seconds: 60 hit_count: 4 name: DEFAULT side: source
           tcp  --  anywhere             anywhere             tcp dpt:6622 state NEW recent: SET name: DEFAULT side: source

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain LOGDROP (0 references)
target     prot opt source               destination         
LOG        all  --  anywhere             anywhere             LOG level warning
DROP       all  --  anywhere             anywhere            

Comme @banjer l'a souligné dans son commentaire, vous essayez la mauvaise solution pour votre problème réel.

Ce que vous devez faire, c'est configurer fail2ban . Il utilise iptables en arrière-plan pour bloquer automatiquement les tentatives de connexion des hôtes qui génèrent des tentatives d'accès infructueuses à partir de diverses sources. Il est incroyablement polyvalent et vous permet d'ajouter et de modifier différents seuils, modèles à rechercher et méthodes d'interdiction; vous devrez légèrement modifier sa prison ssh par défaut pour tenir compte du port non standard que vous utilisez, mais cela ne devrait pas être difficile.

J'utilise des règles comme celle-ci pour ralentir les choses:

iptables -A DDoS -m limit --limit 12/s --limit-burst 24 -j RETURN
iptables -A DDoS -j LOG --log-prefix "[DDos Attack?] "
iptables -A DDoS -j DROP

Dans d'autres endroits, je limite des choses comme ça:

LOGLIMIT="50/h"
LOGLIMITBURST="10"
iptables -A IANA -p tcp -m limit --limit $LOGLIMIT --limit-burst \
     $LOGLIMITBURST -j DROP

Avez-vous lu la page de manuel?

man sshd_config:

 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.
 MaxSessions
         Specifies the maximum number of open sessions permitted 
         per network connection.  The default is 10.
 MaxStartups
         Specifies the maximum number of concurrent unauthenticated
         connections to the SSH daemon.  Additional connections
         will be dropped until authentication succeeds or 
         the LoginGraceTime expires for a connection. The default is 10:30:100.

         Alternatively, random early drop can be enabled by specifying
         the three colon separated values “start:rate:full” (e.g.
         "10:30:60").  sshd(8) will refuse connection attempts with a
         probability of “rate/100” (30%) if there are currently “start”
         (10) unauthenticated connections.  The probability increases
         linearly and all connection attempts are refused if the 
         number of unauthenticated connections reaches “full” (60).

Je viens d'essayer la solution à deux règles et j'ai eu le même problème lorsque je l'ai vérifiée. Ensuite, je remarque que les règles publiées ont une -i eth0option! Je l'ai changé pour la bonne interface réseau et il a finalement commencé à fonctionner.

La plupart des didacticiels -As'ajoutent à la fin de l'ensemble de règles. OP utilisé -Ipour insérer mais sans index, les règles se sont donc retrouvées dans le mauvais ordre.

Un outil précieux pour déboguer les règles iptables est la iptables -vLliste des règles avec le nombre de fois où chaque règle a été appliquée. Lorsque vous obtenez un nombre inattendu de 0, cela peut vous aider à voir ce qui ne va pas.