Re: Why can I telnet my port 21

From: Alexander Harsch (infodude_at_gmx.de)
Date: 03/25/04 

Date: Thu, 25 Mar 2004 23:04:33 +0100

Tim Haynes wrote:

> Colin McKinnon
> <colin.thisisnotmysurname@ntlworld.deletemeunlessURaBot.com> writes:
>
>>> doing a scan with nmap (using the -P0 option) I can see, that there is a
>>> couple of ports open. One of them is port21. I do not have a server
>>> running on this port 21 (no ftp). When I connect from the internet on my
>>> machine on port 21 via telnet, I get a connection, but after a few
>>> seconds a timeout occurs.
>>
>> What does netstat -ap say?

>
> Speedier version: `netstat -plant | grep LISTEN'. Tcp is all that's
> interesting here and we don't need names for things.
>
tcp 0 0.0.0.0:4000 0.0.0.0:* LISTEN 4436/mldonkey
tcp 0 0 0.0.0.0:1024 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:4001 0.0.0.0:* LISTEN 4436/mldonkey
tcp 0 0 0.0.0.0:2049 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:4002 0.0.0.0:* LISTEN 4436/mldonkey
tcp 0 0 0.0.0.0:16743 0.0.0.0:* LISTEN 4436/mldonkey
tcp 0 0 0.0.0.0:841 0.0.0.0:* LISTEN 1931/rpc.statd
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 1470/portmap
tcp 0 0 0.0.0.0:4080 0.0.0.0:* LISTEN 4436/mldonkey
tcp 0 0 0.0.0.0:6000 0.0.0.0:* LISTEN 3087/X
tcp 0 0 0.0.0.0:4662 0.0.0.0:* LISTEN 4436/mldonkey
tcp 0 0 0.0.0.0:631 0.0.0.0:* LISTEN 2631/cupsd
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 2706/master
tcp 0 0 0.0.0.0:700 0.0.0.0:* LISTEN 2645/rpc.mountd
tcp 0 :::22 :::* LISTEN 4104/sshd
^^^^^^^^^^^^^^^^^
Nothing about port 21.

> Other questions: is (x)inetd listening on 21/tcp but the ftpd behind it
> nonexistent?
^^^^^^^^^^^^^^^^^^^
Nope, it's not started.

> What hosts.{allow,deny} rules are there of relevance?
^^^^^^^^^^^^^^^^^^^^^
They are both empty, but this is propably of no relevance.

How
> quick is the disconnection?
^^^^^^^^^^^^^^^^^^^^
About 5 seconds.

Is there anything in a recently-modified
> logfile relating to the connection attempt?
>
^^^^^^^^^^^^^^^^^^^^^
All I can find in the logs is the entries from the firewall, saying that
port 25 was blocked.

>>> I appended my input rules:
>> <snip>
>> yeah, thanx.
>
> Those were useful, because they allow us to say the firewall was designed
> approximately in the stone-age. Specifically, they seem to be built around
> allowing large tracts of source-IP#s to get at anything running on the
> box, whilst dropping a few spot-services. This is not the way to firewall
> a machine; you want stateful matching right up tops (INVALID, followed by
> ESTABLISHED,RELATED rules), rules per provided service, LAN
> considerations, then drop everything else. Nice clear well-organized
> blocks, statefulness for extra security rather than trusting who the
> packet says it's from (`hey, I'm a nice Tim, trust me!!'), etc.
>
> ~Tim
^^^^^^^^^^^^^^^^^^^^^^
But the firewall rules, no matter when they were designed say, that iptables
should please drop these packets. But you are right, they don't look very
logical to me either.
Regards, Alex

Relevant Pages

  • Re: port scan to juniper fw
    ... If the packet with SRC-IP a.b.c.d ... enters firewall via interface 'X' and the route on the firewall for ... the below default behavior of Juniper SSG for a port scan. ... Information Assurance Certification Review ...
    (Pen-Test)
  • RE: Strange replies on closed port
    ... port should be a RST - not dropping the packet. ... receiving an UDP datagram to a non 'listening' port. ... that message isn't generated by the end host, ... Connecting to a closed Port w/o Firewall: ...
    (Pen-Test)
  • Re: Firewall questions -- what is ...?
    ... packet payload inspection. ... IDS is not a firewall and does not necessarily protect you. ... port number for a well known service and the destination port is above 1023, ... Firewalls and IDS are prone to frequent false alarms. ...
    (microsoft.public.security)
  • Re: Basic NAT / Firewall Question
    ... There are two basic types of NAT (Network Address Translation) which you ... NAPT simply maps port numbers to a given address. ... Your firewall will make a note from where the connection was ... with its own address and then sends this "new" packet out on its local ...
    (Security-Basics)
  • Re: FTP Window of opportunity?
    ... Your computer sent a SYN packet... ... a SYN/ACK back, ... > well as blocked by the firewall. ... > When I scan with ISS, the FTP port shows up. ...
    (Pen-Test)