Filtered Port 21 somewhat open - iptables weirdness?

Hi,
one of the machines I administer to is running iptables with an input policy of drop, and allows only a few, selected services. Ftp is most definitely not among them, and there is no ftp server installed on the machine in question.

nmap -P0 -sS reports that among the expected, port 21 is open. telnetting to port 21 shows indeed a successful connect:
radagast@angmar:~>telnet <machine> 21
Trying <ip>...
Connected to <machine>
Escape character is '^]'.
^]
telnet> quit

But it just sits there, no welcoming banner, no response to obvious ascii-commands.

At the same time the kernel logs report that my telnet packets are being blocked by iptables. hping2 -A gets reset packets from that port as well, as if it weren't filtered, while amap shows me nothing of value.

Is this maybe some ip_conntrack weirdness? I already sweeped the machine as well as I could and so far I came up with no indication for a rootkit or backdoor.

Regs,
Sven

Sven Riedel                      [email protected]
Liebigstr. 38 
30163 Hannover                  "Python is merely Perl for those who
                                 prefer Pascal to C" (anon)

try using

netstat -tupan and see wich process is using that port. if any.

----- Original Message -----
From: "Sven Riedel" <[email protected]>
To: <[email protected]>
Sent: Friday, January 23, 2004 10:48 PM
Subject: Filtered Port 21 somewhat open - iptables weirdness?

Already tried that, and came up empty. Same thing with lsof (I compiled a static version of lsof on a guarenteed clean machine, just to make sure that I wasn't getting the output of a rootkit).

Regs,
Sven

Sven Riedel                      [email protected]
Liebigstr. 38 
30163 Hannover                  "Python is merely Perl for those who
                                 prefer Pascal to C" (anon)

I think this last statement pretty much tells us that you are getting a
response from somewhere other than you think. You cannot get a response
from a machine which is not running the service, therefore any response you do get must be coming from somewhere else...

Where are you performing the nmap from? What other machines are between the
nmap machine and the one being tested? I'm thinking of anything which might
redirect TCP port 21 to somewhere else by DNAT, or anything which might be running a transparent FTP proxy?

Remember that <machine> in that last line is produced by your local client, not by the remote server, so it is no guarantee that you are connecting to the system you think you are - it is merely saying that on trying to connect
to <machine>, you get a connection to something. It may not be a connection
to <machine>.

I bet that running ethereal on the machine you think you are ftping to (or on
a sniffer connected to the same network cable) shows no packets. I think
they are being diverted elsewhere between the tester and the tested machines.

Hope these suggestions point you in a constructive direction.

Regards,

Antony.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

                                                     Please reply to the list;
                                                           please don't CC me.