Est-il normal de recevoir des centaines de tentatives d'effraction par jour ?

Quelques centaines, c'est très bien... Le mois dernier, j'ai découvert qu'un de mes serveurs avait 40 000 tentatives ratées. J'ai pris la peine de les tracer : Carte

Une fois que j'ai changé le port ssh et implémenté le Port Knocking, le nombre est tombé à 0 :-)

Pour ma part, j'utilise un "tarpit" en plus de n'autoriser que l'authentification par clé publique et d'interdire les connexions à la racine.

Unter netfilter il existe un recent que vous pouvez utiliser avec le module ( INPUT chaîne) :

iptables -A INPUT -i if0 -p tcp --dport 22 -m state --state NEW -m recent --set --name tarpit --rsource
iptables -A INPUT -i if0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 180 --hitcount 6 --name tarpit --rsource -j DROP
iptables -A INPUT -i if0 -p tcp --dport 22 -j ACCEPT

Ce que cela fait, c'est que chaque tentative de connexion au port 22 est répertoriée par le programme recent avec IP et d'autres trucs sous le nom de "tarpit" (si vous êtes curieux, regardez à /proc/net/xt_recent/tarpit ). Vous pouvez évidemment utiliser d'autres noms.

Pour lister ou retirer des IPs, utilisez :

echo "+123.123.123.123" > /proc/net/xt_recent/tarpit
echo "-123.123.123.123" > /proc/net/xt_recent/tarpit

Cela limite le nombre de tentatives à 5 en 300 secondes. Veuillez noter que les utilisateurs avec une connexion existante ne sont pas gênés par cette limite, car ils ont déjà une connexion établie et sont autorisés à en créer d'autres (même au-delà de la limite de taux).

Adaptez les règles à votre convenance, mais veillez à ce qu'elles soient ajoutées dans cet ordre (c'est-à-dire que lorsque vous ajoutez, utilisez-les dans cet ordre, lorsque vous insérez, dans l'ordre inverse).

Cela réduit considérablement le bruit. Il fournit également une sécurité réelle (contre le forçage brutal) contrairement à la sécurité perçue du changement de port. Cependant, je recommande toujours de changer le port si c'est possible dans votre environnement. Cela permettra de réduire considérablement le niveau de bruit ...

Vous pouvez toujours combiner cela avec fail2ban, bien que je fonctionne très bien sans lui et seulement avec les règles ci-dessus.

EDITAR:

Il est possible de se bloquer en faisant cela, vous pouvez donc ajouter quelque chose comme ce qui suit qui vous permet de lever votre interdiction en frappant sur un port particulier :

iptables -A INPUT -i if0 -p tcp --dport <knockport> -m state --state NEW -m recent --name tarpit --remove

Vous pourriez mettre en œuvre fail2ban ou des méthodes similaires comme le verrouillage SSH sur votre IP. Malheureusement, les robots tentent tout le temps de forcer l'accès par la force brute, c'est donc tout à fait normal.

Oui . C'est tout à fait normal de nos jours.

Veuillez utiliser uniquement l'authentification par clé publique à des fins administratives si possible. Générez une clé privée sur votre poste de travail :

$ ssh-keygen -t dsa

Copier-coller le contenu de ~/.ssh/id_dsa.pub à vos serveurs ~/.ssh/authorized_keys (et /root/.ssh/authorized_keys, si vous avez besoin d'une connexion directe à la racine).

Configurez vos serveurs /etc/ssh/sshd_config pour n'accepter que l'authentification par clé publique :

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin without-password

Si vous avez trop de serveurs, vous pouvez utiliser Marionnette pour exécuter les clés publiques et les configurations à eux.

Regardez dans Denyhosts y fail2ban pour bloquer les tentatives répétées de connexion SSH et voir Snort si vous avez besoin d'un système IDS/IPS complet.