Port logging on a Linux/Mac home network

March 19, 2009 11:39 AM

Looking for a program for Linux (or Mac) that will record what ports I'm using during a given period of time.

About to switch from a basic home router to a Debian router/DHCP box using IPRoute as the firewall - problem is, I'm not 100% sure what ports I'm using with different programs. I know that I could look for a standard port listing, and just highlight which ones are used by programs I have, but I'm sure I'd either forget one, or find that it's not using a standard port. The opposite thinking, which is to block everything, and start opening them as needed, will cause me to have to SSH into the box every single time something doesn't work for the next week or so; not a pleasant thought either.

Is there anything out there that will simply watch and record the port usage of my home network for a given period of time? Since this is not mission critical, and more about me learning Linux server administration than a need for home network security, I was planning to leave the process up for a week (or so), thinking that most everything that I might use would get used at some point in that period of time. Then, I could simply print out the port list, make sure that those ports are properly forwarded and/or open in my configuration, and have no issues when I made the switch-over.

I'm happy to put something (a linux box) between my current router and the net in order to get this info, but I'd rather just be able to sniff things as they're set up now (if only out of laziness). I'm also willing to install something on each computer, as long as it doesn't take up too many resources.

I gotta think something's out there, but my Google-fu is failing me today. Thanks in advance!

posted by plaidrabbit to computers & internet (15 comments total)

man netstat

You could use perl or any number of scripting languages with cron to periodically parse the results of netstat for port usage associated with "foreign address" data.
posted by Blazecock Pileon at 11:47 AM on March 19

I'm not clear on why you wouldn't just look at the current router's port forwarding list and copy it to the new router.
posted by odinsdream at 11:51 AM on March 19

On the Linux front...
tcpdump will do this from the command line.
Ethereal is similar, but runs from a GTK (I think) GUI.

On the Mac, you can use these tools as well, but I'd recommend Little Snitch. It's a bit pricey ($30), but the demo will run for a few hours before shutting down.
posted by mkultra at 11:53 AM on March 19

ntop
posted by devnull at 11:55 AM on March 19

Just to be clear: You don't need to set up any kind of port forwarding for normal things like web browsing and e-mail. Only services you set up inside that need to be accessed from outside need port forwarding. Things like running your own web or FTP server. If you are already running these, then you already had to set up specific port forwarding rules on your current router. Simply copy those rules into your new setup.
posted by odinsdream at 12:26 PM on March 19

I'm not clear on why you wouldn't just look at the current router's port forwarding list and copy it to the new router.

Currently, I forward one port, so that's not any help. While I'm sure that I'd remember the basics (port 80, etc.), I'm looking to catch anything going out that I wouldn't normally think of (like, say, a game I only play once a week, or something like a Last.fm reporter, etc.).

Thanks for the recommendations so far.
posted by plaidrabbit at 1:26 PM on March 19

I think your confused.

The ONLY thing you need to forward ports for is if people are connecting to the ROUTER's ip for things. Do you run a webserver? openssh? anything like that?

If not... then you don't need any port forwarding.

Edit: Just saw odinsdream wrote the same thing
posted by phrakture at 1:52 PM on March 19

Ok, great. The one port that you have forwarded on your router, I would assume, is set to go to a particular internal IP address. This is so that connections from outside your network can reach that internal port on that internal machine. Just add that one rule to your new router.
posted by odinsdream at 2:40 PM on March 19

I'd first try
lsof -n | grep TCP
posted by Pronoiac at 2:53 PM on March 19

Home gateway firewalls that block outbound traffic are misconfigured, in my opinion. Least annoyance and perfectly adequate security is obtained by using a stateful firewall that allows all outbound connections but blocks all inbound traffic except that associated with outbound connections or explictly forwarded to an internal server.

If you're unhappy with that, what threat are you expecting your firewall to protect you from?
posted by flabdablet's sock puppet at 3:51 PM on March 19

Home gateway firewalls that block outbound traffic are misconfigured, in my opinion. Least annoyance and perfectly adequate security is obtained by using a stateful firewall that allows all outbound connections but blocks all inbound traffic except that associated with outbound connections or explictly forwarded to an internal server.

Okay - this might be where I'm dropping the ball on my own understanding, and its becoming clear to me that I might have been inelegant in phrasing my first question. First, just so we're all clear, I know what the router does, and I understand port forwarding, etc, for things on my network (VPN Server, Apache Server, etc.). I've always just made sure that whatever router I'm using had its normal firewall on, and that's seemed to be sufficient.

Perhaps I've misunderstood; while I understand that firewalls shouldn't prevent outgoing traffic, doesn't the reply traffic have to have an open port to get back? Example - if port 80 is closed to inbound traffic, even though page requests might be sent from my browser through port 80, the reply information won't make it back through? Or, is it so that if you send a request, the reply will make it back through the firewall? Do only ports that are associated with receiving inbound requests (SSH, an Apache server, VPN) need to be open?

Thanks for dealing with me on this...I'm not a computer newbie (or really a networking newbie), promise, I've just never had to think about exactly how a firewall works in this manner. Your explanations and further help are greatly appreciated.
posted by plaidrabbit at 8:20 PM on March 19

That's correct. With regard to NAT networks (such as what you have) you only need to specify port forwarding on inbound connections to get them to the right spot. Outbound connections are generally allowed, and so is the reply to that connection - which is what flabdablet's sock puppet is referring to with mention of a "stateful" firewall. The "state" of a connection is monitored by the firewall and used to determine whether other traffic should be allowed or denied. I.e., "Is this traffic part of an already-established connection? Yes/No?"

You can read more about the principles of the traffic in the Wikipedia article on TCP.

That being said, the logic that outbound connections (and data related to them coming back in) be allowed to flow isn't necessarily part of how a firewall works. All consumer firewalls will function this way because it would be a nightmare otherwise. If you're building your own firewall on a Linux box from scratch you will need specific rules to allow this. For example, here is one set of iptables rules I'm using:

Chain INPUT (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere
DROP       tcp  --  anywhere             anywhere            tcp flags:!FIN,SYN,RST,ACK/SYN state NEW
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:228 state NEW
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:http state NEW
ACCEPT     tcp  --  anywhere             anywhere            tcp dpts:afs3-fileserver:7500 state NEW

Chain FORWARD (policy DROP)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere

The third rule in the INPUT section and the only rule in the OUTPUT section are required to implement this "normal" behaviour of allowing outbound connections and the data sent "back" in response to them.

The last three rules in the INPUT section are to specifically allow incoming traffic on ports 228, 80, and 7000-7500.

While a consumer router combines the firewall and router into a single device, the above is just the firewall part of the equation. You would need additional logic to route the above ports to a particular computer in your network. I'm not familiar with IPRoute, but perhaps it simplifies the above into some kind of GUI interface. If not, you may want to explore some other open-source router/firewall distributions like Smoothwall.
posted by odinsdream at 8:42 PM on March 19

doesn't the reply traffic have to have an open port to get back?

Yes, but not necessarily the port you think it's going to need.

Example - if port 80 is closed to inbound traffic, even though page requests might be sent from my browser through port 80, the reply information won't make it back through?

Paste the following paragraph into your text editor so you can refer back to the numbers as we go:

Your NAT router's LAN interface's MAC address is 00:04:ED:1D:A7:79
Your NAT router's LAN IP address is 192.168.1.254
Your NAT router's WAN interface's MAC address is irrelevant
Your NAT router's WAN IP address is 72.32.231.8
Your PC's Ethernet interface's MAC address is 00:13:d4:71:23:08
Your PC's Ethernet interface's IP address, obtained via DHCP from your router, is 192.168.1.1
Your PC's Ethernet interface's subnet mask, also obtained via DHCP, is 255.255.255.0
Your PC's default router (from DHCP again) is your NAT router's LAN interface's IP address 192.168.1.254
Your PC wants to get a web page from 174.132.172.58 port 80

The first thing your PC needs to do is send a TCP connection request packet to 174.132.172.58. That packet will include a source port number, which will not in general be 80 - it will be whatever happens to be convenient at that instant. Let's say the PC picks port 28633. So we're trying to establish a TCP connection between 192.168.1.1:28633 and 174.132.172.58:80.

As a side note: there is nothing to stop your PC also using port 28633 to talk to some other service, as long as the host's IP address isn't 174.132.172.58 or the service's TCP port number isn't 80. In other words, simply using a port number doesn't "use it up". All four items taken together - source IP address, source port number, destination IP address, destination port number - uniquely identify a TCP connection; change any of those, and it's a different connection. This is also why an Internet-connected web server doesn't need to provide service on multiple ports to be useful; port 80 doesn't get "used up" simply because some client somewhere connects to it.

Your PC knows that 174.132.172.58 is not directly connected to any of its own network interfaces, because after the subnet mask 255.255.255.0 is logically ANDed with 174.132.172.58, the result isn't the same as that of ANDing it with 192.168.1.1.

Therefore, your PC knows that to get the packet to its destination, it must be sent via the default router (aka the local gateway). That gateway is directly connected to your PC's Ethernet interface, because (192.168.1.254 & 255.255.255.0) == (192.168.1.1 & 255.255.255.0). The PC does an ARP lookup for 192.168.1.254 via that interface if it hasn't already done so, and finds that it needs to send the packet destined for 174.132.172.58 to 00:04:ED:1D:A7:79.

So the connection request IP packet (source IP 192.168.1.1, source port 28633, destination IP 174.132.172.58, destination port 80, plus assorted bits and bobs that mark it as a TCP connection request) gets wrapped in an Ethernet frame with source MAC 00:13:d4:71:23:08 and destination MAC 00:04:ED:1D:A7:79, dumped onto the Ethernet cable, and received by your NAT router. Note that for packets like this that are supposed to pass through the router on their way to somewhere else, the router's IP address is only used beforehand to look up its MAC address, and doesn't appear anywhere inside the packet that's to be routed.

That router knows that 192.168.1.1, the source IP address, is non-routable, meaning that a packet using it for an IP source address will never get a reply if sent out into the cloud. So it replaces the source IP address in the outgoing packet with 72.32.231.8 (its own public IP address) and replaces the source port number as well - say, with 10623. At the same time, it records all five pieces of this connection request (192.168.1.1, 28633, 174.132.172.58, 80, 10623) in its internal NAT table.

Assuming that the pipes aren't too clogged with trucks, the server at 174.132.172.58:80 will soon receive a connection request from 72.32.231.8:10623 and reply with a TCP connection acknowledgment. Your router gets a packet from 174.132.172.58:80 destined for 72.32.231.8:10623, consults its NAT table, replaces the destination address and port with 192.168.1.1:28633 and sends it on to your PC.

As far as your PC knows, it's now connected to 174.132.172.58:80. As far as that server knows, it's now connected to 72.32.231.8:10623. The server-in-the-cloud never sees the PC's actual IP address (192.168.1.1) because the NAT router munges all the packets passing through it as required to maintain the connection.

Or, is it so that if you send a request, the reply will make it back through the firewall? Do only ports that are associated with receiving inbound requests (SSH, an Apache server, VPN) need to be open?

That's it in a nutshell. "Opening" ports on a NAT router is essentially just pre-loading its NAT table, so that external traffic to selected ports on 72.32.231.8 gets rewritten and sent through to suitable 192.168.1.x:port combinations on the LAN side without a prior outgoing connection being required to create the NAT table entry that makes the translation possible.

When dealing with protocols like FTP that require two separate TCP connections, any decent NAT router will also create extra NAT table entries for connections associated with outbound ones. So when your PC makes an outbound FTP control connection to a cloud server on port 21, your NAT router will create two NAT table entries - one to allow direct replies to the FTP control connection's source port, and another to allow the far end to establish its own inbound connection to port 20 on the same interface the outgoing connection came from. This process is often a bit fragile, which is why it's usually better to use passive mode for FTP connections originating behind NATs.

posted by flabdablet's sock puppet at 12:44 AM on March 21

You may find these articles helpful once you get down to the nuts and bolts, too.
posted by flabdablet's sock puppet at 1:02 AM on March 21

Thanks everyone. That totally clears up exactly what I needed to know, and answers the question to boot. Devnull's answer about ntop is what I was looking for with regards to packages I could install, but flab and odin gave me the real information I was looking for.

Love love love having this resource. :)
posted by plaidrabbit at 12:41 PM on March 25