Krebs on Security booted off Akamai network after DDoS attack proves pricey

Mark Milhollan mlm at pixelgate.net
Mon Sep 26 15:23:15 UTC 2016


On Sun, 25 Sep 2016, Stephen Satchell wrote:

>Yeah, right.  I looked at BCP38.info, and there is very little concrete
>information.  

Yeah, it's pretty naked.  But how-to isn't the usual stumbling block, as 
has been pointed out in this thread there needs to be the will to spend 
resources setting it up and thus committing future resources to 
maintenance.

>I've been slogging through the two RFCs, 2827 and 3794, and find
>it tough sledding to extract the nuggets to put into my firewall and routing
>table.  One of the more interesting new additions to my systems is this, to the
>routing tables:

A list of martian addresses is useful to avoid sending to or accepting 
from weird places but it isn't useful for BCP38 purposes, of ensuring a 
node only uses address(es) assigned to it as the source address in the 
packets it creates/sends.

BGP38 checking is not done by the node itself, though that is not 
entirely unreasonable.  Enforcement is performed by the network as close 
to the point of the node's attachment as possible -- failures should be 
discarded or perhaps returned as prohibited and possibly even sampled 
for use by network staff to work on remediation.  In some cases it's 
very simple and effective to just filter toward your upstream(s), i.e., 
allow this area's addresses and drop/reject/log the rest.

>(Has this been published anywhere before?  I haven't found any yet.)

Cymru has lists in various formats and levels of (de)aggregation and 
detail that you can easily turn into those commands, though there's no 
martians-only lists for IPv6.  You might even use one of the "fullbogon" 
lists to block at a very detailed level if you have sufficient resources 
or tools that keep needs light, e.g., ipset.

>In short, I have yet to see a "cookbook" for BGP38 filtering, for ANY filtering
>system -- BSD, Linux, Cisco.

For some it's just uRPF, strict or loose as your needs demand, which 
their router can already perform, e.g.,

  interface your-template/or/range-of-interfaces/etc
    ip verify unicast reverse-path
 or ip verify unicast source reachable-via rx
 or ip verify unicast source reachable-via any

Which for Linux is controlled by the net.ipv4.conf.if.rp_filter sysctl 
key where "if" can be "default", "all" or a specific interface name and 
a setting of 1 does strict checking while 2 does loose.

Or there's always plain old packet filters, with varying degrees of ease 
or annoyance, as tightly (per customer applied to incoming packets 
received on their interface) or simply (leaving the pop) as you please 
and makes sense.


/mark



More information about the NANOG mailing list