[fw-wiz] RE: Why blocking bogons buys you nothing (Mikael Olsson)
From: Stephen Gill (gillsr_at_yahoo.com)
To: <email@example.com> Date: Fri, 7 Nov 2003 14:30:03 -0600
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
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 22.214.171.124 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
-- _______________________________________________ firewall-wizards mailing list firstname.lastname@example.org http://honor.icsalabs.com/mailman/listinfo/firewall-wizards