[Unsolved] Mitigating SlowLoris DoS | Caddy + PHP-FPM

1. Caddy version (caddy version):

v2.4.3 h1:Y1FaV2N4WO3rBqxSYA8UZsZTQdN+PwcoOcAiZTM8C0I=

2. How I run Caddy:

Installed from package manager, configuration located in Caddyfile. Running from systemctl start/stop. Launch commands and its options are default.

a. System environment:

Debian GNU/Linux 10 (buster) x86_64
3GB RAM
Generic VPS installation. Caddy is installed with PHP-FPM (7.3), and Redis as database. No docker etc.

b. Command:

systemctl restart caddy

c. Service/unit/compose file:

None.

d. My complete Caddyfile or JSON config:

{
        auto_https off
        servers {
                timeouts {
                        read_body 5s
                        read_header 5s
                        idle 15s
                }
        }
}

:80 {
        root * /var/www/html
        encode gzip
        file_server
        try_files {path}.php {path}
        route {
                @canonicalPath {
                        file {path}/index.php
                        not path */
                }
                redir @canonicalPath {path}/ 308
                @indexFiles file {
                        try_files {path} {path}/index.php
                        split_path .php
                }
                rewrite @indexFiles {http.matchers.file.relative}
                @phpFiles path *.php
                reverse_proxy @phpFiles unix//run/php/php7.3-fpm.sock {
                        transport fastcgi {
                                split .php
                        }
                }
        }
        handle_errors {
                respond "{http.error.status_code} {http.error.status_text}"
        }
        header Server Nginx
        log {
                output file /var/log/access.log
        }
}

3. The problem I’m having:

Service starts hanging, checking process status shows this output:

● php7.3-fpm.service - The PHP 7.3 FastCGI Process Manager
   Loaded: loaded (/lib/systemd/system/php7.3-fpm.service; enabled; vendor preset: enabled)
  Drop-In: /run/systemd/system/php7.3-fpm.service.d
           └─zzz-lxc-service.conf
   Active: active (running) since Mon 2021-08-23 12:01:47 UTC; 13min ago
     Docs: man:php-fpm7.3(8)
 Main PID: 5809 (php-fpm7.3)
   Status: "Processes active: 10, idle: 0, Requests: 289, slow: 0, Traffic: 1.3req/sec"
    Tasks: 11 (limit: 19155)
   Memory: 44.4M
   CGroup: /system.slice/php7.3-fpm.service
           ├─5809 php-fpm: master process (/etc/php/7.3/fpm/php-fpm.conf)
           ├─6634 php-fpm: pool www
           ├─6635 php-fpm: pool www
           ├─6636 php-fpm: pool www
           ├─6637 php-fpm: pool www
           ├─6638 php-fpm: pool www
           ├─6639 php-fpm: pool www
           ├─6640 php-fpm: pool www
           ├─6641 php-fpm: pool www
           ├─6642 php-fpm: pool www
           └─6643 php-fpm: pool www

Aug 23 12:01:47 SS systemd[1]: Starting The PHP 7.3 FastCGI Process Manager...
Aug 23 12:01:47 SS systemd[1]: Started The PHP 7.3 FastCGI Process Manager.

4. Error messages and/or full log output:

From Access.log - My access log is filled with these empty requests, that just hang up and time out after 30 seconds. The site is not available at all during this POST spam. The requests never seem to make it to the PHP logic as there is an automatic header redirection to another path than /.

{
	"level":"error",
	"ts":1629717560.6114402,
	"logger":"http.log.access.log0",
	"msg":"handled request",
	"request": {
		"remote_addr":"127.0.0.1:40992",
		"proto":"HTTP/1.1",
		"method":"POST",
		"host":"redacted-host-sorry.com",
		"uri":"/",
		"headers": {
			"Content-Type":["application/x-www-form-urlencoded"],
			"User-Agent":["Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)"],
			"Connection":["keep-alive"],
			"Keep-Alive":["900"],
			"Content-Length":["10000"]
		}
	},
	"common_log":"127.0.0.1 - - [23/Aug/2021:11:19:20 +0000] \"POST / HTTP/1.1\" 502 15",
	"duration":143.002335861,
	"size":15,
	"status":502,
}

5. What I already tried:

Tried to:

  • Mess with php-fpm settings, children and processes. No luck.
  • Tried to add timeouts both to PHP and to Caddy. No luck.

Only thing that works (temporarily) is restarting PHP-FPM.

6. Links to relevant resources:

None

Try turning on the debug global option, at least long enough to see what reverse_proxy is doing. If it’s PHP that gets bogged down, then that would be the bottleneck, rather than servers timeouts.

You could try playing with the fastcgi transport’s timeouts:

This topic was automatically closed after 30 days. New replies are no longer allowed.