> DevOps, Developers, and IT practitioners often misconfigure some of the following: Binding the socket on the wrong network interfaces. For example, listening to connections from 0.0.0.0/* — So it is visible to all network interfaces, instead of only the inner-network interface IP address (172.x.x.x) Binding to 0.0.0.0 is unfortunately the default for Docker. I wish it would have been different.
Exactly my past experience. Carefully tweaking firewalld a couple of years ago, then docker punched a hole through them by injecting their own iptables rules. Rules which where opaque to the firewall-cmd of course.
I used to think you have to be pretty good af your job to get trusted to deploy stuff to the cloud for even medium sized companies. As these articles keep reminding me, you only need to fake competence to management to get the green light. Even if you forget that the cloud is the internet and that the entire internet can reach you over the internet, it doesn't take a genius to set up a password for a cloud service. I…
"it doesn't take a genius to set up a password for a cloud service."
Where are you going to store the password?
I'm not saying it's rocket science but it does take consideration. Do you store it in a plain text file on the server? How do you deal with CI/CD? Do you run a separate service for one credential?
I used to think you have to be pretty good af your job to get trusted to deploy stuff to the cloud for even medium sized companies. As these articles keep reminding me, you only need to fake competence to management to get the green light. Even if you forget that the cloud is the internet and that the entire internet can reach you over the internet, it doesn't take a genius to set up a password for a cloud service. I…
Yikes. I can't believe this and the responses all agree. There are two things at play here: The reality of what happens is that devs with limited experience are asked to do things far outside their comfort zone because they aren't staffed enough. This isn't on the dev, it's on the company and a reality when it comes to growth. People make mistakes. The second thing is that the databases themselves should be secure by…
>People make mistakes.
It's as simple as that. And at scale, it adds up to a lot of mistakes.
And for better or worse, much of the tech industry does not require extensive certification and training with checking and rechecking of every step. (And even aerospace makes mistakes.)
And, yes, junior people make even more mistakes. But I'm not sure the fix to that is to have junior people's every action be check and rechecked by a more senior person. It can be done. That's generally how things work in medicine for example. Along with stringent certifications. But I'm not sure how many people in tech would want that. It's a reasonable discussion to have. Maybe training wheels are taken off too early in many cases.
Another great example why I love to use managed services / serverless services and not take care of security groups and NACLs
Managed services don't save you from that. You still have to configure security groups to reach them and a lot of devs just use the easiest way and expose the thing to the internet.
Is there any additional information on this? Assuming I add a rule via `iptables -I INPUT -s 123.123.123.123 -p tcp --dport 8080 -j DROP` and on interface:port 0.0.0.0:8080 of the host is a container listening which got run as `docker run -d -p 0.0.0.0:8080:8080 some/server:latest` Will that container still be accessible to 123.123.123.132?
The Docker container is using a separate network namespace with a separate virtual interface that packets are routed to. The "PREROUTING" chain runs before the "INPUT" chain so yes, the rules you put in "INPUT" won't apply.
Its rules also go into the "nat" table instead of the "filter" table. Use "iptables -L -t nat" to display them.
I used to think you have to be pretty good af your job to get trusted to deploy stuff to the cloud for even medium sized companies. As these articles keep reminding me, you only need to fake competence to management to get the green light. Even if you forget that the cloud is the internet and that the entire internet can reach you over the internet, it doesn't take a genius to set up a password for a cloud service. I…
"it doesn't take a genius to set up a password for a cloud service." Where are you going to store the password? I'm not saying it's rocket science but it does take consideration. Do you store it in a plain text file on the server? How do you deal with CI/CD? Do you run a separate service for one credential?
Really simple solutions.
AWS itself has a Secrets Manager from which other authorized services can pull secrets. If it's an outside CI/CD platform then those usually also have a place to store credentials.
Strange, I've never seen this before. I've been running Docker for years on one of my pet project machines, but while Docker is exposing the ports on 0.0.0.0 my iptables firewall blocks all of them. I'm not using --iptables=false but I'm not discounting the possibility that maybe I've configured this on a more global level somewhere.
That is still strange ; as you can read from others, docker refreshes it’s own iptable rules which then can mess with your own. Maybe you were lucky but seems unlikely to have that much luck. Be careful anyway; if you opened a port, it’ll be on 0.0.0.0 and docker does rearrange your iptables when the container(s) start. Especially default redis and mongo are good foot-shooters.
I don't quite understand it either. I just triple checked though, the ports are filtered from the outside. I do have a bunch of "docker network isolation" things going on in my iptables setup, so maybe that's why.
Even if you've firewalled you machine, Docker will happily open up the ports to the world, you have to run it with "--iptables=false" to stop it. I accidentally opened up a Redis test-instance to the world like this.
Even better, docker-compose doesn't do IPV6 (well). But if you have an IPV6 address, it will NAT all the incoming IPV6 traffic on the open ports to IPV4 using the internal network gateway address. So, if you're doing any filtering for internal network addresses == internal traffic, congratulations, now your inbound external IPV6 traffic is recognized as internal.
And even better 0.0.0.0 isn’t the default on Docker For Mac, leading devs to a false sense of security who develop on Macs.
Many years ago it was BBS systems and then as Windows took off it became SMB shares, fun times for sure. It then transitioned to databases open and exposed to the WAN and once those admins became educated the targets were RDP clients that were poorly designed, radmin anyone? Everything to this point led to the Payment Card Industry (P.C.I.) founding as losses accrued and blame assignment for cost absorption was needed. As APIs took off, where we are now, the era of data vacuuming everything insecure continues inclusive of AWS. The future however will redefine what it means to build secure software from day zero as IoT devices that control life and property will continue to grow in popularity as well as attack. Industrial, commercial and residential targets grow by the day such as SCADA, lighting control, hot water tanks, faucets, toilets and all the other devices that will become smart in one's life but I would be remiss to not mention the most important items that will enable remote life manipulation, medical devices. What you cannot see matters most and as connectivity of everything grows exponentially one is likely to not even see it coming. Stay Healthy!