Tag: lighttpd

Mitigating CVE-2018-6389 WordPress DoS attack with lighttpd

Posted on by

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.

Un-breaking lighttpd’s broken mod_access

Posted on by

A client let us know that the server where her company’s site was hosted had an unusually high load.

After checking the access log for the web server, it was clear that the cause was repeated access attempts at a single URL, which was not essential to the site. So I though this should be easy, I’ll just block the request in the web server config. Unfortunately, they were using a very outdated version of lighttpd, so it wasn’t that easy.

It seems that older lighttpd builds had several bugs with mod_access, but the worst in our case was that instead of blocking the request and send a 403 Forbidden, it passed the request on to the 404 error handler, and this loaded the entire app enviroment.

So here’s what I did. The lighttpd config looked like this:

$HTTP["url"] =~ "^/foobar.php" {
    url.access-deny = ("")
    server.error-handler-404 = "/403.php"
}

… so request to foobar.php would be handled by 403.php. And then, 403.php:

<?php header('HTTP/1.0 403 Forbidden'); ?>
<h1>Forbidden</h1>

Very silly, but effective. Just because status codes matter.

Por qué y cómo implementar un nombre de dominio canónico

Posted on by

Es bastante frecuente que un cliente tenga el registro de más de un nombre de dominio para su sitio web, así como también que desee que su sitio esté accesible a través de cualquiera de sus dominios… sin embargo, disponibilizar el mismo contenido a través de distintas URL no es una buena idea, sino que siempre debemos preferir configurar un dominio como el principal.

A continuación, por qué es preferible utilizar solamente un dominio para tu sitio, y cómo configurarlo en distintos servidores web.

Continue reading “Por qué y cómo implementar un nombre de dominio canónico”