[CALUG] DoD/OSI Layer 2, 3 and 4 in the real world -- WAS: open ports

Bryan J Smith b.j.smith at ieee.org
Thu Sep 15 16:22:19 EDT 2011


From: Rajiv Gunja <opn.src.rocks at gmail.com>

> So, irrespective of the application, everything communicating
> over the network has a port address.

This is _false_.  Not trying to be anal here, but understand my initial response was hoping to avoid the mega-oversimplification that I'm seeing too often.  I was afraid it would go here.


Understand that after watching some back'n forth, I decided to take the time to break down the 3-4 levels.  Again, I'm not trying to be anal, but I wanted to try to explain some of the detail here that can be everything when you start diving into this level.  This is especially true when you start diving into VPNs, Layer 2 tunneling, etc... which I saw the OP comment on.


Not every IP packet (level 3) is using a transport (level 4) protocol, let alone not all transports (level 4) have a port.  Some exchanges are completely at IP (level 3) and/or have applications (5 in DoD, 5+ in OSI) that do not use a transport (level 4) protocol.  Some completely bypass transport altogether.  UDP datagrams and TCP segements are two transports (level 4) that do.  However, it's important to note that not all do.

When debugging key details or getting into security, it's important to note this reality.  That's why I took the time to expand on those details.  If one does not follow a concept or terminology, I invite you to feel free to ask and/or Wikipedia the concept.  Again, if we're going to go to this level, we need to really watch what we say, and not over-simplify to the point that even under a "general" microscope (and not an "anal" one) the comments are not false.


> PS: If you want to look at the port (source and destination) of
> every application communicating over the network on your desktop
> (linux) use tcpdump or ethereal.

Actually, netstat is far less invasive.  It doesn't require root for many things, and it doesn't put the NIC in promiscuous mode like some libpcap functions (used by tcpdump, who's output is used by ethereal/wireshark) can.

In general, netstat shows many things, everything from the routing table (-r) to listeners (-l) to other options.  Netstat should be the tool most use by default, and only fire off something that uses libpcap when it calls for it.

With that said, I would agree that tools that leverage libpcap can really teach one a lot about various frame, IP packet and various transport structures.  But one doesn't typically want to fire that off just to list ports, where netstat is more than capable.

Let's teach people to use the appropriate tools for the appropriate job, especially if they work in a professional environment.  Again, I'm not trying to be anal, and I know we have a lot of security experts on this list.  But I felt we "crossed a line" on over-simplifying and telling people to use tools that are overkill (and possibly security issues) for the job.



More information about the CALUG mailing list