An open port will respond to all clients attempting to connect. A closed port will respond with a 'port closed' response. A stealth port will not respond at all.
I have an FTP running on my PC. The port is set to stealth but people can access it throught my router. It all works a treat and I have no complaints.
My question is how does an FTP server running on my local lan manages to accept a connection to a client if the port is in stealth mode?
As I see it there is a three way handshake to initiate a connection. Client sends a SYN packet. Server, if open, sends a SYN/ACK back. Client responds with an ACK. Normal communication then begins. If the port is closed the server ould respnd with a SYN/RST to say port is closed. In stealth the server does not respond at all to the SYN request so I can't see how any comminication is initiated.
It doesn't. Period. A port must be "open" to accept connections. In other words, it must respond to a SYN with a SYN/ACK as part of a normal three-way handshake as described in the RFC that specifies TCP.
A "closed" port responds to a SYN with an RST. In other words, the RST reply signals that the port is not accepting connections.
A "stealth" port is, as far as I can tell, an invented term made up by Steve Gibson. It refers to a port that doesn't reply at all to a connection attempt. You won't find the word stealth mentioned in any of the RFCs except in the context of stealth DNS servers. It's best to avoid these Gibsonisms and stick to standard terminology.
OK thanks for the reply Jerry. I will attempt to refrain from using inveted terms from Steve Gibson. ;)
Would you say there were 3 states that a port can be in. If the client sends a SYN packet one of 3 things can happen:
1) Server responds with a SYN/ACK 'Port is open'
2) Server respondes with a SYN/RST 'Port is closed'
3) Server does not respond. Port appears not to exist.
Is this correct? Or is the 3rd option not possible?
Yes, these are more or less the three responses you'll get from a server. In (2), the server will respond with just RST.
In the early dates of the Internet, most servers would send an RST in reply to a SYN sent to a closed port. This would notify the client application immediately that the other end wasn't listening and the client would exit without waiting for the timeout period. The most common reason I've heard for not sending an RST is to avoid replying to spoofed packets. For example, an attacker could generate a stream of SYN packets directed to a server port known to be closed. The server would then send RST responses back to the source address in the packet, which would be the address of an innocent victim rather than the attacker. The drawback to this, of course, is that legitimate clients will keep trying to connect until they timeout because they don't get a RST back from a server with a closed port.
A port is a maintainance number. It is not something you can eat. ;-)
People call a port "open", if there is a process on the machine, which opens a socket to this port (usually by using bind() and listen() or by using connect()).
In any other case, people call a port "closed".
And there is not only TCP in the world. SYN and ACK are flags of the TCP header. There are other protocols, too. Those maintainance numbers are 16bit, that means, they're going from 0 to 65535 (or from 1 to 65535, because 0 has extra meanings).
It is not possible, that a port "does not exist". How should this be? Is there a natural number missing then, and anybody who counts, is omitting it? ;-)
If you want to know more, you could read Richard Stevens "UNIX Network Programming".
That really depends very much on _which_ port is in so called "stealth" mode. Remember, "stealth" means that if a packet arrives to that port and no process is listening there, the kernel does not reply at all (rather than with RST). Normally, a firewall will do this even if a process is listening on that port (the packet is never forwarded to the process), but not always - some "helpful" firewalls may decide to behave otherwise.
FTP uses two ports: one for the control connection, and one for data. The data connection is usually an ad-hoc port number (or it may be fixed), and the direction of the opening (which side sends the first SYN) varies by protocol. Try searching for active/passive FTP to see exactly what happens.
A typical scenario: a client connects to your FTP server control port, which is happily listening on port 21. Your FTP server replies "I'll send data to your port 61234", the client starts listening on that port, and the server initiates a connection there. No problem anywhere.
I suggest you try sniffing the network traffic and see exactly what is being sent.
As I have my FTP server in my LAN waiting on port 21 for a connection, should the port not show up as open? This is why I'm confused as to what state the port is in. As far as I can see it's either open (returning a ACK) or not responding (Not returning anything) if it's the former then when I probe the port it should appear open. However it does not show up as open or closed so I have to assume it's in the third state. If it's in the third state how does it manage to initiate a connection?
Unfortunately I have no way, that I'm aware of to sniff network traffic.
I had no idea that FTP used 2 ports. I though all traffic flowed via port 21. How does the FTP or router agree on a second port for xfer? How does it know this port it picks will not clash with anything else? Say it picks port 27015 becuase it's clear at the time of negotiation, then I fire up Counter Strike which uses port 27015. What happens then? Also if the FTP server says use port x then how is this port forwarded to the FTP server on the LAN, is ther some Port Triggering scenario at work here?
The kernel is running the network stack, not some application.
If any application wants to listen to the port, it tells the kernel to forward the packets to the application.
Firewalls _are_ applications. They push their way in front of all other applications, demanding that the kernel forward packets to them. An application that may actually be receiving packets from a point lower in the stack (such as a packet sniffer) would still receive the packets before the firewall sees them.
The firewall may forward the packets to other applications - those that would normally get the packet if the firewall wasn't intercepting the packet transfer from stack to application.
The firewall may send a "normal" RST or cause an ICMP error if nothing else wants the packet.
The firewall may be configured to not send a RST or ICMP error if nothing else wants the packet. This is what Gibson calls a "stealth" response.
If the kernel has no application to forward the packet to, IT will send the normal RST or ICMP error packet.
When an application wants to send a packet, it hands this to the kernel which makes all arrangements of routing and establishing communications with the remote.
Firewalls _may_ be configured to stand between the OTHER applications and the kernel transmission function. There, it may block transmission or run a user annoyance box to ask the user if such transmission is to be allowed. It may then forward the packet for transmission, or fake it, and tell the sending application anything it wants.
On the client, the port number is always ephemeral - on the server, the port number is always fixed. The client always opens the control port, and MAY send a 'PORT' command to direct opening of a data port. If the 'PORT' command is used, the server will open the connection from it's data port to the client port number specified in the PORT command from the client. See RFC0959. Note that the contents of the PORT command (the client port number) is not under control of the _user_ who is running the client, but is the "next available" port that the client gets access to by the kernel.
See above. The client specifies the receiving port in the PORT command. If the client does not send the PORT command (the user had specified 'passive' mode, or the client application is defaulting to that mode), then the server sends the data on the control channel. One reason the server can't select the port is that it doesn't know what ELSE the client may be doing (and therefore what ports are already in use).
RFC0959 is the official specification for FTP
0959 File Transfer Protocol. J. Postel, J.K. Reynolds. Oct-01-1985. (Format: TXT=147316 bytes) (Obsoletes RFC0765) (Updated by RFC2228, RFC2640, RFC2773) (Also STD0009) (Status: STANDARD)
and RFC2228 (FTP Security Extensions) and RFC2640 (Internationalization of the File Transfer Protocol) add material that isn't relevant to this discussion, as does RFC2389 (Feature negotiation mechanism for the File Transfer Protocol). RFC2773 (Encryption using KEA and SKIPJACK) is an experimental proposal, and was not adopted.
Because you're using "application" here as a synonym to "process", please remember, that not every firewall implementation is implemented with a process. Many filtering software programs are implemented in kernel space.
It depends very much on what firewall you are talking about and how you tested the port status (what scanner you used). For example (assume no firewall), if you scanned when the FTP server was inactive you'll see "closed" in your scan (the kernel answered), but if the FTP server is active you'll see open. The firewall rules may just add complications to the above. You may also want to keep in mind various things on the way between the scanner and your machine (such as external firewalls, NAT, etc).
What this means is if the firewall really blocks all TCP packets that come to port 21 (with or without RST) they'll never make it to your FTP server.
As to initiating a connection: that would usually mean an outgoing packet rather than an incoming one. Most firewalls keep very different rules for incoming and outgoing packets, so you could very well have port 21 closed to incoming packets but allowing outbound packets to port 21. Check the existing rules to see what is done.
There are plenty of free programs to do just that. Google is your friend.
Have a look at the FTP protocol specification to understand how it works. The short version: the server and the client negotiate (over the connection to server port 21) who will be the active party and who is the listener, and what port will the latter listen on. As a side note: FTP is one of the nastiest protocols to NAT - most people will use some kind of proxy for it (if they allow it at all). As to port collisions - most systems do not allow that, so if it occurs you are out of luck.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.