6 ms·
I agree in principal but not in practice here. If you’re using a typical docker host, say CoreOS, following a standard production setup, then running your app
by headmelted 2y ago
I agree in principal but not in practice here.
If you’re using a typical docker host, say CoreOS, following a standard production setup, then running your app as a container on top of that (using an already hardened container that’s been audited), that whole stack has gone through a lot more review than your own custom-configured VPS. It also has several layers between the application and the host that would confine the application.
Docker would increase the attack surface, but a self-configured VPS would likely open a whole lot more windows and backdoors just by not being audited/reviewed.
- zilti 2y agoYou'd have to be utterly incompetent to make a self-configured VPS have more attack surface. I have a FreeBSD server, three open ports: SSH with cert-login only, and http/https that go to nginx. No extra ports or pages for potentially vulnerable config tools.
- oefrha 2y agoGiven the huge number of wide open production Mongo/ES/etc. instances dumped over the years, I wager having heard of ufw puts you among the top 50% of people deploying shit.
- llm_trw 2y agoThis whole thread is incomprehensible to me. I guess no one knows how to harden an OS anymore so we just put everything in a container someone else made and hope for the best.
- headmelted 2y agoI don’t think we need to be calling people incompetent over a disagreement. Are you suggesting that not opening the ports to any other services means they’re no longer a vulnerability concern? That would be.. concerning.