New on RIPE Labs: Securing Network Infrastructure for DNS Servers
Dear colleagues, Ramtin Kiaei shows how to mitigate DNS attacks by implementing a stateless firewall filter at the aggregation or edge router. Please find his article on RIPE Labs: https://labs.ripe.net/Members/ramtin_kiaei/securing-network-infrastructure-for-dns-servers?pk_campaign=labs&pk_kwd=list-dnswg Kind regards, Mirjam Kuehne RIPE NCC
Dear colleagues,
Ramtin Kiaei shows how to mitigate DNS attacks by implementing a stateless firewall filter at the aggregation or edge router. Please find his article on RIPE Labs:
https://labs.ripe.net/Members/ramtin_kiaei/securing-network-infrastructure-for-dns-servers?pk_campaign=labs&pk_kwd=list-dnswg IMHO this is full of bad ideas and against protocol specs. While I agree
Moin! On 28 Jun 2016, at 12:26, Mirjam Kuehne wrote: that at these day and age one must defend against attacks on DNS systems, just blindly dropping on packet size or fragments is a very bad idea. Forwarding to 8.8.8.8 also is, although I know people who disagree with me on that. If you deploy this approach I'm pretty sure down the road you will spend endless ours trying to debug why something does not work and then find out that it's the filter on packet size you totally forgotten about. So long -Ralf
Hi Ralf, Thanks for the feedback. I am copying the author so he is aware of your comment. Kind regards, Mirjam On 28/6/16 12:41, Ralf Weber wrote:
Moin!
On 28 Jun 2016, at 12:26, Mirjam Kuehne wrote:
Dear colleagues,
Ramtin Kiaei shows how to mitigate DNS attacks by implementing a stateless firewall filter at the aggregation or edge router. Please find his article on RIPE Labs:
IMHO this is full of bad ideas and against protocol specs. While I agree that at these day and age one must defend against attacks on DNS systems, just blindly dropping on packet size or fragments is a very bad idea. Forwarding to 8.8.8.8 also is, although I know people who disagree with me on that.
If you deploy this approach I'm pretty sure down the road you will spend endless ours trying to debug why something does not work and then find out that it's the filter on packet size you totally forgotten about.
So long -Ralf
On Tue, Jun 28, 2016 at 12:41:51PM +0200, Ralf Weber <dns@fl1ger.de> wrote a message of 32 lines which said:
IMHO this is full of bad ideas and against protocol specs. While I agree that at these day and age one must defend against attacks on DNS systems, just blindly dropping on packet size or fragments is a very bad idea. Forwarding to 8.8.8.8 also is
I said more or less the same on the RIPE Labs site (comment not yet moderated).
I’m sure there are plenty of people that will disagree with me, but, IMO, you should never put stateful devices in front of a DNS server. It’s better to have plenty DNS servers on different networks and let them crash and burn if necessary. Just like you never put bananas in the refrigerator :-) A moderate volume DDoS will bring most stateful firewalls to their knees, even attacks that can be weathered nicely by a FreeBSD + bind box. I had a very nice conversation in CPH with a person from Russia and we were very much in agreement on this. Sadly I forgot his name and neither of us had any cards left. If you’re there, please get in touch! -Carlos
On Jun 28, 2016, at 10:16 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
On Tue, Jun 28, 2016 at 12:41:51PM +0200, Ralf Weber <dns@fl1ger.de> wrote a message of 32 lines which said:
IMHO this is full of bad ideas and against protocol specs. While I agree that at these day and age one must defend against attacks on DNS systems, just blindly dropping on packet size or fragments is a very bad idea. Forwarding to 8.8.8.8 also is
I said more or less the same on the RIPE Labs site (comment not yet moderated).
On Tue, Jun 28, 2016 at 10:46:17AM -0300, Carlos M. Martinez <carlosm3011@gmail.com> wrote a message of 31 lines which said:
I’m sure there are plenty of people that will disagree with me, but, IMO, you should never put stateful devices in front of a DNS server.
I fully agree but, precisely, this article use stateless filtering.
It talks about rate limiting, which seems to me is a bit hard to do in a stateless way :-D
On Jun 28, 2016, at 10:59 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
On Tue, Jun 28, 2016 at 10:46:17AM -0300, Carlos M. Martinez <carlosm3011@gmail.com> wrote a message of 31 lines which said:
I’m sure there are plenty of people that will disagree with me, but, IMO, you should never put stateful devices in front of a DNS server.
I fully agree but, precisely, this article use stateless filtering.
Carlos M. Martinez wrote:
It talks about rate limiting, which seems to me is a bit hard to do in a stateless way :-D
Queue / buffer management does not need to be stateful. Most implementations are stateless, except for flow based queues, which is not what's demonstrated here. Nick
Thanks!
On Jun 28, 2016, at 11:58 AM, Nick Hilliard <nick@foobar.org> wrote:
Carlos M. Martinez wrote:
It talks about rate limiting, which seems to me is a bit hard to do in a stateless way :-D
Queue / buffer management does not need to be stateful. Most implementations are stateless, except for flow based queues, which is not what's demonstrated here.
Nick
On 28 Jun 2016, at 15:46, Carlos M. Martinez <carlosm3011@gmail.com> wrote:
I’m sure there are plenty of people that will disagree with me, but, IMO, you should never put stateful devices in front of a DNS server. It’s better to have plenty DNS servers on different networks and let them crash and burn if necessary. Just like you never put bananas in the refrigerator :-) The stateless part has already been responded to. The examples which are from Junos I believe work very well with regards to DDoS. I have used comparable filtering a lot in other cases.
So by counting the number of packets matching and using the line rate stateless filtering, we can cleanup the traffic some before it reaches the servers, making them more likely to keep running. and when being attacked the harm is already done, service will be interrupted if we do nothing … so the talk about these boxes throwing away some traffic, bad middleboxes etc. These are not middleboxes, but part of the overall solution at the end-network - and as such they increase operational cost - but they bring more resilience and stability to the service. They even work using the existing hardware devices in many circumstances, making the cost less than buying “DDoS protection service box model 2000" YMMV, and you should always consider your own environment, adding DNSSEC comments are great etc. Some things SHOULD be discarded, others rate-limited and shameless link https://ripe72.ripe.net/wp-content/uploads/presentations/32-simulated-ddos-r... which has similar advise
A moderate volume DDoS will bring most stateful firewalls to their knees, even attacks that can be weathered nicely by a FreeBSD + bind box.
I had a very nice conversation in CPH with a person from Russia and we were very much in agreement on this. Sadly I forgot his name and neither of us had any cards left. If you’re there, please get in touch!
-Carlos
On Jun 28, 2016, at 10:16 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
On Tue, Jun 28, 2016 at 12:41:51PM +0200, Ralf Weber <dns@fl1ger.de> wrote a message of 32 lines which said:
IMHO this is full of bad ideas and against protocol specs. While I agree that at these day and age one must defend against attacks on DNS systems, just blindly dropping on packet size or fragments is a very bad idea. Forwarding to 8.8.8.8 also is
I said more or less the same on the RIPE Labs site (comment not yet moderated).
Mvh/Best regards Henrik — Henrik Lund Kramshøj, Follower of the Great Way of Unix internet samurai cand.scient CISSP hlk@kramse.org hlk@zencurity.dk +45 2026 6000
Moin! On 29 Jun 2016, at 8:55, Henrik Lund Kramshøj wrote:
and when being attacked the harm is already done, service will be interrupted if we do nothing … There is a difference on doing something as a response to attacks or having something hanging there that might treat you bad down the road.
so the talk about these boxes throwing away some traffic, bad middleboxes etc. These are not middleboxes, but part of the overall solution at the end-network - and as such they increase operational cost - but they bring more resilience and stability to the service. They even work using the existing hardware devices in many circumstances, making the cost less than buying “DDoS protection service box model 2000"
YMMV, and you should always consider your own environment, adding DNSSEC comments are great etc. Some things SHOULD be discarded, others rate-limited I don't have problems with discarding, but again it should be done where the impact is understood and a router doesn't have that. Doing opaque dropping to the outbound of a resolver even while part of the solution can have weird effects and should be avoided.
and shameless link https://ripe72.ripe.net/wp-content/uploads/presentations/32-simulated-ddos-r... which has similar advise Again that was during the attack and not permanent (Anand can correct me if I got it wrong). Also this was an authoritative server which has a different defence pattern that a resolver that was described in the article.
So long -Ralf
participants (6)
-
Carlos M. Martinez -
Henrik Lund Kramshøj -
Mirjam Kuehne -
Nick Hilliard -
Ralf Weber -
Stephane Bortzmeyer