Comment sécuriser le serveur Ubuntu contre les attaques sb par bruteforce?
J'ai mes mots de passe sécurisés, mais j'ai entendu des gens se plaindre des performances d'un serveur en panne drastique lorsqu'une attaque brutale se produit. Comment sécuriser mon serveur Ubuntu 10.10 contre de telles attaques? Existe-t-il un profil apparmor pour cela? Ou un autre moyen d'y remédier?
Il y a différentes solutions. Le meilleur consiste à 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 ème solution sur mon serveur car je ne veux pas compliquer les choses pour mes utilisateurs non techniques: utiliser iptables pour limiter le nombre de connexions par minute rendant inefficaces les attaques par force brutale et inefficace.
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 aucune tentative de connexion ultérieure pendant 60 secondes avant de permettre la reprise des connexions. L'option --rttl prend également en compte le TTL du datagramme lors de la mise en correspondance des paquets, afin 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 ensuite faire 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
Je reçois des attaques ssh en force sur mes serveurs à raison de 1 à 2 par jour. J'ai installé denyhosts (paquet Ubuntu: denyhosts). C’est un outil très simple mais efficace à cette fin: essentiellement, il analyse périodiquement vos journaux pour détecter les attaques par force brute et met les adresses IP à l’origine de ces attaques dans votre fichier /etc/hosts.deny. Vous n'entendrez plus parler d'eux et votre charge devrait être considérablement réduite. Il est très configurable via son fichier de configuration /etc/denyhosts.conf pour régler des problèmes tels que le nombre de tentatives erronées constituant une attaque, etc.
Grâce à son fonctionnement transparent, vous pouvez facilement voir ce qui se passe (notification par courrier électronique: 'aha, une autre attaque ignoble contrecarrée!') Et annuler les erreurs dues à la mauvaise saisie répétée du mot de passe par vos utilisateurs.
Bien sûr, tout ce que nous avons déjà dit sur le passage à d’autres méthodes d’authentification est valable, mais il arrive que vos exigences divergent de celles de vos utilisateurs.
En outre, la limitation du taux de nouvelle connexion dans iptables pourrait constituer un meilleur choix que de refuser l'accès via hosts.deny. Alors jetez un œil à fail2ban également. Mais si vous savez que la force principale de ssh est votre principale préoccupation (consultez manuellement le fichier /var/log/auth.log pour le déterminer), utilisez cet outil très simple et sans impact.
- Changer le port sshd en quelque chose de non standard
- Utilisez
knockdpour implémenter un système port-knocking - Utilisez les correspondances _
recentethashlimitde iptables pour limiter les tentatives SSH consécutives - 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 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 lors de la connexion à un mot de passe.
https://help.ubuntu.com/10.04/serverguide/C/openssh-server.html
Utiliser fail2ban pourrait également être une option.
Avez-vous l'intention d'autoriser le service SSH au monde? Ou simplement pour les 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.
- Dans/etc/ssh/sshd_config, veillez à 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, ils ont
PermitRootLogin prohibit-password
Si vous lisez "man sshd_config", je pense que cela signifie que le plus récent "interdire-mot de passe" signifie la même chose et que sa signification est certainement plus évidente. 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 traite-t-il que certains utilisateurs à des endroits particuliers? Fais ça!
éditez /etc/hosts.deny et insérez
TOUS: TOUS
Ensuite, éditez /etc/hosts.allow et listez les numéros IP ou une plage voulant autoriser l’utilisation de SSH. La notation est un peu déroutante car si vous voulez autoriser tous les systèmes avec des numéros IP tels que 111.222.65.101 à 111.222.65.255, vous devez insérer une entrée comme celle-ci dans hosts.allow.
ALL: 127.0.0.1
sshd: 111.222.65.
sshdfwd-X11: 111.222.65.
C'est une solution puissante 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 efficace qu’une solution de tables IP car les routines des 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 pour vous-même. Si vous souhaitez ouvrir un serveur FTP, un serveur Web ou autre chose, 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. En un sens, c'est une solution privilégiée car vous bloquez les ennemis à la limite extérieure. Ubuntu a "ufw" (pare-feu simple) et "man ufw" a beaucoup d'exemples. Je préférerais 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 en existe un maintenant.
- D'autres publications 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 beaucoup de problèmes, car les gens passent d’un ordinateur à l’autre.
Une autre source de frustration se produira lorsque certains utilisateurs accumulent différentes clés SSH pour différents serveurs. Comme j'ai des clés SSH pour environ 12 projets différents, maintenant ssh échoue car j'ai trop de clés publiques (Exige soit "ssh -o PubkeyAuthentication = false" ou la création d'une entrée dans le fichier .ssh/config. Il s'agit d'un PITA)
- Si vous devez laisser le serveur ouvert à SSH depuis le monde entier, vous devez absolument utiliser une routine de rejet pour bloquer les emplacements qui tentent fréquemment de se connecter. Il existe 2 programmes Nice 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 avaient abandonné le paquet denyhosts et n’offraient plus que fail2ban. J'ai aimé denyhosts car il a créé une liste d'utilisateurs/plages d'adresses IP problématiques, puis dans hosts.deny, cette liste a été notée. Nous avons installé fail2ban à la place et tout va bien. D'après ce que je comprends, vous préférez bloquer ces mauvais utilisateurs au niveau de la périphérie externe du serveur. Les bloqueurs basés sur les tables ip, comme fail2ban, sont donc meilleurs. Denyhosts fonctionne au niveau secondaire. Une fois que les ennemis ont dépassé iptables, ils sont ensuite rejetés par le démon sshd.
Dans ces deux programmes, il est un peu fastidieux de sortir les utilisateurs de la 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 commettent 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 revenir, mais ce n'est pas ainsi. Je n'ai qu'à faire cela tous les quelques mois et à oublier comment, entre fois, j'ai donc écrit des instructions pour moi-même sur ma page Web http://pj.freefaculty.org/blog/?p=301
CSF est une alternative à fail2ban: ConfigServer Security & Firewall .
Il est livré avec LFD: un démon d’échec de connexion capable de détecter plusieurs tentatives de connexion infructueuses sur différents services et de bloquer l’adresse IP incriminée (de manière temporaire ou permanente).
Il propose d'autres options permettant de lutter contre les attaques par inondation et éventuellement de détecter les intrusions.
Désavantages:
- Vous devez utiliser la CSF comme pare-feu pour que LFD puisse faire son travail. Donc, si vous avez un pare-feu existant, vous devrez le remplacer par CSF et transférer votre configuration.
- Ce n'est pas emballé 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 est très populaire, donc les intrus intelligents sauront probablement comment désactiver la détection des intrusions avant qu'ils ne soient détectés!
Dans quelle mesure le serveur est-il exposé sur le réseau? Vous pouvez peut-être parler à l'administrateur du réseau et vérifier s'il est possible de surveiller et de limiter l'accès réseau au serveur. Même si les connexions au compte sont sécurisées, il semble que le serveur pourrait souffrir d'une simple attaque DoS/DDoS.