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

Thu Sep 15 15:49:13 EDT 2011

Walt,

To understand ports, you have to divide the explanation.

Telnet port is an application port.

Why do we need a port? The network driver as you put it, does only network
traffic. It does not care if the packet (information) is going to telnet or
KDE or ssh application. All it cares for is the destination address and data
packet sequence (and couple of other things)

So, irrespective of the application, everything communicating over the
network has a port address. This is one way to guarantee delivery of the
packet/information.

When someone says port 23,5001 are open, it means that there is an
application (server) running on the machine looking (listening) for packets
to serve.

Network driver does not care if the packet is from a telnet application or
KDE application or VNC or java program, its function is to deliver the said
data to the end client and guarantee (tcp)that the packet reaches the
destination without corruption.

Hope this clears things up. Thanks

-GGR

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.

--
Rajiv G Gunja
Blog: http://ossrocks.blogspot.com

On Thu, Sep 15, 2011 at 13:42, Bryan J Smith <b.j.smith at ieee.org> wrote:

> 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......
>
>
> _______________________________________________
> CALUG mailing list
> CALUG at unknownlamer.org
> http://lists.unknownlamer.org/listinfo/calug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.unknownlamer.org/pipermail/calug/attachments/20110915/a0b076c5/attachment.htm 