In one of the articles I talked about how the kiddy script interferes with our clients' lives . In this article, I would like to talk about solutions: how we will try to deal with it.
So far, without full source codes, they will be in the next articles. In the meantime, rather, about the strategy and tactics of defense.
Standard "solutions"
Send complaints
A very common approach. If an intrusion into your IS is detected, enter the attacker into the firewall (or not) and send an automatic complaint by mail, which was found in whois.
We receive complaints about our clients from the intrusion detection system of various banks, offices, websites. Even, it seems, large organizations just roll fail2ban and that's it.
It will all work every other time, what if the attacker is not banned? Yes, and it is wrong to give the opportunity to knock on your door, what if someone sets the solarwinds123 level password and is hacked on the first try?
Force users to do the right thing.
You can make your own service, almost malware, as Godaddy did, add another user under the nydys login and forget to disable the cloud-init administrator, as Godaddy did, install 8 extra certificates into the system, as Godaddy did.
You can also block AD and other "insecure ports", as some other hosting did, and that's all.
You can run your crawlers and scan your own nets. Scan ports, find vulnerable services, or even try to break into your own clients with the most commonly cracked passwords.
This will really help in something, but what and how should be arranged on the user's servers must be decided by the user. Plus, if you do all this, as they say, on a scale, then we will stumble upon a spread in the technical savvy of users and a misunderstanding, "Well, what have I done ?!" and “I'm not a programmer!”, but everyone should be safe.
Deal with security
Everything above is very cool and can be useful. But users need to be protected. Especially newbies. Virtual servers are often used as a field for experimentation, a platform for familiarizing themselves with server systems, and sometimes users get it wrong.
We talked with the owners of the compromised machines, asked them to honestly say what password was set and, unfortunately, logins and passwords of the test: test or 111: 111 level, this is still a common practice.
Linux users are getting worse, they are not as willing to contact as Windows users, although, judging by the number of complaints about Linux servers, they are more often hacked or used by cybercriminals.
It is clear that not everyone looses their policies and sets passwords of the "12345678" level on the root, but this happens regularly, so you should try.
Architecture
Simple as a sleeper. Here is a picture:
- The trap server collects statistics for 1 hour and sends the collected data to the database.
- The judge server collects data from the database and makes decisions on bans. Bans are also recorded for the medical history of each specific IP address.
- The BGP server parses the generated banned list and transmits this list as a BGP feed further to the routers.
From trap servers, the data is sent in the same format by the same “Get-Bruteforce” that we offered earlier, namely:
- Hacking attempts
- Logins used
- IP address
- PTR record
How decisions are weighed
We are talking about a potentially combat solution, therefore, it is impossible to ban everyone in a row. It is necessary to introduce discrete, understandable criteria so that it is clear how, what and why.
At the moment, 6 factors are taken into account:
- How many times did the attacker try to break in
- How many different baits did he hit
- Is the IP address static
- Does the IP address belong to the hosting or home provider
- Did the attacker use "bad" logins
- What other good guys say
Quantitative Expressions
Everything is clear here. The more intensive the search and the larger its area, and the larger the dictionary, the higher the threat posed by the attacker. There is no point in expanding this item.
PTR and everything connected with it
When we published the initial brute force analysis, it became noticeable that the PTR record says a lot.
The number of Chinese hosting companies attacking our servers was just overwhelming, but this is no exception, Azure and AWS customers also very cheerfully participated and took not the last places.
The largest number of attacks came from the static IP addresses of hosting providers, so if servers pose the greatest security threat, why ban regular users?
Bad logins
There are some. For example, from the easily googled "k8h3d" is the first candidate for a ban. This is a login from a very stupid crypto-miner worm that left a backdoor in RDP under this username. The same applies to logins typed in Hindi, Chinese and other layouts that are not typical for our clients.
You can imagine a situation where a person makes a mistake in one digit of the IP address, does not enter and starts sorting out all the passwords that were in his life. But it is difficult to imagine expecting from our client that he will start typing something other than the standard Administrator. We provide OS only under English logins, therefore, banning the keyboard layout is perhaps the most effective and safe.
Other good guys
Spamhaus as an example of the good guys, thanks to them for the open block lists. Let's say an attacker hit only one honeypot, but his address has been in the SBL for a long time, then why pull?
It's the same with open fail2ban lists, the opinion of other good guys allows you to make decisions more confidently.
Testing
As in medicine. Randomized, double-blind study. Monitored servers (except for traps) are divided into two groups.
- Control group
- The patients
For the first two weeks, we apply filtering rules for patients only. The control group receives all traffic without filtering. After that, exactly half of the servers from both groups are swapped.
Additional control groups will be located in other DCs to take into account the “seasonality” and exclude the influence of other factors, for example, the closure of controllers, etc.
Thus, it will be possible to most reliably establish how effective honeypotting is as a method of protecting anything other than the honeypots themselves.
What's next?
After collecting the primary data, near-combat testing will be carried out on just a couple of data centers, and if this significantly reduces the number of attacks, then we will publish:
- Open blocking sheet with expanded comments in txt, xml and json format
- Script for RouterOS and separate blocking leaf for RouterOS
- Open feed for BGP routers.
- Source codes.
Well, if there are no fewer attacks or more problems, then we will publish only the source code and a report on why it burned out.
I hope that the topic is as interesting to you as it is waiting for your thoughts on the proposed system, any thoughts will be useful.
