August 23, 2015 (Modified August 31, 2015, September 14, 2015)
(Back to the Previous Article in this Series)
I started using Linux in 1999, specifically Red Hat Linux 6.0, and I recall upgrading to Red Hat Linux 6.1 after downloading the files over a 56k modem – the good old days. I was a little more wise when I upgraded to another release a couple of months later – I found a site on the Internet that offered Red Hat Linux CD sets for a couple of dollars. In late 2001/early 2002 I picked up a very good book about creating Linux-based IPTables firewalls, so I set up a dual firewall setup (with a DMZ in between) using a couple of spare computers. That setup worked great in a corporate environment for several years – I even upgraded the hardware in 2006 to inexpensive Dell PowerEdge servers and installed the latest version of Red Hat Linux (I believe Fedora 5). I was excited about the potential capabilities of this free operating system, even going so far in 2004 to use it as the operating system for the primary file servers (Red Hat Enterprise Linux 3, if I remember correctly) in an effort to save a few thousand dollars in Microsoft licensing fees (it almost worked too).
F.A.I.L.S.? I must have put those keywords in the blog article title for a reason, or maybe not. In 2003 I tried setting up the Frees/wan VPN server on a spare Linux computer as an alternative to having to use a 28k/33k dial up modem connection. It was around that time that I learned the dark side of Linux and the “free” software that could be installed. I found an old message thread that I posted in 2003 related to Frees/wan where I mentioned that I spent in excess of 2.5 months trying to make this free VPN solution work correctly. There were several how-to articles returned by a Google search, some of which were written for other Linux variants, others did not use X.509 certificates, and others almost worked. Making matters worse, the Red Hat Linux kernel at the time did not support X.509 certificates, so I eventually ended up installing the Working Overloaded Linux Kernel. I recall desperately looking for a program called Setup.exe that would just take care of the problem, but no such program was found. A couple of months after I had Frees/wan working, a security compromise was reported in all products like Frees/wan, and the Frees/wan development had been abandoned. I learned a very important lesson that “free” software may not be free software when you consider the time that it takes to implement and maintain the free software. I also learned another important lesson – Linux how-to articles that are more than a couple of months old may be misleading or nearly useless; Linux articles that are written for one of the other 790 Linux Distributions may be just as misleading or useless; and not everything on the Internet in a hot-to article is true/correct (this article is no exception).
With that long introduction out of the way, I thought that I would share a couple of notes that I collected along the way when I setup Fedora 22 Linux as a server for a website that uses Apache and WordPress. I have the headache inspiring SELinux enabled on the server, as well as the latest version of Fail2ban to temporarily block IP addresses used by the clowns on the Internet that want to make the Linux server running WordPress their new best friend. So far, Fail2ban is working great, once the how-to articles that apply to Fedora 21 or Fedora 20 are ignored, although the current version does output apparently incorrect error messages when certain commands are executed:
[fedora 22]# fail2ban-client reload wordpress-login
ERROR NOK: ('Cannot change database when there are jails present',)
—
Protecting Fedora 22 Linux with a Firewall
In one of the recent 17 Fedora releases, there was a transition from directly calling iptables commands in a script to using a command called firewall-cmd to accomplish the same task. So, on Fedora 22 you should no longer execute commands like this:
iptables -t nat -A PREROUTING -i $INET_INTERFACE -p esp -j DNAT --to $VPN_IPADDR iptables -A FORWARD -i $INET_INTERFACE -o $DMZ_INTERFACE -p udp --sport 4500 --dport 4500 -d $VPN_IPADDR -j ACCEPT iptables -A FORWARD -i $INET_INTERFACE -o $DMZ_INTERFACE -p esp -j ACCEPT
Instead, with Fedora 22 the commands that are used to control the firewall have an entirely different syntax (allow access to port http 80, https port 443, ssh port 22, and ftp ports 20/21, remove access to FTP ports 20/21, and then reload and activate the changed rules):
firewall-cmd --set-default-zone=public firewall-cmd --permanent --zone=public --add-service=http firewall-cmd --permanent --zone=public --add-service=https firewall-cmd --permanent --zone=public --add-service=ssh firewall-cmd --permanent --zone=public --add-service=ftp firewall-cmd --permanent --zone=public --remove-service=ftp firewall-cmd --reload
The changes do not take effect until the reload command is executed. If you are planning to setup a publically accessible website, and you do not want the server to respond to ping requests and similar icmp requests, you might add a couple of additional firewall rules:
firewall-cmd --permanent --zone=public --add-icmp-block=destination-unreachable firewall-cmd --permanent --zone=public --add-icmp-block=echo-reply firewall-cmd --permanent --zone=public --add-icmp-block=echo-request firewall-cmd --permanent --zone=public --add-icmp-block=parameter-problem firewall-cmd --permanent --zone=public --add-icmp-block=redirect firewall-cmd --permanent --zone=public --add-icmp-block=router-advertisement firewall-cmd --permanent --zone=public --add-icmp-block=router-solicitation firewall-cmd --permanent --zone=public --add-icmp-block=source-quench firewall-cmd --permanent --zone=public --add-icmp-block=time-exceeded firewall-cmd --reload
You might also decide to block certain web content spiders that mercilessly drain your server’s Internet bandwidth without returning any benefit to your website. I noticed that the Baiduspider web crawler is a frequent offender, using several ranges of IP addresses. I put an end to a large portion of the bandwidth drain from this web content spider with a simple firewall rule that blocks the IP address range 180.76.15.1 through 180.76.15.254 (don’t forget to reload after):
firewall-cmd --permanent --add-rich-rule="rule family='ipv4' source address='180.76.15.0/24' reject"
Note that you may see a message similar to the following when attempting to execute the reload command:
Error: 'NoneType' object has no attribute 'query_rule'
If you see the above error message when trying to reload the firewall rules, just shout “free Linux software” five times and execute this command to restart the firewall – this command should have the same end effect as the reload command, except that this command works:
systemctl restart firewalld
Now, assume that you have setup Fail2ban’s ssh jail. After a couple of hours you have received over 200 emails from Fail2ban telling you that it has blocked 200+ computers wanting to be best ssh friends with your server. Obviously, you skipped the step of setting up a different port for ssh. Modify the sshd config file (if you forgot the basic vi commands: press i to be able to make changes in the file, Esc ZZ to save the changes and exit, Esc :q! to quit without saving changes):
vi /etc/ssh/sshd_config
Assume that you want to change the ssh port from 22 to 1492 (something about sailing the ocean blue?). Below the #Port 22 heading, add:
Port 1492
Then save the file and exit vi. Since SELinux is enabled, we need to instruct SELinux to behave correctly when an ssh client attaches to port 1492:
semanage port -a -t ssh_port_t -p tcp 1492
Note: Using the semanage command requires another package to be installed first:
dnf install policycoreutils-pythonNote 2: If you think that SELinux is blocking something that should not be blocked, SELinux may be temporarily disabled with this command:
setenforce 0To re-enable SELinux, either reboot the server or execute this command:
setenforce 1
Next, we need to add a firewall rule to permit connections on port 1492, and reload the firewall rules (note that I am using the command to restart the firewall daemon instead due to the error that appeared with the reload command):
firewall-cmd --permanent --zone=public --add-port=1492/tcp systemctl restart firewalld
As a final verification, make certain that the Linux firewall and SELinux recognize the new port:
firewall-cmd --list-ports semanage port -l | grep ssh
If there are no apparent problems with the above output, restart the ssh daemon:
systemctl reload sshd.service
You may also wish to confirm which services are enabled for the Linux firewall:
firewall-cmd --list-services
—
Beating on a Linux box that lacks a monitor and keyboard is only so much fun (that old reboot joke, I guess). If you have a Windows computer handy, the free Putty program will allow access to the ssh interface on the Linux server. WinSCP is a helpful utility that provides Windows Explorer-like views through the ssh interface on the Linux server.
Protecting Fedora 22 Linux with Fail2ban
Fail2ban is a utility that monitors various log files on the server, looking for unexpected activity that typically originates from another computer on the network or on the Internet. Fail2ban may be setup to take various actions when a problem is noticed, such as the same IP address failing to connect to SSH 10 times in 15 minutes. The action may be to send an email to an administrator and/or to configure a firewall rule that temporarily blocks the offender’s IP address. There are a few how-to articles found through Google searches that describe how to install and configure Fail2ban. Shockingly (not really), some of those articles are more than a couple of months old (so the articles may not work with Fedora 22) and/or instruct people to modify files that explicitly state in the header:
# YOU SHOULD NOT MODIFY THIS FILE.
What to do? What to do?
If you have not done so recently, make certain that the installed Fedora packages are up to date (dfn… another new command, what happened to the rpm command?):
dnf update
If the Apache web server is running on the server, there is a good chance that you execute commands similar to the following at some time in the past:
dnf install httpd systemctl start httpd.service systemctl enable httpd.service
Fail2ban is able to send emails using Sendmail, so if Sendmail is not installed, consider installing it:
dnf install sendmail systemctl start sendmail systemctl enable sendmail
While not directly applying to Fail2ban, SELinux, by default, blocks Apache from using Sendmail. It is possible to verify that this is the case, and remove the restriction with these two commands:
sestatus -b | grep -i sendmail setsebool -P httpd_can_sendmail 1
With Sendmail installed and running, we are able to proceed with the Fail2ban installation and configuration:
dnf install fail2ban ipset dnf install whois fail2ban-sendmail systemctl start fail2ban systemctl enable fail2ban
The configuration file for Fail2ban that should be modified is /etc/fail2ban/jail.d/local.conf – but that file does not exist after installation. The local.conf file references files in the /etc/fail2ban/filter.d/ directory that tell Fail2ban how to read the various log files and recognize problems using regular expressions (they look pretty irregular to me, but then I have not done much with regular expressions since that Turbo Pascal programming class years ago). A starting point for the local.conf file with Fedora 22 and Sendmail, blocking ssh connection requests after a few incorrect login attempts from the same IP address within an hour, would look like the following (replace my.IP.address.here with your IP address so that Fail2ban will ignore your incorrect login attempts):
[DEFAULT] bantime = 2592000 banaction = firewallcmd-ipset backend = systemd sender = emailaddress1@mydomain.com destemail = emailaddress2@mydomain.com action = %(action_mwl)s ignoreip = 127.0.0.1 my.IP.address.here [sshd] enabled = true findtime = 3600
The settings listed under the [DEFAULT] heading apply to all of the other sections in this file, unless those settings are also mentioned in the other sections of the file. For example, the bantime (number of seconds to block an IP address) applies to the [sshd] section, as does the backend = systemd setting. If we want Fail2ban to help protect WordPress, we will want Fail2ban to monitor a variety of log files, which cannot be done with the backend = systemd setting, so that setting will need to be modified in other sections for the file. [sshd] describes the sshd jail, so we will need to select logical names for the sections of the file that will be added later. The sshd jail was not defined (actually, not enabled – it is defined in another configuration file) when Fail2ban was first started, so we need to let Fail2ban know that it should load/reload the sshd jail configuration, and then verify that the jail is functional:
fail2ban-client reload sshd fail2ban-client status sshd
If you wait a couple of minutes between executing the first of the above and second of the above commands, you may see output similar to this, which indicates that some candidates for blocking were identified and blocked, and a notification email was sent to the email address specified by the destemail setting:
Status for the jail: sshd |- Filter | |- Currently failed: 0 | |- Total failed: 0 | `- Journal matches: _SYSTEMD_UNIT=sshd.service + _COMM=sshd `- Actions |- Currently banned: 307 |- Total banned: 307 `- Banned IP list: 1.215.253.186 101.78.2.106 103.15.61.138 103.224.105.7 103.248.234.3 103.253.211.244 ...
Protecting WordPress running on Fedora 22 with Fail2ban.
When an attempt is made to access the password protected /wp-admin section of a WordPress site, and a bad password is entered, by default WordPress silently destroys that failed connection attempt, so Fail2ban is not able to help by blocking repeat offenders. A partial solution that I found on several websites is to add the following code near the start of the WordPress theme’s functions.php file:
add_action('wp_login_failed', 'log_wp_login_fail'); // hook failed login
function log_wp_login_fail($username) {
error_log("WP login failed for username: $username");
Once that code is in place, some of the bad login attempts will be written to either the /var/log/httpd/error_log or /var/log/httpd/ssl_error_log file. You might then start seeing errors such as these buried in those files:
[Thu Aug 13 10:17:43.578391 2015] [auth_basic:error] [pid 30933] [client 75.145.nnn.nnn:50683] AH01618: user admin not found: /wp-admin/css/login.min.css, referer: http://www.websitehere.com/wp-login.php [Thu Aug 13 19:12:53.054913 2015] [:error] [pid 2060] [client 50.62.136.183:33789] WP login failed for username: k-mm [Thu Aug 13 20:13:02.316777 2015] [:error] [pid 1873] [client 50.62.136.183:42677] WP login failed for username: k-mm [Thu Aug 13 21:13:12.012160 2015] [:error] [pid 15701] [client 50.62.136.183:52432] WP login failed for username: k-mm.com [Thu Aug 13 21:28:32.073261 2015] [:error] [pid 15697] [client 50.62.136.183:58571] WP login failed for username: k-mm.com [Thu Aug 13 21:58:43.118303 2015] [:error] [pid 21245] [client 50.62.136.183:52059] WP login failed for username: k-mm.com [Thu Aug 13 22:03:49.150456 2015] [:error] [pid 21244] [client 50.62.136.183:60540] WP login failed for username: k-mm.com [Thu Aug 13 22:23:28.348351 2015] [:error] [pid 15688] [client 50.62.136.183:52911] WP login failed for username: k-mm.com [Thu Aug 13 23:14:14.453002 2015] [:error] [pid 19632] [client 50.62.136.183:37700] WP login failed for username: admin [Fri Aug 14 01:14:15.455095 2015] [:error] [pid 5085] [client 50.62.136.183:45656] WP login failed for username: administrator [Fri Aug 14 02:14:16.478660 2015] [:error] [pid 4114] [client 50.62.136.183:53068] WP login failed for username: administrator
In the above, note the behavior of the computer at IP address 50.62.136.183 – that computer is slowly hitting the server with different username and password combination – slow so as not to set off blocking utilities like Fail2ban that might be configured to start blocking when there have been, for instance, five bad password attempt in an hour. Note that I stated that the addition to the theme’s functions.php file would help to identify some of the bad login attempts – to see the others, the /var/log/httpd/access_log and /var/log/httpd/ssl_access_log files must also be monitored. In those files you may see patterns such as these where a single IP address will try to rapidly and repeatedly post to the /wp-login.php file for more than eight hours straight:
85.97.41.164 - - [12/Aug/2015:17:17:34 -0400] "POST /wp-login.php HTTP/1.1" 200 1628 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko" 85.97.41.164 - - [12/Aug/2015:17:17:35 -0400] "POST /wp-login.php HTTP/1.1" 200 1628 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko" 85.97.41.164 - - [12/Aug/2015:17:17:36 -0400] "POST /wp-login.php HTTP/1.1" 200 1628 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko" 85.97.41.164 - - [12/Aug/2015:17:17:37 -0400] "POST /wp-login.php HTTP/1.1" 200 1628 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko" 85.97.41.164 - - [12/Aug/2015:17:17:38 -0400] "POST /wp-login.php HTTP/1.1" 200 1628 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko" 85.97.41.164 - - [12/Aug/2015:17:17:38 -0400] "POST /wp-login.php HTTP/1.1" 200 1628 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko" 85.97.41.164 - - [12/Aug/2015:17:17:40 -0400] "POST /wp-login.php HTTP/1.1" 200 1628 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko" 85.97.41.164 - - [12/Aug/2015:17:17:42 -0400] "POST /wp-login.php HTTP/1.1" 200 1628 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko" 85.97.41.164 - - [12/Aug/2015:17:17:43 -0400] "POST /wp-login.php HTTP/1.1" 200 1628 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko" ... 109.228.0.250 - - [13/Aug/2015:01:42:43 -0400] "POST /wp-login.php HTTP/1.0" 403 3030 "-" "-" 109.228.0.250 - - [13/Aug/2015:01:42:48 -0400] "POST /wp-login.php HTTP/1.0" 403 3030 "-" "-" 109.228.0.250 - - [13/Aug/2015:01:42:49 -0400] "POST /wp-login.php HTTP/1.0" 403 3030 "-" "-" 109.228.0.250 - - [13/Aug/2015:01:42:50 -0400] "POST /wp-login.php HTTP/1.0" 403 3030 "-" "-" 109.228.0.250 - - [13/Aug/2015:01:42:56 -0400] "POST /wp-login.php HTTP/1.0" 403 3030 "-" "-" 109.228.0.250 - - [13/Aug/2015:01:42:56 -0400] "POST /wp-login.php HTTP/1.0" 403 3030 "-" "-"
Obviously, the computers at those IP addresses were up to no good, and should also be blocked. Another interesting pattern that might be seen in the access_log or ssl_access_log files is an attacker trying to retrieve the login of the first author username in WordPress, working slowly to try logging into the website so as not to trip protection utilities like Fail2ban that identify multiple failed logins from the same IP address in a short period of time:
185.93.187.69 - - [20/Aug/2015:00:38:16 -0400] "GET /?author=1 HTTP/1.1" 302 - 185.93.187.69 - - [20/Aug/2015:00:38:20 -0400] "GET /wp-login.php HTTP/1.1" 403 221 185.93.187.69 - - [20/Aug/2015:00:58:35 -0400] "GET /?author=1 HTTP/1.1" 302 - 185.93.187.69 - - [20/Aug/2015:00:58:37 -0400] "GET /wp-login.php HTTP/1.1" 403 221 185.93.187.69 - - [20/Aug/2015:01:19:20 -0400] "GET /?author=1 HTTP/1.1" 302 - 185.93.187.69 - - [20/Aug/2015:01:19:22 -0400] "GET /wp-login.php HTTP/1.1" 403 221 185.93.187.69 - - [20/Aug/2015:01:39:45 -0400] "GET /?author=1 HTTP/1.1" 302 - 185.93.187.69 - - [20/Aug/2015:01:39:46 -0400] "GET /wp-login.php HTTP/1.1" 403 221 185.93.187.69 - - [20/Aug/2015:01:59:59 -0400] "GET /?author=1 HTTP/1.1" 302 - 185.93.187.69 - - [20/Aug/2015:02:00:00 -0400] "GET /wp-login.php HTTP/1.1" 403 221
You might also see something like this in the access_log or ssl_access_log file:
220.163.10.250 - - [17/Aug/2015:21:03:43 -0400] "DELETE / HTTP/1.1" 400 226
I strongly suspect that the computer at IP address 220.163.10.250 had other uses in mind for my website. From the documentation:
“The DELETE method requests that the origin server delete the resource identified by the Request-URI. This method MAY be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been completed successfully. However, the server SHOULD NOT indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible location. “
A quick method to determine if a potential attacker tried to use the above DELETE request is to use the grep command to search within the ssl_access_log and access_log files:
grep "DELETE" /var/log/httpd/ssl_access_log* grep "DELETE" /var/log/httpd/access_log*
Another set of attempted compromises that is not directed at WordPress sites are also visible in the ssl_access_log and access_log files:
162.246.61.20 - - [29/Jul/2015:02:13:11 -0400] "GET /cgi-bin/php HTTP/1.1" 404 209 "-" "-" 162.246.61.20 - - [29/Jul/2015:02:13:11 -0400] "GET /cgi-bin/php5 HTTP/1.1" 404 210 "-" "-" 162.246.61.20 - - [29/Jul/2015:02:13:11 -0400] "GET /cgi-bin/php-cgi HTTP/1.1" 404 213 "-" "-" 162.246.61.20 - - [29/Jul/2015:02:13:11 -0400] "GET /cgi-bin/php.cgi HTTP/1.1" 404 213 "-" "-" 162.246.61.20 - - [29/Jul/2015:02:13:11 -0400] "GET /cgi-bin/php4 HTTP/1.1" 404 210 "-" "-" 195.145.157.189 - - [30/Jul/2015:12:07:38 -0400] "GET /cgi-bin/test-cgi HTTP/1.1" 404 214 "-" "the beast" 37.144.20.31 - - [01/Aug/2015:09:34:10 -0400] "GET /tmUnblock.cgi HTTP/1.1" 400 226 "-" "-" 69.64.46.86 - - [03/Aug/2015:01:48:28 -0400] "GET /cgi-bin/rtpd.cgi HTTP/1.0" 404 214 "-" "-" 69.64.46.86 - - [14/Aug/2015:01:24:35 -0400] "GET /cgi-bin/rtpd.cgi HTTP/1.0" 404 214 "-" "-" 23:46.148.18.122 - - [16/Aug/2015:20:30:17 -0400] "GET /tmUnblock.cgi HTTP/1.1" 403 - "-" "-" 23:46.148.18.122 - - [16/Aug/2015:20:30:17 -0400] "GET /hndUnblock.cgi HTTP/1.1" 403 - "-" "-" 88.202.224.162 - - [23/Aug/2015:07:05:15 -0400] "GET //cgi-bin/webcm?getpage=../html/menus/menu2.html&var:lang=%26%20allcfgconv%20-C%20voip%20-c%20-o%20-%20../../../../../var/tmp/voip.cfg%20%2 HTTP/1.1" 404 211 80.82.65.186 - - [01/Aug/2015:08:42:51 -0400] "GET //cgi-bin/webcm?getpage=../html/menus/menu2.html&var:lang=%26%20allcfgconv%20-C%20voip%20-c%20-o%20-%20../../../../../var/tmp/voip.cfg%20%26 HTTP/1.1" 404 211 46.165.220.215 - - [16/Aug/2015:20:51:51 -0400] "GET /cgi-bin/webcm?getpage=../html/menus/menu2.html&var:lang=%26%20allcfgconv%20-C%20voip%20-c%20-o%20-%20../../../../../var/tmp/voip.cfg%20%26 HTTP/1.1" 404 211 46.165.220.215 - - [17/Aug/2015:03:09:59 -0400] "GET /cgi-bin/webcm?getpage=../html/menus/menu2.html&var:lang=%26%20allcfgconv%20-C%20voip%20-c%20-o%20-%20../../../../../var/tmp/voip.cfg%20%26 HTTP/1.1" 404 211
If any of the above appear to be interesting, you might try a Google search to see what the remote computers were attempting to compromise.
Far less obnoxious are entries that show your Nagios monitoring utility checking the website availability:
50.196.nnn.nnn - - [19/Aug/2015:09:30:54 -0400] "GET / HTTP/1.1" 200 57465 "-" "check_http/v1.4.16 (nagios-plugins 1.4.16)" 50.196.nnn.nnn - - [19/Aug/2015:09:31:07 -0400] "GET / HTTP/1.1" 200 57465 "-" "check_http/v1.4.16 (nagios-plugins 1.4.16)" 50.196.nnn.nnn - - [19/Aug/2015:09:31:42 -0400] "GET / HTTP/1.1" 200 57465 "-" "check_http/v1.4.16 (nagios-plugins 1.4.16)" 50.196.nnn.nnn - - [19/Aug/2015:09:31:47 -0400] "GET / HTTP/1.1" 200 57465 "-" "check_http/v1.4.16 (nagios-plugins 1.4.16)"
As well as random computers trying to download a file named wpad.dat (in the webserver root directory execute touch wpad.dat to create a zero byte file for that name – this is important if your client computers should not be trying to retrieve such a file and you have a custom error page configured for the website that is a feature rich web page). There is a chance that your client computers could be searching for this file due to a specific configuration setting:
Example output, showing repeated requests, is shown below:
76.29.115.160 - - [20/Aug/2015:02:07:40 -0400] "GET /wpad.dat HTTP/1.1" 200 - "-" "-" 76.29.115.160 - - [20/Aug/2015:02:07:46 -0400] "GET /wpad.dat HTTP/1.1" 200 - "-" "-" 76.29.115.160 - - [20/Aug/2015:02:08:03 -0400] "GET /wpad.dat HTTP/1.1" 200 - "-" "-" 76.29.115.160 - - [20/Aug/2015:02:08:14 -0400] "GET /wpad.dat HTTP/1.1" 200 - "-" "-"
—
Regular Expression Building Assistance:
If we intend to have Fail2ban help protect WordPress running on Apache on Fedora 22 Linux, we need to first create “filter” files that contain the regular expressions needed to recognize bad guy attempted access. The filter files are located in the /etc/fail2ban/filter.d/ directory and all end with .conf, although the .conf portion of the filename is not specified in the /etc/fail2ban/jail.d/local.conf file that we created earlier. I will create separate filter files for ssl and non-ssl log files, although that is not required. The first filter file is apache-wp-login.conf:
vi /etc/fail2ban/filter.d/apache-wp-login.conf
I set that file to have four regular expressions to recognize a bad guy’s attempted access (one or two of the regular expressions below may be incorrect because I have not had enough recent practice at writing regular expressions):
[Definition] failregex = [[]client <HOST>[]] WP login failed.* [[]client <HOST>[]] client denied.*wp-login.php .*\[auth_basic:error\] \[pid.*\] \[client <HOST>.*? .*\[:error\] \[pid.*\] \[client .*?(?P<host>\S+):\d+\] WP login failed.* ignoreregex =
Save the file and exit vi. Verification of the regular expression syntax is important. The fail2ban-regex utility will process a Linux log file of your choice using one of the regular expression filters that you create in the /etc/fail2ban/filter.d/ directory. For example, to test the filter than was created above, execute the following command:
fail2ban-regex --print-all-matched /var/log/httpd/error_log /etc/fail2ban/filter.d/apache-wp-login.conf
Your output may be similar to what appears below (note that I processed an error_log from a previous week:
Running tests ============= Use failregex filter file : apache-wp-login, basedir: /etc/fail2ban Use log file : /var/log/httpd/error_log-20150816 Use encoding : UTF-8 Results ======= Failregex: 40 total |- #) [# of hits] regular expression | 3) [26] .*\[auth_basic:error\] \[pid.*\] \[client <HOST>.*? | 4) [14] .*\[:error\] \[pid.*\] \[client .*?(?P<host>\S+):\d+\] WP login failed.* `- Ignoreregex: 0 total Date template hits: |- [# of hits] date format | [140] (?:DAY )?MON Day 24hour:Minute:Second(?:\.Microseconds)?(?: Year)? `- Lines: 144 lines, 0 ignored, 40 matched, 104 missed [processed in 0.24 sec] |- Matched line(s): ... | [Thu Aug 13 22:03:49.150456 2015] [:error] [pid 21244] [client 50.62.136.183:60540] WP login failed for username: k-mm.com | [Thu Aug 13 22:23:28.348351 2015] [:error] [pid 15688] [client 50.62.136.183:52911] WP login failed for username: k-mm.com | [Thu Aug 13 23:14:14.453002 2015] [:error] [pid 19632] [client 50.62.136.183:37700] WP login failed for username: admin | [Fri Aug 14 01:14:15.455095 2015] [:error] [pid 5085] [client 50.62.136.183:45656] WP login failed for username: administrator | [Fri Aug 14 02:14:16.478660 2015] [:error] [pid 4114] [client 50.62.136.183:53068] WP login failed for username: administrator | [Fri Aug 14 13:02:10.181252 2015] [auth_basic:error] [pid 30239] [client 75.145.nnn.nnn:54787] AH01618: user test not found: /wp-admin/css/login.min.css, referer: http://www.mydomain.com/wp-login.php | [Fri Aug 14 13:02:12.819515 2015] [auth_basic:error] [pid 30239] [client 75.145.nnn.nnn:54787] AH01618: user test not found: /wp-admin/css/login.min.css, referer: http://www.mydomain.com/wp-login.php | [Fri Aug 14 13:02:14.880515 2015] [auth_basic:error] [pid 30239] [client 75.145.nnn.nnn:54787] AH01618: user test not found: /wp-admin/css/login.min.css, referer: http://www.mydomain.com/wp-login.php | [Fri Aug 14 13:02:29.497034 2015] [:error] [pid 3357] [client 75.145.nnn.nnn:54798] WP login failed for username: k-mm, referer: http://www.mydomain.com/wp-login.php | [Fri Aug 14 13:02:29.531482 2015] [auth_basic:error] [pid 3357] [client 75.145.nnn.nnn:54798] AH01618: user test not found: /wp-admin/css/login.min.css, referer: http://www.mydomain.com/wp-login.php ...
The /etc/fail2ban/filter.d/apache-wp-login-ssl.conf filter file that I created is identical to the /etc/fail2ban/filter.d/apache-wp-login.conf file:
[Definition] failregex = [[]client <HOST>[]] WP login failed.* [[]client <HOST>[]] client denied.*wp-login.php .*\[auth_basic:error\] \[pid.*\] \[client <HOST>.*? .*\[:error\] \[pid.*\] \[client .*?(?P<host>\S+):\d+\] WP login failed.* ignoreregex =
After saving the file and exiting vi, we are able to test the filter:
fail2ban-regex --print-all-matched /var/log/httpd/ssl_error_log /etc/fail2ban/filter.d/apache-wp-login-ssl.conf
The wordpress-login.conf and wordpress-login-ssl.conf filter files will be used to examine the /var/log/httpd/access_log and /var/log/httpd/ssl_access_log files, respectively.
The /etc/fail2ban/filter.d/wordpress-login.conf file (note once again that one or two of the regular expressions used for matching may need to be adjusted):
[Definition] failregex = ^<HOST> .* "POST .*\/wp-login.php HTTP/1.0" 403 .*$ ^<HOST> .* "POST .*\/wp-login.php HTTP/1.1" 403 .*$ ^<HOST> .* "POST .*wp-login.php HTTP.1.*" 403 ^<HOST> .* "POST .*wp-login.php HTTP.1.*" 200 ^<HOST> .* "GET .*wp-login.php HTTP/1.*" 403 221 ^<HOST> .* "GET ..author=1 HTTP/1.*" 302 - ignoreregex =
The /etc/fail2ban/filter.d/wordpress-login-ssl.conf file:
[Definition] failregex = ^<HOST> .* "POST .*\/wp-login.php HTTP/1.0" 403 .*$ ^<HOST> .* "POST .*\/wp-login.php HTTP/1.1" 403 .*$ ^<HOST> .* "POST .*wp-login.php HTTP.1.*" 403 ^<HOST> .* "POST .*wp-login.php HTTP.1.*" 200 ^<HOST> .* "GET .*wp-login.php HTTP/1.*" 403 221 ^<HOST> .* "GET ..author=1 HTTP/1.*" 302 - ignoreregex =
To test those two filters, use these commands:
fail2ban-regex --print-all-matched /var/log/httpd/access_log /etc/fail2ban/filter.d/wordpress-login.conf fail2ban-regex --print-all-matched /var/log/httpd/ssl_access_log /etc/fail2ban/filter.d/wordpress-login-ssl.conf
—
Added August 31, 2015:
I have found that a couple of computers on the Internet are trying to access a variety of *.cgi files in rapid fashion, resulting in entries such as these being written to the /var/log/httpd/error_log file:
[Sun Aug 30 20:38:08.187093 2015] [cgi:error] [pid 6426] [client 64.15.155.177:53122] AH02811: script not found or unable to stat: /var/www/cgi-bin/webmap.cgi [Sun Aug 30 20:38:08.271430 2015] [cgi:error] [pid 6230] [client 64.15.155.177:53316] AH02811: script not found or unable to stat: /var/www/cgi-bin/whois.cgi [Sun Aug 30 20:38:08.599455 2015] [cgi:error] [pid 6094] [client 64.15.155.177:54035] AH02811: script not found or unable to stat: /var/www/cgi-bin/register.cgi [Sun Aug 30 20:38:08.733852 2015] [cgi:error] [pid 6453] [client 64.15.155.177:54213] AH02811: script not found or unable to stat: /var/www/cgi-bin/download.cgi [Sun Aug 30 20:38:09.048479 2015] [cgi:error] [pid 5353] [client 64.15.155.177:54516] AH02811: script not found or unable to stat: /var/www/cgi-bin/shop.cgi [Sun Aug 30 20:38:09.533326 2015] [cgi:error] [pid 5673] [client 64.15.155.177:56107] AH02811: script not found or unable to stat: /var/www/cgi-bin/profile.cgi [Sun Aug 30 20:38:09.736446 2015] [cgi:error] [pid 6455] [client 64.15.155.177:56274] AH02811: script not found or unable to stat: /var/www/cgi-bin/about_us.cgi [Sun Aug 30 20:38:09.830315 2015] [cgi:error] [pid 6456] [client 64.15.155.177:56734] AH02811: script not found or unable to stat: /var/www/cgi-bin/php.fcgi [Sun Aug 30 20:38:09.918823 2015] [cgi:error] [pid 4232] [client 64.15.155.177:56923] AH02811: script not found or unable to stat: /var/www/cgi-bin/calendar.cgi [Sun Aug 30 20:38:10.013162 2015] [cgi:error] [pid 6423] [client 64.15.155.177:57115] AH02811: script not found or unable to stat: /var/www/cgi-bin/download.cgi [Sun Aug 30 20:38:10.106597 2015] [cgi:error] [pid 6425] [client 64.15.155.177:57399] AH02811: script not found or unable to stat: /var/www/cgi-bin/light_board.cgi [Sun Aug 30 20:38:10.193901 2015] [cgi:error] [pid 6426] [client 64.15.155.177:57574] AH02811: script not found or unable to stat: /var/www/cgi-bin/main.cgi [Sun Aug 30 20:38:10.288724 2015] [cgi:error] [pid 6230] [client 64.15.155.177:57754] AH02811: script not found or unable to stat: /var/www/cgi-bin/search.cgi [Sun Aug 30 20:38:10.516842 2015] [cgi:error] [pid 5349] [client 64.15.155.177:57949] AH02811: script not found or unable to stat: /var/www/cgi-bin/test.cgi [Sun Aug 30 20:38:10.601953 2015] [cgi:error] [pid 6094] [client 64.15.155.177:58409] AH02811: script not found or unable to stat: /var/www/cgi-bin/file_up.cgi
If you have Fail2ban running on the webserver, and you are seeing entries like the above in the error_log file, consider creating a file named /etc/fail2ban/filter.d/apache-cgi-bin.conf with the following contents:
[Definition] failregex = ^.*\[cgi:error\] \[pid.*\] \[client .*?(?P<host>\S+):\d+\] AH02811: script not found or unable to stat: \/var\/www\/cgi-bin.*$ ignoreregex =
To test the above filter definition, execute this command:
fail2ban-regex --print-all-matched /var/log/httpd/error_log /etc/fail2ban/filter.d/apache-cgi-bin.conf
(Note that the steps that follow assume that the local.conf file has already been created, see the steps below.) To set up the jail that uses the above filter, in the /etc/fail2ban/jail.d/local.conf file, you would then add the following lines, which will setup blocking when a search locates five or more matching entries from the same IP address within two days:
[apache-cgi-bin] enabled = true filter = apache-cgi-bin logpath = /var/log/httpd/error_log bantime = 2592000 findtime = 172800 port = http,https maxretry = 5 backend = polling journalmatch =
To activate the jail, execute:
fail2ban-client reload apache-cgi-bin
To see the jail status, execute:
fail2ban-client status apache-cgi-bin
Below is sample output for the above command:
Status for the jail: apache-cgi-bin |- Filter | |- Currently failed: 1 | |- Total failed: 111 | `- File list: /var/log/httpd/error_log `- Actions |- Currently banned: 4 |- Total banned: 4 `- Banned IP list: 118.219.233.133 27.254.67.157 118.163.223.214 64.15.155.177
—
Added September 14, 2015:
I noticed a couple of additional suspicious access entries in the access_log file. The first set of entries appears to be from a computer looking for a wide range of web server vulnerabilities:
185.25.48.89 - - [13/Sep/2015:22:57:49 -0400] "GET /wp-content/uploads/samplc.php HTTP/1.1" 301 - "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)" 185.25.48.89 - - [13/Sep/2015:22:57:50 -0400] "GET /wp-content/uploads/samplc.php HTTP/1.1" 301 - "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)" 185.25.48.89 - - [13/Sep/2015:22:57:55 -0400] "POST /uploadify/uploadify.php HTTP/1.1" 301 - "http://k-mm.com/uploadify/uploadify.php" "Mozilla/5.0 (Windows; Windows NT 5.1; en-US) Firefox/3.5.0" 185.25.48.89 - - [13/Sep/2015:22:57:58 -0400] "GET /samplc.php HTTP/1.1" 301 - "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)" 185.25.48.89 - - [13/Sep/2015:22:57:59 -0400] "GET /samplc.php HTTP/1.1" 301 - "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)" 185.25.48.89 - - [13/Sep/2015:22:58:02 -0400] "POST /wp-admin/admin-ajax.php HTTP/1.1" 200 1 "http://k-mm.com/wp-admin/admin-ajax.php" "Mozilla/5.0 (Windows; Windows NT 5.1; en-US) Firefox/3.5.0" 185.25.48.89 - - [13/Sep/2015:22:58:06 -0400] "GET /wp-content/plugins/revslider/temp/update_extract/samplc.php HTTP/1.1" 301 - "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)" 185.25.48.89 - - [13/Sep/2015:22:58:06 -0400] "GET /wp-content/plugins/revslider/temp/update_extract/samplc.php HTTP/1.1" 301 - "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)" 185.25.48.89 - - [13/Sep/2015:22:58:09 -0400] "POST /php-ofc-library/ofc_upload_image.php?name=sample.php HTTP/1.1" 301 - "/php-ofc-library/ofc_upload_image.php?name=sample.php" "Mozilla/5.0 (Windows; Windows NT 5.1; en-US) Firefox/3.5.0" 185.25.48.89 - - [13/Sep/2015:22:58:12 -0400] "GET /tmp-upload-images/samplc.php HTTP/1.1" 301 - "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)" 185.25.48.89 - - [13/Sep/2015:22:58:13 -0400] "GET /tmp-upload-images/samplc.php HTTP/1.1" 301 - "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)" 185.25.48.89 - - [13/Sep/2015:22:58:13 -0400] "GET /large-machining-fabricating-capabilities/ HTTP/1.1" 200 50109 "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)" 185.25.48.89 - - [13/Sep/2015:22:58:17 -0400] "POST /components/com_creativecontactform/fileupload/index.php HTTP/1.1" 301 - "/components/com_creativecontactform/fileupload/index.php" "Mozilla/5.0 (Windows; Windows NT 5.1; en-US) Firefox/3.5.0" 185.25.48.89 - - [13/Sep/2015:22:58:20 -0400] "GET /components/com_creativecontactform/fileupload/files/samplc.php HTTP/1.1" 301 - "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)" 185.25.48.89 - - [13/Sep/2015:22:58:21 -0400] "GET /components/com_creativecontactform/fileupload/files/samplc.php HTTP/1.1" 301 - "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)" 185.25.48.89 - - [13/Sep/2015:22:58:27 -0400] "GET /wp-content/uploads/samplc.php HTTP/1.1" 301 - "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)" 185.25.48.89 - - [13/Sep/2015:22:58:28 -0400] "GET /wp-content/uploads/samplc.php HTTP/1.1" 301 - "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)" 185.25.48.89 - - [13/Sep/2015:22:58:31 -0400] "HEAD /plugins/editor.zoho/agent/save_zoho.php HTTP/1.1" 301 - "-" "-" 185.25.48.89 - - [13/Sep/2015:22:58:32 -0400] "HEAD /sites/all/libraries/elfinder/elfinder.html HTTP/1.1" 301 - "-" "-" 185.25.48.89 - - [13/Sep/2015:22:58:33 -0400] "POST /wp-admin/admin-ajax.php?page=pmxi-admin-settings&action=upload&name=samplc.php HTTP/1.1" 200 1 "/wp-admin/admin-ajax.php?page=pmxi-admin-settings&action=upload&name=samplc.php" "Mozilla/5.0 (Windows; Windows NT 5.1; en-US) Firefox/3.5.0" @ 185.25.48.89 - - [13/Sep/2015:22:58:27 -0400] "GET /wp-content/uploads/samplc.php HTTP/1.1" 301 - "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)" 185.25.48.89 - - [13/Sep/2015:22:58:28 -0400] "GET /wp-content/uploads/samplc.php HTTP/1.1" 301 - "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)" 185.25.48.89 - - [13/Sep/2015:22:58:31 -0400] "HEAD /plugins/editor.zoho/agent/save_zoho.php HTTP/1.1" 301 - "-" "-" 185.25.48.89 - - [13/Sep/2015:22:58:32 -0400] "HEAD /sites/all/libraries/elfinder/elfinder.html HTTP/1.1" 301 - "-" "-" 185.25.48.89 - - [13/Sep/2015:22:58:33 -0400] "POST /wp-admin/admin-ajax.php?page=pmxi-admin-settings&action=upload&name=samplc.php HTTP/1.1" 200 1 "/wp-admin/admin-ajax.php?page=pmxi-admin-settings&action=upload&name=samplc.php" "Mozilla/5.0 (Windows; Windows NT 5.1; en-US) Firefox/3.5.0" 185.25.48.89 - - [13/Sep/2015:22:58:34 -0400] "GET /wp-content/plugins/wpallimport/samplc.php HTTP/1.1" 301 - "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)" 185.25.48.89 - - [13/Sep/2015:22:58:35 -0400] "GET /wp-content/plugins/wpallimport/samplc.php HTTP/1.1" 301 - "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)" 185.25.48.89 - - [13/Sep/2015:22:58:38 -0400] "POST /server/php/ HTTP/1.1" 301 - "/server/php/" "Mozilla/5.0 (Windows; Windows NT 5.1; en-US) Firefox/3.5.0" 185.25.48.89 - - [13/Sep/2015:22:58:41 -0400] "GET /server/php/files/samplc.php HTTP/1.1" 301 - "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)" 185.25.48.89 - - [13/Sep/2015:22:58:42 -0400] "GET /server/php/files/samplc.php HTTP/1.1" 301 - "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)"
The second set of entries appear to be from two different computers that are apparently trying to take advantage of a SQL injection attempt to deface a website, or something similar:
122.154.24.254 - - [14/Sep/2015:03:29:38 -0400] "GET /phpMyAdmin/scripts/setup.php HTTP/1.1" 301 - "-" "-" 122.154.24.254 - - [14/Sep/2015:03:29:41 -0400] "GET /pma/scripts/setup.php HTTP/1.1" 301 - "-" "-" 122.154.24.254 - - [14/Sep/2015:03:29:45 -0400] "GET /myadmin/scripts/setup.php HTTP/1.1" 301 - "-" "-" 122.155.190.132 - - [14/Sep/2015:07:52:22 -0400] "GET /phpMyAdmin/scripts/setup.php HTTP/1.1" 301 - "-" "-" 122.155.190.132 - - [14/Sep/2015:07:52:27 -0400] "GET /pma/scripts/setup.php HTTP/1.1" 301 - "-" "-" 122.155.190.132 - - [14/Sep/2015:07:52:33 -0400] "GET /myadmin/scripts/setup.php HTTP/1.1" 301 - "-" "-"
While the hacking attempts were unsuccessful, I decided that there is little point in wasting the server’s resources with similar attempts. I created a new Fail2ban filter with the filename /etc/fail2ban/filter.d/apache-block-misc-php.conf and added the following lines to recognize the above entries in the Apache access_log file:
[Definition]
failregex = ^<HOST> .* "POST .*uploadify.php HTTP.1.*" .*$
^<HOST> .* "HEAD .*uploadify.php HTTP.1.*" .*$
^<HOST> .* "POST .*ofc_upload_image.php.*" .*$
^<HOST> .* "POST .*fileupload.index.php .*" .*$
^<HOST> .* "HEAD .*save_zoho.php .*" .*$
^<HOST> .* "POST .*save_zoho.php .*" .*$
^<HOST> .* "HEAD .*elfinder.html .*" .*$
^<HOST> .* "POST .*elfinder.html .*" .*$
^<HOST> .* "GET .*scripts.setup.php .*" .*$
^<HOST> .* "POST .*scripts.setup.php .*" .*$
^<HOST> .* "GET .*\/samplc.php .*" .*$
^<HOST> .* "GET .*\/?author=.*" .*$
^<HOST> .* "GET .*abdullkarem.*" .*$
^<HOST> .* "GET .*\/uploadify.php.*" .*$
^<HOST> .* "GET .*\/bin\/perl .*$
^<HOST> .* "GET .*wp-admin\/admin-ajax.php .*" .*$
^<HOST> .* "GET <title>phpMyAdmin HTTP.*$
^<HOST> .* "GET \/phpmyadmin.*$
^<HOST> .* "GET \/phpMyAdmin.*$
^<HOST> .* "GET \/PMA\/.*$
^<HOST> .* "GET \/pma\/.*$
^<HOST> .* "GET \/admin\/.*$
^<HOST> .* "GET \/dbadmin\/.*$
^<HOST> .* "GET \/mysql\/.*$
^<HOST> .* "GET \/myadmin\/.*$
^<HOST> .* "GET \/sqlmanager\/.*$
^<HOST> .* "GET \/mysqlmanager\/.*$
^<HOST> .* "GET \/wcd\/top.xml.*$
^<HOST> .* "GET \/wcd\/system_device.xml.*$
^<HOST> .* "GET \/wcd\/system.xml.*$
^<HOST> .* "GET \/openurgencevaccin\/index.php.*$
^<HOST> .* "GET \/zeuscms\/index.php.*$
^<HOST> .* "GET \/phpcoin\/license.php.*$
^<HOST> .* "GET \/authadmin\/.*$
^<HOST> .* "GET \/backup\/.*$
^<HOST> .* "GET \/backups\/.*$
^<HOST> .* "GET \/bak\/.*$
^<HOST> .* "GET \/cbi-bin\/.*$
^<HOST> .* "GET \/ccard\/.*$
^<HOST> .* "GET \/ccards\/license.php.*$
^<HOST> .* "GET \/cd-cgi\/.*$
^<HOST> .* "GET \/cfide\/.*$
^<HOST> .* "GET \/cgi\/.*$
^<HOST> .* "POST .*\/fileupload\/index.php.*$
^<HOST> .* "POST .*\/php\/index.php.*$
^<HOST> .* "GET .*wp-config.php.*$
^<HOST> .* "POST .*\/examples\/upload.php.*$
ignoreregex =
Once the new filter file is created, test the filter to see if it allows Fail2ban to find any matching lines in the access_log:
fail2ban-regex --print-all-matched /var/log/httpd/access_log /etc/fail2ban/filter.d/apache-block-misc-php.conf
If it appears that the filter is finding matching lines, add a new jail definition in the /etc/fail2ban/jail.d/local.conf file (note that maxretry is set to 2):
[apache-block-misc-php] enabled = true filter = apache-block-misc-php logpath = /var/log/httpd/access_log bantime = 2592000 findtime = 86400 port = http,https maxretry = 2 backend = polling journalmatch =
To activate the new jail, execute the reload command:
fail2ban-client reload apache-block-misc-php
To check the status of the new jail, execute the status command:
fail2ban-client status apache-block-misc-php
Sample output is shown below:
Status for the jail: apache-block-misc-php |- Filter | |- Currently failed: 0 | |- Total failed: 30 | `- File list: /var/log/httpd/access_log `- Actions |- Currently banned: 4 |- Total banned: 4 `- Banned IP list: 114.27.9.31 122.154.24.254 122.155.190.132 185.25.48.89
—
For Fail2ban to use the filters that were just created, we must add additional lines (jail descriptions) to the /etc/fail2ban/jail.d/local.conf file:
vi /etc/fail2ban/jail.d/local.conf
At the end of the file add the following four jail definitions (note that without the backend and journalmatch lines the jails will not work due to the settings in the [DEFAULT] section of this file):
[apache-wp-login] enabled = true filter = apache-wp-login logpath = /var/log/httpd/error_log bantime = 2592000 findtime = 3600 port = http,https maxretry = 5 backend = polling journalmatch = [apache-wp-login-ssl] enabled = true filter = apache-wp-login-ssl logpath = /var/log/httpd/ssl_error_log bantime = 2592000 findtime = 3600 port = http,https maxretry = 5 backend = polling journalmatch = [wordpress-login] enabled = true filter = wordpress-login logpath = /var/log/httpd/access_log bantime = 345600 findtime = 86400 port = http,https maxretry = 6 backend = polling journalmatch = [wordpress-login-ssl] enabled = true filter = wordpress-login-ssl logpath = /var/log/httpd/ssl_access_log bantime = 345600 findtime = 86400 port = http,https maxretry = 6 backend = polling journalmatch =
Save the file and exit vi. Next we need to instruct Fail2ban to recognize the four new jails:
fail2ban-client reload apache-wp-login fail2ban-client reload apache-wp-login-ssl fail2ban-client reload wordpress-login fail2ban-client reload wordpress-login-ssl
As an alternative to the above, we could just restart Fail2ban, which will restart all of the jails, and potentially spam your inbox with ssh blocking notifications:
systemctl restart fail2ban.service
Checking the status of the jails is quite simple to accomplish:
fail2ban-client status apache-wp-login fail2ban-client status apache-wp-login-ssl fail2ban-client status wordpress-login fail2ban-client status wordpress-login-ssl
You might be curious about the emails that Fail2ban sends. Below is a portion of an actual email that I received from Fail2ban recently:
Hi,
The IP 46.119.117.47 has just been banned by Fail2Ban after
12 attempts against wordpress-login.Here is more information about 46.119.117.47:
[Querying whois.ripe.net]
[whois.ripe.net]
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf% Note: this output has been filtered.
% To receive output for a database update, use the “-B” flag.% Information related to ‘46.118.0.0 – 46.119.255.255’
% Abuse contact for ‘46.118.0.0 – 46.119.255.255’ is ‘abuse@kyivstar.net’
inetnum: 46.118.0.0 – 46.119.255.255
descr: Golden Telecom LLC
netname: UA-SVITONLINE-20100517
org: ORG-SOGT1-RIPE
country: UA
admin-c: GTUA-RIPE
tech-c: GTUA-RIPE
status: ALLOCATED PA
mnt-by: RIPE-NCC-HM-MNT
mnt-lower: GTUA-MNT
mnt-lower: GTUA-WO-MNT
mnt-domains: GTUA-ZONE-MNT
mnt-domains: GTUA-MNT
mnt-routes: GTUA-RT-MNT
mnt-routes: GTUA-MNT
created: 2010-05-17T08:47:45Z
last-modified: 2011-08-04T15:58:57Z
source: RIPE # Filteredorganisation: ORG-SOGT1-RIPE
org-name: Golden Telecom LLC
org-type: LIR
address: 15/15/6 V. Khvojki str.
address: 04080
address: Kiev
address: UKRAINE
phone: +380444900000
fax-no: +380444900048
admin-c: AEL17-RIPE
admin-c: NP1533-RIPE
mnt-ref: RIPE-NCC-HM-MNT
mnt-ref: GTUA-MNT
mnt-by: RIPE-NCC-HM-MNT
abuse-c: GTL6-RIPE
created: 2004-04-17T12:09:58Z
last-modified: 2015-07-17T13:48:48Z
source: RIPE # Filteredrole: Golden Telecom Ukraine NOC
address: Golden Telecom
address: 4 Lepse blvr
address: Kiev, 03067, Ukraine
phone: +380 44 4900000
fax-no: +380 44 4900048
remarks: All abuse notifications have to be sent on:
abuse-mailbox: abuse@kyivstar.net
admin-c: AEL17-RIPE
admin-c: NP1533-RIPE
nic-hdl: GTUA-RIPE
mnt-by: GTUA-MNT
created: 2007-07-25T09:02:04Z
last-modified: 2014-06-17T08:24:26Z
source: RIPE # Filtered% Information related to ‘46.119.112.0/20AS15895’
route: 46.119.112.0/20
descr: Kyivstar GSM, Kiev, Ukraine
origin: AS15895
mnt-by: GTUA-MNT
created: 2012-03-21T09:29:14Z
last-modified: 2012-03-21T09:29:14Z
source: RIPE # Filtered% This query was served by the RIPE Database Query Service version 1.80.1 (DB-2)
Lines containing IP:46.119.117.47 in /var/log/httpd/access_log
I am not sure why, but this particular email did not list the lines from the access_log that matched the filter rule.
Protecting WordPress running on Fedora 22 with .htaccess Files
One step that you may want to take is to password protect the /wp-admin directory on your web server. To do that, you would create a new Linux user with a username and password that are difficult to guess based on your website name and WordPress users – the password should be at least eight characters long with upper and lower case letters, numbers, and punctuation marks. Then, using tips from the last post in this message thread, create a file name .htaccess in the /wp-admin directory. Inside that file, add the following lines (replace /full/path/to/your/wp-admin with the directory where you will later create a .htpasswd file):
AuthName "Admin Area" AuthType Basic AuthUserFile /full/path/to/your/wp-admin/.htpasswd require valid-user <Files admin-ajax.php> Order allow,deny Allow from all Satisfy any </Files>
Next use the htpasswd generator website to create an encrypted version of the password for the Linux username. For example, if you created the Linux user hillbillyforpresident with a password of GreatScott1TrumpIsAhead? the htpasswd website would instruct you to create a .htpasswd file with the following contents:
hillbillyforpresident:$apr1$gAgbX0SU$YjtXg5pAvXrD6i.F2lh6z1
Make certain that the .htaccess file (and possibly the .htpasswd file also) have read/write access for the owner, read access for the group in which Apache runs (the Apache user should not own the files), and that the files are not world readable. For example:
chmod 640 /var/www/html/wp-admin/.htaccess
The wp-config.php file should also be protected with similar file permissions:
chmod 640 /var/www/html/wp-config.php
The .htaccess file in the web server’s root directory should also be adjusted to control which files may be accessed. Below the # END WordPress line in the file, consider adding the following (once you understand what the lines accomplish – note that the entry containing 123\.123\.123\.123 should allow the IP address 123.123.123.123 to access the wp-login.php file):
# Block access to files.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^wp-admin/includes/ - [F,L]
RewriteRule !^wp-includes/ - [S=3]
RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]
RewriteCond %{REQUEST_URI} ^(.*)?wp-login\.php(.*)$ [OR]
RewriteCond %{REQUEST_URI} ^(.*)?wp-admin$
RewriteCond %{REMOTE_ADDR} !^123\.123\.123\.123$
RewriteRule ^(.*)$ - [R=403,L]
</IfModule>
<files wp-config.php>
order allow,deny
deny from all
</files>
<Files .htaccess>
order allow,deny
deny from all
</Files>
# Stop Apache from serving .ht* files
<Files ~ "^\.ht">
Order allow,deny
Deny from all
</Files>
Options -Indexes
WordPress and SELinux – a Headache Waiting to Attack
From what I understand, everything in the webserver’s root directory is set by default to the httpd_sys_content_t SELinux context – and sometimes that context is not present when files are copied into various subdirectories that are accessible to Apache. The following command resets the SELinux context to the default context:
chcon -R -v -t httpd_sys_content_t /var/www/
Using FTP integrated with WordPress to install updated plugins or new WordPress versions is a bit of a nightmare because different SELinux contexts are required for the different directories – I never did find a combination that worked. As a result, I added the following line to the wp-config.php file so that FTP integration is not necessary:
define( 'FS_METHOD', 'direct');
Of course the WordPress upload directory must have the httpd_sys_rw_content_t SELinux context, so at some point the following command would need to be executed:
chcon -R -v -t httpd_sys_rw_content_t /var/www/html/wp-content/uploads/
The same command may also need to be executed for the WordPress plugins and upgrade directories (and probably a tempfiles directory) so that it is possible to install and update plugins using the WordPress interface. Right now I do not permit WordPress to auto-update when a new version is released (this is due to the file system permissions that I use that only allow the apache user to read the files, not change the files). I previously created a download directory in the /var directory. Whenever I need to upgrade WordPress to a new version I use a script with the following contents (note that the script was pieced together based on what the WordPress release notes stated needed to be updated):
cd /var/downloads
rm -rf /var/downloads/wordpress
rm /var/downloads/wordpress.tar.gz
wget https://wordpress.org/latest.tar.gz
mv latest.tar.gz wordpress.tar.gz
tar -xzf wordpress.tar.gz
chcon -R -v -t httpd_sys_content_t /var/downloads/wordpress/
chown -R FileOwnerHere:ApacheGroupHere /var/downloads/wordpress/
find /var/downloads/wordpress/ -type d -exec chmod 2755 {} +
find /var/downloads/wordpress/ -type f -exec chmod 2644 {} +
cp -av /var/downloads/wordpress/wp-admin/* /var/www/html/wp-admin/
cp -av /var/downloads/wordpress/wp-includes/* /var/www/html/wp-includes/
cp -v /var/downloads/wordpress/wp-content/* /var/www/html/wp-content/
cp /var/downloads/wordpress/*.php /var/www/html/
cp /var/downloads/wordpress/*.txt /var/www/html/
cp /var/downloads/wordpress/*.html /var/www/html/
—
The above information is consolidated from weeks, maybe months, of hammering on a seemingly simple problem – 12 years later (OK, maybe 16 years later) and I am still in search of the Linux program named Setup.exe that configures everything that needs to be configured to get a job done quickly. Oh, going out on a limb here, let’s ask for a GUI interface too that works with Putty. Or, even further out on a limb, let’s ask for consistency of file paths, filenames, and commands across the 790+ Linux distributions and versions within each distribution so that a how-to article created two years ago is still valid today. Stepping off the soap box… or SOAP box.
If any readers have comments or suggestions that improve upon the above information (or gently correct), please feel free to add a comment below. Maybe someone else will find some of the above information useful to avoid putting a couple of extra dents in the top surface of their desk.
Charles Hooper's Oracle Notes 
Leave a Reply