Month: November 2022

Technology

Improving WordPress Login Security

WordPress is the most common CMS used by websites, recently topping 43% market share of all sites currently on the internet.

With such a significant presence, it is also the largest target for website hackers, and given that it is open-source, good and bad actors are always examining the code for vulnerabilities.

There are plenty of things you can do to tighten defences – the Wordfence plugin is an excellent start, that I highly recommend.

https://flickr.com/photos/136770128@N07/40492737110

Another thing you can do is restrict access to the “wp-login.php” script, based on IP address – however, note that this solution will only work if you have a fixed and known IP address from which you will be logging in to your site.

If you move around, you’re probably locking yourself out of your own website console unless you’re at the IP address we’ll use in the example below. The example below is specific to Apache web servers, but the same principle can be applied to other configurations.

Let’s say my IP address is “aa.bb.cc.dd”. Put the following in the virtual host configuration for your WordPress website, and you can now only log in to your website from that IP address. Your site is still completely visible to the internet, but even if someone has your username and password, that login will be denied – they won’t even get to the login page.

<Location />
  ErrorDocument 403 /idontthinksotim
</Location>
<Files wp-login.php>
  order deny,allow
  deny from all
  allow from aa.bb.cc.dd
</Files>

The “order deny,allow” command tells Apache that it should follow any “deny” command access to “wp-login.php” first. The “deny from all” command is the only example of that that we need here. The “allow from aa.bb.cc.dd” command allows only the specifically listed IP address to get to “wp-login.php”.

You can of course add multiple “allow from” commands, and if you understand CIDR notation, you can use that to specify ranges of IP addresses you might want to allow with a single entry.

The above code means every other IP address on the internet is denied access to “wp-login.php”, and causes a “403” error to be thrown. To make things nice and neat and pretty, I have redirected “403” errors to a URL that does not exist – so that visitors are greeted with a proper “404” page from your WordPress site, rather than the standard “403” Apache error screen.

One final note – there are lots of other ways for bad actors to compromise a website – this is just another potential tool in your bag of tricks to keep them out. Don’t assume your website is 100% protected if you do this. Hackers are clever people, and if they are determined they will find a way.

Technology

Extracting Wordfence Attacker Data

Wordfence is a web application firewall (WAF) designed for WordPress – (the most common website platform on the internet today) – which I have used and trusted for a long time.

Wordfence helps identify attacks and vulnerabilities on your WordPress sites and takes appropriate action to mitigate what it finds. It comes in two forms – a paid and unpaid version, where the paid version gives more rapid updates to its core list of security vulnerabilities and known bad actors, as well as direct support if your attacker does manage to breach your site.

https://www.flickr.com/photos/140988606@N08/36883845116

I highly recommend it – it can be a little tricky to configure but is well worth the effort.

When it finds something hitting your site, the most common thing it does is to block the IP address of the attacker, carte blanche.

As I operate a series of WordPress sites – (in both my professional and personal spheres) – it would be nice to be able to extract the list of all of the IP addresses Wordfence has blocked, to ingest that list into other security systems you might have so they can be reused to implement security policy on other internet facing assets.

I do exactly this to block these identified bad IP addresses for accessing any service on any server I am responsible for.

On the surface, the data Wordfence stores in your WordPress database isn’t easily identifiable as an IP address, so it needs to be translated, for which I use the following SQL:

SELECT `raw_data`.`ipaddress` AS `ipaddress`,`raw_data`.`count` AS `count` FROM (SELECT REPLACE(CONVERT(INET6_NTOA(`wordpress_database_name`.`wp_wfBlockedIPLog`.`IP`) USING utf8mb4),'::ffff:','') AS `ipaddress`,SUM(`wordpress_database_name`.`wp_wfBlockedIPLog`.`blockCount`) AS `count` FROM `wordpress_database_name`.`wp_wfBlockedIPLog` GROUP BY `ipaddress`) `raw_data` ORDER BY `raw_data`.`ipaddress`;

When using the above, change ‘wordpress_database_name’ to the actual name of the database your WordPress installation is using.

Also, I’ve noticed that sometimes the Wordfence table ‘wp_wfBlockedIPLog’ can have different capitalisation, and can appear to be ‘wp_wfblockediplog’ – just look for the table, and change the SQL above to suit the name as it stands in your database.

This query spits out a list of blocked IP addresses, and a count of how many times it has been blocked. I usually create a database view using this query so that it is queriable in the same way as a table, making it much easier to work with.

Once you have that, you can use the data to spread the knowledge of bad IP addresses across your infrastructure, and use the intelligence Wordfence provides to help secure that infrastructure.

Technology

First Use Of Mastodon API

With the growing exodus of people to various Mastodon instances in the wake of the purchase of Twitter by serial boofhead Elon Musk, people will be starting to look for integration tools to start exploiting the Mastodon API.

My first dabble into it has been to update my personal management console to post my links to my chosen Mastodon instance, as well as Twitter for the time being at least.

Here’s a simple PHP function I wrote this morning that allows for simple toots to be posted via scripts or other tools you might like to do this for.

function mastodon_toot ($user_token,$mastodon_url,$toot_content)
{
  $post_data = Array("status"=>"".@str_replace("\'","▒~V~R~V~R~@~Y",$toot_content)."","language"=>"eng","visibility"=>"public");
  $post_headers = ['Authorization: Bearer '.$user_token.''];
  $curl_handle = @curl_init();
  curl_setopt($curl_handle,CURLOPT_URL,"https://".$mastodon_url."/api/v1/statuses");
  curl_setopt($curl_handle,CURLOPT_POST,1);
  curl_setopt($curl_handle,CURLOPT_POSTFIELDS,$post_data);
  curl_setopt($curl_handle,CURLOPT_RETURNTRANSFER,TRUE);
  curl_setopt($curl_handle,CURLOPT_HTTPHEADER,$post_headers);
  $curl_execute = @json_decode(@curl_exec($curl_handle));
  $http_code = "".@curl_getinfo($curl_handle,CURLINFO_HTTP_CODE);
  @curl_close($curl_handle);
  if ($http_code <> "200") {
    $result_code = "HTP";
    $result_message = "cURL returned HTTP code '".$http_code."' when attempting post to the '".$mastodon_url."' instance!";
    $result_data = NULL;
  } else {
    $result_code = "AOK";
    $result_message = "The flilm is okie dokie!";
    $result_data = Array("api_response"=>$curl_execute,"toot_id"=>"".$curl_execute->id."");
  }
  return(Array("result_code"=>$result_code,"result_message"=>$result_message,"result_data"=>$result_data));
}

There are three required parameters – $user_token, $mastodon_url, and $toot_content.

To make use of the function, create an application within your Mastodon account. In most cases you’ll find this in “Preferences -> Development“, then click “New Application“.

Fill in the fields – just use the URL of your website for the requested URLs. We won’t be doing any two-way communication between your application and Mastodon, so they won’t matter in this instance. Save your new application.

Take note of the “Your access token” value – this is what needs to be passed to the function as $user_token. Remember, you must keep this token secret and secure – as anyone with the token will be able to post to Mastodon as if it were you.

The value of $mastodon_url should just be the name of your Mastodon instance – eg: for me, it is “aus.social”.

The value of $toot_content is exactly what it sounds like – whatever you want to post to Mastodon via your script.

The first line in the function does a little cleanup on the content, just to remove crappy characters – I’m not 100% sure this is needed for Mastodon, but I carried this over from my corresponding Twitter tweet function, and it seems to not cause any issues here – so it’s there!

And that’s it. The function returns an array with some diagnostic information – (did it/didn’t it work?) – and the ID of the toot posted, if it was successful.

While the above function is written in PHP, given I’ve chosen to use PHP’s cURL library, if your chosen scripting language is not PHP it should be pretty straightforward to use the cURL library for whichever language you prefer, to come up with an equivalent script.

Over time I’ll delve more into what the Mastodon API can achieve, but in the meantime, happy automated tooting!