[fw-wiz] Why blocking bogons buys you nothing

From: Mikael Olsson (mikael.olsson_at_clavister.com)
Date: 10/31/03

  • Next message: Claussen, Ken: "RE: [fw-wiz] Odd PIX / router behavior" 
    To: fw-wiz <firewall-wizards@honor.icsalabs.com>
Date: Fri, 31 Oct 2003 02:27:37 +0100

    I was meaning to post this writeup to various places back in May
    when I wrote it, but I completely forgot. Don't ask me why.

    ---8<---

    Why Blocking Bogons Buys You Nothing
    ------------------------------------

    By Mikael Olsson <mikael.olsson@clavister.com>, 2003-05-24.

    It appears to be "common knowledge" that blocking bogon networks
    is somehow a good thing. Here are my experiences on the matter.

    On 2003-05-22, the following /8 networks between 1 and 223 are
    IANA reserved according to the ARIN whois database:

      1, 2, 5, 10, 14, 23, 27, 31, 36, 37, 39, 41, 42, 46, 49, 50, 58, 59,
      70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 83, 84, 85, 86, 87, 88, 89,
      90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105,
      106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119,
      120, 121, 122, 123, 124, 125, 126, 127, 173, 174, 175, 176, 177, 178,
      179, 180, 181, 182, 183, 184, 185, 186, 187, 189, 190, 197, 223

    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.

    I decided to take a look at them.

    What I looked at
    ----------------

    I narrowed down the scope to the logs of the main gateway cluster;
    52GB gzipped -- 600GB uncompressed and about 2 750 000 000 events.

    I extracted all events (dropped packets, statelessly forwarded packets,
    and statefully tracked connections) with a source IP belonging to the
    above series, excluding the 10 network which is in use locally, that
    arrived at the external interface of the gateway.

    During this time, we've experienced one DDOS attack that actually hurt,
    and a couple of smaller ones that basically only showed up as blips in
    the logs. The logs also cover the SQL Slammer worm event, from its rise
    to its current levels, four months later.

    The results
    -----------

    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.

    Now, couple this with the fact that the log events involving bogons are
    mostly drops, which occur once per dropped packets. The bulk of the REST
    of the (non-bogon) log data is statefully tracked connections opening and
    closing, and transferring anywhere between a few kbytes to several giga-
    bytes in between, and you can begin to guess at the actual data ratio.

    The log data, with the uninteresting fields stripped out, is available:
    http://www.clueby4.org/pubs/bogons.log.gz [118KB]

    Activity summary per /8 network
    -------------------------------

    Note that blocks with fewer than five events have
    been excluded from this listing.

        1/8: 629 events
        2/8: 65 events
        5/8: 47 events
       14/8: 25 events
       23/8: 37 events
       27/8: 26 events
       31/8: 736 events
       36/8: 19 events
       37/8: 40 events
       39/8: 6 events
       41/8: 10 events
       49/8: 5 events
       50/8: 10 events
       58/8: 5 events
       70/8: 384 events
       84/8: 23 events
       88/8: 5 events
       89/8: 821 events
       90/8: 735 events
       91/8: 32 events
       92/8: 350 events
       95/8: 12 events
       96/8: 5 events
       97/8: 9 events
       98/8: 328 events
       99/8: 5 events
      100/8: 5643 events
      101/8: 663 events
      103/8: 23 events
      105/8: 15 events
      110/8: 621 events
      111/8: 41 events
      113/8: 8 events
      116/8: 5 events
      120/8: 566 events
      123/8: 126 events
      125/8: 2993 events
      126/8: 17 events
      127/8: 557 events
      173/8: 8 events
      174/8: 5 events
      175/8: 119 events
      176/8: 52 events
      177/8: 162 events
      178/8: 1735 events
      179/8: 58 events
      180/8: 20 events
      181/8: 53 events
      182/8: 30 events
      185/8: 5 events
      190/8: 1222 events
      197/8: 92 events
      223/8: 37 events

    Activity summary per destination port and protocol
    --------------------------------------------------

    Note that single ports with fewer than 10 events
    have been excluded from this listing.

      TCP 21: 37 events
      TCP 80: 171 events
      TCP 139: 2112 events
      TCP 445: 16 events
      TCP 1074: 10 events
      TCP 1100: 14 events
      TCP 1214: 109 events
      TCP 1433: 379 events
      TCP 2030: 24 events
      TCP 2043: 10 events
      TCP 2893: 10 events
      TCP 3419: 21 events
      TCP 3866: 15 events
      TCP 3889: 10 events
      TCP 3940: 25 events
      TCP 6346: 28 events
      TCP 6698: 22 events
      TCP 6699: 18 events
      TCP 11211: 16 events
      TCP 64641: 11 events

      UDP 137: 13244 events
      UDP 1434: 69 events
      UDP 3866: 17 events

      ICMP DEST_UNREACH: 466 events
      ICMP ECHO_REPLY : 1405 events
      ICMP TIME_EXCEED : 129 events

    Conclusion
    ----------

    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.

    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
    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.

    I won't be installing blocks for unassigned networks any time soon.

    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.

    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.

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

    ---8<---

    This is also available on
    http://www.clueby4.org/pubs/blocking-bogons.txt

    Posted here in its entirity because noone bothers to click URLs :) 

    -- 
Mikael Olsson, Clavister AB
Storgatan 12, Box 393, SE-891 28 ÖRNSKÖLDSVIK, Sweden
Phone: +46 (0)660 29 92 00   Mobile: +46 (0)70 26 222 05
Fax: +46 (0)660 122 50       WWW: http://www.clavister.com
_______________________________________________
firewall-wizards mailing list
firewall-wizards@honor.icsalabs.com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
  • Next message: Claussen, Ken: "RE: [fw-wiz] Odd PIX / router behavior"

    Relevant Pages