Question Des centaines de connexions ssh échouées


Chaque nuit, je reçois des centaines, voire des milliers de connexions ssh échouées sur mon serveur RedHat 4. Pour des raisons de pare-feu provenant de sites distants, je dois utiliser le port standard. Y a-t-il quelque chose que je devrais faire pour bloquer cela? Je remarque que beaucoup viennent de la même adresse IP. Ne devrait-il pas être arrêté après un certain temps?


76
2018-06-02 16:18


origine




Réponses:


Vous pouvez utiliser iptables pour limiter le nombre de nouvelles connexions entrantes vers le port SSH. Il faudrait que je voie la totalité de votre configuration iptables pour pouvoir vous donner une solution clé en main, mais vous parlez essentiellement d'ajouter des règles telles que:

iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 5 --name SSH --rsource -j DROP 
iptables -A INPUT -p tcp --dport 22 -m recent --set --name SSH --rsource -j ACCEPT 

Ces règles supposent que vous acceptez les connexions ESTABLISHED plus tôt dans la table (afin que seules les nouvelles connexions respectent ces règles). Les nouvelles connexions SSH respecteront ces règles et seront marquées. En 60 secondes, 5 tentatives d'une même adresse IP entraîneront la perte de nouvelles connexions entrantes à partir de cette adresse IP.

Cela a bien fonctionné pour moi.

Edit: Je préfère cette méthode à "fail2ban" car aucun logiciel supplémentaire ne doit être installé, et se produit totalement en mode noyau. Il ne gère pas l'analyse des fichiers journaux comme "fail2ban", mais si votre problème ne concerne que SSH, je ne voudrais pas utiliser un mode utilisateur nécessitant une installation logicielle et plus complexe.


63
2018-06-02 16:25



J'aime cette solution et je prévois de la mettre en place ce soir, une fois les feux allumés d'aujourd'hui. - MattMcKnight
Cela ralentit les attaques et je le recommande, mais comme il existe des botnets d'analyse distribués, ce n'est pas une panacée. Il restera toujours des connexions non valables à partir de botnets exécutant des analyses distribuées contre vous. Il n’ya pas vraiment grand-chose que vous puissiez faire à ce sujet, à moins d’une sorte de mécanisme de "portage à la volée" permettant d’activer à distance le port SSH lorsque vous souhaitez entrer. - Evan Anderson
+1 pour la suggestion de "port knock" de @ Evan. Quelques infos: linux.die.net/man/1/knockd . Mais ne le faites pas comme la page de manuel (c’est-à-dire l’ajout / la suppression de règles iptables), mais utilisez plutôt -m condition iptables correspond à la place. - pepoluan
n’avez-vous pas besoin de --dport 22 dans ces règles pour qu’elles ne soient appliquées qu’au trafic SSH? - clime
@clime - Oui. Difficile de croire que cela a été ici 2 ans et demi et personne n'a remarqué! Bonne prise. - Evan Anderson


fail2ban peut vous aider en bloquant les adresses IP avec trop de tentatives de connexion infructueuses.


38
2018-06-02 16:20



je n'aime pas les outils / scripts qui lisent les journaux et émettent des commandes pour le compte de l'utilisateur sysadmin - asdmin
@asdmin, oui, surtout quand ils avoir une si belle expérience ... - maxschlepzig


Si vous le pouviez, je vous recommanderais d'utiliser un port non standard pour SSH (par exemple, le port 10222), mais puisque vous avez mentionné que vous ne pouviez pas le faire, je vous recommanderais d'utiliser un outil tel que DenyHosts.

http://denyhosts.sourceforge.net/

Excellent package, facile à installer et à configurer.


25
2018-06-02 17:16



Je ne sais pas pourquoi les gens votent pour cela; SSH utilise un port standard 22. Cela signifie que lorsque vous êtes sur un réseau étranger, vous ne comptez pas sur eux pour ouvrir un port non standard via le pare-feu sortant. La solution réelle à ce problème est documentée ci-dessus: restreignez le nombre de connexions répétées via votre pare-feu entrant ou désactivez les connexions par mot de passe. - Andrew Taylor
OpenSSH 6.7 gouttes tcpwrappers supporte, qui est ce que denyhosts utilise. - Zoredache


Bien qu'il puisse être intéressant de pouvoir ssh dans votre système à partir d'emplacements arbitraires sur Internet, il existe des systèmes automatisés d'attaque de mots de passe qui se verrouillent sur un port ssh ouvert et appliquent diverses attaques de compte joe et de dictionnaire contre votre système. Cela peut être compliqué à lire dans votre résumé journal quotidien et est une perte de votre bande passante.

Si vous avez un serveur Web sur le même système, vous pouvez utiliser les wrappers php et tcp pour limiter le trafic entrant ssh aux systèmes connus, et vous donner une clé de porte arrière pour vous autoriser à accéder à partir de systèmes arbitraires sur Internet.

Voici comment vous le faites:

refuser toutes les connexions ssh dans /etc/hosts.deny:

# /etc/hosts.deny fragment
sshd:  all

Autorisez les systèmes connus par IP dans /etc/hosts.allow, plus ajoutez un fichier pour un accès temporaire:

# /etc/hosts.allow fragment
sshd:  10.0.10.2     # some system
sshd:  172.99.99.99  # some other system
sshd:  /etc/hosts.allow.temporary-sshd-access

Créez un fichier php sur votre serveur web et donnez-lui un nom non évident comme my-sshd-access.php:

<?php
function get_ip()
{
    return getenv("REMOTE_ADDR"); 
}

?>

<?php
$out='/etc/hosts.allow.temporary-sshd-access';
$log='/var/log/sshd-access-addition-log';

print "Was:";
readfile($out);
print "<br>";
$ip=get_ip();
$fp=fopen($out,"w");
fputs($fp,$ip);
fclose($fp);

$lfp=fopen($log,"a");
fputs($lfp,$ip);
fputs($lfp,"n");
fclose($lfp);

print "Wrote: ";
readfile($out);
?>

Pardonnez le code php - je l'ai glissé d'un autre endroit, afin qu'il puisse probablement être nettoyé un tas. Il ne fait qu'ajouter l'adresse IP du système qui y accède au fichier /etc/hosts.allow.temporary-sshd-access, qui est lu par sshd (en raison de son inclusion par /etc/hosts.allow) au moment de la connexion. .

Maintenant, lorsque vous êtes sur un système Web arbitraire et que vous voulez utiliser SSH sur ce système, utilisez d'abord un navigateur Web et cliquez sur ce fichier (ou utilisez wget ou équivalent):

$ wget http://your.system.name/my-sshd-access.php

Vous devriez maintenant pouvoir vous connecter à votre système. Si c'est quelque part où vous ferez souvent des ssh, il serait trivial de lire le contenu du fichier /etc/hosts.allow.temporary-sshd-access et d'ajouter définitivement l'adresse IP à / etc / hosts. permettre.


15
2018-06-02 17:07



Pour rendre cela plus sûr, exécutez cette page sur https. - Robert Munteanu
Si vous modifiez le script afin qu'il ne génère pas le contenu du fichier "adresse IP temporaire autorisée", aucun renifleur potentiel ne sera reniflé. Ensuite, vous pouvez l'exécuter sur http au lieu de https. - Barry Brown
"L'adresse IP temporaire autorisée" est toujours celle du demandeur (c'est-à-dire la vôtre). Je ne pense pas que cela compte d'une manière ou d'une autre. Https signifie que l'URL demandée est cryptée, ce qui signifie qu'il n'est pas trivial de la renvoyer hors du réseau. - David Mackintosh
Cela ne fonctionnera pas si vous êtes sur un réseau qui proxy les connexions HTTP mais votre route directe vers Internet passe par une sortie différente. - Andrew Taylor
OpenSSH 6.7 gouttes tcpwrappers supporte, qui est ce qui est utilisé dans votre réponse. - Zoredache


Vous voudrez peut-être regarder nier les hôtes ainsi que.

Pour votre information: OpenSSH 6.7 gouttes tcpwrappers supporte, ce qui signifie que denyhosts n’est probablement pas la solution pour les nouvelles installations.


9
2018-06-02 16:23





Faites-vous une faveur et désactivez le mot de passe de connexion. Utiliser exclusivement des clés d'authentification (google ssh-keygen par exemple) - Exemple: http://www.puddingonline.com/~dave/publications/SSH-with-Keys-HOWTO/document/html/SSH-with-Keys-HOWTO-4.html ) Votre serveur sera plus sécurisé, vous vous y connecterez plus confortablement (vérifiez ssh-agent, ssh-add, keychain) et vous ne serez plus victime d'attaques par force brute de ssh.


8
2017-08-17 22:08





une autre solution consiste simplement à déplacer ssh vers un autre port. ces vers sont assez stupides.


2
2018-06-02 16:28



L’affiche originale indiquait qu’il devait fonctionner sur le port standard. - kbyrd
désolé, je dois lire les questions plus attentivement :) - disserman
Je dois être d'accord ... Mon SSH fonctionne sur des ports "alternatifs" et cela fait une différence énorme dans les journaux. Les vers sont à peu près aussi intelligents qu'une brique, cela fonctionne donc bien contre les scripts d'automatisation stupides; pas si bien contre les assaillants humains. Pourtant, les journaux ont le son béni de silence en eux ... - Avery Payne


Une autre option pourrait consister à exiger que toutes les connexions SSH soient vérifiées par un certificat et suppriment les mots de passe.

J'avais l'habitude d'utiliser Denyhosts, mais je me suis rendu compte que je ne me connectais régulièrement qu'à distance depuis un petit nombre d'endroits; j'ai donc bloqué toutes les connexions du port 22, sauf de partout ailleurs, et j'utilisais le port frappant pour que je puisse me connecter n'importe où avec mon ordinateur portable. .


2
2018-06-03 00:51





Toute solution impliquant le blocage automatique des adresses IP après plusieurs défaillances introduit un risque d'attaque par déni de service. Tant qu'une bonne politique de mot de passe est en place pour réduire l'efficacité des attaques par force brute ou par dictionnaire, je ne m'inquiéterais pas trop à leur sujet.

Si vous limitez les utilisateurs / groupes à ceux qui devraient être autorisés à ssh en premier lieu et désactivez la connexion en tant que root, vous devez être suffisamment sécurisé. Et, si cela ne suffit pas, il existe toujours une authentification par clé.


1
2018-06-02 17:03





Honnêtement, si vous devez exécuter SSH (et sur le port 22), vous ne pouvez pas les éviter. Si vous devez accepter les mots de passe, votre situation est encore pire.

Votre meilleur choix est de configurer votre logiciel d'analyse de journal pour exclure les journaux SSH. Exécutez ensuite une instance distincte pour consulter uniquement les journaux SSH et utilisez procmail pour filtrer les tentatives infructueuses. Vous pouvez même écrire des scripts pour rechercher les connexions réussies à partir d'adresses IP avec plusieurs tentatives infructueuses.

Il n'y a aucun moyen d'empêcher les gens de tester votre serveur SSH. Denyhosts, fail2ban et l'exemple iptables fonctionneront jusqu'à un certain point, mais avec le risque supplémentaire de bloquer accidentellement des utilisateurs légitimes. La meilleure méthode consiste à l’absorber et à essayer d’automatiser le processus d’analyse de journaux afin de réduire le temps nécessaire pour y réfléchir.


1
2017-08-17 22:51





Quand vous dites que votre compte Red Hat échoue, quel type de pare-feu est installé derrière et combien de personnes doivent y entrer. Je suggère que si vous le souhaitez, vous souhaitez limiter les tentatives au niveau du pare-feu avant qu’elles ne se rapprochent de votre serveur actuel.

Si vous pouvez limiter la plage d'adresses IP qui ont légitimement besoin d'un accès, vous devriez pouvoir configurer une liste d'accès sur le pare-feu. Si vous pouvez limiter le trafic au niveau du pare-feu, je vous suggère d’examiner les systèmes d’intrusion réseau, car il semble que votre serveur soit ciblé par quelque chose.


0
2018-06-02 17:28