Post by Dhaupin » Wed Sep 24, 2014 3:54 am

According to various stats there are still millions of servers open to DNS amplification. This is a basic thesis on how to protect your server from becoming a node or slave in a chain of DDOS to a target. Ill try to explain it simply using BIND on a CentOS VPS with SSH access...if anyone has info to add (like for windows or something) feel free to share.

Skill Level: Advanced This is a in depth level of server management, please don't attempt any of this unless you are comfortable, have your host fix it instead.



Get on with it. What is a DNS amplifier and how does this effect my server?
We all know about trojan based DDOS attacks, basically a piece of bad software turns your home PC silently against a target of the botnets choice. But this can happen to your web server in a way too.

DNS amplification means someone can connect via your DNS server via recursion to take part in a greater flood on a target. Since its via your server, it has the effect that its from you. Often these are triggered from a single deploy IP, which may be part of underlying chains of amplifiers/zombies/slaves. This is similar to how those trojan based attacks work, and in some cases may make relays for those trojan-based zombies to pass through.



Wait what?? How do I find out if my server is vulnerable to becoming an amplifier?
Step 1) you should SSH into your server and check to see what version of BIND you're running using the command "named -v". Ideally it should be far above BIND 9.2.x, preferably above 9.8.8 as of writing this article. This fixes various bugs that aide malfeasants to abuse your DNS.

Step 2) grep your /var/log/messages for DENIED entries from shadowserver.org, if-is.net, or openresolverproject.org. This should tell you right away if you're denying passthroughs.

Step 3) attempt to access Google via your DNS by using command "nslookup google.com 123.123.123.123" where 123.123.123.123 is your name server IP. It should return ** server can't find google.com: REFUSED

Optionally, you can use an online test although i wouldnt trust the results and opt for server based testing on your own. An example is this: http://smurf.powertech.no/

If you find many DENIED and your tests say REFUSED, and you pass optional test site, youre good to go and your DNS will refuse pass-through. If it failed tests, see next steps.



I didn't find any DENIED from those domains in logs and/or my nslookup allowed pass to google.com, how do I fix my server?
Simple Answer) This is beyond the scope of this small tutorial. Contact your host and if you need show them this article. They would have the best tailored config for your server to button it up. This is not an area for the average Joe since parts of the config may require a "trusted" list of IP's or localnets pointed for other servers/utilities.

Advanced Answer) If you are comfortable in your server, and using BIND settings with possible ACL, you can attempt to amend this by restricting allow-recursion{} within the options{} of /etc/named.conf. Normally this is set up in 1 of 2 ways, and if nothing is set, most servers revert to "any" request allowed:


Ok i fixed it, but now my DNS logs are being flooded by strange DENIED for random sites, IP's, or ports?
This is a sign that folks are attempting to pass through. An example of a malicious attempt via your DNS looks like this as a log line in /var/log/messages:

Code: Select all

Sep 22 15:51:15 SERVER-NAME named[1489]: client 162.212.181.242#48747: query (cache) 'wwww.jrdga.info/A/IN' denied
It can be from multiple client IP's on multiple ports. Often, checking the client Ip will reveal a recorded replication server in sites like sans or projecthoneypot.org -- youre safe to ban the bad ones. For a rough list of known passthrough attempts you can visit http://dnsamplificationattacks.blogspot.com/ Keep in mind, the fact that its logging can be a hinderance if a massive flood is encountered. DNS can handle like 65k requests a second with minimal performance loss, but if its logging all of them (like the above denied line) it will start to bog things. Just keep that in mind :)



Thats about it. By forcing recursion to only allow localnet or trusted sources, you have buttoned your DNS. Running the test again in step 3 should return REFUSED, and checking logs should eventually start to show you all the requests DENIED trying to tunnel through to their target. Hope that helps clarify it a bit and that it helps to harden your server.

https://creadev.org | support@creadev.org - Opencart Extensions, Integrations, & Development. Made in the USA.


User avatar
Active Member

Posts

Joined
Tue May 13, 2014 3:45 am
Location - PA
Who is online

Users browsing this forum: No registered users and 32 guests