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

[Bryan J Smith]

Ugh!  That should be 802.3 CSMA/CD Ethernet and 802.11 CSMA/CA WLAN, not CDMA (or that CMDA typo either).  Was talking other things earlier today in another discussion.  I was focused more on the CD and CA aspects, along with the medium.



----- Original Message -----

From: Bryan J Smith <b.j.smith at ieee.org>
Sent: Thursday, September 15, 2011 1:38 PM

There are actually four (4) levels involved here.  For the most part, you only need to be concerned with three (3), and can "fold" one level into another.

Level 2 (HW):  Media Access
Level 2 (SW):  Data Link
     Level 3:  Internet Protocol (IP)
     Level 4:  Datagram (UDP) / Segment (TCP)

The driver handles the Level 2 Hardware, Media Access.  And yes, "Media Access" is the "MA" in MAC address, such as for an IEEE 802 specification hardware.  One address per physical NIC (software bridging, virtualization and other things can change this though).  The data link is actually the additional software support, including additional IEEE 802 specification standards.  The Linux kernel provides most of this.  So you can consider HW+SW (driver+support) in the kernel to be Level 2 together.

The Level 2 talks in "frames," which all other nodes on the same collision domain (e.g., same Ethernet hub, or endpoints in a switch) can see.  There are several different types of frames, including radically different implementations.  E.g., 802.3 (CSMA/CD, aka Ethernet LAN) has a source and destination, while 802.11 (CSMA/CA, aka Wireless LAN) uses source, destination and bridge (e.g., optional "Access Point," if in infrastructure mode and not adhoc).  In the case of Ethernet, f the frame is a "broadcast," then all other nodes on the same Ethernet can see it (all ports in a switch stack).

The Linux kernel provides Level 3 network, which is almost always Internet Protocol (IP).  Each node then has one or more logically assigned addresses, IP address.

The Level 3 talks in "packets," which all other nodes on the same broadcast domain (e.g., same IP subnet) can see.  There are different IP protocol of packets, including ICMP (1), TCP (6) and UDP (17).  There are also many others for IPv4/v6, ARP/RARP, IKE (used in some VPNs, like IPSec based), etc...  Each protocol may have different types, and contain a payload of their own.

It's important to note that even if a device is on a different IP subnet (level 3) than another device, if the two are still on the same Ethernet (level 2), they can see each other's framing traffic.  Some early Windows firewalls often failed to physically segment level 2, and exposed level 3+ traffic as a result.

Now when people talk "ports," they are typical speaking about Level 4 protocols.  Both TCP (IP Protocol 6) and UDP (IP Protocol 17) utilize the concept of ports.  These "transport" protocols carry more meta-data information, plus the payload, which is not handled by the IP packet (level 3) which IP does for ICMP and others.  UDP transports are known as "datagrams" while TCP transports are known as "segments."  As the latter might suggest, TCP is better designed for dealing with large data that is spread into many "segments" of IP packets.

Most stateful packet inspection (SPI) focuses on inter-relating UDP/IP datagrams or TCP/IP segments (level 3/4) access between talking nodes, and limiting packet-only (level 3) access to only necessary packets (ARP, maybe 1-2 ICMP if any at all, etc...), let alone physically segmenting any frames (level 2) between networks.  And yes, you can do SPI on UDP/IP datagrams, or even IP packets like ARP, ICMP, etc... for to prevent access and spoofing.  It all depends on the SPI implementation and design.


________________________________
From: Joel J. <tcepsa at gmail.com>
To: "calug at unknownlamer.org" <calug at unknownlamer.org>
Sent: Thursday, September 15, 2011 1:01 PM
Subject: Re: [CALUG] open ports

I'll admit I am not a networking expert, but it sounds like you have the right idea.
The driver handles all communication with the network card. I don't know whether the driver actually knows about which ports are open or not. Regardless, yes, to get from the network to the telnet process the packets must be handled by the driver.
However, I am also pretty sure that the driver handles all incoming traffic on all ports, even ones that are closed, because it doesn't know what port a packet is trying to get to without checking it first. After it figures out the port, though, it may just discard packets that are trying to go to ports that are closed. (I could be wrong and the discard is handled by something else later on). Also, if you are running a firewall, all packets are filtered through it before being allowed to continue on.
For your final POV, it depends on the telnet server implementation (and how it is shut down). If it is terminated gracefully and closes the port, then yes, unless another process reopens that port it will remain unaccessible and should be impervious to attacks against that port.  However, if it crashes or for some other reason terminates without closing the port, then the port will remain open until the OS cleans it up or another process closes it.  That's not usually a big deal either, though,  because the process is dead.  Even if malicious packets are coming in, it's only really a problem if a vulnerable process is receiving them.  So mostly an unclosed socket is about as much of a problem as an unclosed file.  In fact, I believe that ports (or sockets, to be precise) are handled like files, so I don't think two processes can share a port unless one is a fork of the other. That is probably not relevant for telnet, but might be applicable for
other applications.
Hopefully that helps, and please correct me if I am mistaken about anything important.
Cheers,
Joel


On Sep 15, 2011 12:17 PM, "Walt Smith" <waltechmail at yahoo.com> wrote:
> 
> I enjoyed a great deal the openVPN session.
> 
> I was wondering what was meant by the term "open ports"?
> I don't recall if an "Ethernet" driver actually listens
> ( is the sole accessor to directly listen to.. )
> to all the ports.  Contrast to some "service" that does.
> For example, port 23 would be a telnet server listening to
> that port.  i.e does the telnet server get it's packets from
> the ethernet driver ?
> 
> re-stated,
> Is the telnet server the only software that directly accesses
> the "port" itself ?  Seems to me in the OSI that the ethernet driver
> is what resides and sucks out the packets. 
> 
> So, does "open port" mean the ethernet driver is actually listening ?
> ( is the only true connection/listener ).
> Other than the listing of "ports" in the "services" file,
> is that the config file that "permits"/"enables" the 
> port ?  Is there a specific block to specific ports ?
> 
> Another POV, does stopping the telnet server mean port 23
> is no longer "connected/used/accessible" ?  hence "safe"
> from intrusion attempts ( other than a hole in the OS ) ?
> 
> thx,
> Walt......