blocking unallocated subnets

I work for a large email provider and we've run into trouble
delivering mail to certain sites after bringing up new servers in a
recently allocated subnet of 72/8. Apparently, some folks decided it
would be a good policy to protect their nameservers from ddos attacks
to silently drop requests from unallocated subnets. So they obtained
a list of subnets at some point in the past, deployed it and then
never updated it.

This manifests itsself in our system when the dns query repeatedly
times out on the smtp servers in that subnet while it works from
elsewhere. In the instances we've run into this, it only seemed to
affect dns and not, say, smtp connections.

I just wanted to try to raise some awareness of this practice and the
trouble it may cause if the ruleset gets out-of-date. This caused us
a pretty major headache the result of which is that we've given up for
now on trying to deliver mail out of that subnet.

john

Welcome to 2002. Have a look at http://69box.atlantic.net/

Hi, John.

] I work for a large email provider and we've run into trouble
] delivering mail to certain sites after bringing up new servers in a
] recently allocated subnet of 72/8. Apparently, some folks decided it
] would be a good policy to protect their nameservers from ddos attacks
] to silently drop requests from unallocated subnets. So they obtained
] a list of subnets at some point in the past, deployed it and then
] never updated it.

This is why we recommend to those who filter unallocated and bogon
space to keep current with lists such as the sundry formats found
here:

   <http://www.cymru.com/Bogons/>

Another option is to automate the updates and leave the hard work
to us! :slight_smile: Consider peering with the Bogon route-servers, located
throughout the globe thanks to the kind donation of hosting from
several folks.

   <http://www.cymru.com/BGP/bogon-rs.html>

Thanks,
Rob.

Another option is to automate the updates and leave the hard work
to us!

the op was discussing port-specific filtering for dns only. could
you explain how i can automake my /etc/ipfw.rules leaving the hard
work to you? e.g.

    add deny udp from 203.49.118.0/24 to any 53

randy

Hi, Randy.

] > Another option is to automate the updates and leave the hard work
] > to us!
]
] the op was discussing port-specific filtering for dns only. could
] you explain how i can automake my /etc/ipfw.rules leaving the hard
] work to you? e.g.

There are often subtle relationships when it comes to filtering.
While the DNS name servers may have no such filters, they are
unreachable due to filters on upstream routers. So we try to
provide as wide a set of filters as possible.

] add deny udp from 203.49.118.0/24 to any 53

Now that is a set of filters we don't make available. I'll see
if I can create another page for IPFW filters. I should do the
same for IPF as well.

You could Zebra peer with the Bogon route-servers and accept
these prefixes as null routes. I've used null routes on servers
frequently, but I've not tried the combination before. Take it
with a grain of salt. :slight_smile:

Thanks,
Rob.

Hi Rob,

On recent FreeBSD (ipfw2)

<doh> cool. i had never followed the changes in ipfw2. thanks!

randy