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

261–270 of 287 posts

Re: A story on home server security

#261

Post by harrall »

dijit wrote: post #54
bluedino wrote: post #30

Earlier quoted context omitted.

Containers are widely used at our company, by developers who don't understand underlying concepts, and they often expose services on all interfaces, or to all hosts. You can explain this to them, they don't care, you can even demonstrate how you can access their data without permission, and they don't get it. Their app "works" and that's the end of it. Ironically enough even cybersecurity doesn't catch them for it, t…

This is pretty common, developers are focused on making things that work. Sysadmins were always the ones who focused on making things secure, and for a bunch of reasons they basically don’t exist anymore. EDIT: what guidelines did I break?

Sometimes when you work less rigidly as a team, covering for others when it’s convenient for you, everyone gets more things done with less stress and less trouble.

And you go home at 5pm and had a good work day.

Re: A story on home server security

#263

Post by harrall »

phoronixrly wrote: post #25
matharmin wrote: post #10

I think I'm missing something here - what is specific about Docker in the exploit? Nowhere is it mentioned what the actual exploit was, and whether for example a non-containerized postgres would have avoided it. Should the recommendation rather be "don't expose anything from your home network publically unless it's properly secured"?

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 doesn’t expose ports by default. It only bypasses your firewall if you choose to explicitly publish a port.

OP explicitly forwarded a port in Docker to their home network.

OP explicitly forwarded their port on their router to the Internet.

OP may have ran Postgres as root.

OP may have used a default password.

OP got hacked.

Imagine having done these same steps on a bare metal server.

Re: A story on home server security

#264

Post by globular-toast »

Volundr wrote: post #143
globular-toast wrote: post #32

Earlier quoted context omitted.

This is only an issue if you run Docker on your firewall, which you absolutely should not.

Do you not run firewalls on your internal facing machines to make sure they only have the correct ports exposed? Security isn't just an at the edge thing.

No. That would be incredibly annoying and it's probably why docker overrides it as it would cause all manner of confusion.

Re: A story on home server security

#265

Post by phoronixrly »

63stack wrote: post #238
phoronixrly wrote: post #92

Earlier quoted context omitted.

Are you sure about that? Last I checked pg admins had command execution on the DB host, as well as FS r/w and traversal. See https://www.postgresql.org/docs/current/sql-copy.html#id-1.9... Specifically the `filename` and `PROGRAM` parameters. And that is documented expected out of the box behaviour without even looking for an exploit...

It's funny that you said TFA a few comments earlier, because you seem to have not read the article either, or are making some great leaps here. If the break in happened as you would explain the article would also mention that: * the attacker gained access to the postgres user or equally privileged user * they used specific SQL commands to execute code * would have not claimed the vulnerability was about docker contai…

The article would only say that if OP was competent enough to determine exactly what went wrong. I did read the article however I do not agree with the conclusions in it as simply opening a postgres port to the Internet while having set up authentication correctly, is not fatal (though admittedly inadvisable).

Re: A story on home server security

#266

Post by phoronixrly »

harrall wrote: post #263
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 doesn’t expose ports by default. It only bypasses your firewall if you choose to explicitly publish a port. OP explicitly forwarded a port in Docker to their home network. OP explicitly forwarded their port on their router to the Internet. OP may have ran Postgres as root. OP may have used a default password. OP got hacked. Imagine having done these same steps on a bare metal server.

I do imagine:

1. postgres would have a sane default pg_hba disallowing remote superuser access.

2. postgres would not be running as root.

3. postgres would not have a default superuser password, as it uses peer authentication by default.

4. If ran on a redhat-derived distro, postgres would be a subject to selinux restrictions.

And yes, all of these can be circumvented by an incompetent admin.

Re: A story on home server security

#267

Post by globular-toast »

tommy_axle wrote: post #249
matharmin wrote: post #10

I think I'm missing something here - what is specific about Docker in the exploit? Nowhere is it mentioned what the actual exploit was, and whether for example a non-containerized postgres would have avoided it. Should the recommendation rather be "don't expose anything from your home network publically unless it's properly secured"?

This is one that can sneak up on you even when you're not intentionally exposing a port to the internet. Docker manages iptables directly by default (you can disable it but the networking between compose services will be messed up). Another common case this can bite you is if using an iptables front-end like ufw and thinking you're exposing just the application. Then unless you bind to localhost then Posgres in this…

All this talk of iptables etc is really confusing. People don't use iptables rules on servers do they? Ubuntu server has the option to enable ufw but it's disabled by default because it would be a really annoying default for a server which is by definition supposed to have services. I couldn't imagine trying to wrangle firewall rules across every box on the network vs using network segregation and firewall appliances at the edges. Is there some confusion here between running docker on your dev box vs running it on a server to intentionally run network services?

Re: A story on home server security

#268

Post by junon »

globular-toast wrote: post #267
tommy_axle wrote: post #249

Earlier quoted context omitted.

This is one that can sneak up on you even when you're not intentionally exposing a port to the internet. Docker manages iptables directly by default (you can disable it but the networking between compose services will be messed up). Another common case this can bite you is if using an iptables front-end like ufw and thinking you're exposing just the application. Then unless you bind to localhost then Posgres in this…

All this talk of iptables etc is really confusing. People don't use iptables rules on servers do they? Ubuntu server has the option to enable ufw but it's disabled by default because it would be a really annoying default for a server which is by definition supposed to have services. I couldn't imagine trying to wrangle firewall rules across every box on the network vs using network segregation and firewall appliances…

Yes, they do. At least back when I was at ZEIT, docker definitely used iptables directly. I know this because I was patching them as part of our infra that managed Docker at the time.

Re: A story on home server security

#269

Post by joseda-hg »

throwaway2037 wrote: post #260
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…

> My team where I work is responsible for sending frivolous newsletters via email and sms to over a million employees. "frivolous newsletters" -- Thank you for your honesty! Real question: One million employees!? Even Foxconn doesn't have one million employees. That leaves only Amazon and Walmart according to this link: https://www.statista.com/statistics/264671/top-50-companies-...

To a million employees doesn't necessarily mean they're from the same company

They might be a third party service for companies to send mail to _their_ employees

Re: A story on home server security

#270

Post by diggan »

johntash wrote: post #254
diggan wrote: post #223

Earlier quoted context omitted.

I don't remember the particular syntax, but isn't there a different to binding a port on the address the container runs on, VS binding a port on the host address? Maybe it's the difference between "-P" and "-p", or specifying both "8080:8080" instead of "8080", but there is a difference, especially since one wouldn't be reachable outside of your machine and the other one would be on worse case trying to bind 0.0.0.0.

You can specify the interface address to listen on, like "127.0.0.1:8080:8080" or "192.168.1.100:8080:8080". I have a lot of containers exposed like this but bind specifically to a vpn ip on the host so that they don't get exposed externally by default.

The trouble is that docker seems to default to using 0.0.0.0, so if you do `docker run -it -p 8080 node:latest` for example, now that container accepts incoming connections on port :32768 or whatever docker happens to assign it, which is bananas default behavior.
Post reply on HN