RE: How many backbones here are filtering the makelovenotspam scr eensaver site?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
-----Original Message----- From: Justin Ryburn [mailto:justin@ryburn.org] Sent: Thursday, December 02, 2004 4:18 PM To: Chad Skidmore; nanog@merit.edu Subject: Re: How many backbones here are filtering the makelovenotspam scr eensaver site?
This is what scares me. Who determines the "bad guys?" I don't know anyone over at Lycos so I have no trust (or lack there of) in Lycos. Who is to say that Lycos won't decide next month that Yahoo, Google, MSN, _insert your own network here_ are "bad guys" and point the screen saver at them. Are they likely to do it? Probably not; it would be a PR nightmare for them. But who is to stop them? What if they don't go so extreme and just point the screen saver at "gray hat" hosts who are open relays or something?
I agree 100%. I believe that I get to decide what is or is not "ok" traffic on my network. I define that in my AUP and customers agree to and understand that when they buy service from me.
My opinion (not that anyone asked) is retaliation is childish and unprofessional. I remember the Internet before Spam,
Also agree 100%. If there is traffic hitting my network that I don't believe is "ok" then I can choose not to carry that traffic on my network. It doesn't give me the right to attack the originator of that traffic or the person that I "believe" to be the originator of that traffic. That's why I am a very firm believer in the power of "ip route x.x.x.x y.y.y.y null0" command. :) Makes the problem go away for me (for the most part) and doesn't cause anyone else any pain as a result except my customers, who agreed to let me use that power when they purchased service from me.
botnets, DDOS, etc. and dream of a day when these are "under control" again just as much as the next geek. However, stooping to the level of the miscreant is not the answer to the problem in my opinion.
Justin Ryburn justin@ryburn.org
"Dance like nobody's watching; love like you've never been hurt. Sing like nobody's listening; live like it's heaven on earth." -- Mark Twain
- ---------------------------- Chad E Skidmore One Eighty Networks, Inc. http://www.go180.net 509-688-8180 -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQa+yXU2RUJ5udBnvEQLX1gCglUjYXtQXyrSMFdfsQeZg9beq/xsAoI/C jOJ77EI+PIQs01sPNEnBphWK =ZScz -----END PGP SIGNATURE-----
Chad,
That's why I am a very firm believer in the power of "ip route x.x.x.x y.y.y.y null0" command. :) Makes the problem go away for me (for the most part) and doesn't cause anyone else any pain as a result except my customers, who agreed to let me use that power when they purchased service from me.
I would rather prefer the traffic not hitting anything behind my transit/peering machinery at all, so the "ip route" alone doesn't make me happy, I also have to adjust ingress ACLs every once in a while. And while Cisco's autosecure feature looks fine in most parts (saves a lazy overworked bum like me a lot of typing), it does not do much good - in my opinion - when it comes to bogon filtering. I prefer knowing what the filter looks like, and it does not seem to give me that, nor any way of modifying the list (correct me if I'm wrong). I like the simplicity of, e.g., the Cymru route-server project, giving me bogon prefixes I can then blackhole, and giving me the opportunity to filter those prefixes (and hence my filters). Unfortunately, this only works for egress, and I still have to look after my ingress ACLs. Oh, and of course this is only a good thing as long as the Cymru folks can be trusted... Cheers, Elmi. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2@ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---
On Fri, 3 Dec 2004, Elmar K. Bins wrote:
And while Cisco's autosecure feature looks fine in most parts (saves a lazy overworked bum like me a lot of typing), it does not do much good - in my opinion - when it comes to bogon filtering. I prefer knowing what the filter looks like, and it does not seem to give me that, nor any way of modifying the list (correct me if I'm wrong).
See pages 9, 10 and 12 of the PDF I posted. Specifically, it sets up: "ip access-list extended autosec_iana_reserved_block", and "ip access-list extended autosec_complete_bogon" which you of course can change like any other ACL. -Hank
Hank :-)
that, nor any way of modifying the list (correct me if I'm wrong).
See pages 9, 10 and 12 of the PDF I posted. Specifically, it sets up: "ip access-list extended autosec_iana_reserved_block", and "ip access-list extended autosec_complete_bogon" which you of course can change like any other ACL.
Yup, read the last bits now, so at least that holds no more fear. Unfortunately one still has to mop all routers every time. Thanks for correcting that, Elmi. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2@ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---
Hank Nussbacher wrote:
On Fri, 3 Dec 2004, Elmar K. Bins wrote:
And while Cisco's autosecure feature looks fine in most parts (saves a lazy overworked bum like me a lot of typing), it does not do much good - in my opinion - when it comes to bogon filtering. I prefer knowing what the filter looks like, and it does not seem to give me that, nor any way of modifying the list (correct me if I'm wrong).
See pages 9, 10 and 12 of the PDF I posted. Specifically, it sets up: "ip access-list extended autosec_iana_reserved_block", and "ip access-list extended autosec_complete_bogon" which you of course can change like any other ACL.
This is broken by design. Routers would ship with the iana_reserved_block list of when they were manufactured. If the user is stoopid enough not to be able to get his filters from Cymru directly then he should not have any filtering at all because he is never going to update it anyway in the future. Ergo lots of black holes for newly allocated address spaces to the RIR's. The cure will be far worse than the disease if routers would come with pre-configured bogon lists. And you are missing a big point; What bogons are bogons? In an enterprise setup the RFC1918 space (10/8, 172.16/12, 192.168/16) is most likely not a bogon while it most likely is for an ISP. Breaks right here. On top of that it is solving a non-problem. There is only little junk coming from the non-iana allocated ranges. And that is easily taken care of by filtering inbound traffic at the customer edges (ie. allow customers to send only traffic with source IP's out of the assigned IP range). If you do any bogon filtering at all then do it with some automatically updating system like an BGP bogon feed from Cymru. -- Andre
On 3-dec-04, at 10:57, Andre Oppermann wrote:
Routers would ship with the iana_reserved_block list of when they were manufactured. If the user is stoopid enough not to be able to get his filters from Cymru directly then he should not have any filtering at all because he is never going to update it anyway in the future. Ergo lots of black holes for newly allocated address spaces to the RIR's.
Exactly. (Unless "IANA reserved" != "unallocated" but IANA does call unallocated space "reserved".)
The cure will be far worse than the disease if routers would come with pre-configured bogon lists.
Indeed. In fact, the whole bogon filtering thing is more harmful than useful.
If you do any bogon filtering at all then do it with some automatically updating system like an BGP bogon feed from Cymru.
What exactly does this feed do for me? Wouldn't bogons be everything that isn't in the global routing table?
On Fri, Dec 03, 2004 at 10:57:15AM +0100, Andre Oppermann wrote:
If you do any bogon filtering at all then do it with some automatically updating system like an BGP bogon feed from Cymru.
How does the BGP bogon feed from cymru protect against more-specific bogons ? -- Cliff Albert <cliff@oisec.net>
participants (6)
-
Andre Oppermann -
Chad Skidmore -
Cliff Albert -
Elmar K. Bins -
Hank Nussbacher -
Iljitsch van Beijnum