Processus cachés

Pause Café
#1

J’ai passé un de mes serveurs de Etch à Lenny. Du coup j’ai constaté plusieurs choses sur la recherche de processus caché:
Le serveur est un FitPC avec un processeur Geode à 500MHz, autrement dit pas une bête de course.

Depuis longtemps, j’utilise en tache de fond un programme perso conçue avec l’aide de la DUF

cf lists.debian.org/debian-user-fre … 01427.html

pour la genèse de ce programme.

Depuis unhide est apparu. Je connais 3 méthodes pour trouver des processus cachés:

Méthode 1 (initiale et qu’utilise cacheproc):
Pour i de 1 à 65535 test de l’existence /proc/$i et vérification pour savoir
si /proc/$i est visible.

Méthode 2:
Pour i allant de 1 à 65536, création d’un processus par fork et récupération du PID, celui ci est donc un numéro libre. Tous les $PID non obtenus sont des processus qui doivent exister. Test de cette existence.

Méthode 3:
Idem mais en utilisant les threads.

La deuxième et la troisième méthode construisent une table puis vérifient l’existence des processus. Tout processus terminant entre temps fait un faux positif.

Y-a-t-il des différences entre ces 3 méthodes dans les résultats attendus
(dans un cadre idéal)?

Sur ma machine (peu puissante), j’ai depuis lenny une centaine de faux positif par unhide. J’ai donc patché le source pour que 2 tables de processus suspects soit gérées, un processus fugitif figurera dans une table mais pas dans l’autre. Le source est disponible ici
boisson.homeip.net/unhide-linux26.c

Pour cacheproc, j’ai également un augmentation importante de faux positifs (je pense à cause de la généralisation de l’utilisation des threads). Une version modifiée de cacheproc améliore les choses en diminuant le nombre de faux positifs. Je suggère donc une MAJ pour ceux qui l’utilise.

#2

Voilà un sujet très technique, complexe (enfin pour moi) mais très intéressant.

Je rebondis sur ton poste pour poser quelques questions.

  1. Pourquoi ne pas avoir migré vers Squeeze directement, tu ne le trouves pas assez mûre pour une utilisation serveur?

  2. Je ne connaissais pas cacheproc ou unhide, qu’apporte t-il en plus de rkhunter ou chkrootkit?

  3. Est il possible d’utiliser aisément ton programme perso? S’agit il du paquet ‘surveillance’?

#3

[quote=“M3t4linux”]Voilà un sujet très technique, complexe (enfin pour moi) mais très intéressant.

Je rebondis sur ton poste pour poser quelques questions.

  1. Pourquoi ne pas avoir migré vers Squeeze directement, tu ne le trouves pas assez mûre pour une utilisation serveur?
    [/quote]Non[quote]
  2. Je ne connaissais pas cacheproc ou unhide, qu’apporte t-il en plus de rkhunter ou chkrootkit?
    [/quote]Lis le fil sur la genèse de cacheproc, tu sauras pourquoi j’ai développé ce programme.[quote]
  3. Est il possible d’utiliser aisément ton programme perso? S’agit il du paquet ‘surveillance’?[/quote]
    cacheproc et surveillance sont des programmes perso. surveillance surveille l’intégrité des fichiers, cacheproc recherche les processus cachés suivant la méthode (1)
#4

Est ce que ça ne viendrais pas d’un logiciel qui maintenant utilise beaucoup plus intensivement les processus pour faire son travail (comme le font chrome et firefox) ? Et donc qui utiliserais des processus avec des durées de vies relativement courte (c’est bien ça les faux positifs ?).

#5

Merci pour la piqûre de rappel.

J’avais collé cacheproc sur mon ancien serveur sous etch mais depuis le changement de machine plus rien. Je n’ai même pas ton dépôt dans mon source.list c’est dire…par contre j’en connais encore l’adresse de tête.

Choix cornélien entre unhide et chercheprocess ! Un peu des 2 et c’est parti.
On voit quand même une nette différence de temps d’exécution suivant la méthode utilisée par unhide.

#6

Non, c’est sur un serveur avec les mêmes processus, le passage de Etch à Lenny a multiplié les processus. Je pense qu’il y a plus d’utilisation de threads et autres d’où ces processus fugitifs. Bizarrement il n’y a pas vraiment beaucoup de processus, le pbm arrive quand la machine est chargée or j’utilise la même version d’exim (la 3.36)

Avec le unhide-linux26 classique

[quote]Found HIDDEN PID: 5942
Found HIDDEN PID: 5990
Found HIDDEN PID: 6369
Found HIDDEN PID: 6416
Found HIDDEN PID: 6419
Found HIDDEN PID: 6489
Found HIDDEN PID: 6493
Found HIDDEN PID: 6574
Found HIDDEN PID: 6575
Found HIDDEN PID: 6580
Found HIDDEN PID: 6583
Found HIDDEN PID: 6700
Found HIDDEN PID: 6701
Found HIDDEN PID: 6723
Found HIDDEN PID: 6806
Found HIDDEN PID: 6807
Found HIDDEN PID: 6812
Found HIDDEN PID: 6815
Found HIDDEN PID: 6903
Found HIDDEN PID: 6904
Found HIDDEN PID: 6929
Found HIDDEN PID: 7191
Found HIDDEN PID: 7192
Found HIDDEN PID: 7218
Found HIDDEN PID: 7414
Found HIDDEN PID: 7415
Found HIDDEN PID: 7433
Found HIDDEN PID: 7624
Found HIDDEN PID: 7625
Found HIDDEN PID: 7645
Found HIDDEN PID: 7808
Found HIDDEN PID: 7809
Found HIDDEN PID: 7830
Found HIDDEN PID: 8011
Found HIDDEN PID: 8012
Found HIDDEN PID: 8031
[…][/quote]
Avec celui que j’ai modifié

[code]cerbere:/home/francois# unhide-linux26fb brute
Unhide 20100201
http://www.security-projects.com/?Unhide

[*]Starting scanning using brute force against PIDS with fork()

[*]Starting scanning using brute force against PIDS with Threads

cerbere:/home/francois#
[/code]

Mais je pense qu’il y a un souci avec la méthode 2 et 3…

#7

Non, c’est sur un serveur avec les mêmes processus, le passage de Etch à Lenny a multiplié les processus. Je pense qu’il y a plus d’utilisation de threads et autres d’où ces processus fugitifs. Bizarrement il n’y a pas vraiment beaucoup de processus, le pbm arrive quand la machine est chargée or j’utilise la même version d’exim (la 3.36)[/quote]
C’est grosso modo ce que je voulais dire :slightly_smiling:

Tu n’a que exim sur ta machine ? Ton anti-spam n’a pas changé ? La gestion du boot n’aurais pas changée elle aussi (passage au parallèle “makefile style” comme il disent) ?

#8

Non, il n’y a pas que exim bien sur, clamav avait été backporté sur etch mais peut être que spamassassin a été modifié. Ce serait bizarre car vu la puissance du serveur j’ai limité à 2 le nombre de fils possibles et les processus de spamassassin durent facilement quelques dizaines de secondes. Mais ça peut être une explication.

Pour le boute, il fallait que je mette à jour quelques scripts de départ, du coup il continue sur un boute séquentiel (je m’en moque, je ne reboute la machine qu’une fois tous les ans ou deux ans au maximum, ça doit faire la 8ième et 9ième fois depuis son achat (en comptant l’installation pour 1), alors gagner 3 secondes sur le boute…

#9

@fran : j’ai téléchargé les sources pour cacheproc, je vois les deux fichiers à exécuter : chercheprocess & regarde.
L’extension est ml, ce sont donc des fichiers codés en (o)caml non??

Comment exécuter ce genre de fichiers? Quel paquet faut il installer concernant (o)caml?

Merci

#10

Un apt-get build-dep cacheproc devrait le faire. Ici c’est écrit en camllight, tu as le paquet sur mon site. chercheprocess est une version avec visualisation de progression, regarde est sans sortie, regarde le fichier /usr/share/doc/cacheproc/LISEZMOI ou README.
unhide a vraiment un souci:

[code]cerbere:/home/francois# unhide proc
Unhide 20100201
http://www.security-projects.com/?Unhide

[*]Searching for Hidden processes through /proc scanning

Found HIDDEN PID: 2962
Command: /usr/sbin/named

Found HIDDEN PID: 2963
Command: /usr/sbin/named

Found HIDDEN PID: 2964
Command: /usr/sbin/named

[…]
^C
cerbere:/home/francois# ls -ld /proc/23409
dr-xr-xr-x 7 francois francois 0 avr 28 08:00 /proc/23409
cerbere:/home/francois# ps xa | grep 23409
9770 pts/1 S+ 0:00 grep 23409
cerbere:/home/francois# exit
francois@cerbere:~$ ps xa -H | grep 23409
9856 pts/1 S+ 0:00 grep 23409
cerbere:/proc# find /proc -name 23409
/proc/23408/task/23409
cerbere:/proc#
[/code]

#11

Je sais bien que tu t’en fout mais j’imaginais que peut être la mise à jour avait fait le travail tout seul.

Tu as console-kit d’installé ? Il génère énormément de fils chez moi ?

Sinon je ne vois vraiment pas, il faudrait instrumenter ton système en wrappant le fork, mais vu que c’est un appel système et que ça passe pas par une bibliothèque, il faudrait passer par le noyau (je sais plus comment ça s’appelle la capture des appelles systèmes).

#12

Je sais bien que tu t’en fout mais j’imaginais que peut être la mise à jour avait fait le travail tout seul.[/quote]Non, c’est pour ça que j’ai fait cette précision, il m’a signalé qu’il laissait le démarrage séquentiel.[quote]
Tu as console-kit d’installé ? Il génère énormément de fils chez moi ?
[/quote]Ben non[quote]
Sinon je ne vois vraiment pas, il faudrait instrumenter ton système en wrappant le fork, mais vu que c’est un appel système et que ça passe pas par une bibliothèque, il faudrait passer par le noyau (je sais plus comment ça s’appelle la capture des appelles systèmes).[/quote]
Bizarre, je verrais quand j’aurais un peu + de temps.