On 25/02/2014, at 17:55, Roland Dobbins wrote:

Transparently redirecting DNS or ntp is hostile & unethical, if not actionable. Setting up policies so that customers must by default use your recursive DNS & ntp setups makes perfect sense, as long as those policies are made clear & as long as 'advanced' customers can opt out.

I assume you mean non-notified transparent redirection. Hostile and unethical are interesting terms to use if customers are informed of the behaviour. Depending on one's customer base, the vast majority of users are likely far more interested in "Can I get a correct answer to DNS questions?" and "Can I sync my clocks to something that looks like the correct time?" than "Can I get an answer from DNS/NTP servers of my choice?" An opt-out policy of "You must use my recursive DNS and NTP infrastructure" (presumably enforced by packet filters) will almost certainly result in more support calls from such a customer base than transparently redirecting the same traffic to (supposedly) known-good servers. That is to say, a filter-enforced policy combined with transparent redirection may make more sense than a filter-enforced policy alone. Doing either without the opt-out component is not something I'd consider a good idea, but as they say, your network, your rules. I did overhear someone mention that transparent snaffling of packets on a network run by an company called End2End was somewhat amusing, though :p Cheers -Mike

Forgive me for missing the obvious here, but isn't the answer to drop packets emitting from customers on UDP/123 above _a certain rate limit_? Transparent UDP/123 redirection is going to break a lot of assumptions people have about how their current systems work, and would certainly get me, if i were a customer, very hot under the collar indeed. Debugging the subtle problems this would cause would mean a lot of wasted hours for many expensive people. Regards, Joel van Velden Cloud Scale Ltd NZ Cloud Storage API-compatible with Amazon S3. On 25/02/2014 11:00 p.m., Dobbins wrote:

On Feb 25, 2014, at 1:53 PM, Mike Jager wrote:

...

I assume you mean non-notified transparent redirection. Correct - I should've made that clear, thanks for pointing it out.

That being said, how many customers understand enough to know what they're agreeing to have performed on their traffic?

Also, there could be very serious consequences for dorking around with ntp, especially - far too many critical systems (incorrectly) utilize the public Internet for this sort of thing.

----------------------------------------------------------------------- Roland Dobbins // http://www.arbornetworks.com

Luck is the residue of opportunity and design.

-- John Milton

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

On 25 Feb 2014, at 5:32, Dobbins, Roland wrote:

On Feb 25, 2014, at 6:19 PM, Joel van Velden wrote:

...

Forgive me for missing the obvious here, but isn't the answer to drop packets emitting from customers on UDP/123 above a certain rate limit?

IMHO, the obvious solution is to block ntp packets which aren't 76 bytes in length towards either attack targets or to/from ntpds being abused, because source-based QoS isn't that commonplace, plus per-source numbers can be relatively (*relatively*) low compared to the attack aggregate.

This approach has been used with considerable success over the last week-and-a-half, FWIW.

It doesn’t do great things for the long-term development of NTP as a protocol, though. I understand the need to put out flames during a big fire, but short-term fixes that don’t cause immediate damage have a habit of sticking around. Joe

That's why we use NAT for security, right? On Thu, Feb 27, 2014 at 9:45 AM, Simon Lyall wrote:

On Wed, 26 Feb 2014, Joe Abley wrote:

...

I understand the need to put out flames during a big fire, but short-term fixes that don't cause immediate damage have a habit of sticking around.

Especially when they turn into "Security best practice"

http://support.microsoft.com/kb/828263

-- Simon Lyall | Very Busy | Web: http://www.simonlyall.com/ "To stay awake all night adds a day to your life" - Stilgar

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

On 27/02/2014, at 1:55 pm, Jeremy Visser wrote:

On 27/02/14 07:57, Sam Russell wrote:

...

That's why we use NAT for security, right?

While you’re at it, it’s probably a good idea to block all ICMP, as you don’t want hackers to be able to ping things (after all, that’ll only encourage them to break in), and ICMP isn’t actually used for anything other than pings.

Please warn people before you use sarcasm. I’ll be fine, I just need some pictures of kittens and dandelions.

On Feb 27, 2014, at 12:18 AM, Joe Abley wrote:

I understand the need to put out flames during a big fire, but short-term fixes that don’t cause immediate damage have a habit of sticking around.

Concur 100%. And I advocate it being done selectively where possibly, in mitigation centers through which traffic destined for attack targets is diverted during an attack. ----------------------------------------------------------------------- Roland Dobbins // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton