When you’re ready to ensure that no one visits your site over an insecure connection, the Strict Transport Security header is key.
Continue reading Ensuring encrypted web traffic with Strict Transport Security headers (HSTS)
When you’re ready to ensure that no one visits your site over an insecure connection, the Strict Transport Security header is key.
Continue reading Ensuring encrypted web traffic with Strict Transport Security headers (HSTS)
In my post two weeks about setting consistent headers in nginx, one of the headers I was concerned with was the Public Key Pinning header (HPKP). This, and the Strict Transport Security header (HSTS) are both defensive mechanisms meant to increase the reliability of secure connections to a given site.
Along with the joy and burden of running my own servers comes a great deal of paranoia. Are my machines secured against unauthorized access? Is my mailserver an open relay? Will DNS for ethitter.com keep working if my primary machine is down? What happens if something crashes? Do I have all of my configurations tracked should I need to rebuild one of the boxes?
These, and many similar questions, are so frequently thoughts of mine that I had no choice but to establish many layers of redundancy and backups, lest I be unable to focus on anything else.
Continue reading Assuaging my paranoia with redundancy and many, many backups
As noted previously, I’ve opted to serve all of my sites securely. I even went to far as to get ethitter.com on Chrome’s preload list, meaning no major browser even attempts an insecure connection to my site. Try loading http://ethitter.com/ in Chrome, Firefox, or Safari, and the browser will redirect to http://ethitter.com/ before my nginx configuration ever tells it to.
That vaguely-entertaining detail aside, this means that I’ve reason to be concerned about how soon my SSL certificates expire. The HPKP headers I set have 60-day lives, which I need to account for any time I renew the certificate for a pinned domain.
Continue reading Economically monitoring SSL certificate expiration
For the three visitors I attract in a month, I’ve had an outsized interest in making this the most secure WordPress site that I can. My focus of late has been primarily on the security-related headers I can set. In particular, ensuring that HSTS and HPKP were present on all requests became a priority.
A few weeks ago, I noticed that certain assets served from my CDN host lacked the Strict Transport Security headers (HSTS) I’d expected. To the best of my knowledge, I’d configured nginx to set these headers on every request.
Continue reading nginx header inconsistency, aka setting headers all the way down
As part of checking that that the plugins I maintain are ready for WordPress 3.6, I took the opportunity to fix a number of bugs, patch a few content disclosure vulnerabilities, and refactor some things I wasn’t pleased with.
Below is a rundown of all that changed. It’s worth noting that all of the plugins I actively maintain are compatible with WordPress 3.6, which will be released in the coming weeks.
Continue reading Updating all the plugins!
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?
In Microsoft’s recent advertisements promoting Windows 7, the company focuses on the various user-initiated features the new operating system includes. As far as I’ve seen, however, the company has not addressed the dual concerns of virus and spyware vulnerabilities. Similarly, the October 26 issue of Fortune Magazine, which declares “Microsoft Is Cool Again,” highlights various improvements Microsoft made to Windows 7 in response to the myriad problems that plagued Vista, but author Jeffrey O’Brien completely overlooked the securities vulnerabilities that malicious software poses. While I have no doubt that Windows 7 is a substantial improvement over Vista (my former employer upgraded to Vista, much to its chagrin), the risks arising from viruses and malware emphasize why, for security and other reasons, Mac OS X is my choice of operating system. As it turns out, though, Microsoft may not be showcasing its efforts to address these security risks because only certain editions of Windows 7 include a feature to deal with these problems.
Continue reading Windows 7 Advertising Misses The Point; Features, Not Security, Microsoft’s Focus