5 ms·

I can infer so many errors in the architecture, I wonder how this may have survived so far. 1. you put your DB in a server which is exposed to the internet. 2

I can infer so many errors in the architecture, I wonder how this may have survived so far. 1. you put your DB in a server which is exposed to the internet. 2. you have no VIP/NAT in front of your systems. 3. you rely in iptables , while knowing some automatic system is manipulating it. 3 hours? I wonder it took so long. I expect this infrastructure will be a script kiddies party room within a few minutes.

deleted 5y ago
[deleted]
Kiro 5y ago
As someone who has been running multiple services with millions of users for decades: 1. I need to be able to connect to my DB from anywhere. 2. No idea what that even means. 3. Don't know. Never even touched the firewall. I have a PW on my DB and that's it. Why do I need more than that?
- unionpivo 5y ago
  > 1. I need to be able to connect to my DB from anywhere. Understandable and reasonable. there are ways to achieve this without exposing the DB but it take some more effort. > 3. Don't know. Never even touched the firewall. Firewalls are good, because they add an extra layer on security. Personally I believe, there should be firewall on most servers (firewall should be the default). But firewalls aren't magic and they are just one layer. > I have a PW on my DB and that's it. Why do I need more than that? Because this means you have 0 margins for error. Either you PW auth works flawlessly and without bugs, or you are screwed. Also you expose one more endpoint that can potentially be a ddos target.
- LunaSea 5y ago
  You need to: - put the database in a virtual private cloud (VPC), an internal network - setup a Virtual Private Network (VPN) also placed in the same VPC from which developers can connect to to access the internal network - setup at least two MongoDB users, one `readWrite` user that can connect from the internal network and one administrative user that can only connect from localhost - setup a key based SSH connection only accessible from the VPN to the MongoDB instance - setup Security Groups (firewall) to lock all the unused ports and IP origins out That way you'll need a VPN key, an SSH key and the MongoDB admin user's access to fully compromise the database.
- pritambaral 5y ago
  > 1. I need to be able to connect to my DB from anywhere. So do I. So I setup all my dbs with TLS mutual auth or equivalent. Even databases that don't support TLS natively (e.g., Redis 5 and below) get a TLS/SSH port-forward setup for them at the network boundary. > I have a PW on my DB and that's it. Why do I need more than that? If you're not using an MITM-proof connection (e.g., TLS or SSH), and you connect to your DB from a network that has me (maybe we're in the same coffee shop, maybe I'm working in your office, or maybe I just work at an ISP between you and your server), then I have your PW.
- vultour 5y ago
  Why would you need to be able to connect to your database from anywhere?

deleted 5y ago

[deleted]

Kiro 5y ago

As someone who has been running multiple services with millions of users for decades: 1. I need to be able to connect to my DB from anywhere. 2. No idea what that even means. 3. Don't know. Never even touched the firewall. I have a PW on my DB and that's it. Why do I need more than that?

unionpivo 5y ago
> 1. I need to be able to connect to my DB from anywhere. Understandable and reasonable. there are ways to achieve this without exposing the DB but it take some more effort. > 3. Don't know. Never even touched the firewall. Firewalls are good, because they add an extra layer on security. Personally I believe, there should be firewall on most servers (firewall should be the default). But firewalls aren't magic and they are just one layer. > I have a PW on my DB and that's it. Why do I need more than that? Because this means you have 0 margins for error. Either you PW auth works flawlessly and without bugs, or you are screwed. Also you expose one more endpoint that can potentially be a ddos target.
LunaSea 5y ago
You need to: - put the database in a virtual private cloud (VPC), an internal network - setup a Virtual Private Network (VPN) also placed in the same VPC from which developers can connect to to access the internal network - setup at least two MongoDB users, one `readWrite` user that can connect from the internal network and one administrative user that can only connect from localhost - setup a key based SSH connection only accessible from the VPN to the MongoDB instance - setup Security Groups (firewall) to lock all the unused ports and IP origins out That way you'll need a VPN key, an SSH key and the MongoDB admin user's access to fully compromise the database.
pritambaral 5y ago
> 1. I need to be able to connect to my DB from anywhere. So do I. So I setup all my dbs with TLS mutual auth or equivalent. Even databases that don't support TLS natively (e.g., Redis 5 and below) get a TLS/SSH port-forward setup for them at the network boundary. > I have a PW on my DB and that's it. Why do I need more than that? If you're not using an MITM-proof connection (e.g., TLS or SSH), and you connect to your DB from a network that has me (maybe we're in the same coffee shop, maybe I'm working in your office, or maybe I just work at an ISP between you and your server), then I have your PW.
vultour 5y ago
Why would you need to be able to connect to your database from anywhere?