I'm looking to implement the Spamhaus drop list. http://www.spamhaus.org/drop/index.lasso On their FAQ they have a script that looks like it grabs the lists text file and connects to a given router, and tells you what has changed in the list, and what your router is null routing. I'm not sure if it then removes the null routes if a list entry has been removed. I haven't found much documentation on the net regarding this. In the future it looks like you will be able to peer with them and null route traffic from a private AS, which will be routes from the drop list. Right now though, it looks like you'd have to update an ACL manually for any changes to the list. Or use this script which null routes the traffic (I guess it's not a big deal getting the syn packets, as long as the mail won't send because of the null route). I am not sure if this script updates the null routes automatically, or how to use it, I can't find to much documentation. Any documentation on this script or another script available. What are your suggestions? thanks
On Jun 15, 2009, at 1:16 PM, Quinn Mahoney wrote:
Or use this script which null routes the traffic (I guess it's not a big deal getting the syn packets, as long as the mail won't send because of the null route)
I you are using uRPF, the SYN packets won't get through either, because they came from an interface other than the null interface. Not so helpful interddomain, but it protects your customers from each other (as BCP 38 does in other cases).
Once upon a time, Fred Baker <fred@cisco.com> said:
On Jun 15, 2009, at 1:16 PM, Quinn Mahoney wrote:
Or use this script which null routes the traffic (I guess it's not a big deal getting the syn packets, as long as the mail won't send because of the null route)
I you are using uRPF, the SYN packets won't get through either, because they came from an interface other than the null interface. Not so helpful interddomain, but it protects your customers from each other (as BCP 38 does in other cases).
Not true for JUNOS; "discard" routes are still in the forwarding table and are treated as a valid destination when it comes to loose-mode uRPF. -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
participants (3)
-
Chris Adams
-
Fred Baker
-
Quinn Mahoney