Krebs on Security booted off Akamai network after DDoS attack proves pricey
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
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
>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
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.,
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.
More information about the NANOG