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:
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.
-m conditioniptables match.
fail2ban peut vous aider avec ceci en bloquant les adresses IP avec trop de tentatives de connexion infructueuses.
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.
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.
Vous voudrez peut-être aussi regarder denyhosts .
Pour votre information: OpenSSH 6.7 supprime le support de tcpwrappers , ce qui signifie que denyhosts n'est probablement pas la solution pour les nouvelles installations.
Faites-vous une faveur et désactivez le mot de passe de connexion. Utilisez 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 (consultez ssh-agent, ssh-add, trousseau) et vous ne serez plus victime d'attaques par force brute de ssh.
une autre solution consiste simplement à déplacer ssh vers un autre port. ces vers sont assez stupides.
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. .
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é.
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.
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.
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).
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 :)
Une autre option similaire à DenyHosts est sshutout http://www.techfinesse.com/sshutout/sshutout.html.