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

Groups > comp.os.linux.security > #474 > 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:23 +0000
    Re: Why does nmap appear to be slower vs. reject rules than drop rules? Ken Sims <ng12207@kensims.#nospam#.net.invalid> - 2014-04-05 14:53 -0700
      Re: Why does nmap appear to be slower vs. reject rules than drop rules? Andrew <andrew@invalid.invalid> - 2014-04-06 04:18 +0000
        Re: Why does nmap appear to be slower vs. reject rules than drop rules? Ken Sims <ng12207@kensims.#nospam#.net.invalid> - 2014-04-06 09:09 -0700

#474 — 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]

#476

Hi Andrew -

On Sat, 5 Apr 2014 16:23:10 +0000 (UTC), Andrew
<andrew@invalid.invalid> 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. That seems 
>counterintuitive to me, and makes observing differences when I change 
>things irritating. What is the cause of this?

One possibility that comes to mind is rejecting a TCP connection with
an ICMP rejection.

Keep your existing rules, but right ahead of your ICMP rejection rule,
put

-A INPUT -p tcp -j REJECT --reject-with tcp-reset

-- 
Ken

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

#478

On Sat, 05 Apr 2014 14:53:23 -0700, Ken Sims 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. That seems
>>counterintuitive to me, and makes observing differences when I change
>>things irritating. What is the cause of this?
> 
> One possibility that comes to mind is rejecting a TCP connection with an
> ICMP rejection.
> 
> Keep your existing rules, but right ahead of your ICMP rejection rule,
> put
> 
> -A INPUT -p tcp -j REJECT --reject-with tcp-reset

That works perfectly, and thank you, but I don't understand why it works. 
From RFC 1122: 

"A transport protocol that has its own mechanism for notifying the sender 
that a port is unreachable (e.g., TCP, which sends RST segments) MUST 
nevertheless accept an ICMP Port Unreachable for the same purpose."

I read this as "it ought to behave the same way receiving an ICMP reject 
as it does when receiving a TCP reject", but clearly it doesn't. I must 
admit that I don't understand the protocols well enough to know whether 
that's a reasonable expectation. 

-- 

Andrew

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

#480

Hi Andrew -

On Sun, 6 Apr 2014 04:18:38 +0000 (UTC), Andrew
<andrew@invalid.invalid> wrote:

>That works perfectly, and thank you, but I don't understand why it works. 
>From RFC 1122: 
>
>"A transport protocol that has its own mechanism for notifying the sender 
>that a port is unreachable (e.g., TCP, which sends RST segments) MUST 
>nevertheless accept an ICMP Port Unreachable for the same purpose."
>
>I read this as "it ought to behave the same way receiving an ICMP reject 
>as it does when receiving a TCP reject", but clearly it doesn't. I must 
>admit that I don't understand the protocols well enough to know whether 
>that's a reasonable expectation. 

nmap isn't really a transport program and isn't using the protocols as
they are intended.

Nevertheless IMO your expectation is reasonable.  nmap *ought* to
handle the ICMP rejections.

But speaking in more general terms, a reset is inherent in the TCP
connection itself, so when iptables is being used to REJECT
connections, IMO it is best to REJECT the tcp protocol with the
tcp-reset and everything else with the appropriate ICMP rejection
type.

-- 
Ken

[toc] | [prev] | [standalone]

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

csiph-web