Ask HN: How databases are compromised? I just saw this: https://news.ycombinator.com/item?id=9277370 about SlackHQ's database being compromised. I want to understand what are the different ways a hacker might get access to the database. As a general practice, you should put firewall in front of db to allow access only via your web servers. So what are the different ways to get access? |
Google "firewalking" for more sophisticated attacks against firewalls, but usually a firewall can be breached via malware, phishing, specially crafted web apps, XSS, etc. In general firewalls should be considered weak and only a first line of defense. Far, far too much emphasis is placed on them at the expense of host and app level security -- the "soft underbelly problem."
My personal and admittedly slightly fringe opinion is that you should harden your apps, servers, and endpoint devices first and your network last. Assume there is no firewall at all. Would your box be secure if it were just naked on the Internet? If not, it's not secure.
Here's what I'd recommend:
- Databases should always use local DB-level authentication. It's become trendy of late to dispense with this. Some newer DBs I've seen don't even support it, which is really stupid.
- Keep DB passwords out of world-readable files, command lines visible to 'ps', and code repos!
- The database should only bind to the backplane network device, not to 0.0.0.0 or ::0. Or if it's for local use only, use unix domain sockets or bind to 127.0.0.1 or ::1.
- There are some interesting local iptables rules you can use to control e.g. which users on a system are allowed to open sockets. These can be valuable for loopback/localhost database access control as another layer of security.
- Consider using VMs and/or containerization to separate concerns, though this is not a panacea. Sometimes multiplying complexity and system count this way actually makes it harder to defend your overall system, and of course you're f'd if someone pwns the physical host. A bunch of isolated virtual machines can also mean a lot of nooks and crannies where an attacker can set up shop inside your network and hide out. I've heard un-policed systems/VMs like this termed "crack houses."
- Be very careful with backups. Sometimes people can compromise backups instead of compromising your actual systems. Encryption is a good idea.
- The meat sack between the chair and the keyboard is usually one of the weakest links in system security. Beware of phishing attacks, social engineering, and copy/pasting untrusted code off the net. The latter has become a popular attack of late, especially given what can be done with unicode and other weird tricks to hide stuff in innocent looking text. There's also been cases where underhanded backdoors have been smuggled into organizations via cooperative coding vectors like StackOverflow. Others include just 'docker pull'ing any old Docker project off Docker Hub without regard of what goodies may be hiding inside.
All security can be breached. The only 100% secure system is one that is off.
In this case you are trusting Amazon to implement good host and network security. The weak point here is the credentials you use to access the database. Guard those with your life.