j'ai un serveur web que j'administre à distance via ssh (machine debian Sarge).
Tout ce qu'il y a de plus classique. J'ai vu dans mes logs auth.log des entrées
qui me paraissent suspectes. Il doit s'agir de tentatives d'attaques ssh.
Voilà ce que disent les logs :
Illegal user test from 219.136.9.84
Dec 4 23:53:46 myserver sshd[22991]: error: Could not get shadow information
for NOUSER
Dec 4 23:53:46 myserver sshd[22991]: Failed password for illegal user test from
219.136.9.84 port 56232 ssh2
Dec 4 23:53:49 myserver sshd[22993]: Illegal user guest from 219.136.9.84
Dec 4 23:53:49 myserver sshd[22993]: error: Could not get shadow information
for NOUSER
Qu'est-ce que cela signifie exactement?
Comment sécuriser ssh pour éviter ces attaques?
Comment savoir si l'attaque a abouti?
Merci
Stéphane
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Ca ressemble bien a une "attaque" : pour fiabiliser les choses : 1) interdire le login de root, 2) changer le port par default pour un autre que 22, 3) eventuellement installer iptable en autorisant que des adresses a toi a passer sur le port de ssh 4) utiliser le principe des cles.
pour savoir si l'attaque est passée, ben il faut une ligne du genre : Dec 5 06:40:56 localhost sshd[4293]: Accepted password for toto from iii.iii.iii.iii port 44696 ssh2
le probleme c'est que ca peut aussi bien etre toi qui t'es connecté.... et surtout si le pirate est bon il effacera ces traces.
Il y a peut etre d'autre facon de savoir mais je ne les connais pas.
@plus !
arnaud boulliat
a écrit :
Bonjour,
j'ai un serveur web que j'administre à distance via ssh (machine debian Sarge). Tout ce qu'il y a de plus classique. J'ai vu dans mes logs auth.log des entrées qui me paraissent suspectes. Il doit s'agir de tentatives d'attaques ssh. Voilà ce que disent les logs :
Illegal user test from 219.136.9.84 Dec 4 23:53:46 myserver sshd[22991]: error: Could not get shadow information for NOUSER Dec 4 23:53:46 myserver sshd[22991]: Failed password for illegal user test from 219.136.9.84 port 56232 ssh2 Dec 4 23:53:49 myserver sshd[22993]: Illegal user guest from 219.136.9.84 Dec 4 23:53:49 myserver sshd[22993]: error: Could not get shadow information for NOUSER
Qu'est-ce que cela signifie exactement? Comment sécuriser ssh pour éviter ces attaques? Comment savoir si l'attaque a abouti?
Merci Stéphane
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Salut !
Ca ressemble bien a une "attaque" :
pour fiabiliser les choses :
1) interdire le login de root,
2) changer le port par default pour un autre que 22,
3) eventuellement installer iptable en autorisant que des adresses a toi
a passer sur le port de ssh
4) utiliser le principe des cles.
pour savoir si l'attaque est passée, ben il faut une ligne du genre :
Dec 5 06:40:56 localhost sshd[4293]: Accepted password for toto from
iii.iii.iii.iii port 44696 ssh2
le probleme c'est que ca peut aussi bien etre toi qui t'es connecté....
et surtout si le pirate est bon il effacera ces traces.
Il y a peut etre d'autre facon de savoir mais je ne les connais pas.
@plus !
arnaud boulliat
spetrot@free.fr a écrit :
Bonjour,
j'ai un serveur web que j'administre à distance via ssh (machine debian Sarge).
Tout ce qu'il y a de plus classique. J'ai vu dans mes logs auth.log des entrées
qui me paraissent suspectes. Il doit s'agir de tentatives d'attaques ssh.
Voilà ce que disent les logs :
Illegal user test from 219.136.9.84
Dec 4 23:53:46 myserver sshd[22991]: error: Could not get shadow information
for NOUSER
Dec 4 23:53:46 myserver sshd[22991]: Failed password for illegal user test from
219.136.9.84 port 56232 ssh2
Dec 4 23:53:49 myserver sshd[22993]: Illegal user guest from 219.136.9.84
Dec 4 23:53:49 myserver sshd[22993]: error: Could not get shadow information
for NOUSER
Qu'est-ce que cela signifie exactement?
Comment sécuriser ssh pour éviter ces attaques?
Comment savoir si l'attaque a abouti?
Merci
Stéphane
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Ca ressemble bien a une "attaque" : pour fiabiliser les choses : 1) interdire le login de root, 2) changer le port par default pour un autre que 22, 3) eventuellement installer iptable en autorisant que des adresses a toi a passer sur le port de ssh 4) utiliser le principe des cles.
pour savoir si l'attaque est passée, ben il faut une ligne du genre : Dec 5 06:40:56 localhost sshd[4293]: Accepted password for toto from iii.iii.iii.iii port 44696 ssh2
le probleme c'est que ca peut aussi bien etre toi qui t'es connecté.... et surtout si le pirate est bon il effacera ces traces.
Il y a peut etre d'autre facon de savoir mais je ne les connais pas.
@plus !
arnaud boulliat
a écrit :
Bonjour,
j'ai un serveur web que j'administre à distance via ssh (machine debian Sarge). Tout ce qu'il y a de plus classique. J'ai vu dans mes logs auth.log des entrées qui me paraissent suspectes. Il doit s'agir de tentatives d'attaques ssh. Voilà ce que disent les logs :
Illegal user test from 219.136.9.84 Dec 4 23:53:46 myserver sshd[22991]: error: Could not get shadow information for NOUSER Dec 4 23:53:46 myserver sshd[22991]: Failed password for illegal user test from 219.136.9.84 port 56232 ssh2 Dec 4 23:53:49 myserver sshd[22993]: Illegal user guest from 219.136.9.84 Dec 4 23:53:49 myserver sshd[22993]: error: Could not get shadow information for NOUSER
Qu'est-ce que cela signifie exactement? Comment sécuriser ssh pour éviter ces attaques? Comment savoir si l'attaque a abouti?
Merci Stéphane
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Yann Lejeune
On 2006/12/05-09:06(+0100), wrote :
Qu'est-ce que cela signifie exactement? Comment sécuriser ssh pour éviter ces attaques? Comment savoir si l'attaque a abouti?
Ce sont des tentatives de connexion en utilisant des comptes "classiques".
Le meilleur moyen de se protéger c'est :
- Refuser les connexions via le compte root (PermitRootLogin no) - Spécifier les comptes qui ont le droit de se connecter (AllowUsers/AllowGroups) - Forcer les utilisateurs à avoir de vrai mot de passe - Mieux encore : n'accepter que l'authentification via clé publique. - Désaciver tous les comptes qui ne sont pas nécessaires et mettre un /bin/false en shell aux utilisateurs qui n'en ont pas besoin. - Configurer SSH pour n'écouter que sur les interfaces auxquelles vous vous connectez - Via IPTables n'autoriser que les machines à partir desquelles vous vous connectez à ouvrir une session tcp sur le port 22. - Eventuellement changer le port d'écoute de sshd - Installer fail2ban, qui apres une serie de mauvaise authentification, installera des règles IPTables pour blacklister la source.
Avec ca ton serveur sera un minimun configuré correctement. Après dès qu'on mets un service avec authentification accessible sur internet (ssh ftp...), il faut inévitablement s'attendre à ce que des bots, ou mêmes des personnes, tentent d'y accéder via brute force, ou attaque par dictionnaire.
Yann.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
On 2006/12/05-09:06(+0100), spetrot@free.fr wrote :
Qu'est-ce que cela signifie exactement?
Comment sécuriser ssh pour éviter ces attaques?
Comment savoir si l'attaque a abouti?
Ce sont des tentatives de connexion en utilisant des comptes
"classiques".
Le meilleur moyen de se protéger c'est :
- Refuser les connexions via le compte root (PermitRootLogin no)
- Spécifier les comptes qui ont le droit de se connecter
(AllowUsers/AllowGroups)
- Forcer les utilisateurs à avoir de vrai mot de passe
- Mieux encore : n'accepter que l'authentification via clé publique.
- Désaciver tous les comptes qui ne sont pas nécessaires et mettre un
/bin/false en shell aux utilisateurs qui n'en ont pas besoin.
- Configurer SSH pour n'écouter que sur les interfaces auxquelles vous
vous connectez
- Via IPTables n'autoriser que les machines à partir desquelles vous
vous connectez à ouvrir une session tcp sur le port 22.
- Eventuellement changer le port d'écoute de sshd
- Installer fail2ban, qui apres une serie de mauvaise authentification,
installera des règles IPTables pour blacklister la source.
Avec ca ton serveur sera un minimun configuré correctement. Après dès qu'on
mets un service avec authentification accessible sur internet (ssh ftp...),
il faut inévitablement s'attendre à ce que des bots, ou mêmes des
personnes, tentent d'y accéder via brute force, ou attaque par
dictionnaire.
Yann.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Qu'est-ce que cela signifie exactement? Comment sécuriser ssh pour éviter ces attaques? Comment savoir si l'attaque a abouti?
Ce sont des tentatives de connexion en utilisant des comptes "classiques".
Le meilleur moyen de se protéger c'est :
- Refuser les connexions via le compte root (PermitRootLogin no) - Spécifier les comptes qui ont le droit de se connecter (AllowUsers/AllowGroups) - Forcer les utilisateurs à avoir de vrai mot de passe - Mieux encore : n'accepter que l'authentification via clé publique. - Désaciver tous les comptes qui ne sont pas nécessaires et mettre un /bin/false en shell aux utilisateurs qui n'en ont pas besoin. - Configurer SSH pour n'écouter que sur les interfaces auxquelles vous vous connectez - Via IPTables n'autoriser que les machines à partir desquelles vous vous connectez à ouvrir une session tcp sur le port 22. - Eventuellement changer le port d'écoute de sshd - Installer fail2ban, qui apres une serie de mauvaise authentification, installera des règles IPTables pour blacklister la source.
Avec ca ton serveur sera un minimun configuré correctement. Après dès qu'on mets un service avec authentification accessible sur internet (ssh ftp...), il faut inévitablement s'attendre à ce que des bots, ou mêmes des personnes, tentent d'y accéder via brute force, ou attaque par dictionnaire.
Yann.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Romain Wisniewski
On 12/5/06, wrote:
Bonjour,
j'ai un serveur web que j'administre à distance via ssh (machine debian Sarge). Tout ce qu'il y a de plus classique. J'ai vu dans mes logs auth.log des e ntrées qui me paraissent suspectes. Il doit s'agir de tentatives d'attaques ssh. Voilà ce que disent les logs :
Illegal user test from 219.136.9.84 Dec 4 23:53:46 myserver sshd[22991]: error: Could not get shadow informa tion for NOUSER Dec 4 23:53:46 myserver sshd[22991]: Failed password for illegal user te st from 219.136.9.84 port 56232 ssh2 Dec 4 23:53:49 myserver sshd[22993]: Illegal user guest from 219.136.9.8 4 Dec 4 23:53:49 myserver sshd[22993]: error: Could not get shadow informa tion for NOUSER
Qu'est-ce que cela signifie exactement? Comment sécuriser ssh pour éviter ces attaques? Comment savoir si l'attaque a abouti?
Merci Stéphane
Bonjour,
Effectivement c'est une attaque, la pluipart du temps se sont des vers qui tentent des attaques par dicitonnaire sur les ports SSH ouverts dans des plages d'adresses. C'est très fréquent.
Si tu te sens l'âme charitable, tu peux faire un whois sur l'IP et écrire un mail au service abuse des administrateur pour qu'ils solutionnent le problème de leur coté.
Solutions en vrac pour sécuriser de ton coté : - faire écouter SSH sur un port différent (tu évites quasiement toute s les attaques automatiques) - enlever l'authentification par mot de passe - utiliser le port knocking (un peu extreme, mais tres efficace)
Bonne journée...
-- + Romain.
On 12/5/06, spetrot@free.fr <spetrot@free.fr> wrote:
Bonjour,
j'ai un serveur web que j'administre à distance via ssh (machine debian Sarge).
Tout ce qu'il y a de plus classique. J'ai vu dans mes logs auth.log des e ntrées
qui me paraissent suspectes. Il doit s'agir de tentatives d'attaques ssh.
Voilà ce que disent les logs :
Illegal user test from 219.136.9.84
Dec 4 23:53:46 myserver sshd[22991]: error: Could not get shadow informa tion
for NOUSER
Dec 4 23:53:46 myserver sshd[22991]: Failed password for illegal user te st from
219.136.9.84 port 56232 ssh2
Dec 4 23:53:49 myserver sshd[22993]: Illegal user guest from 219.136.9.8 4
Dec 4 23:53:49 myserver sshd[22993]: error: Could not get shadow informa tion
for NOUSER
Qu'est-ce que cela signifie exactement?
Comment sécuriser ssh pour éviter ces attaques?
Comment savoir si l'attaque a abouti?
Merci
Stéphane
Bonjour,
Effectivement c'est une attaque, la pluipart du temps se sont des vers
qui tentent des attaques par dicitonnaire sur les ports SSH ouverts
dans des plages d'adresses. C'est très fréquent.
Si tu te sens l'âme charitable, tu peux faire un whois sur l'IP et
écrire un mail au service abuse des administrateur pour qu'ils
solutionnent le problème de leur coté.
Solutions en vrac pour sécuriser de ton coté :
- faire écouter SSH sur un port différent (tu évites quasiement toute s
les attaques automatiques)
- enlever l'authentification par mot de passe
- utiliser le port knocking (un peu extreme, mais tres efficace)
j'ai un serveur web que j'administre à distance via ssh (machine debian Sarge). Tout ce qu'il y a de plus classique. J'ai vu dans mes logs auth.log des e ntrées qui me paraissent suspectes. Il doit s'agir de tentatives d'attaques ssh. Voilà ce que disent les logs :
Illegal user test from 219.136.9.84 Dec 4 23:53:46 myserver sshd[22991]: error: Could not get shadow informa tion for NOUSER Dec 4 23:53:46 myserver sshd[22991]: Failed password for illegal user te st from 219.136.9.84 port 56232 ssh2 Dec 4 23:53:49 myserver sshd[22993]: Illegal user guest from 219.136.9.8 4 Dec 4 23:53:49 myserver sshd[22993]: error: Could not get shadow informa tion for NOUSER
Qu'est-ce que cela signifie exactement? Comment sécuriser ssh pour éviter ces attaques? Comment savoir si l'attaque a abouti?
Merci Stéphane
Bonjour,
Effectivement c'est une attaque, la pluipart du temps se sont des vers qui tentent des attaques par dicitonnaire sur les ports SSH ouverts dans des plages d'adresses. C'est très fréquent.
Si tu te sens l'âme charitable, tu peux faire un whois sur l'IP et écrire un mail au service abuse des administrateur pour qu'ils solutionnent le problème de leur coté.
Solutions en vrac pour sécuriser de ton coté : - faire écouter SSH sur un port différent (tu évites quasiement toute s les attaques automatiques) - enlever l'authentification par mot de passe - utiliser le port knocking (un peu extreme, mais tres efficace)
Bonne journée...
-- + Romain.
Jean-Michel OLTRA
Bonjour,
Le mardi 05 décembre 2006, Yann Lejeune a écrit...
Avec ca ton serveur sera un minimun configuré correctement. Après dès qu'on mets un service avec authentification accessible sur internet (ssh ftp...), il faut inévitablement s'attendre à ce que des bots, ou mêmes des personnes, tentent d'y accéder via brute force, ou attaque par dictionnaire.
Il y a également la directive MaxStartups qui peut freiner un peu. Le maximum par défaut semble être à 60, ce qui est élevé.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Bonjour,
Le mardi 05 décembre 2006, Yann Lejeune a écrit...
Avec ca ton serveur sera un minimun configuré correctement. Après dès qu'on
mets un service avec authentification accessible sur internet (ssh ftp...),
il faut inévitablement s'attendre à ce que des bots, ou mêmes des
personnes, tentent d'y accéder via brute force, ou attaque par
dictionnaire.
Il y a également la directive MaxStartups qui peut freiner un peu. Le
maximum par défaut semble être à 60, ce qui est élevé.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Le mardi 05 décembre 2006, Yann Lejeune a écrit...
Avec ca ton serveur sera un minimun configuré correctement. Après dès qu'on mets un service avec authentification accessible sur internet (ssh ftp...), il faut inévitablement s'attendre à ce que des bots, ou mêmes des personnes, tentent d'y accéder via brute force, ou attaque par dictionnaire.
Il y a également la directive MaxStartups qui peut freiner un peu. Le maximum par défaut semble être à 60, ce qui est élevé.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Laurent Besson
Le Mardi 5 Décembre 2006 09:26, Yann Lejeune a écrit :
On 2006/12/05-09:06(+0100), wrote :
....
Avec ca ton serveur sera un minimun configuré correctement. Après d ès qu'on mets un service avec authentification accessible sur internet (ssh ftp... ), il faut inévitablement s'attendre à ce que des bots, ou mêmes des personnes, tentent d'y accéder via brute force, ou attaque par dictionnaire.
Yann.
Quelqu'un m'a fait découvrir le programme "knockd"... Qui permet de laisser fermé les ports sensibles SSH, FTP... Mais lorsqu'il est invoqué avec la bonne conf, ouvre les ports voulus pen dant un certain temps "time_out"
Le Mardi 5 Décembre 2006 09:26, Yann Lejeune a écrit :
On 2006/12/05-09:06(+0100), spetrot@free.fr wrote :
....
Avec ca ton serveur sera un minimun configuré correctement. Après d ès qu'on
mets un service avec authentification accessible sur internet (ssh ftp... ),
il faut inévitablement s'attendre à ce que des bots, ou mêmes des
personnes, tentent d'y accéder via brute force, ou attaque par
dictionnaire.
Yann.
Quelqu'un m'a fait découvrir le programme "knockd"...
Qui permet de laisser fermé les ports sensibles SSH, FTP...
Mais lorsqu'il est invoqué avec la bonne conf, ouvre les ports voulus pen dant
un certain temps "time_out"
Le Mardi 5 Décembre 2006 09:26, Yann Lejeune a écrit :
On 2006/12/05-09:06(+0100), wrote :
....
Avec ca ton serveur sera un minimun configuré correctement. Après d ès qu'on mets un service avec authentification accessible sur internet (ssh ftp... ), il faut inévitablement s'attendre à ce que des bots, ou mêmes des personnes, tentent d'y accéder via brute force, ou attaque par dictionnaire.
Yann.
Quelqu'un m'a fait découvrir le programme "knockd"... Qui permet de laisser fermé les ports sensibles SSH, FTP... Mais lorsqu'il est invoqué avec la bonne conf, ouvre les ports voulus pen dant un certain temps "time_out"
Le Mardi 5 Décembre 2006 13:47, Laurent Besson a écrit :
Le Mardi 5 Décembre 2006 09:26, Yann Lejeune a écrit :
...
Quelqu'un m'a fait découvrir le programme "knockd"... Qui permet de laisser fermé les ports sensibles SSH, FTP... Mais lorsqu'il est invoqué avec la bonne conf, ouvre les ports voulus pendant un certain temps "time_out"
Il en existe au moins deux : knockd knock
...
Le Mardi 5 Décembre 2006 13:47, Laurent Besson a écrit :
Le Mardi 5 Décembre 2006 09:26, Yann Lejeune a écrit :
...
Quelqu'un m'a fait découvrir le programme "knockd"...
Qui permet de laisser fermé les ports sensibles SSH, FTP...
Mais lorsqu'il est invoqué avec la bonne conf, ouvre les ports voulus
pendant un certain temps "time_out"
Le Mardi 5 Décembre 2006 13:47, Laurent Besson a écrit :
Le Mardi 5 Décembre 2006 09:26, Yann Lejeune a écrit :
...
Quelqu'un m'a fait découvrir le programme "knockd"... Qui permet de laisser fermé les ports sensibles SSH, FTP... Mais lorsqu'il est invoqué avec la bonne conf, ouvre les ports voulus pendant un certain temps "time_out"
Il en existe au moins deux : knockd knock
...
Paul Filo
> Bonjour,
Effectivement c'est une attaque, la pluipart du temps se sont des vers qui tentent des attaques par dicitonnaire sur les ports SSH ouverts dans des plages d'adresses. C'est très fréquent.
Si tu te sens l'âme charitable, tu peux faire un whois sur l'IP et écrire un mail au service abuse des administrateur pour qu'ils solutionnent le problème de leur coté.
Solutions en vrac pour sécuriser de ton coté : - faire écouter SSH sur un port différent (tu évites quasiement toutes les attaques automatiques) - enlever l'authentification par mot de passe - utiliser le port knocking (un peu extreme, mais tres efficace)
Moi j'utilise les règles iptables suivantes qui autorisent 1 connexion par minute (ou moins si on veut) et par ip sur le port ssh. Ca permet de calmer les tentatives avec différents users en rafale sans géner l'utilisation normale :
# Limite connexion ssh iptables -A INPUT -m hashlimit -m tcp -p tcp --dport 22 -i $INTER_IF --hashlimit 1/min --hashlimit-mode srcip --hashlimit-name ssh -m state --state NEW -j ACCEPT iptables -A INPUT -m tcp -p tcp --dport 22 -i $INTER_IF -m state --state NEW -j REJECT
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
> Bonjour,
Effectivement c'est une attaque, la pluipart du temps se sont des vers
qui tentent des attaques par dicitonnaire sur les ports SSH ouverts
dans des plages d'adresses. C'est très fréquent.
Si tu te sens l'âme charitable, tu peux faire un whois sur l'IP et
écrire un mail au service abuse des administrateur pour qu'ils
solutionnent le problème de leur coté.
Solutions en vrac pour sécuriser de ton coté :
- faire écouter SSH sur un port différent (tu évites quasiement toutes
les attaques automatiques)
- enlever l'authentification par mot de passe
- utiliser le port knocking (un peu extreme, mais tres efficace)
Moi j'utilise les règles iptables suivantes qui autorisent 1 connexion
par minute (ou moins si on veut) et par ip sur le port ssh. Ca permet de
calmer les tentatives avec différents users en rafale sans géner
l'utilisation normale :
# Limite connexion ssh
iptables -A INPUT -m hashlimit -m tcp -p tcp --dport 22 -i $INTER_IF
--hashlimit 1/min --hashlimit-mode srcip --hashlimit-name ssh -m
state --state NEW -j ACCEPT
iptables -A INPUT -m tcp -p tcp --dport 22 -i $INTER_IF -m state --state
NEW -j REJECT
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Effectivement c'est une attaque, la pluipart du temps se sont des vers qui tentent des attaques par dicitonnaire sur les ports SSH ouverts dans des plages d'adresses. C'est très fréquent.
Si tu te sens l'âme charitable, tu peux faire un whois sur l'IP et écrire un mail au service abuse des administrateur pour qu'ils solutionnent le problème de leur coté.
Solutions en vrac pour sécuriser de ton coté : - faire écouter SSH sur un port différent (tu évites quasiement toutes les attaques automatiques) - enlever l'authentification par mot de passe - utiliser le port knocking (un peu extreme, mais tres efficace)
Moi j'utilise les règles iptables suivantes qui autorisent 1 connexion par minute (ou moins si on veut) et par ip sur le port ssh. Ca permet de calmer les tentatives avec différents users en rafale sans géner l'utilisation normale :
# Limite connexion ssh iptables -A INPUT -m hashlimit -m tcp -p tcp --dport 22 -i $INTER_IF --hashlimit 1/min --hashlimit-mode srcip --hashlimit-name ssh -m state --state NEW -j ACCEPT iptables -A INPUT -m tcp -p tcp --dport 22 -i $INTER_IF -m state --state NEW -j REJECT
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Jerome Moinet
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Comment sécuriser ssh pour éviter ces attaques?
En plus des autres solutions, fail2ban, simple et efficace. Ca bloque dans iptables l'ip de l'attaquant pour x heures après n tentatives de connexion failed (chez moi ça bloque pour 600 heures au bout de 3 tentatives).
jerome
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Comment sécuriser ssh pour éviter ces attaques?
En plus des autres solutions, fail2ban, simple et efficace. Ca bloque
dans iptables l'ip de l'attaquant pour x heures après n tentatives de
connexion failed (chez moi ça bloque pour 600 heures au bout de 3
tentatives).
jerome
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
En plus des autres solutions, fail2ban, simple et efficace. Ca bloque dans iptables l'ip de l'attaquant pour x heures après n tentatives de connexion failed (chez moi ça bloque pour 600 heures au bout de 3 tentatives).
jerome
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Pascal Hambourg
Salut
Paul Filo a écrit :
Moi j'utilise les règles iptables suivantes qui autorisent 1 connexion par minute (ou moins si on veut) et par ip sur le port ssh. Ca permet de calmer les tentatives avec différents users en rafale sans géner l'utilisation normale :
Sans gêner, c'est vite dit. Ce genre de limitation permet de réaliser de beaux dénis de service par usurpation de l'adresse IP source.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Salut
Paul Filo a écrit :
Moi j'utilise les règles iptables suivantes qui autorisent 1 connexion
par minute (ou moins si on veut) et par ip sur le port ssh. Ca permet de
calmer les tentatives avec différents users en rafale sans géner
l'utilisation normale :
Sans gêner, c'est vite dit. Ce genre de limitation permet de réaliser de
beaux dénis de service par usurpation de l'adresse IP source.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Moi j'utilise les règles iptables suivantes qui autorisent 1 connexion par minute (ou moins si on veut) et par ip sur le port ssh. Ca permet de calmer les tentatives avec différents users en rafale sans géner l'utilisation normale :
Sans gêner, c'est vite dit. Ce genre de limitation permet de réaliser de beaux dénis de service par usurpation de l'adresse IP source.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Paul Filo
Le 07/12/2006 23:45 Pascal Hambourg a dit :
Salut
Paul Filo a écrit :
Moi j'utilise les règles iptables suivantes qui autorisent 1 connexion par minute (ou moins si on veut) et par ip sur le port ssh. Ca permet de calmer les tentatives avec différents users en rafale sans géner l'utilisation normale :
Sans gêner, c'est vite dit. Ce genre de limitation permet de réaliser de beaux dénis de service par usurpation de l'adresse IP source.
C'est vrai mais c'est également le cas de fail2ban (qui a le même défaut) et de toutes les solutions sur IP source. La solution la plus élégante est sans doute le port-knocking mais qui oblige le firewall sur lequel on sort à avoir pas mal de ports ouverts (rarement le cas).
Et puis dans la pratique, pour un serveur ssh chez soi, depuis 2 ans que j'utilise ces règles, je n'ai jamais eu aucun souci pour me connecter et ça a bien limité l'impact des tentatives.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Le 07/12/2006 23:45 Pascal Hambourg a dit :
Salut
Paul Filo a écrit :
Moi j'utilise les règles iptables suivantes qui autorisent 1 connexion
par minute (ou moins si on veut) et par ip sur le port ssh. Ca permet de
calmer les tentatives avec différents users en rafale sans géner
l'utilisation normale :
Sans gêner, c'est vite dit. Ce genre de limitation permet de réaliser de
beaux dénis de service par usurpation de l'adresse IP source.
C'est vrai mais c'est également le cas de fail2ban (qui a le même
défaut) et de toutes les solutions sur IP source. La solution la plus
élégante est sans doute le port-knocking mais qui oblige le firewall sur
lequel on sort à avoir pas mal de ports ouverts (rarement le cas).
Et puis dans la pratique, pour un serveur ssh chez soi, depuis 2 ans que
j'utilise ces règles, je n'ai jamais eu aucun souci pour me connecter et
ça a bien limité l'impact des tentatives.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Moi j'utilise les règles iptables suivantes qui autorisent 1 connexion par minute (ou moins si on veut) et par ip sur le port ssh. Ca permet de calmer les tentatives avec différents users en rafale sans géner l'utilisation normale :
Sans gêner, c'est vite dit. Ce genre de limitation permet de réaliser de beaux dénis de service par usurpation de l'adresse IP source.
C'est vrai mais c'est également le cas de fail2ban (qui a le même défaut) et de toutes les solutions sur IP source. La solution la plus élégante est sans doute le port-knocking mais qui oblige le firewall sur lequel on sort à avoir pas mal de ports ouverts (rarement le cas).
Et puis dans la pratique, pour un serveur ssh chez soi, depuis 2 ans que j'utilise ces règles, je n'ai jamais eu aucun souci pour me connecter et ça a bien limité l'impact des tentatives.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
