<p>I'll admit I am not a networking expert, but it sounds like you have the right idea.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>Hopefully that helps, and please correct me if I am mistaken about anything important.</p>
<p>Cheers,<br>
Joel</p>
<div class="gmail_quote">On Sep 15, 2011 12:17 PM, "Walt Smith" <<a href="mailto:waltechmail@yahoo.com">waltechmail@yahoo.com</a>> wrote:<br type="attribution">> <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>> Celebrating over 13,000 emails in my Yahoo Inbox !<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">http://lists.unknownlamer.org/listinfo/calug</a><br></div>