Banned IP issue via Caddy

Configuration
1

Lately I get -almost on a daily basis- my Caddy Server IP banned. Looking at the Caddy log at the time the IP gets banned (=time from IP ban. Yaml) I see below (ignore the xxx in the url):

104.132.40.72 - - [18/Jan/2019:11:39:50 +0000] "GET /api/websocket HTTP/1.1" 200 0
104.132.40.72 - - [18/Jan/2019:12:03:04 +0000] "GET /api/camera_proxy/camera.bikes?token=5497b0c87e2e75fb6dc8ff263xxxxxxxxxx2921e7f6eaf5e81f5 HTTP/2.0" 401 17
104.132.40.72 - - [18/Jan/2019:12:03:04 +0000] "GET /api/camera_proxy/camera.garage_front?token=d0cbc0562a14153c4234f22b812768exxxxxxxxb5db3b6936f27fd4180af2 HTTP/2.0" 401 17
104.132.40.72 - - [18/Jan/2019:12:03:04 +0000] "GET /api/camera_proxy/camera.garage_back?token=0ea7ae17800070aa0c9af29ab6fe44f6ed23xxxxxxxx4749ff06cee745 HTTP/2.0" 401 17
104.132.40.72 - - [18/Jan/2019:12:03:04 +0000] "GET /api/camera_proxy/camera.front?token=b53dac5e28384cf1b965867cf2378924fxxxxxxxx71037b1a6a3e0e833a7a HTTP/2.0" 401 17
104.132.40.72 - - [18/Jan/2019:12:03:04 +0000] "GET /api/camera_proxy/camera.frontdoor?token=c21bbcc9e45c540a1bf2ef94b1d41406xxxxxxx1c58e895bc01d910 HTTP/2.0" 401 17
104.132.40.72 - - [18/Jan/2019:12:03:04 +0000] "GET /api/camera_proxy/camera.back?token=874e80161c69fad7e289b68d77a76xxxxxxb7725d84e0637f4a312 HTTP/2.0" 403 14

It seems there is a relation with the camera’s. Can anyone interpret what is going on?

2

You have some sort of cloud camera?

Edit: that’s ok, that address resolves to xxx

3

The IP is fine, that’s my employer :wink:

I think (but not sure as I don’t exactly understand how to interpret the data) that it happens somehow if I pull camera info in the HASS interface when I’m remote but this is all internal; within hass config I have cameras configured which pull their info on the local network)

4

Ah ok, no worries removed it, I thought you meant it was constantly accessing your service.

That looks very much the same as what I see but I dont use tokens so dont have that part on mine. Do you get failed authentication messages in your HA log?

If the caddy server is being banned and not the end user IP, you mustn’t be using X-Forwarded-For to allow HA to see the clients real IP?

5

I setup caddy about two years ago and it was a small miracle I got it going. I have below in my caddyfile when it comes to Hass. Any better way to do this?

ha.xxxxxx.com {
    proxy / 192.168.1.196:8123 {
        transparent
        websocket
    }
tls [email protected]
log caddyhass.log
}
6

This is my whole file,

https://xx.org:9123 {
        header / {
                # Enable HTTP Strict Transport Security (HSTS) to force clients to always
                # connect via HTTPS (do not use if only testing)
                Strict-Transport-Security "max-age=31536000; includeSubdomains"
                # Enable cross-site filter (XSS) and tell browser to block detected attacks
                X-XSS-Protection "1; mode=block"
                # Prevent some browsers from MIME-sniffing a response away from the declared Content-Type
                X-Content-Type-Options "nosniff"
                # Disallow the site to be rendered within a frame (clickjacking protection)
                X-Frame-Options "SAMEORIGIN"
                Referrer-Policy "same-origin"
        }
        tls /etc/letsencrypt/live/xxx.org/fullchain.pem /etc/letsencrypt/live/xxx.org/privkey.pem
        proxy / 127.0.0.1:8123 {
                websocket
                header_upstream Host {host}
                header_upstream X-Real-IP {remote}
                header_upstream X-Forwarded-For {remote}
                header_upstream X-Forwarded-Proto {scheme}
        }
        log /var/log/caddy-access.log {
                rotate_size 20
                rotate_age  14
                rotate_keep 4
                rotate_compress
        }
        errors stderr
}

https://:9123 {
        tls self_signed
        status 403 /
}

FYI the part at the bottom presents a fake self signed page if someone tries to access it via the IP not the full FQDN.

7

wow. That’s a bit more extensive. Do I understand correctly that you run caddy on the same server as hass (due to linking to 127.0.0.1:8123)?

8

Yeah, the part to add for the X-Forwarded-For is:

                header_upstream Host {host}
                header_upstream X-Real-IP {remote}
                header_upstream X-Forwarded-For {remote}
                header_upstream X-Forwarded-Proto {scheme}

configuration.yaml will need

http:
  use_x_forwarded_for: true
  trusted_proxies:
    - 127.0.0.1

There is a lot on the forums about issues with X-Forwarded-For but this comes about from two angles, letting the user set the X-Forwarded-For address so they look to be internal, and also having a trusted network enabled for internal devices.

9

Thanks. Is trusted proxys still the same IP if I have caddy on another server?

10

No its the caddy server.

11

Ok, added the lines to config yaml and copied your caddy file 1:1 where everything xxx.org changed to my domain. I can access hass remotly so file seems to work fine. Let’s see if that solves the issue. You setup seems safer anyway…

12

It might not solve it, it will just forward the correct address to home assistant so will ban the client, not caddy.

The second part is why it’s banning in the first place, are the token being used valid?

13

I did not use tokens for the cams. I just have (also, next to user authentication) the API password method enabled. Hass then seems to autogenerate the tokens. This is a normal camera integration with Hass, pulling the feed from the cams so conceptually no login into Hass from the cams needed(?)