nmap and "filtered" ports

nmap and "filtered" ports

[urgrue]

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?

Re: nmap and "filtered" ports

[Glynn Clements]

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 <glynn.clements@virgin.net>

Re: nmap and "filtered" ports

[urgrue]

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 <glynn.clements@virgin.net>

Re: nmap and "filtered" ports

[Glynn Clements]

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 <glynn.clements@virgin.net>

Re: nmap and "filtered" ports

[Nathan]

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 <glynn.clements@virgin.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
>

-- 

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

--

Running an ftp Server Behind a Router/Firewall

[Marshall Lake]

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

Re: Running an ftp Server Behind a Router/Firewall

[Artem Daniliants]

 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

Re: Running an ftp Server Behind a Router/Firewall

[Artem Daniliants]

 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

Re: Running an ftp Server Behind a Router/Firewall

[Scott Taylor]

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?

<snip mostly redundant and some useless info>


--
Scott

Re: Running an ftp Server Behind a Router/Firewall

[Marshall Lake]

> 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

Re: Running an ftp Server Behind a Router/Firewall

[Glynn Clements]

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 <glynn.clements@virgin.net>

Re: Running an ftp Server Behind a Router/Firewall

[Marshall Lake]

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