Over the course of the last year there have been various items of news confirming that many DDoS attacks are being triggered from websites with vulnerabilities of the persistent Cross Site Scripting (XSS) type.
- Users / Infected Website / DDoS Attack / Attacker / Server -
might not be as harmful as:
The second uniform resource locator (URL) would trigger a greater amount of processing work for the victim's server, because it must search for the word "incibe" in the database.
The news that has been published stated that video sites are a frequent target for this type of attack. The reason is that victims spend a long period of time visiting a site while they watch videos. This makes them a prime target for such attacks, because the longer a page stays open, the longer the attack continues.
How to protect against this sort of attack
Just as for any DDoS attack, the first thing to do is to identify the pattern used by the attacker. This can be done by executing the following command to view the access logs for the server, in this case Apache:
When this is executed, it becomes possible to view in real time all visits to the site, so that the attacker internet protocol address (IP) can be identified.
- IPs and Dates for All Request -
- Request Received by Web Server -
- User-Agent Employed by Users -
As can be seen, each IP corresponds to one of the different users who are accessing the infected website. It is the site that causes users to send requests to the server, without their even being aware of what is going on.
As the headers have not been edited, it is possible to find out which page is being used to trigger the DDoS attack.
In this case it is: http://alvarodiaz.ovh/index.php?video=ID
At this point, the best thing is to warn the administrator responsible for that page, who will certainly not be aware of what is happening. While the programmers for the site sort out the vulnerability, it is possible to block access by the attacking IPs so as to try to slow down the DDoS attack that is being suffered.
Among other possibilities, this can be done by using fail2ban. Fail2ban is a script programmed in Python that monitors Apache logs for suspicious patterns. It is also able to take measures to block attackers, either with iptables or by running whatever command we choose. It is distributed under a GNU licence.
Fail2ban allows requests to be filtered by a number of fields, such as by IPs, header reference or the number of connections in a given period of time. In the example filtering can be by the reference "http://alvarodiaz.ovh/index.php?video=ID" .
If this piece of data was not available, it would be necessary to take into account all requests, filtering with the string "GET / HTTP/1.1". This is a very common state of affairs and might lead to the banning of legitimate visits.
- Installing Fail2ban -
Below are some guidelines on configuring fail2ban. The configuration directory for fail2ban is to be found in: /etc/fail2ban/, where there are two further directories, action.d and filter.d
- action.d: This has the actions that fail2ban will take when any of our filters finds some misbehaving IP.
- filter.d: This stores the filters that will be used to identify attackers.
To avoid an attack the file /etc/fail2ban/jail.conf should be edited, adding the following lines:
- Configuration Lines to Be Added -
- Maxretry: This specifies how many tries will be allowed before an IP is banned.
- findtime: This is the amount of time over which retries will be counted (300 seconds = 5 minutes).
- bantime: This is the amount of time that will elapse before fresh requests will be permitted. It is effectively the time that an IP will be locked out, in this case five minutes.
- Logpath: This is the route to our Apache log.
It is crucial to configure this file correctly, because otherwise fail2ban will lock out genuine visits.
Next the filtering file is created in /etc/fail2ban/filters.d/http-get-dos.conf. The following lines will be included in it:
- Configuration Lines to Be Added -
Finally, fail2ban must be restarted so it will adopt the new configuration.
- Restart Command for Fail2ban -
Once it has restarted, all that is necessary is to wait while fail2ban blocks attacking IPs automatically. It is possible to see what bans it imposes by looking at its log file /var/log/fail2ban.log
- Banning IP 126.96.36.199 -
When this IP tries to access our server, fail2ban will stop it in its tracks.
Why Ban IPs with Fail2ban and Not from Apache or Htaccess?
The reason is that if locking out of IPs is done from the applications level this is ineffective because the server, in this case Apache, still receives the request. If a firewall like iptables is used, then connections are blocked at network level, so that Apache will never process the request.
Finally, it should be noted that although fail2ban limits the impact of an attack of this kind, it is not a definitive solution, as the server continues to receive requests. If an attack generates a large volume of these, it could also cause a denial of service on our server.