[fw-wiz] RE: Why blocking bogons buys you nothing (Mikael Olsson)

From: Stephen Gill (gillsr_at_yahoo.com)
Date: 11/07/03

  • Next message: Mikael Olsson: "Re: [fw-wiz] Pix 501 configuration question"
    To: <firewall-wizards@honor.icsalabs.com>
    Date: Fri, 7 Nov 2003 14:30:03 -0600

    Hi Michael,

    I'd like to point out a few issues with your report as I tend to disagree
    with it :).

    ] Why Blocking Bogons Buys You Nothing

    This title is misleading. Blocking Bogons buys you a LOT, you just don't
    get to see the benefits because others are doing it for you. This comes in
    the form of Unicast RPF on core routers (loose and strict), BGP Bogon
    Peering (blocking bogon BGP announcements), Spoof filtering, etc...

    I think you mean to say: "Why Blocking Inbound Bogons Buys You Very Little
    on Firewalls"

    I would tend to agree more with that statement. I would rather do it on the
    edge routers further upstream towards the source where the firewall wouldn't
    even see this.

    ] Now, I've got seven months of firewall logs at hand right now,
    ] from a gateway in front of a few dozen class C networks with a
    ] couple of thousand private and corporate users. They total about
    ] 80GB gzipped -- closer to terabyte uncompressed.

    So why are we drawing global conclusions from a _single_ site? What makes
    this location special or a target in that anyone would want to send spoofed
    packets towards your network anyways? The same should be said for traffic
    leaving your network.

    The idea of blocking bogons is to do it as close as possible to the source,
    not the other way around. So someone _else's_ filtering will benefit you.
    In turn, you doing the same thing would benefit others.

    ] The resulting log file was close to five megabytes. Now, compare this to
    ] the full log set size of 600 gigabytes. Log events including "bogon"
    ] source IPs are only 0.00083% of the total amount of log events.

    One could easily argue that part of the benefits you're seeing is because
    _others_ are doing bogon filtering for you and you just don't see it. Many
    DDOS attacks I see still use random spoofed sources. Most DDOS attack data
    points to bogon filtering having a _significant_ impact on reducing the
    overall load reached on the target network.

    As you state, this data only covers one largish DDOS attack. Chances are,
    yes that you will not be attacked very often, most hopefully never. When
    calculating percentages, you should use the traffic during a DDOS only not
    all the data that you see on a regular basis. This gives you an estimate of
    what you're seeing when under attack. Sure, TCP SYN packets are probably
    only .01% of your traffic, but does that mean you don't need them? The
    percentage argument is specious the other way around as well.

    ] Contrary to the common belief that blocking "bogus" source addresses can
    ] somehow protect you against distributed denial-of-service attacks or
    ] otherwise decrease your network load, our seven months of log data
    ] show nothing to support those beliefs.

    Blocking bogon networks doesn't protect you from DDOS attacks, but it does
    drop your network load the further upstream towards the source you go. This
    should be done at the SOURCE, not at the destination as your study suggest.
    If you protect the Internet from spoofing from within your network you are
    also doing the reverse as you state.

    ] Couple this with the fact that the networks commonly dropped as "bogus"
    ] are, in fact, NOT bogus. They're simply not assigned yet. Sooner or

    The term is bogon, not bogus. No one is indicating that these networks are
    "bogus". They are unassigned, as such they should never be seen or routed
    on the public Internet period.

    ] later, some of them will be, and the poor sods that find themselves
    ] assigned such IP addresses will find that parts of the Internet can't
    ] be reached. And vice versas.

    That is why you should never place any of this type of filtering in your
    network if you are not prepared to update it on a regular basis when
    necessary, or have it automated. Automated feeds come in several flavors:


    BGP, DNS, Whois, Radb, HTTP

    Firewalls are generally stateful packet filters and in most cases you can
    get by with filtering everything but traffic sourced form the local
    network's IPs. In most cases it is easy to determine if an egress packet is
    spoofed or not and you can filter appropriately. Thus, there is no need for
    bogon filtering, because you have something MUCH better (outbound).

    For inbound traffic, there is likely less of a benefit to this approach,
    especially if the pipe is full. It doesn't matter how fast the firewall is,
    if the pipe is full it's game over. However, in some cases when the
    firewall can handle the load, and the pipe is not full, and inbound traffic
    is being spoofed from bogon ranges that have not been filtered further
    upstream when they should have been, you may benefit from inbound bogon
    filtering at the firewall.

    ] Blocking the 0/8 network, 127/8 network and 224/3 networks is another
    ] thing altogheter; there are firm technical and security reasons for
    ] doing that.

    There are other networks that will never be part of the global Internet
    routing table, such as but not limited to RFC 1918 space.

    ] Preventing spoofing attacks by making sure that networks known to live
    ] on the inside are not heard on the outside and vice versa is also a very
    ] good idea.

    Certainly... and the preferred method for all. Bogon filtering raises the
    bar for DDOS attacks and requires those that are sending spoofed attacks to
    come from valid networks. Unicast RPF (sometimes combined with bogon
    filtering when in loose mode) raises the bar even higher on core routers.

    ] But you won't find me arbitrarily deciding that whoever has the misfortune
    ] of being assigned two years from now can't connect to my network.

    If you are not prepared to update your configurations then I'm very glad to
    hear that. No one should place any static bogon filters in their network if
    they are not prepared to manage and maintain them. This is certainly why
    automated methods are preferred. Some have developed scripts for firewalls
    to check the bogon networks on a regular basis and update the configuration
    as necessary.

    Stephen Gill

    firewall-wizards mailing list

  • Next message: Mikael Olsson: "Re: [fw-wiz] Pix 501 configuration question"