4 ms·

> The beautiful thing about this scheme is that the cookie is always sent, so I can create a rule which bypasses auth when the cookie is present. You don't eve

> The beautiful thing about this scheme is that the cookie is always sent, so I can create a rule which bypasses auth when the cookie is present. You don't even need the basic auth for that. Years ago I needed to expose my pfsense WebGUI on the default HTTPS, but I didn't want it to be so obvious, so I made a couple of HAProxy rules, which allowed me to open https://pfsense.tld/open-sesame https://pfsense.tld/open-sesame to set a cookie, after which I could open the default https://pfsense.tld/ https://pfsense.tld/ just fine and see the WebGUI. Without the cookie there was just 404 for everyone. It wasn't the best realisation (and some parts of webgui didn't like it) but it worked and allowed me to access it even on the smartphone.

diarrhea 5y ago
Embracing security through obscurity like that is also how I decided to help protect my password manager, Vaultwarden. It's open to the internet on 80/443, but its URL is `subdomain.domain.tld/some-secret-path/`. It's dead simple, but indeed no unwanted visitors even see that site. Of course, even if they did, the regular login prompt with MFA appears.
- rambambram 5y ago
  I'm using something similar. Even if people tried to brute force their way to the hidden door, these attempts would probably be blocked by Cloudflare.
- pronoiac 5y ago
  Have you checked if the secret path leaks in referrers?
  - diarrhea 5y ago
    It doesn't seem so. Clicking a random link from inside the Vaultwarden webpage (which is never used anyway, in favor of the Bitwarden browser plugins) and following the requests in Firefox's Browser Console, no request has a Referer HTTP request header. Vaultwarden does not send the Referer header cross-origin: https://github.com/dani-garcia/vaultwarden/blob/920371929bc89f5000d26c55b834148b32c8058f/src/util.rs#L31 https://github.com/dani-garcia/vaultwarden/blob/920371929bc8... My home server uses Caddy and its JSON logs. These are incredibly easy to parse of course. Through the dynamic DNS solution I use (Docker image qmcgaw/ddns-updater), I have a list of all of my own IP addresses. Add to that others like my work's IPv4 block, and I get a collection of 'known', i.e. harmless IP addresses. Filtering these in a little pandas-based Python tool leaves all requests reaching the secret endpoint. Logs reach back around a week. Another tool 'enriches' each log entry with IP lookup info from ipinfo.io. Their free API tier is enough for my uses. That way, I can filter for request origin countries, hostnames, etc. The entire pipeline is automated, but triggered manually on-demand. So far, no hits from unknown IPs to the endpoint!
    - pronoiac 5y ago
      That's a good way to investigate; I would've pointed to a server I control and check the logs.
tlrobinson 5y ago
Kind of like “port knocking” but for HTTP.
- crtasm 5y ago
  I like the idea of a multistep version, load domain.com/string1, domain.com/string2, domain.com/string3 in order and within a certain timeframe.

diarrhea 5y ago

Embracing security through obscurity like that is also how I decided to help protect my password manager, Vaultwarden. It's open to the internet on 80/443, but its URL is `subdomain.domain.tld/some-secret-path/`. It's dead simple, but indeed no unwanted visitors even see that site. Of course, even if they did, the regular login prompt with MFA appears.

rambambram 5y ago
I'm using something similar. Even if people tried to brute force their way to the hidden door, these attempts would probably be blocked by Cloudflare.
pronoiac 5y ago
Have you checked if the secret path leaks in referrers?
- diarrhea 5y ago
  It doesn't seem so. Clicking a random link from inside the Vaultwarden webpage (which is never used anyway, in favor of the Bitwarden browser plugins) and following the requests in Firefox's Browser Console, no request has a Referer HTTP request header. Vaultwarden does not send the Referer header cross-origin: https://github.com/dani-garcia/vaultwarden/blob/920371929bc89f5000d26c55b834148b32c8058f/src/util.rs#L31 https://github.com/dani-garcia/vaultwarden/blob/920371929bc8... My home server uses Caddy and its JSON logs. These are incredibly easy to parse of course. Through the dynamic DNS solution I use (Docker image qmcgaw/ddns-updater), I have a list of all of my own IP addresses. Add to that others like my work's IPv4 block, and I get a collection of 'known', i.e. harmless IP addresses. Filtering these in a little pandas-based Python tool leaves all requests reaching the secret endpoint. Logs reach back around a week. Another tool 'enriches' each log entry with IP lookup info from ipinfo.io. Their free API tier is enough for my uses. That way, I can filter for request origin countries, hostnames, etc. The entire pipeline is automated, but triggered manually on-demand. So far, no hits from unknown IPs to the endpoint!
  - pronoiac 5y ago
    That's a good way to investigate; I would've pointed to a server I control and check the logs.

tlrobinson 5y ago

Kind of like “port knocking” but for HTTP.

crtasm 5y ago
I like the idea of a multistep version, load domain.com/string1, domain.com/string2, domain.com/string3 in order and within a certain timeframe.