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 😉
7 Commentaires
Recevoir les commentaires par email
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 😀
++
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é… 😉
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.
++
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)
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
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
[…] vous aviez changé le port d’ssh, vous devez alors entrer la commande […]
Trackbacks
-
Réparer ssh : WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! dit :
16 juin 08 à 22:44
URL de trackback: https://www.billyboylindien.com/securite/log-ssh-et-bruteforce-iptables.html/trackback/[…] vous aviez changé le port d’ssh, vous devez alors entrer la commande […]