Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question

marked as duplicate by Ben Pilbrow, Iain, Mark Henderson, splattne Dec 17 '10 at 16:40

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

2 Answers 2

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...

share|improve this answer
    
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 Dec 21 '10 at 8:41
    
BTW I used ULOG for that. stearns.org/doc/iptables-ulog.v0.1.html –  Erik Johansson Dec 21 '10 at 8:48
    
ulog seems to be obsolete –  halp Dec 21 '10 at 10:25
    
Not really, works great here. Using it on 4 firewalls with mysql backend. :-) –  Erik Johansson Dec 21 '10 at 11:04

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

share|improve this answer
    
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. –  Erik Johansson Dec 21 '10 at 9:52

Not the answer you're looking for? Browse other questions tagged or ask your own question.