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

    From Andrew@110:300/11 to All on Sat Apr 5 16:22:39 2014
    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

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: A noiseless patient Spider (110:300/11@linuxnet)
  • From Andrew@110:300/11 to All on Sat Apr 5 16:23:10 2014
    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

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: A noiseless patient Spider (110:300/11@linuxnet)
  • From Andrew@110:300/11 to All on Sat Apr 5 16:31:21 2014
    Subject: Re: Why does nmap appear to be slower vs. reject rules than drop
    rules?

    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.

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: A noiseless patient Spider (110:300/11@linuxnet)
  • From Ken Sims@110:300/11 to All on Sat Apr 5 21:53:23 2014
    Subject: Re: Why does nmap appear to be slower vs. reject rules than drop rules?

    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

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: A noiseless patient Spider (110:300/11@linuxnet)
  • From Moe Trin@110:300/11 to All on Sat Apr 5 23:47:20 2014
    Subject: Re: Why does nmap appear to be slower vs. reject rules than drop
    rules?

    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

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: Crash Test Dummy Training Academy (110:300/11@linuxnet)
  • From Andrew@110:300/11 to All on Sun Apr 6 04:18:38 2014
    Subject: Re: Why does nmap appear to be slower vs. reject rules than drop
    rules?

    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

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: A noiseless patient Spider (110:300/11@linuxnet)
  • From Richard Kettlewell@110:300/11 to All on Sun Apr 6 09:20:10 2014
    Subject: Re: Why does nmap appear to be slower vs. reject rules than drop rules?

    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/

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: Anjou (110:300/11@linuxnet)
  • From Ken Sims@110:300/11 to All on Sun Apr 6 16:09:14 2014
    Subject: Re: Why does nmap appear to be slower vs. reject rules than drop rules?

    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

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: A noiseless patient Spider (110:300/11@linuxnet)