Des centaines de connexions ssh échouées


81

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?

Réponses:


67

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 offrir une solution clé en main, mais vous parlez essentiellement de 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 passe 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 l'installation de logiciels et plus complexe.


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

2
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 des botnets exécutant des analyses distribuées contre vous. Il n'y a pas vraiment grand-chose que vous puissiez faire à ce sujet, à moins d'une sorte de mécanisme de "portage à la volée" permettant de faire monter le port SSH à distance lorsque vous souhaitez entrer.
Evan Anderson

1
+1 pour la suggestion de "port knock" de @ Evan. Quelques informations: linux.die.net/man/1/knockd . Mais ne le faites pas à la manière de la page de manuel (c.-à-d. Ajouter / supprimer des règles iptables), mais plutôt utiliser -m conditioniptables match.
pepoluan

2
n'avez-vous pas besoin de --dport 22 dans ces règles pour qu'elles s'appliquent uniquement au trafic ssh?
Clime

2
@clime - Oui. Difficile de croire que cela a été ici 2 ans et demi et personne n'a remarqué! Bonne prise.
Evan Anderson

39

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


11
Je n'aime pas les outils / scripts qui lisent les journaux et émettent des commandes pour le compte de l'utilisateur sysadmin
asdmin

2
@asdmin, oui, surtout quand ils ont une aussi belle
performance

25

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.


6
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 vraie solution à 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

1
OpenSSH 6.7 supprime le support de tcpwrappers , ce que denyhosts utilise.
Zoredache

15

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 comptes joe et de dictionnaires sur votre système. Cela peut être compliqué à lire dans votre résumé journal quotidien et constitue 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 permettre d'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 (du fait 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'ing, 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. Autoriser.


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 en attente ne sera capturé. 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 supprime le support de tcpwrappers , qui est utilisé dans votre réponse.
Zoredache



2

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


3
L’affiche originale indiquait qu’il devait fonctionner sur le port standard.
kbyrd

1
désolé, je dois lire les questions plus attentivement :)
disserman

1
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 du silence en eux ...
Avery Payne

..c'est pas que les bots sont "stupides", c'est qu'ils sont conçus pour chercher des fruits bas. Déplacer le port SSH est donc dans le style de .. Gardez vos fruits du sol.
Elrobis

2

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 une poignée 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. .


1

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 pour elles.

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 y a toujours une authentification par clé.


1

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 journaux 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 des journaux afin de réduire le temps nécessaire pour y réfléchir.


0

Quand vous dites que votre compte Red Hat échoue, quel type de pare-feu se trouve 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'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 semblerait que votre serveur soit ciblé par quelque chose.


0

La plupart des hôtes Web utilisent APF + BFD pour bloquer par ip les connexions SSH échouées. De nos jours, il existe un CSF (pare-feu Configserver) qui inclut un outil appelé LFD qui fait la même chose, et plus encore, y compris le blocage des IP de certains pays pour lesquels vous ne souhaitez pas accéder à votre serveur (par exemple, la Corée, la Chine, etc.), où 99% de mes sondes SSH semblent provenir de).



0

Si vous avez besoin de traiter ce problème sur plusieurs hôtes, vous pouvez consulter OSSEC: http://www.ossec.net/main/ossec-architecture

Cela vous permettra de configurer plusieurs agents à partir d'un emplacement centralisé pour répondre automatiquement aux attaques par force brute (ainsi que tout autre modèle que vous pouvez extraire des journaux).

Très beau logiciel :)


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.