Skip to content

erick t. hitter

web tinkerer

  • Home
    • Adventures with VPS
      • Backups
      • mailserver
      • nginx
      • SSL
    • Tech & Tools
    • WordPress
  • Photos
  • Musings, ramblings, etc.
  • Code
    • GitHub
    • Automating plugin releases to WordPress.org using GitLab CI
    • Generating a CSR with SAN at the command line
    • Monitoring and culling stale GitLab Runner instances
  • Presentations
    • Presentations @ Slideshare
  • Plugins
    • Automating releases using GitLab CI
    • Redis User Session Storage
  • About
    • Public Keys
      SSH, PGP, etc
    • apt repos
    • Timeline
      Where I’ve been and when
    • Contact
    • License
    • Donate
    • Privacy Policy
  • Twitter
  • GitLab
  • GitHub
  • WordPress.org

Latest Posts

  • Plugin updates and translation lessons
  • Connecting an iHome SmartPlug to Home Assistant
  • Compiling nginx with GitLab CI

Categories

Tag: wp-login

Rate limiting: another way I guard against brute-force logins

Rate limiting: another way I guard against brute-force logins

For the last few weeks, the VPS powering this site received an increase in nefarious traffic arriving via IPv6. Perhaps unsurprisingly, much of this traffic came as brute-force login attempts against my WordPress site, and its arrival over IPv6 was key.

As I noted in my post on login monitoring, I already employ fail2ban, in conjunction with Konstantin Kovshenin’s technique for blocking failed WP logins. Unfortunately, fail2ban only supports IPv4, which is the only reason I even noticed this uptick in login attempts or needed to address it.

Continue reading Rate limiting: another way I guard against brute-force logins

Posted on May 16, 2016March 15, 2017Categories Adventures with VPS, Tech & Tools, TutorialsTags logwatch, nginx, swatch, swatchdog, WordPress, wp-login, wp-login.php1 Comment on Rate limiting: another way I guard against brute-force logins

Protecting the WordPress login in nginx

In recent days, many tech blogs have written about a distributed attack targeting WordPress and other content management systems. This brute-force attack focuses on compromising sites that use the admin user account. The attack is notable for its scale, as many hosts have seen reported degraded performance resulting from it.

There are plugin solutions, such as Limit Login Attempts, that can mitigate the effectiveness of this attack, but I wanted a solution that didn’t  let the flood of attempts ever reach my server’s PHP processor. On this approach, there are numerous tutorials that recommend restricting access to wp-login.php and the entire wp-admin directory. This approach is problematic because WordPress’ Ajax endpoint exists within the wp-admin directory, so it must be publicly accessible for many themes and plugins to function properly.

Since this latest attack targets wp-login.php, I opted to place that file behind basic access authentication by modifying my server’s nginx configuration. This is a single-user site, so I don’t need to worry about managing users at both the server and WP levels.

location ~* /wp-login.php {
	auth_basic "erick t. hitter WordPress Network Login";
	auth_basic_user_file PATH_TO_AUTH_FILE;
	PHP_CONFIGURATION
}

The ~* tells nginx to match all requests for wp-login.php regardless of casing (WP-LOGIN.php, WP-login.php, etc.), and also without regard to the directory the request was made to. I took this approach because my access logs revealed many requests to wp-login.php in directories that didn’t exist, likely the bots’ attempt to uncover all possible locations for the file.

In the above example, PHP_CONFIGURATION is replaced with whatever directives your configuration needs to pass PHP requests to the processor; in my case, I’m using PHP-FPM, and those settings appear there. It is necessary to redeclare these configuration settings within this new location block since the existing declarations won’t be applied to requests handled by this new location block.

Beyond ensuring that the Ajax endpoint is accessible, protecting only wp-login.php also restricts this extra security step to login requests alone. Once I’ve logged in, and for as long as I remain logged in, I’m not prompted to provide the HTTP authentication credentials again. In other words, additional security without too great an annoyance for me.

To be clear, this change constitutes just one element of the login protections employed on my multisite network. The admin user doesn’t exist, I use a very strong password, and I’ve enabled a two-factor authentication plugin.

What are you doing to ensure your WordPress setup isn’t compromised by this latest attack?


Reference: http://arstechnica.com/security/2013/04/huge-attack-on-wordpress-sites-could-spawn-never-before-seen-super-botnet/

Posted on April 14, 2013August 12, 2017Categories Adventures with VPS, Code, Tech & Tools, WordPressTags Authentication, nginx, Security, wp-login4 Comments on Protecting the WordPress login in nginx

Replacing WordPress Logo on wp-login.php

There are many times when, as much as I’d love to publicize that a site is built on WordPress, the logo just isn’t appropriate on the login screen (wp-login.php). Thankfully, it’s quite easy to replace the logo using a bit of CSS. Simply paste the following snippet of code into your theme’s functions.php file and adjust the CSS on line 4 as needed.

//Theme login screen
function replace_login_logo() {
 $style = '<style type="text/css">';
 $style .= '#login h1 { background: url( ' .  get_stylesheet_directory_uri() . '/images/logo.gif ) no-repeat scroll center top transparent; display: block; height: 118px; overflow: hidden; padding-bottom: 15px; text-indent: -9999px; width: 369px; margin-left: -25px; }';
 $style .= '#login h1 a { display: none; }';
 $style .= '</style>';
 echo $style;
}
add_action( 'login_head', 'replace_login_logo' );
Posted on November 6, 2010March 15, 2017Categories Code, Tech & Tools, WordPressTags Logo, WordPress, wp-login, wp-login.php
Privacy Policy Proudly powered by WordPress