As tu gkrellm d’installé?
Sinon essaye quelque chose du geznre
[code]# script /root/trace
lsof -i -P -r1 -n | grep IP_suspecte[/code]
et laisse tourner…
@fran.b: je découvre l’option -r de lsof, et du coup #lsof -i -P -r1 -n | grep IP_suspecte résume en une ligne mon script 
…
Mais, car il y a un mais, ça ne marche tjs pas avec une requête dns. Mais pour le reste c’est nickel.
Et oui, j’ai gkrellm d’installé.
[edit]En fait, ça a l’air de marcher, même pour les requêtes dns. Je viens de me rendre compte que j’avais laissé tourner,et ça a sorti des résultats:
# lsof -i -P -r1 -n | grep 213.188.172.1
firefox-b 17451 yanlolot 35u IPv4 479462 0t0 UDP 192.168.1.3:55843->213.188.172.1:53
firefox-b 17451 yanlolot 33r IPv4 498679 0t0 UDP 192.168.1.3:39333->213.188.172.1:53
firefox-b 17451 yanlolot 33r IPv4 511290 0t0 UDP 192.168.1.3:57792->213.188.172.1:53
firefox-b 17451 yanlolot 33r IPv4 511290 0t0 UDP 192.168.1.3:57792->213.188.172.1:53
firefox-b 17451 yanlolot 33r IPv4 511290 0t0 UDP 192.168.1.3:57792->213.188.172.1:53
firefox-b 17451 yanlolot 33r IPv4 511290 0t0 UDP 192.168.1.3:57792->213.188.172.1:53
firefox-b 17451 yanlolot 33r IPv4 511320 0t0 UDP 192.168.1.3:58780->213.188.172.1:53
firefox-b 17451 yanlolot 33r IPv4 511320 0t0 UDP 192.168.1.3:58780->213.188.172.1:53
(....)
Je retesterai demain, mais ça a l’air bon.
Merci encore.
[/edit]
Bon, bah c’est pas concluant; J’ai effectué un test, et sur 64 requêtes dns, # lsof -i -P -r1 -n | grep IP_serveur_dns_du_FAI n’en chope qu’une seule. 
(ce qui reste mieux que mon script qui, même avec les options -n -P ajoutées à lsof, n’en trouve aucune…)
Il semble que le port 19150 soit utilisé par gkrellm (cf différents sites). Vérifie.
a la base c’etait le module :
-m owner
selon la doc ici:
http://www.linux-france.org/prj/inetdoc/guides/iptables-tutorial/explicitmatches.html#ownermatchet donc ce n’est pas supporter.
la solution consiste donc a lire les log et a effectuer les requête système, ou encore d’écrire ce module dan siptable de manière appropriée , amha pour ceux qui font du C sa serai une bonne idée car la demande pour ce type de filtrage est assez forte.
quand a utiliser le Shell a ce moment la il faut faire le contraire.
autoriser les sortie ,loguer chaque nouvelle entrée dans les log et autoriser aux fure et a mesure, l’inconvénient c’est que l’on ce retrouve avec un processus qui mange des ressource cpu.
le mieux est donc de tout fermer et de connaître les requettes a l’avances.
de filtrer les sortie par utilisateur.
@fran.b: je comprends pourquoi tu me parles de gkrellm, c’est à cause du post
[quote=“yanlolot”]j’ajoute cette règle à netfilter:
#iptables -A OUTPUT -d IP_suspecte -j ULOG --ulog-prefix "traque"
Remarque: je récupère des lignes de ce type dans /var/log/ulog/syslogemu.log:
ce qui m’interrese, c’est le port de sortie (en vert). [/quote]
Oui, c’est bien gkrellm qui utilise ce port (j’ai gkrellmd d’installé sur mon serveur, et gkrellm sur le fixe qui me ressort les données du gkrellmd du serveur).
Mais ce n’est pas une ip suspecte, c’était juste un exemple (un mauvais exemple) du type de ligne que me sort iptables -A OUTPUT -d IP_suspecte -j ULOG --ulog-prefix “traque”, afin de mieux expliquer mon script awk.
Non, je n’ai pas d’IP suspecte à surveiller. Je cherche juste à faire un équivalent à --log-uid, mais pour le pid.
Ce qui m’amène à:
@panthere: le module owner ne répond pas à mon attente: on s’en sert lorsqu’on connaît déjà le pid, et on “match” donc les requêtes concernant ce pid.
Moi, tout ce que je connais, c’est une adresse IP, et je voudrais savoir quel processus “dialogue” avec cette IP (un -LOG --log-pid serait nickel, mais ça n’existe pas ). J’ai donc essayer de passer par le port utilisé (qui est caractéristique à un instant t donné du processus qui l’utilise), mais ça marche pô bien 
c’était le role du dit module mai pas opérationnel. il faudrait le coder dans iptables mai bon voila c’est quelque chose qui manque je te suggère de faire la demande a celui qui a coder le module de faire ce don tu a besoins 