Strike ddos ​​botnet in the home

Good day, dear habrosoobschestvu, at the request of habrovchan decided to share some of their best practices in the fight against ddos ​​on the basis of personal practical experience of repelling attacks.

This article will not be another new way to protect yourself from ddos ​​on your own, there is plenty of information on this. We will go a little on the other side.

As they say the best defense is attack. So we will be with you to strike at the most painful place of ddosers - at bots. An additional nice bonus for us is that we will do a good deed and free at least some of the infected machines from the captivity of the evil botnetchik.

It is clear that we can’t kill the botnet, but sometimes it is possible to inflict quite substantial blow, especially if the main part of the botnet is Dedik with rootkits, which sometimes create the main problem in repelling the attack. Well, a kulhatskeru vase with his hundred blood and then extracted bots can also be very bad for mischief. For bots, especially on good channels and from good regions, cost money and sometimes considerable ones. If they start to breathe from the abuses that have fallen down, it may be unprofitable for ddosers to continue to do you and they can raise the price for the customer or even stop the attack altogether. It is much easier to do that from whom there will be no excess noise.

How to kill a bot?

')

So, how can we kill a bot, or at least try to free its soul from the evil forces that have settled?



For this you need:



one). Determine the ip address of the attacking bots

2). Determine who owns these IP addresses (parent organization: DC, provider, institution ...), from whois get a list of contact abuse email, which we will send complaints

3). Prepare logs confirming the fact of the attack.

four). Send log email abuse lists



If there are few bots, you can of course do all this with your hands, but we will automate this process.

Ddos is different

We remember that DDoS can be different and there are no universal ways to determine malicious addresses, in each case there will be a different algorithm and other sources.



In general, this is a topic for a separate article, but I will try to choose an easy and accessible way for everyone to understand.

So, let's say we have TCP / UDP flood on different ports, some methods restrict ddos, access to the machine is there, but we want to reduce the attack power and prevent it from increasing, well, or just foul up ddoseram.

The task is to inflict a counterstrike, to deprive the botnet of the most active bots.

We collect logs

There are many options, again a topic for a separate article. There are many different ways to log traffic, for example, tcpdump, iptrtaf, netflow ...

I somehow historically had most of the logs taken off using iptraf, which was used to monitor the attack, and all the scripts were configured to parse them. The solution may not be the most beautiful, but quite universal. With the most minimal modification, you can use any logs and perform all the following manipulations in real time.



So, the ddos ​​started, we launch iptraf, in the settings (Configure) we enable logging (Logging), now when we start the IP traffic monitor, it will ask which file to save the log for, for example

/var/log/iptraf/iptraf.log

Now iptraf for us will record basic information about each package (including the one dropped).

By personal observation, the server will not get worse from this; this logging almost does not waste any useful server resources.

Send abuses

When there is a log, we can proceed with its processing and sending letters of happiness to providers of infected machines, so that they understand the owners.

For this I propose several self-written scripts intended for this.

The scripts were written in a very difficult time, so there was no talk about beauty and optimization, now I have modified them a little, have spiced them up with comments.

Specially broke all the work into several modules, each of which is responsible for its task. This will allow to adapt them to your case and control each step.

Scripts

All scripts can be downloaded here: github.com/Ajex/AntiDdosAbuse



Below I will describe each.



one). show_ips.sh - displays a list of ip addresses from the log and the number of packets that passed during the collection interval.



Launch parameters:

./show_ips.sh iptraf.log "Dec 12" > ddos_ips.txt 

After this, the script will parse the file using the iptraf.log file and the filter “Dec 12” as the source log, and output the result to the ddos_ips.txt file for further analysis by other scripts.



* You can apply any of your filters, choosing data for example for a specific hour.



Its output will be the following:

  3 1.1.1.1. 3 1.1.1.2. 3 1.1.2.1. 10 2.3.2.2. 10 2.3.2.2. .... 7833 xxxx 19343 yyyy 58234 zzzz 

Given that this log will be made at the time of the attack, there will be a very strong gap between the smallest and largest values. Sometimes thousands and tens of thousands of times. Here, again, there are no universal algorithms on what grounds to consider traffic anomalous, you need to look and think with your head.

But as a rule, the file will be very clearly visible, because a normal user cannot send several tens of thousands of requests in a few minutes.

Based on this log, we define the border from which to consider aypishniki bots. You can additionally carry out a manual check of some addresses from the tops using the apache / nginx logs and the ipraf log.

For example, the bot was bursting over UDP, and you only had a webserver or TCP gobbled up on some kind of left ports that you have tightly closed.

It is very important to include the head at this step, for I repeat, there are no universal methods, it all depends on what server is under attack, what services are running, what load.

You can modify the script and, together with the number, display, for example, another region of the address and count the number of closed ports on which the bot was breaking, add information from the web server logs ...

There is a whole field for mental activity that goes beyond the scope of this article.



2). get_info.sh - extracts the abuse of email from whois information for each IP address received by the show_ips.sh script in step 1.

Launch parameters:

 ./get_info.sh ddos_ips.txt > abuse_email.txt 

where, ddos_ips.txt is the file created in step 1

After that, abuse_email.txt will contain a list of email addresses to send emails.



Its output will be the following:

 xxxx abuse@aaa.com master@aaa.com yyyy abuse@bbb.com zzzz abuse@ccc.com .... 

It is important that the script has the configuration parameter th_limit , it means from how many connections it is considered to be a bot, this boundary is determined at the previous step.



3). get_logs.sh - the script extracts information for each specific ip address from the iptraf log, saves it in a separate file and packs it into Gzip



Launch parameters:

 ./get_logs.sh ddos_ips.txt iptraf.log "Nov 20" pref 

where, pref prefix created logs for easy sorting



It is necessary to specify th_limit in the parameters, this is again the number of connections from the ddos_ips.txt file separating good ip addresses from bots.

At the output in the current folder will be created Gzip files containing logs for each individual Ip.



four). mail_send.sh - script sending out letters to the lists obtained from step 2. using get_info.sh script



Launch parameters:

 ./mail_send.sh abuse_email.txt pref 

where the abuse_email.txt file obtained in step 2



Inside the script is the title and body of the letter, which you customize to fit your needs. You can scare all sorts of heavenly punishments and threats to go to the police, etc., for some it even acts.



echo "Hi, today, our server xxxx was attacked from your or your c$ip

Here are the logs yourcompany.com/abuse$pref$ip.txt.gz (TZ - Europe/Moscow) ... bla bla bla ... The Company Name Ltd." | mail -s "[Abuse] ddos attack from your $ip" $email_row

(I don’t specifically give my text so that they do not send it according to a template and do not fall into the spam filter)



In the script, in the sending template, there is a link to the file with logs. I tried to attach files directly to the letter, but, firstly, they are often voluminous, and secondly, they are often cut by spam filters and are suspicious, in the third it is sometimes difficult to send them from a machine under DDoS, and the link to the corporate site looks more weighty and safer.

Therefore, I simply copied the logs to another machine with a raised web server using a simple script, and in the body of the letter I simply indicated a link to the log.



do_all.sh - this script performs all actions consistently, but more has been done to demonstrate, because before running it, you need to tune the script parameters, especially th_limit for your own case



Here are its parameters:



parse_date - Grep log will be made by this expression, if you need to select records for a certain number or hour

pref - prefix for created files, for example, the same date

iptraf_raw_file - where to get the iptrafa log



It is clear that it was possible to make scripts through streams, but for an article and an understanding of the work did as it is, the scope for fantasy is endless. You can modify and automate all processes, for example, automatically enable logging after the start of an attack, make a more accurate analyzer for step 1.



If you act wisely, you can inflict a sufficiently significant blow to the botnet, especially if the number of bots is small, but they mostly consist of dedik on rootkits. I say this from personal experience.

And what is the result? Does it really work?

What happens to the resulting abuse? Perhaps, of course, it will be ignored, but, for example, the next day, the IP address will again fall into the black list and again an abusa will leave, etc., perhaps sometime they will react.

If an un is some kind of a VPS / VDS server and the abusa falls for example into a DC with detailed logs, it is normally framed, then it will most likely be studied, and if the logs are very compelling and converge with DC statistics, then there may be a block. It's about 50/50, which is generally not bad either.

If this comes to the provider, he will most likely notify the subscriber (he communicated with some friends, they said they would do just that), and if there are several complaints, and again they are reasoned, they may be blocked until the client installs a normal anti-virus.



After our mailing around the world, there will be a whole chain of events that we may never know about, and they may not have a decisive impact, but in any case it’s better than not to do anything and hope that tomorrow there will be someone else and not you.

If such actions will produce the majority and abuses will be strewed from different IPs, the providers will have to take measures, each such abuser is a nail in the coffin of the botnet.



Thank you for your attention, this is my first article on Habré, please do not strongly scold if something goes wrong. If the subject matter is of interest, I’ll share my practical experience, as I don’t have serious resources, having 3 rubles in my bosom can withstand strong enough attacks. Sometimes cunning and ingenuity can give more than a powerful iron or a wide channel.



UPD: By the way, there are times when the method described in the article can be a real salvation from ddos. For example, if the entire width of the port is overwhelmed with a relatively small number of bots on wide channels or the network does not cope with the flow of requests. In this case, either the unit on the side of the upstream router will help, which is very often not possible in many DCs, or wrestling with abuz. The latter, apart from its simplicity and accessibility, makes it possible to foul up and disarm them so well.