Forum général.général [SSH] Comment bannir un hôte insistant ?

Posté par  (site web personnel) .
Étiquettes : aucune
0
23
mai
2005
Bonjour,

Ce n'est pas la première fois que ça m'arrive, j'ai retrouvé dans les logs d'une de mes machines les lignes suivantes (extrait):

[...]
May 22 17:58:47 itchy sshd[8334]: Invalid user temp from 203.237.221.xxx
May 22 17:58:50 itchy sshd[8338]: Invalid user eric from 203.237.221.xxx
May 22 17:58:53 itchy sshd[8342]: Invalid user staff from 203.237.221.xxx
May 22 17:58:57 itchy sshd[8346]: Invalid user bb from 203.237.221.xxx
May 22 17:59:00 itchy sshd[8350]: Invalid user maggie from 203.237.221.xxx
May 22 17:59:04 itchy sshd[8374]: Invalid user rock from 203.237.221.xxx
May 22 17:59:07 itchy sshd[8440]: Invalid user sandra from 203.237.221.xxx
May 22 17:59:11 itchy sshd[8444]: Invalid user kim from 203.237.221.xxx
May 22 17:59:14 itchy sshd[8448]: Invalid user recruit from 203.237.221.xxx
May 22 17:59:18 itchy sshd[8452]: Invalid user alina from 203.237.221.xxx
May 22 17:59:21 itchy sshd[8456]: Invalid user dana from 203.237.221.xxx
[...]

Ça ressemble à une sorte de vers qui tenterait de s'introduire sur la machine (comme je le disais plus haut, ça fait plusieurs mois que je vois régulièrement ça dans les logs de différentes machines que j'administre sans réellement savoir de quoi il s'agit).

La question est simple. Existe-t-il un moyen (via la config d'OpenSSH ou via iptables) de bannir une machine qui insisterait lourdement pour se connecter sur mon serveur SSH). L'idéal serait que, par exemple, après 3 tentatives de login infructueuses, la machine distante ne puisse plus se connecter (pendant une période limitée dans le temps).

J'utilise la directive "AllowUsers" dans mon sshd_config pour éviter quelques problèmes mais j'aimerai bien "blinder" un peu plus le bouzin.

Merci pour vos précieux conseils.

  • # Iptables

    Posté par  (site web personnel) . Évalué à 2.

    Allez, basiquement un " iptables -A INPUT -s 203.237.221.xxx -j DROP ", tu pourrais restreindre au port SSH, mais en même temps, le gars va essayer toute la panoplie sur Apache, Samba, etc, alors ça ne mange pas de pain.

    • [^] # Re: Iptables

      Posté par  (site web personnel) . Évalué à 2.

      Je n'ai ces requêtes qu'en direction du port 22 et pas ailleurs. Ça se fait par vagues.

      Si tu regardes les logs, il y a une tentative environ toutes les 3-4 secondes avec, à chaque fois, un nom de login différent (et parfois root apparait plusieurs fois de suite).

      Après s'être excité pendant quelques minutes avec toute une panoplie de logins, pouf, disparition, la machine distante n'envoie plus de requêtes bidons.

      Pour moi c'est soit un vers ou un Jean-Kevin qui est content d'avoir trouvé un serveur SSH en scannant une plage IP et qui lance un soft pour essayer de s'introduire sur ma bécane.

      Ce que j'aimerai c'est un truc automatique (et non permanent) parce que je vais pas rester éveillé 24/7 pour matter mes logs et voir si quelqu'un joue le boulet de service. Je vais creuser du côté d'iptables et voir ce qu'il est possible de faire (sachant que, côté sshd, les options de configuration semblent plutot limitées pour ce que j'aimerai faire).

      • [^] # Re: Iptables

        Posté par  (site web personnel, Mastodon) . Évalué à 2.

        pareil, j'ai la meme chose sur ma passerelle (debian sarge) !

        j'utilise logcheck qui m'envoi un mail tous les jours et me signale les tentatives comme celles ci!

        j'ai développer un script (un peu buggé mais fonctionnel) http://kolter.free.fr/blog/index.php?2005/03/31/5-sshlogs-01-is-out(...) qui me permet de recup toutes les ip de ses tentatives d'intrusions et après trois solutions :

        - soit tu fais comme dis précédemment , tu fais une regle iptables par adresse !
        - soit tu utilise les /etc/hosts.deny et tu rajoute une ligne comme "sshd: 203.237.221.xxx"
        - soit tu utilises shorewall et tu mets la liste des IP dans /etc/shorewall/blacklist (ce que je fais) !!

        après tout est automatisable !!!

        à noté que de temps en temps quand c'est possible j'essaye de remonter à la source de l'attaque et c'est ce que j'ai fais ce WE, j'ai envoyé un mail au mec qui me scannait ou qui a une machine infecté (merci host, dig, whois) !!! j'attends sa réponse sinon c'est abuse@sonFAI !

        M.

  • # ssh brute force scan

    Posté par  (site web personnel) . Évalué à 1.

    http://isc.sans.org/diary.php?date=2005-04-29(...)

  • # module iptables

    Posté par  . Évalué à 3.

    Tout est expliqué sur http://blog.andrew.net.au/2005/02/17#ipt_recent_and_ssh_attacks(...)

    Il est possible de spécifier la durée pendant laquelle une erreur de mot de passe provoque un bloquage de l'ip, le nombre d'essai infructueux autorisés, de faire une liste d'exclusion du filtre (pour des machines auxquelles on fait confiance), etc..

    Voici le type de syntaxe :

    iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
    iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_WHITELIST
    iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j ULOG --ulog-prefix SSH_brute_force
    iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP

  • # changement de port

    Posté par  . Évalué à 1.

    De mon coté ça fait un moment que j'ai modifié le port SSH et j'ai plus ce soucis :o

    • [^] # Re: changement de port

      Posté par  (site web personnel) . Évalué à 2.

      Tu t'es fait moinsser (initialement), et je trouve ça quelque peu injuste. Ce n'est bien sûr pas une très belle ou très bonne solution, mais c'est très efficace ! J'ai des machines avec SSH sur port standard, avec des scans quotidiens, et j'ai des machines avec SSH sur un port non standard, et absolument aucun scan en plusieurs mois.

      Ceci dit, ça ne fait pas de mal d'ajouter un PermitRootLogin no, ça fait prendre de meilleures habitudes.

  • # Merci !

    Posté par  (site web personnel) . Évalué à 2.

    Merci à tous pour votre aide précieuse !!!

    En plus d'utiliser dans mon sshd_config:
    PermitRootLogin no
    AllowUsers xxxx
    PasswordAuthentication no

    Je vais regarder du côté du module iptables "recent" (merci symoon). Comme j'utilise Shorewall je suis tombé sur cette page [1] qui explique comment implémenter la technique du "port-knocking" et qui semble intéressante...

    Sinon je vais m'en tenir à ce que je souhaitais faire à l'origine, à savoir la méthode que me pointe symoon (après adaptation pour Shorewall).

    Encore un grand merci pour votre aide !


    [1] - http://www.shorewall.net/PortKnocking.html(...)

  • # port knocking

    Posté par  (site web personnel) . Évalué à 1.

    http://www.aplawrence.com/Security/sshloginattack.html(...)

    en résumé laisser passer le traffic sur un port (ici le service ssh port 22) que quand le user en a besoin.
    La demande se fait par une telnet sur un port définit à l'avance, et un autre port permet de refermer l'access (via des règles iptables)

    Avantage peut s'appliquer a beaucoup de service dit sensible, comme une webcam sur le web ou ce genre de truc, ca évite que tout le monde y est access. (les flux ne possedent pas tjs de protocole qui accepte une identification -> limitant sur une webcam privée pour la famille)

    Un script un peu plus complexe autorisera que l'IP ayant fait la demande ( par contre je suis pas un expert de iptable donc voila ..)

    Bon c'est de l'obscurantisme donc faut pas se fier c'est pas une technique fiable a 100% mais ca permet d'eviter de remplir les logs, et de voir les attacks plus sérieuses.

    Sinon j'ai eu le meme problème sur mon serveur et j'ai simplement "déplacer" le port ca marche ^^ (mais bon scanner toute les ports + identification du service associé et le service sera trouvé.)

    http://www.theatre-eibel.fr http://www.isc2chapter-yorkshire.co.uk

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.