<font color="#3333ff"><font face="verdana,sans-serif"><div>Walt,</div><div><br></div><div>To understand ports, you have to divide the explanation.</div><div><br></div><div>Telnet port is an application port. </div><div><br>
</div><div>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)</div>
<div><br></div><div>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.</div><div><br></div><div>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. </div>
<div><br></div><div>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.</div>
<div><br></div><div>Hope this clears things up. Thanks</div><div><br></div><div>-GGR</div><div><br></div><div>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.</div>
<div><br></div></font></font><span style="color:rgb(51, 51, 255);font-family:verdana,sans-serif">--</span><br style="color:rgb(51, 51, 255);font-family:verdana,sans-serif"><span style="color:rgb(51, 51, 255);font-family:verdana,sans-serif">Rajiv G Gunja</span><br style="color:rgb(51, 51, 255);font-family:verdana,sans-serif">
<span style="color:rgb(51, 51, 255);font-family:verdana,sans-serif">Blog: <a href="http://ossrocks.blogspot.com" target="_blank">http://ossrocks.blogspot.com</a></span><br>
<br><br><div class="gmail_quote">On Thu, Sep 15, 2011 at 13:42, Bryan J Smith <span dir="ltr"><<a href="mailto:b.j.smith@ieee.org">b.j.smith@ieee.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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.<br>
<div class="im"><br>
<br>
<br>
----- Original Message -----<br>
<br>
From: Bryan J Smith <<a href="mailto:b.j.smith@ieee.org">b.j.smith@ieee.org</a>><br>
Sent: Thursday, September 15, 2011 1:38 PM<br>
<br>
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.<br>
<br>
Level 2 (HW): Media Access<br>
Level 2 (SW): Data Link<br>
Level 3: Internet Protocol (IP)<br>
Level 4: Datagram (UDP) / Segment (TCP)<br>
<br>
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.<br>
<br>
</div>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).<br>
<div><div></div><div class="h5"><br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
________________________________<br>
From: Joel J. <<a href="mailto:tcepsa@gmail.com">tcepsa@gmail.com</a>><br>
To: "<a href="mailto:calug@unknownlamer.org">calug@unknownlamer.org</a>" <<a href="mailto:calug@unknownlamer.org">calug@unknownlamer.org</a>><br>
Sent: Thursday, September 15, 2011 1:01 PM<br>
Subject: Re: [CALUG] open ports<br>
<br>
I'll admit I am not a networking expert, but it sounds like you have the right idea.<br>
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.<br>
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.<br>
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<br>
other applications.<br>
Hopefully that helps, and please correct me if I am mistaken about anything important.<br>
Cheers,<br>
Joel<br>
<br>
<br>
On Sep 15, 2011 12:17 PM, "Walt Smith" <<a href="mailto:waltechmail@yahoo.com">waltechmail@yahoo.com</a>> wrote:<br>
><br>
> I enjoyed a great deal the openVPN session.<br>
><br>
> I was wondering what was meant by the term "open ports"?<br>
> I don't recall if an "Ethernet" driver actually listens<br>
> ( is the sole accessor to directly listen to.. )<br>
> to all the ports. Contrast to some "service" that does.<br>
> For example, port 23 would be a telnet server listening to<br>
> that port. i.e does the telnet server get it's packets from<br>
> the ethernet driver ?<br>
><br>
> re-stated,<br>
> Is the telnet server the only software that directly accesses<br>
> the "port" itself ? Seems to me in the OSI that the ethernet driver<br>
> is what resides and sucks out the packets.<br>
><br>
> So, does "open port" mean the ethernet driver is actually listening ?<br>
> ( is the only true connection/listener ).<br>
> Other than the listing of "ports" in the "services" file,<br>
> is that the config file that "permits"/"enables" the<br>
> port ? Is there a specific block to specific ports ?<br>
><br>
> Another POV, does stopping the telnet server mean port 23<br>
> is no longer "connected/used/accessible" ? hence "safe"<br>
> from intrusion attempts ( other than a hole in the OS ) ?<br>
><br>
> thx,<br>
> Walt......<br>
<br>
<br>
_______________________________________________<br>
CALUG mailing list<br>
<a href="mailto:CALUG@unknownlamer.org">CALUG@unknownlamer.org</a><br>
<a href="http://lists.unknownlamer.org/listinfo/calug" target="_blank">http://lists.unknownlamer.org/listinfo/calug</a><br>
</div></div></blockquote></div><br>