Then you could also just get a connection to team cymru's bogon servers.
Works Perfectly for us. I have been peering with them from our sink
hole/black hole trigger router, for a while now, and I no longer need to
manually update the files.
More info here.
http://www.cymru.com/BGP/bogon-rs.html
Regards,
Mark
Any of IBM people on list? NOC email and phone is not good. I am trying
to get 72.1.1920.19 off their Bogon filtering for 2 weeks now without
any luck. If someone has a contact that can at least point me in the
right direction it will be much appreciated.
Regards,
Majid Farid
Telecom Ottawa Limited.
I do as well, but does this scale? Can Team CYMRU handle 2,000 BGP
sessions? 20K? 200K? -Hank
Hi, Hank.
] I do as well, but does this scale? Can Team CYMRU handle 2,000 BGP
] sessions? 20K? 200K? -Hank
We can handle quite a lot of sessions, and already do, thanks to
the distributed nature of the Bogon route-server project. We
have several routers deployed, and are prepared to deploy more
if necessary.
By the way we recommend that folks peer with at least two of the
Bogon route-servers.
Thanks,
Rob.
Hi Rob,
I have one question regarding the CYMRU bogon route-server. What good is
it if more-specific bogons are going around in the BGP table ?
With OpenBSD 3.6 running pf and bgpd, you can apply a filter rule to BGP updates received from individual peers which updates a pf radix table with the network received:
# team cymru bogon route servers
group "bogons" {
remote-as 65333
local-address A.B.C.D
multihop 64
announce none
max-prefix 1000
tcp md5sig password "xxsomethingxx"
neighbor E.F.G.H
neighbor I.J.K.L
}
# cymru set 65333:888 on bogon routes
allow from any community 65333:888 set pftable "bogons"
allow from any community 65333:888 set nexthop blackhole
This allows you to block inbound/outbound packets in the packet filter, and not just rely on blackhole routing (I left the "nexthop blackhole" policy statement in there to provide some coverage in case I accidentally disable pf one day due to caffeine deficiency). The pf config bits are:
table <bogons> persist
# no bogon sources or destinations
block quick from <bogons> to any
block quick from any to <bogons>
This seems to work very nicely, and neatly accommodates the problem of what to do with packets which follow more-specific routes of the cymru bogon supernets. The rules above would probably need to be loosened somewhat for a network which used 1918 addresses and NAT, since the 1918 addresses are included in the bogon feed.
This is an answer that is probably not useful for the average ISP backbone, but I tried it out a week or so ago on my home network firewall/router boxes, and it works very nicely. It's a good solution for (say) an enterprise network whose external traffic falls within the bounds of what an OpenBSD box can handle (or boxes, if you do stateful failover with CARP and pfsync).
Joe
>I have one question regarding the CYMRU bogon route-server. What good
>is
>it if more-specific bogons are going around in the BGP table ?With OpenBSD 3.6 running pf and bgpd, you can apply a filter rule to
BGP updates received from individual peers which updates a pf radix
table with the network received:
Interesting, but no option on Juniper/IOS boxes/foundry boxen.
This is an answer that is probably not useful for the average ISP
backbone, but I tried it out a week or so ago on my home network
firewall/router boxes, and it works very nicely. It's a good solution
for (say) an enterprise network whose external traffic falls within the
bounds of what an OpenBSD box can handle (or boxes, if you do stateful
failover with CARP and pfsync).
Indeed, for such purposes it's a nice solutions.
PF and bgpd with local filter table is good when you're expecting those
filtered ip routes to change often. But this is not true about bogons
which for cymru IANA-only data changes couple times a year and for
completewhois full RIR bogon changes once/day. Both of those are not
often enough that updating firewall filters from active bgp session is
worth it, its easier to just download list of bogons once/day or once/week
from web or ftp and update local rules.
Completewhois webpage on how to use our bogon data has all the scripts for
doing bogon firewall filtering on Linux, FreeBSD and OpenBSD machines,
see http://www.completewhois.com/bogons/using_bogon_lists.htm
william(at)elan.net wrote:
I have one question regarding the CYMRU bogon route-server. What good is
it if more-specific bogons are going around in the BGP table ?
With OpenBSD 3.6 running pf and bgpd, you can apply a filter rule to BGP updates received from individual peers which updates a pf radix table with the network received:
PF and bgpd with local filter table is good when you're expecting those
filtered ip routes to change often.
I dont understand this attitude. Automating everything that is safely automatable is the only right way to do things. Its always worth it and it is always good. Everyone has always professed to believe in this.
In this case this is the exact cause of the problem the thread started addressing: Manual updates that dont keep up.
Once upon a time this was the argument of sendmail access database V. dnsbls. Once upon a time you were expected to manually update virus definitions. Once upon a time you were expected to etc.. the list goes on.
Every "weekly" task an admin takes on manually adds up. It may be great job insurance but it starts to suck quick for anyone with half a brain.
Now to throw some whacky ideas out instead of opinions.
I think that a BGP mechanism to tag routes as "ignore all more specifics" would solve this problem nicely. (and perhaps a whole lot others -- such as needless deaggregation)
As far as router vendors such as Cisco autosecure, I do not think there is any way to make default access lists lossless. They should step up to the plate and offer md5 by system serial number keyed multihop BGP bogons in the manner of cymru. Its their responsibility. Also good that it makes them eat even more of their own dogfood which is probably ill suited to this kind of thing.
They should ask team cymru to help them do it and give them a nice fat check while they are at it.
Failing that they could offer radius/tacaccs loading of that access list. Anything else is negligence.
And using BGP for /32 blacklist routes probably has very limited scalability. Any one have any relevant numbers?
Everybody who posts lists of static access lists should seriously consider stopping. If not that, offer an email subscription to announce updates.
(think I beat the S:N? --even if my S is nonsense?)
Joe
Ok, I guess I did not read original post closely enough. PF is for
reinjecting routes that match local rules back into bgp, right?
If so I apologize, I though it was talking about taking bgp data
and using it to filter local servers....
For looking at active routes and seeing which ones match the rules I
personally use "hacked" bird daemon, but it is not ready for public
testing...
Hi, Cliff.
] I have one question regarding the CYMRU bogon route-server. What good is
] it if more-specific bogons are going around in the BGP table ?
At present, none. We have feature requests into some major router
vendors to make this more useful. The goal is to provide a syntax
similar to prefix-list that would permit you to filter on a prefix
and anything more specific. Stay tuned!
Thanks,
Rob.
Indeed, that's the biggest problem at the moment. I have seen some folks
feature requesting this at juniper, but seems they all got a big NO
back.
Cliff Albert wrote:
>>
I have one question regarding the CYMRU bogon route-server. What good is it if more-specific bogons are going around in the BGP table ?
With OpenBSD 3.6 running pf and bgpd, you can apply a filter rule to BGP updates received from individual peers which updates a pf radix table with the network received:
Nice - anyone know of anything equivalent for ipf/pfil on Solaris?
Interesting, but no option on Juniper/IOS boxes/foundry boxen.
Since 12.0(29)S and 12.2(25)S, this feature:
BGP Support for IP Prefix Import from Global Table into a VRF Table
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120s/120s29/cs_bgivt.htm
does the trick nicely, as long as you trust builds that new,
and your linecards are new enough. Worked fine in my testing.
This is effectively a way of populating a VRF and then pointing uRPF at
it. I think it was aimed at feasible path uRPF, but can do the bogon
stuff as well.
I think that a BGP mechanism to tag routes as "ignore all more specifics" would solve this problem nicely. (and perhaps a whole lot others -- such as needless deaggregation)
Yeah, like people who are needlessly deaggregating are going to send out an aggregate with this tag on it...
What you want is a way to inject filters into a box remotely with live updating. So this is what the vendors should build.
As far as router vendors such as Cisco autosecure, I do not think there is any way to make default access lists lossless. They should step up to the plate and offer md5 by system serial number keyed multihop BGP bogons in the manner of cymru. Its their responsibility.
Why?
Why should anyone bother?
Why are we even discussing this?
The whole point that started this discussion is that bogon filtering is HARMFUL a good part of the time. And it doesn't really do anything useful to begin with! You get to reject packets from dark address space, but:
- That's only some 40% of all address space, so you need to be able to deal with the other 60% anyway. Why wouldn't whatever mechanism that deals with the 60% be unable to deal with the additional 40%?
- (Loose) uRPF will buy you the exact same functionality and more without any upkeep.
Hi, NANOGers.
] - That's only some 40% of all address space, so you need to be able to
] deal with the other 60% anyway. Why wouldn't whatever mechanism that
] deals with the 60% be unable to deal with the additional 40%?
In a study of one oft' scanned and attacked site, we found that
66.85% of the source IPs were bogon (RFC1918, unallocated, etc.).
You can read about it at the following URL:
<http://www.cymru.com/Presentations/60days.ppt>
Filtering out bogons removes yet one more potential source of
badness. Does it remove all badness? Of course not. We win
by degrees. Removing any tool from the bad persons' toolkit is
useful.
Those who track backscatter (the detritus of a spoofed source
attack) are still seeing a healthy bit of traffic. While
spoofing is less popular than it once was, it still remains a
viable attack feature. Tools such as bang.c depend entirely on
the ability to spoof. Not all spoofing uses bogon IP space.
That's fine, we can reduce the alternatives bit by bit.
Dealing with the other sources of badness is an exercise for
other ideas. The Darknet Project is one such way to spot that
badness.
<http://www.cymru.com/Darknet/>
How you choose to respond to that badness (report it to the
source, report it to their upstreams, null route them, do
nothing) is of course up to you.
] - (Loose) uRPF will buy you the exact same functionality and more
] without any upkeep.
Even with uRPF one needs to keep the RIB clean. That means the
use of filtering. We and others provide those as well:
<http://www.cymru.com/Documents/secure-bgp-template.html>
<http://www.cymru.com/gillsr/documents/junos-bgp-template.htm>
<ftp://ftp-eng.cisco.com/cons/isp/security/Ingress-Prefix-Filter-Templates/>
Thanks,
Rob.
>PF and bgpd with local filter table is good when you're expecting those
>filtered ip routes to change often.
>
I dont understand this attitude. Automating everything that is safely
automatable is the only right way to do things. Its always worth it and
it is always good. Everyone has always professed to believe in this.
I completely agree about automatic updates. I just want to point out that
for data that rarely changes and where such changes can easily be
accomodated when distributed within 24 hours using BGP (which is
designed for rapid updates of routing data) is an overkill.
In this case this is the exact cause of the problem the thread started
addressing: Manual updates that dont keep up.Once upon a time this was the argument of sendmail access database V.
dnsbls. Once upon a time you were expected to manually update virus
definitions. Once upon a time you were expected to etc.. the list goes on.
And look at virus defenitions - they do not get distributed immediatly
to end-sites like BGP, instead local systems check with remote server
once/day or once/week and automaticly download new definitions.
Every "weekly" task an admin takes on manually adds up. It may be great
job insurance but it starts to suck quick for anyone with half a brain.
Look at the webpage I listed, it mentiones several times that updates
must be made automaticly (or otherwise you should not bother) and includes
scripts that automaticly recreate firewall scripts every week or every
day from the downloaded ip list.
As far as router vendors such as Cisco autosecure, I do not think there
is any way to make default access lists lossless. They should step up to
the plate and offer md5 by system serial number keyed multihop BGP
bogons in the manner of cymru. Its their responsibility. Also good that
it makes them eat even more of their own dogfood which is probably ill
suited to this kind of thing.
Or they could offer service to update relevent ios security config
(including access-list) from remote server once/day/week. This would
be a lot easier then forcing everyone who needs this do bgp feed
and it also takes care of security updates that require more then
just updating one specific access-list.
Just FYI --
Team Cymru also provides IRR objects for those using automated BGP policies
with ease. Using IRR objects, dependent on how *you* set it up, you should be
able to filter out specifics.
Their object is fltr-bogons on whois.radb.net:
filter-set: fltr-bogons
descr: All bogon IPv4 prefixes.
filter: fltr-unallocated OR fltr-martian
tech-c: RTH32-ARIN
admin-c: RTH32-ARIN
mnt-by: MAINT-BOGON-FILTERS
changed: radb@cymru.com 20040420
source: RIPE
Example for filtering bogons from transit:
import: from AS209 accept ANY and not fltr-bogons
I make use of these objects for configuring BGP for customers who are multihomed
to different ISP's, so far with great success.
Hope this helps,
-J
Hi, NANOGers.
Hello,
] - That's only some 40% of all address space, so you need to be able to
] deal with the other 60% anyway. Why wouldn't whatever mechanism that
] deals with the 60% be unable to deal with the additional 40%?In a study of one oft' scanned and attacked site, we found that
66.85% of the source IPs were bogon (RFC1918, unallocated, etc.).
You can read about it at the following URL:<http://www.cymru.com/Presentations/60days.ppt>
Filtering out bogons removes yet one more potential source of
badness. Does it remove all badness? Of course not. We win
by degrees. Removing any tool from the bad persons' toolkit is
useful.
Does it really?
When I perform any type of change the most important thing for me isn't
what it will prevent/help for but the opposite; What it will not prevent/help.
Blocking bogons will result in that attackers use existing netblocks
instead. This will again result in more insecureness since any attack will
have source addresses within valid space and some people will find it
harder to determine the real sources, atleast in the beginning.
So any type of bogon filter like that seems to me a total waste of time.
It does not really prevent anything in the long run.
You may have taken the can-opener away from this bad person, but you don't
really need a can-opener to open the beer anyway... correct me if I'm
wrong.
Joergen Hovland ENK
If the people making attack code would stay out of 224.0.0.0/4 space (both
for dest and src) it would be a big improvement.
And if the people making attack code were forced to use real IP address, or, put another way, if you could guarantee that the source IP address on an attack packet was the actual source of the attack, it would help in tracking attacks.
Before you say "we know where bot-net attacks are originating, but cannot get them to stop", that is another problem. As Rob said, problems are solved in steps, not with one wave of the magic wand. And saying "step one won't solve the problem so we shouldn't even start" is not, IMHO, a good idea.