Posted by jakelsaunders94 7 days ago
An inbound firewall can only help protect services that aren't meant to be reachable on the public internet. This service was exposed to the internet intentionally so a firewall wouldn't have helped avoid the breach.
The lesson to me is that keeping up with security updates helps prevent publicly exposed services from getting hacked.
js scripts running on frameworks running inside containers
PS so I see the host ended up staying uncompromised
Unless ran as root this could return file not found because of missing permissions, and not just because the file doesn't actually exist, right?
> “I don’t use X” doesn’t mean your dependencies don’t use X
That is beyond obvious, and I don't understand how anyone would feel safe from reading about a CVE on a widely used technology when they run dozens of containers on their server. I have docker containers and as soon as I read the article I went and checked because I have no idea what technology most are built with.
> No more Umami. I’m salty. The CVE was disclosed, they patched it, but I’m not running Next.js-based analytics anymore.
Nonsensical reaction.
Nothing is immune. What analytics are you going to run? If you roll your own you'll probably leave a hole somewhere.
But kudos for the word play!
Backend access trivial with Tailscale, etc.
Cloudflare can certainly do more (e.g. protect against DoS and hide your personal IP if your server is at home).
If you plug in a machine at home, it is behind the router, and behind the router's firewall.
If you want more of a firewall locally, something as simple as an EdgeRouter X can get you started easily with this excellent guide: https://github.com/mjp66/Ubiquiti
The nice thing about using cloudflare tunnel, is theres zero ports to expose, ever. The cloudflare tunnel app running on your local machine is what connects out to the internet and takes care of creating a secure connection between cloudflare and your machine.
If you want to forward more than one port to the machine, you could use something like cloudflare to forward to a machine on your home server, and then have the nginx proxy manager or something send the traffic around internally.
It's totally fine to start with cloudflare, and if you aren't already, something like Proxmox (youtube tutorials are pretty quick) gets you up and running and playing pretty quick. Feel free to ask any other questions you like.
One thing I don't really get is why it is "more dangerous" to expose a port on my home IP, versus exposing a port on a Cloudflare tunnel. In both cases, a random user from the Internet can reach my server, and if I host a vulnerable application on that exposed port, it can be exploited. Right?
In order to host my server at home, but keep it outside my LAN, I have been considering having two routers: a "perimeter" router (not sure if that's how it's called) that connects to my ISP, and my normal "LAN" router. The LAN router does not expose anything, as usual. I connect my server to the perimeter router, so that it is in the "DMZ" between both routers. And on the perimeter router, I expose the port to my server. My idea being that if my server gets hacked, it doesn't affect my LAN. A bit like if my server was on a remote VPS.
And then I can run something like proxmox to separate my different services on my server.
But doing this, I expose my home IP instead of a Cloudflare IP, so now I'm concerned that maybe it is a risk? :-)
- exposes the port to be available for inbound connections from anyone on the public internet. When we use a web browser, it's outbound first which initiates responses.
- with an exposed port, you are that much more at the mercy of your firewalls ability to protect and defend the open port, which becomes more of a consideration.
- some people take additional security steps to only allow certain IPs to connect to the exposed port if it works for their scenario.
Compared with the Cloudflare Tunnel:
- if it's a website, for example, nothing is open to the public at all. The CF Tunnel (or a similar tool) conencts first outbound to Cloudflare to setup a secure link between your home server.
- having this amount of security can make it harder to connect back to your own server for admin - this is where a tool like Tailscale (also free) can be handy, where you can continue to have full secured access to the server, and the public side only has whatever you want to expose to the public internet.
- if there's a port or service in specific you're looking to sort out feel free to ask.
Network design:
- keeping a server at home outside of your LAN is a good idea, it could be a perimeter router. DMZ can mean exposed to the internet without a firewall.
- if you read the guide I posted above, it's sounds like an exact match for what your'e trying to figure out - it achieves it with multiple VLANS to separate traffic rules. The PDF has some nice graphics to break it out - I wish I had somethign like this when starting out. The concepts described in the PDF should be possible on most equipment that exposes the settings, and while I don't endorse a particular product, the Ubiquiti EdgeRouter X for the $50 or so is very capable as a starting point for what you are after to be the main router. In thet case of adding a dedicated router like this, you would have to switch your modem into "bridging" mode to let this be the main router for everything. Wireless access points can then be individually added to it. Alternatively if something like pfSense interests you, their parent company makes Netgate equipment that a lot of people seem to love. Both are well represented and supported on Youtube to learn from as well.
But that alone would not solve the problem being a RCE from HTTP, that is why edge proxy provider like Cloudflare[0] and Fastfy[1] proactivily added protections in his WAF products.
Even cloudflare had an outage trying to protect his customers[3].
- [0] https://blog.cloudflare.com/waf-rules-react-vulnerability/ - [1] https://www.fastly.com/blog/fastlys-proactive-protection-cri... - [2] https://blog.cloudflare.com/5-december-2025-outage/
Backend access trivial with Tailscale, etc.
Public IP never needs to be used. You can just leave it an internal IP if you really want.
The firewall could run on a piece of dedicated equipment, where it might not be a server, or it could run in a container, on a dedicated computer, which might be the server.
Again, I'm only speaking about what I have experience with in addition to my past experience and have surprisingly found to run well despite thinking I'd never self-host again.
DNS is no issue. External DNS can be handled by Cloudflare and their waf. Their DNS service can can obsfucate your public IP, or ideally not need to use it at all with a Cloudflare tunnel installed directly on the server. This is free.
Backend access trivial with Tailscale, etc.
Public IP doesn't always need to be used. You can just leave it an internal IP if you really want.
Free way - sign up for a cloudflare account. Use the DNS on cloudflare, they wil put their public ip in front of your www.
Level 2 is install the cloudflare tunnel software on your server and you never need to use the public IP.
Backend access securely? Install Tailscale or headscale.
This should cover most web hosting scenarios. If there's additional ports or services, tools like nginx proxy manager (web based) or others can help. Some people put them on a dedicated VPS as a jump machine.
This way using the Public IP can almost be optional and locked down if needed. This is all before running a firewall on it.
I use them for self-hosting.
If you are using Cloudflare's DNS they can hide your IP on the dns record but it would still have to be locked down but some folks find ways to tighten that up too.
If you're using a bare metal server it can be broken up.
It's fair that it's a 3rd party's castle. At the same time until you know how to run and secure a server, some services are not a bad idea.
Some people run pangolin or nginx proxy manager on a cheap vps if it suits their use case which will securely connect to the server.
We are lucky that many of these ideas have already been discovered and hardened by people before us.
Even when I had bare metal servers connected to the internet, I would put a firewall like pfsense or something in between.
If I run vulnerable software, it will still be vulnerable through a Cloudflare tunnel, right?
Genuinely interested, I'm always scared to expose things to the internet :-).
With the amount of automated bots that port scan looking for anything/everything that's open, as well as scanning DNS records for server IPs that could be targeted, one of the nice patterns of cloud hosting is how application and data servers are hosted behind firewalls of some kind, to effectively be internal.
As for what's exposed to the web, let's say the payload of a website, if there was something vulnerable in the javascript, that could be a weakness hosted anywhere.
Cloudflare can also help achieve this without too much fuss for self-hosted projects, be it personal, and production grade, assuming the rest of the trimmings are tehre.
Oh I see, so that I benefit from the "professional" firewall of Cloudflare, as opposed to my own that I may have possibly misconfigured or forgot to update etc?
Or is there more, like Cloudflare will block IPs that know to come from malicious actors and things like this?
Keeping the IP secret seems like a misnomer.
Its often possible to lock down the public IP entirely to not accept connections except what's initiated from the inside (like the cloudflare tunnel or otherwise reaching out).
Something like a Cloudflare+tunnel on one side, tailscale or something to get into it on the other.
Folks other than me have written decent tutorials that have been helpful.