nmap and "filtered" ports

can someone explain to me what exactly it means when nmap sees ports as
"filtered"?
because this is confusing me a bit:

myhostname:/ # nmap localhost
Starting nmap V. 2.54BETA30 ( www.insecure.org/nmap/ )
Interesting ports on localhost (127.0.0.1):
(The 1542 ports scanned but not shown below are in state: closed)
Port State Service
21/tcp open ftp
22/tcp open ssh
25/tcp open smtp
80/tcp open http
139/tcp open netbios-ssn
515/tcp open printer
10000/tcp open snet-sensor-mgmt

these are all the ports im using, localhost indeed can access them
unconditionally. but nmap from the outside:

rata:~ nmap myhostname.etc.etc.
Starting nmap V. 2.3BETA6 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/)
Interesting ports on a.b.c.d (1.2.3.4):
Port State Protocol Service
21 open tcp ftp
22 open tcp ssh
25 filtered tcp smtp
80 open tcp http
111 filtered tcp sunrpc
137 filtered tcp netbios-ns
138 filtered tcp netbios-dgm
139 filtered tcp netbios-ssn
515 filtered tcp printer
756 filtered tcp unknown
1434 filtered tcp ms-sql-m
2049 filtered tcp nfs

so it sees the open ports which are indeed open. port 1434, 21049, 756,
111, etc are absolutely definitely not in use on my server. the others,
that are in use, 25, 515, 139, etc, are absolutely definitely DROPped by
iptables when accessed from the external interface (as this nmap is doing).
i can tcpdump on the external interface and witness that my server is not
sending back any reply packets whatsoever, during the nmap, except for
ports 21,22,and 80.

so how on earth does nmap come to these conclusions?

-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: nmap and "filtered" ports

urgrue wrote:

> rata:~ nmap myhostname.etc.etc.
> Starting nmap V. 2.3BETA6 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/)
> Interesting ports on a.b.c.d (1.2.3.4):
> Port State Protocol Service
> 21 open tcp ftp
> 22 open tcp ssh
> 25 filtered tcp smtp
> 80 open tcp http
> 111 filtered tcp sunrpc
> 137 filtered tcp netbios-ns
> 138 filtered tcp netbios-dgm
> 139 filtered tcp netbios-ssn
> 515 filtered tcp printer
> 756 filtered tcp unknown
> 1434 filtered tcp ms-sql-m
> 2049 filtered tcp nfs
>
> so it sees the open ports which are indeed open. port 1434, 21049, 756,
> 111, etc are absolutely definitely not in use on my server. the others,
> that are in use, 25, 515, 139, etc, are absolutely definitely DROPped by
> iptables when accessed from the external interface (as this nmap is doing).
> i can tcpdump on the external interface and witness that my server is not
> sending back any reply packets whatsoever, during the nmap, except for
> ports 21,22,and 80.
>
> so how on earth does nmap come to these conclusions?

The obvious guess is that "filtered" means that a SYN probe resulted
in neither a SYN-ACK nor a RST.

Sending a SYN probe to a port which wasn't filtered and on which no
process was listening would result in a RST.

Sending a SYN probe which gets blocked by the filtering rules will
produce the same result (e.g. no response, ICMP destination
unreachable) regardless of whether or not anything is listening on
that port.

--
Glynn Clements
-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: nmap and "filtered" ports

ok thanks for your answers.
is there any practical difference (from a security standpoint) between
offering an icmp dest unreachable (reject) vs simply dropping the packet
entirely? or are both "just as good"...?

can anyone venture to guess why, also, nmap feels ports 111, 756, 1434, and
2049 are "filtered"? there is no iptables rule applying to those ports
whatsoever (policy is ACCEPT). surely these should behave just like any
arbitrary unfiltered port that has no process listening on it (ie RST, as i
understand)?



>urgrue wrote:
>
> > rata:~ nmap myhostname.etc.etc.
> > Starting nmap V. 2.3BETA6 by Fyodor (fyodor@dhp.com,
> www.insecure.org/nmap/)
> > Interesting ports on a.b.c.d (1.2.3.4):
> > Port State Protocol Service
> > 21 open tcp ftp
> > 22 open tcp ssh
> > 25 filtered tcp smtp
> > 80 open tcp http
> > 111 filtered tcp sunrpc
> > 137 filtered tcp netbios-ns
> > 138 filtered tcp netbios-dgm
> > 139 filtered tcp netbios-ssn
> > 515 filtered tcp printer
> > 756 filtered tcp unknown
> > 1434 filtered tcp ms-sql-m
> > 2049 filtered tcp nfs
> >
> > so it sees the open ports which are indeed open. port 1434, 21049, 756,
> > 111, etc are absolutely definitely not in use on my server. the others,
> > that are in use, 25, 515, 139, etc, are absolutely definitely DROPped by
> > iptables when accessed from the external interface (as this nmap is
> doing).
> > i can tcpdump on the external interface and witness that my server is not
> > sending back any reply packets whatsoever, during the nmap, except for
> > ports 21,22,and 80.
> >
> > so how on earth does nmap come to these conclusions?
>
>The obvious guess is that "filtered" means that a SYN probe resulted
>in neither a SYN-ACK nor a RST.
>
>Sending a SYN probe to a port which wasn't filtered and on which no
>process was listening would result in a RST.
>
>Sending a SYN probe which gets blocked by the filtering rules will
>produce the same result (e.g. no response, ICMP destination
>unreachable) regardless of whether or not anything is listening on
>that port.
>
>--
>Glynn Clements

-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: nmap and "filtered" ports

urgrue wrote:

> is there any practical difference (from a security standpoint) between
> offering an icmp dest unreachable (reject) vs simply dropping the packet
> entirely? or are both "just as good"...?

If you filter *all* ports, then simply dropping the packet without any
response means that an attacker can't even tell if there's a box at
the corresponding IP address. OTOH, a (potentially) legitimate
connection attempt can't tell whether it was explicitly refused or if
the packet got lost on the way.

> can anyone venture to guess why, also, nmap feels ports 111, 756, 1434, and
> 2049 are "filtered"? there is no iptables rule applying to those ports
> whatsoever (policy is ACCEPT). surely these should behave just like any
> arbitrary unfiltered port that has no process listening on it (ie RST, as i
> understand)?

In your original message, you said:

> i can tcpdump on the external interface and witness that my server is not
> sending back any reply packets whatsoever, during the nmap, except for
> ports 21,22,and 80.

If there isn't anything on that port you should get a RST. If there is
something on it, you should get SYN+ACK. The only case where you
should get nothing is if the packet is dropped by the filtering rules
(not necessarily a rule for that specific port).

--
Glynn Clements
-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: nmap and "filtered" ports

On Fri, 21 Mar 2003, urgrue wrote:

> ok thanks for your answers.
> is there any practical difference (from a security standpoint) between
> offering an icmp dest unreachable (reject) vs simply dropping the packet
> entirely? or are both "just as good"...?
>
> can anyone venture to guess why, also, nmap feels ports 111, 756, 1434, and
> 2049 are "filtered"? there is no iptables rule applying to those ports
> whatsoever (policy is ACCEPT). surely these should behave just like any
> arbitrary unfiltered port that has no process listening on it (ie RST, as i
> understand)?

I'm not sure for your case, but my ISP 'filters' ports that netbus and
back orfice are know to listen on at the router level. This causes nmap to
show me the same filtered responce as you are getting.

-Nathan

>
>
> >urgrue wrote:
> >
> > > rata:~ nmap myhostname.etc.etc.
> > > Starting nmap V. 2.3BETA6 by Fyodor (fyodor@dhp.com,
> > www.insecure.org/nmap/)
> > > Interesting ports on a.b.c.d (1.2.3.4):
> > > Port State Protocol Service
> > > 21 open tcp ftp
> > > 22 open tcp ssh
> > > 25 filtered tcp smtp
> > > 80 open tcp http
> > > 111 filtered tcp sunrpc
> > > 137 filtered tcp netbios-ns
> > > 138 filtered tcp netbios-dgm
> > > 139 filtered tcp netbios-ssn
> > > 515 filtered tcp printer
> > > 756 filtered tcp unknown
> > > 1434 filtered tcp ms-sql-m
> > > 2049 filtered tcp nfs
> > >
> > > so it sees the open ports which are indeed open. port 1434, 21049, 756,
> > > 111, etc are absolutely definitely not in use on my server. the others,
> > > that are in use, 25, 515, 139, etc, are absolutely definitely DROPped by
> > > iptables when accessed from the external interface (as this nmap is
> > doing).
> > > i can tcpdump on the external interface and witness that my server is not
> > > sending back any reply packets whatsoever, during the nmap, except for
> > > ports 21,22,and 80.
> > >
> > > so how on earth does nmap come to these conclusions?
> >
> >The obvious guess is that "filtered" means that a SYN probe resulted
> >in neither a SYN-ACK nor a RST.
> >
> >Sending a SYN probe to a port which wasn't filtered and on which no
> >process was listening would result in a RST.
> >
> >Sending a SYN probe which gets blocked by the filtering rules will
> >produce the same result (e.g. no response, ICMP destination
> >unreachable) regardless of whether or not anything is listening on
> >that port.
> >
> >--
> >Glynn Clements
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-admin" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>

--

I'm as confused as a baby in a topless bar !

--

-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Running an ftp Server Behind a Router/Firewall

I'm having a heck of a time getting my ftp server (proftpd) to function
properly behind a router. I think I understand the passive vs active
concept and as far as I can tell I've configured the router properly to
handle this.

Does anyone else have proftpd running properly behind a router? Is
other ftp server software better suited to run behind a router?

If someone has an ftp server running properly maybe they could send me an
explanation of their router configuration?

--
Marshall Lake -- mlake@mlake.net -- http://mlake.net

-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Running an ftp Server Behind a Router/Firewall

Hi.
I am currently running ftp behind the router. Only thing I had to do is to
forward port 21 to machine where ftp server is. Here how it's done in my
router:
PORTFWIP="192.168.0.3"

$IPTABLES -A FORWARD -i $EXTIF -o $INTIF -p tcp --dport 3389 -m state
--state NEW,ESTABLISHED,RELATED -j ACCEPT

$IPTABLES -A PREROUTING -t nat -p tcp -d $EXTIP --dport 3389 -j DNAT --to
$PORTFWIP:3389

I hope this helped


>
> I'm having a heck of a time getting my ftp server (proftpd) to function
> properly behind a router. I think I understand the passive vs active
> concept and as far as I can tell I've configured the router properly to
> handle this.
>
> Does anyone else have proftpd running properly behind a router? Is
> other ftp server software better suited to run behind a router?
>
> If someone has an ftp server running properly maybe they could send me
> an explanation of their router configuration?
>
> --
> Marshall Lake -- mlake@mlake.net -- http://mlake.net
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-admin"
> in the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html


--
Artem Daniliants

E-Mail; artem@goldenrain.net
Phone: +358504100167

FInland, Oulu


-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Running an ftp Server Behind a Router/Firewall

HI. Let me explain a bit more =)
Here is the deal, I have two computers:
1.Router/gateway (running Linux kernel 2.4.19 patched with Gsecurity)
2.FTP server machine running proFTPD 1.2.7 on port 21

On router I am using masquerade script which forwards 21 port connections
to LAN computer with IP 192.168.0.3

Here how it's done using iptables on the router:

PORTFWIP="192.168.0.3"

$IPTABLES -A FORWARD -i $EXTIF -o $INTIF -p udp --dport 21 -m state
--state NEW,ESTABLISHED,RELATED -j ACCEPT

$IPTABLES -A PREROUTING -t nat -p udp -d $EXTIP --dport 21 -j DNAT --to
$PORTFWIP:21

This is just a part of my masquerade script. I hope this helped. I didn't
do anything special with proftpd.conf


Cheers

>
> Thanks for responding to my query.
>
>> I am currently running ftp behind the router. Only thing I had to do
>> is to forward port 21 to machine where ftp server is. Here how it's
>> done in my router:
>
> Which ftp server software are you running?
>
>> PORTFWIP="192.168.0.3"
>>
>> $IPTABLES -A FORWARD -i $EXTIF -o $INTIF -p tcp --dport 3389 -m state
>> --state NEW,ESTABLISHED,RELATED -j ACCEPT
>>
>> $IPTABLES -A PREROUTING -t nat -p tcp -d $EXTIP --dport 3389 -j DNAT
>> --to $PORTFWIP:3389
>
> I don't run IPTABLES and I'm not sure I understand the above. Are you
> telling the router to send back all ftp data responses via port 3389 ?
> Did you have to tell ftp anything special with regard to data ports when
> you initiated it?
>
> --
> Marshall Lake -- mlake@mlake.net -- http://mlake.net


--
Artem Daniliants

E-Mail; artem@goldenrain.net
Phone: +358504100167

FInland, Oulu


-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Running an ftp Server Behind a Router/Firewall

Artem Daniliants said:

> HI. Let me explain a bit more =)

I take it this doesn't work?

> On router I am using masquerade script which forwards 21 port connections
> to LAN computer with IP 192.168.0.3
>
> Here how it's done using iptables on the router:
>
> PORTFWIP="192.168.0.3"
>
> $IPTABLES -A FORWARD -i $EXTIF -o $INTIF -p udp --dport 21 -m state
> --state NEW,ESTABLISHED,RELATED -j ACCEPT

Shouldn't this be "-p tcp"?

> $IPTABLES -A PREROUTING -t nat -p udp -d $EXTIP --dport 21 -j DNAT --to
> $PORTFWIP:21

Again... tcp not udp.

How about the reverse? ftp need to know where to go and how to get there:

$IPTABLES -t nat -A PREROUTING -d $EXTIP -p tcp --dport 21 \
-m state --state NEW,ESTABLISHED,RELATED -j DNAT --to 192.168.0.3

Make sure you have default route on 192.168 machine set to your
gateway/firewall and it should just work. You can ping the outside world
from your ftp server right?




--
Scott
-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Running an ftp Server Behind a Router/Firewall

> Make sure you have default route on 192.168 machine set to your
> gateway/firewall and it should just work. You can ping the outside
> world from your ftp server right?

Yes, I can get outside of my router with everything except ftp data. I
have the default route set up properly. I don't run IPTABLES. I have a
dedicated router ... a Linksys. I've exhausted trying everything I know
of to get ftp working.

--
Marshall Lake -- mlake@mlake.net -- http://mlake.net

-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Running an ftp Server Behind a Router/Firewall

Marshall Lake wrote:

> I'm having a heck of a time getting my ftp server (proftpd) to function
> properly behind a router. I think I understand the passive vs active
> concept and as far as I can tell I've configured the router properly to
> handle this.

For both active and passive modes, the control channel consists of an
inbound connection to port 21.

For active mode, the data channels consist of an outbound connection
from port 20 on the server to an arbitrary port on the client; the
destination (client) port is sent from the client to the server over
the control channel.

For passive mode, the data channels consist of an inbound connection
from an arbitrary port on the client to an arbitrary port on the
server. The destination (server) port is sent from the server to the
client over the control channel.

> Does anyone else have proftpd running properly behind a router? Is
> other ftp server software better suited to run behind a router?

What do you mean by "behind a router"? Every FTP server on the
Internet is running behind a router.

If you're talking about running it through NAT, then you have to
configure NAT to forward the data channels (which run on either port
20 or arbitrary ports, depending upon whether you're using active or
passive FTP) as well as the control channels (port 21).
OTOH, if you really are just talking about a plain router, without any
kind of NAT, then you need one real IP address per host, but you
shouldn't need any special configuration for FTP.

In any case, the choice of FTP server software doesn't really affect
anything.

[later]

> > Make sure you have default route on 192.168 machine set to your
> > gateway/firewall and it should just work. You can ping the outside
> > world from your ftp server right?
>
> Yes, I can get outside of my router with everything except ftp data. I
> have the default route set up properly. I don't run IPTABLES. I have a
> dedicated router ... a Linksys. I've exhausted trying everything I know
> of to get ftp working.

Then you might be better off posting to a LinkSys mailing list; the
issue here is how to configure the router, not the server.

--
Glynn Clements
-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Running an ftp Server Behind a Router/Firewall

Thanks for everyone's input with regard to my problem. I've discovered
that the cause lies with the router (Linksys BEFSR81 V2) firmware
(v2.44.2). There are two areas where port forwarding can be configured.
For ftp (and only ftp as far as I can tell) port forwarding must be done
in the area entitled "Port Range Forwarding".

--
Marshall Lake -- mlake@mlake.net -- http://mlake.net

-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html