J'ai relevé dans /var/log/messages des tentatives de connexion
sur mon ordinateur par ssh, plusieurs utilisateurs sont essayés,
test, guest, admin, etc...
Apparament j'ai un certain nombre d'utilisateur qui on été
créé lors de l'installation de la Mandrake 10. notament :
bin,daemon,adm,lp,sync,shutdown,halt,mail,news,uucp,operator,
games,nobody,rpm,vcsa,rpc,xfs,apache,rpcuser,ftp,mysql,
postgres, etc...
Je n'ai jamais configuré aucun mot de passe pour ces comptes,
il semble que pour certain des shells soient associés.
il y t'il un risque de pénétration de mon système avec l'un de ces
comptes ?.
Comment peut ont interdire la connexion à ces comptes ?
Peut on supprimer les shells de connexions qui leurs sont
associés ?.
Je ne souhaite pas supprimer ssh, c'est le seul moyen que
j'ai pour me connecter à distance (j'ai limité les ports
par un firewall).
J'ai eu la même tentative ce matin. Ça vient de Corée selon whois et j'ai envoyé une plainte à qui de droit.
C'est un ver qui circule depuis cet été, il exploite des mots de passe triviaux par défaut sur certaines distributions merdiques. J'en subis deux à trois par jour. Quand je m'ennuie, je nmap en retour, et s'il y a un SMTP ouvert j'envoie un mail à root : il y en a même un qui a été lu et qui a suscité une réponse de remerciment :)
nicolas wrote in message
<pan.2004.10.18.17.05.39.351827@online.fr.invalid>:
J'ai eu la même tentative ce matin. Ça vient de Corée selon whois et
j'ai envoyé une plainte à qui de droit.
C'est un ver qui circule depuis cet été, il exploite des mots de passe
triviaux par défaut sur certaines distributions merdiques. J'en subis deux à
trois par jour. Quand je m'ennuie, je nmap en retour, et s'il y a un SMTP
ouvert j'envoie un mail à root : il y en a même un qui a été lu et qui a
suscité une réponse de remerciment :)
J'ai eu la même tentative ce matin. Ça vient de Corée selon whois et j'ai envoyé une plainte à qui de droit.
C'est un ver qui circule depuis cet été, il exploite des mots de passe triviaux par défaut sur certaines distributions merdiques. J'en subis deux à trois par jour. Quand je m'ennuie, je nmap en retour, et s'il y a un SMTP ouvert j'envoie un mail à root : il y en a même un qui a été lu et qui a suscité une réponse de remerciment :)
Glennie Vignarajah
TiChou a écrit:
Bonsoir,
On pourrait aussi faire du filtrage au niveau de Netfilter en utilisant le match owner de la commande iptables.
Heuh? Ca marche pour les connexions sortantes. Ca marche aussi pour les connexions entrantes?. J'ai dû mal à voir comment IPTABLES peut détecter UID de la connexion entrante... A+
-- Glennie "Personne ne survit au fait d'être estimé au-dessus de sa valeur."
TiChou a écrit:
Bonsoir,
On pourrait aussi faire du filtrage au niveau de Netfilter en
utilisant le match owner de la commande iptables.
Heuh?
Ca marche pour les connexions sortantes.
Ca marche aussi pour les connexions entrantes?. J'ai dû mal à voir
comment IPTABLES peut détecter UID de la connexion entrante...
A+
--
Glennie
"Personne ne survit au fait d'être estimé au-dessus de sa valeur."
On pourrait aussi faire du filtrage au niveau de Netfilter en utilisant le match owner de la commande iptables.
Heuh? Ca marche pour les connexions sortantes. Ca marche aussi pour les connexions entrantes?. J'ai dû mal à voir comment IPTABLES peut détecter UID de la connexion entrante... A+
-- Glennie "Personne ne survit au fait d'être estimé au-dessus de sa valeur."
TiChou
Dans le message <news:417415cf$0$30562$, *Glennie Vignarajah* tapota sur f.c.o.l.configuration :
TiChou a écrit:
Bonsoir,
On pourrait aussi faire du filtrage au niveau de Netfilter en utilisant le match owner de la commande iptables.
Heuh? Ca marche pour les connexions sortantes. Ca marche aussi pour les connexions entrantes?.
Ça fonctionne pour tout type de trafic (entrant ou sortant), de protocole, etc.
À ce que je sache, une connexion c'est une liaison avec un flux qui va dans les deux sens, entrant et sortant. Empêcher le flux dans un des sens, c'est alors empêcher une connexion.
J'ai dû mal à voir comment IPTABLES peut détecter UID de la connexion entrante...
Le but n'était pas de détecter une connexion entrante, le but était d'interdire que l'UID X puisse faire du trafic après authentification.
Mais dans mon idée, je raisonnais avec le processus de la séparation des privilèges de sshd durant l'authentification et je pensais « bêtement » qu'on bloquerait alors le trafic du processus sshd lancé sous l'utilisateur authentifié, mais bien sûr il n'en est rien puisque la connexion a été établie à partir du processus père qui lui est forcément lancé sous root. On peut donc oublier mon idée...
-- TiChou
Dans le message <news:417415cf$0$30562$626a14ce@news.free.fr>,
*Glennie Vignarajah* tapota sur f.c.o.l.configuration :
TiChou a écrit:
Bonsoir,
On pourrait aussi faire du filtrage au niveau de Netfilter en
utilisant le match owner de la commande iptables.
Heuh?
Ca marche pour les connexions sortantes.
Ca marche aussi pour les connexions entrantes?.
Ça fonctionne pour tout type de trafic (entrant ou sortant), de protocole,
etc.
À ce que je sache, une connexion c'est une liaison avec un flux qui va dans
les deux sens, entrant et sortant. Empêcher le flux dans un des sens, c'est
alors empêcher une connexion.
J'ai dû mal à voir comment IPTABLES peut détecter UID de la connexion
entrante...
Le but n'était pas de détecter une connexion entrante, le but était
d'interdire que l'UID X puisse faire du trafic après authentification.
Mais dans mon idée, je raisonnais avec le processus de la séparation des
privilèges de sshd durant l'authentification et je pensais « bêtement »
qu'on bloquerait alors le trafic du processus sshd lancé sous l'utilisateur
authentifié, mais bien sûr il n'en est rien puisque la connexion a été
établie à partir du processus père qui lui est forcément lancé sous root.
On peut donc oublier mon idée...
Dans le message <news:417415cf$0$30562$, *Glennie Vignarajah* tapota sur f.c.o.l.configuration :
TiChou a écrit:
Bonsoir,
On pourrait aussi faire du filtrage au niveau de Netfilter en utilisant le match owner de la commande iptables.
Heuh? Ca marche pour les connexions sortantes. Ca marche aussi pour les connexions entrantes?.
Ça fonctionne pour tout type de trafic (entrant ou sortant), de protocole, etc.
À ce que je sache, une connexion c'est une liaison avec un flux qui va dans les deux sens, entrant et sortant. Empêcher le flux dans un des sens, c'est alors empêcher une connexion.
J'ai dû mal à voir comment IPTABLES peut détecter UID de la connexion entrante...
Le but n'était pas de détecter une connexion entrante, le but était d'interdire que l'UID X puisse faire du trafic après authentification.
Mais dans mon idée, je raisonnais avec le processus de la séparation des privilèges de sshd durant l'authentification et je pensais « bêtement » qu'on bloquerait alors le trafic du processus sshd lancé sous l'utilisateur authentifié, mais bien sûr il n'en est rien puisque la connexion a été établie à partir du processus père qui lui est forcément lancé sous root. On peut donc oublier mon idée...
-- TiChou
g2lx
Le Mon, 18 Oct 2004 19:14:19 +0200, Rakotomandimby Mihamina a écrit :
On Mon, 18 Oct 2004 18:48:42 +0200, Raphaël 'SurcouF' Bordet wrote:
Sinon, tu peux limiter les utilisateurs ayant droit de se connecter via ssh.
