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

251–260 of 287 posts

Re: A story on home server security

#251

Post by yencabulator »

geye1234 wrote: post #84
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 am not a security person at all. Are you really saying that it could potentially cause Iptables to open ports without an admin's knowing? Is that shockingly, mind-bogglingly bad design on Docker's part, or is it just me? Worse, the linked bug report is from a DECADE ago, and the comments underneath don't seem to show any sense of urgency or concern about how bad this is. Have I missed something? This seems appallin…

> Is that shockingly, mind-bogglingly bad design on Docker's part, or is it just me?

This the default value for most aspects of Docker. Reading the source code & git history is a revelation of how badly things can be done, as long as you burn VC money for marketing. Do yourself a favor and avoid all things by that company / those people, they've never cared about quality.

Re: A story on home server security

#252

Post by ropable »

bluedino wrote: post #30
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…

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…

"Everybody gangsta 'bout infosec until their machine is cryptolockered." (some CISO, probably).

Re: A story on home server security

#253

Post by robertlagrant »

normie3000 wrote: post #203
talkin wrote: post #186

Earlier quoted context omitted.

Nobody said you shouldn’t do any due diligence. But 1 sprint vs 2 months of review really smells like ‘processes over people’. ;)

A more positive view would be that the security team may have had different priorities to the product team.

Two months of review after the work would be a lot more useful than before.

Re: A story on home server security

#254

Post by johntash »

diggan wrote: post #223
tomjen3 wrote: post #220

Earlier quoted context omitted.

To run Docker, you need to be an admin or in the Docker group, which warns you that it is equivalent to having sudo rights, AKA be an admin. As for it not being explicitly permitted, no ports are exposed by default. You must provide the docker run command with -p, for each port you want exposed. From their perspective, they're just doing exactly what you told them to do. Personally, I think it should default to givin…

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.

Re: A story on home server security

#255

Post by grayhatter »

rpadovani wrote: post #8

> "None of the database guides I followed had warned me about the dangers of exposing a docker containerized database to the internet." This prompts a reflection about, as an industry, we should make a better job in providing solid foundations. When I check tutorials on how to drill in the wall, there is (almost) no warning about how I could lose a finger doing so. It is expected that I know I should be careful aroun…

That's an interesting take away, I just quoted the exact same line from the blob to a friend with my response being

> why didn't somebody stop me?!

I'm not sure if "the industry" has a problem with relaying the reality that: the internet is full of malicious people that will try to hack you.

My take away was closer to. The author knew better but thought some mix of 1) no one would provide incomplete information 2) I'm not a target 3) containers are magic, and are safe. I say that because they admit as much immediately following.

> Ofcourse I password protected it, but seeing as it was meant to be temporary, I didn't dive into securing it properly.

Re: A story on home server security

#256

Post by pepa65 »

eadmund wrote: post #214
veyh wrote: post #125

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.

Be aware that there is an effort to repurpose most of 127.0.0.0/8: https://www.ietf.org/archive/id/draft-schoen-intarea-unicast... It’s well-intentioned, but I honestly believe that it would lead to a plethora of security problems. Maybe I am missing something, but it strikes me as on the level of irresponsibility of handing out guardless chainsaws to kindergartners.

That is awful and I hope it will never pass. It would be a security nightmare. If passed, it should lead to a very wide review of all software using 127/8, and that will never be comprehensive...

Re: A story on home server security

#257

Post by Fnoord »

jcgl wrote: post #243
Fnoord wrote: post #146

Earlier quoted context omitted.

Solid advice! I've had certain countries in my blocklist thus far, and now I have added Censys (I did not know that was the company behind Shodan). Now, I've also added the Tor exit node list as my blocklist. Since nothing good comes from any of these. I used this blocklist for the latter [1] (the Censys ranges I just did manually, as it is only 12 entries in total). [1] https://github.com/7c/torfilter

I hope you'll reconsider your stance on Tor exit nodes; many people use the Tor network to avoid censorship or even just bolster their own privacy. Blacklisting users on the basis of their Tor usage is hostile to their goals of privacy and anti-censorship.

There's no reason Tor exit nodes need to access my home network. Zero. I do use BitTorrent but behind a VPN; this remains unaffected, though if it were I would block traffic which isn't supposed to go through Tor (since BitTorrent over Tor is not recommended).

As a rule of thumb, I will gladly pass on Tor traffic, but no exit node, and I understand if network admins want to block entry node, too. It is a decision everyone who maintains a network has to make themselves.

The reason I block it is also the same reason I block banana republics like CN and RU: these don't prosecute people who break the law with regards to hacking. Why should one accept unrestricted traffic from these?

In the end, the open internet was once a TAZ [1] and unfortunately with the commercialization of the internet together with massive changes in geopolitics the ship sailed.

[1] https://en.m.wikipedia.org/wiki/Temporary_Autonomous_Zone

Re: A story on home server security

#258

Post by yobid20 »

AlgebraFox wrote: post #9

Tailscale is a great solution for this problem. I too run homeserver with Nextcloud and other stuff, but protected behind Tailscale (Wireguard) VPN. I can't even imagine exposing something like my family's personal data over internet, no matter how convenient it is. But I sympathize with OP. He is not a developer and it is sad that whatever software engineers produce is vulnerable to script kiddies. Exposing database…

c and c++ are not failing us and are not unsafe.

Re: A story on home server security

#259

Post by wbadart »

WaxProlix wrote: post #20
AlgebraFox wrote: post #9

Tailscale is a great solution for this problem. I too run homeserver with Nextcloud and other stuff, but protected behind Tailscale (Wireguard) VPN. I can't even imagine exposing something like my family's personal data over internet, no matter how convenient it is. But I sympathize with OP. He is not a developer and it is sad that whatever software engineers produce is vulnerable to script kiddies. Exposing database…

Thanks, I've got a homelab/server with a few layers of protection right now, but had been wanting to just move to a vpn based approach - this looks really nice and turnkey, though I dislike the requirement of using a 3P IDP. Still, promising. Cheers.

You might like ZeroTier[0]. Similar solution to Tailscale but supports email registration.

[0]: https://www.zerotier.com/

Re: A story on home server security

#260

Post by throwaway2037 »

malfist wrote: post #59
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…

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-...

Post reply on HN