UDP flood is irritating. How much irritating? It can simply blow away your instance in various ways, if network can somehow handle the load and you configured IPTables to rate limit, log can flood your disk space. Here is details on UDP Flood Attack and how to stop UDP Flood DDoS Attack on both cloud server & dedicated server. UDP is like old postal service where a fake person can actually flood with hundreds of postal letters without bearing postal stamp!
Coming towards the basics, UDP is User Datagram Protocol which is one member of the Internet protocol suite and defined in RFC 768. With this UDP, servers can send messages to other hosts on an Internet Protocol (IP) network which is referred as datagrams.
How might one check if a UDP port is open to another server? You really can’t, because UDP is a connectionless protocol. That means, contrary to TCP, when your server sends an UDP message to another server, there is no expectation that the receiver will send you back an acknowledgement. In fact, there is even no way for the receiver to do that; it’s a very simple protocol. When you send an UDP message, either the destination received it and processed it, or it didn’t. You have no way to know and there is no recovery mechanism. Theoretically, if an UDP port is formally closed (for example with an iptables REJECT rule), the destination host can reply with an ICMP “Port unreachable” packet to inform the sender. But there is no guarantee that it will do that, it can also silently drop the message. Again, this is very different from TCP. If someone sends a TCP connection request (a SYN packet) to a TCP port on a server, three things can happen:
- The server replies with a SYN,ACK packet. It means the connection is accepted and the port is open.
- The server replies with a RST packet. It means the connection is rejected and the port is closed.
- The server does not reply. After some time sender can assume the server either never received SYN and can try again or just ignored it (following a DROP iptables rule, for example). If multiple SYN receive no answer, sender can assume that the port is closed and firewalled.
So you can always determine the state of the TCP port. Conversely, if some sends an UDP message to a port on a server – either the server replies with an ICMP Port unreachable packet which means the port is “closed” and firewalled or the server replies nothing, which can mean anything, from the packet having been received and processed to no service listening on that port of the port being firewalled but differently (with a DROP and not a REJECT rule). So an attacker generally just can’t know what happened from the information given by the UDP protocol alone. In a UDP Flood, the attackers send spoofed UDP packets at a very high packet rate using a large source IP range. Random ports on the target machine are flooded with packets that cause it to listen for applications on that those ports and report back with a ICMP packet.
Advertisement ---
How To Stop UDP Flood DDoS Attack : Basic Idea For Cloud & Dedicated Server
While it is true that Cloud Server and Dedicated Server by principle same, but for dedicated server; you should talk with a real experienced sysadmin as datacenter, host, networking hardware has too much to do with UDP. As for Cloud Server, host will always do some networking monitoring and filtering for saving their own datacenter.
As for cloud servers, we can block at DNS level, use an anti-DDoS service, change the IP (rarely works), completely close UDP service via IPTables and so on. Around the IPtables part, we are going in to details in next paragraphs ahead.
As for the dedicated servers, things are same like cloud server but what your physical networking device configured that we do not know. Such attack may indicate more bigger flaw than simply irritating. That is why we talked about having discussion with an experienced sysadmin. The general solution is to buy extra hardware that will go in front of the server to look at the incoming packets.
How To Stop UDP Flood DDoS Attack Via IPTables
We have basic 3 guides on IPTables and Fail2Ban. Those are in general mandatory to follow. All UDP traffic can be completely blocked with the following :
1 2 | iptables -A OUTPUT -p udp -j DROP ip6tables -A OUTPUT -p udp -j DROP |
As rule of thumb, if you allow DNS with IP a.b.c.d and o.x.y.z before (example is for only IPv4) :
1 2 3 4 5 | iptables -A OUTPUT -p udp --dport 53 -d a.b.c.d -j ACCEPT iptables -A OUTPUT -p udp --dport 53 -d o.x.y.z -j ACCEPT iptables -A OUTPUT -p udp -j DROP ip6tables -A OUTPUT -p udp -j DROP |
then only that DNS will be allowed. It can be Dyn as your DNS for testing. There is difference between REJECT and DROP. Keep in mind that there is IPv4 and IPv6.
Unfortunately there not much you can do huge about UDP flood. You can setup server to ignore Pings to protect from ICMP/Ping flood so that an attack will be only 50% effective as server will not be replying to the thousands of Pings.
That can be done by running these :
1 2 | echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all nano /etc/sysctl.conf |
make the below line like this :
1 | net.ipv4.icmp_echo_ignore_all = 1 |
It is complicated matter as some host will require to leave ICMP Echo enabled, you can still use iptables to disable Ping in only some interfaces.
