North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: SMURF amplifier block list

  • From: Phil Howard
  • Date: Sat Apr 18 16:45:05 1998

Dean Anderson writes...

> >> During an in progress attack, you probably have to take extreme measures,
> >Do you remember - it's not attack against you or attack by some of your
> >customer's networks used as amplifier, but the attack initiated from your
> >own network. You never note such thing withouth some permanent
> >measurement.
> Oops. I misunderstood this first time round.  I don't think you can easily
> detect smurf initiations, because you have to guess at the broadcast
> address.
> I think it is much easier to detect and block forged source addresses,
> which are also necessary for the hacker who is operating out of your
> network.

A combination of ...

1.  blocking outbound packets with sources not in your own networks

2.  blocking inbound packets addressed to broadcast addresses you know
    you have in your subnetting topology

3.  blocking inbound echo_request

4.  blocking outbound echo_reply

... would be a good start.  It breaks things like outsiders pinging your
network, but many find this an acceptable compromise.  I've done #1, #3
and #4 for over 4 years.  I plan to add #2 shortly, not only at the main
gateways, but also for all RADIUS based dialups, whether LAN or not.  I
already block outbound packets to port 25, except allow them to my mail
servers, for all but customers who run their own mail servers, via RADIUS,
for purposes of blocking spam relaying.  Of course that won't stop it all,
but it does stop most, including the naive.

I have no plans to block outbound packets to addresses ending in .255.

I'd love to be able to:

5.  block inbound packets with sources I have no routes for

6.  block inbound packets with sources that came in over an interface that
    such a source could not route to if it were a destination

Phil Howard | [email protected] [email protected] [email protected]
  phil      | [email protected] [email protected] [email protected]
    at      | [email protected] [email protected] [email protected]
  milepost  | [email protected] [email protected] [email protected]
    dot     | [email protected] [email protected] [email protected]
  com       | [email protected] [email protected] [email protected]