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)
On 2005-02-18, Rakotomandimby (R12y) Mihamina wrote:
2) Ok , l'intrus a réussi a faire tourner sa merde sous l'user du locataire du serveur. C'est par là qu'on en déduis qu'il a reussi a avoir plus de privilèges qu'un simple user ?
Est ce que tu connais le mot de pass de ce compte ? Tu peux toujours passer du temps a securiser le serveur, mais si le proprietaire du compte utilise 'toto' comme password, ca ne sert pas a grand chose.
On 2005-02-18, Rakotomandimby (R12y) Mihamina <mihamina@mail.rktmb.org> wrote:
2) Ok , l'intrus a réussi a faire tourner sa merde sous l'user du
locataire du serveur. C'est par là qu'on en déduis qu'il a reussi a
avoir plus de privilèges qu'un simple user ?
Est ce que tu connais le mot de pass de ce compte ?
Tu peux toujours passer du temps a securiser le serveur, mais si le
proprietaire du compte utilise 'toto' comme password, ca ne sert pas
a grand chose.
On 2005-02-18, Rakotomandimby (R12y) Mihamina wrote:
2) Ok , l'intrus a réussi a faire tourner sa merde sous l'user du locataire du serveur. C'est par là qu'on en déduis qu'il a reussi a avoir plus de privilèges qu'un simple user ?
Est ce que tu connais le mot de pass de ce compte ? Tu peux toujours passer du temps a securiser le serveur, mais si le proprietaire du compte utilise 'toto' comme password, ca ne sert pas a grand chose.
1) une machine sur laquelle s'est executée un binaire lancé depuis /tmp/ ou /var/tmp est-elle à coup sur root-kitée ? En effet, ce sont des repertoires wide-writable... pas besoin d'être root pour y ecrire.
Certes. Mais : a) le gus n'aurais pas du arriver ici. Il a donc un accès illégitime sur la machine.
b) il existe pas mal de failles qui permettent de passer root une fois en local et si on laisse entrer un gus sur la machine (premier problème de sécu) je parie volontier que le système est loin d'être patché contre les exploits locaux :-/
2) Ok , l'intrus a réussi a faire tourner sa merde sous l'user du locataire du serveur. C'est par là qu'on en déduis qu'il a reussi a avoir plus de privilèges qu'un simple user ?
Non, mais voir b au dessus. De plus sauf si on a prévu d'agir en amount (aide, anti-rootkits) il est presqu'impossible sur un serveur qu'on ne redémarre pas (genre CD de rescue) de s'assurer qu'il ne reste pas quelques surprises.
3) J'ai mal fait (une partie de) mon boulot. Ok. Bon maintenant, réinstaller...
Ben oui :) On fait tous des connerie à un moment ou un autre : j'ai été prendre mon café avec un log root sur ssh sans verrouiller ma console -ou mieux me délogger et verrouiller la console- cet aprem. Ok j'étais chez moi et seul mais c'est vraiment le genre de truc à finir mal :-(
Eric.
-- L'invulnérable : Je ne pense pas etre piratable, infectable par un trojen oui! Vu sur fcs un jour de mars 2004.
Rakotomandimby (R12y) Mihamina wrote:
1) une machine sur laquelle s'est executée un binaire lancé depuis /tmp/
ou /var/tmp est-elle à coup sur root-kitée ? En effet, ce sont des
repertoires wide-writable... pas besoin d'être root pour y ecrire.
Certes. Mais :
a) le gus n'aurais pas du arriver ici. Il a donc un accès illégitime sur
la machine.
b) il existe pas mal de failles qui permettent de passer root une fois
en local et si on laisse entrer un gus sur la machine (premier problème
de sécu) je parie volontier que le système est loin d'être patché contre
les exploits locaux :-/
2) Ok , l'intrus a réussi a faire tourner sa merde sous l'user du
locataire du serveur. C'est par là qu'on en déduis qu'il a reussi a
avoir plus de privilèges qu'un simple user ?
Non, mais voir b au dessus.
De plus sauf si on a prévu d'agir en amount (aide, anti-rootkits) il est
presqu'impossible sur un serveur qu'on ne redémarre pas (genre CD de
rescue) de s'assurer qu'il ne reste pas quelques surprises.
3) J'ai mal fait (une partie de) mon boulot. Ok. Bon maintenant,
réinstaller...
Ben oui :)
On fait tous des connerie à un moment ou un autre :
j'ai été prendre mon café avec un log root sur ssh sans verrouiller ma
console -ou mieux me délogger et verrouiller la console- cet aprem.
Ok j'étais chez moi et seul mais c'est vraiment le genre de truc à finir
mal :-(
Eric.
--
L'invulnérable :
Je ne pense pas etre piratable, infectable par un trojen oui!
Vu sur fcs un jour de mars 2004.
1) une machine sur laquelle s'est executée un binaire lancé depuis /tmp/ ou /var/tmp est-elle à coup sur root-kitée ? En effet, ce sont des repertoires wide-writable... pas besoin d'être root pour y ecrire.
Certes. Mais : a) le gus n'aurais pas du arriver ici. Il a donc un accès illégitime sur la machine.
b) il existe pas mal de failles qui permettent de passer root une fois en local et si on laisse entrer un gus sur la machine (premier problème de sécu) je parie volontier que le système est loin d'être patché contre les exploits locaux :-/
2) Ok , l'intrus a réussi a faire tourner sa merde sous l'user du locataire du serveur. C'est par là qu'on en déduis qu'il a reussi a avoir plus de privilèges qu'un simple user ?
Non, mais voir b au dessus. De plus sauf si on a prévu d'agir en amount (aide, anti-rootkits) il est presqu'impossible sur un serveur qu'on ne redémarre pas (genre CD de rescue) de s'assurer qu'il ne reste pas quelques surprises.
3) J'ai mal fait (une partie de) mon boulot. Ok. Bon maintenant, réinstaller...
Ben oui :) On fait tous des connerie à un moment ou un autre : j'ai été prendre mon café avec un log root sur ssh sans verrouiller ma console -ou mieux me délogger et verrouiller la console- cet aprem. Ok j'étais chez moi et seul mais c'est vraiment le genre de truc à finir mal :-(
Eric.
-- L'invulnérable : Je ne pense pas etre piratable, infectable par un trojen oui! Vu sur fcs un jour de mars 2004.
FAb
"Rakotomandimby (R12y) Mihamina" writes:
( Fri, 18 Feb 2005 16:27:13 +0000 ) FAb :
V'là quoi un petit rappel ne ferait pas de mal je pense.
Merci. Mais:
1) une machine sur laquelle s'est executée un binaire lancé depuis /tmp/ ou /var/tmp est-elle à coup sur root-kitée ? En effet, ce sont des repertoires wide-writable... pas besoin d'être root pour y ecrire.
Truc a faire c est de rendre la partition non executable ! Je viens juste d y penser !
2) Ok , l'intrus a réussi a faire tourner sa merde sous l'user du locataire du serveur. C'est par là qu'on en déduis qu'il a reussi a avoir plus de privilèges qu'un simple user ?
Oui s'il a DL un exploit qui lui a permis de passer root
3) J'ai mal fait (une partie de) mon boulot. Ok. Bon maintenant, réinstaller...
V'là quoi un petit rappel ne ferait pas de mal je pense.
Merci.
Mais:
1) une machine sur laquelle s'est executée un binaire lancé depuis /tmp/
ou /var/tmp est-elle à coup sur root-kitée ? En effet, ce sont des
repertoires wide-writable... pas besoin d'être root pour y ecrire.
Truc a faire c est de rendre la partition non executable ! Je viens juste d y
penser !
2) Ok , l'intrus a réussi a faire tourner sa merde sous l'user du
locataire du serveur. C'est par là qu'on en déduis qu'il a reussi a
avoir plus de privilèges qu'un simple user ?
Oui s'il a DL un exploit qui lui a permis de passer root
3) J'ai mal fait (une partie de) mon boulot. Ok. Bon maintenant,
réinstaller...
V'là quoi un petit rappel ne ferait pas de mal je pense.
Merci. Mais:
1) une machine sur laquelle s'est executée un binaire lancé depuis /tmp/ ou /var/tmp est-elle à coup sur root-kitée ? En effet, ce sont des repertoires wide-writable... pas besoin d'être root pour y ecrire.
Truc a faire c est de rendre la partition non executable ! Je viens juste d y penser !
2) Ok , l'intrus a réussi a faire tourner sa merde sous l'user du locataire du serveur. C'est par là qu'on en déduis qu'il a reussi a avoir plus de privilèges qu'un simple user ?
Oui s'il a DL un exploit qui lui a permis de passer root
3) J'ai mal fait (une partie de) mon boulot. Ok. Bon maintenant, réinstaller...
Ca vaudrait mieux
FAb (il galere en ssh par putty un azerty)
Patrick Mevzek
Patrick Mevzek wrote:
Le Fri, 18 Feb 2005 10:14:19 +0100, Rakotomandimby (R12y) Mihamina a écrit
Chez certains hébergeurs, dès qu'ils estiment la machine vérolée, ils la débranchent et ne la rebranchent qu'après paiement *et* réinstallation.
Si je paye pour une certaine bande passante et que le gus me débranche la machine au lieu de limiter la BP ça va chier pour lui en justice[1](sauf si son contrat le prévoit mais j'aurais été voir
Oui, sauf si le contrat le prévoit, et le contrat le prévoit bien plus souvent qu'on ne le pense, vu qu'on ne le lit pas souvent en intégralité, notes et annexes y compris. Après, effectivement, la concurrence aidant, on devrait toujours pouvoir trouver le prestataire de son choix avec le contrat qui va bien. En pratique, les gens qui courent après le prix le plus bas risquent de ne pas prêter suffisamment attention aux clauses contractuelles... notamment celles qui vont leur tomber dessus des mois après l'achat.
Pour en revenir au cas présenté je trouve quand même irresponsable de laisser en place la machine plus que potentiellement compromise (surtout si on vend, même partiellement, de la sécu!).
Nous sommes d'accord, mais il faut mettre alors dans la *même* catégorie les possesseurs d'une connexion ADSL qui ne font strictement rien pour sécuriser leur machine (leur tord n'étant pas à 100% de leur côté aussi, certains constructeurs devraient être trainés devant la justice pour vice caché...)
Au minimum tu peux au moins tenter de bloquer tous les ports (sauf un ssh sur ton ip par exemple) et de faire un D/SNAT vers une autres machine mise en place où tu veux pour l'occasion (ton prestataire peut peut être même règler ça en amount de ta machine ce qui évite les gags de portknocking).
C'est ce que je proposais, en gros. Ce n'est qu'un palliatif, nous sommes d'accord. Une réinstallation s'impose.
En ayant préparé[2] à l'avance cette machine (backup de la première) tu
Si on n'a pas le temps/l'envie de sécuriser une machine, je pense qu'il est irréaliste d'espérer avoir le temps/l'envie d'en sécuriser une autre, en cas de problèmes.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Patrick Mevzek wrote:
Le Fri, 18 Feb 2005 10:14:19 +0100, Rakotomandimby (R12y) Mihamina a
écrit
Chez certains hébergeurs, dès qu'ils estiment la machine vérolée, ils
la débranchent et ne la rebranchent qu'après paiement *et*
réinstallation.
Si je paye pour une certaine bande passante et que le gus me débranche
la machine au lieu de limiter la BP ça va chier pour lui en
justice[1](sauf si son contrat le prévoit mais j'aurais été voir
Oui, sauf si le contrat le prévoit, et le contrat le prévoit bien plus
souvent qu'on ne le pense, vu qu'on ne le lit pas souvent en intégralité,
notes et annexes y compris.
Après, effectivement, la concurrence aidant, on devrait toujours pouvoir
trouver le prestataire de son choix avec le contrat qui va bien. En
pratique, les gens qui courent après le prix le plus bas risquent de ne
pas prêter suffisamment attention aux clauses contractuelles... notamment
celles qui vont leur tomber dessus des mois après l'achat.
Pour en revenir au cas présenté je trouve quand même irresponsable de
laisser en place la machine plus que potentiellement compromise (surtout
si on vend, même partiellement, de la sécu!).
Nous sommes d'accord, mais il faut mettre alors dans la *même* catégorie
les possesseurs d'une connexion ADSL qui ne font strictement rien pour
sécuriser leur machine (leur tord n'étant pas à 100% de leur côté aussi,
certains constructeurs devraient être trainés devant la justice pour vice
caché...)
Au minimum tu peux au moins tenter de bloquer tous les ports (sauf un
ssh sur ton ip par exemple) et de faire un D/SNAT vers une autres
machine mise en place où tu veux pour l'occasion (ton prestataire peut
peut être même règler ça en amount de ta machine ce qui évite les gags
de portknocking).
C'est ce que je proposais, en gros. Ce n'est qu'un palliatif, nous sommes
d'accord. Une réinstallation s'impose.
En ayant préparé[2] à l'avance cette machine (backup de la première) tu
Si on n'a pas le temps/l'envie de sécuriser une machine, je pense qu'il
est irréaliste d'espérer avoir le temps/l'envie d'en sécuriser une autre,
en cas de problèmes.
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Le Fri, 18 Feb 2005 10:14:19 +0100, Rakotomandimby (R12y) Mihamina a écrit
Chez certains hébergeurs, dès qu'ils estiment la machine vérolée, ils la débranchent et ne la rebranchent qu'après paiement *et* réinstallation.
Si je paye pour une certaine bande passante et que le gus me débranche la machine au lieu de limiter la BP ça va chier pour lui en justice[1](sauf si son contrat le prévoit mais j'aurais été voir
Oui, sauf si le contrat le prévoit, et le contrat le prévoit bien plus souvent qu'on ne le pense, vu qu'on ne le lit pas souvent en intégralité, notes et annexes y compris. Après, effectivement, la concurrence aidant, on devrait toujours pouvoir trouver le prestataire de son choix avec le contrat qui va bien. En pratique, les gens qui courent après le prix le plus bas risquent de ne pas prêter suffisamment attention aux clauses contractuelles... notamment celles qui vont leur tomber dessus des mois après l'achat.
Pour en revenir au cas présenté je trouve quand même irresponsable de laisser en place la machine plus que potentiellement compromise (surtout si on vend, même partiellement, de la sécu!).
Nous sommes d'accord, mais il faut mettre alors dans la *même* catégorie les possesseurs d'une connexion ADSL qui ne font strictement rien pour sécuriser leur machine (leur tord n'étant pas à 100% de leur côté aussi, certains constructeurs devraient être trainés devant la justice pour vice caché...)
Au minimum tu peux au moins tenter de bloquer tous les ports (sauf un ssh sur ton ip par exemple) et de faire un D/SNAT vers une autres machine mise en place où tu veux pour l'occasion (ton prestataire peut peut être même règler ça en amount de ta machine ce qui évite les gags de portknocking).
C'est ce que je proposais, en gros. Ce n'est qu'un palliatif, nous sommes d'accord. Une réinstallation s'impose.
En ayant préparé[2] à l'avance cette machine (backup de la première) tu
Si on n'a pas le temps/l'envie de sécuriser une machine, je pense qu'il est irréaliste d'espérer avoir le temps/l'envie d'en sécuriser une autre, en cas de problèmes.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Arnaud Gomes-do-Vale
FAb writes:
1) une machine sur laquelle s'est executée un binaire lancé depuis /tmp/ ou /var/tmp est-elle à coup sur root-kitée ? En effet, ce sont des repertoires wide-writable... pas besoin d'être root pour y ecrire.
Truc a faire c est de rendre la partition non executable ! Je viens juste d y penser !
Pas évident. Certains logiciels, à commencer par RPM, s'attendent à pouvoir y mettre des exécutables (les scripts pré/post-installation dans le cas de RPM).
-- Arnaud
FAb <fab@mortimer.localdomain> writes:
1) une machine sur laquelle s'est executée un binaire lancé depuis /tmp/
ou /var/tmp est-elle à coup sur root-kitée ? En effet, ce sont des
repertoires wide-writable... pas besoin d'être root pour y ecrire.
Truc a faire c est de rendre la partition non executable ! Je viens juste d y
penser !
Pas évident. Certains logiciels, à commencer par RPM, s'attendent à
pouvoir y mettre des exécutables (les scripts pré/post-installation
dans le cas de RPM).
1) une machine sur laquelle s'est executée un binaire lancé depuis /tmp/ ou /var/tmp est-elle à coup sur root-kitée ? En effet, ce sont des repertoires wide-writable... pas besoin d'être root pour y ecrire.
Truc a faire c est de rendre la partition non executable ! Je viens juste d y penser !
Pas évident. Certains logiciels, à commencer par RPM, s'attendent à pouvoir y mettre des exécutables (les scripts pré/post-installation dans le cas de RPM).
