methods of combating DoS/DDoS attacks

Your morning starts with reading bug reports and analyzing logs. You update the software daily
and update the firewall rules hourly. Snort is your best
friend, and Zabbix is your invisible assistant. You have built a real bastion, which
cannot be approached from any side. But! You are completely defenseless against the most
insidious and vile attack in the world - DDoS.

It's hard to say when the term DoS attack first appeared. Experts talk
about 1996, hinting along the way that this type of attacks "reached" the masses only in
In 1999, when Amazon, Yahoo, CNN, and eBay websites fell one after another.
Even earlier, the DoS effect was used to test the stability of systems and
communication channels. And if you dig deeper and use the term DoS to
denote the phenomenon, it becomes clear that it has always existed, since the days
of the first mainframes. That's just thinking about it as a means of intimidation
began much later.

In simple terms, DoS attacks are some kind of malicious
activity aimed at bringing a computer system to a
state where it will not be able to serve legitimate users or
properly perform the functions assigned to it. The denial of
service condition is usually caused by software errors or excessive load on the network
channel or the system as a whole. As a result, the software, or the entire operating system
of the machine, "crashes" or ends up in a "looped" state. And this threatens
downtime, loss of visitors / customers and losses.

The anatomy of DoS attacks
DoS attacks are divided into local and remote. Local ones include
various exploits, fork bombs and programs that open a million files each or
launch a kind of cyclic algorithm that eats up memory and processor
resources. We will not dwell on all this. But we will consider remote DoS attacks
in more detail. They are divided into two types:

Remote exploitation of errors in the software in order to bring it into an inoperable
state.
Flood - sending a huge number of meaningless (less
often meaningful) packages to the victim's address. The purpose of the flood may be a communication channel or resources
cars. In the first case, the packet stream occupies the entire bandwidth and does not
allow the attacked machine to process legitimate requests. In the second
- the resources of the machine are captured by repeated and very frequent
access to any service that performs a complex, resource-intensive
operation. This may be, for example, a long-term access to one of
the active components (script) of the web server. The server spends all the resources of the machine
to process the attacker's requests, and users have to wait.
In the traditional version (one attacker - one victim) now remains
only the first type of attacks is effective. Classic flood is useless. Simply
because with today's server channel width, the level of computing power and
the widespread use of various anti-DoS techniques in software (for example, delays
when performing the same actions multiple times by one client), the attacker
turns into an annoying mosquito, unable to cause any
damage. But if there are hundreds, thousands or even hundreds of thousands of these mosquitoes, they
will easily put the server on the shoulder blades. The crowd is a terrible force not only in life, but also in
the computer world. A distributed denial of service (DDoS) attack,
usually carried out with the help of many zombie hosts, can
cut off even the most persistent server from the outside world, and the only effective
protection is the organization of a distributed server system (but
not everyone can afford it, hello Google).

 
Methods of struggle
The danger of most DDoS attacks lies in their absolute transparency and
"normality". After all, if an error in the software can always be fixed, then the complete
devouring of resources is almost an ordinary phenomenon. Many people face them
administrators, when the machine resources (channel width) become insufficient,
or the website is subjected to a slashdot effect (twitter.com became unavailable a
few minutes after the first news of Michael Jackson's death). And if you cut
traffic and resources for everyone in a row, you will be saved from DDoS, but you will lose a good
half of your customers.

There is virtually no way out of this situation, but the consequences of DDoS attacks and their
effectiveness can be significantly reduced by properly configuring
the router, firewall and constant analysis of anomalies in network traffic. In
in the next part of the article, we will consider sequentially:

ways to recognize an incipient DDoS attack;
methods of dealing with specific types of DDoS attacks;
universal tips that will help you prepare for a DoS attack and
reduce its effectiveness.
At the very end, the answer to the question will be given: what to do when it started
DDoS attack.

 
Fighting flood attacks
So, there are two types of DoS/DDoS attacks, and the most common of them
is based on the idea of flooding, that is, flooding the victim with a huge number of packets.
The flood can be different: ICMP flood, SYN flood, UDP flood and HTTP flood. Modern
DoS bots can use all these types of attacks at the same time, so you should
take care in advance of adequate protection against each of them.

 
1. ICMP flood.
A very primitive method of clogging bandwidth and creating loads on
the network stack through monotonous sending of ICMP ECHO requests (ping). It is easily
detected by analyzing traffic flows in both directions: during
an ICMP flood attack, they are almost identical. An almost painless method of absolute
protection is based on disabling responses to ICMP ECHO requests:

# sysctl net.ipv4.icmp_echo_ignore_all=1

Or using a firewall:

# iptables -A INPUT -p icmp -j DROP --icmp-type 8

 
2. SYN-flood.
One of the most common ways is not only to clog the communication channel, but also to put
the network stack of the operating system in a state where it will no longer be able
to accept new connection requests. It is based on an attempt to initialize
a large number of simultaneous TCP connections by sending a SYN packet with
a non-existent return address. After several attempts to send a reply
ACK packet to an inaccessible address most of the operations queue an unspecified
connection. And only after the nth attempt, the connection is closed. Since
the stream of ACK packets is very large, soon the queue turns out to be full, and the kernel
refuses attempts to open a new connection. The most intelligent DoS bots also
analyze the system before launching an attack in order to send requests only to open
vital ports. Identifying such an attack is simple: just
try to connect to one of the services. Defensive measures usually
include:

3. UDP flood.
A typical method of cluttering up bandwidth. It is based on the endless sending
of UDP packets to the ports of various UDP services. It is easily eliminated by cutting
off such services from the outside world and setting a limit on the number of connections per
unit of time to the DNS server on the gateway side:

# iptables -I INPUT -p udp --dport 53 -j DROP -m iplimit --iplimit-above 1

 
4. HTTP flood.
One of the most common flood methods today. It is based on
the endless sending of HTTP GET messages to the 80th port in order to download
the web server is so much so that it is unable to process all
other requests. Often the purpose of the flood is not the root of the web server, but one of
the scripts that perform resource-intensive tasks or work with the database. In any
case, the abnormally fast growth of the web server logs will serve as an indicator of the attack that has begun
.

Methods of combating HTTP flood include tuning the web server and database
in order to reduce the effect of the attack, as well as filtering out DoS bots using
various techniques. First, you should increase the maximum number of connections to
database at the same time. Secondly, install a lightweight
and productive nginx in front of the Apache web server – it will cache requests and give static. This
is a solution from the "must have" list, which will not only reduce the effect of DoS attacks, but also
allow the server to withstand huge loads. A small example:

Universal tips
In order not to get into a hopeless situation during the collapse of a DDoS storm on
systems, it is necessary to carefully prepare them for such a situation:

All servers with direct access to the external network should be
prepared for a simple and fast remote reboot (sshd will save the father
of Russian democracy). A big plus will be the presence of a second,
administrative, network interface through which you can access
the server if the main channel is clogged.
The software used on the server must always be up to date
condition. All the holes are patched, updates are installed (simple as
a boot, advice that many do not follow). This will protect you from DoS attacks
exploiting bugs in the services.
All listening network services intended for administrative
use should be hidden by a firewall from anyone who should not
have access to them. Then the attacker will not be able to use them to conduct
DoS attacks or bruteforce.
A
traffic analysis system (NetFlow to help) should be installed on the approaches to the server (the nearest router), which will allow timely
learn about the beginning of the attack and take timely measures to prevent it.
Add the following lines to /etc/sysctl.conf:

It should be noted that all the techniques given in the past and this sections
are aimed at reducing the effectiveness of DDoS attacks that aim to
use up the resources of the machine. It is almost impossible to defend against a flood that clogs the channel with garbage,
and the only correct, but not always feasible
way of fighting is to "deprive the attack of meaning." If you have
a really wide channel at your disposal that will easily miss the traffic
of a small botnet, consider that your server is protected from 90% of attacks. There is a more
sophisticated way of protection. It is based on a distributed organization
a computer network that includes many duplicate servers that
are connected to different trunk channels. When the computing power or
bandwidth of the channel runs out, all new clients are redirected
to another server (or gradually "smeared" on servers according
to the round-robin principle). This is an incredibly expensive, but very stable structure,
which is almost impossible to fill up.

Another more or less effective solution is to purchase expensive
hardwired Cisco Traffic Anomaly Detector and Cisco Guard systems. Working in
In combination, they can suppress an incipient attack, but, like most other
solutions based on training and state analysis, they fail. Therefore, you should
think carefully before knocking out tens of thousands
of dollars from your superiors for such protection.

 
It seems to have started. What to do?
Before the immediate start of the attack, the bots "warm up", gradually
increasing the flow of packets to the attacked machine. It is important to catch the moment and start
active actions. Constant monitoring of the router
connected to an external network (analysis of NetFlow graphs) will help in this. On the victim server
you can determine the beginning of the attack by improvised means.

The presence of a SYN flood is easily established - by counting the number of "half-open"
TCP connections:

This will give you some head start (very small; often the source IP address
is spoofed), which you should use in order to contact the
provider / hoster (with the logs of the web server, kernel, firewall attached to the message
and a list of the IP addresses identified by you). Most of them, of course,
will ignore this message (and hosting companies with traffic payments will also rejoice -
a DoS attack will bring them profit) or simply turn off your server. But in any
case, it should be done without fail – effective DDoS protection is possible
only on trunk channels. Alone, you will cope with minor attacks
aimed at depletion of server resources, but you will find yourself defenseless before
a more or less serious DDoS.

 
Fighting DDoS in FreeBSD
Reducing the waiting time for a response packet to a SYN-ACK request (protection against
SYN flood):

# sysctl net.inet.tcp.msl=7500

Turning the server into a black hole. So the kernel will not send response packets when
trying to connect to unoccupied ports (reduces the load on the machine during
DDoS on random ports):

# sysctl net.inet.tcp.blackhole=2
# sysctl net.inet.udp.blackhole=1

We limit the number of responses to ICMP messages to 50 per second (protection against
ICMP flooding):

# sysctl net.inet.icmp.icmplim=50

Increasing the maximum number of connections to the server (protection against all
types of DDoS):

# sysctl kern.ipc.somaxconn=32768

Enable DEVICE_POLLING - independent polling of the network driver by the kernel at
high loads (significantly reduces the load on the system during DDoS):

Rebuilding the kernel with the "options DEVICE_POLLING" option;
Activating the polling mechanism: "sysctl kern.polling.enable=1";
Adding the entry "kern.polling.enable=1" to /etc/sysctl.conf.
 
Naive Internet
At the time of its dawn, DoS attacks were a real disaster for servers
and ordinary workstations. A web site could easily be flooded with a
single host implementing a Smurf-type attack. Workstations with
Windows OS installed fell like dominoes from attacks like Ping of Death, Land,
WinNuke. There is no need to be afraid of all this today.

The largest botnets
Kraken - 400 thousand
computers.
Srizbi - 315 thousand
computers.
Bobax - 185 thousand computers.
Rustock - 150 thousand computers.
Storm - 100 thousand computers.
Psybot - 100 thousand ADSL routers based on Linux.
BBC botnet - 22 thousand computers.
An experimental botnet
created by the BBC.

 
A trace in the history
of 1997 - DDoS attack on the Microsoft website. One day of silence.
1999 - Yahoo, CNN, eBay, etc. web sites were "out of range".
October 2002 - attack on the Internet root DNS servers. 
7 out of 13 servers were disabled for some time.
February 21, 2003 - DDoS attack on LiveJournal.com . For two days, the service
was in a paralyzed state, only occasionally showing signs of life.

 
Intelligent systems
An interesting alternative to Cisco solutions is being released by Reactive Networks (www.reactivenetworks.com ).
Their product called FloodGuard is a hardware complex
consisting of detectors and executive modules. Detectors installed on
firewalls, routers and switches constantly monitor traffic and create
its profile based on parameters such as packet volume, source,
direction, type, etc. In case of anomalies, the detector sends all
the details about what happened to the executive modules located on
routers in different network segments. After receiving a message from the detector,
the execution modules begin to act: they look for parasitic traffic in
passing packets and, if successful, notify the modules that were earlier in the course
of traffic and send them instructions on activating filters on routers.
As a result, a barrier should form in front of the flood traffic flow, which
will quickly move towards its source.