1

So I did some packet capturing in my networking and everything else is actually fine except for this weird communication where source and destination is literally 127.0.0.1, source port is 631, and destination port is a continuously incrementing number by 1 for every exchange that happens.

I have disabled all services that are listening by default like cups, avahi-daemon, and etc. even as far as actually uninstalling cups because I don't really need it. So I really have no idea what's causing this traffic. I did a search about port 631 and all I can see are results related to printing/printers which really doesn't help my case.

Could someone please help me get to the bottom of this mystery? Here are the pcaps:

cmakeislife
  • 13
  • 2

2 Answers2

1

That is 10 TCP SYNs from 127.0.0.1 to 127.0.0.1 port 631. All immediately get a RST response. They happen to be spaced by 3.75 seconds, and the source port increases by 4 each time.

As you noticed, port 631 is registered for Internet Printing Protocol. Something printing related is possible.

As there is no data in the TCP stream and it is all localhost, not much identifying information. Trace the process that attempts the TCP connection. On recent Linux, bpf allows you to see all TCP connects with scripts like, well, tcpconnect. This will return the PID and COMM of connections. Something that isn't cups would be unusual.

John Mahowald
  • 32,050
  • 2
  • 19
  • 34
  • Thanks for this! Apparently there is only bpf for debian buster and not for debian stretch which sucks cause sadly my distro's latest release is still currently based on Debian Stretch and work is still being done for the new release that would be based on Debian Buster. Do you have any other alternatives? – cmakeislife Sep 03 '19 at 16:58
  • I have the problem solved and my bad, I never thought it would turn out to be the evil cups-browsed and I saw upon doing a quick netstat -lp after trying so hard to wrap my head around the results I got from Anderson's suggestions. In any case, I would still appreciate if you know other alternate methods that are similar to bpf when it comes to viewing connections and sharing it. – cmakeislife Sep 03 '19 at 17:40
0

As the traffic tries to flow across the port 631/tcp in the loopback interface, I believe that a local process is trying to contact a CUPS daemon and print something. Unfortunately, I am unable to get additional information about it from provided PCAP files, because none of captured TCP packets conveys payload. I can only see that a process is probably closing the connecting socket after getting a failure and retrying using new ones.

I was presented a similar issue some time ago. In order to collect information from a process trying to establish connections to a closed local port frequently, I used the following strategies:

  • Honeypot technique

    In a terminal tab, I launched a ncat process listening to connections on port 631/tcp:

    # ncat -l -p 631 -k -vv

    Then, in another terminal tab, I ran an on-the-fly Bash script collecting information about processes connected to the port:

    # while sleep 0.1; do ss -tapen state established 'dport = 631' > output.txt ; fgrep -wq 631 output.txt && cat output.txt; done

  • IPTABLES/NFTABLES logging

    I created an on-the-fly IPTABLES/NFTABLES rule into OUTPUT chain, logging connection information to SYSLOG:

    # iptables -I OUTPUT -p tcp --syn --dport 631 -j LOG --log-prefix 'WHOIS? ' --log-level warning --log-uid

    # nft insert rule ip filter OUTPUT tcp dport 631 tcp flags '&(fin|syn|rst|ack)' == syn counter log prefix '"WHOIS? "' level warn flags skuid
Anderson Medeiros Gomes
  • 2,477
  • 9
  • 20
  • I first tried to do the iptables logging but I did not end up finding out what the process was as it was in a loop of running and quitting end up filling the log with ever changing PIDs: -------------------Sep 4 01:06:09 Volatile kernel: [14117.483330] WHOIS? IN= OUT=lo SRC=127.0.0.1 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=56434 DF PROTO=TCP SPT=39670 DPT=631 WINDOW=43690 RES=0x00 SYN URGP=0 UID=0 GID=0 ;;;; ;;;; ncat method turned out with these results: – cmakeislife Sep 03 '19 at 17:19
  • Since the results are quite vast and a no good fit in comments I put it in a private bin: https://bin.disroot.org/?36bf624769293f87#704Uv0EqgmmV7RGWc4CsLudkgew4iigYw/aog/3sVd8= – cmakeislife Sep 03 '19 at 17:22
  • Thank you for this! It somehow help lead me to figuring things out. I was nuts to not really bother to think that cups probably ended up reviving itself somehow and it really was there listening! Gotten rid of it and loopback is now back to clean silence :D – cmakeislife Sep 03 '19 at 17:39
  • @cmakeisfile I am glad to know that. Thank you for the feedback. Yeah, the `iptables` logging strategy does not present the ID of the offending process. In my scenario, I firstly identified that connections had come from a running Wildfly (JBoss) instance and afterwards, a coworker of mine inspected the logs and found a configuration error on a deployed WAR. – Anderson Medeiros Gomes Sep 03 '19 at 20:02
  • @cmakeislife I see from `ncat` output that the TCP connection conveys HTTP payload that appears to come from a running CUPS daemon, according to the `User-Agent` header. It was a valuable hint. – Anderson Medeiros Gomes Sep 03 '19 at 20:13
  • Thank you really for all the help, this knowledge will surely be valuable to me in the near future! – cmakeislife Sep 05 '19 at 09:41