Permitting spoofed traffic [Was: Re: ddos attack blog]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2/14/2014 10:22 AM, Wayne E Bouchard wrote: On Thu, Feb 13, 2014 at 08:01:27PM -0500, Jared Mauch wrote: I would actually like to ask for those folks to un-block NTP so there is proper data on the number of hosts for those researching this. The right thing to do is reconfigure them. I've seen a good trend line in NTP servers being fixed, and hope we will see more of that in the next few weeks. A slight exception to that statement, if I may... The right thing to do is for people to not permit services to operate on hosts they do not intend to operate on and not to be visible to those they do not intend to use them. In other words, to properly manage their networks. If that means blocking all access to potentially faulty implementations, then that's the right thing to do. In short, companies should do what is right for their companies and nevermind anyone else. Never forget that researches are just part of the public and should never consider that their usage of the internet is any more or less valid to the average third party than the next guy. Taken to the logical extreme, the right thing to do is to deny any spoofed traffic from abusing these services altogether. NTP is not the only one; there is also SNMP, DNS, etc. - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlL+Y68ACgkQKJasdVTchbJ/dgEAqgERvP6HMl2v5fbhZDwI9QKT YEe/c3mN5gZlxsIKFo0A/3BH9KMV6ln7XMrlnk4c/GuwZ9X4LAgqO6l2p8u3aA49 =yWZU -END PGP SIGNATURE-
Re: Permitting spoofed traffic [Was: Re: ddos attack blog]
On 2/14/2014 12:42 PM, Paul Ferguson wrote: Taken to the logical extreme, the right thing to do is to deny any spoofed traffic from abusing these services altogether. Since the 1990s I have argued (ineffectively, it turns out) a case that says that sentence can be edited down to good advantage as: Taken to the logical extreme, the right thing to do is to deny any spoofed traffic. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)
Re: Permitting spoofed traffic [Was: Re: ddos attack blog]
On Fri, Feb 14, 2014 at 10:42:55AM -0800, Paul Ferguson wrote: [snip] Taken to the logical extreme, the right thing to do is to deny any spoofed traffic from abusing these services altogether. NTP is not the only one; there is also SNMP, DNS, etc. ...and then we're back to implement BCP38 already! (like one of the authors of the document didn't think of that, ferg? ;-) NB: Some Entities believe all filtering is 'bcp 38' and thus have given this stone-dead logical and sane practice a bad rap. If someone is sloppy with their IRR-based filters or can't drive loose RPF correctly, that isn't the fault of BCP38. The document specifically speaks to aggregation points, most clearly in the introduction: In other words, if an ISP is aggregating routing announcements for multiple downstream networks, strict traffic filtering should be used to prohibit traffic which claims to have originated from outside of these aggregated announcements. This goes for access, hosting, and most recently virtual hosting in teh cloude. Stop forgery at your edges and your life will be easier. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / CotSG / Usenix / NANOG
Re: Permitting spoofed traffic [Was: Re: ddos attack blog]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2/14/2014 3:00 PM, Larry Sheldon wrote: On 2/14/2014 12:42 PM, Paul Ferguson wrote: Taken to the logical extreme, the right thing to do is to deny any spoofed traffic from abusing these services altogether. Since the 1990s I have argued (ineffectively, it turns out) a case that says that sentence can be edited down to good advantage as: Taken to the logical extreme, the right thing to do is to deny any spoofed traffic. But of course. :-) - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlL+y1QACgkQKJasdVTchbIgWgEAns/Nw6pqK+BaXSmI2DmP5J9Z mxeVg3KTCHdMBSDeZXAA/2+PlVSwHXdFem6hwRC/iv1+zscghkwUgimGbhKA5Gnx =VXx2 -END PGP SIGNATURE-
Re: Permitting spoofed traffic [Was: Re: ddos attack blog]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2/14/2014 4:09 PM, Joe Provo wrote: On Fri, Feb 14, 2014 at 10:42:55AM -0800, Paul Ferguson wrote: [snip] Taken to the logical extreme, the right thing to do is to deny any spoofed traffic from abusing these services altogether. NTP is not the only one; there is also SNMP, DNS, etc. ...and then we're back to implement BCP38 already! (like one of the authors of the document didn't think of that, ferg? ;-) NB: Some Entities believe all filtering is 'bcp 38' and thus have given this stone-dead logical and sane practice a bad rap. If someone is sloppy with their IRR-based filters or can't drive loose RPF correctly, that isn't the fault of BCP38. The document specifically speaks to aggregation points, most clearly in the introduction: In other words, if an ISP is aggregating routing announcements for multiple downstream networks, strict traffic filtering should be used to prohibit traffic which claims to have originated from outside of these aggregated announcements. This goes for access, hosting, and most recently virtual hosting in teh cloude. Stop forgery at your edges and your life will be easier. Indeed -- I'm not in the business of bit-shipping these days, so I can't endorse or advocate any particular method of blocking spoofed IP packets in your gear. I can, however, say with confidence that it is still a good idea. Great idea, even. :-) - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlL+y8sACgkQKJasdVTchbKTXAEA0/czP0ECsFX4CyUr6yt4Dkap D0NZT/UIo6h5E/dl0KEA/3hpxN2NLxZRix6JUTVHyv+LZ4RzgpG2myoXbgAq1+WS =QQjA -END PGP SIGNATURE-
Re: Permitting spoofed traffic [Was: Re: ddos attack blog]
On 2/14/2014 9:07 PM, Paul Ferguson wrote: Indeed -- I'm not in the business of bit-shipping these days, so I can't endorse or advocate any particular method of blocking spoofed IP packets in your gear. If you're dead-end, a basic ACL that permits ONLY your prefixes on egress, and blocks your prefixes on ingress, is perhaps the safest bet. Strict uRPF has it's complications, and loose uRPF is almost too forgiving. If you're providing transit, it gets much more complicated much more quickly, but the same principles apply (they just get to be a less-than-100% solution) :) I can, however, say with confidence that it is still a good idea. Great idea, even. :-) Oh yeah :) Jeff signature.asc Description: OpenPGP digital signature
