What program sent which packet to the network

7,999

Solution 1

information about the process sending a packet (even when it origininated from the local machine) is not available to tcpdump because it's not provided by the kernel's packet capture interface... seach for "DLT_LINUX_SLL" on http://www.tcpdump.org/pcap3_man.html

changing this is surely a rather complex kernel hacking task...

the closest to a solution seems to be iptable's "owner" match module, which supports matching packets by user-id (also process-id in some linux versions, iirc that feature was removed later), and the --log-uid (sadly no --log-pid) option of the LOG target.

so, when you add an iptables rule like: iptables -I OUTPUT -p tcp --syn -j LOG --log-prefix "new tcp connection: " --log-uid

you get a log (in your kernel log, aka dmesg) of all newly established connections with their source port and user-id, so you could get a map of connections to users without having to poll netstat...

Solution 2

Look at this answer to an identical question. It suggests to use the auditd framework.

Share:
7,999

Related videos on Youtube

Erik Johansson
Author by

Erik Johansson

I'm a philosophy student and I worked my way through university by doing CS work, loves big text corpuses, GIS and arcane Unix things..

Updated on September 17, 2022

Comments

  • Erik Johansson
    Erik Johansson over 1 year

    I would like to have a tcpdump like program that shows which program sent a specific packet, instead of just getting the port number. This is a generic problem I've had on and off sometimes when you have and old tcpdump file lying around you have no way to find what program was sending that data..

    The solution in how i can identify which process is making UDP traffic on linux ? is an indication that I can solve this with auditd, dTrace, OProfile or SystemTap, but doesn't show how to do it. I.e. it doesn't show the source port of the program calling bind()..

    The problem I had was strange UDP packets, and since those ports are so short lived it took me a while to solve this issue. I solved this by running an ugly hack similar to:

    while true; date +%s.%N;netstat -panut;done
    

    So either a method better than this hack, a replacement for tcpdump, or some way to get this info from the kernel so I can patch tcpdump.

    Solving this with auditd

    sudo auditctl -a exit,always -F arch=b64  -S bind -k BIND
    

    This fills /var/log/audit/audit.log with lines like:

    type=SYSCALL msg=audit(1292929028.845:3377): arch=c000003e syscall=49 success=yes exit=0 a0=3 a1=808710 a2=10 a3=7fffab28ea10 items=0 ppid=1564 pid=24442 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=4294967295 comm="nc" exe="/bin/nc.openbsd" key="BIND"
    type=SOCKADDR msg=audit(1292929028.845:3377): saddr=0200FFFF000000000000000000000000
    

    Then parse the saddr=0200xxxx00 where xxxx is the port number, 0001 is lowest and FFFF is highest.

    EDIT: This was asked on superuser "tracking what programs sends to net", no good solution though.

  • Erik Johansson
    Erik Johansson over 13 years
    Thank you, I knew iptables had this at one time (I've actually used it), just couldn't find it. Thanks for pointing it out...
  • Erik Johansson
    Erik Johansson over 13 years
    This is not what I need, I need auditd to print out the port and PID of programs sending to the net. This only show programs using socket to bind a socket, I would have to 1. trace bind() instead 2. interpret the struct sockaddr_in in auditd.
  • halp
    halp over 13 years
    ulog seems to be obsolete
  • Erik Johansson
    Erik Johansson over 13 years
    Not really, works great here. Using it on 4 firewalls with mysql backend. :-)