4

I need a little help dealing with ddos. I'm experiencing 1gb ddos attack on my server and I don't know how to stop it. (1gbs is the maximum speed of the server.)

I've the following iptables rules:

 iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
 iptables -A INPUT -p tcp --dport 22 -j ACCEPT
 iptables -A INPUT -p tcp --dport 80 -j ACCEPT
 iptables -A INPUT -p tcp --dport 8080 -j ACCEPT
 iptables -A INPUT -i lo -j ACCEPT
 iptables -A INPUT -j DROP

however with tcpdump I can see packets coming from from port 53

12:14:40.341410 IP 195.137.162.149 > x.x.x.x: ip-proto-17
12:14:40.341411 IP 193.169.188.52.53 > x.x.x.x.23495: 23454- 0/4/6 (234)
12:14:40.341414 IP 195.248.88.120 > x.x.x.x: ip-proto-17
12:14:40.341416 IP 193.19.184.42.53 > x.x.x.x.50529: 26701| 6/0/1 TXT[|domain]
12:14:40.341418 IP 192.41.13.71.53 > x.x.x.x.10634: 23454| 6/0/1 TXT[|domain]
12:14:40.341418 IP 50.97.53.214.53 > x.x.x.x.65437: 23454| 6/0/1 TXT[|domain]
12:14:40.341419 IP 192.3.130.149.53 > x.x.x.x.57519: 24820| 6/0/1 TXT[|domain]
12:14:40.341438 IP 195.182.58.136 > x.x.x.x: ip-proto-17
12:14:40.341441 IP 193.234.216.12 > x.x.x.x: ip-proto-17
12:14:40.341442 IP 195.228.85.145.53 > x.x.x.x.7903: 37969| 6/0/1 TXT[|domain]
12:14:40.341512 IP 192.195.177.60.53 > x.x.x.x.42871: 57501- 0/13/23 (718)
12:14:40.341552 IP 192.210.150.10.53 > x.x.x.x.41447: 25994| 6/0/1 TXT[|domain]
12:14:40.341556 IP 193.28.177.41 > x.x.x.x: ip-proto-17

iptables -xnvL

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
  415575 293176304 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state ESTABLISHED
   24101  1323153 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80
   19725  1182436 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:8080
       2      104 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
13101233 35329988490 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 488686 packets, 518540789 bytes)
    pkts      bytes target     prot opt in     out     source               destination

in nginx i've

limit_req_zone  $binary_remote_addr  zone=one:10m   rate=5r/s;

in this screenshot you can see the actual numbers. my normal usage is no more than 5mb/sec. enter image description here

netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n | tail | grep -v "127.0.0"

 13 87.149.x.x
 14 95.68.x.x
 15 109.186.x.x
 15 84.108.x.x
 15 91.231.x.x
 17 162.17.x.x
 18 82.212.x.x
 82 151.248.x.x
 94 79.180.x.x
Orlo
  • 231
  • 1
  • 3
  • 11
  • 1
    What is the network speed of the server? If the attack is larger than your server's capacity, you will likely need to mitigate upstream and not at the server level. – jeffatrackaid Jan 02 '14 at 16:25

3 Answers3

7

As far as I can see, the iptables question is a red herring: your rules are dropping these packets just fine, hence the very large packet counts on your fifth and final rule (the DROP rule).

I presume from your question that you want not just to drop them, but not to see them on your port at all, and that can only be achieved by talking to your provider. Simply having them block all inbound UDP traffic with source port 53 will probably stop the server working, as it will break DNS, but if you can reconfigure your server to only use two or three specific upstream DNS servers there is some chance of getting your provider to block all other inbound port 53 traffic.

Edit: my commiserations on your poor provider. I think the issue of hardware firewalls is irrelevant: one of those won't stop the traffic being delivered to your port, it will only sit between your port and your server and stop the traffic consuming resources on your server. Since I don't see any evidence above that it's causing any resource issues on the server I don't see how that will help you.

It would be very normal indeed for a responsible provider to agree to block temporarily certain kinds of traffic to a port, but if your provider won't do this, then I don't see you can do much but shrug, weather the storm, then look at other providers when your contract comes around for renewal.

MadHatter
  • 78,442
  • 20
  • 178
  • 229
  • The response I got: Thank you for your ticket. Unfortunately we are unable to block this port. In order to stop DDOS attacks you will need to purchase a fire wall product, please see our website. – Orlo Jan 02 '14 at 16:49
  • So basically time to find a new provider. The hardware firewall will not help. 100%, If you have a 1gb/s connection, all that will do is push the attack to the firewall, and fill that pipe. block 53, and maybe ride it out? – Doon Jan 02 '14 at 17:34
  • 1
    @Orlo This looks like the classic DNS amplification attack. Not a whole lot you can do if the provider is money-grabbing like they are now. – Nathan C Jan 02 '14 at 19:38
  • I do not think the provider really recommends to purchase a "hardware" firewall - more likely, it is selling some firewall option to its hosting packages where you could configure packet blocks to be set in the provider's core router. – the-wabbit Mar 07 '14 at 09:25
  • syneticon, you may be right; only the OP can clarify that. But if that is what his provider is doing, then my commiserations stand - as does my agreement with NathanC on his characterisation of the provider as "*money-grabbing*"! – MadHatter Mar 07 '14 at 09:40
  • @MadHatter I can't agree that it is *necessarily* money-grabbing. A provider might have a low-cost base line offering and add-on modules for people who need it. A core-router packet filter might be such an option, just as might be something like an IPv4 subnet. In the end, you might be hosting through a CDN and not feel the need for a packet filter option - why pay for it then? – the-wabbit Mar 07 '14 at 23:34
  • I think we may have to agree to disagree on what is expected, as a bare minimum, from a hosting provider. I **can** say, without fear of refutation, that I would flee such a provider as fast as my legs could carry me. – MadHatter Mar 08 '14 at 08:09
5

Assuming your port size is smaller then 1Gbps:

Simple answer. Get a hardware firewall. Fighting a dDoS, especailly one in the Gbps range is not going to happen at the actual server.

If all the traffic is coming from port 53, have your provider block port 53 upstream.

Jason
  • 3,821
  • 17
  • 65
  • 106
  • Dont you need port 53 for DNS? – ProfessionalAmateur Jan 02 '14 at 17:00
  • @ProfessionalAmateur You only need inbound 53 if the server is a DNS server. – ceejayoz Jan 02 '14 at 17:02
  • Or if it ever wants to look up a hostname for any purpose whatsoever. Inbound `dport` 53, sure, DNS servers only; but the traffic above is inbound `sport` 53, and you can't block that across the board without causing serious problems. – MadHatter Jan 02 '14 at 17:06
  • A common workaround would set up a block for traffic from sport 53 except for the traffic from the DNS resolver(s) your host is configured to use (i.e. non-local hosts listed in /etc/resolv.conf) – the-wabbit Mar 07 '14 at 09:52
-4

Install NGINIX and solve the issue it's a very nice piece of software and does the job there is plenty of literature to read up on about adding extra tools behind it or to make the config of the setup work for your issue.

Planet Host
  • 1
  • 2
    nginx's load balancing capabilities might not be super efficient with an heavy dDOS attack, especially if only one machine is targeted. – John WH Smith Mar 07 '14 at 09:18