Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Why not just ban inbound port 53 traffic on all VPS?
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.

Why not just ban inbound port 53 traffic on all VPS?

pechspilzpechspilz Member
edited March 2013 in General

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.

«1

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).

  • KrisKris Member
    edited March 2013

    @Jack said: Because people have dns services running?

    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.

  • RalliasRallias Member
    edited March 2013

    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.

    @Kris said: /etc/named.conf or /etc/named.caching-nameserver.conf, and 5 minutes of sed.

    You happen to be willing to share the specific command? This isn't something I considered yet.

  • MunMun Member

    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.

  • @Mun said: 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

  • KrisKris Member

    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.

  • @Kenshin said: 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.

    They usually only hit your node with 2-3 mbit/s IN. It's when you're sending OUT traffic that it causes issues.

  • MunMun Member

    @Rallias said: No, most people who run kloxo without securing it is where the problem is.

    By default, our images only recurse for localhost AFAICT.

    LOL thus another reason why Kloxo sucks, but there is other cases such as the default Debian image which has bind installed.

  • KrisKris Member

    Also:

    On BIND9 implementation running the RRL patches, add the following lines to the options block of the authoritative views [13]:

    rate-limit {
    responses-per-second 5;
    window 5;
    };
    

    Beta, but if you have an open resolver and are getting pounded, could help.

    Otherwise, I just turn recursion off.

  • edited March 2013

    @Kris said: On BIND9 implementation running the RRL patches

    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.

  • KrisKris Member

    @pechspilz said: What's the point of an authoritative DNS on a LEB?

    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.

  • @pechspilz said: What's the point of an authoritative DNS on a LEB?

    You have full control over your own dns-settings. Same reason why people want root-access.

  • jarjar Patron Provider, Top Host, Veteran
    edited March 2013

    @Kris said: sed -i 's/recursion yes;/recursion no;/' /etc/named.conf

    +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

  • KrisKris Member
    edited March 2013

    Didn't work quite right, I like to find out via

    grep recursion /vz/private/*/etc/named*.conf
    

    Checks both named.conf and named.caching-nameserver.conf

    netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n
    

    Also helps quite well if the system's getting hit left right and center.

  • emgemg Veteran

    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:

    1. Respond to external queries for my domains only. All others get dropped.
    2. Respond to internal queries for any domain - in other words, only if it originates from a process in the VPS itself.
    3. Implement response rate limiting without being forced to recompile bind every time a security patch is released.
    4. Do it all without relying on a control panel. Someday I will use control panels, but I want to understand what they do under the hood, so I can easily troubleshoot issues in the future.

    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

  • jarjar Patron Provider, Top Host, Veteran
    edited March 2013

    @Patrick said: Providers can check this as a guideline:

    If I'm to believe that, I've got 5 clients to take care of, wow my life is hard :P

  • @jarland said: 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

  • nutjobnutjob Member
    edited March 2013

    @pechspilz said: With all the recent talk about DNS amp DDOS attacks...

    If they really want to avoid any DOS problems providers should just block all ports.

  • DomainBopDomainBop Member
    edited March 2013

    @Jack http://openresolverproject.org doesn't seem to update.

    the real-time accuracy of their lists is on a par with that of Spamhaus's lists :P

    @pechspilz 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 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. :

  • jarjar Patron Provider, Top Host, Veteran
    edited March 2013

    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.

  • MunMun Member

    I fully agree with blocking port 53, and having to put in a ticket to use it. :)

  • liviuliviu Member

    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

  • MunMun Member

    @texteditor said: Block all inbound and outbound traffic on port 53

    ughh no.

  • @Mun said: ughh no.

    Agreed, that is just excessive

Sign In or Register to comment.