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

[Jim Bauer]

On 09/15/2011 05:54 PM, Rajiv Gunja wrote:
> Ok Mr Bryan the IEEE guru, please read what I wrote.
>
> ----
> Network driver does not care if the packet is from a telnet application or
> KDE application or VNC or java program,

correct

>    its function is to deliver the said
> data to the end client and guarantee (tcp)that the packet reaches the
> destination without corruption.
> ----

Not really.  Network drivers send and receive frames by controlling the 
network (e.g. Ethernet) interface hardware.  Incoming frames are handed 
off to the networking stack (typically IP).  When, for example, IP has 
something to send it'll pass it off to the driver which will handle the 
transmission.  The network drivers definitely do not communicate 
directly with applications.  There is a ton of stuff between them.  And 
the drivers certainly do not guarantee delivery.  We have TCP for that.




On 09/15/2011 12:15 PM, Walt Smith wrote:
 >
 > I was wondering what was meant by the term "open ports"?

An open port is usually referring to a TCP or UDP port that some program 
is listening on for datagrams(udp) or connections(tcp).

To see what TCP port something is listening on, run netstat -lnt
and you see something like this (I shortened the lines a bit):

Proto  RcvQ  SndQ   Local addr   Foreign Addr     State
tcp       0     0   0.0.0.0:22   0.0.0.0:*        LISTEN

Here there is one TCP socket is a listen state on port 22.
(replace the 't' option with 'u' to see UDP sockets.)

 > 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 ?

The telnet server would gets its data (not packets) from TCP (via the 
socket API).  TCP would get packets from IP.  The packets TCP gets are 
reassembled o provide a continuous stream of data to the application 
(telnet server in this case).  IP would get frames from the network driver.

 > So, does "open port" mean the ethernet driver is actually listening ?
 > ( is the only true connection/listener ).

It is TCP (or UDP) that is listening.  The driver gets all frames 
addressed to the system (or every frame if the interface is in 
promiscuomous mode).  The networking stack decides what to do with the 
packets it gets.

 > 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 ?

No.  The service file just maps names to numbers.  No access control.

 > 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 ) ?

Yes assuming nothing else starts listening on that port.  Run the 
netstat command show previously to see what is really listening.  Or if 
you have root (or sudo) access, add the 'p' option (netstat -lntp) and 
you can see the PID and program that is doing the listening.



On 09/15/2011 01:01 PM, Joel J. wrote:
 >
 > 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.

It doesn't matter how the program was terminated.  A listening socket 
goes away right away.  An opened TCP socket however can linger as a few 
TCP packets need to be exchanged to close the connection.  This does 
assume that some other process doesn't have that file descriptor open 
(e.g. from a fork).