Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.security > #473 > unrolled thread

Why does nmap appear to be slower vs. reject rules than drop rules?

Back to article view | Back to comp.os.linux.security

Contents

  Why does nmap appear to be slower vs. reject rules than drop rules? Andrew <andrew@invalid.invalid> - 2014-04-05 16:22 +0000
    Re: Why does nmap appear to be slower vs. reject rules than drop rules? Andrew <andrew@invalid.invalid> - 2014-04-05 16:31 +0000
    Re: Why does nmap appear to be slower vs. reject rules than drop rules? Moe Trin <ibuprofin@painkiller.example.tld.invalid> - 2014-04-05 23:47 +0000
      Re: Why does nmap appear to be slower vs. reject rules than drop rules? Richard Kettlewell <rjk@greenend.org.uk> - 2014-04-06 10:20 +0100

#473 — Why does nmap appear to be slower vs. reject rules than drop rules?

I'm setting up a scratch server to experiment with iptables. I tend to 
prefer rejecting packets over dropping them (mostly because that seems to 
be what the RFCs specify), so my last rule is a -j REJECT. The rules look 
like this: 

# Generated by iptables-save v1.4.14 on Sat Apr  5 16:09:28 2014
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [668:57464]
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m multiport --dports 22,80,443 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-port-unreachable
COMMIT
# Completed on Sat Apr  5 16:09:28 2014

I pared most of them out to lose the noise. Point nmap at the server with 
these rules, and it takes ~15 minutes to finish. Comment out the 
rejection, and it takes less than five seconds. That seems 
counterintuitive to me, and makes observing differences when I change 
things irritating. What is the cause of this?

-- 

Andrew

[toc] | [next] | [standalone]

#475

I'm not sure what my newsreader did that stripped the line breaks between 
the rules, but this should be fixed...

> # Generated by iptables-save v1.4.14 on Sat Apr  5 16:09:28 2014
> *filter
> :INPUT DROP [0:0]
> :FORWARD DROP [0:0]
> :OUTPUT ACCEPT [668:57464]
> -A INPUT -p icmp -j ACCEPT
> -A INPUT -i lo -j ACCEPT 
> -A INPUT -p tcp -m multiport --dports 22,80,443 -j ACCEPT 
> -A INPUT -j REJECT --reject-with icmp-port-unreachable
> COMMIT
> # Completed on Sat Apr  5 16:09:28 2014

-- 
Andrew

IT is a filter. It accepts masochists on stdin and emits misanthropes on
stdout.

[toc] | [prev] | [next] | [standalone]

#477

On Sat, 5 Apr 2014, in the Usenet newsgroup comp.os.linux.security, in
article <lhpake$b54$1@dont-email.me>, Andrew wrote:

>I'm setting up a scratch server to experiment with iptables. I tend to
>prefer rejecting packets over dropping them (mostly because that seems
>to be what the RFCs specify), so my last rule is a -j REJECT.

Yup.   Have you looked at Rusty's various HOWTOs?  Try
http://www.netfilter.org/documentation/HOWTO/ and look at the seven
HOWTOs.  Some time ago, it looked like this:

   [TXT] NAT-HOWTO.txt 05-Oct-2012 10:33 25K
   [TXT] netfilter-double-nat.txt 05-Oct-2012 10:33 9.4K
   [TXT] netfilter-extensions-HOWTO.txt 05-Oct-2012 10:33 80K
   [TXT] netfilter-hacking-HOWTO.txt 05-Oct-2012 10:33 81K
   [TXT] netfilter-mirror-HOWTO.txt 05-Oct-2012 10:33 7.8K
   [TXT] networking-concepts-HOWTO.txt 05-Oct-2012 10:33 28K
   [TXT] packet-filtering-HOWTO.txt 05-Oct-2012 10:33 51K

>I pared most of them out to lose the noise. Point nmap at the server
>with these rules, and it takes ~15 minutes to finish. Comment out the
>rejection, and it takes less than five seconds.

"man nmap"   and look at the problems about determining open/dropped.
Specifically:

      Nmap cannot determine whether the port is open because
      packet filtering prevents its probes from reaching the port.
      The filtering could be from a dedicated firewall device,
      router rules, or host-based firewall software. These ports
      frustrate attackers because they provide so little
      information. Sometimes they respond with ICMP error messages
      such as type 3 code 13 (destination unreachable:
      communication administratively prohibited), but filters that
      simply drop probes without responding are far more common.
      This forces Nmap to retry several times just in case the
      probe was dropped due to network congestion rather than
      filtering. This slows down the scan dramatically.

>That seems counterintuitive to me, and makes observing differences
>when I change things irritating. What is the cause of this?

nmap waiting for a reply that never comes, because you dropped it in
the default rules.

        Old guy

[toc] | [prev] | [next] | [standalone]

#479

Moe Trin <ibuprofin@painkiller.example.tld.invalid> writes:
> article <lhpake$b54$1@dont-email.me>, Andrew wrote:
>>I pared most of them out to lose the noise. Point nmap at the server
>>with these rules, and it takes ~15 minutes to finish. Comment out the
>>rejection, and it takes less than five seconds.

What options are you giving to nmap and are you running it as root or
mortal?

> "man nmap"   and look at the problems about determining open/dropped.
> Specifically:
>
>       Nmap cannot determine whether the port is open because
>       packet filtering prevents its probes from reaching the port.
>       The filtering could be from a dedicated firewall device,
>       router rules, or host-based firewall software. These ports
>       frustrate attackers because they provide so little
>       information. Sometimes they respond with ICMP error messages
>       such as type 3 code 13 (destination unreachable:
>       communication administratively prohibited), but filters that
>       simply drop probes without responding are far more common.
>       This forces Nmap to retry several times just in case the
>       probe was dropped due to network congestion rather than
>       filtering. This slows down the scan dramatically.
>
>>That seems counterintuitive to me, and makes observing differences
>>when I change things irritating. What is the cause of this?
>
> nmap waiting for a reply that never comes, because you dropped it in
> the default rules.

You just described exactly the opposite of the behavior the OP reports.

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.security

csiph-web