[BlueOnyx:12715] Re: Proposed changes to BlueOnyx DNS (important!)

Stephanie Sullivan ses at aviaweb.com
Mon Apr 1 16:17:02 -05 2013


Michael,

While you are in DNS land with BX would you please consider the following
enhancement:
I would like to be able to setup default primary and secondary DNS server
IP's so when creating a new zone they are pre-filled. It would be a time
saver for sure and I hope it would be a simple addition.

I like option A. As we've discussed I run my DNS on dedicated servers vs on
each box and can't imagine anyone who allows recursion outside the subnet(s)
their servers are on. Though I'm sure some folks have a good reason... Yow!
Security is a very good thing.

	Thanks,
		-Stephanie

> -----Original Message-----
> From: Michael Stauber [mailto:mstauber at blueonyx.it]
> Sent: Sunday, March 31, 2013 11:46 PM
> To: blueonyx at mail.blueonyx.it
> Subject: [BlueOnyx:12701] Proposed changes to BlueOnyx DNS
> (important!)
> 
> Hi all,
> 
> I looked at ways to counter the DNS ANY? attacks natively in
> BlueOnyx.
> 
> My work at that has progressed to a point where I need maybe another
> hour to wrap it up and release it. But there are implications, so I'd
> like to ask the list what you think about the changes that are in the
> works.
> 
> - BlueOnyx 5107R, 5108R: Fully patched both use bind-9.8.2-0.17.rc1,
> which has the experimental rate-limit patch in it. Which counters
> some
> of the fallout of the ongoing DNS DDoS attacks. If there are too many
> queries from a given source and you have rate-limits enabled, then
> the
> offending host will be temporarily banned. At the moment BlueOnyx has
> no
> provisions for rate-limiting in named.conf
> 
> - BlueOnyx 5106R: The Bind on it is much older and doesn't have
> rate-limiting capability yet.
> 
> I managed to recompile the bind-9.8.2-0.17.rc1 for 5106R. So it's
> possible to release this much newer version through the BlueOnyx YUM
> repositories. BUT: This also means that whenever a new bind comes out
> for RHEL6 clones, I need to take that one and recompile it as well
> for
> 5106R and need to release it through the BlueOnyx YUM repository. I
> don't like that prospect much, but it's an option.
> 
> Additionally I reworked the "Advanced" tab in DNS management.
> 
> A new layout has been suggested here on the list, but the old GUI
> doesn't allow me that flexibility. So what I have now in the making
> is this:
> 
> 
>  Allow DNS Query Access 		[x]
>  Allow Queries from Everyone		[x]
>  		 -------------------------------
>  Allow Queries	 | 127.0.0.1/32			|
>  from these	 |				|
>  Networks:	 |				|
> 		 -------------------------------
> 
>  Allow DNS Cache Access 		[x]
>  Open DNS Server (Not recommended!)	[ ]
>  		 -------------------------------
>  Allow Cache	 | 127.0.0.1/32			|
>  access from	 |				|
>  these Networks: |				|
> 		 -------------------------------
> 
>  		 -------------------------------
>  Forwarding	 | 				|
>  Servers:	 |				|
> 		 |				|
> 		 -------------------------------
> 
>  		 -------------------------------
>  Zone Transfer	 | 				|
>  access by IP	 |				|
>  Address:	 |				|
> 		 -------------------------------
> 
>  Rate Limits Enabled:	 		[x]
>  Responses per Second: 			 5
>  Window: 				 5
> 
> The settings shown above are my proposed defaults.
> 
> Some extra explanations: The checkboxes "Allow Queries from Everyone"
> and "Open DNS Server (Not recommended!)" will add "0.0.0.0/0" to the
> addresses in the large input text boxes if they are ticked. I have to
> handle this differently, because the GUI thinks 0.0.0.0/0 is not a
> valid
> network address range and I'm unable to fix the broken regular
> expression that's currently in place there.
> 
> The problem:
> ============
> 
> The above default settings will create the following options{}
> section
> in /etc/named.conf:
> 
> options {
>   directory "/var/named";
>   // spoof version for a little more security via obscurity
>   version "100.100.100";
>   // no forwarders defined
>   // zone transfer access denied
>   allow-transfer { none; };
>   allow-query { 0.0.0.0/0; 127.0.0.1/32; };
>   allow-recursion { 127.0.0.1/32; };
>   // recursion allowed
>   rate-limit { responses-per-second 5; window 5;};
> 
> };
> 
> When I push this update out as it is, then all enabled DNS servers on
> BlueOnyx 5106R, 5107R and 5108R will inherit these settings.
> 
> Forwarders and zone transfer will not be modified. That info stays as
> it
> is. But query access gets allowed for everyone and recursion is only
> allowed from localhost. Additionally rate-limits are turned on.
> 
> You see the problem: If you are currently running an open DNS server
> (by
> accident, intent or imagined necessity), then this might throw a
> wrench
> into your setup.
> 
> If your BlueOnyx uses it's own DNS server as resolver, it can still
> query for domains that it's not authoritative for and will get a
> valid
> answer. But any other box that uses your BlueOnyx as a resolver will
> not
> be able to query anything but the domains you have zones for. Unless
> you
> go in and add the IP addresses or address ranges of those allowed
> servers into the "Allow Cache access from these Networks" input field
> and save the changes.
> 
> Now please note: The "rate-limits" are *really* nice to have. But
> enabling them doesn't entirely solve the problem. So just turning
> those
> on and leaving the DNS server entirely open isn't a great idea.
> 
> 
> So what do you suggest?
> =======================
> 
> a.) Do we bite into the sour apple and release this update that (for
> once) enforces a more secure DNS server setting (which can then be
> opened up as far as every admin desires)?
> 
> IF we release this as I suggest, then some people will probably get
> upset when their DNS server no longer works as the open DDoS-attack-
> tool
> that it unwittingly might have become in the meantime.
> 
> b.) Or do we go the safe and insecure route and only enforce ...
> 
> allow-recursion { 127.0.0.1/32; };
> 
> ... only on new installs and release it with ...
> 
> allow-recursion { 0.0.0.0/0; };
> 
> ... as it's now?
> 
> Personally I tend to option (a) and want it locked own and damn the
> consequences. But I'm willing to listen to reason. :-)
> 
> So let me know your thoughts. Thanks!
> 
> --
> With best regards
> 
> Michael Stauber
> _______________________________________________
> Blueonyx mailing list
> Blueonyx at mail.blueonyx.it
> http://mail.blueonyx.it/mailman/listinfo/blueonyx




More information about the Blueonyx mailing list