201–210 of 287 posts
Earlier quoted context omitted.
I wonder how many people realize you can use the whole 127.0.0.0/8 address space, not just 127.0.0.1. I usually use a random address in that space for all of a specific project's services that need to be exposed, like 127.1.2.3:3000 for web and 127.1.2.3:5432 for postgres.
TIL I always thought it was /32
practically all these attacks require downloading remote files to the server once they gain access, using curl, wget or bash.
Restricting arbitrary downloads from curl, wget or bash (or better, any binary) makes these attacks pretty much useless.
Also these cryptominers are usually dropped to /tmp, /var/tmp or /dev/shm. They need internet access to work, so again, restricting outbound connections per binary usually mitigates these issues.
https://www.aquasec.com/blog/kinsing-malware-exploits-novel-...
Earlier quoted context omitted.
To be fair, I would also be alarmed, albeit not by OTP. "sign an electronic document" and "built with COTs libraries in a single sprint" is essentially begging for a security review. Signatures and their verification are non-trivial, case in point: https://news.ycombinator.com/item?id=42590307
Nobody said you shouldn’t do any due diligence. But 1 sprint vs 2 months of review really smells like ‘processes over people’. ;)
There usual route that people would take is either use VPN/tailscale/Clouflare Tunnels ..etc and only expose things locally and you will need to be on VPN network to access services. The other route is not to expose any ports and rely on reverse proxy. Actually you can combine the two approaches and it is relativity easy for non SWE homelab hobbyists.
I use HAProxy on PFSense to expose a home media server (among other services) for friends to access. It runs on a privileged LXC (because NFS) but as an unprivileged user. Is this reckless? Reading through all this makes me wonder if SSHFS (instead of NFS) with limited scope might be necessary.
Suppose you have the media server in its own VLAN/Subnet, chances are good that the firewall is instrumental in enforcing that security boundary. If any part of the layer-7 attack surface is running on the firewall... you probably get the idea.
Earlier quoted context omitted.
There's nothing wrong with wireguard at all if you already have the hosting service available. The core value add for Tailscale is that they provide/host the service coordinating your wireguard network. If I'm not mistaken, there's a self-hosted alternative that let's you run the core of Tailscale's service yourself if you're interested in managing wireguard.
What kind of "hosting service" are you referring to? Just run wireguard on the home server, or your router, and that's it. No more infra required.
The main reason I haven't jumped into hosting wireguard rather than using Tailscale is mainly because I reach for Tailscale to avoid exposing my home server to the public internet.
Earlier quoted context omitted.
Tbh I prefer not exposing any ports directly, and then throwing Tailscale on the network used by docker. This automatically protects everything behind a private network too.
Another option is using Cloudflare Tunnels (`cloudflared`), and stacking Cloudflare Access on top (for non-public services) to enforce authentication.
Earlier quoted context omitted.
Tbh I prefer not exposing any ports directly, and then throwing Tailscale on the network used by docker. This automatically protects everything behind a private network too.
Important to note that, even if you use Tailscale, the firewall punching happens regardless, so you still have to make sure you either: 1. Have some external firewall outside of the Docker host blocking the port 2. Explicitly tell Docker to bind to the Tailscale IP only
Does it? I think it only happens if you specifically enumerate the ports. You do not need to enumerate the ports at all if you're using Tailscale as a container.
Earlier quoted context omitted.
Tbh I prefer not exposing any ports directly, and then throwing Tailscale on the network used by docker. This automatically protects everything behind a private network too.
I would love to read a write-up on that! Are you doing something like https://tailscale.com/blog/docker-tailscale-guide ?
I have a tailscale container, and a traefik container. Then I use labels with all my other containers to expose themselves on Traefik.
Earlier quoted context omitted.
Of course, that means you need to run NixOS for that to work (which I also do everywhere) and there are networking problems with Docker/Podman in NixOS you need to address yourself. Whereas Docker "runs anywhere" these days. Worth noting the tradeoffs, but I agree using Nix for this makes life more pleasant and easy to maintain.
> that means you need to run NixOS for that to work Does it? I'm pretty sure you're able to run Nix (the package manager) on Arch Linux for example, I'm also pretty sure you can do that on things like macOS too but that I haven't tested myself. Or maybe something regarding this has changed recently?
edit: I actually never checked, but I guess nothing stops home-manager or nix-darwin from working too, but I don't think either supports running containers by default. EOD all NixOS does is make a systemd service which runs `docker run ..` for you.
Docker has a known security issue with port exposure in that it punches holes through the firewall without asking your permission, see https://github.com/moby/moby/issues/4737 I usually expose ports like `127.0.0.1:1234:1234` instead of `1234:1234`. As far as I understand, it still punches holes this way but to access the container, an attacker would need to get a packet routed to the host with a spoofed IP SRC set t…
I wonder how many people realize you can use the whole 127.0.0.0/8 address space, not just 127.0.0.1. I usually use a random address in that space for all of a specific project's services that need to be exposed, like 127.1.2.3:3000 for web and 127.1.2.3:5432 for postgres.