Sur le site d'un de nos clients (dont nous n'administrons pas le réseau) ,
un serveur
HP sous RH7.2 , sans accès internet (donc pas de DNS , ...) , connecté au
LAN , un
routeur Netgear ADSL (avec parefeu par défaut),un modem de télémaintenance
sur
un autre serveur sur le LAN, rencontre le problème suivant:
Avant aujourd'hui:
.connexion root en direct , fonctionnait OK
.connexion root via telnet donnait parfois de manière aléatoire des "mots
de passe
invalides" que l'on "traitait" en se connectant sous un compte
utilisateur et en faisant
un su - root. La connexion utilisateur fonctionnait toujours.
Depuis aujourd'hui:
.le seul élément qui paraisse significatif (encore que ...) comme
"déclencheur" est
la création d'un compte utilisateur (non privilégié) pour faire des
transferts FTP.
.un premier test FTP sous ce compte a fonctionné
.quelque temps plus tard: invalid password (via ftp) ,connexions sous
telnet parfois
valide , parfois invalid password.
.la fonction su - xxx ne fonctionne plus ("impossible d'attribuer les
groupes")
.on observe que dans /var/log/messages pam signale des fichiers de /etc
(securetty,
ftpusers , shells) comme étant en écriture par world , en effet ils sont
tous en
777. le fichier bin/su n'a plus l'attribut suid.
.on remet les fichiers dans bonne protection (644) ,suid , ... tout
remarche.
.15 minutes après : les protections sont revenues à 777 (y compris /bin/su)
.il en va de même de la base oracle dont l'exécutable doit être en
protection 6751
et qui repasse en 777
.ceci est reproductible
Nous avons: déconnecté le routeur (mais il semble qu'il y en ait d'autre
sur le LAN).
Cela n'a rien changé , les process actifs n'ont a priori rien de bizarre.
Il n'y a pas
de cron bizarres. Les shells .bashrc,bashrc,.bash_profile semblent OK. Il
n' ya pas
de fichiers récents dans les rc.d. Les fichiers reviennent en 777.
Merci de toute idée .....
Pour info (ne semble pas avoir de rapport , mais ...) : ce serveur a
remplacé en novembre un
serveur plus ancien , qui reste sur le LAN , l'adresse IP du nouveau
serveur est
celle de l'ancien , qui lui a hérité d'une nouvelle adresse. Trainerait-il
quelque
part sur l'ancien "quelque chose" qui ferait des choses par @IP et
s'adresserait au
nouveau ??
--
J.Bratières
Enlever paspub pour répondre
Please remove paspub when answering
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Raphaël 'SurcouF' Bordet
Bonjour,
Sur le site d'un de nos clients (dont nous n'administrons pas le réseau) , un serveur HP sous RH7.2 , sans accès internet (donc pas de DNS , ...) , connecté au LAN , un routeur Netgear ADSL (avec parefeu par défaut),un modem de télémaintenance sur un autre serveur sur le LAN, rencontre le problème suivant:
Donc, connecté à Internet quand même, que tu le veuilles ou non.
Avant aujourd'hui: .connexion root en direct , fonctionnait OK .connexion root via telnet donnait parfois de manière aléatoire des "mots de passe invalides" que l'on "traitait" en se connectant sous un compte utilisateur et en faisant un su - root. La connexion utilisateur fonctionnait toujours.
Depuis aujourd'hui: .le seul élément qui paraisse significatif (encore que ...) comme "déclencheur" est la création d'un compte utilisateur (non privilégié) pour faire des transferts FTP. .un premier test FTP sous ce compte a fonctionné .quelque temps plus tard: invalid password (via ftp) ,connexions sous telnet parfois valide , parfois invalid password. .la fonction su - xxx ne fonctionne plus ("impossible d'attribuer les groupes") .on observe que dans /var/log/messages pam signale des fichiers de /etc (securetty, ftpusers , shells) comme étant en écriture par world , en effet ils sont tous en 777. le fichier bin/su n'a plus l'attribut suid. .on remet les fichiers dans bonne protection (644) ,suid , ... tout remarche. .15 minutes après : les protections sont revenues à 777 (y compris /bin/su) .il en va de même de la base oracle dont l'exécutable doit être en protection 6751 et qui repasse en 777 .ceci est reproductible
Nous avons: déconnecté le routeur (mais il semble qu'il y en ait d'autre sur le LAN). Cela n'a rien changé , les process actifs n'ont a priori rien de bizarre. Il n'y a pas de cron bizarres. Les shells .bashrc,bashrc,.bash_profile semblent OK. Il n' ya pas de fichiers récents dans les rc.d. Les fichiers reviennent en 777.
Merci de toute idée .....
Rapatrie donc des exécutables sains de ps et ls et faire un tour d'horizon: je ne serais pas étonné que tu découvres des processus et des dossiers qui étaient jusque-là masqués à ton visage.
Pour info (ne semble pas avoir de rapport , mais ...) : ce serveur a remplacé en novembre un serveur plus ancien , qui reste sur le LAN , l'adresse IP du nouveau serveur est celle de l'ancien , qui lui a hérité d'une nouvelle adresse. Trainerait-il quelque part sur l'ancien "quelque chose" qui ferait des choses par @IP et s'adresserait au nouveau ??
Possible mais toujours est-il qu'une RedHat 7.2 n'est pas vraiment ce qu'il y a de plus à jour: les failles existantes sont légions maintenant. Avez-vous simplement pensé à modifier les mots de passe des comptes utilisateurs ? Ne sous-estimez pas non plus une "attaque" interne. Une autre machine a peut-être été aussi compromise...
J'ai bien peur, qu'au final, il ne faille ré-installer cette machine et, de préférence, avec une distribution à jour telle que Fedora, Mandrake ou Debian Sarge.
-- Raphaël 'SurcouF' Bordet http://debianfr.net/ | surcouf at debianfr dot net
Bonjour,
Sur le site d'un de nos clients (dont nous n'administrons pas le réseau)
, un serveur
HP sous RH7.2 , sans accès internet (donc pas de DNS , ...) , connecté
au LAN , un
routeur Netgear ADSL (avec parefeu par défaut),un modem de
télémaintenance sur
un autre serveur sur le LAN, rencontre le problème suivant:
Donc, connecté à Internet quand même, que tu le veuilles ou non.
Avant aujourd'hui:
.connexion root en direct , fonctionnait OK
.connexion root via telnet donnait parfois de manière aléatoire des
"mots de passe
invalides" que l'on "traitait" en se connectant sous un compte
utilisateur et en faisant
un su - root. La connexion utilisateur fonctionnait toujours.
Depuis aujourd'hui:
.le seul élément qui paraisse significatif (encore que ...) comme
"déclencheur" est
la création d'un compte utilisateur (non privilégié) pour faire des
transferts FTP.
.un premier test FTP sous ce compte a fonctionné
.quelque temps plus tard: invalid password (via ftp) ,connexions sous
telnet parfois
valide , parfois invalid password.
.la fonction su - xxx ne fonctionne plus ("impossible d'attribuer les
groupes")
.on observe que dans /var/log/messages pam signale des fichiers de /etc
(securetty,
ftpusers , shells) comme étant en écriture par world , en effet ils
sont tous en
777. le fichier bin/su n'a plus l'attribut suid.
.on remet les fichiers dans bonne protection (644) ,suid , ... tout
remarche.
.15 minutes après : les protections sont revenues à 777 (y compris /bin/su)
.il en va de même de la base oracle dont l'exécutable doit être en
protection 6751
et qui repasse en 777
.ceci est reproductible
Nous avons: déconnecté le routeur (mais il semble qu'il y en ait
d'autre sur le LAN).
Cela n'a rien changé , les process actifs n'ont a priori rien de
bizarre. Il n'y a pas
de cron bizarres. Les shells .bashrc,bashrc,.bash_profile semblent OK.
Il n' ya pas
de fichiers récents dans les rc.d. Les fichiers reviennent en 777.
Merci de toute idée .....
Rapatrie donc des exécutables sains de ps et ls et faire un tour
d'horizon: je ne serais pas étonné que tu découvres des processus et des
dossiers qui étaient jusque-là masqués à ton visage.
Pour info (ne semble pas avoir de rapport , mais ...) : ce serveur a
remplacé en novembre un
serveur plus ancien , qui reste sur le LAN , l'adresse IP du nouveau
serveur est
celle de l'ancien , qui lui a hérité d'une nouvelle adresse.
Trainerait-il quelque
part sur l'ancien "quelque chose" qui ferait des choses par @IP et
s'adresserait au
nouveau ??
Possible mais toujours est-il qu'une RedHat 7.2 n'est pas vraiment ce
qu'il y a de plus à jour: les failles existantes sont légions
maintenant. Avez-vous simplement pensé à modifier les mots de passe des
comptes utilisateurs ? Ne sous-estimez pas non plus une "attaque"
interne. Une autre machine a peut-être été aussi compromise...
J'ai bien peur, qu'au final, il ne faille ré-installer cette machine et,
de préférence, avec une distribution à jour telle que Fedora, Mandrake
ou Debian Sarge.
--
Raphaël 'SurcouF' Bordet
http://debianfr.net/ | surcouf at debianfr dot net
Sur le site d'un de nos clients (dont nous n'administrons pas le réseau) , un serveur HP sous RH7.2 , sans accès internet (donc pas de DNS , ...) , connecté au LAN , un routeur Netgear ADSL (avec parefeu par défaut),un modem de télémaintenance sur un autre serveur sur le LAN, rencontre le problème suivant:
Donc, connecté à Internet quand même, que tu le veuilles ou non.
Avant aujourd'hui: .connexion root en direct , fonctionnait OK .connexion root via telnet donnait parfois de manière aléatoire des "mots de passe invalides" que l'on "traitait" en se connectant sous un compte utilisateur et en faisant un su - root. La connexion utilisateur fonctionnait toujours.
Depuis aujourd'hui: .le seul élément qui paraisse significatif (encore que ...) comme "déclencheur" est la création d'un compte utilisateur (non privilégié) pour faire des transferts FTP. .un premier test FTP sous ce compte a fonctionné .quelque temps plus tard: invalid password (via ftp) ,connexions sous telnet parfois valide , parfois invalid password. .la fonction su - xxx ne fonctionne plus ("impossible d'attribuer les groupes") .on observe que dans /var/log/messages pam signale des fichiers de /etc (securetty, ftpusers , shells) comme étant en écriture par world , en effet ils sont tous en 777. le fichier bin/su n'a plus l'attribut suid. .on remet les fichiers dans bonne protection (644) ,suid , ... tout remarche. .15 minutes après : les protections sont revenues à 777 (y compris /bin/su) .il en va de même de la base oracle dont l'exécutable doit être en protection 6751 et qui repasse en 777 .ceci est reproductible
Nous avons: déconnecté le routeur (mais il semble qu'il y en ait d'autre sur le LAN). Cela n'a rien changé , les process actifs n'ont a priori rien de bizarre. Il n'y a pas de cron bizarres. Les shells .bashrc,bashrc,.bash_profile semblent OK. Il n' ya pas de fichiers récents dans les rc.d. Les fichiers reviennent en 777.
Merci de toute idée .....
Rapatrie donc des exécutables sains de ps et ls et faire un tour d'horizon: je ne serais pas étonné que tu découvres des processus et des dossiers qui étaient jusque-là masqués à ton visage.
Pour info (ne semble pas avoir de rapport , mais ...) : ce serveur a remplacé en novembre un serveur plus ancien , qui reste sur le LAN , l'adresse IP du nouveau serveur est celle de l'ancien , qui lui a hérité d'une nouvelle adresse. Trainerait-il quelque part sur l'ancien "quelque chose" qui ferait des choses par @IP et s'adresserait au nouveau ??
Possible mais toujours est-il qu'une RedHat 7.2 n'est pas vraiment ce qu'il y a de plus à jour: les failles existantes sont légions maintenant. Avez-vous simplement pensé à modifier les mots de passe des comptes utilisateurs ? Ne sous-estimez pas non plus une "attaque" interne. Une autre machine a peut-être été aussi compromise...
J'ai bien peur, qu'au final, il ne faille ré-installer cette machine et, de préférence, avec une distribution à jour telle que Fedora, Mandrake ou Debian Sarge.
-- Raphaël 'SurcouF' Bordet http://debianfr.net/ | surcouf at debianfr dot net
Rakotomandimby (R12y) Mihamina
( Wed, 02 Feb 2005 09:59:08 +0100 ) nwjb :
Bonjour,
Bonjour
un serveur HP sous RH7.2
Peut-etre que le probleme est la... -- L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance) Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
( Wed, 02 Feb 2005 09:59:08 +0100 ) nwjb :
Bonjour,
Bonjour
un serveur
HP sous RH7.2
Peut-etre que le probleme est la...
--
L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses
activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance)
Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
Peut-etre que le probleme est la... -- L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance) Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
nwjb
Le Wed, 02 Feb 2005 10:45:41 +0100, Raphaël 'SurcouF' Bordet a écrit:
Bonjour, Sur le site d'un de nos clients (dont nous n'administrons pas le réseau) , un serveur HP sous RH7.2 , sans accès internet (donc pas de DNS , ...) , connecté au LAN , un routeur Netgear ADSL (avec parefeu par défaut),un modem de télémaintenance sur un autre serveur sur le LAN, rencontre le problème suivant:
Donc, connecté à Internet quand même, que tu le veuilles ou non.
Avant aujourd'hui: .connexion root en direct , fonctionnait OK .connexion root via telnet donnait parfois de manière aléatoire des "mots de passe invalides" que l'on "traitait" en se connectant sous un compte utilisateur et en faisant un su - root. La connexion utilisateur fonctionnait toujours. Depuis aujourd'hui: .le seul élément qui paraisse significatif (encore que ...) comme "déclencheur" est la création d'un compte utilisateur (non privilégié) pour faire des transferts FTP. .un premier test FTP sous ce compte a fonctionné .quelque temps plus tard: invalid password (via ftp) ,connexions sous telnet parfois valide , parfois invalid password. .la fonction su - xxx ne fonctionne plus ("impossible d'attribuer les groupes") .on observe que dans /var/log/messages pam signale des fichiers de /etc (securetty, ftpusers , shells) comme étant en écriture par world , en effet ils sont tous en 777. le fichier bin/su n'a plus l'attribut suid. .on remet les fichiers dans bonne protection (644) ,suid , ... tout remarche. .15 minutes après : les protections sont revenues à 777 (y compris /bin/su) .il en va de même de la base oracle dont l'exécutable doit être en protection 6751 et qui repasse en 777 .ceci est reproductible Nous avons: déconnecté le routeur (mais il semble qu'il y en ait d'autre sur le LAN). Cela n'a rien changé , les process actifs n'ont a priori rien de bizarre. Il n'y a pas de cron bizarres. Les shells .bashrc,bashrc,.bash_profile semblent OK. Il n' ya pas de fichiers récents dans les rc.d. Les fichiers reviennent en 777. Merci de toute idée .....
Rapatrie donc des exécutables sains de ps et ls et faire un tour d'horizon: je ne serais pas étonné que tu découvres des processus et des dossiers qui étaient jusque-là masqués à ton visage.
Pour info (ne semble pas avoir de rapport , mais ...) : ce serveur a remplacé en novembre un serveur plus ancien , qui reste sur le LAN , l'adresse IP du nouveau serveur est celle de l'ancien , qui lui a hérité d'une nouvelle adresse. Trainerait-il quelque part sur l'ancien "quelque chose" qui ferait des choses par @IP et s'adresserait au nouveau ??
Possible mais toujours est-il qu'une RedHat 7.2 n'est pas vraiment ce qu'il y a de plus à jour: les failles existantes sont légions maintenant. Avez-vous simplement pensé à modifier les mots de passe des comptes utilisateurs ? Ne sous-estimez pas non plus une "attaque" interne. Une autre machine a peut-être été aussi compromise...
J'ai bien peur, qu'au final, il ne faille ré-installer cette machine et, de préférence, avec une distribution à jour telle que Fedora, Mandrake ou Debian Sarge.
Merci de vos réponses , étudions maj RH.....
-- J.Bratières
Enlever paspub pour répondre Please remove paspub when answering
Le Wed, 02 Feb 2005 10:45:41 +0100, Raphaël 'SurcouF' Bordet
<surcouf@debianfr.net> a écrit:
Bonjour,
Sur le site d'un de nos clients (dont nous n'administrons pas le
réseau) , un serveur
HP sous RH7.2 , sans accès internet (donc pas de DNS , ...) , connecté
au LAN , un
routeur Netgear ADSL (avec parefeu par défaut),un modem de
télémaintenance sur
un autre serveur sur le LAN, rencontre le problème suivant:
Donc, connecté à Internet quand même, que tu le veuilles ou non.
Avant aujourd'hui:
.connexion root en direct , fonctionnait OK
.connexion root via telnet donnait parfois de manière aléatoire des
"mots de passe
invalides" que l'on "traitait" en se connectant sous un compte
utilisateur et en faisant
un su - root. La connexion utilisateur fonctionnait toujours.
Depuis aujourd'hui:
.le seul élément qui paraisse significatif (encore que ...) comme
"déclencheur" est
la création d'un compte utilisateur (non privilégié) pour faire des
transferts FTP.
.un premier test FTP sous ce compte a fonctionné
.quelque temps plus tard: invalid password (via ftp) ,connexions sous
telnet parfois
valide , parfois invalid password.
.la fonction su - xxx ne fonctionne plus ("impossible d'attribuer les
groupes")
.on observe que dans /var/log/messages pam signale des fichiers de
/etc (securetty,
ftpusers , shells) comme étant en écriture par world , en effet ils
sont tous en
777. le fichier bin/su n'a plus l'attribut suid.
.on remet les fichiers dans bonne protection (644) ,suid , ... tout
remarche.
.15 minutes après : les protections sont revenues à 777 (y compris
/bin/su)
.il en va de même de la base oracle dont l'exécutable doit être en
protection 6751
et qui repasse en 777
.ceci est reproductible
Nous avons: déconnecté le routeur (mais il semble qu'il y en ait
d'autre sur le LAN).
Cela n'a rien changé , les process actifs n'ont a priori rien de
bizarre. Il n'y a pas
de cron bizarres. Les shells .bashrc,bashrc,.bash_profile semblent OK.
Il n' ya pas
de fichiers récents dans les rc.d. Les fichiers reviennent en 777.
Merci de toute idée .....
Rapatrie donc des exécutables sains de ps et ls et faire un tour
d'horizon: je ne serais pas étonné que tu découvres des processus et des
dossiers qui étaient jusque-là masqués à ton visage.
Pour info (ne semble pas avoir de rapport , mais ...) : ce serveur a
remplacé en novembre un
serveur plus ancien , qui reste sur le LAN , l'adresse IP du nouveau
serveur est
celle de l'ancien , qui lui a hérité d'une nouvelle adresse.
Trainerait-il quelque
part sur l'ancien "quelque chose" qui ferait des choses par @IP et
s'adresserait au
nouveau ??
Possible mais toujours est-il qu'une RedHat 7.2 n'est pas vraiment ce
qu'il y a de plus à jour: les failles existantes sont légions
maintenant. Avez-vous simplement pensé à modifier les mots de passe des
comptes utilisateurs ? Ne sous-estimez pas non plus une "attaque"
interne. Une autre machine a peut-être été aussi compromise...
J'ai bien peur, qu'au final, il ne faille ré-installer cette machine et,
de préférence, avec une distribution à jour telle que Fedora, Mandrake
ou Debian Sarge.
Merci de vos réponses , étudions maj RH.....
--
J.Bratières
Enlever paspub pour répondre
Please remove paspub when answering
Le Wed, 02 Feb 2005 10:45:41 +0100, Raphaël 'SurcouF' Bordet a écrit:
Bonjour, Sur le site d'un de nos clients (dont nous n'administrons pas le réseau) , un serveur HP sous RH7.2 , sans accès internet (donc pas de DNS , ...) , connecté au LAN , un routeur Netgear ADSL (avec parefeu par défaut),un modem de télémaintenance sur un autre serveur sur le LAN, rencontre le problème suivant:
Donc, connecté à Internet quand même, que tu le veuilles ou non.
Avant aujourd'hui: .connexion root en direct , fonctionnait OK .connexion root via telnet donnait parfois de manière aléatoire des "mots de passe invalides" que l'on "traitait" en se connectant sous un compte utilisateur et en faisant un su - root. La connexion utilisateur fonctionnait toujours. Depuis aujourd'hui: .le seul élément qui paraisse significatif (encore que ...) comme "déclencheur" est la création d'un compte utilisateur (non privilégié) pour faire des transferts FTP. .un premier test FTP sous ce compte a fonctionné .quelque temps plus tard: invalid password (via ftp) ,connexions sous telnet parfois valide , parfois invalid password. .la fonction su - xxx ne fonctionne plus ("impossible d'attribuer les groupes") .on observe que dans /var/log/messages pam signale des fichiers de /etc (securetty, ftpusers , shells) comme étant en écriture par world , en effet ils sont tous en 777. le fichier bin/su n'a plus l'attribut suid. .on remet les fichiers dans bonne protection (644) ,suid , ... tout remarche. .15 minutes après : les protections sont revenues à 777 (y compris /bin/su) .il en va de même de la base oracle dont l'exécutable doit être en protection 6751 et qui repasse en 777 .ceci est reproductible Nous avons: déconnecté le routeur (mais il semble qu'il y en ait d'autre sur le LAN). Cela n'a rien changé , les process actifs n'ont a priori rien de bizarre. Il n'y a pas de cron bizarres. Les shells .bashrc,bashrc,.bash_profile semblent OK. Il n' ya pas de fichiers récents dans les rc.d. Les fichiers reviennent en 777. Merci de toute idée .....
Rapatrie donc des exécutables sains de ps et ls et faire un tour d'horizon: je ne serais pas étonné que tu découvres des processus et des dossiers qui étaient jusque-là masqués à ton visage.
Pour info (ne semble pas avoir de rapport , mais ...) : ce serveur a remplacé en novembre un serveur plus ancien , qui reste sur le LAN , l'adresse IP du nouveau serveur est celle de l'ancien , qui lui a hérité d'une nouvelle adresse. Trainerait-il quelque part sur l'ancien "quelque chose" qui ferait des choses par @IP et s'adresserait au nouveau ??
Possible mais toujours est-il qu'une RedHat 7.2 n'est pas vraiment ce qu'il y a de plus à jour: les failles existantes sont légions maintenant. Avez-vous simplement pensé à modifier les mots de passe des comptes utilisateurs ? Ne sous-estimez pas non plus une "attaque" interne. Une autre machine a peut-être été aussi compromise...
J'ai bien peur, qu'au final, il ne faille ré-installer cette machine et, de préférence, avec une distribution à jour telle que Fedora, Mandrake ou Debian Sarge.
Merci de vos réponses , étudions maj RH.....
-- J.Bratières
Enlever paspub pour répondre Please remove paspub when answering
Eric Sibert
HP sous RH7.2 , sans accès internet (donc pas de DNS , ...) , connecté au LAN , un
Pas bien. RH7.2 n'est plus supporté...
.connexion root via telnet
Pas bien telnet ... pas sécurisé. Super pour se faire attraper du mot de passe root.
Comme suggéré par les autres intervenants, faire une mise à jour. Si, pour une raison ou une autre, vous ne souhaitez pas trop modifier votre serveur, allez au moins vers RedHat 7.3, qui, elle, est toujours supportée pour la sécurité. Un peu de lecture :
http://www.fedoralegacy.org
<<<Users of RHL 7.2 are urged to upgrade to RHL 7.3>>>
Eric
HP sous RH7.2 , sans accès internet (donc pas de DNS , ...) , connecté
au LAN , un
Pas bien. RH7.2 n'est plus supporté...
.connexion root via telnet
Pas bien telnet ... pas sécurisé. Super pour se faire attraper du mot de
passe root.
Comme suggéré par les autres intervenants, faire une mise à jour. Si,
pour une raison ou une autre, vous ne souhaitez pas trop modifier votre
serveur, allez au moins vers RedHat 7.3, qui, elle, est toujours
supportée pour la sécurité. Un peu de lecture :
http://www.fedoralegacy.org
<<<Users of RHL 7.2 are urged to upgrade to RHL 7.3>>>
HP sous RH7.2 , sans accès internet (donc pas de DNS , ...) , connecté au LAN , un
Pas bien. RH7.2 n'est plus supporté...
.connexion root via telnet
Pas bien telnet ... pas sécurisé. Super pour se faire attraper du mot de passe root.
Comme suggéré par les autres intervenants, faire une mise à jour. Si, pour une raison ou une autre, vous ne souhaitez pas trop modifier votre serveur, allez au moins vers RedHat 7.3, qui, elle, est toujours supportée pour la sécurité. Un peu de lecture :
http://www.fedoralegacy.org
<<<Users of RHL 7.2 are urged to upgrade to RHL 7.3>>>
Eric
Jérémy JUST
On Fri, 04 Feb 2005 17:28:22 +0100 Eric Sibert wrote:
.connexion root en direct , fonctionnait OK .connexion root via telnet donnait parfois de manière aléatoire des "mots de passe invalides" que l'on "traitait" en se connectant sous un compte utilisateur et en faisant un su - root. Pas bien telnet ... pas sécurisé. Super pour se faire attraper du mot
de passe root.
Entre telnet et la connexion distante en root, j'ai cru à un poisson d'avril... Ce qui est dommage, c'est que ça ne semble pas être le cas. La politique de sécurité sera à revoir sérieusement!
Un petit coup de chkrootkit ne pourra pas faire de mal pour commencer. Attention: un résultat négatif ne veut pas forcément dire que la machine est propre.
-- Jérémy JUST
On Fri, 04 Feb 2005 17:28:22 +0100
Eric Sibert <courrier@ericNOsibertSPAM.com> wrote:
.connexion root en direct , fonctionnait OK
.connexion root via telnet donnait parfois de manière aléatoire des
"mots de passe invalides" que l'on "traitait" en se connectant sous
un compte utilisateur et en faisant un su - root.
Pas bien telnet ... pas sécurisé. Super pour se faire attraper du mot
de passe root.
Entre telnet et la connexion distante en root, j'ai cru à un poisson
d'avril... Ce qui est dommage, c'est que ça ne semble pas être le cas.
La politique de sécurité sera à revoir sérieusement!
Un petit coup de chkrootkit ne pourra pas faire de mal pour
commencer. Attention: un résultat négatif ne veut pas forcément dire que
la machine est propre.
On Fri, 04 Feb 2005 17:28:22 +0100 Eric Sibert wrote:
.connexion root en direct , fonctionnait OK .connexion root via telnet donnait parfois de manière aléatoire des "mots de passe invalides" que l'on "traitait" en se connectant sous un compte utilisateur et en faisant un su - root. Pas bien telnet ... pas sécurisé. Super pour se faire attraper du mot
de passe root.
Entre telnet et la connexion distante en root, j'ai cru à un poisson d'avril... Ce qui est dommage, c'est que ça ne semble pas être le cas. La politique de sécurité sera à revoir sérieusement!
Un petit coup de chkrootkit ne pourra pas faire de mal pour commencer. Attention: un résultat négatif ne veut pas forcément dire que la machine est propre.
