Sécurisation du serveur SSH contre le bruteforcing


14

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.


Réponses:


17

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.


2
J'utilise denyhosts, mais c'est à peu près la même chose que fail2ban afaik.
pfyon

Fail2Ban vous semble familier ... Je vais y jeter un œil.
Paul Peelen

1
+1 Fail2Ban, 5 tentatives infructueuses = bloc IP de 5 minutes. À moins que vous n'ayez un mot de passe ridiculement facile, il ne sera jamais forcé à 1 mot de passe par minute.
Chris S

@Chris S Oui, c'est l'un de mes favoris. Les script kiddies ne savent généralement pas comment gérer les délais d'attente ...
gWaldo

1
@gWaldo, le biais de confirmation va un long chemin dans la réécriture des choses que vous lisez pour dire ce que vous pensez déjà être vrai.
Chris S

7

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.


Très bonne réponse. Je suis totalement d'accord avec vous en gras ... donc la lettre combinée avec des mots de passe numériques. L'authentification par clé est un peu trop pour ce serveur ... mais une bonne idée. J'ai maintenant installé Fail2ban, il ne semble pas que je doive le reconfigurer et parce que ce petit serveur svn est à la maison, j'y ai facilement accès (étant donné qu'il se trouve à l'arrière de mon dressing = S) Thnx pour vos conseils!
Paul Peelen

1
Spamhaus publie une liste des réseaux de spammeurs connus. Il ne couvre pas les botnets, il est juste connu des spammeurs "professionnels": spamhaus.org/drop
Chris S


4

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

  1. 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.


2
Pour une solution à très faible stress, je seconde définitivement l'exécution de ssh sur un port non standard. D'après ce que j'ai vu, cela abandonnera les tentatives de connexions par force brute à votre serveur ssh d'un ordre de grandeur. Sur une période d'une semaine, l'un de mes serveurs (exécutant ssh sur un port standard) a reçu 134 tentatives de connexion invalides. Au cours de la même période, une instance virtuelle sur ce même serveur (exécutant ssh sur un port non standard) avait 0.
DF

1

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.


Savez-vous s'il existe un moyen d'être alerté (par exemple par e-mail) chaque fois qu'un scan de port est effectué sur le serveur?
Paul Peelen

1

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. "


Cela semble net ... je vais y jeter un œil. thnx
Paul Peelen

1

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!


1

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

0

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.


Je l'ai fait aussi, swiched au port 23. Principalement parce que j'avais un autre serveur sur le port 22 (que j'ai maintenant supprimé).
Paul Peelen

2
23 est un port réservé pour telnetcependant. Il est souvent préférable d'utiliser des ports non réservés, tels que> 60k. iana.org/assignments/port-numbers vous donne une liste des numéros de port réservés.
ℝaphink

Merci pour le conseil. Je n'utilise pas encore de principe sur cette machine, mais je changerai le port. J'ai une plage de ports entre 52000 et 59000 que j'utilise sur mes serveurs professionnels, en pensant à en utiliser de même pour celui-ci.
Paul Peelen

1
@Paul: I don't use te[l]net on this machine- continuez comme ça. Bien que vous souhaitiez un client telnet pour diverses raisons, il n'y a aucune raison d'exécuter un serveur telnet lorsque ssh est disponible. Les mots de passe en texte clair sur le fil sont incorrects .
mlp

0

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.


En général, j'accepte votre solution. Je crois que c'est la norme dans l'entreprise pour laquelle je travaille ... mais je ne pense pas que ce soit quelque chose pour moi. Le problème est que j'utilise principalement mon macbook pro depuis la maison (réseau local), depuis le travail (IP statique) ou en déplacement (en utilisant un modem 3G / iPhone). Pour le dernier, c'est un problème si je n'ai pas de VPN qui est trop exagéré, je suppose. Merci pour ta réponse.
Paul Peelen

0

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.


0

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.