Logs for https redirections goes to wrong log file

Help
1

1. Caddy version:

v2.6.2 h1:wKoFIxpmOJLGl3QXoo6PNbYvGW4xLEgo32GPBEjWL8o=

2. How I installed, and run Caddy:

curl -O “https://github.com/caddyserver/caddy/releases/download/v2.6.2/caddy_2.6.2_linux_arm64.tar.gz”

a. System environment:

Linux/Ubuntu

b. Command:

caddy run

c. Service/unit/compose file:

N/A

d. My complete Caddy config:

:80 :443 {
        log {
                output file ./abort.log
        }
        abort
}

foo.internal {
        respond "WELCOME"
        log {
                output file ./foo.log
        }
        tls internal
}

3. The problem I’m having:

I am trying to capture unexpected requests (Mostly from port scanning bots hunting for vulnerable servers) in a different log file and real requests in a different log file.
When someone requests http://foo.internal, caddy automatically redirects to https://foo.internal as expected. However the redirection log is written to abort.log instead of foo.log. I can post process the log to exclude those re-directions. But is there a better/cleaner way to configure expected and unexpected requests to go to different logs?

Side note: Unexpected https requests don’t get logged at all.

4. Error messages and/or full log output:

❯ cat abort.log 
2023/01/28 02:23:43.251 info    http.log.access.log0    handled request {"request": {"remote_ip": "127.0.0.1", "remote_port": "48370", "proto": "HTTP/1.1", "method": "GET", "host": "foo.internal", "uri": "/foobar", "headers": {"User-Agent": ["curl/7.81.0"], "Accept": ["*/*"]}}, "user_id": "", "duration": 0.002897993, "size": 0, "status": 308, "resp_headers": {"Location": ["https://foo.internal/foobar"], "Content-Type": [], "Server": ["Caddy"], "Connection": ["close"]}}

5. What I already tried:

See Caddyfile.

6. Links to relevant resources:

N/A

2

Your config doesn’t specifically handle http://foo.internal, it only configures HTTPS.

Caddy’s Automatic HTTPS routine sets up the HTTP->HTTPS redirects, and that happens on the HTTP server.

You configured the HTTP server (with the :80 site address) to log to abort.log. So that’s what Caddy does.

You can see how this behaves by adapting your config to JSON, it should give you an idea of how it works. Run caddy adapt --config path/to/Caddyfile --pretty

If you want the redirect for known domains to log elsewhere, you’ll need to explicitly configure that. Add a site like this I guess:

http://foo.internal {
        log {
                output file ./foo.log
        }
}

Yep, that’s normal. Failed TLS handshakes don’t reach the HTTP handlers.

3

Had to add explicit redir as well.

http://foo.internal {
    log {
        output file ./foo.log
    }
    redir https://foo.internal{uri}
}

Failed TLS handshakes don’t reach the HTTP handlers.

I understand it does not reach the headers. Is there any way to collect those ip addresses? Without caddy logging it, the only way is then to log all ips from iptables and then filter out expected ones from caddy’s log. This is both slow and complex. :frowning:

4

If you enable debug level logging, you can see the TLS handshake failures. But that will significantly increase the amount of logs Caddy produces.

Frankly, I don’t think you need to worry about blocking those IP addresses unless you’re being hammered with requests via a targeted attack. They fail early and fast.

5

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