No matter which services you run – it will not take long until somebody or something will start bruteforcing them. Instead of manually constructing a network-based mechanism like using netfilter string matching combined w/ ipt_recent, it might probably make sense to use what we already have and which does the same: fail2ban.
So, as a simple example, lets deal w/ wordpress login bruteforcing. If we look into the server logfiles, relevant entries will contain:
"POST /wp-login.php HTTP/1.1"
So now simply extend fail2ban to include that by first creating
and filling that w/ the following if it fits your site’s structure:
[Definition] failregex = ^<HOST> .* "POST /wp-login.php
Now just include the new configuration to the (hopefully) already existing
[wp-auth] enabled = true filter = wp-auth action = iptables-multiport[name=wp-auth, port="http,https"] logpath = /var/www/log/error.log bantime = 1200 maxretry = 5
If implemented properly, we just need to restart fail2ban and it should mention the new rule by
2017-10-12 17:39:16,554 fail2ban.jail : INFO Creating new jail 'wp-auth' 2017-10-12 17:39:16,554 fail2ban.jail : INFO Jail 'wp-auth' uses pyinotify 2017-10-12 17:39:16,593 fail2ban.jail : INFO Jail 'wp-auth' started
If underlying principles are well understood, protecting other – not necessarily web-based – services should not be a hard task.
Basic IP Recon
Out of curiosity, it might be quite interesting to find out where the logged WordPress login bruteforce attacks (in my case, about 150 in only a few hours) originate from. So, lets first write a very basic skript to extract relevant data from our fail2ban.log:
#!/bin/bash grep 'WARNING \[wp-auth\]' /var/log/fail2ban.log exit 0
This will printout all the bans as well as the unbans which take place 20 minutes later if the configuration is left in its default state. Now, lets process that data a bit more to first reduce it to relevant content, eliminate double entries, and finally try to lookup the IP adresses involved. A simple approach could look like:
sudo ./WPBF.sh | grep Ban | cut -d " " -f 7 | sort | uniq | nslookup | grep "name ="
and gives us quite some valid information. Mostly originating from .ru and .cn, perhaps some .jp and .tr, this is quite the usual background noise, of which only 4 look a bit uncommon:
188.8.131.52.in-addr.arpa name = pc0.zz.ha.cn. 184.108.40.206.in-addr.arpa name = pc0.zz.ha.cn. 220.127.116.11.in-addr.arpa name = pc0.zz.ha.cn. 18.104.22.168.in-addr.arpa name = no-data.
Lets checkout the WHOIS information for each of them:
inetnum: 22.214.171.124 - 126.96.36.199 netname: HA-ZZ-USAT-LTD country: CN descr: Henan University Science And Technology Limited Company, descr: No 7 Dongqing Road, descr: Zhengzhou City, descr: Henan Province.
Okay, a university network. Like back in the old days 🙂 The next one:
inetnum: 188.8.131.52 - 184.108.40.206 netname: HA-ZZ-HUANJBHJ-GOV country: CN descr: HUANJBHJ Gov, descr: SSDDYEBH, descr: ZhengZhou City, descr: Henan Provice.
Hmm, the government….and the last one
inetnum: 220.127.116.11 - 18.104.22.168 netname: UNICOM-HA country: CN descr: China Unicom Henan province network descr: China Unicom
is at least in my experience seen very often in any of portscan, spam, or bruteforce attacks. Now to the last highlighted one:
inetnum: 22.214.171.124 - 126.96.36.199 netname: CNPC-TJ country: CN descr: CNPC Dagang Oilfield Communication Corporation
Never heard something like this before – could be interesting if that is really some kind of measuring device or a “normal” PC. Since it got 1723/tcp open, I suspect the former. Also, the question always remains: Are these attacks really originating from these adresses or are they just backdoored boxes?
If we do a quick portscan, all four IPs got one thing in common:
9999/tcp open abyss syn-ack
and a quick search reveals that it might be a remote access trojan called “The Prayer”.
To checkout all hosts for that backdoor, we can simply do s/t like
for i in `sudo ./WPBF.sh | grep Ban | cut -d " " -f 7 | sort | uniq ` ; do nmap -p 9999 $i --host-timeout=1 | grep open -B 3; done