Portal Home > Knowledgebase > Articles Database > DNS Amplified Attack? How to stop it, urgent!


DNS Amplified Attack? How to stop it, urgent!




Posted by todd001, 09-08-2013, 03:06 AM
How can i protect it ? Bind and named are removed and only one i have now is tinydns or djbdns but not running ... Can i totally close port 53 ? Or it wont help ? So when i do I got

Posted by NetworkPanda, 09-08-2013, 03:23 AM
You didn't need to remove Bind. You could edit named.conf and add this line in the "options" section: I don't know if tinydns or djbdns have such options, so it could be better to remove them, reinstall Bind and add the above line to its configuration. Then, if you are on cPanel restart it with: or if not running cPanel:

Posted by todd001, 09-08-2013, 03:42 AM
Ok all is removed and not running to be sure for now... Oh and it was kloxo, and that allow-recursion { "none";}; wont help i tried, so i better removed whole dns stuff, dont removed but by installing tinydns kloxo crap broken it and it no more works, better i dont need it ... I did: According to this site -> dns.measurement-factory.com/cgi-bin/openresolvercheck.pl the resolver is CLOSED which is good ... And got: Port 53 is closed but i still can see that attack on port 53 ??

Posted by todd001, 09-08-2013, 05:57 AM
really there is no way to remove that crap udp protocol from server ? or totally block it ? iptables wont help and firewall too ...

Posted by todd001, 10-28-2013, 04:12 AM
Port 53 was all the time blocked by firewall. As of 23-October 2013 we help for loggin the UDP ddos and was stopped due to info we collected and started post to pastebin -> pastebin.com/u/scriptz-team (Example: pastebin.com/6ku2VhVy) Every single ip is logged and being reported to ISP to investigate. Last edited by todd001; 10-28-2013 at 04:20 AM.

Posted by khunj, 10-28-2013, 10:03 AM
Those IPs are spoofed: attackers put the victim's IPs so that your server will reply/attack them. That is the main goal of a DNS amplified attack.

Posted by todd001, 10-28-2013, 10:13 AM
these ips exists, and once they exists, you can report them for abusing ISP service, i dont think its allowed to ddos from leased ip you pay for, even you dont know about it, you will know when isp or host nullroute your ip for being ddos someone else host. we report, and we will do in future.

Posted by EvolutionCrazy, 10-28-2013, 10:36 AM
As said above those are spoofed IPs, you should report the real source, not the spoofed one.

Posted by todd001, 10-28-2013, 11:11 AM
Those "spoofed" ips are real and exists (its the source that attacker use to attack my server ip), as i was told those ips are infected and sending requests to my server ip. Easy to track them via -> tcpdump -n udp dst port 53|grep ANY

Posted by EvolutionCrazy, 10-28-2013, 11:18 AM
Who told you those are infected? That command does not show the real source but only parse the header. Does the TTL seems real to you? Generally it's not.

Posted by Infinitnet, 10-28-2013, 11:53 AM
Well, if it's too much traffic for your server to handle even with the iptables rules you mentioned, it might make sense to get an external DDoS protection. The IPs you are seeing are in fact just the actual targets of the attack and not the source. Edit: Actually it should be enough to just change your IP, so you don't use the one that's in an "open resolver" list anymore.

Posted by todd001, 10-28-2013, 12:06 PM
Well i dont want to be bad or so but i starting thinking that ddos is new marketing for ANTI-DDOS companies. They ddos you and you need to order anti-ddos proxy or so. Also well, see this from our logs: ------ -------------- COUNT IP ------ -------------- 210058 37.48.64.204 -- netname: LEASEWEB descr: LeaseWeb And now tell me that i was used to ddos that ip? No! The ip 37.48.64.204 was logged 210058x and the ip 37.48.64.204 is infected (used in one larger ddos) and ddos my server via UDP.

Posted by derp, 10-28-2013, 12:16 PM
As everyone else is saying. Your 37.48.*.* IP is not the attacker. That IP is the target. It's the victim. The way a DNS amplification attack works is, the attacker will go and send packets and modify the source IP header to be that of its target. It will send these packets to as many DNS servers (similar to what you have). The idea is that your server will get the packet, your server will think that the fake source IP requested a DNS lookup and send to that IP the response. Your DNS server's response is significantly bigger than what the attacker is sending you, so in effect your server is helping with amplifying the data amount that the target has to deal with. You cannot find the attacker. You need to ask your host for help for that and it's not a trivial procedure. You'd need cooperation from every router operator that those packets pass through.

Posted by todd001, 10-28-2013, 12:20 PM
So well again, my server dns resolver was discovered time ago since never ever before heard about that (missed that, my mistake), but if i did tcpdump and also added src for source and not dst for destination, i saw that source was all those ips, how then? Plus i did iftop -f udp to see who eat all the BW/packets, and since i fixed and blocked whole port 53 i saw that those ips sending BW/packets to my server and i did not send nothing out

Posted by Infinitnet, 10-28-2013, 12:21 PM
It's quite possible that some fishy anti DDoS providers attack their own clients or potential clients to generate more sales. However, no reputable company would do such thing. Nowadays it's become very easy for everyone to start DDoS attacks, because there are plenty of cheap booters around anymore can use without any tech knowledge. Obviously this increases the quantity of DDoS attacks. Well, from the logs you posted it looks like those IPs are trying to query your DNS for values for domain names (like anonsc.com), right? With a DNS amplification attack the open resolver (ie. the "zombie" DNS) is being queried for values, where these queries have the source IP spoofed to appear to come from the machine which is the actual target. Your DNS in this case would then send the query result back to the IP the query appears to come from and the answer is larger than the request, which makes it possible to generate huge attacks with relatively small bandwidth used to generate the attack. If you have more UDP traffic out than in, then you're just being used as a "zombie" and you're not the target of the attack. That's easy enough to check. Afterall, I could be misunderstanding your logs.

Posted by derp, 10-28-2013, 12:23 PM
There's not much of a misunderstanding. You're 100% certainly being used as a zombie. You aren't the target. Disable recursion, or turn off DNS if you aren't using it, or limit recursion to only a few authorized IP addresses. There's not really another solution.

Posted by Infinitnet, 10-28-2013, 12:27 PM
The source IP addresses you see are all fake, the queries are not actually coming from these IPs - the packet header is just modified to make it look like it to your server. That's why. You might want to read an article on how exactly such an attack works: https://www.cert.be/pro/docs/dns-amp...-dns-resolvers

Posted by todd001, 10-28-2013, 12:31 PM
if someone wanted to use my server as "zobie" why this today comes this (port 80 ddos), it seems like once you are on list and used in bigger ddos you cant easilly turn it off:

Posted by Infinitnet, 10-28-2013, 12:39 PM
These IPs look spoofed as well. I doubt that the DoD and a lot of other govt IPs are attacking you. There are TCP reflection attacks as well. They usually don't generate as much bandwidth as UDP/DNS attacks, but they can be quite effective anyway. If you're that particular that you're the target of these attacks and not a victim used to generate attacks, I wonder why don't you get a DDoS protection or talk to your hosting provider and see if he can do anything about it? It would be quite messy to try to block all this with iptables.

Posted by todd001, 10-28-2013, 12:47 PM
They have auto IDS to nullroute ip. Also as of now tcpdump -f udp: 19:45:50.743025 IP MY_SERVER_IP.vaprtm > 8.8.8.8.53: 33559+ A? db.local.clamav.net. (37) 19:45:55.743265 IP MY_SERVER_IP.jdmn-port > 8.8.4.4.53: 33559+ A? db.local.clamav.net. (37) 19:46:00.743574 IP MY_SERVER_IP.pit-vpn > 8.8.8.8.53: 11629+[|domain] 19:46:05.743803 IP MY_SERVER_IP.48065 > 8.8.4.4.53: 11629+[|domain] 19:46:10.744062 IP MY_SERVER_IP.pit-vpn > 8.8.8.8.53: 11629+[|domain] 19:46:15.744302 IP MY_SERVER_IP.48065 > 8.8.4.4.53: 11629+[|domain]

Posted by Infinitnet, 10-28-2013, 12:49 PM
That would be just your own server resolving domains it connects to using the Google resolvers.

Posted by todd001, 10-28-2013, 12:54 PM
Okay, so if i kill process -> named or do service named stop i still dont know why it wont helps to being not ddosed as if you turn of recursion in bind/named, i just turned off whole dns service on my server not? //The more funny part is that as of today i wrote about that logs we started making and post on pastebin, the ddos started agin but on port 80 not 53, hmm someone watching (maybe in that logs is one and real attacker ip? who know, but i will not takes things easy and i will hunt those fukers till they die). Last edited by todd001; 10-28-2013 at 01:00 PM.

Posted by Infinitnet, 10-28-2013, 01:00 PM
You shouldn't fully disable recursion, but restrict it to localhost. You can use the search function on WHT, there are plenty of threads about this or just use Google on how to secure your DNS by restricting recursion. This would not stop your DNS from working, but just from resolving domains that are not hosted on that server (if restricted to localhost) or in your network (if restricted to localhost + your own IP ranges).

Posted by todd001, 10-28-2013, 01:03 PM
i did: allow-recursion { "none";}; not helped then: iptables -A OUTPUT -s 8.8.8.8 -p UDP --dport 53 -j ACCEPT iptables -A OUTPUT -s 8.8.4.4 -p UDP --dport 53 -j ACCEPT iptables -A INPUT -p UDP --dport 53 -j DROP not helped god really isnt there any option to somehow broke/destroy/delete whole port 53 ?? Last edited by todd001; 10-28-2013 at 01:08 PM.

Posted by Infinitnet, 10-28-2013, 01:08 PM
It will not block the incoming queries - it will just prevent your DNS from answering to these queries.

Posted by todd001, 10-28-2013, 01:11 PM
how it wont block incoming ? INPUT is for inbound/income traffic not ?

Posted by Infinitnet, 10-28-2013, 01:21 PM
I was talking about the "allow-recursion { "none";};" that you apprently added to your bind9 config.

Posted by todd001, 10-28-2013, 01:26 PM
Aaaaha, understand but iptables -A INPUT -p UDP --dport 53 -j DROP should block incoming traffic not ?

Posted by Infinitnet, 10-28-2013, 01:29 PM
You should write "udp" and not "UDP", ie. lowercase. Also you will have to check your whole iptables rules to see if there is any other rule that might allow all traffic to port 53 and overrides your rules to drop it.

Posted by todd001, 10-28-2013, 01:35 PM
See traffic 1 day -> http://i.imgur.com/Nm9aIS4.png Firewall: # Clear rules service iptables stop iptables -F iptables -X iptables -t nat -F iptables -t nat -X iptables -t mangle -F iptables -t mangle -X #iptables -t filter -F #iptables -t filter -X echo - Clear rules : [OK] iptables -A INPUT -s MY_HOME_IP -p tcp --dport 21 -j ACCEPT iptables -A INPUT -s MY_HOME_IP -p tcp --dport 3306 -j ACCEPT iptables -A INPUT -s MY_HOME_IP -p tcp --dport 110 -j ACCEPT iptables -A INPUT -s MY_HOME_IP -p tcp --dport 25 -j ACCEPT iptables -A INPUT -s MY_HOME_IP -p tcp --dport 22 -j ACCEPT iptables -A OUTPUT -s MY_HOME_IP -p tcp --dport 22 -j ACCEPT iptables -A OUTPUT -s 8.8.8.8 -p UDP --dport 53 -j ACCEPT iptables -A OUTPUT -s 8.8.4.4 -p UDP --dport 53 -j ACCEPT iptables -A OUTPUT -o venet0 -p tcp --sport 25 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A OUTPUT -o venet0 -p tcp --dport 25 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -i venet0 -p tcp --sport 25 -m state --state ESTABLISHED -j ACCEPT iptables -A OUTPUT -o venet0 -p tcp --sport 993 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A OUTPUT -o venet0 -p tcp --dport 993 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -i venet0 -p tcp --sport 993 -m state --state ESTABLISHED -j ACCEPT iptables -A OUTPUT -o venet0 -p tcp --sport 995 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A OUTPUT -o venet0 -p tcp --dport 995 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -i venet0 -p tcp --sport 995 -m state --state ESTABLISHED -j ACCEPT iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP iptables -A INPUT -f -j DROP iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP iptables -A INPIT -p tcp --tcp-flags ALL NONE -j DROP iptables -A INPUT -p tcp --dport 80 -m limit --limit 1/second --limit-burst 50 -j DROP iptables -A INPUT -p icmp -j DROP iptables -A OUTPUT -p icmp -j DROP iptables -A INPUT -p tcp --dport 21 -j DROP iptables -A INPUT -p tcp --dport 443 -j DROP iptables -A INPUT -p tcp --dport 25 -j DROP iptables -A INPUT -p tcp --dport 143 -j DROP iptables -A INPUT -p tcp --dport 43 -j DROP iptables -A INPUT -p tcp --dport 110 -j DROP iptables -A INPUT -p tcp --dport 22 -j DROP iptables -A INPUT -p tcp --dport 3306 -j DROP iptables -A INPUT -p UDP --dport 53 -j DROP iptables -A INPUT -p tcp --dport 993 -j DROP iptables -A INPUT -p tcp --dport 995 -j DROP echo - Firewall [OK] service iptables save service iptables start

Posted by Infinitnet, 10-28-2013, 01:38 PM
This should be: iptables -A INPUT -p udp --dport 53 -j DROP Obviously iptables will not prevent the traffic from reaching your server - it will just not process the packets and drop them.

Posted by todd001, 10-28-2013, 01:39 PM
No matter if UDP or udp as if i did http://www.yougetsignal.com/tools/open-ports/ and entered server ip and port 53 it shows closed. I just want to destroy port 53

Posted by GreenHornet, 10-28-2013, 01:40 PM
todd001, there is a difference between an attack targeted on your server and an attack which is actually exploiting your server and use its power to attack others (like amplification floods could be). Most likely every attack on your server is from spoofed IPs which for sure exist and are real but their owners does not even know that their IPs are being used for executing DDoS attack, so there is no point of reporting/blocking them. There is even a chance when you will block/report visitors of yours... Only application layer attacks are being executed from not spoofed IPs which are worth reporting/blocking.

Posted by Infinitnet, 10-28-2013, 01:41 PM
As I said, iptables will just drop the packets but not stop them from reaching your server. If you don't want such traffic to reach your server, you need a DDoS protection or you can ask your hosting provider to add an ACL for your IP to drop any incoming UDP traffic with dst port 53 except from 8.8.8.8 and 8.8.4.4, although only very few providers would add custom ACLs to their routers.

Posted by todd001, 10-28-2013, 01:43 PM
Will ask hosting ... Also anyone know a way to destroy/delete UDP or port 53 just need to delete it totally its like if i dont have apache/nginx then port 80 is closed no ? then why i can not just close port 53 ?

Posted by GreenHornet, 10-28-2013, 01:44 PM
Also blocking traffic on particular port most likely will not help at all, because the attack traffic will still enter your provider's network and if it is massive it could result in your IP to be nullrouted.

Posted by Infinitnet, 10-28-2013, 01:45 PM
You did close it by shutting off bind9 and any other DNS service and you did block it with the iptables rules. Still the packets will reach your server. You can only completely block this traffic from reaching your server by asking your provider to add an ACL to his routers to drop UDP traffic to port 53 on their routers before it reaches your server.

Posted by todd001, 10-30-2013, 04:20 AM
Also did apache benchmark just for test and is there a way to limit speed of transfer ? Also "Failed requests: 238" means that my anti-ddos soft does not let pass those requests ? [root@hosted ~]# ab -n 250 -c 100 http://---/ This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking --- (be patient) Completed 100 requests Completed 200 requests Finished 250 requests Server Software: --- Server Hostname: --- Server Port: 80 Document Path: / Document Length: 5344 bytes Concurrency Level: 100 Time taken for tests: 0.382 seconds Complete requests: 250 Failed requests: 238 (Connect: 0, Receive: 0, Length: 238, Exceptions: 0) Write errors: 0 Non-2xx responses: 238 Total transferred: 422494 bytes HTML transferred: 343302 bytes Requests per second: 654.78 [#/sec] (mean) Time per request: 152.723 [ms] (mean) Time per request: 1.527 [ms] (mean, across all concurrent requests) Transfer rate: 1080.63 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 4 5 0.5 5 8 Processing: 25 120 32.0 129 259 Waiting: 20 120 32.6 129 258 Total: 30 125 32.0 134 263 Percentage of the requests served within a particular time (ms) 50% 134 66% 136 75% 137 80% 138 90% 153 95% 167 98% 177 99% 208 100% 263 (longest request)



Was this answer helpful?

Add to Favourites Add to Favourites    Print this Article Print this Article

Also Read