Re: rootkit Jessie?
Le jeudi 18 septembre 2014, 16:06:28 Serge SMEESTERS a écrit :
>[… find /proc | sed | sh …]
> Et c'est curieux, alors que je cherchais à trouver les PID,
> elles ont finis par disparaître...
> Serions-nous à ce point surveillé :)
Ce qui serait bien avant d’exécuter (et d’« optimiser ») une
commande donnée, ce serait d’essayer de la comprendre et, aussi,
d’en comprendre les limites.
Techniquement, la commande de François (qui doit être exécutée
depuis /proc) :
— liste tous les fichiers cmdline (for + ls) ;
— récupère le pid et crée une commande ps avec celui-ci (sed) ;
— exécute ces commandes.
Le but est de repérer les processus existant dans /proc mais
que ps ne verrait pas (erreur lors du ps pour le pid d’icelui).
Il y a plusieurs (petits) problèmes avec cette commande.
Déjà, effectivement, le seq n’est pas des plus rapides (c’est
même très très lent un seq). Le find est sans doute un peu
mieux. Un simple
cd /proc && ls -d [0-9]*
donne directement la liste des pids des processus en cours, sans
la lenteur d’un seq (ou d’un find).
D’ailleurs, on peut éviter le sed et le sh final :
cd /proc && ls -d [0-9]* | while read i; ps -p $i >/dev/null
|| echo $i ; done
Ensuite, puisqu’on ne cherche que les pids qui posent
problème, la sortie du ps ne nous intéresse pas vraiment. Elle
est même plutôt gênante. Ce qui serait bien plus intéressant,
c’est le cmdline du processus qui n’est pas vu par ps.
Enfin, et surtout, entre le moment où la liste des pids est
faite et le moment où le ps de chaque pid est exécuté, le
processus en question a des chances d’avoir terminé. Donc le ps
sort en erreur alors que le processus était bénin (p.ex.,
surtout avec le seq, si le pid en question correspond à une de
nos propres commandes intermédiaires, comme un des ls). Le
système ne s’arrête pas de créer des processus quand on se met à
les regarder…
Donc, pour ce genre de choses, il vaut mieux donner sa
confiance à un outil un peu mieux peaufiné (ce qui n’empêche pas
non plus d’essayer de comprendre ce que l’outil fait).
Sinon, pour revenir au sujet premier, il semble simplement que
chkrootkit n’aime pas que /sbin/init soit un lien symbolique.
C’est le cas dans Debian pour pouvoir utiliser systemd, sysv-
init ou autre facilement. Et c’est le « ou autre » et
« facilement » qui peut faire peur à un chkrootkit…
--
Sylvain Sauvage
Reply to: