jnelson wrote:

Bogon lists? How effective are they? DDoS scripts are abundant to those who seek them. Am I going to reep any rewards by taxing my edge routers an extra 25 lines of ACL?

If you're using 'access-list compiled', you're not adding any load whatsoever, since there should be an existing and extremely important access list there denying all incoming over your edge (peer || transit) links for your own network blocks and single-homed customers [possibly multi-homed ones as well, that's more debatable though], to prevent spoofing. Warning though, there appears to be a bogus bogon in the current list. See my post of a few minutes back.

Who out there has some stats I can look at?

Unfortunately nothing useful. The usefulness of the bogon lists is rather proportional to how badly configured people's networks are though. If everyone was using unicast verify reverse-path or explicit ingress filtering on their customers and applying egress filtering where appropriate[1] then the bogon list would be pointless. But we all know that's not happening.

And by posting this, am I diminishing its value?

Yes, although only slightly. I never publically post full details of how I protect the IRC server on our network that was DDoS'd a number of times, since posting all the details would negate about half the defences (the defences are based on knowing the attacks, but if the attackers knew the defences, and are sufficiently skilled, they could most likely find a way work around them; and the latest attacks [that we noticed at least - some months back now - we added more defences after them and every now and then I notice "oh someone tried to attack the IRC server again"] were based on knowing that we use Cisco routers which can be overloaded in a particular way, and attacking the infrastructure rather than the IRC server). David. [1] egress filtering can be a pain on upstream links. If the upstream lets you off lightly by not ingress filtering you, sometimes there's a reason to not egress filter. The most common one is this: say you have a customer who advertises x.x.0.0/16 to you - a large multinational. but an upstream advertises x.x.x.0/24 to you. now your peer, an ISP who can't afford to run a full table (in Australia a lot of ISPs run the ~6000 route Australian BGP table or ~2000 route "Australian peering" BGP table) sees x.x.0.0/16 and quite legitimately routes traffic for x.x.x.0/24 to you, not knowing of the off-shore route for x.x.x.0/24. if you egress filter, you break the affected peer(s) ability to access off-shore subnets of x.x.x.0/24. note you can avoid them abusing other routes in your network by not having a default route in your peering router, but still let this traffic pass unharmed. this is actually a very common problem in Australia with mid-sized ISPs and can't simply be fixed by "fix the (customer || peer)". there is a solution which is based on MPLS VPNs (having the internet as one MPLS VPN and a separate MPLS VPN for peers, with defined route/traffic exchange between the VPNs) but compilicates trouble-shooting of the network.