Recommended way to close connection on requests to IP?

[bernd]

1. The problem I’m having:

On a server I have increasing traffic of bots scanning the server by performing requests to http://<IP-Address/.
Caddy responds with a 308 redirect to https://<IP-Address/.

I wonder if there is a recommended way to

• ignore requests to the raw IP (perfect)
• perform a connection reset below the application layer (like NGINX’s 444) (ok)
• respond w/out a location redirect (at least)

In that particular case I don’t want to return 403 code or the like as I see it more in the way of “it’s not forbidden, it’s just not configured”.

2. Error messages and/or full log output:

curl -I http://1.2.3.4/backup.sql

HTTP/1.1 308 Permanent Redirect
Connection: close
Location: https://1.2.3.4/backup.sql
Server: Caddy
Date: Wed, 26 Apr 2023 08:25:49 GMT

3. Caddy version:

latest

4. How I installed and ran Caddy:

a. System environment:

d. My complete Caddy config:

I just configured domain blocks.

example.com {
...
}

[matt (Matt Holt)]

@bernd

ignore requests to the raw IP (perfect)

I am not sure if this is possible, because the server can’t know the request is “to” the “raw IP” until it reads the Host header. To truly ignore the request would involve ignoring all requests, essentially turning off the server.

But what you can do is match on the Host header if it contains your IP and then abort the request:

http://1.2.3.4 {
    abort
}

That closes the connection uncleanly and doesn’t even write an HTTP response. I’d say it’s somewhere between your “perfect” and “ok” solutions.

Anyway, you could try that.

[bernd]

That seems to work (tested locally): Both curl and wget fail due to the abort, e.g.

* Empty reply from server
* Closing connection 0
curl: (52) Empty reply from server

I added it like this:

http://1.2.3.4, https://1.2.3.4 {
    abort
}

The runtime.log is empty for the http-request and only logs the tls_get_certificate event.

I’ll give it a try on production.

Thank you Matt!

[francislavoie]

@bernd

https://1.2.3.4

This doesn’t make sense – Caddy won’t have a certificate for that hostname anyways so the TLS handshake will never succeed, so HTTP routing never happens. You should only keep the http:// site address.

[bernd]

@francislavoie

This doesn’t make sense – Caddy won’t have a certificate for that hostname anyways so the TLS handshake will never succeed, so HTTP routing never happens. You should only keep the http:// site address.

In my local dev server I previously had a line

10.1.1.1, demo.dev {
...
}

so it created a certificate. I think. At least this is what I read out of the logs (DEBUG tls.handshake choosing certificate {"identifier": "10.1.1.1.", "num_choices": 1}).
Not on the prod server.

[francislavoie]

IP addresses are not eligible for publically trusted certs. You would’ve only had a cert if you used tls internal.

[matt (Matt Holt)]

@francislavoie

IP addresses are not eligible for publically trusted certs.

Generally true, but to be nuanced in case a future searcher finds this thread: they are eligible, but only some CAs offer them and only in certain ways (i.e. very few allow ACME to issue IP certs).

@francislavoie

You would’ve only had a cert if you used tls internal.

I’m pretty sure Caddy will issue its own self-signed cert for IP addresses, without needing to specify tls internal.