> Sshd ne bloque pas l'IP après un nombre x d'essais qui ont échoués ?
Et comme ça avec une IP spoofée tu peux te chopper un magnifique DOS. Si l'attaquant sait quelle est ton IP, tu ne pourras même plus te connecter à ton serveur! AMHA c'est une stratégie dangeureuse si implémentée sans précaution.
Il y a plusieurs solutions pour résoudre le petit désagrément des vilains bots:
- changer le port d'écoute de sshd (les bots pour ssh n'attaquent que le 22 la +part du temps)
- n'autoriser que les connections avec des clés valides (authorized_keys) depuis des machines connues (known_hosts)
- utiliser des mots de passes jetables (skey ou OPIE) très utile quand on se connecte depuis une machine que l'on ne connait pas (évidemment incompatible avec le known_hosts)
- désactiver la connection par mot de passe: PasswordAuthentication no
- comme indiqué + bas, utiliser Portknocking: http://www.portknocking.org/(...)
- enfin en dernier recours faire un script pour iptables qui bloque l'IP pendant un temps bien déterminé de façon à éviter le DOS. Mais je ne suis pas trop pour. :(
Sinon quelques conseils de bon sens:
- avoir évidemment des mots de passe à toute épreuve (y compris celle des Rainbow Tables C.f. http://passcracking.com/(...) Donc au minimum 20 caractères avec tous ceux que l'on utilise habituellement que pour les jurons. ;)
- éventuellement bloquer la connection à root sauf si on utilise des mots de passe jetables pour administrer la machine depuis une autre machine sans confiance. Auquel cas un su ou sudo mettrait toute la sécurité par terre si la machine est infectée par un logger.
- s'il s'agit d'une machine passerelle et que l'on a pas besoin de s'y connecter depuis un des réseaux, ne mettre sshd qu'en écoute sur l'autre adresse.
- vérifier les options de son sshd_config et surtout MaxAuthTries, PermitEmptyPasswords, UsePAM (dans ce cas voir aussi la config de PAM) et ne pas oublier de bloquer SSH1: Protocol 2
- et enfin si on est vraiment parano, utiliser Kerberos.
Finalement mettre un message d'interdiction des connections non authorisées dans /etc/ssh/banner. Les bots s'en foutent, mais si quelqu'un réussit à percer toutes les barrières précédentes, il ne pourra pas prétendre qu'il n'a pas vu l'interdiction d'entrer (pour le forensic).
[^] # Re: Machine infectée
Posté par Raoul Volfoni (site web personnel) . En réponse au journal une petite attaque. Évalué à 10.
Et comme ça avec une IP spoofée tu peux te chopper un magnifique DOS. Si l'attaquant sait quelle est ton IP, tu ne pourras même plus te connecter à ton serveur! AMHA c'est une stratégie dangeureuse si implémentée sans précaution.
Il y a plusieurs solutions pour résoudre le petit désagrément des vilains bots:
- changer le port d'écoute de sshd (les bots pour ssh n'attaquent que le 22 la +part du temps)
- n'autoriser que les connections avec des clés valides (authorized_keys) depuis des machines connues (known_hosts)
- utiliser des mots de passes jetables (skey ou OPIE) très utile quand on se connecte depuis une machine que l'on ne connait pas (évidemment incompatible avec le known_hosts)
- désactiver la connection par mot de passe: PasswordAuthentication no
- comme indiqué + bas, utiliser Portknocking: http://www.portknocking.org/(...)
- enfin en dernier recours faire un script pour iptables qui bloque l'IP pendant un temps bien déterminé de façon à éviter le DOS. Mais je ne suis pas trop pour. :(
Sinon quelques conseils de bon sens:
- avoir évidemment des mots de passe à toute épreuve (y compris celle des Rainbow Tables C.f. http://passcracking.com/(...) Donc au minimum 20 caractères avec tous ceux que l'on utilise habituellement que pour les jurons. ;)
- éventuellement bloquer la connection à root sauf si on utilise des mots de passe jetables pour administrer la machine depuis une autre machine sans confiance. Auquel cas un su ou sudo mettrait toute la sécurité par terre si la machine est infectée par un logger.
- s'il s'agit d'une machine passerelle et que l'on a pas besoin de s'y connecter depuis un des réseaux, ne mettre sshd qu'en écoute sur l'autre adresse.
- vérifier les options de son sshd_config et surtout MaxAuthTries, PermitEmptyPasswords, UsePAM (dans ce cas voir aussi la config de PAM) et ne pas oublier de bloquer SSH1: Protocol 2
- et enfin si on est vraiment parano, utiliser Kerberos.
Finalement mettre un message d'interdiction des connections non authorisées dans /etc/ssh/banner. Les bots s'en foutent, mais si quelqu'un réussit à percer toutes les barrières précédentes, il ne pourra pas prétendre qu'il n'a pas vu l'interdiction d'entrer (pour le forensic).