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
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.
Cela fait des années que j'applique cette règle et ne m'en porte que mieux
[...] 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
Tout à fait. Mais attention, cela ne fonctionne pas avec scp
[...]
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.
Fail2ban est parfait pour bloquer ce genre d'attaques. Il ne faut pas oublier que certains services se doivent de tourner sur le port qui leur est défini (IAX, SIP, H323, ...). Fail2ban est alors le compagnon indispensable. Combien de serveurs VOIP sont attaqués et ce avec réussite, la légèreté de programmation des règles du dialplan et de la définition des clients étant dans la très grande majorité des cas responsable de la cette réussite.
-- 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/
Bonjour
Le 17/12/2010 14:00, Stephane Bortzmeyer a écrit :
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.
Cela fait des années que j'applique cette règle et ne m'en porte que mieux
[...]
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
Tout à fait. Mais attention, cela ne fonctionne pas avec scp
[...]
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.
Fail2ban est parfait pour bloquer ce genre d'attaques. Il ne faut pas
oublier que certains services se doivent de tourner sur le port qui leur
est défini (IAX, SIP, H323, ...). Fail2ban est alors le compagnon
indispensable. Combien de serveurs VOIP sont attaqués et ce avec
réussite, la légèreté de programmation des règles du dialplan et de la
définition des clients étant dans la très grande majorité des cas
responsable de la cette réussite.
--
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/4D0B627F.1020507@tootai.net
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.
Cela fait des années que j'applique cette règle et ne m'en porte que mieux
[...] 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
Tout à fait. Mais attention, cela ne fonctionne pas avec scp
[...]
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.
Fail2ban est parfait pour bloquer ce genre d'attaques. Il ne faut pas oublier que certains services se doivent de tourner sur le port qui leur est défini (IAX, SIP, H323, ...). Fail2ban est alors le compagnon indispensable. Combien de serveurs VOIP sont attaqués et ce avec réussite, la légèreté de programmation des règles du dialplan et de la définition des clients étant dans la très grande majorité des cas responsable de la cette réussite.
-- 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/
giggzounet
Bonjour,
[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. 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.
Mon pc s'intègre au réseau de l'université où je bosse. Je ne peux malheureusement pas changé de port pour ssh (sinon je ne peux plus me connecter de l'extérieur...). J'ai adopté fail2ban et ça marche très bien. J'ai de la visite sur mon port ssh 3 à 4 fois par jour et fail2ban me vire tout ça fissa et m'envoie un mail.
le changement de port j'ai fait ça à la maison et ça marche super bien aussi.
Bye
-- 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/iefqr5$uoq$
Bonjour,
[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. 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.
Mon pc s'intègre au réseau de l'université où je bosse. Je ne peux
malheureusement pas changé de port pour ssh (sinon je ne peux plus me
connecter de l'extérieur...). J'ai adopté fail2ban et ça marche très
bien. J'ai de la visite sur mon port ssh 3 à 4 fois par jour et fail2ban
me vire tout ça fissa et m'envoie un mail.
le changement de port j'ai fait ça à la maison et ça marche super bien
aussi.
Bye
--
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/iefqr5$uoq$1@dough.gmane.org
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.
Mon pc s'intègre au réseau de l'université où je bosse. Je ne peux malheureusement pas changé de port pour ssh (sinon je ne peux plus me connecter de l'extérieur...). J'ai adopté fail2ban et ça marche très bien. J'ai de la visite sur mon port ssh 3 à 4 fois par jour et fail2ban me vire tout ça fissa et m'envoie un mail.
le changement de port j'ai fait ça à la maison et ça marche super bien aussi.
Bye
-- 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/iefqr5$uoq$
Alain Vaugham
Le Friday 17 December 2010 14:00:17 Stephane Bortzmeyer, vous avez écrit :
Existe-t-il d'autres méthodes pour contrarier ce genre d'attaquants ?
Voici ce que j'utilise :
Pour ssh En plus de changer le port d'écoute par défaut, j'interdit l'accès ro ot et j'oblige l'identification par clefs. $ ssh -ple-bon-port commande
Pour scp $ scp -Ple-bon-port -rCp la-source la-cible
-- Alain Vaugham Clef GPG : 0xD26D18BC
-- 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 Friday 17 December 2010 14:00:17 Stephane Bortzmeyer, vous avez écrit :
Existe-t-il d'autres méthodes pour contrarier ce genre d'attaquants ?
Voici ce que j'utilise :
Pour ssh
En plus de changer le port d'écoute par défaut, j'interdit l'accès ro ot et
j'oblige l'identification par clefs.
$ ssh -ple-bon-port user@machine commande
Pour scp
$ scp -Ple-bon-port -rCp la-source la-cible
--
Alain Vaugham
Clef GPG : 0xD26D18BC
--
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/201012171837.53647.alain@vaugham.com
Le Friday 17 December 2010 14:00:17 Stephane Bortzmeyer, vous avez écrit :
Existe-t-il d'autres méthodes pour contrarier ce genre d'attaquants ?
Voici ce que j'utilise :
Pour ssh En plus de changer le port d'écoute par défaut, j'interdit l'accès ro ot et j'oblige l'identification par clefs. $ ssh -ple-bon-port commande
Pour scp $ scp -Ple-bon-port -rCp la-source la-cible
-- Alain Vaugham Clef GPG : 0xD26D18BC
-- 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/
Yves Rutschle
On Fri, Dec 17, 2010 at 03:07:32PM +0100, giggzounet wrote:
Mon pc s'intègre au réseau de l'université où je bosse. Je ne peux malheureusement pas changé de port pour ssh (sinon je ne peux plus me connecter de l'extérieur...).
On peut le mettre derrière un port connu (par exemple 443), ça peut aider.
Y.
-- 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 Fri, Dec 17, 2010 at 03:07:32PM +0100, giggzounet wrote:
Mon pc s'intègre au réseau de l'université où je bosse. Je ne peux
malheureusement pas changé de port pour ssh (sinon je ne peux plus me
connecter de l'extérieur...).
On peut le mettre derrière un port connu (par exemple 443),
ça peut aider.
Y.
--
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/20101217171906.GN20837@naryves.com
On Fri, Dec 17, 2010 at 03:07:32PM +0100, giggzounet wrote:
Mon pc s'intègre au réseau de l'université où je bosse. Je ne peux malheureusement pas changé de port pour ssh (sinon je ne peux plus me connecter de l'extérieur...).
On peut le mettre derrière un port connu (par exemple 443), ça peut aider.
Y.
-- 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 18:19, Yves Rutschle a écrit :
On Fri, Dec 17, 2010 at 03:07:32PM +0100, giggzounet wrote:
Mon pc s'intègre au réseau de l'université où je bosse. Je ne peux malheureusement pas changé de port pour ssh (sinon je ne peux plus me connecter de l'extérieur...).
On peut le mettre derrière un port connu (par exemple 443), [...]
Mais non, déjà pris par OpenVPN ;-) -- 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 18:19, Yves Rutschle a écrit :
On Fri, Dec 17, 2010 at 03:07:32PM +0100, giggzounet wrote:
Mon pc s'intègre au réseau de l'université où je bosse. Je ne peux
malheureusement pas changé de port pour ssh (sinon je ne peux plus me
connecter de l'extérieur...).
On peut le mettre derrière un port connu (par exemple 443),
[...]
Mais non, déjà pris par OpenVPN ;-)
--
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/4D0BA2CB.4030907@tootai.net
On Fri, Dec 17, 2010 at 03:07:32PM +0100, giggzounet wrote:
Mon pc s'intègre au réseau de l'université où je bosse. Je ne peux malheureusement pas changé de port pour ssh (sinon je ne peux plus me connecter de l'extérieur...).
On peut le mettre derrière un port connu (par exemple 443), [...]
Mais non, déjà pris par OpenVPN ;-) -- 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
Stephane Bortzmeyer writes:
En sécurité, les solutions les plus simples et les moins fatigantes sont souvent les meilleures.
Le petit script iptables ci-dessous met dehors toutes les attaques par dictionnaire (plus de 3 connexions par minutes sur le ssh, et l'IP source est bloquée), sans avoir besoin de changer le port d'écoute du serveur. On peut whitelister également une IP, avant la règle du DROP, comme indiqué. Coût (temps, logiciel, ...) de maintenance, zéro.
# 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 ? ;-)
-- 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/
En sécurité, les solutions les plus simples et les moins fatigantes
sont souvent les meilleures.
Le petit script iptables ci-dessous met dehors toutes les attaques par
dictionnaire (plus de 3 connexions par minutes sur le ssh, et l'IP
source est bloquée), sans avoir besoin de changer le port d'écoute du
serveur. On peut whitelister également une IP, avant la règle du DROP,
comme indiqué. Coût (temps, logiciel, ...) de maintenance, zéro.
# 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 ? ;-)
--
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/87tyicz2ux.fsf@petole.demisel.net
En sécurité, les solutions les plus simples et les moins fatigantes sont souvent les meilleures.
Le petit script iptables ci-dessous met dehors toutes les attaques par dictionnaire (plus de 3 connexions par minutes sur le ssh, et l'IP source est bloquée), sans avoir besoin de changer le port d'écoute du serveur. On peut whitelister également une IP, avant la règle du DROP, comme indiqué. Coût (temps, logiciel, ...) de maintenance, zéro.
# 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 ? ;-)
-- 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/
Stephane Bortzmeyer
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é).
-- 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 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é).
--
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/20101217191521.GA21373@sources.org
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é).
-- 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/
Jean-Michel OLTRA
Bonjour,
Le vendredi 17 décembre 2010, Stephane Bortzmeyer a écrit...
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.
J'utilise :
- L'authentification par clefs ; - fail2ban ; - ossec hids et la réponse active ; - iptables avec ipset pour bloquer les méchants pendant un certain temps.
-- 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, Stephane Bortzmeyer a écrit...
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.
J'utilise :
- L'authentification par clefs ;
- fail2ban ;
- ossec hids et la réponse active ;
- iptables avec ipset pour bloquer les méchants pendant un certain temps.
--
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/20101217205540.GD1990@espinasse
Le vendredi 17 décembre 2010, Stephane Bortzmeyer a écrit...
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.
J'utilise :
- L'authentification par clefs ; - fail2ban ; - ossec hids et la réponse active ; - iptables avec ipset pour bloquer les méchants pendant un certain temps.
-- 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/
Stephane Bortzmeyer
On Fri, Dec 17, 2010 at 06:37:53PM +0100, Alain Vaugham wrote a message of 29 lines which said:
j'oblige l'identification par clefs.
C'est sûr que c'est sûr mais cela peut entrainer le blocage de l'administrateur hors de son propre serveur, s'il n'a pas son ordinateur sous la main (on peut voir ça comme un avantage pour la sécurité : l'administrateur ne devrait pas se loguer en SSH en utilisant une machine quelconque).
Ceci dit, sur Android, je ne connais aucun client SSH qui puisse utiliser les clés pour l'authentification.
-- 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 Fri, Dec 17, 2010 at 06:37:53PM +0100,
Alain Vaugham <alain@vaugham.com> wrote
a message of 29 lines which said:
j'oblige l'identification par clefs.
C'est sûr que c'est sûr mais cela peut entrainer le blocage de
l'administrateur hors de son propre serveur, s'il n'a pas son
ordinateur sous la main (on peut voir ça comme un avantage pour la
sécurité : l'administrateur ne devrait pas se loguer en SSH en
utilisant une machine quelconque).
Ceci dit, sur Android, je ne connais aucun client SSH qui puisse
utiliser les clés pour l'authentification.
--
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/20101217213527.GB21373@sources.org
On Fri, Dec 17, 2010 at 06:37:53PM +0100, Alain Vaugham wrote a message of 29 lines which said:
j'oblige l'identification par clefs.
C'est sûr que c'est sûr mais cela peut entrainer le blocage de l'administrateur hors de son propre serveur, s'il n'a pas son ordinateur sous la main (on peut voir ça comme un avantage pour la sécurité : l'administrateur ne devrait pas se loguer en SSH en utilisant une machine quelconque).
Ceci dit, sur Android, je ne connais aucun client SSH qui puisse utiliser les clés pour l'authentification.
-- 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/
--
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/1292622331.2107.0.camel@bouriquet
