Comment sécuriser le serveur Ubuntu contre les attaques bruteforce ssh?

J'ai mes mots de passe sécurisés, mais j'ai entendu des gens se plaindre de la performance d'un serveur qui chutait radicalement lorsqu'une attaque par bruteforce avait lieu. Comment puis-je sécuriser mon serveur ubuntu 10.10 contre de telles attaques? Existe-t-il un profil d'apparmeur pour cela? Ou une autre façon de le résoudre?

Il existe différentes solutions. Le meilleur est d'utiliser l'authentification RSA qui utilise des clés publiques / privées pour authentifier les utilisateurs.

Consultez ce grand manuel pour différentes approches (authentification RSA incluse): http://www.la-samhna.de/library/brutessh.html

J'utilise la 3e solution sur mon serveur parce que je ne veux pas compliquer la tâche pour mes utilisateurs non techniques: utiliser iptablespour limiter le nombre de connexions par minute qui rend les attaques par bruteforce inefficaces et inefficaces.

Voici la solution que j'utilise:

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 recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force "
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP

Comme mentionné ici : cela autorisera trois connexions au port 22 à partir de n'importe quelle adresse IP donnée dans un délai de 60 secondes, et ne nécessitera 60 secondes d'aucune tentative de connexion ultérieure avant de reprendre l'autorisation des connexions. L'option --rttl prend également en compte le TTL du datagramme lors de la mise en correspondance des paquets, afin de tenter de limiter les adresses source usurpées.

Comme indiqué dans le guide mentionné, il est préférable d'utiliser une liste blanche pour séparer les utilisateurs de confiance de ces règles:

iptables -N SSH_WHITELIST

puis ajoutez des hôtes de confiance:

iptables -A SSH_WHITELIST -s $TRUSTED_HOST -m recent --remove --name SSH -j ACCEPT

et après cela, établissez les règles:

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_WHITELIST
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j ULOG --ulog-prefix SSH_brute_force
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP

J'obtiens des attaques ssh par force brute sur mes serveurs avec un taux de 1 à 2 par jour. J'ai installé denyhosts (package ubuntu: denyhosts). C'est un outil très simple mais efficace à cet effet: il analyse essentiellement vos journaux périodiquement pour détecter les attaques par force brute et place les adresses IP d'où ces attaques proviennent dans votre fichier /etc/hosts.deny. Vous ne les entendrez plus et votre charge devrait être considérablement réduite. Il est très configurable via son fichier de configuration /etc/denyhosts.conf pour modifier des problèmes comme le nombre de tentatives erronées constituant une attaque, etc.

En raison de son fonctionnement transparent, vous pouvez facilement voir ce qui se passe (notification par e-mail: `` aha, une autre attaque ignoble contrecarrée! '') Et annuler les erreurs dues au fait que vos utilisateurs ont mal tapé leurs mots de passe à plusieurs reprises.

Bien sûr, tout ce qui a été dit précédemment sur le passage à d'autres méthodes d'authentification est valable, mais parfois vos exigences ne correspondent pas à celles de vos utilisateurs.

En outre, la limitation du taux de nouvelle connexion dans iptables pourrait être un meilleur choix que de refuser l'accès via hosts.deny. Alors, jetez également un œil à fail2ban. Mais si vous savez que la force brute ssh est votre principale préoccupation (regardez manuellement dans /var/log/auth.log pour le déterminer), optez pour cet outil très simple et à faible impact.

1. Changez le port sshd en quelque chose de non standard
2. Utiliser knockdpour implémenter un système de port-knocking
3. Utilisez iptables recentet les hashlimitcorrespondances pour limiter les tentatives SSH consécutives
4. N'utilisez pas de mots de passe, mais utilisez plutôt des clés SSH

Tout d'abord, vous devriez envisager de ne pas utiliser de mots de passe et d'utiliser des clés à la place. Il n'est pas nécessaire d'utiliser un mot de passe. Si cela fonctionne pour vous, vous pouvez configurer le serveur OpenSSH pour qu'il ne réagisse pas aux connexions par mot de passe.

https://help.ubuntu.com/10.04/serverguide/C/openssh-server.html

L'utilisation de fail2ban pourrait également être une option.

https://help.ubuntu.com/community/Fail2ban

Quelle est l'étendue du serveur exposé sur le réseau? Vous pouvez peut-être discuter avec l'administrateur réseau et vérifier s'il est possible de surveiller et de restreindre l'accès réseau au serveur. Même si les connexions au compte sont sécurisées, il semble que le serveur puisse souffrir d'une simple attaque DoS / DDoS.

Une alternative à fail2ban est CSF: ConfigServer Security & Firewall .

Il est livré avec LFD: un démon d'échec de connexion qui peut détecter plusieurs tentatives de connexion échouées sur divers services et bloquera l'adresse IP incriminée (temporairement ou définitivement).

Il a d'autres options qui peuvent aider contre les attaques par inondation et éventuellement détecter les intrusions.

Désavantages:

• Vous devez utiliser CSF comme votre pare-feu pour que LFD fasse son travail. Donc, si vous avez un pare-feu existant, vous devrez le remplacer par CSF et transférer votre configuration.
• Il n'est pas conditionné pour Ubuntu. Vous devrez faire confiance aux mises à jour automatiques de configserver.com ou désactiver les mises à jour automatiques.
• J'ai entendu dire qu'il était assez populaire, donc les intrus intelligents sauront probablement comment désactiver la détection d'intrusion avant qu'ils ne soient détectés!

Avez-vous l'intention d'autoriser le service SSH dans le monde? Ou tout simplement aux membres de l'équipe à des endroits particuliers? Ma réponse dépend un peu de la gravité de votre défi.

Dans les deux cas, vous devez vous assurer que le serveur SSH n'autorise pas les connexions par mot de passe pour l'utilisateur root.

1. Dans / etc / ssh / sshd_config, assurez-vous de ne jamais autoriser une connexion root sauf avec une clé SSH.

Dans mes systèmes, j'ai ce paramètre

PermitRootLogin without-password

mais je remarque dans Ubuntu plus récent qu'ils ont

PermitRootLogin prohibit-password

Si vous lisez "man sshd_config", je pense que cela signifie que ce nouveau "mot de passe interdit" signifie la même chose et est certainement plus évident dans sa signification. Ce n'est PAS par défaut sur certains systèmes Linux, mais devrait probablement l'être.

Maintenant, à propos de votre problème. Votre serveur système ne concerne-t-il que certains utilisateurs à des endroits particuliers? Faites ça!

2. éditez /etc/hosts.deny et insérez

   TOUS: TOUS

Modifiez ensuite /etc/hosts.allow et répertoriez les numéros IP ou une plage qui souhaitent autoriser l'utilisation de SSH. La notation y est un peu déroutante car si vous souhaitez autoriser tous les systèmes avec des numéros IP tels que 111.222.65.101 à 111.222.65.255, vous mettez une entrée comme celle-ci dans hosts.allow

ALL: 127.0.0.1
sshd: 111.222.65.
sshdfwd-X11: 111.222.65.

Il s'agit d'une solution bruteforce et puissante. Si vos utilisateurs peuvent être énumérés par plage IP, faites-le!

Cette solution existait avant la création des tables IP, elle est (je pense) beaucoup plus facile à administrer, mais elle n'est pas aussi bonne qu'une solution de tables IP car les routines de tables IP repèreront les ennemis plus tôt que les programmes pilotés par hosts.allow et hosts .Nier. Mais c'est un feu sûr, un moyen simple de résoudre beaucoup de problèmes, pas seulement de SSH.

Notez le problème que vous créez par vous-même. Si vous souhaitez ouvrir un serveur FTP, un serveur Web ou autre, vous devrez autoriser les entrées dans les hôtes.

Vous pouvez atteindre le même objectif de base en jouant avec iptables et le pare-feu. Dans un sens, c'est une solution préférée car vous bloquez les ennemis à la limite extérieure. Ubuntu a "ufw" (pare-feu simple) et "man ufw" a de nombreux exemples. Je préfère avoir une interface graphique agréable pour parcourir tout cela, je n'ai pas à le faire tout le temps. Peut-être que d'autres peuvent nous dire s'il y en a un maintenant.

3. D'autres articles ici suggèrent d'utiliser la clé publique SSH uniquement pour vos utilisateurs. Cela aidera certainement, au prix de la complexité et de la frustration de vos utilisateurs. Dans notre laboratoire, il y a 15 ordinateurs. Les utilisateurs vont parmi les ordinateurs. Exiger une authentification par clé SSH causerait de gros tracas car les gens passent d'un ordinateur à l'autre.

Une autre source de frustration se produira lorsque certains utilisateurs accumuleront différentes clés ssh pour différents serveurs. Parce que j'ai des clés SSH pour environ 12 projets différents, maintenant ssh échoue parce que j'ai trop de clés publiques (exigeant soit "ssh -o PubkeyAuthentication = false" soit la création d'une entrée dans le fichier .ssh / config. C'est un PITA)

4. Si vous devez laisser le serveur ouvert à SSH du monde entier, alors vous devez certainement utiliser une routine de rejet pour bloquer les emplacements qui essaient fréquemment de se connecter. Il existe 2 programmes sympas pour cela, ceux que nous avons utilisés sont denyhosts et fail2ban . Ces programmes ont des paramètres qui vous permettent d'interdire les délinquants, pour une durée que vous aimez.

Dans nos systèmes Centos Linux, j'ai remarqué qu'ils ont abandonné le package denyhosts et ne proposent que fail2ban. J'ai aimé denyhosts car il a créé une liste d'utilisateurs / plages IP gênantes, puis dans hosts.deny, cette liste a été notée. Nous avons installé à la place fail2ban et c'est OK. Ma compréhension est que vous préférez bloquer ces mauvais utilisateurs sur le bord extérieur du serveur, donc les bloqueurs basés sur les tables ip, comme fail2ban, sont en fait meilleurs. Denyhosts fonctionne au niveau secondaire, après que les ennemis ont passé iptables, ils sont ensuite rejetés par le démon sshd.

Dans ces deux programmes, il est un peu fastidieux de faire sortir les utilisateurs de prison s'ils oublient leur mot de passe et d'essayer de se connecter plusieurs fois. Il est un peu difficile de faire revenir les gens lorsqu'ils font des erreurs de connexion. Vous auriez deviné qu'il y aurait une interface graphique pointer-cliquer où vous pourriez simplement pointer et laisser les gens rentrer, mais ce n'est pas de cette façon. Je n'ai qu'à le faire tous les quelques mois et oublier comment entre les temps, j'ai donc écrit des instructions pour moi sur ma page Web http://pj.freefaculty.org/blog/?p=301