|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Filtering ICMP (Was Re: SMURF amplifier block list)
On Mon, 20 Apr 1998, Michael Dillon wrote:
> Wholesale filtering of ?.?.?.255 is irresponsible but if you have
> downstream networks who are unable to block directed broadcasts then it is
> a reasonable stopgap measure to block ?.?.?.255 traffic in those
Only if the downstream networks are no bigger than a class C and/or
you have the permission of all customers affected by that filter
and the filter only affects packets destined to your customers
(not outbound packets to the net). If you have any downstreams
larger than a /24, you should allow those through.
Even then, your netmask should have 1s on the left and right
(i.e. 255.255.0.255) for a /16 subnetted at /8.
Really, you should filter the known broadcast addresses of
your downstream networks with the cooperation of those networks.
What I was objecting to was the idea that some ISP would get
the idea that it was a good idea to filter all .255 destined traffic
passing through their network and the general idea that it was
ok for an ISP to assume that .255 was a broadcast address when
they should actually know their downstream networks in more detail
than that (although they might not know about subnetting).
Actually, even if they don't know the subnet structure before hand, they
will discover this, as far as is relevent to smurfing, when they perform
a smurf scan on their own CIDR blocks. Any address that results in
multiple smurf type echo replies from different addresses would be
considered a broadcast address; any that didn't, wouldn't.
And, of course, any ISP should always inform their downstream contacts
of any filtering which affects packets to/from their downstream network
(no matter how standard) and this information should be propagated
downward (possibly excluding details of the firewall protecting
the ISPs servers provided that that firewall is not inline for
packets between the downstream and either upstream, peers, or
other downstreams).
> downstream network blocks only. But at the same time you should *DEMAND*
> that the downstream customer's router vendor fix their broken equipment or
> else advertise that it is suitable only for use on networks that are not
> interconnected with the Internet.
Indeed.
In the following comments, "firewall" will refer to a packet filtering
box, not a proxy box. In a separate message, in private email, another
participant, Marc Slemco, pointed out that IP fragment reassembly by a
router is contrary to RFC 1812 and dangerous in some situations because
the fragments could take separate routes. So, I would consider the
following conditions to be necessary before one used fragment reassembly:
- The firewall in question is the only route in or out of
a network (i.e. if there are multiple links they all come
to the same box).
- An exception to the above rule could, perhaps, be granted,
if all the firewalls protecting a multiply connected leaf network
were programmed to behave in such a way that fragments which
took multiple routes were sent to the same box to be reassembled.
One still needs to consider what happens when one of the boxes is
down. One also needs to be careful, from a security perspective, that
the method of relaying fragments does not cause them to be mistaken for
traffic originating inside; simply "routing" all fragments which arrive
at firewall1 and firewall2 to firewall0 (or using a hash) would not be
acceptable (unless you had a dedicated fragment network), some form
of encapsulation would be needed.
- And the deviation from RFC-1812 was well documented, preferably
somewhere readily accessable from both inside and outside the protected
network. Actually, I would like to see a RFC for using DNS
to associate (perhaps using text records) a URL to a WEB page
which documents any ideosyncracies of any given router with
the canonical forward DNS entry for that router. That way,
there would be a consistent way to document broken hardware
or hardware which had to, for some reason, deviate from the RFC's.
I.e., you MUST not do this, but if you do it anyway, you MUST
confess :-). And confession should not be confused with absolution.
[Another pet peeve: people who fail to include reverse address
DNS records for their router addresses. It is so easy to do
(http://www.dbd.com/~whitis/temp/dns/makerev.c) ].
It is also possible, I suspect, if you have multiple links, for some
packets to be consistenly fragmented and the fragments routed consistently
over multiple routes (based on size or some other criteria) including
one which was down so that you received (consistently) some but not all
fragments for a while. Combination of retransmission, fragmentation,
and multiple routes could conceivably even conspire to produce
hostile DoS style improperly fragmented packets entirely by accident
(i.e. the overlapping fragment style); this is regardless of whether you
reassemble packets at your firewall(s).
But if you are protecting a leaf network with a firewall, I still do think
you should normally reassemble packets at the firewall; you simply cannot
trust all the different stacks inside the firewall in most situations.
But conformance with RFC-1812 is likely to mean you have to
have a single firewall (a single point of failure, possibly
with an offline backup) between the protected organization and all
outside connections or that some new code be written.
---------------------------------------------------------------------------
--- Mark Whitis <[email protected]> WWW: http://www.dbd.com/~whitis/ ---
--- 428-B Moseley Drive; Charlottesville, VA 22903 804-962-4268 ---
---------------------------------------------------------------------------
|