Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A story on home server security

raniseth.com

Post reply on HN
Print view View original

121–130 of 287 posts

Re: A story on home server security

#121

Post by malfist »

dfsegoat wrote: post #69
malfist wrote: post #59

Earlier quoted context omitted.

Checklist security at it's finest. My team where I work is responsible for sending frivolous newsletters via email and sms to over a million employees. We use an OTP for employees to verify they gave us the right email/phone number to send them to. Security sees "email/sms" and "OTP" and therefor, tickets us at the highest "must respond in 15 minutes" priority ticket every time an employee complains about having lost…

I feel this. Recently implemented a very trivial “otp to sign an electronic document” function in our app. Security heard “otp” and forced us through a 2 month security/architecture review process for this sign-off feature that we built with COTs libraries in a single sprint.

Oh I know that feeling. We got in hot water because the codes were 6 digits long and security decided we needed to make them eight digits.

We pushed back and initially they agreed with us and gave us an exception, but about a year later some compliance audit told them it was no longer acceptable and we had to change it ASAP. About a year after that they told us it needed to be ten characters alphanumeric and we did a find and replace in the code base for "verification code" and "otp" and called them verification strings, and security went away.

Re: A story on home server security

#122

Post by smarx007 »

dboreham wrote: post #114
diggan wrote: post #110

Earlier quoted context omitted.

Would that actually save you in this case? OP had their container exposed to the internet, listening for incoming remote connections. Wouldn't matter in that case if you're running a unprivileged container, podman, rocky-linux or with selinux, since everything is just wide open at that point.

I think it's more about whether traffic is bound to localhost or a routable interface. Podman has different behavior vs Docker.

I think exposing 8080:8080 would result in sockets bound to 0.0.0.0:8080 in either Docker or Podman. You still need 127.0.0.1:8080:8080 for the socket binding to be 127.0.0.1:8080 in Podman. The only difference is that Podman would not punch holes in the firewall after binding on 0.0.0.0:8080, thus preventing an unintended exposure given that the firewall is set up to block all incoming connections except on 443, for example.

Edit: just confirmed this to be sure.

    $ podman run --rm -p 8000:80 docker.io/library/nginx:mainline
    $ podman ps 
    CONTAINER ID  IMAGE                             COMMAND               CREATED         STATUS         PORTS                 NAMES
    595f71b33900  docker.io/library/nginx:mainline  nginx -g daemon o...  40 seconds ago  Up 41 seconds  0.0.0.0:8000->80/tcp  youthful_bouman
    $ ss -tulpn | rg 8000

    tcp   LISTEN 0      4096                                          *:8000             *:*    users:(("rootlessport",pid=727942,fd=10))

Re: A story on home server security

#123

Post by diggan »

phartenfeller wrote: post #77

A lot of people comment about Docker firewall issues. But it still doesn't answer how an exposed postgres instance leads to arbitrary code execution. My guess is that the attacker figured out or used the default password for the superuser. A quick lookup reveals that a pg superuser can create extension and run some system commands. I think the takeaway here is that the pg image should autogenerate a strong password o…

> I think the takeaway here is that the pg image should autogenerate a strong password or not start unless the user defines a strong one. Currently it just runs with "postgres" as the default username and password.

Takeaway for beginner application hosters (aka "webmasters") is to never expose something on the open internet unless you're 100% sure you absolutely have to. Everything should default to using a private network, and if you need to accept external connections, do so via some bastion host that isn't actually hosted on your network, which reaches into your private network via proper connections.

Re: A story on home server security

#124

Post by smarx007 »

dfsegoat wrote: post #69
malfist wrote: post #59

Earlier quoted context omitted.

Checklist security at it's finest. My team where I work is responsible for sending frivolous newsletters via email and sms to over a million employees. We use an OTP for employees to verify they gave us the right email/phone number to send them to. Security sees "email/sms" and "OTP" and therefor, tickets us at the highest "must respond in 15 minutes" priority ticket every time an employee complains about having lost…

I feel this. Recently implemented a very trivial “otp to sign an electronic document” function in our app. Security heard “otp” and forced us through a 2 month security/architecture review process for this sign-off feature that we built with COTs libraries in a single sprint.

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

Re: A story on home server security

#125

Post by veyh »

smarx007 wrote: post #16

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.

Re: A story on home server security

#126

Post by phoronixrly »

armsaw wrote: post #45
phoronixrly wrote: post #25

Earlier quoted context omitted.

From TFA: > This was somewhat releiving, as the latest change I made was spinning up a postgres_alpine container in Docker right before the holidays. Spinning it up was done in a hurry, as I wanted to have it available remotely for a personal project while I was away from home. This also meant that it was exposed to the internet, with open ports in the router firewall and everything. Considering the process had been…

Docker would punch through the host firewall by default, but the database wouldn’t be accessible to the internet unless the user opened the ports on their router firewall as well, which based on the article, it sounds like they did. Making the assumption they’re using a router firewall… In this case, seems like Docker provided a bit of security in keeping the malware sandboxed in the container, as opposed to infectin…

That's a bit of a stretch here... Had the attackers' target been to escape from the docker container, they would have done it. They may even have done it, we can't know as OP does not seem to have investigated thoroughly enough apart from seeing some errors and then stopping the container...

Also, had it been a part of the host distro, postgres may have had selinux or apparmor restrictions applied that could have prevented further damage apart from a dump of the DB...

Re: A story on home server security

#127

Post by ocdtrekkie »

kibwen wrote: post #108
lopkeny12ko wrote: post #48

Earlier quoted context omitted.

What motivates this attitude? Software, like anything else, needs to be actively maintained. This is a positive sign of technology evolution and improvement over time. To expect to run some software for 20 years without needing to apply a single security patch is ridiculous, and probably exactly the attitude that caused the author to get himself in this situation.

> To expect to run some software for 20 years without needing to apply a single security patch is ridiculous The whole point of my comment is that it's only "ridiculous" because of path dependency and the choices that we have made. There's no inherent need for this to be true, and to think otherwise is just learned helplessness.

Better security design fixes this. Sandstorm fixed this for self-hosters ten years ago (Sandstorm is designed to run unmaintained or actively malicious apps relatively safely), but people are still choosing the quick and easy path over the secure one.

Re: A story on home server security

#128

Post by smarx007 »

anthropodie wrote: post #101
MortyWaves wrote: post #76

Earlier quoted context omitted.

I want to use Podman but I keep reading the team feels podman-compose to be some crappy workaround they don’t really want to keep. This is daunting because: Take 50 random popular open source self-hostable solutions and the instructions are invariably: normal bare installation or docker compose. So what’s the ideal setup when using podman? Use compose anyway and hope it won’t be deprecated, or use SystemD as Podman s…

Podman supports kubernetes YAML or the quadlets option. It's fairly easy to convert docker-compose to one of these. Nowaday I just ask genAI to convert docker-compose to one of the above options and it almost always works.

Is there a blog post/tutorial on how to take a fairly complex docker-compose.yml and migrate it to quadlets?

UPD: hmm, seems quite promising - https://chat.mistral.ai/chat/1d8e15e9-2d1a-48c8-be3a-856254e...

Re: A story on home server security

#129

Post by oarsinsync »

kibwen wrote: post #108
lopkeny12ko wrote: post #48

Earlier quoted context omitted.

What motivates this attitude? Software, like anything else, needs to be actively maintained. This is a positive sign of technology evolution and improvement over time. To expect to run some software for 20 years without needing to apply a single security patch is ridiculous, and probably exactly the attitude that caused the author to get himself in this situation.

> To expect to run some software for 20 years without needing to apply a single security patch is ridiculous The whole point of my comment is that it's only "ridiculous" because of path dependency and the choices that we have made. There's no inherent need for this to be true, and to think otherwise is just learned helplessness.

Has there ever been any production software ever written that didn’t suffer from some kind of bug or exploit?

I don’t think imperfection is a choice we’ve made. I think imperfection is part of our nature.

That said, the current state of software development is absolutely a choice, and a shockingly poor one in my opinion.

Re: A story on home server security

#130

Post by oarsinsync »

WaxProlix wrote: post #60
fullspectrumdev wrote: post #53

Earlier quoted context omitted.

You absolutely can. Have you a credit card and a web browser? You can buy all sorts of heavy machinery and have it shipped to your door!

You've introduced a new element here - the credit card. And if you did have the money and whimsy it'd still show up with (regulated, mandatory, industry-standardized) safety documentation.

The credit card (or rather, money) was required to purchase the computer, much like it’s required to purchase other power tools or industrial machinery
Post reply on HN