I think the easiest method to achieve what you want here will be the use of iptables along with logging to either the LOG or ULOG targets.
This will leave you with the following type of log information:
Aug 13 14:42:07 srv1 IN=eth0 OUT= MAC=00:0c:29:8c:2b:6c:00:d0:02:eb:e8:0a:08:00 SRC=75.125.70.194 DST=XXX.XXX.XXX.XXX LEN=40 TOS=00 PREC=0×00 TTL=54 ID=9566 PROTO=TCP SPT=57144 DPT=445 SEQ=2770468863 ACK=0 WINDOW=512 SYN URGP=0
Aug 13 14:45:29 srv1 IN=eth0 OUT= MAC=00:0c:29:8c:2b:6c:00:d0:02:eb:e8:0a:08:00 SRC=75.125.70.194 DST=XXX.XXX.XXX.XXX LEN=40 TOS=00 PREC=0×00 TTL=55 ID=13702 PROTO=TCP SPT=58528 DPT=445 SEQ=1217789951 ACK=0 WINDOW=512 SYN URGP=0
You'll then be able to use standard tools such as awk or grep to pull data from this when you want to see what's going on on this system.
2 rules such as these should log any "NEW" connections that are either incoming or outgoing. These will prefix the rules so that they're esaier to spot:
iptables -I INPUT -m state --state NEW -j LOG --log-prefix "New Connection: "
iptables -I OUTPUT -m state --state NEW -j LOG --log-prefix "New Connection: "
Resulting in log entries like this:
[ 2134.566659] New Connection: IN= OUT=wlan0 SRC=192.168.178.229 DST=192.168.178.21 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=65094 DF PROTO=UDP SPT=55717 DPT=53 LEN=40
References
Local processes connecting to such port will create a unix pipe instead of an IP socket.
Whether a process uses a pipe or a socket does not depend on the interface per se. It depends on which system services it calls.
To create a named pipe, the program calls mkfifo(2). To get a descriptor on that file, it calls open(2). ls -l shows a "p" in the status bits of a fifo. Anonymous pipes, created with pipe(2), have no name and are invisible to processes without a common ancestor.
To create a TCP socket, it calls socket(2) and then bind(2) to assign it a name for other processes to connect to. If the argument to bind is an external address, it will be visible to the network, else not.
You may be thinking of the loopback address 127.0.0.1. If the program binds to that, it won't be visible or accessible from the network. Only processes running on the host machine can bind or connect to the loopback address.
It is also possible to create a TCP connection over something that looks a bit like a file, known as a UNIX-domain socket. In that case the argument to bind (and connect) has a filename. Because the name appears in the filesystem, it looks a little like a pipe, but ls -l shows an "s" among the status bits.
If you're interested in how all these strange distinctions came to be, NetBSD distributes two papers that date from their invention and are still relevant today. Look for An Advanced 4.4BSD Interprocess Communication Tutorial and An Introductory 4.4BSD Interprocess Communication Tutorial on the web.
Best Answer
There are two tools you could use to monitor TCP
connectevents on Linux:The difference between the two is that the former provides options for customizing output (e.g., filtering by PID or port number) while the latter is a more simplistic tool and doesn't provide fancy options.
For your use case, the most simple option would be to install bcc and run:
If you install these tools using your distro's package manager, keep in mind that some distros don't place
tcpconnectin/usr/binand place them under somewhere else like/usr/shareinstead. So be sure to check where your distro places these files if you can't find them.