Update Spamhaus DROP list from Cisco CLI (TCL)

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:

http://tmagill.net/cisco_networking_ccie_studies/?p=83

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?

Thomas Magill
Network Engineer
Office: (858) 909-3777
Cell: (858) 869-9685
tmagill@providecommerce.com<mailto:tmagill@providecommerce.com>

provide-commerce
4840 Eastgate Mall
San Diego, CA 92121

ProFlowers<http://www.proflowers.com/> | redENVELOPE<http://www.redenvelope.com/> | Cherry Moon Farms<http://www.cherrymoonfarms.com/> | Shari's Berries<http://www.berries.com/>

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.

- Jared

Did you try this

http://www.spamhaus.org/faq/answers.lasso?section=DROP%20FAQ#168

LInks to Marco d'Itri's "cisco tools" package -
http://www.linux.it/~md/software/cisco-tools-0.2.tgz

Pretty neat, can update bogons as well

It's only useful if you want to make troubleshooting problems more difficult and require remote parties to contact you off-net. Conditionals for such blocks are more difficult (abuse@domain whitelisted isn't enough, you have to have a specific @domain which the filters don't apply to).

I agree that smaller networks are the ones more likely to participate in such things.

Jack

I saw that. I just wanted to do it in TCL so that it was completely self-contained and could be run like a command from IOS itself. It was mostly an exercise/challenge in scripting for myself, that yielded what I felt to be a useful product.

I made a version of Mr. Magill's script to read the dshield.org's
block list and create null routes for it. He deserves all of the
credit, but none of the blame in case it doesn't work for you. I'm not
a TCL programmer - use at your own risk.
Anyone else have any nifty TCL for Cisco scripts they can share? I'm
curious to know what's possible and what people have done.