For quite a long time on various websites and forums there were articles and topics that spoke of numerous brute-force attacks on wordpress sites. Recently had to face this infection. :)
In this post, I would like to tell you about my experience in dealing with the selection of a password on sites that work on WordPress. Immediately, I note that all my sites work on nginx + php-fpm .
As an instruction, one article was taken as the basis. However, the described recipe had to be slightly modified for the specifics of its attackers. :)
The first step is to install fail2ban. This should not cause difficulties.
aptitude install fail2ban
After that we add the following to the end of the /etc/fail2ban/jail.conf configuration file:
[nginx-wp-auth] enabled = true filter = nginx-wp-auth action = iptables-multiport [name = wp-auth, port = "http, https"] logpath = /var/log/nginx/*.access.log maxretry = 3 bantime = 3600
In this case, the action will block access for violators only on the specified protocols and mark them as wp-auth. In the logpath specify the path to the logs.
All logs will be analyzed, such as example.com.access.log. For web site logs, you can set special names, for example, wordpress-example.com.access.log, so that only these log files are analyzed.
The maximum number of authorization attempts for one ip is three. The blocking time is an hour. Both of these parameters can be selected individually.
The next step is to create a filter.
During this action, I had difficulties: the example from the original article did not work. And he had to change. :)
[Definition] failregex = <HOST>. * / wp-login.php HTTP / 1.1 "200 <HOST>. * / Wp-login.php / HTTP / 1.1 "302 <HOST>. * / Wp-login.php HTTP / 1.0 "200 ignoreregex =
The first parameter contains all the matches that should be found in the log files. Here you need to analyze the requests of the attackers in the logs of your server and add all suspicious ones related to wp-login.php.
The second parameter is intended for exceptions from the first line. It is not required and remains empty.
After creating the filter, check its operation with the command:
fail2ban-regex / var / log / nginx / example.com .access.log /etc/fail2ban/filter.d/nginx-wp-auth.conf
Matches found will be displayed in the test results. For example:
Running tests ============= Use regex file: /etc/fail2ban/filter.d/nginx-wp-auth.conf Use log file: /var/log/nginx/***.ru..access.log Results ======= Failregex | - Regular expressions: | . * / Wp-login.php HTTP / 1.1 "200 | . * / Wp-login.php / HTTP / 1.1 "302 | . * / Wp-login.php HTTP / 1.0 "200 | `- Number of matches:  1 match (es)  0 match (es)  0 match (es) Ignoreregex | - Regular expressions: | `- Number of matches: Summary ======= Addresses found: [one] 18.104.22.168 (Fri Jul 04 07:29:20 2014)   Date template hits: 0 hit (s): MONTH Day Hour: Minute: Second 0 hit (s): WEEKDAY MONTH Day Hour: Minute: Second Year 0 hit (s): WEEKDAY MONTH Day Hour: Minute: Second 0 hit (s): Year / Month / Day Hour: Minute: Second 0 hit (s): Day / Month / Year Hour: Minute: Second 0 hit (s): Day / Month / Year Hour: Minute: Second 58 hit (s): Day / MONTH / Year: Hour: Minute: Second 0 hit (s): Month / Day / Year: Hour: Minute: Second 0 hit (s): Year-Month-Day Hour: Minute: Second 0 hit (s): Year.Month.Day Hour: Minute: Second 0 hit (s): Day-MONTH-Year Hour: Minute: Second [.Millisecond] 0 hit (s): Day-Month-Year Hour: Minute: Second 0 hit (s): TAI64N 0 hit (s): Epoch 0 hit (s): ISO 8601 0 hit (s): Hour: Minute: Second 0 hit (s): <Month / Day / Year @ Hour: Minute: Second> Success, the total number of match is 1
Checking the lock log
Fail2ban will record all locks produced. If necessary, you can check the log file /var/log/fail2ban.log for their presence.
grep WARNING /var/log/fail2ban.log