Sécurisation du serveur SSH contre le bruteforcing

J'ai un petit serveur SVN, un vieux Dell Optiplex fonctionnant sous Debian. Je n'ai pas des exigences élevées sur mon serveur, car c'est juste un petit serveur SVN ... mais je veux qu'il soit sécurisé.

Je viens de renouveler mon serveur pour un optiplex plus récent et meilleur, et j'ai commencé à chercher un peu dans l'ancien serveur. Je l'ai retiré après avoir rencontré des problèmes. Quand je vérifie les journaux, c'est plein de tentatives de force brute et quelqu'un a réussi à entrer dans ma machine. Cette personne a créé un volume supplémentaire appelé "knarkgosse" avec deux répertoires "root" et "swap1" ou quelque chose. Je ne sais pas vraiment pourquoi et ce qu'ils font, mais je veux vraiment éviter que cela ne se reproduise. Je trouve cela un peu étrange, car je change mon mot de passe tous les quelques mois environ, et les mots de passe sont toujours des lettres et des chiffres aléatoires mis en place ... pas facile à forcer.

Je sais que je peux empêcher root de se connecter et utiliser sudoers ... et changer le port SSH, mais que puis-je faire de plus?

J'ai donc quelques questions:

1. Comment puis-je empêcher la connexion pendant 5 minutes après un nombre X d'essais incorrects. Ou des essais lents vers le bas après chaque essai incorrect?

2. Existe-t-il une sorte de liste noire centrale à laquelle un serveur peut se connecter? Une liste noire qui conserve la trace des adresses IP qui sont «dangereuses» et ne devraient jamais avoir accès?

3. Que puis-je faire de plus pour appliquer la sécurité à mon serveur?

Comme je l'ai dit plus tôt, j'utilise Debian 5 avec Apache (problème d'utilisateur www-data?), Svn, mysql, php, phpmyadmin, hudson. Il se trouve sur un réseau domestique avec redirection de port sur 80, 443, 8080, 8180, 23 et 22.

Fail2ban et Port Knocking devraient répondre à la plupart de vos besoins.

Il est également recommandé de modifier votre port SSH et d'autoriser uniquement l'authentification par clé.

On peut affirmer que vous pouvez atteindre un point de rendement décroissant en ajoutant des mesures de sécurité supplémentaires, mais là encore, c'est à vous de décider quand vous êtes "suffisamment en sécurité".

C'est également une bonne idée de refuser la connexion root.

Rien ne remplace les mots de passe sécurisés ET l'authentification par clé. Cela étant dit, Fail2Ban est un excellent outil pour interdire les adresses IP des utilisateurs qui tentent de s'authentifier trop souvent. Il est également disponible sous forme de package pré-construit pour la plupart des distributions. Soyez averti, vous pouvez vous faire bannir accidentellement, alors assurez-vous d'avoir une adresse IP de récupération également ou un accès facile à la console ...

Fail2Ban a plusieurs bons exemples de comment configurer tout ce que vous avez demandé ... il n'a cependant pas de référentiel universel de mauvaises adresses. Je ne pense pas qu'il existe un tel référentiel n'importe où en raison de la facilité d'obtenir une autre IP (attaques dhcp renouvellement / bot-net / etc ...). Je voudrais également désactiver la connexion via ssh en utilisant des noms d'utilisateur de type «administrateur» courants (root / admin / administrator / sysop / etc ..) car ce sont les plus couramment frappés.

J'ai arrêté les attaques par force brute avec:

• fail2ban
• sshd.config:
  • Authentification par mot de passe Non
  • PermitRootLogin Non
• Limiter les tarifs SSH Connect avec iptables ( http://www.debian-administration.org/articles/187 )

Il existe un certain nombre de bonnes suggestions ici. Je suggère respectueusement que trois choses devraient rendre cela relativement sûr:

1. Exécutez le sshd sur un port haut aléatoire. Les bots ne recherchent généralement que le port 22 et les variations du port 22 comme 2222.
2. Désactivez l'authentification par mot de passe dans la configuration sshd:

UsePAM no

3. Authentifiez-vous uniquement avec ce site via des paires de clés SSH pré-partagées. Man sur ssh-keygen pour commencer avec l'authentification basée sur PKI.

J'espère que cela t'aides.

J'ai toujours été un grand fan de CSF / LFD qui peut bloquer les adresses IP des personnes qui essaient de forcer la force, de scanner les ports et d'autres options. C'est fondamentalement un énorme perl-wrapper pour les tables IP, mais le fichier de configuration n'est pas difficile à lire et la documentation n'est pas mauvaise.

Vous pouvez également consulter sshguard. Je ne l'ai pas utilisé mais j'ai entendu de bonnes choses.

Sources:
http://isc.sans.edu/diary.html?storyid=9370

http://www.sshguard.net/

http://www.sshguard.net/docs/faqs/

"Sshguard surveille les serveurs à partir de leur activité de journalisation. Lorsque les journaux transmettent que quelqu'un fait une mauvaise chose, sshguard réagit en le bloquant un peu. Sshguard a une personnalité délicate: lorsqu'un méchant insiste dérange votre hôte, il réagit plus ferme et plus ferme. "

J'ai un serveur SSH connecté à Internet sur le port par défaut et je n'ai jamais rencontré de problèmes ..

• tcp_wrappers (ie. hosts.allow hosts.deny) pour SSH .. Je ne pense pas qu'il existe un SSH qui ne dispose pas de support compilé
• iptables ceci en conjonction avec tcp_wrappers a éliminé environ 99% de mes analyses de ports aléatoires / tentatives de bruteforce .. le seul problème est que vous devez savoir d'où vous allez vous connecter afin d'autoriser ces plages IP / IP ... Je l'ai simplement fait une recherche sur les fournisseurs populaires de ma région pour voir leurs plages d'adresses IP et autoriser celles-ci .. la plupart des analyses semblent provenir de pays lointains :)
• PermitRootLogin sans mot de passe (c'est-à-dire uniquement les paires de clés RSA / DSA qui sont chiffrées avec une phrase de passe) fonctionne à merveille pour les tâches automatisées .. lorsque je me connecte pour interagir, j'utilise évidemment mon compte (normal) qui est configuré avec l'accès sudo
• sudoers
• mises à jour constantes .. Je mets à jour cette boîte fréquemment avec toutes les mises à jour de sécurité / critiques
• changements de mot de passe / phrase de passe
• exécutez chkrootkit de temps en temps pour voir si j'ai des problèmes .. (il y en a plusieurs qui remplissent cette fonction)

J'espère que cela aide!

Il existe une meilleure façon de le faire, l'utilisation de fail2ban signifie que vous devez ajouter une application et qu'elle fonctionne au niveau de la couche application.

Si vous utilisez iptables, il est plus efficace car il fonctionne au niveau de la couche réseau et vous n'avez pas besoin d'installer une application supplémentaire.

Utilisez le module récent iptables http://www.snowman.net/projects/ipt_recent/

iptables -N SSHSCAN
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSHSCAN
iptables -A SSHSCAN -m recent --set --name SSH
iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 3 --name SSH -j LOG --log-level info --log-prefix "SSH SCAN blocked: "
iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 3 --name SSH -j DROP
iptables -A SSHSCAN -j ACCEPT

Une option (à utiliser en plus d'autres mesures de sécurité) consiste à écouter sshd sur un port autre que 22. Je ne l'ai pas essayé moi-même, mais je l'ai entendu dire qu'il réduit le nombre d'attaques par force brute pure par des bots.

Je dois souligner que ce n'est pas une vraie sécurité, cela réduit simplement le nombre d'attaques automatisées par force brute. Trop de travail pour vérifier chaque port, je suppose.

Quelque chose qui n'est pas mentionné ici et qui devrait vraiment limiter l'accès via le pare-feu. Cela ne convient pas à toutes les situations, mais si vous vous connectez à l'hôte à partir d'un emplacement cohérent avec une IP statique, vous pouvez simplement bloquer SSH entièrement, sauf sur cette IP. Cela empêchera les intrus d'entrer. Comme je l'ai mentionné cependant, cela ne convient pas toujours à toutes les situations, surtout si votre adresse IP est dynamique et change souvent.

DenyHosts, http://denyhosts.sourceforge.net/ , est un bon projet avec lequel j'ai eu de la chance. Si vous configurez denyhosts pour qu'il se synchronise, il téléchargera de nouvelles adresses IP à ajouter à une liste d'interdiction qui a dû forcer d'autres systèmes à l'aide de denyhosts. Il expire également les adresses IP qui n'ont pas essayé de forcer la force depuis un certain temps.

L'utilisation de l'authentification par clé publique et la désactivation de la journalisation des mots de passe est probablement la meilleure chose que vous puissiez faire. Vainc toutes les attaques par force brute.

Ce qui a été efficace pour moi:

1. Comme d'autres l'ont dit, pas de connexion root, PasswordAuthentication défini sur no (uniquement connexion avec clés) dans sshd_config

2. Seuls un ou deux utilisateurs sont autorisés à se connecter via ssh et ils ont des noms quasi-obscurs qui ne figurent pas sur les listes de noms d'utilisateurs des outils de force brute courants (c'est-à-dire pas "admin" ou "apache" ou "web" ou " johnny ")

3. Règles de pare-feu restrictives (en gros, tout est bloqué sauf mon port de service et ssh). Je restreins même le ping, pour conjurer les analyses les plus grossières (au grand dam de mon partenaire).

4. Sur mon hébergeur, je restreins l'accès à quelques adresses IP spécifiques - mais cela ne semble pas être une option pour vous. Je ne peux certainement pas le faire moi-même sur tous nos hôtes. Vous voudrez peut-être aussi vous pencher sur le "port-knocking".

5. Et mon préféré: le module de réponse active OSSEC pour bloquer un certain nombre de conditions de force brute et des alertes sur d'autres erreurs également. Il détecte x connexions non valides en y quantité de temps, puis les bloque (via une commande de suppression de pare-feu iptables) pendant une certaine période de temps. Je bloque depuis environ 12 heures maintenant pour le plaisir. :)

Une chose que je fais ici pour m'assurer de ne pas trop bloquer la mauvaise chose, c'est que dans /etc/ossec.conf, je règle la réponse active à un niveau élevé (qui n'existe pas dans la configuration par défaut), puis passer par le sshd_rules.xml et définir les règles que je veux bloquer à ce niveau et modifier les seuils de blocage par rapport à l'alerte selon les besoins.

Si vous exécutez Apache, vous pouvez également bloquer les éléments qui violent les règles d'Apache. Je ne bloque pas ces derniers juste à cause du problème NAT, je veux penser à bloquer une université entière ou quelque chose. :) De plus, vous pouvez écrire des règles personnalisées pour bloquer certaines conditions dans les fichiers journaux, ce qui peut être très utile.