Protéger son acces SSH
Par Dju » 10 mars 2010 (22:30) - Serveur
Lorsqu'on a un serveur en ligne 24h/24, il est obligatoire d'avoir un accès SSH pour pouvoir s'y connecter à distance et intervenir dessus.
De fait, il y aura toujours des petits malins pour s'amuser à aller scanner vos ports et essayer d'entrer sur votre machine.
La plupart du temps, la technique n'est pas très évoluée et les tentatives sont faites en brute-force, c'est à dire en essayant successivement des logins et mots de passe différents jusqu'à trouver le bon.
On se retrouve donc avec un fichier log de 3 km de long, ainsi qu'une certaine utilisation des ressources de la machine ainsi que de sa bande passante...
Bref, pas glop !
En premier lieu, on change généralement le port. il est par défaut à 22, et donc facile à identifier. Beaucoup de softs tels que nmap le detecteront.
On peut le changer pour un autre à 5 chiffres, on sera deja un peu plus tranquille.
Pour ce faire, on peut éditer le fichier /etc/ssh/sshd_config
Toujours dans ce même fichier, on peut indiquer les utilisateurs autorisés à se connecter, via la commande AllowUsers.
Exemple, on veut autoriser juste titi et toto :
AllowUsers titi toto
Encore mieux, on peut donner un user@ip.
On peut ainsi autoriser les acces root pour le reseau local, et un utilisateur pour le reste:
AllowUsers titi toto@192.168.1.1 root@192.168.2.0/24
Maintenant, il y a toutes sortes d'attaques utilisant des techniques différentes, je ne vous parlerai ici que de la brute-force.
Lors de ce type d'attaque, le hacker établit plusieurs connexions par secondes, chacune avec un couple login/pass différents. Afin de s'en protéger et de bannir l'adresse ip de l'attaquant, on va rajouter ces 3 lignes dans notre firewall iptables :
iptables -A INPUT -i eth1 -p tcp --dport 22 -m state --state NEW -m recent --set
iptables -A INPUT -i eth1 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 90 --hitcount 3 -j LOG --log-prefix="SSH BRUTEFORCE BANNED"
iptables -A INPUT -i eth1 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 90 --hitcount 3 -j DROP
Explication :
- La 1è ligne indique que lorsqu'une connexion arrive sur le port 22 (port ssh par défaut, à adapter suivant vos besoins), on va la marquer comme "à surveiller"
- La 2è va logger l'adresse IP et la date si il y a 3 nouvelles connexions venant de la meme adresse IP en 90 secondes
- Enfin la 3è va bannir cette adresse IP, et ne plus répondre à ces requêtes.
Ici ces 3 règles sont faites pour des connexions entrantes arrivant sur l'interface eth1, à adapter également
L'avantage de ces règles est que toutes les tentatives de brute-force vont être loggées, et les ip bannies.
(on peut d'ailleurs dé-commenter la 2è ligne si on ne veut pas de log)
Mais l'inconvénient est que si vous vous plantez de login ou mot de passe lors de la connexion, plus de 3 fois en 90 secondes, ou que vous vous connectez puis deconnectez 3 fois en 90 secondes, vous êtes mort ! :D
Il vous faudra donc être trèèèèès prudent (surtout quand vous êtes à l'extérieur et que vous accédez en ssh à votre machine depuis votre iphone jailbreaké, on peut facilement se planter de touche, vécu inside... lol ) et adapter le nombre de connexions et le temps suivant vos besoins.
Dans l'exemple ci dessus, c'est assez drastique, suite à de très nombreuses tentatives. Dans un contexte courant, on pourrait mettre par exemple 5 connexions sur 5 minutes.
Pour faire mieux, on peut également configurer son firewall pour n'autoriser l'accès à SSH que depuis une adresse IP en particulier, comme ça plus de problème
iptables -A INPUT -i eth1 -p tcp --dport 22 -s 1.2.3.4 -j ACCEPT
Par contre, il faut penser à autoriser autant d'adresses ip que vous avez de connexions extérieures; sinon vous serez coincé aussi.
Au passage, si vous avez installé Munin sur votre machine, il y a un plugin pour monitorer les accès. cela peut donner une bonne idées de la quantité de tentatives
Enfin, pendant qu'on est dans les règles firewall, en voici également une pour se protéger du "syn-flood", technique consistant à initier massivement des connexions TCP, donc envoyer des paquets syn à un serveur sans y répondre, rendant ainsi à terme la machine distante non-communicante, voire figée si trop de ressources utilisées.
Testé et approuvé !
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
iptables -A INPUT -m state --state NEW -p tcp --tcp-flags ! ALL SYN -j DROP
La 1è ligne active la protection anti syn-flood au niveau du kernel, et la 2è indique à iptables de bloquer toutes les nouvelles connexions tcp ne commençant pas par un syn.
Longue vie à votre serveur
sinon, fail2ban fait ça très bien (même si ça a un petit côté "bidouille") et pas seulement pour le SSH
salut fredo,
c'est vrai que c'est bien fail2ban, et qu'on peut le configurer pour verifier pas mal de services différents tant qu'il y a des logs derrière.
mais contrairement à iptables, il n'agit pas "en temps réel".
en cas de grosse attaque, le temps qu'il commence à agir, le serveur peut être deja par terre
Vous pouvez utiliser Google Authenticator pour protéger votre connexion SSH avec un code de validation à 2 facteurs http://pirmax.fr/2014/02/13/securis...
Interessant, je ne connaissais pas. merci
sinon le must reste toujours de ne plus utiliser de password mais la clé ssh
Pas mal cet article même si je connaissais déjà la syntaxe iptables concernant les brute force SSH. Pour OpenSSH, y'a également la double authentification password et yubikey qui est plutôt cool. Mais effectivement rien ne vaut l'authentification par clef.
On peut faire la même chose avec PF d'OpenBSD est la syntaxe est plutôt sympa :
block quick from <bruteforce>
pass in quick on $ext_if proto tcp from any to $ext_if port ssh \
keep state (max-src-conn 5, max-src-conn-rate 5/60, \
overload <bruteforce> flush global)
Pour la protection contre les SYN Flood, ça donne ça :
pass in quick on $ext_if proto tcp from any to X.X.X.X port www synproxy state
Franchement, PF c'est vraiment du bonheur par rapport à NETFILTER/IPTABLES.
A+
bonjour quentin
bien entendu, l'auth par clé est la meilleure ! et tellement pratique...
un coup de ssh-copy-id et c'est parti
Sinon j'avais vu aussi la yubi-key, faut que je m'y interesse. après, faut juste l'avoir sur soit en permanence et pas la perdre
Fil des commentaires de ce billet
URL de rétrolien : https://blog.crifo.org/trackback/33