Re: [fw-wiz] Why blocking bogons buys you nothing

From: Andrea Pasquinucci (cesare_at_ucci.it)
Date: 10/31/03

  • Next message: Melson, Paul: "RE: [fw-wiz] Odd PIX / router behavior" 
    To: fw-wiz <firewall-wizards@honor.icsalabs.com>
Date: Fri, 31 Oct 2003 11:50:18 +0100 (CET)

    I perfectly agree, at least from a practical point of view. I would like
    to add only a couple of comments:

    - from a theoretical point of view, you would like to filter all traffic
    entering (and exiting) your network allowing only source addresses which
    have a chance to correspond to a real host

    - DDoS, attacks etc. will of course use assigned addresses so to have more
    possibilities to succeed

    - filtering on "IANA reserved" blocks requires to check almost daily if
    the block has been assigned to someone (I have personal experience with
    cases where these filters have been setup, but then there was not time to
    check the IANA list, and all of a sudden customers where complaining that
    they could not reach some web site...)

    - if you cannot/don't want to do also this work of checking, filter 0/8,
    127/8, 224/3 as you say, but I would also obviously add 172.16/12 and
    192.168/16 (true, you considered /8 only), and the risk/work/pain balance
    would be in your favour

    - I would think that is more important to have egress filtering to the
    internet than to filter on "IANA reserved" blocks

    Andrea

    PS. these filters on "IANA reserved" blocks now are also added as optional
    command in some routers/firewalls etc, with a static list of X
    months/years ago and a warning that the list could be old...

    > Date: Fri, 31 Oct 2003 02:27:37 +0100
    > From: Mikael Olsson <mikael.olsson@clavister.com>
    > To: fw-wiz <firewall-wizards@honor.icsalabs.com>
    > Subject: [fw-wiz] Why blocking bogons buys you nothing
    >
    >
    > 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.
    >

    [ ... snip ... ]

    >
    >
    > 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 :)
    >
    >

    _______________________________________________
    firewall-wizards mailing list
    firewall-wizards@honor.icsalabs.com
    http://honor.icsalabs.com/mailman/listinfo/firewall-wizards

  • Next message: Melson, Paul: "RE: [fw-wiz] Odd PIX / router behavior"

    Relevant Pages

    • Re: March 29, 2006 total eclipse - IT admins WORST NIGHTMARE
      ... and NewsProxy is the answer for that. ... > Comcast news server. ... simply filters out what I dont want on the network. ... NewsProxy - Network level killfile and content filter for Usenet. ...
      (comp.security.firewalls)
    • DirectShow Filter (COM Issues)
      ... I am trying to write a DirectShow filter to allow a programmer to send data ... DS Network Sender.CPP: ... CNetworkSenderFilter::CNetworkSenderFilter(TCHAR *tszName, LPUNKNOWN pUnk, ... HRESULT CNetworkSenderFilter::CheckMediaType{ ...
      (microsoft.public.win32.programmer.ole)
    • Re: FIREWALL CHECK
      ... at all (windows firewall). ... The job of a real FW, which I don't consider some 3rd party personal FW/packet filter or even Vista's FW/packet filter to be a FW is not to stop malware. ... A packet filtering FW router, FW appliance or host based software FW running on a secured gateway computer jobs are not to be stopping a malware program running on some computer. ... In either case, it must have at least two network interfaces, one for the network it is intended to protect, and one for the network it is exposed to. ...
      (microsoft.public.windows.vista.security)
    • Re: Network source filter
      ... I need to use/develop a network source filter, ... for mpeg2 transport stream. ... I am currently using existing DSNet filter, ... I am not sure if it is because of buffer constraints in the DSNet ...
      (microsoft.public.win32.programmer.directx.video)