[135290] in North American Network Operators' Group
Re: Update Spamhaus DROP list from Cisco CLI (TCL)
daemon@ATHENA.MIT.EDU (Jared Mauch)
Wed Jan 19 21:20:50 2011
From: Jared Mauch <jared@puck.nether.net>
In-Reply-To: <A1B9BAEA8FE39847BCD6C473E894B595027BF5E0@SDEXMB02.Proflowers.com>
Date: Wed, 19 Jan 2011 21:19:57 -0500
To: Thomas Magill <tmagill@providecommerce.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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.
>=20
> 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:
>=20
> http://tmagill.net/cisco_networking_ccie_studies/?p=3D83
>=20
> There is also a script to remove all of the Spamhaus_SBLXXXXX null =
routes.
>=20
> 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.
- Jared=
