[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Last-call DoS/DoS Attack BCOP
- Subject: Last-call DoS/DoS Attack BCOP
- From: rs at seastrom.com (Rob Seastrom)
- Date: Tue, 24 Mar 2015 05:27:30 -0400
- In-reply-to: <20150323182142.364b56df@localhost> (John Kristoff's message of "Mon, 23 Mar 2015 18:21:42 -0500")
- References: <CAC1-dtns9BDpVCLr+jnFsaGrNAcR7pzQZFesdu2PfgjeMubMdg@mail.gmail.com> <[email protected]> <[email protected]> <[email protected]> <20150323182142.364b56df@localhost>
John Kristoff <jtk at cymru.com> writes:
> If the attack is an infrastructure attack, say a routing interface that
> wouldn't normally receive or emit traffic from its assigned address
> except perhaps for network connectivity testing (e.g. traceroute) or
> control link local control traffic (e.g. local SPF adjacencies, BGP
> neighbors), you can "hide" those addresses, making them somewhat less
> easy to target by using something like unnumbered or unadvertised or
> ambiguous address space (e.g. RFC 1918).
That comes at a cost, both operational/debugging and breaking pmtud.
But if you don't care about collateral damage, setting the interface to
admin-down stops attacks against it *cold*.
Due to the drawbacks, I wouldn't consider this a good candidate for
inclusion in a BCOP document.
I have often thought there ought to be a companion series for
Questionable Current Operational Practices, or maybe "desperate
measures". I volunteer to write the article on "YOLO upgrades",
wherein one loads untested software on equipment with no OOB, types
"request system reboot", shouts "YOLO", and hits return.
-r