How to refuse access by IP address

1. My Caddy version (caddy -version):

Caddy v1.0.0 (h1:KI6RPGih2GFzWRPG8s9clKK28Ns4ZlVMKR/v7mxq6+c=)

2. How I run Caddy:

/usr/local/bin/caddy -agree -log /var/log/caddy/caddy.log -email dont@harvest.me -conf /root/Caddyfile -root /var/www/none -pidfile /var/run/caddy.pid

a. System environment:

Ubuntu 16.04.6 LTS

d. My complete Caddyfile:

(log) {
  tls peter@passchier.net
  gzip
  # Use stderr & stdout for systemd
  errors /var/log/caddy/error.log
  log /var/log/caddy/access.log
}

(php) {
  import log
  fastcgi / /var/run/php/php7.0-fpm.sock php
}

compare.4e4.win {
  import php
  root /var/www/lampang/compare
}

a-di.eu {
  import log
  redir https://knowgod.in.th/
}

zending.ga {
  import log
  redir https://omf.org/nederland/
}

3. The problem I’m having:

When using the IP address of the server in the browser, I get “site not served on this interface” from caddy on port 80 and “Secure Connection Failed” from the browser on port 443.

What I would like to get is for these access attempts to be completely ignored. Is that possible within caddy? Or is that possible outside of caddy??

4. Error messages and/or full log output:

See 3.

You are effectively already refusing access to requests for an IP address as Caddy isn’t serving a site for an IP address.

What would your ideal solution look like instead?

But this is caddy, right? “404 Site 45.58.49.179 is not served on this interface”

I was hoping for a response similar to not having anything serving those ports, like the browser saying “The connection has timed out”.

Yes, that is Caddy refusing to serve anything because it’s not configured to serve your IP address as a hostname.

Caddy can’t help you with this, I’m afraid. The requested hostname is just one part of the HTTP request itself.

By the time Caddy is receiving information from the client - including which hostname the client wants - the connection is already established and it’s too late to go back in time and deny them access to the port.

Imagine it’s like a phone call. The caller dials a number (the client connecting to an IP address on port 80), the recipient answers (the operating system accepts the connection), the caller identifies themselves and asks for something (client says “Hi, I’m <CLIENT> and I want <WEBSITE>”), the recipient now responds (Caddy replies “Yes, I can help you, here’s the site” or “No, I can’t help you”).

The thing is, when accessed on port 443 with an IP address, it is likely to come up with “Secure Connection Failed” in the browser, unless you get an SSL certificate on the IP address. I can catch port 80, I was just wondering if there was a nice uniform way of dealing with this. What do other people do?

There’s no standard way of handling this. Generally, people leave it as is (TLS fails, and HTTP returns “site not served”).

“Secure Connection Failed” is a side effect of Caddy not having a valid certificate. Caddy does not attempt to provide one at all for unconfigured sites, so TLS connections will always fail. Back when Caddy used to use the first available certificate it actually had (which would be invalid - wrong domain - but still allowed a user to click through the error), a user clicking through would get the same result on HTTPS as they would on HTTP (“site not served”), just with a red padlock.

As a general rule, your average internet users do not manually browse to IP addresses. Don’t advertise your IP address as a valid website anywhere, tell real clients to use your actual domain, and everything should be fine. Bots, scanners, etc might get these responses when they’re enumerating addresses, but you don’t care about them, and they know how to handle this result anyway.

2 Likes

OK, so you recommend leaving the Caddyfile as is, no catchall of some sort at all?

Nah. I don’t run catchalls on any of my Caddy servers.

If you really wanted to get pedantic about it, you could look into pointing fail2ban at your access log to IP-block repeat offenders making requests to your IP address or other invalid hostnames.

1 Like

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