La plupart des serveurs et routeurs connectés à l'Internet ont un
serveur SSH qui écoute sur le port 22 pour permettre l'accès à distance
et l'administration de la machine. Très souvent, des attaques
automatiques sont lancées contre ces machines. Même si elles échouent,
elles remplissent les journaux et déclenchent des alarmes inutiles. Je
recommande personnellement de ne jamais faire tourner le serveur SSH
sur le port 22.
Voici un exemple d'une attaque réelle (je n'ai pas modifié l'adresse IP
source de l'attaquant car, comme d'habitude, abuse n'a jamais répondu à
mon signalement (http://www.bortzmeyer.org/abuse-ne-repond-pas.html)).
Il s'agit apparemment d'une attaque par dictionnaire classique, où
l'assaillant essaie plusieurs mots de passe classiques pour des comptes
courants dans les pays anglo-saxons (john, adam, kevin) :
Dec 9 05:35:10 mon-serveur sshd[28839]: Invalid user john from 173.45.74.230
Dec 9 05:35:10 mon-serveur sshd[28839]: pam_unix(sshd:auth): check pass; user unknown
Dec 9 05:35:10 mon-serveur sshd[28839]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=e6.4a.2d.static.xlhost.com
Dec 9 05:35:11 mon-serveur sshd[28839]: Failed password for invalid user john from 173.45.74.230 port 40514 ssh2
Dec 9 05:35:12 mon-serveur sshd[28841]: Invalid user john from 173.45.74.230
Dec 9 05:35:12 mon-serveur sshd[28841]: pam_unix(sshd:auth): check pass; user unknown
Dec 9 05:35:12 mon-serveur sshd[28841]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=e6.4a.2d.static.xlhost.com
Dec 9 05:35:14 mon-serveur sshd[28841]: Failed password for invalid user john from 173.45.74.230 port 41395 ssh2
Dec 9 05:35:16 mon-serveur sshd[28843]: Invalid user kevin from 173.45.74.230
Dec 9 05:35:16 mon-serveur sshd[28843]: pam_unix(sshd:auth): check pass; user unknown
Dec 9 05:35:16 mon-serveur sshd[28843]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=e6.4a.2d.static.xlhost.com
Dec 9 05:35:18 mon-serveur sshd[28843]: Failed password for invalid user kevin from 173.45.74.230 port 42402 ssh2
Dec 9 05:35:19 mon-serveur sshd[28845]: Invalid user kevin from 173.45.74.230
Dec 9 05:35:19 mon-serveur sshd[28845]: pam_unix(sshd:auth): check pass; user unknown
Dec 9 05:35:19 mon-serveur sshd[28845]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=e6.4a.2d.static.xlhost.com
Dec 9 05:35:20 mon-serveur sshd[28845]: Failed password for invalid user kevin from 173.45.74.230 port 43071 ssh2
Dec 9 05:35:21 mon-serveur sshd[28847]: Invalid user adam from 173.45.74.230
Dec 9 05:35:21 mon-serveur sshd[28847]: pam_unix(sshd:auth): check pass; user unknown
Dec 9 05:35:21 mon-serveur sshd[28847]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=e6.4a.2d.static.xlhost.com
Dec 9 05:35:23 mon-serveur sshd[28847]: Failed password for invalid user adam from 173.45.74.230 port 43842 ssh2
Dec 9 05:35:24 mon-serveur sshd[28849]: Invalid user adam from 173.45.74.230
Dec 9 05:35:24 mon-serveur sshd[28849]: pam_unix(sshd:auth): check pass; user unknown
Dec 9 05:35:24 mon-serveur sshd[28849]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=e6.4a.2d.static.xlhost.com
Dec 9 05:35:27 mon-serveur sshd[28849]: Failed password for invalid user adam from 173.45.74.230 port 44743 ssh2
Ici, l'attaque a apparemment échoué. Mais, même si le serveur SSH a un
accès restreint (par exemple avec la directive
AllowUsers de OpenSSH),
c'est ennuyeux d'avoir ses journaux encombrés par de telles attaques,
qui sont très courantes. Un script PHP bogué,
une prise de contrôle à distance, même sans passer
root et hop, tout serveur dédié n'importe où
sur la planète commence un balayage systématique des serveurs et
routeurs, pour le compte du craqueur masqué
derrière lui.
Ma méthode préférée pour garder mes journaux courts et pour embêter un
peu les pirates est de faire tourner le serveur sur un autre port. Avec
OpenSSH, c'est :
Port 42666
dans le fichier de configuration. Et, là, plus d'attaques.
J'insiste bien sur le fait que le but principal est d'éviter
l'encombrement des journaux. Changer de port ralentit les craqueurs
mais n'est pas réellement un gros avantage en matière de sécurité
(croire cela serait croire au STO). Un craqueur compétent pourrait
faire un nmap sur le serveur et découvrir le port SSH par la bannière
envoyée :
% telnet mon-serveur 42666
Trying 2001:db8:37a::d946:bee8:232...
Connected to mon-serveur.
Escape character is '^]'.
SSH-2.0-OpenSSH_5.1p1 Debian-5
...
Mais, en pratique, la plupart des attaques sont bêtes et massives. Pas
de subtilité, juste tester le port 22. Sur les serveurs qui écoutent
sur un autre port, on ne voit jamais, à l'heure actuelle, d'attaques
par dictionnaire.
Certaines personnes pensent que changer de port va leur compliquer la
vie à eux aussi, en les obligeant à indiquer le numéro de port à chaque
commande SSH, par exemple à taper ssh -p 42666 mon-serveur au lieu de
ssh mon-serveur. Mais non ; OpenSSH permet de mettre le numéro de port
une fois pour toutes dans le fichier ~/.ssh/config :
Host mon-serveur
Port 42666
et c'est tout, il n'y aura plus rien à taper (si on travaille sur
plusieurs machines, ce qui est mon cas, on peut synchroniser son répertoire (http://www.bortzmeyer.org/home-in-subversion.html)). Même
chose avec un client SSH comme ConnectBot (http://code.google.com/p/connectbot/) sur
Android, qui permet d'indiquer le numéro de
port lors de l'enregistrement d'un serveur.
Existe-t-il d'autres méthodes pour contrarier ce genre d'attaquants ?
Oui, bien sûr, on peut restreindre l'accès à SSH par adresse IP source.
Cela se fait souvent sur les routeurs, qu'on n'administre que depuis le
réseau interne, mais ce n'est pas toujours possible pour les serveurs,
il faut bien pouvoir se connecter à distance. Il y a aussi la
possibilité de faire du « toquage à la porte » avec un logiciel comme
knockd ou avec une solution plus simple
(http://www.debian-administration.org/articles/268). Encore une autre
solution est d'utiliser fail2ban mais je ne l'ai personnellement pas
encore tenté. En sécurité, les solutions les plus simples et les moins
fatigantes sont souvent les meilleures.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20101217130017.GA31515@nic.fr
> - iptables avec ipset pour bloquer les méchants pendant un certain > temps.
merci pour ipset ça a l'air puissant.
Oui, et très pratique pour rajouter à la volée des ports autorisés, des hôtes autorisés (ou non).
Je suppose également que ça permet un traitement plus rapide des requêtes à évincer lorsque le traitement par les sets sont mis en début de la liste des règles.
-- jm
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Bonjour,
Le vendredi 17 décembre 2010, Julien a écrit...
> - iptables avec ipset pour bloquer les méchants pendant un certain
> temps.
merci pour ipset ça a l'air puissant.
Oui, et très pratique pour rajouter à la volée des ports autorisés, des
hôtes autorisés (ou non).
Je suppose également que ça permet un traitement plus rapide des
requêtes à évincer lorsque le traitement par les sets sont mis en début
de la liste des règles.
--
jm
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20101217215159.GF1990@espinasse
> - iptables avec ipset pour bloquer les méchants pendant un certain > temps.
merci pour ipset ça a l'air puissant.
Oui, et très pratique pour rajouter à la volée des ports autorisés, des hôtes autorisés (ou non).
Je suppose également que ça permet un traitement plus rapide des requêtes à évincer lorsque le traitement par les sets sont mis en début de la liste des règles.
-- jm
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Pascal Hambourg
Salut,
Nicolas KOWALSKI a écrit :
# iptables-save # Generated by iptables-save v1.4.2 on Fri Dec 17 18:45:42 2010 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -i lo -j ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -s <ip-whitelistee>/32 -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name SSH --rsource -A INPUT -p tcp -m tcp --dport 22 -m recent --update --seconds 60 --hitcount 3 --rttl --name SSH --rsource -j DROP -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
Simple, non ? ;-)
J'hésite à dire simpliste, même. La correspondance "recent" d'iptables est vulnérable à l'usurpation d'adresse et a une mémoire limitée, ce qui permet à un attaquant de débloquer son adresse rapidement ou de bloquer une adresse arbitraire, provoquant un déni de service.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Salut,
Nicolas KOWALSKI a écrit :
# iptables-save
# Generated by iptables-save v1.4.2 on Fri Dec 17 18:45:42 2010
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s <ip-whitelistee>/32 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name SSH --rsource
-A INPUT -p tcp -m tcp --dport 22 -m recent --update --seconds 60 --hitcount 3 --rttl --name SSH --rsource -j DROP
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
Simple, non ? ;-)
J'hésite à dire simpliste, même. La correspondance "recent" d'iptables
est vulnérable à l'usurpation d'adresse et a une mémoire limitée, ce qui
permet à un attaquant de débloquer son adresse rapidement ou de bloquer
une adresse arbitraire, provoquant un déni de service.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/4D0BEAAC.3000803@plouf.fr.eu.org
# iptables-save # Generated by iptables-save v1.4.2 on Fri Dec 17 18:45:42 2010 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -i lo -j ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -s <ip-whitelistee>/32 -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name SSH --rsource -A INPUT -p tcp -m tcp --dport 22 -m recent --update --seconds 60 --hitcount 3 --rttl --name SSH --rsource -j DROP -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
Simple, non ? ;-)
J'hésite à dire simpliste, même. La correspondance "recent" d'iptables est vulnérable à l'usurpation d'adresse et a une mémoire limitée, ce qui permet à un attaquant de débloquer son adresse rapidement ou de bloquer une adresse arbitraire, provoquant un déni de service.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Daniel Huhardeaux
Le 17/12/2010 20:15, Stephane Bortzmeyer a écrit :
On Fri, Dec 17, 2010 at 02:15:43PM +0100, Daniel Huhardeaux wrote a message of 65 lines which said:
Host mon-serveur Port 42666
Tout à fait. Mais attention, cela ne fonctionne pas avec scp
Je regrette mais c'est tout à fait faux (et je viens de re-tester, et ça marche, et -v indique bien le port utilisé).
Tu n'as pas à regretter, tu rétablis la vérité. Effectivement, cela fonctionne, mea culpa.
PS: je suis abonné à la liste, pas de nécessité de me mettre en copie -- Daniel
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Le 17/12/2010 20:15, Stephane Bortzmeyer a écrit :
On Fri, Dec 17, 2010 at 02:15:43PM +0100,
Daniel Huhardeaux<no-spam@tootai.net> wrote
a message of 65 lines which said:
Host mon-serveur
Port 42666
Tout à fait. Mais attention, cela ne fonctionne pas avec scp
Je regrette mais c'est tout à fait faux (et je viens de re-tester, et
ça marche, et -v indique bien le port utilisé).
Tu n'as pas à regretter, tu rétablis la vérité. Effectivement, cela
fonctionne, mea culpa.
PS: je suis abonné à la liste, pas de nécessité de me mettre en copie
--
Daniel
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/4D0C8D89.5010007@tootai.net
Le 17/12/2010 20:15, Stephane Bortzmeyer a écrit :
On Fri, Dec 17, 2010 at 02:15:43PM +0100, Daniel Huhardeaux wrote a message of 65 lines which said:
Host mon-serveur Port 42666
Tout à fait. Mais attention, cela ne fonctionne pas avec scp
Je regrette mais c'est tout à fait faux (et je viens de re-tester, et ça marche, et -v indique bien le port utilisé).
Tu n'as pas à regretter, tu rétablis la vérité. Effectivement, cela fonctionne, mea culpa.
PS: je suis abonné à la liste, pas de nécessité de me mettre en copie -- Daniel
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Nicolas KOWALSKI
Pascal Hambourg writes:
J'hésite à dire simpliste, même. La correspondance "recent" d'iptables est vulnérable à l'usurpation d'adresse et a une mémoire limitée, ce qui permet à un attaquant de débloquer son adresse rapidement ou de bloquer une adresse arbitraire, provoquant un déni de service.
Il y a une autre méthode basée sur iptables, simple et sûre, en lieu et place de fail2ban ?
-- Nicolas
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
J'hésite à dire simpliste, même. La correspondance "recent" d'iptables
est vulnérable à l'usurpation d'adresse et a une mémoire limitée, ce qui
permet à un attaquant de débloquer son adresse rapidement ou de bloquer
une adresse arbitraire, provoquant un déni de service.
Il y a une autre méthode basée sur iptables, simple et sûre, en lieu
et place de fail2ban ?
--
Nicolas
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/87k4j7ypgq.fsf@petole.demisel.net
J'hésite à dire simpliste, même. La correspondance "recent" d'iptables est vulnérable à l'usurpation d'adresse et a une mémoire limitée, ce qui permet à un attaquant de débloquer son adresse rapidement ou de bloquer une adresse arbitraire, provoquant un déni de service.
Il y a une autre méthode basée sur iptables, simple et sûre, en lieu et place de fail2ban ?
-- Nicolas
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Pascal Hambourg
Nicolas KOWALSKI a écrit :
Pascal Hambourg writes:
J'hésite à dire simpliste, même. La correspondance "recent" d'iptables est vulnérable à l'usurpation d'adresse et a une mémoire limitée, ce qui permet à un attaquant de débloquer son adresse rapidement ou de bloquer une adresse arbitraire, provoquant un déni de service.
Il y a une autre méthode basée sur iptables, simple et sûre, en lieu et place de fail2ban ?
Tu veux dire une méthode non basée sur les logs d'échec de sshd ? Je n'en connais pas. Pour se protéger contre l'usurpation d'adresse, il faudrait se baser sur la réception du dernier paquet de la poignée de main TCP. Mais ce paquet est un simple ACK qu'il n'est pas aisé de distinguer de n'importe quel autre ACK. Sa seule particularité est qu'il est le premier ACK reçu. De toute façon iptables n'a aucun moyen seul de reconnaître un échec d'authentification, et il peux exister des usages légitimes impliquant plusieurs connexions SSH rapprochées, par exemple avec scp. L'analyse des logs a le double avantage de protéger raisonnablement contre l'usurpation d'adresse (très difficile d'établir une connexion TCP en usurpant l'adresse source sur internet, et pas de log si pas de connexion) et de ne sanctionner que les échecs.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
J'hésite à dire simpliste, même. La correspondance "recent" d'iptables
est vulnérable à l'usurpation d'adresse et a une mémoire limitée, ce qui
permet à un attaquant de débloquer son adresse rapidement ou de bloquer
une adresse arbitraire, provoquant un déni de service.
Il y a une autre méthode basée sur iptables, simple et sûre, en lieu
et place de fail2ban ?
Tu veux dire une méthode non basée sur les logs d'échec de sshd ?
Je n'en connais pas. Pour se protéger contre l'usurpation d'adresse, il
faudrait se baser sur la réception du dernier paquet de la poignée de
main TCP. Mais ce paquet est un simple ACK qu'il n'est pas aisé de
distinguer de n'importe quel autre ACK. Sa seule particularité est qu'il
est le premier ACK reçu. De toute façon iptables n'a aucun moyen seul de
reconnaître un échec d'authentification, et il peux exister des usages
légitimes impliquant plusieurs connexions SSH rapprochées, par exemple
avec scp. L'analyse des logs a le double avantage de protéger
raisonnablement contre l'usurpation d'adresse (très difficile d'établir
une connexion TCP en usurpant l'adresse source sur internet, et pas de
log si pas de connexion) et de ne sanctionner que les échecs.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/4D0D262E.4060909@plouf.fr.eu.org
J'hésite à dire simpliste, même. La correspondance "recent" d'iptables est vulnérable à l'usurpation d'adresse et a une mémoire limitée, ce qui permet à un attaquant de débloquer son adresse rapidement ou de bloquer une adresse arbitraire, provoquant un déni de service.
Il y a une autre méthode basée sur iptables, simple et sûre, en lieu et place de fail2ban ?
Tu veux dire une méthode non basée sur les logs d'échec de sshd ? Je n'en connais pas. Pour se protéger contre l'usurpation d'adresse, il faudrait se baser sur la réception du dernier paquet de la poignée de main TCP. Mais ce paquet est un simple ACK qu'il n'est pas aisé de distinguer de n'importe quel autre ACK. Sa seule particularité est qu'il est le premier ACK reçu. De toute façon iptables n'a aucun moyen seul de reconnaître un échec d'authentification, et il peux exister des usages légitimes impliquant plusieurs connexions SSH rapprochées, par exemple avec scp. L'analyse des logs a le double avantage de protéger raisonnablement contre l'usurpation d'adresse (très difficile d'établir une connexion TCP en usurpant l'adresse source sur internet, et pas de log si pas de connexion) et de ne sanctionner que les échecs.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Nicolas KOWALSKI
Pascal Hambourg writes:
Nicolas KOWALSKI a écrit :
Il y a une autre méthode basée sur iptables, simple et sûre, en lieu et place de fail2ban ?
Tu veux dire une méthode non basée sur les logs d'échec de sshd ? Je n'en connais pas.
Oui, je pensais à ce type de méthode. Dommage, j'aimais bien cette simplicité d'utilisation.
L'analyse des logs a le double avantage de protéger raisonnablement contre l'usurpation d'adresse (très difficile d'établir une connexion TCP en usurpant l'adresse source sur internet, et pas de log si pas de connexion) et de ne sanctionner que les échecs.
Bon, je vais refaire des essais avec fail2ban alors.
Merci pour toutes ces précisions.
-- Nicolas
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Il y a une autre méthode basée sur iptables, simple et sûre, en lieu
et place de fail2ban ?
Tu veux dire une méthode non basée sur les logs d'échec de sshd ?
Je n'en connais pas.
Oui, je pensais à ce type de méthode. Dommage, j'aimais bien cette
simplicité d'utilisation.
L'analyse des logs a le double avantage de protéger raisonnablement
contre l'usurpation d'adresse (très difficile d'établir une
connexion TCP en usurpant l'adresse source sur internet, et pas de
log si pas de connexion) et de ne sanctionner que les échecs.
Bon, je vais refaire des essais avec fail2ban alors.
Merci pour toutes ces précisions.
--
Nicolas
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/87tyiaw19k.fsf@petole.demisel.net
Il y a une autre méthode basée sur iptables, simple et sûre, en lieu et place de fail2ban ?
Tu veux dire une méthode non basée sur les logs d'échec de sshd ? Je n'en connais pas.
Oui, je pensais à ce type de méthode. Dommage, j'aimais bien cette simplicité d'utilisation.
L'analyse des logs a le double avantage de protéger raisonnablement contre l'usurpation d'adresse (très difficile d'établir une connexion TCP en usurpant l'adresse source sur internet, et pas de log si pas de connexion) et de ne sanctionner que les échecs.
Bon, je vais refaire des essais avec fail2ban alors.
Merci pour toutes ces précisions.
-- Nicolas
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Ebling Andreas
Bonjour,
J'avais une méthode radicale, mais dangereuse avec iptables: iptables -A INPUT -p tcp --dport ssh -m state --state NEW -m recent --set --name SSH iptables -A INPUT -p tcp --dport ssh --match state --state NEW -m recent --update --seconds 60 --hitcount 3 --rttl --name SSH -j DROP
Le principe de la règle est simple, si quelqu'un tente de faire plus de 3 connexions ssh en moins de 60s, l'IP est bannie pendant un certain temps. Le problème et qu'il ne fait pas la différence entre connexion réussie et connexion échouée, du coup un utilisateur "normal" est soumis aux même règles. (peut s'arranger avec --source éventuellement, j'avais configuré ça pour mon réseau local)
Cordialement, Andreas
On Dec 19, 2010, at 10:38 AM, Nicolas KOWALSKI wrote:
Pascal Hambourg writes:
Nicolas KOWALSKI a écrit :
Il y a une autre méthode basée sur iptables, simple et sûre, en lieu et place de fail2ban ?
Tu veux dire une méthode non basée sur les logs d'échec de sshd ? Je n'en connais pas.
Oui, je pensais à ce type de méthode. Dommage, j'aimais bien cette simplicité d'utilisation.
L'analyse des logs a le double avantage de protéger raisonnablement contre l'usurpation d'adresse (très difficile d'établir une connexion TCP en usurpant l'adresse source sur internet, et pas de log si pas de connexion) et de ne sanctionner que les échecs.
Bon, je vais refaire des essais avec fail2ban alors.
Merci pour toutes ces précisions.
-- Nicolas
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Bonjour,
J'avais une méthode radicale, mais dangereuse avec iptables: iptables -A INPUT -p tcp --dport ssh -m state --state NEW -m recent --set --name SSH
iptables -A INPUT -p tcp --dport ssh --match state --state NEW -m recent --update --seconds 60 --hitcount 3 --rttl --name SSH -j DROP
Le principe de la règle est simple, si quelqu'un tente de faire plus de 3 connexions ssh en moins de 60s, l'IP est bannie pendant un certain temps.
Le problème et qu'il ne fait pas la différence entre connexion réussie et connexion échouée, du coup un utilisateur "normal" est soumis aux même règles.
(peut s'arranger avec --source éventuellement, j'avais configuré ça pour mon réseau local)
Cordialement,
Andreas
On Dec 19, 2010, at 10:38 AM, Nicolas KOWALSKI wrote:
Il y a une autre méthode basée sur iptables, simple et sûre, en lieu
et place de fail2ban ?
Tu veux dire une méthode non basée sur les logs d'échec de sshd ?
Je n'en connais pas.
Oui, je pensais à ce type de méthode. Dommage, j'aimais bien cette
simplicité d'utilisation.
L'analyse des logs a le double avantage de protéger raisonnablement
contre l'usurpation d'adresse (très difficile d'établir une
connexion TCP en usurpant l'adresse source sur internet, et pas de
log si pas de connexion) et de ne sanctionner que les échecs.
Bon, je vais refaire des essais avec fail2ban alors.
Merci pour toutes ces précisions.
--
Nicolas
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/7E073549-3824-4023-BDA3-4574FA94FD6A@free.fr
J'avais une méthode radicale, mais dangereuse avec iptables: iptables -A INPUT -p tcp --dport ssh -m state --state NEW -m recent --set --name SSH iptables -A INPUT -p tcp --dport ssh --match state --state NEW -m recent --update --seconds 60 --hitcount 3 --rttl --name SSH -j DROP
Le principe de la règle est simple, si quelqu'un tente de faire plus de 3 connexions ssh en moins de 60s, l'IP est bannie pendant un certain temps. Le problème et qu'il ne fait pas la différence entre connexion réussie et connexion échouée, du coup un utilisateur "normal" est soumis aux même règles. (peut s'arranger avec --source éventuellement, j'avais configuré ça pour mon réseau local)
Cordialement, Andreas
On Dec 19, 2010, at 10:38 AM, Nicolas KOWALSKI wrote:
Pascal Hambourg writes:
Nicolas KOWALSKI a écrit :
Il y a une autre méthode basée sur iptables, simple et sûre, en lieu et place de fail2ban ?
Tu veux dire une méthode non basée sur les logs d'échec de sshd ? Je n'en connais pas.
Oui, je pensais à ce type de méthode. Dommage, j'aimais bien cette simplicité d'utilisation.
L'analyse des logs a le double avantage de protéger raisonnablement contre l'usurpation d'adresse (très difficile d'établir une connexion TCP en usurpant l'adresse source sur internet, et pas de log si pas de connexion) et de ne sanctionner que les échecs.
Bon, je vais refaire des essais avec fail2ban alors.
Merci pour toutes ces précisions.
-- Nicolas
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
mouss
Le 17/12/2010 14:00, Stephane Bortzmeyer a écrit :
[snip] Existe-t-il d'autres méthodes pour contrarier ce genre d'attaquants ? Oui, bien sûr, on peut restreindre l'accès à SSH par adresse IP source. Cela se fait souvent sur les routeurs, qu'on n'administre que depuis le réseau interne, mais ce n'est pas toujours possible pour les serveurs, il faut bien pouvoir se connecter à distance.
on peut aussi activer plusieurs ports dans sshd_config:
Port 22 Port ABCDE
et n'autoriser le port 22 qu'à partir de certaines IPs (avec iptables ou autre). ça a l'avantage de ne pas devoir modifier les scripts qui utilisent ssh à partir de certaines machines (rsync par exemple).
de plus, si le nombre de comptes qui ont droit à ssh est réduit, on peut créer un groupe et utiliser un truc du genre:
AllowGroups _sshuser
Il y a aussi la possibilité de faire du « toquage à la porte » avec un logiciel comme knockd ou avec une solution plus simple (http://www.debian-administration.org/articles/268). Encore une autre solution est d'utiliser fail2ban mais je ne l'ai personnellement pas encore tenté. En sécurité, les solutions les plus simples et les moins fatigantes sont souvent les meilleures.
tout à fait.
pour fail2ban et les méthodes de même type (blocage d'une IP suite à une tentative), ça ne marchera pas si l'attaque est distribuée.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Le 17/12/2010 14:00, Stephane Bortzmeyer a écrit :
[snip]
Existe-t-il d'autres méthodes pour contrarier ce genre d'attaquants ?
Oui, bien sûr, on peut restreindre l'accès à SSH par adresse IP source.
Cela se fait souvent sur les routeurs, qu'on n'administre que depuis le
réseau interne, mais ce n'est pas toujours possible pour les serveurs,
il faut bien pouvoir se connecter à distance.
on peut aussi activer plusieurs ports dans sshd_config:
Port 22
Port ABCDE
et n'autoriser le port 22 qu'à partir de certaines IPs (avec iptables ou
autre). ça a l'avantage de ne pas devoir modifier les scripts qui
utilisent ssh à partir de certaines machines (rsync par exemple).
de plus, si le nombre de comptes qui ont droit à ssh est réduit, on peut
créer un groupe et utiliser un truc du genre:
AllowGroups _sshuser
Il y a aussi la
possibilité de faire du « toquage à la porte » avec un logiciel comme
knockd ou avec une solution plus simple
(http://www.debian-administration.org/articles/268). Encore une autre
solution est d'utiliser fail2ban mais je ne l'ai personnellement pas
encore tenté. En sécurité, les solutions les plus simples et les moins
fatigantes sont souvent les meilleures.
tout à fait.
pour fail2ban et les méthodes de même type (blocage d'une IP suite à une
tentative), ça ne marchera pas si l'attaque est distribuée.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20101219172141.DB76513A4CB0@liszt.debian.org
[snip] Existe-t-il d'autres méthodes pour contrarier ce genre d'attaquants ? Oui, bien sûr, on peut restreindre l'accès à SSH par adresse IP source. Cela se fait souvent sur les routeurs, qu'on n'administre que depuis le réseau interne, mais ce n'est pas toujours possible pour les serveurs, il faut bien pouvoir se connecter à distance.
on peut aussi activer plusieurs ports dans sshd_config:
Port 22 Port ABCDE
et n'autoriser le port 22 qu'à partir de certaines IPs (avec iptables ou autre). ça a l'avantage de ne pas devoir modifier les scripts qui utilisent ssh à partir de certaines machines (rsync par exemple).
de plus, si le nombre de comptes qui ont droit à ssh est réduit, on peut créer un groupe et utiliser un truc du genre:
AllowGroups _sshuser
Il y a aussi la possibilité de faire du « toquage à la porte » avec un logiciel comme knockd ou avec une solution plus simple (http://www.debian-administration.org/articles/268). Encore une autre solution est d'utiliser fail2ban mais je ne l'ai personnellement pas encore tenté. En sécurité, les solutions les plus simples et les moins fatigantes sont souvent les meilleures.
tout à fait.
pour fail2ban et les méthodes de même type (blocage d'une IP suite à une tentative), ça ne marchera pas si l'attaque est distribuée.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Vincent Lefevre
On 2010-12-19 18:15:02 +0100, mouss wrote:
on peut aussi activer plusieurs ports dans sshd_config:
Port 22 Port ABCDE
et n'autoriser le port 22 qu'à partir de certaines IPs (avec iptables ou autre). ça a l'avantage de ne pas devoir modifier les scripts qui utilisent ssh à partir de certaines machines (rsync par exemple).
Pas besoin de modifier les scripts quand on change de port: il suffit de modifier le .ssh/config, et cela une fois pour toutes.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
On 2010-12-19 18:15:02 +0100, mouss wrote:
on peut aussi activer plusieurs ports dans sshd_config:
Port 22
Port ABCDE
et n'autoriser le port 22 qu'à partir de certaines IPs (avec iptables ou
autre). ça a l'avantage de ne pas devoir modifier les scripts qui utilisent
ssh à partir de certaines machines (rsync par exemple).
Pas besoin de modifier les scripts quand on change de port: il suffit
de modifier le .ssh/config, et cela une fois pour toutes.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20101219213656.GN1777@prunille.vinc17.org
on peut aussi activer plusieurs ports dans sshd_config:
Port 22 Port ABCDE
et n'autoriser le port 22 qu'à partir de certaines IPs (avec iptables ou autre). ça a l'avantage de ne pas devoir modifier les scripts qui utilisent ssh à partir de certaines machines (rsync par exemple).
Pas besoin de modifier les scripts quand on change de port: il suffit de modifier le .ssh/config, et cela une fois pour toutes.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Sebastien Rodriguez
Le 17 décembre 2010 22:35, Stephane Bortzmeyer a écrit :
Ceci dit, sur Android, je ne connais aucun client SSH qui puisse utiliser les clés pour l'authentification.
Bonjour, Si si, ConnectBot (http://code.google.com/p/connectbot/) permet d'utiliser des clefs d'authentification : je l'utilise avec succès... Mais le clavier virtuel limite mon usage de SSH sur mon téléphone.
Sébastien.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/AANLkTikH+
Le 17 décembre 2010 22:35, Stephane Bortzmeyer <stephane@sources.org> a écrit :
Ceci dit, sur Android, je ne connais aucun client SSH qui puisse
utiliser les clés pour l'authentification.
Bonjour,
Si si, ConnectBot (http://code.google.com/p/connectbot/) permet
d'utiliser des clefs d'authentification : je l'utilise avec succès...
Mais le clavier virtuel limite mon usage de SSH sur mon téléphone.
Sébastien.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/AANLkTikH+Sbr2ynZZ9__Z_5PtCvWm697RCub9VAWfa21@mail.gmail.com
Le 17 décembre 2010 22:35, Stephane Bortzmeyer a écrit :
Ceci dit, sur Android, je ne connais aucun client SSH qui puisse utiliser les clés pour l'authentification.
Bonjour, Si si, ConnectBot (http://code.google.com/p/connectbot/) permet d'utiliser des clefs d'authentification : je l'utilise avec succès... Mais le clavier virtuel limite mon usage de SSH sur mon téléphone.
Sébastien.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/AANLkTikH+
