Log ssh et bruteforce, iptables, interdire root

L’emplacemment de vox log ssh est /var/log/auth.log.

Pour avoir une petite analyse, faites un petit

nano /var/log/auth.log

Si comme moi vous avez de jolis log du genre:

Sep 3 16:19:29 sd-4145 sshd[23909]: Illegal user aleksandra from 88.191.11.198
Sep 3 16:19:29 sd-4145 sshd[23911]: Illegal user aleksandra from 88.191.11.198
Sep 3 16:19:29 sd-4145 sshd[23913]: Illegal user aleksandra from 88.191.11.198
Sep 3 16:19:30 sd-4145 sshd[23929]: Illegal user alenka from 88.191.11.198
Sep 3 16:19:30 sd-4145 sshd[23931]: Illegal user alenka from 88.191.11.198
Sep 3 16:19:30 sd-4145 sshd[23933]: Illegal user alenka from 88.191.11.198

Ba inquietez vous, on essai de vous brutforcer, donc dans ce cas, un petit abuse est de rigueure pour l’ip en question.

On peut aussi parer à ce genre d’attaque par une petit regle iptables:

iptables -I INPUT -s 88.191.11.198 -j DROP

ou:

iptables -A INPUT -p tcp –dport ssh -m recent –update –seconds 60 –hitcount 4 –name SSH -j DROP
iptables -A INPUT -p tcp –dport ssh -m recent –set –name SSH
iptables -A INPUT -p tcp –dport ssh -j ACCEPT

Qui bloque celui qui tente de se connecter plus de 4 fois en 60 sec en ssh ;-)

Une autre très bonne solution est de changer le port de ssh

nano /etc/ssh/sshd_config

Et changer la ligne port 22
et relancez ssh:

/etc/init.d/ssh reload

Il y a aussi les trucs du genre failtoban.

Sans oublier biensur de ne pas autoriser l’acces ssh par root :
dans /etc/ssh/sshd_config

PermitRootLogin no  #changez yes en no

et relancez ssh:

/etc/init.d/ssh reload

Voila ;-)

Réseaux sociaux :
  • Bluegger
  • Blogasty
  • Fuzz
  • Scoopeo
  • del.icio.us

7 commentaires

  1. admin nous disait le September 16th, 2006 at 12:56 :

    Depuis que j’ai changer mon port ssh: 0 scans

    Résultats failtoban installé pour rien mais on sait jamais desfois que quelqu’un voudrais scanner mon port ssh avant :D

    ++

  2. skool nous disait le February 11th, 2007 at 15:28 :

    Et ca bannit combien de temps la regle iptables ? 60 secondes ?

    En tout cas, merci du tuyau, j’en avasi marre de me faire bruteforcé… ;)

  3. admin nous disait le February 11th, 2007 at 15:34 :

    Oui 60 secondes.
    Et c’est RADICAL

    99% de scan en moin.
    Rien que le fait de changer de port ca te change la vie en même temps.

    ++

  4. skool nous disait le February 11th, 2007 at 16:12 :

    Bon, j’ai un peu adapté les regles iptables pour pouvoir régler le temps de bannissage de l’ip qui essaye de se connecter 4 fois en 60 secondes

    le principe est de créer une table de bannissage, au bout de 4 tentatives, on mets une entrée dans la table de bannissage, puis à la suivante, si c’est loggé en table de bannissage, alors on bloque pendant x secondes

    en concret, ca donne à peu pres cà :
    -N SSH_BAN
    -A SSH_BAN -p tcp -m tcp -m recent -i eth0 --dport 22 --update --seconds 300 --name SSH_BAN -j DROP
    -A SSH_BAN -p tcp -m tcp -m recent -i eth0 --dport 22 --set --name SSH_BAN
    -A INPUT -p tcp -m tcp -m recent -i eth0 --dport 22 --update --seconds 60 --hitcount 4 --name SSH -j SSH_BAN
    -A INPUT -p tcp -m tcp -m recent -i eth0 --dport 22 --set --name SSH

    en ajoutant /sbin/iptables au début de chaque ligne pour l’utiliser dans un script pure (moi c’est un fichier de regles, utilisé en parametres d’un autre script..)

    et techniquement, ca bannit 5 min ceux qui tentent de se logger 4 fois en 60 secondes, puis 2 autres fois en 5 min (a verifier, je ne suis pas sur à 100% de la synchro, mais en tout cas, c’est au bout de 6 fois)

  5. Benjamin L nous disait le October 5th, 2007 at 7:50 :

    Hum… Ce n’est pas très… « rigolo ». :p

    J’ai utilisé les dernières règles IPtables indiquées dans les commentaires, et depuis je n’arrive plus à me conecter moi-même en SSH. ôO
    Je me connectes habituellement avec une clé DSA, mais là… rien. Au bout de deux minutes : connexion refusée, et rien de plus.

    C’est vexant, et je vais me faire chier pour corriger ça. :p

  6. Benjamin L nous disait le October 5th, 2007 at 15:08 :

    Bon, mon problème est résolu. J’ai finalement opté pour une connexion uniquement à base de clé DSA ; ça règle aussi le problème de brute-force, après-tout. :p

  7. Réparer ssh : WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! nous disait le June 16th, 2008 at 22:44 :

    [...] vous aviez changé le port d’ssh, vous devez alors entrer la commande [...]

Commenter