Je souhaite tcpdumper les connexion d'une application java qui utilise beaucoup de ports (non connus à l'avance).
Sur la machine il y a pas mal d'autres applis qui utilisent du réseau. Cela provoque pas mal de parasitage dans mes analyses.
Existe t'il un moyen simple de ne faire le tcpdump que pour les connexions réseaux de cette appli?
Merci
Filtrer sur l'ip accédée ? tcpdump src ***.***.***.*** and dst ***.***.***.***
Julien Salgado
Kevin Denis a écrit :
Bonjour,
Bonjour
Je souhaite tcpdumper les connexion d'une application java qui utilise beaucoup de ports (non connus à l'avance).
Sur la machine il y a pas mal d'autres applis qui utilisent du réseau. Cela provoque pas mal de parasitage dans mes analyses.
Existe t'il un moyen simple de ne faire le tcpdump que pour les connexions réseaux de cette appli?
En utilisant lsof, on peux sortir les file descriptors ouverts par appli (donc ceux utilisé par le réseau), exemple, pour avoir les flux tcp établis du processus de PID 42 : lsof -i 4TCP -s TCP:ESTABLISHED -a -p 42
Les informations peuvent aussi se retrouver dans /proc/$PID/fd (lien qui sont des sockets) et /proc/$PID/tcp par exemple.
Ensuite passer les arguments qui vont bien à tcpdump (port par exemple)
Une autre solution si on connait un critère différenciant et d'attraper les paquets en noyau via netfilter et une cible ULOG qui envoie en mode user par exemple à ulogd version pcap. Comme critère différenciant, on peut utiliser l'UID ou le GID via un match owner, ou avec les bons modules si on utilise les cgroups on peut utiliser un filtre sur les cgroup. (Penser en local, à mettre les règles en output et en input;) )
-- Julien
Kevin Denis a écrit :
Bonjour,
Bonjour
Je souhaite tcpdumper les connexion d'une application java qui
utilise beaucoup de ports (non connus à l'avance).
Sur la machine il y a pas mal d'autres applis qui utilisent
du réseau. Cela provoque pas mal de parasitage dans mes analyses.
Existe t'il un moyen simple de ne faire le tcpdump que
pour les connexions réseaux de cette appli?
En utilisant lsof, on peux sortir les file descriptors ouverts par appli
(donc ceux utilisé par le réseau), exemple, pour avoir les flux tcp
établis du processus de PID 42 :
lsof -i 4TCP -s TCP:ESTABLISHED -a -p 42
Les informations peuvent aussi se retrouver dans /proc/$PID/fd (lien qui
sont des sockets) et /proc/$PID/tcp par exemple.
Ensuite passer les arguments qui vont bien à tcpdump (port par exemple)
Une autre solution si on connait un critère différenciant et d'attraper
les paquets en noyau via netfilter et une cible ULOG qui envoie en mode
user par exemple à ulogd version pcap. Comme critère différenciant, on
peut utiliser l'UID ou le GID via un match owner, ou avec les bons
modules si on utilise les cgroups on peut utiliser un filtre sur les
cgroup. (Penser en local, à mettre les règles en output et en input;) )
Je souhaite tcpdumper les connexion d'une application java qui utilise beaucoup de ports (non connus à l'avance).
Sur la machine il y a pas mal d'autres applis qui utilisent du réseau. Cela provoque pas mal de parasitage dans mes analyses.
Existe t'il un moyen simple de ne faire le tcpdump que pour les connexions réseaux de cette appli?
En utilisant lsof, on peux sortir les file descriptors ouverts par appli (donc ceux utilisé par le réseau), exemple, pour avoir les flux tcp établis du processus de PID 42 : lsof -i 4TCP -s TCP:ESTABLISHED -a -p 42
Les informations peuvent aussi se retrouver dans /proc/$PID/fd (lien qui sont des sockets) et /proc/$PID/tcp par exemple.
Ensuite passer les arguments qui vont bien à tcpdump (port par exemple)
Une autre solution si on connait un critère différenciant et d'attraper les paquets en noyau via netfilter et une cible ULOG qui envoie en mode user par exemple à ulogd version pcap. Comme critère différenciant, on peut utiliser l'UID ou le GID via un match owner, ou avec les bons modules si on utilise les cgroups on peut utiliser un filtre sur les cgroup. (Penser en local, à mettre les règles en output et en input;) )
-- Julien
Pascal
En utilisant lsof, on peux sortir les file descriptors ouverts par appli (donc ceux utilisé par le réseau), exemple, pour avoir les flux tcp établis du processus de PID 42 : lsof -i 4TCP -s TCP:ESTABLISHED -a -p 42
Je ne connaissais pas... Merci pour le partage
En utilisant lsof, on peux sortir les file descriptors ouverts par appli
(donc ceux utilisé par le réseau), exemple, pour avoir les flux tcp
établis du processus de PID 42 :
lsof -i 4TCP -s TCP:ESTABLISHED -a -p 42
En utilisant lsof, on peux sortir les file descriptors ouverts par appli (donc ceux utilisé par le réseau), exemple, pour avoir les flux tcp établis du processus de PID 42 : lsof -i 4TCP -s TCP:ESTABLISHED -a -p 42
Je ne connaissais pas... Merci pour le partage
Kevin Denis
Le 29-08-2014, Julien Salgado a écrit :
Sur la machine il y a pas mal d'autres applis qui utilisent du réseau. Cela provoque pas mal de parasitage dans mes analyses.
Existe t'il un moyen simple de ne faire le tcpdump que pour les connexions réseaux de cette appli?
En utilisant lsof, on peux sortir les file descriptors ouverts par appli (donc ceux utilisé par le réseau), exemple, pour avoir les flux tcp établis du processus de PID 42 : lsof -i 4TCP -s TCP:ESTABLISHED -a -p 42
Les informations peuvent aussi se retrouver dans /proc/$PID/fd (lien qui sont des sockets) et /proc/$PID/tcp par exemple.
Ensuite passer les arguments qui vont bien à tcpdump (port par exemple)
Le problème, c'est que c'est une appli qui va prober un grand nombre de ports/IPs au démarrage dont un certain nombre ne répondent pas/plus. Et c'est bien cette liste de port/IP que je veux connaitre :)
Une autre solution si on connait un critère différenciant et d'attraper les paquets en noyau via netfilter et une cible ULOG qui envoie en mode user par exemple à ulogd version pcap.
Pourquoi pas
Comme critère différenciant, on peut utiliser l'UID ou le GID via un match owner,
effectivement, pas bête.
ou avec les bons modules si on utilise les cgroups on peut utiliser un filtre sur les cgroup. (Penser en local, à mettre les règles en output et en input;) )
Ca je connais moins par contre, un lien?
Merci -- Kevin
Le 29-08-2014, Julien Salgado <Julien.Salgado@nospam.invalid> a écrit :
Sur la machine il y a pas mal d'autres applis qui utilisent
du réseau. Cela provoque pas mal de parasitage dans mes analyses.
Existe t'il un moyen simple de ne faire le tcpdump que
pour les connexions réseaux de cette appli?
En utilisant lsof, on peux sortir les file descriptors ouverts par appli
(donc ceux utilisé par le réseau), exemple, pour avoir les flux tcp
établis du processus de PID 42 :
lsof -i 4TCP -s TCP:ESTABLISHED -a -p 42
Les informations peuvent aussi se retrouver dans /proc/$PID/fd (lien qui
sont des sockets) et /proc/$PID/tcp par exemple.
Ensuite passer les arguments qui vont bien à tcpdump (port par exemple)
Le problème, c'est que c'est une appli qui va prober un grand nombre
de ports/IPs au démarrage dont un certain nombre ne répondent pas/plus.
Et c'est bien cette liste de port/IP que je veux connaitre :)
Une autre solution si on connait un critère différenciant et d'attraper
les paquets en noyau via netfilter et une cible ULOG qui envoie en mode
user par exemple à ulogd version pcap.
Pourquoi pas
Comme critère différenciant, on
peut utiliser l'UID ou le GID via un match owner,
effectivement, pas bête.
ou avec les bons
modules si on utilise les cgroups on peut utiliser un filtre sur les
cgroup. (Penser en local, à mettre les règles en output et en input;) )
Sur la machine il y a pas mal d'autres applis qui utilisent du réseau. Cela provoque pas mal de parasitage dans mes analyses.
Existe t'il un moyen simple de ne faire le tcpdump que pour les connexions réseaux de cette appli?
En utilisant lsof, on peux sortir les file descriptors ouverts par appli (donc ceux utilisé par le réseau), exemple, pour avoir les flux tcp établis du processus de PID 42 : lsof -i 4TCP -s TCP:ESTABLISHED -a -p 42
Les informations peuvent aussi se retrouver dans /proc/$PID/fd (lien qui sont des sockets) et /proc/$PID/tcp par exemple.
Ensuite passer les arguments qui vont bien à tcpdump (port par exemple)
Le problème, c'est que c'est une appli qui va prober un grand nombre de ports/IPs au démarrage dont un certain nombre ne répondent pas/plus. Et c'est bien cette liste de port/IP que je veux connaitre :)
Une autre solution si on connait un critère différenciant et d'attraper les paquets en noyau via netfilter et une cible ULOG qui envoie en mode user par exemple à ulogd version pcap.
Pourquoi pas
Comme critère différenciant, on peut utiliser l'UID ou le GID via un match owner,
effectivement, pas bête.
ou avec les bons modules si on utilise les cgroups on peut utiliser un filtre sur les cgroup. (Penser en local, à mettre les règles en output et en input;) )
Ca je connais moins par contre, un lien?
Merci -- Kevin
Nicolas George
Kevin Denis , dans le message , a écrit :
Le problème, c'est que c'est une appli qui va prober un grand nombre de ports/IPs au démarrage dont un certain nombre ne répondent pas/plus. Et c'est bien cette liste de port/IP que je veux connaitre :)
Dans ce cas, j'utiliserais strace.
Kevin Denis , dans le message
<slrnm01eg6.2a7.kevin@slackwall.local.tux>, a écrit :
Le problème, c'est que c'est une appli qui va prober un grand nombre
de ports/IPs au démarrage dont un certain nombre ne répondent pas/plus.
Et c'est bien cette liste de port/IP que je veux connaitre :)
Le problème, c'est que c'est une appli qui va prober un grand nombre de ports/IPs au démarrage dont un certain nombre ne répondent pas/plus. Et c'est bien cette liste de port/IP que je veux connaitre :)
