[dns-operations] CloudShield advices against dDoS
http://www.cloudshield.com/applications/dns-control-traffic-load.asp My first reaction was These solutions are incredibly stupid and my second one But let's check among the experts at the dns-operations ML before trolling. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] CloudShield advices against dDoS
On 2013-02-20, at 12:46, Stephane Bortzmeyer bortzme...@nic.fr wrote: http://www.cloudshield.com/applications/dns-control-traffic-load.asp I think this particular information security professional with more than 16 years of experience is a bit confused. I tried hard to find something in there I agreed with, but I failed. Joe ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] CloudShield advices against dDoS
On Feb 20, 2013, at 12:03 PM, Joe Abley jab...@hopcount.ca wrote: On 2013-02-20, at 12:46, Stephane Bortzmeyer bortzme...@nic.fr wrote: http://www.cloudshield.com/applications/dns-control-traffic-load.asp I think this particular information security professional with more than 16 years of experience is a bit confused. I tried hard to find something in there I agreed with, but I failed. I cannot imagine a computer, tablet, or smartphone that can generate more than 10 qps Giggles…. W Joe ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- Have you got any previous convictions? Well, I dunno... I suppose I used to believe very firmly that a penny saved is a penny earned-- -- Terry Pratchett ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] CloudShield advices against dDoS
Stephane wrote on 02/20/2013 11:46:51 AM: http://www.cloudshield.com/applications/dns-control-traffic-load.asp My first reaction was These solutions are incredibly stupid and my second one But let's check among the experts at the dns-operations ML before trolling. Even though I manage our name servers, I'm more of a DNS data consumer And two of his three points strike me as seriously flawed. His first suggestion is to return false data instead of NXDOMAIN. So a mail server that is attempting to deliver mail in good faith will have to connect to itself to find out that u...@bogusdomain.com is invalid? And if it is an outbound relay, it may loop that message several times depending on configuration before dropping it. If it had received an NXDOMAIN, it may not have accepted the message in the first place. I'm sure there are other situations where this will cause problems. This approach will drastically reduce traffic in case of an attack. Does it really? His second suggestion actually makes some sense. If your server can't handle more than X, don't allow more than X to receive it. But make sure X is sufficient to meet demand! Kind of like a two pound bird trying to lay a three pound egg. The third point makes me want to lock him out of all computers on the planet and give him an Etch A Sketch. I had a network security guy here do this to me. He threw up a firewall rule preventing more than Y connections per minute. I forget the actual value of Y. Well, my spam filters handling about 1,000 messages per minute could no longer reach the DNS servers for the 5 or more DNS queries per message. Of course there was absolutely no notification that this change was being made. It took me three days to figure out what the frack happened. Only the off-hand comment of one of the other network staff tipped me off. Thank $DIETY he's long gone and I got to build two more DNS servers dedicated to the spam filters. Baseline the normal traffic before making such stupid assumptions! Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] CloudShield advices against dDoS
On 20 February 2013 17:03, Joe Abley jab...@hopcount.ca wrote: On 2013-02-20, at 12:46, Stephane Bortzmeyer bortzme...@nic.fr wrote: http://www.cloudshield.com/applications/dns-control-traffic-load.asp I think this particular information security professional with more than 16 years of experience is a bit confused. I tried hard to find something in there I agreed with, but I failed. There are some very limited scenarios where some of his suggestions might be acceptable if closely monitored by someone who has a clue about DNS. Anyone who feels the need to read a 'how to set up your DNS servers' type article like that should definately not be doing any of the things on that list - every one of those suggestions will break something in a hard to diagnose way and should never be done on a production network without a full understanding of the implications. It doesn't even make a distinction between recursive and authoratative servers which are very different animals with very different traffic patterns, it seems to flip back and forth between the 2 as if they were one and the same - anyone writing about DNS should know to make the distinction clear. Probably the most important and most basic bit of 'security advice' for anyone setting up DNS servers is to keep those roles separate, I don't see that in the article? - Mike (Yes I know there are legitimate cases where it's fine to combine authoratitive and recursive roles, but if you can explain when and where then you're probably not the target audience for the article) ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] CloudShield advices against dDoS
Stephane Bortzmeyer wrote: http://www.cloudshield.com/applications/dns-control-traffic-load.asp My first reaction was These solutions are incredibly stupid and my second one But let's check among the experts at the dns-operations ML before trolling. hmm, s/before/while/, maybe. also, i think you're in the clear, since their anti-trolling policy only applies to patents and not blog posts: Referential Use Only. Third parties may reference CloudShield patents. Referential use is prohibited is such use would defame or disparage CloudShield, its products, or any other person or entity. (http://www.cloudshield.com/company/patents.asp) and hey, doesn't this behavior make kaminsky poisoning even easier? If this is true, why should you allow DNS queries with other resource records like , HIP, or SIG to reach your servers? [...] This only consumes processing time because they have no answer. The best way to handle them is to block it upfront. -- Robert Edmonds edmo...@isc.org ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Defending against DNS reflection amplification attacks
Jan-Piet Mens wrote: FYI, a paper (Feb 2013) titled Defending against DNS reflection amplification attacks at [1]. -JP [1] http://www.nlnetlabs.nl/downloads/publications/report-rrl-dekoning-rozekrans.pdf i had a brief look. actually, i skipped straight to appendix E :) i think measuring performance with process accounting (top, htop...) is not such a great idea. something like cyclesoak would probably be better: `cyclesoak' calculates CPU load by a subtractive method: a background cycle-soaking task is executed on all CPUs and `cyclesoak' measures how much the throughput of the background tasks is degraded by running the traffic. This means that ALL effects of networking (or other userspace + kernel activity) are measured - interrupt load, softirq handling, memory bandwidth usage, etc. This is much more accurate than using Linux process accounting. (http://www.tux.org/pub/sites/www.zip.com.au/%257Eakpm/linux/README.zc) and perf is a great profiling tool for linux, too. (https://perf.wiki.kernel.org/) -- Robert Edmonds edmo...@isc.org ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] CloudShield advices against dDoS
On Feb 20, 2013, at 9:03 PM, Joe Abley wrote: On 2013-02-20, at 12:46, Stephane Bortzmeyer bortzme...@nic.fr wrote: http://www.cloudshield.com/applications/dns-control-traffic-load.asp I think this particular information security professional with more than 16 years of experience is a bit confused. I tried but it can work for public sector well... hard to find something in there I agreed with, but I failed. Joe ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Defending against DNS reflection amplification attacks
* Jan-Piet Mens wrote: FYI, a paper (Feb 2013) titled Defending against DNS reflection amplification attacks at [1]. Despite they are using the wrong patch for DNS Dampening, the results are impressing. Works as designed. Of course, they require a SLIP parameter. I heard this. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] CloudShield advices against dDoS
On Feb 21, 2013, at 1:02 AM, Mike Hoskins (michoski) wrote: -Original Message- From: Joe Abley jab...@hopcount.ca Date: Wednesday, February 20, 2013 12:03 PM To: Stephane Bortzmeyer bortzme...@nic.fr Cc: DNS Operations List dns-operations@lists.dns-oarc.net Subject: Re: [dns-operations] CloudShield advices against dDoS On 2013-02-20, at 12:46, Stephane Bortzmeyer bortzme...@nic.fr wrote: http://www.cloudshield.com/applications/dns-control-traffic-load.asp I think this particular information security professional with more than 16 years of experience is a bit confused. I tried hard to find something in there I agreed with, but I failed. While we're trolling... since when do information security professionals agree? ;-) No trolling at all - but there are no updates to this old patented solution for a years And it is hard to estimate software evolution (I'm hoping the usenet standard of including a smiley still implies tongue-in-cheek in the twitter age...) Personally, stepping back from the technology a bit, I'd be wary of any professional who makes statements such as, You can do everything right... Really? Are you $DIETY? Did they even do everything right? **looks around** Years of experience in any discipline typically teaches you about pragmatism and incremental refinement. One size does not fit all. When I read the intro, I prepared myself for soapboxing and had to fight very hard not to gloss over the conveniently succinct 3-point plan to perfection. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
