With tcpdump I see many SYN packets ... and source IP is Localhost.

I wish to find which processes are trying to connect.

Note the connections don't reach ESTABLISHED state, they seems to be random port scans.

  • For what OS? Kernel tracing tools on e.g. Solaris (DTrace) or Linux (SystemTap, etc) may provide insight. – thrig May 21 '17 at 14:59
  • @thrig linux, and I am ignorant about systemtap – Massimo May 21 '17 at 20:22
  • it is a linux instance on AWS, and the culprit is " curl -s -f…" – Massimo May 21 '17 at 20:30
  • who is running this and why ? – Massimo May 21 '17 at 20:31
  • When you say "source IP is Localhost", do you mean Or the the IP address of the host on any of the system's network interface other than the loopback one (lo)? On what interface did you run that tcpdump on ? – Stéphane Chazelas May 22 '17 at 14:29

Assuming you have SystemTap installed

probe begin {
probe syscall.connect {
    # connect however may fail or flail around in a EINPROGRESS state;
    # this log only indicates that a connect was attempted
    if (uaddr_af == "AF_INET" || uaddr_af == "AF_INET6")
        printf("%s[%d]: %s\n", execname(), pid(), argstr);
probe syscall.connect.return {
    printf(" -> %s[%d]: %s\n", execname(), pid(), retstr);

saved as whomakeconnect.stp will show connect calls when run with stap as root

# stap-prep
... fix anything reported, it requires debug kernels ...
# stap whomakeconnect.stp

I've been in the same situation recently on Linux (the culprit was adb). My approach was to use the audit system to log the connect() system calls.

sudo auditctl -a exit,always  -F arch=b64  -S connect -k who-connects

To tell the audit system to log all connect() system calls (here the 64bit variant, you can add another one for the 32 bit variants if you're on a multi-arch system with both 32 and 64 bit applications)

Later run:

sudo ausearch -i -k who-connects

To see what made connections.

It would still be possible to make TCP connections without using the socket API. For instance by implementing a TCP stack in user space and using lower level APIs to send packets, but that would not be common (especially on the loopback interface).

  • I issue "sudo su -" then auditctl with arch=b64 and auditctl with arch=b32; ausearch prints two identical lines without arch and with auid user not root : is it right ? – Massimo May 21 '17 at 20:26
  • type=CONFIG_CHANGE msg=audit(05/21/2017 20:21:05.954:135) : auid=USER ses=12 op="add_rule" key=who-connects list=exit res=yes – Massimo May 21 '17 at 20:26
  • @Massimo, that's the log entries for the auditctl commands you did (which do change the audit configuration). If there's nothing else, that would mean there's not been any connect() system call. – Stéphane Chazelas May 21 '17 at 21:22

You can use netstat cammand. It shows the state of the packet. But you have to catch the output, because it only seems at sending time. It is not like a tcp listening socket. That's why you can ty to catch it by using watch command. I suppose that the connection is over ipv4.

watch -n 0.1 'netstat -4pn | grep -F "SYN_SENT"'

nestat flags

p flag: process id/name

n flag: numeric output (no dns resolution)

4 flag: show ipv4 sockets

watch command makes netstat command run repetitive with 0.1 second period.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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