New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Why not just ban inbound port 53 traffic on all VPS?
With all the recent talk about DNS amp DDOS attacks, I wonder why none (?) of you LEB providers just blocks inbound port 53 traffic to all VPS?
The number of VPS users who need an open DNS resolver most likely is very small and the number of users who know how to protect an open DNS resolver is a fraction of it. It's just asking for trouble, not worth the hassle. Even though it might not affect your network in a big way, the spoofed target address of the DNS response certainly is affected.
I know there are cool tools like Iodine which will be affected by such a ban.
Comments
Because some people want to use their VPSes for name servers (authoritive).
Both recursive and authoritive name servers run on the same port (53).
This. If it's cause issues, turn recursion off.
/etc/named.conf or /etc/named.caching-nameserver.conf, and 5 minutes of sed.
Run a script at the host-node level if you want to turn recursion off on every container, but don't block DNS ports inbound, that would be daft.
I AM implementing blocks on DNS for those PROVEN TO RUN A RECURSIVE DNS. They were warned, it's not my fault they ignored our message.
You happen to be willing to share the specific command? This isn't something I considered yet.
Why don't they just not install bind by default on the VPS images? Most people who don't know bind is there is where the problem really occurs.
No, most people who run kloxo without securing it is where the problem is.
By default, our images only recurse for localhost AFAICT.
Blocking incoming doesn't mean the traffic doesn't come in. It just means the vps doesn't see it but the node likely still completely flooded with traffic and still can't be accessed.
Why reinvent the wheel? he.net, cloudflare anycast dns, linode dns, afraid.org
sed -i 's/recursion yes;/recursion no;/' /etc/named.conf
sed -i 's/recursion yes;/recursion no;/' /etc/named.caching-nameserver.conf
Most managed clients / even the self managed clients haven't a clue, so we've started to disable them with that in a script, executed on all containers.
Can be modified for host-node level to work with /vz/private/CTID/etc/named.conf but we've been running it within the container.
They usually only hit your node with 2-3 mbit/s IN. It's when you're sending OUT traffic that it causes issues.
LOL thus another reason why Kloxo sucks, but there is other cases such as the default Debian image which has bind installed.
Also:
On BIND9 implementation running the RRL patches, add the following lines to the options block of the authoritative views [13]:
Beta, but if you have an open resolver and are getting pounded, could help.
Otherwise, I just turn recursion off.
This.
I'm using this now, working very well.
In RH6 it is patched in the official package, for ArchLinux
bind-rl
is available in AUR, not sure about other distributions.What's the point of an authoritative DNS on a LEB?
I mean okay, it's nice to try things out and see how they work (you could do this on a local network as well btw.) but wouldn't (almost) anyone want to just use a high-availability auth DNS? There are still a few free ones out there and some domain registrars even provide them for free for domains bought through them.
Mostly it's our clients, but when they wish to use it - best you can / should do is turn recursion off, apply updates / patches when you can for them.
There will always be those that want to re-invent the wheel.
You have full control over your own dns-settings. Same reason why people want root-access.
+1
Script it, give clients a window to opt out, automate the change for every client. Then simply alter your templates. That's in my list of things to do. Gonna have to borrow from Blizzard for the schedule... http://www.wowwiki.com/Soon
Didn't work quite right, I like to find out via
Checks both named.conf and named.caching-nameserver.conf
Also helps quite well if the system's getting hit left right and center.
I am currently blocking port 53 on my VPSs. When I am ready, I would like to set up two of them to be primary and secondary (master and slave) DNS servers for my domains. Here is what I would like to do:
I am currently running Debian 6 on my VPSs. Based on comments above, an RRL version of bind is not included with the standard set of updates yet.
Is that so hard to do? I have been looking at many many web pages on how to configure DNS servers, but good, complete, and straightforward documentation is lacking. Too many of them assume that the administrator is running Kloxo or Webmin or cPanel.
Can you suggest any hints or links?
You could pair dns-flood-detector with fail2ban to (temporarily) ban an IP address if it hits a certain threshold within a certain timeframe.
Providers can check this as a guideline:
http://openresolverproject.org
If I'm to believe that, I've got 5 clients to take care of, wow my life is hard :P
Possibly, commonly to do with cPanel/Kloxo.
We had about 10 on each /24 which we opened a individual ticket to sort out but also about to mass mail all clients as well. About 90% was from the Kloxo Host In A Box template we have when they were running BIND
If they really want to avoid any DOS problems providers should just block all ports.
the real-time accuracy of their lists is on a par with that of Spamhaus's lists :P
The security risks of open resolvers have been known for years. If datacenters want to decrease risks maybe they should think about blocking the ports of all providers who were clueless about the problem before it was publicized in the mass media this week. :
Could've, should've, would've...
Don't amount to a hill of beans right now
It's in our face so now it gets dealt with. That's usually how life goes.
I fully agree with blocking port 53, and having to put in a ticket to use it.
I'm using UDP/53 with several providers for OpenVPN. Blocking it == one less customer
Bind RRL is the way to go, or similar with other DNS services
Block all inbound and outbound traffic on port 53
ughh no.
Agreed, that is just excessive