Re: Handling Scans.

[Valdis Kletnieks <Valdis.Kletnieks () VT EDU>]

On Tue, 13 Feb 2001 19:07:20 EST, "Reeves, Mike" said:
> It is not turned off on the router... I don't let destination unreachables
> out from the router because you can map an entire network using that
> information. I don't think that is excessive paranoia.. I thought it was

Remember that 'dest unreachable' has subcodes, as follows:

#define ICMP_UNREACH            3               /* dest unreachable, codes: */
#define         ICMP_UNREACH_NET        0               /* bad net */
#define         ICMP_UNREACH_HOST       1               /* bad host */
#define         ICMP_UNREACH_PROTOCOL   2               /* bad protocol */
#define         ICMP_UNREACH_PORT       3               /* bad port */
#define         ICMP_UNREACH_NEEDFRAG   4               /* IP_DF caused drop */
#define         ICMP_UNREACH_SRCFAIL    5               /* src route failed */

Of these, PMTU discovery only needs 'NEEDFRAG' to be generated by the router
if the next-hop requires fragmenting.  And since *ALL* addresses through that
next hop would generate it, it's hardly a good mapping tool.  That one
should be passed.

Codes 0-3 can be suppressed, at the expense of causing more
network traffic and waits for timeouts.  Most IP stacks trying to make
an inbound connection will retransmit the SYN packet multiple times
if they fail to get an ICMP_UNREACH or other reply back (this is how, for
example, web browsers and similar programs can give back "unable to contact
host" errors almost immediately - they got a ICMP back.  If there's NO
response, you get the little animated icon while waiting for the timeout ;)

If your site has "well known" hosts that *should* be reachable, I'd
recommend allowing codes 0-3 back *from those hosts* so programs can
detect quickly if there's problems.  Feel free to nuke 0-3 for
hosts that random people shouldn't be trying to reach.. ;)

You should note that there is a problem with disabling 'Port Unreachable'
to prevent network mapping - those are generated for UDP ports
only.  RFC793, section 3.4 requires the following:

    1.  If the connection does not exist (CLOSED) then a reset is sent
    in response to any incoming segment except another reset.  In
    particular, SYNs addressed to a non-existent connection are rejected
    by this means.

Unfortunately, it's hard to distinguish *this* TCP RST packet outbound
from *other* causes of RST packets unless you have a clever stateful firewall.
And you *really* want to let the *other* RST packets to escape, because
it's *also* how you tell the *other* end "take a leap, we've rebooted and
the TCP connection is history"...

Anybody who manages to generate a code 5 (source route failed) deserves
not to get the ICMP back . ;)

> standard to tell you the truth. You can still traceroute the hosts.. So I
> shall rephrase.. I have all the "BAD" ICMP error messages turned off from
> the host. Anyone have any good recommendation on what ICMP to allow/disable?

Of the other ICMP codes, the following should be passed:

ICMP Source Quench should be allowed outbound - if this one is generated
outside the context of an established connection, you're probably being
DDOS'ed anyway (or a broken UDP application)...

If you allow TTL Exceeded out, be sure to double-check you don't have
any IP stacks that generate that ICMP when they receive a packet with
TTL=0 exactly.  I'm sure that *somebody* has an IP stack that will
reject packets that have a TTL of zero even when the final destination is
the local host, and those hosts will be mappable...

You probably want to allow ICMP type 12 (Param Problem) out...

It's probably safe to stomp on any outbound ICMP I've not specifically
mentioned...

Anyhow, I've been wordy enough here.. ;)

                                Valdis Kletnieks
                                Operating Systems Analyst
                                Virginia Tech