Ci-apr=E8s le contenu de deux logchecks de ce matin. Il me semble qu'il
s'agit de tentatives (infructueuses:) de se loguer sur ma machine via
ssh.
Quelqu'un peut-il m'indiquer comment je devrais r=E9agir en termes de
s=E9curisation, identification (commandes) et r=E9pression (abuse)?
Journal de 5h02:
Security Events
=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D
Mar 23 04:46:03 GDem3 sshd[11168]: Failed password for illegal user
test from ::ffff:211.176.33.46 port 50152 ssh2 Mar 23 04:46:06 GDem3
sshd[11174]: Failed password for illegal user guest from
::ffff:211.176.33.46 port 50252 ssh2 Mar 23 04:46:08 GDem3 sshd[11176]:
Illegal user admin from ::ffff:211.176.33.46 Mar 23 04:46:08 GDem3
sshd[11176]: Failed password for illegal user admin from
::ffff:211.176.33.46 port 50344 ssh2 Mar 23 04:46:11 GDem3 sshd[11182]:
Illegal user admin from ::ffff:211.176.33.46 Mar 23 04:46:11 GDem3
sshd[11182]: Failed password for illegal user admin from
::ffff:211.176.33.46 port 50439 ssh2 Mar 23 04:46:14 GDem3 sshd[11184]:
Failed password for illegal user user from ::ffff:211.176.33.46 port
50526 ssh2 Mar 23 04:46:17 GDem3 sshd[11190]: Failed password for root
from ::ffff:211.176.33.46 port 50618 ssh2 Mar 23 04:46:20 GDem3
sshd[11192]: Failed password for root from ::ffff:211.176.33.46 port
50711 ssh2 Mar 23 04:46:23 GDem3 sshd[11199]: Failed password for root
from ::ffff:211.176.33.46 port 50797 ssh2 Mar 23 04:46:26 GDem3
sshd[11201]: Failed password for illegal user test from
::ffff:211.176.33.46 port 50890 ssh2
System Events
=3D-=3D-=3D-=3D-=3D-=3D-=3D
Mar 23 04:46:03 GDem3 sshd[11168]: Illegal user test from
::ffff:211.176.33.46 Mar 23 04:46:03 GDem3 sshd[11168]: error: Could not
get shadow information for NOUSER Mar 23 04:46:06 GDem3 sshd[11174]:
Illegal user guest from ::ffff:211.176.33.46 Mar 23 04:46:06 GDem3
sshd[11174]: error: Could not get shadow information for NOUSER Mar 23
04:46:08 GDem3 sshd[11176]: error: Could not get shadow information for
NOUSER Mar 23 04:46:11 GDem3 sshd[11182]: error: Could not get shadow
information for NOUSER Mar 23 04:46:14 GDem3 sshd[11184]: Illegal user
user from ::ffff:211.176.33.46 Mar 23 04:46:14 GDem3 sshd[11184]: error:
Could not get shadow information for NOUSER Mar 23 04:46:26 GDem3
sshd[11201]: Illegal user test from ::ffff:211.176.33.46 Mar 23 04:46:26
GDem3 sshd[11201]: error: Could not get shadow information for NOUSER
Journal de 10h02:
Security Events
=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D
Mar 23 09:11:39 GDem3 sshd[27590]: Failed password for root from
::ffff:62.193.236.45 port 45567 ssh2 Mar 23 09:11:40 GDem3 sshd[27592]:
Failed password for root from ::ffff:62.193.236.45 port 45687 ssh2 Mar
23 09:11:41 GDem3 sshd[27594]: Failed password for root from
::ffff:62.193.236.45 port 45769 ssh2 Mar 23 09:11:42 GDem3 sshd[27596]:
Failed password for root from ::ffff:62.193.236.45 port 45851 ssh2 Mar
23 09:11:42 GDem3 sshd[27598]: Failed password for root from
::ffff:62.193.236.45 port 45936 ssh2 Mar 23 09:11:43 GDem3 sshd[27600]:
Failed password for root from ::ffff:62.193.236.45 port 46006 ssh2 Mar
23 09:11:44 GDem3 sshd[27602]: Failed password for root from
::ffff:62.193.236.45 port 46076 ssh2 Mar 23 09:11:44 GDem3 sshd[27608]:
Failed password for root from ::ffff:62.193.236.45 port 46156 ssh2
On Wed, Mar 23, 2005 at 11:26:12AM +0100, Gwendal Demaille wrote:
Ci-après le contenu de deux logchecks de ce matin. Il me semble qu'il s'agit de tentatives (infructueuses:) de se loguer sur ma machine via ssh.
J'ai au moins 10 tentatives de ce genre par jour...
Quelqu'un peut-il m'indiquer comment je devrais réagir en termes de sécurisation, identification (commandes) et répression (abuse)?
Si tu as un noyau récent avec ipt-recent, tu peux tenter de rajouter des règles dans le style (à ajuster en fonction de tes besoins):
iptables -A INPUT -i eth0 -p tcp --dport ssh -m state --state NEW -m recent --set --name SSH iptables -A INPUT -i eth0 -p tcp --dport ssh -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
Ça n'autorise que 3 tentatives de connection en SSH par IP en minute et il faut ensuite une minute sans connexion pour que le SSH soit de nouveau autorisé depuis cette IP. Ça devrait calmer ceux qui font de la force brute !
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
On Wed, Mar 23, 2005 at 11:26:12AM +0100, Gwendal Demaille wrote:
Ci-après le contenu de deux logchecks de ce matin. Il me semble qu'il
s'agit de tentatives (infructueuses:) de se loguer sur ma machine via
ssh.
J'ai au moins 10 tentatives de ce genre par jour...
Quelqu'un peut-il m'indiquer comment je devrais réagir en termes de
sécurisation, identification (commandes) et répression (abuse)?
Si tu as un noyau récent avec ipt-recent, tu peux tenter de rajouter des
règles dans le style (à ajuster en fonction de tes besoins):
iptables -A INPUT -i eth0 -p tcp --dport ssh -m state --state NEW -m recent --set --name SSH
iptables -A INPUT -i eth0 -p tcp --dport ssh -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
Ça n'autorise que 3 tentatives de connection en SSH par IP en
minute et il faut ensuite une minute sans connexion pour que le SSH soit
de nouveau autorisé depuis cette IP. Ça devrait calmer ceux qui font de
la force brute !
On Wed, Mar 23, 2005 at 11:26:12AM +0100, Gwendal Demaille wrote:
Ci-après le contenu de deux logchecks de ce matin. Il me semble qu'il s'agit de tentatives (infructueuses:) de se loguer sur ma machine via ssh.
J'ai au moins 10 tentatives de ce genre par jour...
Quelqu'un peut-il m'indiquer comment je devrais réagir en termes de sécurisation, identification (commandes) et répression (abuse)?
Si tu as un noyau récent avec ipt-recent, tu peux tenter de rajouter des règles dans le style (à ajuster en fonction de tes besoins):
iptables -A INPUT -i eth0 -p tcp --dport ssh -m state --state NEW -m recent --set --name SSH iptables -A INPUT -i eth0 -p tcp --dport ssh -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
Ça n'autorise que 3 tentatives de connection en SSH par IP en minute et il faut ensuite une minute sans connexion pour que le SSH soit de nouveau autorisé depuis cette IP. Ça devrait calmer ceux qui font de la force brute !
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Vincent Lefevre
On 2005-03-23 13:03:37 +0100, antoine roy wrote:
la meilleure chose à faire est encore de ne pas autoriser les connections sur le 22 depuis partout .
Le problème est que l'on ne connaît pas forcément à l'avance les IP à partir desquelles on risque de se connecter. D'où ma question: existe-t-il des blacklists d'IP concernant le ssh, comme il y en a pour le spam?
D'autre part, est-il possible de configurer sshd pour autoriser seulement certains utilisateurs à se connecter par ssh? (Un peu comme le PermitRootLogin, mais l'inverse...)
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
On 2005-03-23 13:03:37 +0100, antoine roy wrote:
la meilleure chose à faire est encore de ne pas autoriser les
connections sur le 22 depuis partout .
Le problème est que l'on ne connaît pas forcément à l'avance les IP
à partir desquelles on risque de se connecter. D'où ma question:
existe-t-il des blacklists d'IP concernant le ssh, comme il y en
a pour le spam?
D'autre part, est-il possible de configurer sshd pour autoriser
seulement certains utilisateurs à se connecter par ssh? (Un peu
comme le PermitRootLogin, mais l'inverse...)
la meilleure chose à faire est encore de ne pas autoriser les connections sur le 22 depuis partout .
Le problème est que l'on ne connaît pas forcément à l'avance les IP à partir desquelles on risque de se connecter. D'où ma question: existe-t-il des blacklists d'IP concernant le ssh, comme il y en a pour le spam?
D'autre part, est-il possible de configurer sshd pour autoriser seulement certains utilisateurs à se connecter par ssh? (Un peu comme le PermitRootLogin, mais l'inverse...)
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Vincent Lefevre
On 2005-03-23 16:41:32 +0100, Aurelien Jarno wrote:
Si tu as un noyau récent avec ipt-recent, tu peux tenter de rajouter des règles dans le style (à ajuster en fonction de tes besoins):
iptables -A INPUT -i eth0 -p tcp --dport ssh -m state --state NEW -m recent --set --name SSH iptables -A INPUT -i eth0 -p tcp --dport ssh -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
Ça n'autorise que 3 tentatives de connection en SSH par IP en minute et il faut ensuite une minute sans connexion pour que le SSH soit de nouveau autorisé depuis cette IP. Ça devrait calmer ceux qui font de la force brute !
C'est idiot quand on utilise certains outils, comme Subversion, qui peut faire jusqu'à (au moins) 5 connexions ssh à la suite pour une seule commande.
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
On 2005-03-23 16:41:32 +0100, Aurelien Jarno wrote:
Si tu as un noyau récent avec ipt-recent, tu peux tenter de rajouter des
règles dans le style (à ajuster en fonction de tes besoins):
iptables -A INPUT -i eth0 -p tcp --dport ssh -m state --state NEW -m recent --set --name SSH
iptables -A INPUT -i eth0 -p tcp --dport ssh -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
Ça n'autorise que 3 tentatives de connection en SSH par IP en minute
et il faut ensuite une minute sans connexion pour que le SSH soit de
nouveau autorisé depuis cette IP. Ça devrait calmer ceux qui font de
la force brute !
C'est idiot quand on utilise certains outils, comme Subversion, qui
peut faire jusqu'à (au moins) 5 connexions ssh à la suite pour une
seule commande.
On 2005-03-23 16:41:32 +0100, Aurelien Jarno wrote:
Si tu as un noyau récent avec ipt-recent, tu peux tenter de rajouter des règles dans le style (à ajuster en fonction de tes besoins):
iptables -A INPUT -i eth0 -p tcp --dport ssh -m state --state NEW -m recent --set --name SSH iptables -A INPUT -i eth0 -p tcp --dport ssh -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
Ça n'autorise que 3 tentatives de connection en SSH par IP en minute et il faut ensuite une minute sans connexion pour que le SSH soit de nouveau autorisé depuis cette IP. Ça devrait calmer ceux qui font de la force brute !
C'est idiot quand on utilise certains outils, comme Subversion, qui peut faire jusqu'à (au moins) 5 connexions ssh à la suite pour une seule commande.
Ce qui signifie que depuis le LAN, je peux faire du ssh mais nada depuis internet. Donc, mon /var/log/secure est nickel.
Quand je suis chez moi et que je veux bosser, c'est à dire faire du ssh sur un serveur de la boite, j'envoie un mail avec le sujet "ouverture du service ssh" à un user spécial (genre ). A réception, postfix fait travailler procmail qui vérifie si les 2 contraintes sont respectées (sujet + destinataire). Si c'est le cas, alors, il lance un petit script perl pour modifier le host.allow. De la même façon, lorsque je veux protéger le service ssh depuis internet, j'envoie un mail avec le sujet "fermeture du service ssh" à mon user spécial.
Voici le détail de la procédure:
Activation de procmail dans postfix: Dans /etc/postfix/main.cf, mettre la ligne mailbox_transport = procmail à la place de la ligne #mailbox_transport = cyrus
C'est le user cyrus (group mail) qui lance le script depuis /etc/procmail chmod 664 /etc/hosts.allow chown root.mail /etc/hosts.allow
DELIVERMAIL="/usr/libexec/cyrus/deliver" IMAP="$DELIVERMAIL -e -a $USER -m user.$USER" BACKUP="$DELIVERMAIL -e -a $USER -m user.$USER.sav"
#INCLUDERC=/home/$USER/.procmailrc
#################################################################### ### Create a backup of the messagejust in case one of our recipes fail ### We can always comment this out later when we're confident of our recipes ####################################################################
#:0 c #| $BACKUP
#ouvrir ssh (rajoute une sshd: ALL dans hosts.allow) :0: * ^Subject: ouverture du service ssh * ^To: |echo "sshd: ALL" >> /etc/hosts.allow
#fermer ssh (vire sshd: ALL de hosts.allow) :0: * ^Subject: fermeture du service ssh #|perl -pi -e 's/sshd: ALL/ /g' /etc/hosts.allow 1) créer un hosts.allow temporaire dans tmp 2) vider le /etc/hosts.allow 3) remplir le /etc/hosts.allow à patir de /tmp/hosts.allow |sed -e 's/sshd: ALL/ /g' /etc/hosts.allow > /tmp/hosts.allow && sed '' /etc/hosts.allow > /etc/hosts.allow && cat /tmp/hosts.allow >> /etc/hosts.allow
########################################################### ### Deliver it to the user inbox ###########################################################
:0 w | $IMAP
:0 w { EXITCODE=$? HOST }
Autrement, à chaque fois que quelqu'un se connecte en ssh sur tes serveurs, il lance automatiquement /etc/ssh/sshrc. Il suffirait d'y placer la ligne : echo $USER | mail -s "Connexion ssh depuis internet" root pour récupérer toutes les connexions réussies.
voilà voilà
a+
f.
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
> Bonjour,
salut,
Quelqu'un peut-il m'indiquer comment je devrais réagir en termes de
sécurisation?
Voici ma méthode pour accéder en ssh aux serveurs de la boite depuis le
LAN ou internet. Il necessite un serveur mail.
Ce qui signifie que depuis le LAN, je peux faire du ssh mais nada depuis
internet. Donc, mon /var/log/secure est nickel.
Quand je suis chez moi et que je veux bosser, c'est à dire faire du ssh
sur un serveur de la boite, j'envoie un mail avec le sujet "ouverture du
service ssh" à un user spécial (genre robot@mondomaine.com). A
réception, postfix fait travailler procmail qui vérifie si les 2
contraintes sont respectées (sujet + destinataire). Si c'est le cas,
alors, il lance un petit script perl pour modifier le host.allow.
De la même façon, lorsque je veux protéger le service ssh depuis
internet, j'envoie un mail avec le sujet "fermeture du service ssh" à
mon user spécial.
Voici le détail de la procédure:
Activation de procmail dans postfix:
Dans /etc/postfix/main.cf, mettre la ligne
mailbox_transport = procmail
à la place de la ligne
#mailbox_transport = cyrus
C'est le user cyrus (group mail) qui lance le script depuis /etc/procmail
chmod 664 /etc/hosts.allow
chown root.mail /etc/hosts.allow
DELIVERMAIL="/usr/libexec/cyrus/deliver"
IMAP="$DELIVERMAIL -e -a $USER -m user.$USER"
BACKUP="$DELIVERMAIL -e -a $USER -m user.$USER.sav"
#INCLUDERC=/home/$USER/.procmailrc
#################################################################### ###
Create a backup of the messagejust in case one of our recipes fail ###
We can always comment this out later when we're confident of our recipes
####################################################################
#:0 c
#| $BACKUP
#ouvrir ssh (rajoute une sshd: ALL dans hosts.allow)
:0:
* ^Subject: ouverture du service ssh
* ^To: TON_USER_SPECIAL@TON_DOMAIN.FR
|echo "sshd: ALL" >> /etc/hosts.allow
#fermer ssh (vire sshd: ALL de hosts.allow)
:0:
* ^Subject: fermeture du service ssh
#|perl -pi -e 's/sshd: ALL/ /g' /etc/hosts.allow
1) créer un hosts.allow temporaire dans tmp
2) vider le /etc/hosts.allow
3) remplir le /etc/hosts.allow à patir de /tmp/hosts.allow
|sed -e 's/sshd: ALL/ /g' /etc/hosts.allow > /tmp/hosts.allow && sed ''
/etc/hosts.allow > /etc/hosts.allow && cat /tmp/hosts.allow >>
/etc/hosts.allow
########################################################### ### Deliver
it to the user inbox
###########################################################
:0 w
| $IMAP
:0 w
{
EXITCODE=$?
HOST
}
Autrement, à chaque fois que quelqu'un se connecte en ssh sur tes
serveurs, il lance automatiquement /etc/ssh/sshrc. Il suffirait d'y
placer la ligne :
echo $USER | mail -s "Connexion ssh depuis internet" root
pour récupérer toutes les connexions réussies.
voilà voilà
a+
f.
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter 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
Ce qui signifie que depuis le LAN, je peux faire du ssh mais nada depuis internet. Donc, mon /var/log/secure est nickel.
Quand je suis chez moi et que je veux bosser, c'est à dire faire du ssh sur un serveur de la boite, j'envoie un mail avec le sujet "ouverture du service ssh" à un user spécial (genre ). A réception, postfix fait travailler procmail qui vérifie si les 2 contraintes sont respectées (sujet + destinataire). Si c'est le cas, alors, il lance un petit script perl pour modifier le host.allow. De la même façon, lorsque je veux protéger le service ssh depuis internet, j'envoie un mail avec le sujet "fermeture du service ssh" à mon user spécial.
Voici le détail de la procédure:
Activation de procmail dans postfix: Dans /etc/postfix/main.cf, mettre la ligne mailbox_transport = procmail à la place de la ligne #mailbox_transport = cyrus
C'est le user cyrus (group mail) qui lance le script depuis /etc/procmail chmod 664 /etc/hosts.allow chown root.mail /etc/hosts.allow
DELIVERMAIL="/usr/libexec/cyrus/deliver" IMAP="$DELIVERMAIL -e -a $USER -m user.$USER" BACKUP="$DELIVERMAIL -e -a $USER -m user.$USER.sav"
#INCLUDERC=/home/$USER/.procmailrc
#################################################################### ### Create a backup of the messagejust in case one of our recipes fail ### We can always comment this out later when we're confident of our recipes ####################################################################
#:0 c #| $BACKUP
#ouvrir ssh (rajoute une sshd: ALL dans hosts.allow) :0: * ^Subject: ouverture du service ssh * ^To: |echo "sshd: ALL" >> /etc/hosts.allow
#fermer ssh (vire sshd: ALL de hosts.allow) :0: * ^Subject: fermeture du service ssh #|perl -pi -e 's/sshd: ALL/ /g' /etc/hosts.allow 1) créer un hosts.allow temporaire dans tmp 2) vider le /etc/hosts.allow 3) remplir le /etc/hosts.allow à patir de /tmp/hosts.allow |sed -e 's/sshd: ALL/ /g' /etc/hosts.allow > /tmp/hosts.allow && sed '' /etc/hosts.allow > /etc/hosts.allow && cat /tmp/hosts.allow >> /etc/hosts.allow
########################################################### ### Deliver it to the user inbox ###########################################################
:0 w | $IMAP
:0 w { EXITCODE=$? HOST }
Autrement, à chaque fois que quelqu'un se connecte en ssh sur tes serveurs, il lance automatiquement /etc/ssh/sshrc. Il suffirait d'y placer la ligne : echo $USER | mail -s "Connexion ssh depuis internet" root pour récupérer toutes les connexions réussies.
voilà voilà
a+
f.
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Frédéric Bothamy
* Vincent Lefevre [2005-03-23 17:30] :
On 2005-03-23 13:03:37 +0100, antoine roy wrote: > la meilleure chose à faire est encore de ne pas autoriser les > connections sur le 22 depuis partout .
[...]
D'autre part, est-il possible de configurer sshd pour autoriser seulement certains utilisateurs à se connecter par ssh? (Un peu comme le PermitRootLogin, mais l'inverse...)
Oui avec la directive AllowUsers (ou même AllowGroups) dans /etc/ssh/sshd_config.
Fred
-- Comment poser les questions de manière intelligente ? http://www.gnurou.org/documents/smart-questions-fr.html Comment signaler efficacement un bug ? http://www.chiark.greenend.org.uk/~sgtatham/bugs-fr.html
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
* Vincent Lefevre <vincent@vinc17.org> [2005-03-23 17:30] :
On 2005-03-23 13:03:37 +0100, antoine roy wrote:
> la meilleure chose à faire est encore de ne pas autoriser les
> connections sur le 22 depuis partout .
[...]
D'autre part, est-il possible de configurer sshd pour autoriser
seulement certains utilisateurs à se connecter par ssh? (Un peu
comme le PermitRootLogin, mais l'inverse...)
Oui avec la directive AllowUsers (ou même AllowGroups) dans
/etc/ssh/sshd_config.
Fred
--
Comment poser les questions de manière intelligente ?
http://www.gnurou.org/documents/smart-questions-fr.html
Comment signaler efficacement un bug ?
http://www.chiark.greenend.org.uk/~sgtatham/bugs-fr.html
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter 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
On 2005-03-23 13:03:37 +0100, antoine roy wrote: > la meilleure chose à faire est encore de ne pas autoriser les > connections sur le 22 depuis partout .
[...]
D'autre part, est-il possible de configurer sshd pour autoriser seulement certains utilisateurs à se connecter par ssh? (Un peu comme le PermitRootLogin, mais l'inverse...)
Oui avec la directive AllowUsers (ou même AllowGroups) dans /etc/ssh/sshd_config.
Fred
-- Comment poser les questions de manière intelligente ? http://www.gnurou.org/documents/smart-questions-fr.html Comment signaler efficacement un bug ? http://www.chiark.greenend.org.uk/~sgtatham/bugs-fr.html
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Vincent Lefevre
On 2005-03-23 17:35:07 +0100, Fabrice Régnier wrote:
Quand je suis chez moi et que je veux bosser, c'est à dire faire du ssh sur un serveur de la boite, j'envoie un mail avec le sujet "ouverture du service ssh" à un user spécial (genre ).
Tu fermes le ssh, mais du coup tu dois ouvrir un serveur de mail sur l'extérieur, avec risque de relais de spam si un problème de config survient... Pour ceux qui, comme moi, récupèrent leur mail uniquement par POP et/ou IMAP, ce n'est pas forcément une bonne solution. Sans compter que certains FAI peuvent filtrer les connexions sur le port 25 en destination (j'ai d'ailleurs déjà ce problème avec ssh, pour lequel j'ai dû rediriger le port 443, non filtré, sur le port 22).
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
On 2005-03-23 17:35:07 +0100, Fabrice Régnier wrote:
Quand je suis chez moi et que je veux bosser, c'est à dire faire du ssh
sur un serveur de la boite, j'envoie un mail avec le sujet "ouverture du
service ssh" à un user spécial (genre robot@mondomaine.com).
Tu fermes le ssh, mais du coup tu dois ouvrir un serveur de mail
sur l'extérieur, avec risque de relais de spam si un problème de
config survient... Pour ceux qui, comme moi, récupèrent leur mail
uniquement par POP et/ou IMAP, ce n'est pas forcément une bonne
solution. Sans compter que certains FAI peuvent filtrer les
connexions sur le port 25 en destination (j'ai d'ailleurs déjà ce
problème avec ssh, pour lequel j'ai dû rediriger le port 443, non
filtré, sur le port 22).
On 2005-03-23 17:35:07 +0100, Fabrice Régnier wrote:
Quand je suis chez moi et que je veux bosser, c'est à dire faire du ssh sur un serveur de la boite, j'envoie un mail avec le sujet "ouverture du service ssh" à un user spécial (genre ).
Tu fermes le ssh, mais du coup tu dois ouvrir un serveur de mail sur l'extérieur, avec risque de relais de spam si un problème de config survient... Pour ceux qui, comme moi, récupèrent leur mail uniquement par POP et/ou IMAP, ce n'est pas forcément une bonne solution. Sans compter que certains FAI peuvent filtrer les connexions sur le port 25 en destination (j'ai d'ailleurs déjà ce problème avec ssh, pour lequel j'ai dû rediriger le port 443, non filtré, sur le port 22).
> > 1/ ok déjà fait. su,sudo,sux sont là pour ça >
Attention tout de meme avec sudo puisqu'il n'est pas nécessaire d'avoir le passwd root pour l'utiliser.
il n'y a donc qu'un seul mdp à casser si le user peut faire un "sudo su" ou encore un "sudo vi" etc ..
info intéressante je ne le savais pas, je n'utilise que les deux autres!
Ça dépend de ce que tu permets à tes utilisateurs, sudo c'est quand même très bien.
Chez moi, la seule commande accessible via sudo est "apt-get" comme ça je n'ai pas à changer d'utilisateur quand je fais une mise à jour.
-- (°> Nicolas Évrard / ) Liège - Belgique ^^
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Vincent Lefevre
On 2005-03-23 16:41:32 +0100, Aurelien Jarno wrote:
Si tu as un noyau récent avec ipt-recent, tu peux tenter de rajouter des règles dans le style (à ajuster en fonction de tes besoins):
iptables -A INPUT -i eth0 -p tcp --dport ssh -m state --state NEW -m recent --set --name SSH iptables -A INPUT -i eth0 -p tcp --dport ssh -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
Ça n'autorise que 3 tentatives de connection en SSH par IP en minute et il faut ensuite une minute sans connexion pour que le SSH soit de nouveau autorisé depuis cette IP. Ça devrait calmer ceux qui font de la force brute !
Je viens de penser à un autre système: est-il possible de faire apparaître le port 22 comme fermé à la première tentative de connexion, mais de ne l'ouvrir qu'à une seconde tentative (depuis la même adresse IP)?
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
On 2005-03-23 16:41:32 +0100, Aurelien Jarno wrote:
Si tu as un noyau récent avec ipt-recent, tu peux tenter de rajouter des
règles dans le style (à ajuster en fonction de tes besoins):
iptables -A INPUT -i eth0 -p tcp --dport ssh -m state --state NEW -m recent --set --name SSH
iptables -A INPUT -i eth0 -p tcp --dport ssh -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
Ça n'autorise que 3 tentatives de connection en SSH par IP en
minute et il faut ensuite une minute sans connexion pour que le SSH soit
de nouveau autorisé depuis cette IP. Ça devrait calmer ceux qui font de
la force brute !
Je viens de penser à un autre système: est-il possible de faire
apparaître le port 22 comme fermé à la première tentative de
connexion, mais de ne l'ouvrir qu'à une seconde tentative (depuis
la même adresse IP)?
On 2005-03-23 16:41:32 +0100, Aurelien Jarno wrote:
Si tu as un noyau récent avec ipt-recent, tu peux tenter de rajouter des règles dans le style (à ajuster en fonction de tes besoins):
iptables -A INPUT -i eth0 -p tcp --dport ssh -m state --state NEW -m recent --set --name SSH iptables -A INPUT -i eth0 -p tcp --dport ssh -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
Ça n'autorise que 3 tentatives de connection en SSH par IP en minute et il faut ensuite une minute sans connexion pour que le SSH soit de nouveau autorisé depuis cette IP. Ça devrait calmer ceux qui font de la force brute !
Je viens de penser à un autre système: est-il possible de faire apparaître le port 22 comme fermé à la première tentative de connexion, mais de ne l'ouvrir qu'à une seconde tentative (depuis la même adresse IP)?
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
fra-duf-no-spam
Le 12865ième jour après Epoch, Vincent Lefevre écrivait:
Sans compter que certains FAI peuvent filtrer les connexions sur le port 25 en destination (j'ai d'ailleurs déjà ce problème avec ssh, pour lequel j'ai dû rediriger le port 443, non filtré, sur le port 22).
Perso, j'ai ce souci quand je me connecte avec mon téléphone portable sur le net. Mon FAI vends d'ailleurs cette solution comme "Sans limite" (sic).J'ai choisi d'utiliser le port de telnet, non filtré, pour mes accès ssh. Ça évite de bloquer 443 que j'utiliserai peut-être un jour sur mon serveur ;)
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Le 12865ième jour après Epoch,
Vincent Lefevre écrivait:
Sans compter que certains FAI peuvent filtrer les
connexions sur le port 25 en destination (j'ai d'ailleurs déjà ce
problème avec ssh, pour lequel j'ai dû rediriger le port 443, non
filtré, sur le port 22).
Perso, j'ai ce souci quand je me connecte avec mon téléphone portable
sur le net. Mon FAI vends d'ailleurs cette solution comme "Sans
limite" (sic).J'ai choisi d'utiliser le port de telnet, non filtré,
pour mes accès ssh. Ça évite de bloquer 443 que j'utiliserai peut-être
un jour sur mon serveur ;)
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter 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 12865ième jour après Epoch, Vincent Lefevre écrivait:
Sans compter que certains FAI peuvent filtrer les connexions sur le port 25 en destination (j'ai d'ailleurs déjà ce problème avec ssh, pour lequel j'ai dû rediriger le port 443, non filtré, sur le port 22).
Perso, j'ai ce souci quand je me connecte avec mon téléphone portable sur le net. Mon FAI vends d'ailleurs cette solution comme "Sans limite" (sic).J'ai choisi d'utiliser le port de telnet, non filtré, pour mes accès ssh. Ça évite de bloquer 443 que j'utiliserai peut-être un jour sur mon serveur ;)
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Yves Rutschle
On Wed, Mar 23, 2005 at 06:42:41PM +0100, Nicolas Evrard wrote:
Chez moi, la seule commande accessible via sudo est "apt-get" comme ça je n'ai pas à changer d'utilisateur quand je fais une mise à jour.
Tu ferais aussi bien de ne pas mettre de mot de passe sur root alors: Si j'arrive à m'introduire sous ton identité, il me suffit de créer un fichier de configuration à passer à apt-get (option -c), qui spécifie une source de paquets que je contrôle. Je peux alors installer ce que je veux sur ta machine, y compris une version de su(1) qui ne demande pas de mots de passe.
Si j'ai la flemme, je peux juste démolir ton système en desinstallant tout.
Y.
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
On Wed, Mar 23, 2005 at 06:42:41PM +0100, Nicolas Evrard wrote:
Chez moi, la seule commande accessible via sudo est "apt-get" comme ça
je n'ai pas à changer d'utilisateur quand je fais une mise à jour.
Tu ferais aussi bien de ne pas mettre de mot de passe sur
root alors: Si j'arrive à m'introduire sous ton identité,
il me suffit de créer un fichier de configuration à passer à
apt-get (option -c), qui spécifie une source de paquets que
je contrôle. Je peux alors installer ce que je veux sur ta
machine, y compris une version de su(1) qui ne demande pas
de mots de passe.
Si j'ai la flemme, je peux juste démolir ton système en
desinstallant tout.
Y.
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter 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
On Wed, Mar 23, 2005 at 06:42:41PM +0100, Nicolas Evrard wrote:
Chez moi, la seule commande accessible via sudo est "apt-get" comme ça je n'ai pas à changer d'utilisateur quand je fais une mise à jour.
Tu ferais aussi bien de ne pas mettre de mot de passe sur root alors: Si j'arrive à m'introduire sous ton identité, il me suffit de créer un fichier de configuration à passer à apt-get (option -c), qui spécifie une source de paquets que je contrôle. Je peux alors installer ce que je veux sur ta machine, y compris une version de su(1) qui ne demande pas de mots de passe.
Si j'ai la flemme, je peux juste démolir ton système en desinstallant tout.
Y.
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
