Sur une Debian Sarge, un serveur dédié loué, l'hebergeur a contacté
le locataire du serveur pour lui dire que son serveur s'était fait
intruder.
Le gars, un poet à moi m'en a fait part, et m'a filé les identifiants
root de la machine. J'y accede par ssh.
J'ai installé iftop (c'est un truc qui fait comme 'top' mais pour le
réseau) et j'ai vu qu'il y a un nombre incroyable de connection sortantes
vers le port 22 (ssh) de plein d'adresses IP.
Note: Malheureusement je ne peux pas vous retraccer _exactement_ ce que
j'ai vu et fait mais je vous raconte juste les choses.
En voyant le nombre, je fais un 'netstat -taupe | grep ssh', et je vois
que c'est un process './pscan2' qui fait tout ça.
Bon premier reflexe, puisque je n'en ai pas besoin, un coup de DROP de
tout OUTPUT vers le port 22, histoire de calmer le réseau.
Le INPUT reste tel quel puisque je controle la machine avec.
'ps aux | grep pscan' me donne plein de processes au nom unique de 'jason'
Bon... un coup de boucle for avec les PID de tous les process qui ont un
rapport avec pscan et tous les pscan disparaissent... ça se calme
vraiment. Et ça ne redemarre pas. Ouf ...
Je passe un coup de 'updatebd', puis 'locate pscan'. Rien.
# cd /var/tmp
# ls -la
total 20
drwxrwxrwt 5 root root 4096 Feb 10 20:55 .
drwxr-xr-x 16 root root 4096 Jan 17 19:13 ..
drwxr-xr-x 6 jason jason 4096 Feb 16 19:21 .pzo
drwxr-xr-x 4 jason jason 4096 Feb 10 18:07 dwg
drwxrwxrwt 2 root root 4096 Jan 21 03:55 vi.recover
"jason" c'est le proprio (enfin le locataire) du serveur.
donc aparemment c'est soit lui qui s'est fait un truc histoire de me
tester, soit ben... je sais pas.
J'ai trouvé peu de truc sur pscan2 sur le net, et j'ai trouvé ceci:
Mais en général, je devrais faire quoi, a part virer/renommer/déplacer
ces fichiers dans /var/tmp? Est-ce un "faille/vulnérabilité/exploit"
connu?
--
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)
Sur une Debian Sarge, un serveur dédié loué, l'hebergeur a contacté le locataire du serveur pour lui dire que son serveur s'était fait intruder.
Le gars, un poet à moi m'en a fait part, et m'a filé les identifiants root de la machine. J'y accede par ssh.
J'ai installé iftop (c'est un truc qui fait comme 'top' mais pour le réseau) et j'ai vu qu'il y a un nombre incroyable de connection sortantes vers le port 22 (ssh) de plein d'adresses IP.
Note: Malheureusement je ne peux pas vous retraccer _exactement_ ce que j'ai vu et fait mais je vous raconte juste les choses.
En voyant le nombre, je fais un 'netstat -taupe | grep ssh', et je vois que c'est un process './pscan2' qui fait tout ça.
Bon premier reflexe, puisque je n'en ai pas besoin, un coup de DROP de tout OUTPUT vers le port 22, histoire de calmer le réseau.
Le INPUT reste tel quel puisque je controle la machine avec.
'ps aux | grep pscan' me donne plein de processes au nom unique de 'jason' Bon... un coup de boucle for avec les PID de tous les process qui ont un rapport avec pscan et tous les pscan disparaissent... ça se calme vraiment. Et ça ne redemarre pas. Ouf ...
Je passe un coup de 'updatebd', puis 'locate pscan'. Rien.
Mais en général, je devrais faire quoi, a part virer/renommer/déplacer ces fichiers dans /var/tmp? Est-ce un "faille/vulnérabilité/exploit" connu?
Si tu arrives à obtenir la preuve absolue que la machine n'est pas root-kittée (ou lkmrk) t'as peu être un chance de la faire fonctionner sainement en passant à la loupe tous les binaires et les so du système à partir d'outils propres, c'est à dire compilés en statique et importés pour le nettoyage.
Et encore.
Sinon, tu peux faire une incantation de réinstallation.
Sur une Debian Sarge, un serveur dédié loué, l'hebergeur a contacté
le locataire du serveur pour lui dire que son serveur s'était fait
intruder.
Le gars, un poet à moi m'en a fait part, et m'a filé les identifiants
root de la machine. J'y accede par ssh.
J'ai installé iftop (c'est un truc qui fait comme 'top' mais pour le
réseau) et j'ai vu qu'il y a un nombre incroyable de connection sortantes
vers le port 22 (ssh) de plein d'adresses IP.
Note: Malheureusement je ne peux pas vous retraccer _exactement_ ce que
j'ai vu et fait mais je vous raconte juste les choses.
En voyant le nombre, je fais un 'netstat -taupe | grep ssh', et je vois
que c'est un process './pscan2' qui fait tout ça.
Bon premier reflexe, puisque je n'en ai pas besoin, un coup de DROP de
tout OUTPUT vers le port 22, histoire de calmer le réseau.
Le INPUT reste tel quel puisque je controle la machine avec.
'ps aux | grep pscan' me donne plein de processes au nom unique de 'jason'
Bon... un coup de boucle for avec les PID de tous les process qui ont un
rapport avec pscan et tous les pscan disparaissent... ça se calme
vraiment. Et ça ne redemarre pas. Ouf ...
Je passe un coup de 'updatebd', puis 'locate pscan'. Rien.
Mais en général, je devrais faire quoi, a part virer/renommer/déplacer
ces fichiers dans /var/tmp? Est-ce un "faille/vulnérabilité/exploit"
connu?
Si tu arrives à obtenir la preuve absolue que la machine n'est pas root-kittée
(ou lkmrk) t'as peu être un chance de la faire fonctionner sainement en passant
à la loupe tous les binaires et les so du système à partir d'outils propres,
c'est à dire compilés en statique et importés pour le nettoyage.
Et encore.
Sinon, tu peux faire une incantation de réinstallation.
Sur une Debian Sarge, un serveur dédié loué, l'hebergeur a contacté le locataire du serveur pour lui dire que son serveur s'était fait intruder.
Le gars, un poet à moi m'en a fait part, et m'a filé les identifiants root de la machine. J'y accede par ssh.
J'ai installé iftop (c'est un truc qui fait comme 'top' mais pour le réseau) et j'ai vu qu'il y a un nombre incroyable de connection sortantes vers le port 22 (ssh) de plein d'adresses IP.
Note: Malheureusement je ne peux pas vous retraccer _exactement_ ce que j'ai vu et fait mais je vous raconte juste les choses.
En voyant le nombre, je fais un 'netstat -taupe | grep ssh', et je vois que c'est un process './pscan2' qui fait tout ça.
Bon premier reflexe, puisque je n'en ai pas besoin, un coup de DROP de tout OUTPUT vers le port 22, histoire de calmer le réseau.
Le INPUT reste tel quel puisque je controle la machine avec.
'ps aux | grep pscan' me donne plein de processes au nom unique de 'jason' Bon... un coup de boucle for avec les PID de tous les process qui ont un rapport avec pscan et tous les pscan disparaissent... ça se calme vraiment. Et ça ne redemarre pas. Ouf ...
Je passe un coup de 'updatebd', puis 'locate pscan'. Rien.
Mais en général, je devrais faire quoi, a part virer/renommer/déplacer ces fichiers dans /var/tmp? Est-ce un "faille/vulnérabilité/exploit" connu?
Si tu arrives à obtenir la preuve absolue que la machine n'est pas root-kittée (ou lkmrk) t'as peu être un chance de la faire fonctionner sainement en passant à la loupe tous les binaires et les so du système à partir d'outils propres, c'est à dire compilés en statique et importés pour le nettoyage.
Et encore.
Sinon, tu peux faire une incantation de réinstallation.
FAb
nicolas vigier
On 2005-02-15, Rakotomandimby (R12y) Mihamina wrote:
"jason" c'est le proprio (enfin le locataire) du serveur. donc aparemment c'est soit lui qui s'est fait un truc histoire de me tester, soit ben... je sais pas.
Ca ressemble aux tentatives de connections que (comme la plupars des gens je suppose) je recoi sur mes machines, avec des essais de tout un tas de logins classiques et mots de passe simples. Ton amis a du utiliser un mot de passe trop simple sur le compte "jason".
J'ai trouvé peu de truc sur pscan2 sur le net, et j'ai trouvé ceci:
Mais en général, je devrais faire quoi, a part virer/renommer/déplacer ces fichiers dans /var/tmp? Est-ce un "faille/vulnérabilité/exploit" connu?
Si tu en as la possibilite, je te conseil le backup de toutes les donnees, avant de reinstaller completement l'OS sur la machine. Sinon si tu penses que le compte root n'a pas ete ateint, tu peux te contenter de supprimer tous les fichiers du compte "jason" autres que des donnes, apres avoir reboote ou tue tous ses processus (et bien sur change le mot de pass si il etait trop simple).
On 2005-02-15, Rakotomandimby (R12y) Mihamina <mihamina@mail.rktmb.org> wrote:
"jason" c'est le proprio (enfin le locataire) du serveur.
donc aparemment c'est soit lui qui s'est fait un truc histoire de me
tester, soit ben... je sais pas.
Ca ressemble aux tentatives de connections que (comme la plupars des
gens je suppose) je recoi sur mes machines, avec des essais de tout un
tas de logins classiques et mots de passe simples. Ton amis a du
utiliser un mot de passe trop simple sur le compte "jason".
J'ai trouvé peu de truc sur pscan2 sur le net, et j'ai trouvé ceci:
Mais en général, je devrais faire quoi, a part virer/renommer/déplacer
ces fichiers dans /var/tmp? Est-ce un "faille/vulnérabilité/exploit"
connu?
Si tu en as la possibilite, je te conseil le backup de toutes les
donnees, avant de reinstaller completement l'OS sur la machine. Sinon
si tu penses que le compte root n'a pas ete ateint, tu peux te contenter
de supprimer tous les fichiers du compte "jason" autres que des donnes,
apres avoir reboote ou tue tous ses processus (et bien sur change le
mot de pass si il etait trop simple).
On 2005-02-15, Rakotomandimby (R12y) Mihamina wrote:
"jason" c'est le proprio (enfin le locataire) du serveur. donc aparemment c'est soit lui qui s'est fait un truc histoire de me tester, soit ben... je sais pas.
Ca ressemble aux tentatives de connections que (comme la plupars des gens je suppose) je recoi sur mes machines, avec des essais de tout un tas de logins classiques et mots de passe simples. Ton amis a du utiliser un mot de passe trop simple sur le compte "jason".
J'ai trouvé peu de truc sur pscan2 sur le net, et j'ai trouvé ceci:
Mais en général, je devrais faire quoi, a part virer/renommer/déplacer ces fichiers dans /var/tmp? Est-ce un "faille/vulnérabilité/exploit" connu?
Si tu en as la possibilite, je te conseil le backup de toutes les donnees, avant de reinstaller completement l'OS sur la machine. Sinon si tu penses que le compte root n'a pas ete ateint, tu peux te contenter de supprimer tous les fichiers du compte "jason" autres que des donnes, apres avoir reboote ou tue tous ses processus (et bien sur change le mot de pass si il etait trop simple).
Ca ressemble aux tentatives de connections que (comme la plupars des gens je suppose) je recoi sur mes machines, avec des essais de tout un tas de logins classiques et mots de passe simples. Ton amis a du utiliser un mot de passe trop simple sur le compte "jason".
D'ailleurs "jason" est un des login que ce genre de scanner essaye...
nicolas vigier wrote:
Ca ressemble aux tentatives de connections que (comme la plupars des
gens je suppose) je recoi sur mes machines, avec des essais de tout un
tas de logins classiques et mots de passe simples. Ton amis a du
utiliser un mot de passe trop simple sur le compte "jason".
D'ailleurs "jason" est un des login que ce genre de scanner essaye...
Ca ressemble aux tentatives de connections que (comme la plupars des gens je suppose) je recoi sur mes machines, avec des essais de tout un tas de logins classiques et mots de passe simples. Ton amis a du utiliser un mot de passe trop simple sur le compte "jason".
D'ailleurs "jason" est un des login que ce genre de scanner essaye...
Sebastien Vincent
"jason" c'est le proprio (enfin le locataire) du serveur. donc aparemment c'est soit lui qui s'est fait un truc histoire de me tester, soit ben... je sais pas.
Bah si tu te met à la place de l'attaquant, j'aurais fait pareil, il est bien plus discret de lancer tout cela en jason qu'en root :)
Je suis tombé la dessus tout a l'heure si tu as à faire a un 2.6 récent : http://www.guninski.com/where_do_you_want_billg_to_go_today_3.html
Mais sinon tu as toujours uselib() (la plupart des exploits publics ne marchent pas mais des privés fonctionnent très bien).
Pour les 2.4 ptrace() et do_brk() restent les plus utilisés avec un petit gout de mremap() en cas de total désespoir (mais au bout du compte ca marche bien aussi).
J'ai trouvé peu de truc sur pscan2 sur le net, et j'ai trouvé ceci:
Bah lance un string dessus voir si ce que c'est, mais l'interet est de masquer l'outil utilisé cela peut très bien être un remote shell style netcat ou rshell, ou autre...
Mais en général, je devrais faire quoi, a part virer/renommer/déplacer ces fichiers dans /var/tmp? Est-ce un "faille/vulnérabilité/exploit" connu?
Vérifie que le noyau est bien patché pour les différentes failles citées ci-dessus. Ca c'est le premier point.
Le second, c'est le php, ca c'est galère il y a des exploits publics qui sortent de partout en ce moment... Ne te laisse pas avoir par le fait qu'il n'y a pas de fichier ownés par www-data dans /tmp cela ne veux rien dire. Chasse les fichiers où others ont les droits d'écriture. De tête un : find / -perm +002.
Regarde si un fichier php n'a pas été "overwrité" par un shell php ou meme un binaire s'il a les droits d'execution.
Essaye un lsof et controle "tout", je veux dire par la le contenu des fichiers (le nom ne signifie rien).
Recherche tous les fichiers suid, notre ami s'est peux être "spawné" un shell uid 0 :) ou guid (wheel ?).
Après il y a des trucs encore plus "gros" mais la ce n'est pas le style de notre ami je pense. Ce que je t'ai dit ce sont des methodes classiques que l'on retrouve souvent.
Et après, on a beau dire, mais la meilleure solution c'est une réinstallation complète.
Bon bah bonne chance :)
Cordialement,
Sebastien VINCENT.
"jason" c'est le proprio (enfin le locataire) du serveur.
donc aparemment c'est soit lui qui s'est fait un truc histoire de me
tester, soit ben... je sais pas.
Bah si tu te met à la place de l'attaquant, j'aurais fait pareil, il est
bien plus discret de lancer tout cela en jason qu'en root :)
Je suis tombé la dessus tout a l'heure si tu as à faire a un
2.6 récent :
http://www.guninski.com/where_do_you_want_billg_to_go_today_3.html
Mais sinon tu as toujours uselib() (la plupart des exploits publics
ne marchent pas mais des privés fonctionnent très bien).
Pour les 2.4 ptrace() et do_brk() restent les plus utilisés avec un
petit gout de mremap() en cas de total désespoir (mais au bout du
compte ca marche bien aussi).
J'ai trouvé peu de truc sur pscan2 sur le net, et j'ai trouvé ceci:
Bah lance un string dessus voir si ce que c'est, mais l'interet est de
masquer l'outil utilisé cela peut très bien être un remote shell style
netcat ou rshell, ou autre...
Mais en général, je devrais faire quoi, a part virer/renommer/déplacer
ces fichiers dans /var/tmp? Est-ce un "faille/vulnérabilité/exploit"
connu?
Vérifie que le noyau est bien patché pour les différentes failles citées
ci-dessus. Ca c'est le premier point.
Le second, c'est le php, ca c'est galère il y a des exploits publics qui
sortent de partout en ce moment... Ne te laisse pas avoir par le fait
qu'il n'y a pas de fichier ownés par www-data dans /tmp cela ne veux
rien dire. Chasse les fichiers où others ont les droits d'écriture.
De tête un : find / -perm +002.
Regarde si un fichier php n'a pas été "overwrité" par un shell php ou
meme un binaire s'il a les droits d'execution.
Essaye un lsof et controle "tout", je veux dire par la le contenu des
fichiers (le nom ne signifie rien).
Recherche tous les fichiers suid, notre ami s'est peux être "spawné" un
shell uid 0 :) ou guid (wheel ?).
Après il y a des trucs encore plus "gros" mais la ce n'est pas le style
de notre ami je pense. Ce que je t'ai dit ce sont des methodes
classiques que l'on retrouve souvent.
Et après, on a beau dire, mais la meilleure solution c'est une
réinstallation complète.
"jason" c'est le proprio (enfin le locataire) du serveur. donc aparemment c'est soit lui qui s'est fait un truc histoire de me tester, soit ben... je sais pas.
Bah si tu te met à la place de l'attaquant, j'aurais fait pareil, il est bien plus discret de lancer tout cela en jason qu'en root :)
Je suis tombé la dessus tout a l'heure si tu as à faire a un 2.6 récent : http://www.guninski.com/where_do_you_want_billg_to_go_today_3.html
Mais sinon tu as toujours uselib() (la plupart des exploits publics ne marchent pas mais des privés fonctionnent très bien).
Pour les 2.4 ptrace() et do_brk() restent les plus utilisés avec un petit gout de mremap() en cas de total désespoir (mais au bout du compte ca marche bien aussi).
J'ai trouvé peu de truc sur pscan2 sur le net, et j'ai trouvé ceci:
Bah lance un string dessus voir si ce que c'est, mais l'interet est de masquer l'outil utilisé cela peut très bien être un remote shell style netcat ou rshell, ou autre...
Mais en général, je devrais faire quoi, a part virer/renommer/déplacer ces fichiers dans /var/tmp? Est-ce un "faille/vulnérabilité/exploit" connu?
Vérifie que le noyau est bien patché pour les différentes failles citées ci-dessus. Ca c'est le premier point.
Le second, c'est le php, ca c'est galère il y a des exploits publics qui sortent de partout en ce moment... Ne te laisse pas avoir par le fait qu'il n'y a pas de fichier ownés par www-data dans /tmp cela ne veux rien dire. Chasse les fichiers où others ont les droits d'écriture. De tête un : find / -perm +002.
Regarde si un fichier php n'a pas été "overwrité" par un shell php ou meme un binaire s'il a les droits d'execution.
Essaye un lsof et controle "tout", je veux dire par la le contenu des fichiers (le nom ne signifie rien).
Recherche tous les fichiers suid, notre ami s'est peux être "spawné" un shell uid 0 :) ou guid (wheel ?).
Après il y a des trucs encore plus "gros" mais la ce n'est pas le style de notre ami je pense. Ce que je t'ai dit ce sont des methodes classiques que l'on retrouve souvent.
Et après, on a beau dire, mais la meilleure solution c'est une réinstallation complète.
Bon bah bonne chance :)
Cordialement,
Sebastien VINCENT.
Rakotomandimby (R12y) Mihamina
( Wed, 16 Feb 2005 10:18:31 +0000 ) FAb :
Sinon, tu peux faire une incantation de réinstallation.
Bah non. ça coute cher. Et puis en supprimant l'user en question et les fichiers qui étaient dans /tmp/ et /var/tmp ... ça s'est calmé.
-- 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, 16 Feb 2005 10:18:31 +0000 ) FAb :
Sinon, tu peux faire une incantation de réinstallation.
Bah non. ça coute cher.
Et puis en supprimant l'user en question et les fichiers qui étaient dans
/tmp/ et /var/tmp ... ça s'est calmé.
--
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)
Sinon, tu peux faire une incantation de réinstallation.
Bah non. ça coute cher. Et puis en supprimant l'user en question et les fichiers qui étaient dans /tmp/ et /var/tmp ... ça s'est calmé.
-- 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)
FAb
"Rakotomandimby (R12y) Mihamina" writes:
( Wed, 16 Feb 2005 10:18:31 +0000 ) FAb :
Sinon, tu peux faire une incantation de réinstallation.
Bah non. ça coute cher. Et puis en supprimant l'user en question et les fichiers qui étaient dans /tmp/ et /var/tmp ... ça s'est calmé.
Questions :
- Que faisait pscan ? Y avait-il les sources ? - La machine est-elle saine ??? Si psan est un programme pour attaquer d'autres machines il est plus que probable que la personne qui est entré s'est gardé une porte pour revenir. - La brèche par laquelle elle s'est introduite a été identifiée et supprimée ? - Les données sont-elles sauvegardées et prêtes pour une réinstallation ?
Enfin je ne suis pas un expert dans le domaine comme les habitués de ce ng, mais c'est juste ce qui me semble être le bon sens.
Sinon, tu peux faire une incantation de réinstallation.
Bah non. ça coute cher.
Et puis en supprimant l'user en question et les fichiers qui étaient dans
/tmp/ et /var/tmp ... ça s'est calmé.
Questions :
- Que faisait pscan ? Y avait-il les sources ?
- La machine est-elle saine ???
Si psan est un programme pour attaquer d'autres machines il est plus que
probable que la personne qui est entré s'est gardé une porte pour revenir.
- La brèche par laquelle elle s'est introduite a été identifiée et supprimée ?
- Les données sont-elles sauvegardées et prêtes pour une réinstallation ?
Enfin je ne suis pas un expert dans le domaine comme les habitués de ce ng, mais
c'est juste ce qui me semble être le bon sens.
Sinon, tu peux faire une incantation de réinstallation.
Bah non. ça coute cher. Et puis en supprimant l'user en question et les fichiers qui étaient dans /tmp/ et /var/tmp ... ça s'est calmé.
Questions :
- Que faisait pscan ? Y avait-il les sources ? - La machine est-elle saine ??? Si psan est un programme pour attaquer d'autres machines il est plus que probable que la personne qui est entré s'est gardé une porte pour revenir. - La brèche par laquelle elle s'est introduite a été identifiée et supprimée ? - Les données sont-elles sauvegardées et prêtes pour une réinstallation ?
Enfin je ne suis pas un expert dans le domaine comme les habitués de ce ng, mais c'est juste ce qui me semble être le bon sens.
FAb
Vincent Bernat
OoO En cette nuit nuageuse du jeudi 17 février 2005, vers 01:49, "Rakotomandimby (R12y) Mihamina" disait:
Sinon, tu peux faire une incantation de réinstallation.
Bah non. ça coute cher. Et puis en supprimant l'user en question et les fichiers qui étaient dans /tmp/ et /var/tmp ... ça s'est calmé.
Si le propriétaire du script qui a effectué l'intrusion a été prévenu de l'intrusion et a trouvé une faille locale, il a tout intérêt à ne plus continuer les scans classiques et à laisser passer du temps.
C'est un compte d'administrateur qui a été pris là, il est assez facile de voler le mot de passe root ensuite (pire encore s'il y avait sudo, il l'a déjà) en collant des binaires trafiqués de su par exemple. -- Let the machine do the dirty work. - The Elements of Programming Style (Kernighan & Plaugher)
OoO En cette nuit nuageuse du jeudi 17 février 2005, vers 01:49,
"Rakotomandimby (R12y) Mihamina" <mihamina@mail.rktmb.org> disait:
Sinon, tu peux faire une incantation de réinstallation.
Bah non. ça coute cher.
Et puis en supprimant l'user en question et les fichiers qui étaient dans
/tmp/ et /var/tmp ... ça s'est calmé.
Si le propriétaire du script qui a effectué l'intrusion a été prévenu
de l'intrusion et a trouvé une faille locale, il a tout intérêt à ne
plus continuer les scans classiques et à laisser passer du
temps.
C'est un compte d'administrateur qui a été pris là, il est assez
facile de voler le mot de passe root ensuite (pire encore s'il y avait
sudo, il l'a déjà) en collant des binaires trafiqués de su par
exemple.
--
Let the machine do the dirty work.
- The Elements of Programming Style (Kernighan & Plaugher)
OoO En cette nuit nuageuse du jeudi 17 février 2005, vers 01:49, "Rakotomandimby (R12y) Mihamina" disait:
Sinon, tu peux faire une incantation de réinstallation.
Bah non. ça coute cher. Et puis en supprimant l'user en question et les fichiers qui étaient dans /tmp/ et /var/tmp ... ça s'est calmé.
Si le propriétaire du script qui a effectué l'intrusion a été prévenu de l'intrusion et a trouvé une faille locale, il a tout intérêt à ne plus continuer les scans classiques et à laisser passer du temps.
C'est un compte d'administrateur qui a été pris là, il est assez facile de voler le mot de passe root ensuite (pire encore s'il y avait sudo, il l'a déjà) en collant des binaires trafiqués de su par exemple. -- Let the machine do the dirty work. - The Elements of Programming Style (Kernighan & Plaugher)
Cedric Blancher
Le Thu, 17 Feb 2005 00:49:20 +0000, Rakotomandimby (R12y) Mihamina a écrit :
Bah non. ça coute cher.
Ah ben ouais, mais faut savoir ce que tu veux...
Et puis en supprimant l'user en question et les fichiers qui étaient dans /tmp/ et /var/tmp ... ça s'est calmé.
Est-ce que tu as corrigé la faille qui a permis au mec de rentrer sur la machine ? Est-ce qu'au moins tu sais comment il a fait ? Est-ce que tu es sûr qu'il n'a pas fait autre chose sur la machine ?
Si tu ne sais pas répondre à ces questions, tu peux passer par la case réinstallation complète, et pour autant, tu ne seras toujours pas en sécurité car la probabilité que ta nouvelle installation soit également vulnérable est loin d'être faible...
-- BOFH excuse #149:
Dew on the telephone lines.
Le Thu, 17 Feb 2005 00:49:20 +0000, Rakotomandimby (R12y) Mihamina a
écrit :
Bah non. ça coute cher.
Ah ben ouais, mais faut savoir ce que tu veux...
Et puis en supprimant l'user en question et les fichiers qui étaient dans
/tmp/ et /var/tmp ... ça s'est calmé.
Est-ce que tu as corrigé la faille qui a permis au mec de rentrer sur la
machine ? Est-ce qu'au moins tu sais comment il a fait ?
Est-ce que tu es sûr qu'il n'a pas fait autre chose sur la machine ?
Si tu ne sais pas répondre à ces questions, tu peux passer par la case
réinstallation complète, et pour autant, tu ne seras toujours pas en
sécurité car la probabilité que ta nouvelle installation soit
également vulnérable est loin d'être faible...
Le Thu, 17 Feb 2005 00:49:20 +0000, Rakotomandimby (R12y) Mihamina a écrit :
Bah non. ça coute cher.
Ah ben ouais, mais faut savoir ce que tu veux...
Et puis en supprimant l'user en question et les fichiers qui étaient dans /tmp/ et /var/tmp ... ça s'est calmé.
Est-ce que tu as corrigé la faille qui a permis au mec de rentrer sur la machine ? Est-ce qu'au moins tu sais comment il a fait ? Est-ce que tu es sûr qu'il n'a pas fait autre chose sur la machine ?
Si tu ne sais pas répondre à ces questions, tu peux passer par la case réinstallation complète, et pour autant, tu ne seras toujours pas en sécurité car la probabilité que ta nouvelle installation soit également vulnérable est loin d'être faible...
-- BOFH excuse #149:
Dew on the telephone lines.
Rakotomandimby (R12y) Mihamina
( Thu, 17 Feb 2005 18:07:20 +0000 ) Xavier :
NON. La machine est et reste trouée.
J'en suis convaincu. Maintenant, dans l'immediat, une reinstallation n'est pas envisageable.
Si tu veux, le gars il a deja compromis sa machine deux fois en la reinstallant en un mois de location. Il va pas decider de reinstaller de suite.Il sous-loue a des gugus qui font des scripts php de merde et qui ont un acces shell, mais lui il comprend pas, il veut ca c'est tout. Il decidera de reinstaller quand la machine sera totalement HS.
Donc un niveau de la sécurité, on cherche un moyen de "colmater" avec de la rustine d'abord (genre kill regulier des processes qui tournent sous un user qui a un shell, sauf root, etc etc... reload periodique du script iptable avec un blocage de presque tout en output pour eviter de tonber le reseau de l'hebergeur,..., bref, du bricolage quoi) . Les backups sont fait plus souvent que jamais et c'est tout.
Ton attitude, excuse moi de le dire comme ça, est celle du mec qui tombe du 90ième étage : "jusqu'ici, tout va bien"
Non. du 90 eme etage quand tu tombe t'as interet a voir la vie en bien parceque ce sont tes dernieres secondes a vivre.
-- 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)
( Thu, 17 Feb 2005 18:07:20 +0000 ) Xavier :
NON. La machine est et reste trouée.
J'en suis convaincu.
Maintenant, dans l'immediat, une reinstallation n'est pas envisageable.
Si tu veux, le gars il a deja compromis sa machine deux fois en la
reinstallant en un mois de location. Il va pas decider de reinstaller de
suite.Il sous-loue a des gugus qui font des scripts php de merde et qui
ont un acces shell, mais lui il comprend pas, il veut ca c'est tout. Il
decidera de reinstaller quand la machine sera totalement HS.
Donc un niveau de la sécurité, on cherche un moyen de "colmater" avec de
la rustine d'abord (genre kill regulier des processes qui tournent sous un
user qui a un shell, sauf root, etc etc... reload periodique du script
iptable avec un blocage de presque tout en output pour eviter de
tonber le reseau de l'hebergeur,..., bref, du bricolage quoi) . Les
backups sont fait plus souvent que jamais et c'est tout.
Ton attitude, excuse moi de le dire comme ça, est celle du mec qui
tombe du 90ième étage : "jusqu'ici, tout va bien"
Non. du 90 eme etage quand tu tombe t'as interet a voir la vie en bien
parceque ce sont tes dernieres secondes a vivre.
--
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)
J'en suis convaincu. Maintenant, dans l'immediat, une reinstallation n'est pas envisageable.
Si tu veux, le gars il a deja compromis sa machine deux fois en la reinstallant en un mois de location. Il va pas decider de reinstaller de suite.Il sous-loue a des gugus qui font des scripts php de merde et qui ont un acces shell, mais lui il comprend pas, il veut ca c'est tout. Il decidera de reinstaller quand la machine sera totalement HS.
Donc un niveau de la sécurité, on cherche un moyen de "colmater" avec de la rustine d'abord (genre kill regulier des processes qui tournent sous un user qui a un shell, sauf root, etc etc... reload periodique du script iptable avec un blocage de presque tout en output pour eviter de tonber le reseau de l'hebergeur,..., bref, du bricolage quoi) . Les backups sont fait plus souvent que jamais et c'est tout.
Ton attitude, excuse moi de le dire comme ça, est celle du mec qui tombe du 90ième étage : "jusqu'ici, tout va bien"
Non. du 90 eme etage quand tu tombe t'as interet a voir la vie en bien parceque ce sont tes dernieres secondes a vivre.
-- 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)
Nicob
On Fri, 18 Feb 2005 09:14:19 +0000, Rakotomandimby (R12y) Mihamina wrote:
Si tu veux, le gars il a deja compromis sa machine deux fois en la reinstallant en un mois de location
J'avoue ne pas avoir compris cette phrase ...
Nicob
On Fri, 18 Feb 2005 09:14:19 +0000, Rakotomandimby (R12y) Mihamina wrote:
Si tu veux, le gars il a deja compromis sa machine deux fois en la
reinstallant en un mois de location
