Hi,
There are ways to add static routes that can be blackholed. I can
understand the utility of such routes if those are installed in my
forwarding table. What bewilders me is why would anyone want to
advertise "blackhole" routes using say, BGP?
Is it only to prevent some sort of DoS attacks or are there other uses
also of advertising black hole routes?
Thanks,
Abhishek
Abhishek Verma wrote:
There are ways to add static routes that can be blackholed. I can
understand the utility of such routes if those are installed in my
forwarding table. What bewilders me is why would anyone want to
advertise "blackhole" routes using say, BGP?Is it only to prevent some sort of DoS attacks or are there other uses
also of advertising black hole routes?
Look at the way the MAPS RBL started.
Anybody else who trusts your judgement of what traffic to blackhole can take a bgp feed of the blackhole routes and use it.
There are several sources of eBGP feeds for blackholing, they can be very useful
depending on what your requirements are. You can get feeds for spam, ddos bots,
bogon routes etc
For iBGP this can be useful too, if you are being DDoS'd you can inject an iBGP
route and have all your routers instantly blackhole traffic at your edge instead
of having to static config all of them..
regards
Steve
There are ways to add static routes that can be blackholed. I can
understand the utility of such routes if those are installed in my
forwarding table. What bewilders me is why would anyone want to
advertise "blackhole" routes using say, BGP?
Have you read the presentation from the Feb. NANOG?
http://www.nanog.org/mtg-0402/morrow.html
All the presentation pages on the NANOG website have Merit's
address at the bottom so when I google for this kind of stuff
I use a query like the following to get a shortlist with
mostly relevant pages.
"4251 Plymouth Road" blackhole
--Michael Dillon
We use Blackholing extensively to protect our campus network from "bad"
machines. I did a writeup (replete my own personal brand of braindead
typos) a while back that details out how we set it up using OSPF and uRPF.
http://www.merit.edu/mail.archives/nanog/2003-11/msg00225.html
There are mechanisms to do it using eBGP and communities as well which I'm
sure most on this list are more familiar with.
Think of blackholing as a way to surgically remove a specific IP from your
network, without having to deal with pushing ACLs into multiple entry
points. At least that's what it accomplishes for us.
Robert Hayden
Univeristy of Wisconsin Madison
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
====================== NEW Materials =========================
Powersession on Core Security (4-6 May 2004)
http://www.ciscoeventreg.net/go/networkers/agenda9.lasso
CPN Summit SP Security Materials (April 2004)
ftp://ftp-eng.cisco.com/cons/isp/security/CPN-Summit-2004/
====================== Public Materials ========================
SP Security Materials
- ----------------------
Public On-Line ISP Security Bootcamp - Singapore Summer 2003
http://www.getitmm.com/bootcampflash/launch.html
Sign-On:
http://palomar.getitmm.com/bootcamp/
Much of the materials presented in the ISP Security Bootcamp builds
on and assumes a basic understanding of the principles in the ISP
Essentials materials. This whitepaper is now a book - ISP Essentials
which can be purchased through Cisco Press
(http://www.ciscopress.com/) or through another on-line book store.
The supplements for the book along with the tutorials, workshops, and
bootcamps presented by Philip and I are at:
or
TEAM CYMRU Templates and Tools
- ------------------------------
Team CYMRU provides configuration templates, security templates, and
other services to help make the Internet a safer place to network.
These can be found at:
The Original Backscattered Traceback and Customer Triggered Remote
Triggered Black Hole Techniques
- ----------------------------------------------------------------------
- ---------------------------
http://www.secsup.org/Tracking/
http://www.secsup.org/CustomerBlackHole/
What is a BOTNET?
- -----------------
One of the best write ups is from a freeware tool gone commercial (I
guess so they can scale).
http://swatit.org/bots/index.html
BGP 'Attack Tree' - Realities of BGP Security
- -------------------------------------------
Cisco's CIAG Team moves beyond the armchair hypothesizing of BGP
Security Risk and runs test again the industry's multiple
implementations of BGP
http://wwwin-people.cisco.com/sean/ciag-bgp-blackhatv2.pdf
Communities of People Working Together to Mitigate Miscreant
Activities
- ----------------------------------------------------------------------
- -
+ Distributed Detection Systems Individuals and Organizations can
Participate:
Dshield - www.dshield.org
My Netwatchman - www.mynetwatchman.com
NANOG SP Security Seminars and Talks
- -------------------------------------
The NANOG Coordination Committee actively works to product sessions
and seminars to help foster security on the Internet. All sessions
are taped and converted to VOD for all to use for their personal
education. Over time, this effort has generated a valuable On-Line
Tutorial for engineers and organzations seeking to learn more about
running a more secure network.
NANOG Security Tutorial Series
Tutorial: Implementing a Secure Network Infrastructure (Part I)
http://www.nanog.org/mtg-0310/kaeo.html
Tutorial: ISP Security - Real World Techniques I - Remote Triggered
Black Hole Filtering and Backscatter Traceback.
http://www.nanog.org/mtg-0110/greene.html
Tutorial: ISP Security - Real World Techniques II - Secure the CPE
Edge
http://www.nanog.org/mtg-0210/ispsecure.html
Tutorial: ISP Security: Deploying and Using Sinkholes
http://www.nanog.org/mtg-0306/sink.html
Tutorial: Deploying IP Anycast
http://www.nanog.org/mtg-0310/miller.html
NANOG Security Sessions
Watching Your Router Configurations and Detecting Those Exciting
Little Changes
http://www.nanog.org/mtg-0310/rancid.html
Building a Web of Trust
http://www.nanog.org/mtg-0310/abley.html
The Relationship Between Network Security and Spam
http://www.nanog.org/mtg-0310/spam.html
Simple Router Security, What Every ISP Router Engineer Should Know
and Practice
http://www.nanog.org/mtg-0310/routersec.html
Flawed Routers Flood University of Wisconsin Internet Time Server
http://www.nanog.org/mtg-0310/plonka.html
Trends in Denial of Service Attack Technology
http://www.nanog.org/mtg-0110/cert.html
Recent Internet Worms: Who Are the Victims, and How Good Are We at
Getting the Word Out?
` http://www.nanog.org/mtg-0110/moore.html
DoS Attacks in the Real World
http://www.nanog.org/mtg-0110/irc.html
Diversion & Sieving Techniques to Defeat DDoS
http://www.nanog.org/mtg-0110/afek.html
DNS Damage - Measurements at a Root Server
http://www.nanog.org/mtg-0202/evi.html
Protecting the BGP Routes to Top Level DNS Servers
http://www.nanog.org/mtg-0206/bush.html
BGP Security Update
http://www.nanog.org/mtg-0206/barry.html
Industry/Government Infrastructure Vulnerability Assessment:
Background and Recommendations
http://www.nanog.org/mtg-0206/avi.html
A National Strategy to Secure Cyberspace
http://www.nanog.org/mtg-0210/sachs.html
How to 0wn the Internet in Your Spare Time
http://www.nanog.org/mtg-0210/vern.html
ISP Security BOF I
http://www.nanog.org/mtg-0210/securebof.html
The Spread of the Sapphire/Slammer Worm
http://www.nanog.org/mtg-0302/weaver.html
ISP Security BOF II
http://www.nanog.org/mtg-0302/securebof.html
The BGP TTL Security Hack
http://www.nanog.org/mtg-0302/hack.html
Security Considerations for Network Architecture
http://www.nanog.org/mtg-0302/avi.html
Lack of Priority Queuing on Route Processors Considered Harmful
http://www.nanog.org/mtg-0302/gill.html
Interception Technology: The Good, The Bad, and The Ugly!
http://www.nanog.org/mtg-0306/schiller.html
The NIAC Vulnerability Disclosure Framework and What It Might Mean to
the ISP Community
http://www.nanog.org/mtg-0306/duncan.html
Inter-Provider Coordination for Real-Time Tracebacks
http://www.nanog.org/mtg-0306/moriarity.html
ISP Security BOF III
http://www.nanog.org/mtg-0306/securitybof.html
S-BGP/soBGP Panel: What Do We Really Need and How Do We Architect a
Compromise to Get It?
http://www.nanog.org/mtg-0306/sbgp.html
BGP Vulnerability Testing: Separating Fact from FUD
http://www.nanog.org/mtg-0306/franz.html
BGP Attack Trees - Real World Examples
http://www.nanog.org/mtg-0306/hares.html
NRIC Best Practices for ISP Security
http://www.nanog.org/mtg-0306/callon.html
RIPE-46 NSP Security BoF
- ------------------------
RIPE-46 BoF: NSP-SEC (Hank Nussbacher)
http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-nspbof-
nsp-sec.pdf
IRT Object in the RIPE Database (Ulrich Kiermayr)
http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-nspbof-
irt.pdf
Operational Security Requirements (George M. Jones)
http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-techsec
- -ops-security.pdf
Infrastructure Security (Nicholas Fischbach)
http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-nspbof-
fischbach.pdf
===================== End Public Materials =========================
We use a variation of this for several things. At the risk of getting in to
political policy discussions ...
We have a PERL script which looks for the wildcard .com record. If it finds
it (the old Verisign SiteFinder), it injects a blackhole route to kill it.
Also, we periodically pull in (every 4 hours), allocations from various
registries like ARIN, APNIC, LACNIC, etc. and filter by country. It isn't
elegant, but it does give us the ability to deny traffic to areas our
policies dictate. Pretty effective for getting rid of spam and the offshore
phishing sites. If you want to argue the political or policy side of doing
this, I really don't have time, but our clients have been happy with it for
two plus years.
What I would to see (and have never researched in depth) is a way to apply
the blackhole routes on a community to port basis (i.e. we set up a specific
BGP community to filter mail, and that community goes to a route map that
kills only port 25, another community applies to a map that kills port 80,
etc). When I have spare time, I may see if there is any way to do that. Of
course by then, IPv6 will be obsolete, so .....
Eric
And perhaps more importantly, when using eBGP blackholing communities,
without DDoS traffic hitting your ingress bandwidth from your upstreams.
ACL's can only filter traffic that's already at your edge, whereas
blackholing allows your upstream to filter it for you throughout his
network, reducing the risk of congested links.
Cheers,
It sounds like you are confusing ideas here...
If BGP is making a forwarding table entry, that's it. Ports are not really considered in forwarding decisions -- or if they are, the box is usually called a Firewall, not a router.
It would be pretty trivial to take the information you are generating and dump them into an IPFW or similar table and filter them that way. It would not be as effective, but you could watch your netflow data and selectively add holes or filters based on abuse of certain IP:port combinations. However, if you can destroy end-to-end connectivity and your customers are happy, I wouldn't change a thing. Its much simpler to debug a blackhole then it is a more selective filter.
Deepak Jain
AiNET
Eric Germann wrote:
Just thinking out loud here... BUT, you could potentially (provided you
had the interfaces and time) re-next-hop certain traffic based on source
or destination address (dest would be easiest, which means catching
syn-ack and discarding it to drop the sessions as embryos) and filter out
'bad' stuff in a more centralized manner. There are risks with this, of
course, and complications which you'll probably want to avoid in any
decently large network. As Deepak points out though, this is leading down
some very dark paths of midnight-troubleshooting on complex configurations
-Chris
It goes a little further than that these days. Folks are openly
allowing customers to advertize routes with something lika a 666
community which will then be blackholed within their network. So if
you're a service provider with your own blackhole system, you can
easily tie it into your upstream's system and dump the traffic many
hops away from you meaning that the traffic is getting dumped closer
to the source than the destination in a fair number of cases.
It goes a little further than that these days. Folks are openly
allowing customers to advertize routes with something lika a 666
community which will then be blackholed within their network. So if
you're a service provider with your own blackhole system, you can
easily tie it into your upstream's system and dump the traffic many
hops away from you meaning that the traffic is getting dumped closer
to the source than the destination in a fair number of cases.
This is very dangerous however.....
If providers start tying their customer's blackhole announcements to the provider's upstreams' blackhole announcements in an AUTOMATIC process, bad things <tm> are likely to happen. What happens when a customer of a provider mistakenly advertises more routes than he should [lets say specifics in case #1] you can flood your upstreams' routers with specifics and potentially cause flapping or memory overflows...
In case #2, presumably the blackhole community takes precedence, so if a customer is mistakenly readvertising their multihome provider's table with a 666 tag, all of the upstream providers might be blackholing the majority of their non-customer routes.
Non-automatic tying of customer blackholes to upstream or peer blackholes is a powerful tool to improve the stability of the net as a whole.
Deepak Jain
AiNET
>It goes a little further than that these days. Folks are openly
>allowing customers to advertize routes with something lika a 666
>community which will then be blackholed within their network. So if
>you're a service provider with your own blackhole system, you can
>easily tie it into your upstream's system and dump the traffic many
>hops away from you meaning that the traffic is getting dumped closer
>to the source than the destination in a fair number of cases.
>This is very dangerous however.....
If providers start tying their customer's blackhole announcements to the
provider's upstreams' blackhole announcements in an AUTOMATIC process,
bad things <tm> are likely to happen. What happens when a customer of a
provider mistakenly advertises more routes than he should [lets say
specifics in case #1] you can flood your upstreams' routers with
specifics and potentially cause flapping or memory overflows...
Yes, well, in my case, I go through a dedicated server with multi-hop
sessions and set a prefix limit of 25 or so so I don't get bombarded
with 5 billion /32 routes and don't send those routes upstream. (I try
to play nice when possible.) I expect that the upstreams have various
defense mechanisms of their own to protect them against me
misconfiguring my boxes as well. (It only makes sense..)
In case #2, presumably the blackhole community takes precedence, so if a
customer is mistakenly readvertising their multihome provider's table
with a 666 tag, all of the upstream providers might be blackholing the
majority of their non-customer routes.
If the customer does themselves in, thats not something I can really
protect against.
Non-automatic tying of customer blackholes to upstream or peer
blackholes is a powerful tool to improve the stability of the net as a
whole.
Yes, but far too slow when you're getting DOSd off the face of several
planets.
If a customer has a prefix filter, he cannot announce bogus routes.
If every BGP session in your network is protected by a max-prefix
limit, no matter who leaks, the damage will be limited and contained.
If you apply both types of filter to all customers, the worst that
can happen is that one of your larger customers can inject a few
thousand of his own more-specifics into your network before he trips
the max-prefix limit.
Additionally, re: case #1 above, any customer-announced route with
your blackhole community attached should be tagged with NO_EXPORT or
your internal equivalent.
--Jeff
Well I think in most cases, there are some safeguards, in terms of the
number of blackhole prefixes that will be accepted, and the length of
the prefix (i.e., accept no more than 10 blackhole routes, only accept
blackhole routes that are within prefixes the customer is advertising,
only accept prefixes longer than /24).
GBLX's docs on this are at:
https://robin.gblx.net/api/docs/null_route.html
-- one example of a "real life" implementation of such a system.
we can handle most DoS's ourselves, this is the case with a lot/most? upstreams,
we dont automatically forward blackholes upstream
the only time anyone would need to do that is if a particular upstream's
connection was saturated with the DoS.
i'd agree automatically propogating these isnt good practice.. (imho)
Steve
Deepak Jain wrote:
If providers start tying their customer's blackhole announcements to the provider's upstreams' blackhole announcements in an AUTOMATIC process, bad things <tm> are likely to happen. What happens when a customer of a provider mistakenly advertises more routes than he should [lets say specifics in case #1] you can flood your upstreams' routers with specifics and potentially cause flapping or memory overflows...
In case #2, presumably the blackhole community takes precedence, so if a customer is mistakenly readvertising their multihome provider's table with a 666 tag, all of the upstream providers might be blackholing the majority of their non-customer routes.
I build two prefix lists for each customer. One represents the exact match routes that I'm willing to propagate, and the other covers "le 32" more specifics of what I'm willing to allow special treatment on. They can't blackhole anything outside what they would otherwise be allowed to announce (and I use it for several other special cases as well). Customers who are single-homed and otherwise static routed are welcome to use BGP for these special cases; their prefix lists reflect the fact that their space is not to be propagated.
pt
This tends to work better for a variety of reasons. Most importantly, a
dedicated session with a dedicated prefix-list can easily be configured to
accept up to /32s for blackhole routes only, it can easily be configured
to tag all routes received no-export, and it can easily be placed into a
seperate prefix-limit which will not affect production traffic forwarding
if something goes wrong. Also, if you have customers attached to Juniper
routers, you need to have the sessions configured multihop anyways, in
order to turn on the ability to rewrite next-hop.
That said, it is still absolutely silly that we can't standardize on a
globally accepted blackhole community. A provider with many transit
upstreams who wishes to pass on blackhole routes for their customers could
quickly find themselves with some very messy configs and announcements
trying to get everyones' specific blackhole community in place. I know
we've all been tossing this idea around for a number of years, but if it
hasn't been done already will someone please get this put into a draft
already.
> provider mistakenly advertises more routes than he should [lets say
> specifics in case #1] you can flood your upstreams' routers with
> specifics and potentially cause flapping or memory overflows...
>
> In case #2, presumably the blackhole community takes precedence, so if a
> customer is mistakenly readvertising their multihome provider's table
> with a 666 tag, all of the upstream providers might be blackholing the
> majority of their non-customer routes.If a customer has a prefix filter, he cannot announce bogus routes.
true, but not universal, sadly.
If every BGP session in your network is protected by a max-prefix
limit, no matter who leaks, the damage will be limited and contained.
true, also not univeral, sadly. Many networks out there do NOT use any of
these protections...
I'd have to disagree with you. While you and many other networks may be
able to handle most DoS attacks without involving your upstreams, there
are still plenty (the majority I would say) of networks who can't. In
fact, the entire CONCEPT of a blackhole customer community is to move the
filtering up one level higher on the Internet, where it should
theoretically be easier for the larger network to filter. It would be
silly to assume that there is no attack which the person implementing the
blackhole community can not handle, or to assume that there will never be
tier 2/3 ISPs aggregating or reselling bandwidth.
Also, since the point of a blackhole community is to block all traffic to
a destination prefix anyways, it doesn't matter whether the blackhole
takes place 1 network upstream or 10. Any prefix which can be announced
and routed on the global routing table should be able to be blackholed by
every network on the global Internet, using a standard well-known
community. This changes nothing of the current practices of accountability
for your announcements, filtering by prefix length, etc. There would still
remain a clear role for no-export and more specifics upto /32 between
networks who have negotiated this relationship, but there absolutely no
reason you couldn't and shouldn't have global blackholes available as
well.