Update Spamhaus DROP list from Cisco CLI (TCL)
jared at puck.nether.net
Wed Jan 19 20:19:57 CST 2011
On Jan 19, 2011, at 9:04 PM, Thomas Magill wrote:
> Previous conversations made me decide this would be fun to do so I ignored all my real work today and made it happen.
> I built a TCL script that can be mapped to an alias ("alias exec updatedrop tclsh updatedrop.tcl") that will connect to the Spamhaus DROP list and route all of the prefixes to null0. It should alsbo be able to be mapped to a kron job, but I haven't tested that and I've heard there are issues with kron+tcl unless you tie it to an EEM event. It adds a name indicator (Spamhaus_SBLXXXXX) to all of the routes to show that they come from the DROP list. You can find the script at:
> There is also a script to remove all of the Spamhaus_SBLXXXXX null routes.
> If I were to redis these into BGP they could be propagated just like the CYMRU Bogons... I plan on doing that within the next week and start testing. Does anyone see that as a useful service to be offered?
This was done once before, it was called MAPS at the time. Using BGP as a signaling mechanic for this stuff can obviously be useful. The challenge has always been balancing the trust with a 3rd party with the other operational requirements.
Typically business needs push this out such that it's harder to obtain. Smaller networks may participate as the cost may be higher proportionally upon them. Larger networks just do the triage the same way they always do, with their abuse desks.
The business needs/concerns are typically something like "How do we trust them? Can it be hacked? etc."
There are always sunsetting issues. Sometimes nobody knows that the network was peered with the bogons server, or has an old bogons list that needs to be updated. There will be a lot of fun soon as we attain the "end of ipv4 allocations" soon. Many people with old bogon lists will ultimately need to remove them. Some people won't notice, possibly for years.
More information about the NANOG