On Neofeudalism and the Digital Manor, Cory Doctorow compares Apple, Microsoft, Google to warlords willing to defend your digital security… unless they’re compelled to turn on you by a government power, which, it turns out, happens quite a lot. A good reminder that all that sensitive information that they’re collecting on you, can and will be used against you, just as that seemingly well-intentioned control over your device will be abused.
Tag: security
Mitigating CVE-2018-6389 WordPress DoS attack with lighttpd
Early in 2018, Barak Tawily published a possible DoS attack for WordPress, that basically works by requesting all possible scripts on the /wp-admin/load-scripts.php, a script that fetches and concatenates javascript files — there’s also a load-styles.php file that does the same for styles.
His vulnerability report was rejected by the WordPress team, on the account that this type of attack should be mitigated at the server or network level… so how do you do that using lighttpd?
Actually it’s pretty easy using mod_evasive, a “very simplistic module to limit connections per IP”, as advertised on the lighttpd docs.
First, you must make sure that mod_evasive it’s enabled on the server.modules block:
server.modules = ( "mod_access", "mod_alias", "mod_compress", "mod_redirect", "mod_rewrite", "mod_accesslog", "mod_evasive" )
Then, on the main lighttpd config file you can add the following:
$HTTP["url"] =~ "/wp-admin/load-(styles|scripts).php(.*)" {
evasive.max-conns-per-ip = 8
}
This will effectively limit the amount of allowed connections to 8 by IP. Of course, you can adjust that value to whatever you need; 8 connections by IP it’s plenty enough for a “normal” editor use.
You can test if it’s working by “attacking” your server with siege or ab or your favourite benchmarking/load testing tool and checking your lighttpd error log, where this should appear:
2018-03-22 21:05:53: (mod_evasive.c.183) 192.168.33.1 turned away. Too many connections.
After testing, you might also want to add this to the lighttpd config:
evasive.silent = "enabled"
… that way, blocked IPs won’t be logged on the errors.log (which, on its own could trigger a DoS by repeatedly writing to the log file)
If you’re using nginx with HTTP/2, there’s an even better way.
Let’s talk about usernames
Usernames are a much, much harder problem than what you might think at first glance… even if you can get away with a really simple and naive implementation on a prototype, a large, global and secure service must consider lots of not-so-obvious details and possible attack vectors.
Let’s talk about usernames deals with the problem with uniqueness, homograph attacks, confusables and other security concerns that you might need to consider.
Using Basic Authentication with the WordPress HTTP API
Basic Authentication it’s often used as a simple security measure or as a temporary authentication method while developing with certain APIs.
While the WordPress HTTP API doesn’t have explicit support for basic authentication, it’s still possible to use it as a header:
$request = wp_remote_post(
$remote_api_endpoint,
array(
'body' => array( 'foo' => 'bar' ),
'headers' => array(
'Authorization' => 'Basic '. base64_encode( $username .':'. $password )
)
)
);
Remember that if you’re sending an unencrypted request, all the headers will be sent in plain text, so you should only use it over HTTPS.
What happens when shit happens
There’s a very entertaining and educational thread going on Hacker News about data loss and disaster recovery that came about an actual, ongoing, massive system outage at Gliffy… I’m sure everyone has a similar story to share.
Backups are simple
… or they should be, anyway.
I think that one of the more popular excuses around for not having backups it’s “I haven’t gotten to it”; usually because you don’t have the time to try that fantastic tutorial you found for encrypted-incremental-automatic-deduplicated-control-versioned-backups on Amazon S3.
The thing it’s… it’s ok if you don’t have time for it, because it means you’re doing your job… which very likely isn’t Chief Backups Officer. What it’s not ok it’s that you keep postponing your backups!
That’s why I think that when you’re first configuring your server you should immediately configure some sort of backup that:
- It’s very quick to setup, so you actually do it
- It’s easy to restore from, so it’s actually useful
And since I’m assuming you’re not an idiot, I know you’ll do your best to keep them safe; which doesn’t mean creating some new fancy encryption scheme but using existing tools to do the job (for instance, ssh and rsync are both encrypted, so they’re good enough for transmitting the data to another server).
I’m sure there are plenty cool alternatives to keep your data safe, but the truth it’s that if they don’t comply with these two basic requirements you should wonder if there’s a better, simpler way.
Comments on the Sony hack
That we live in the world where we aren’t sure if any given cyberattack is the work of a foreign government or a couple of guys should be scary to us all
Check Sony got hacked hard: what we know and what we don’t know so far from Wired for a broad synthesis of the hack or A breakdown and analysis of the December, 2014 Sony hack from Risk Based Security for a more detailed perspective.