You should know that Windows XP (and probably other versions) has an internal wrapper for FTP connections (the purpose of this is to try to allow PORT command to complete successfully, even behind a firewall or a router).
This wrapper intercepts any connection to any host on port 21, so it can monitor it and try to open the incoming port of a PORT command issued by the client.
This wrapper also has a side effect: as it intercepts any connection to a port 21, it sends a signal that the connection has been established to the software, which will see the connection as established, but the connection is really established only to Windows's internal wrapper.
The wrapper then tries to open the connection to the real host, and if it timeouts, then it sends a signal to the software that the connection has been lost. The software will see the connection as lost.
Summing this up, the software believes a connection has been successfully established, then lost, but no real connection has been established.
So, in your case, what happens: you run nmap. Nmap tries to connect to your server on port 21. Windows's wrapper intercepts the connection. Nmap "thinks" it is connected to your server (but it's only connected to the wrapper), and reports the port as opened.
You can confirm this by typing in a command line:
ftp 4.3.2.1
You'll see:
C:>ftp 4.3.2.1
Connected to 4.3.2.1.
Connection closed by foreign host.
You can try any valid IP, ftp will always connect, and disconnect shortly after, whereas it should report "Connection timed out".
I never saw any documentation about this. After many investigation, I discovered this strange behavior, and after more investigation, discovered why it is here.
Well, the conclusion of this (big) answer is that the port 21 of your server is definitely closed, as netstat reports, and nmap is fooled by this behaviour.
My guess is it's a firewall issue. To diagnose, either switch to root or use sudo to execute these commands described below:
Firstly, service iptables status will show you your current rules. Depending on how esoteric your firewall rules are, you may need to add them into the main question to debug but essentially you're looking for a line that accepts TCP port 8800 prior to a line that rejects all connections.
e.g.
Table: filter
Chain INPUT (policy ACCEPT)
num target prot opt source destination
...
14 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:8800
15 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
If you don't have a REJECT line on your input chain, then the firewall is probably already turned off.
One way to get around this is obviously to turn off the firewall (service iptables stop) although this defeats the entire purpose of having a firewall.
If you need to add a new firewall rule, you have a couple of options:
Use the excellent Firewall Configuration tool (system-config-firewall) that ships with Fedora and can be found at the System->Administration->Firewall menu item in Gnome.
On the command line, insert a new rule before the REJECT rule by executing the following (uses numbers from my example above): iptables -I INPUT 15 -m state --state NEW -m tcp -p tcp --dport 8800 -j ACCEPT. NOTE that these changes are not permanent and will not persist beyond the next reboot.
Manually edit the /etc/sysconfig/iptables file and add a rule (-A INPUT -m state --state NEW -m tcp -p tcp --dport 8800 -j ACCEPT) to the firewall prior to the REJECT rule. Cycle the firewall service to pick up the changes via a service iptables restart. These changes will be applied every time the firewall service is started.
Best Answer
From my reading of this page, it appears that ntp doesn't use the INADDR_ANY
0.0.0.0address exclusively partly for security reasons, and partly for authentication reasons.First port 123, is below 1024, and so is considered a privileged port, and only root can bind to that port. Ntp is typically set to drop privileges after it is started. From what I understand from the mail lists, and the article once the privileges are dropped can't open a socket to reply from correct source port of 123, so ntp opens up sockets for every assigned address before it drops privileges.
From what I have read some of the authentication mechanisms for ntp basically require that the source and destination port be 123, and nothing else.
The matter isn't entirely clear. See the section about the wildcard address
0.0.0.0, it is opened by ntpd for some reason, but from the comments should never actually be used, except possible in some special rare cases, that the devs aren't entirely sure about, but, they don't want to remove the socket, just in case they break things.I think the main answer to your question is in the above comment here.