Beware of hackers

Databases
1

I had a PostgreSQL development database that had a port forwarded to be publicly available. Yeah I know bad idea :(.

Anyway a hacker cracked the password and wiped the databases. Fortunately I had enough of backups to get by, but not without a bit of pain.

What is the best way to securely serve data to a device outside the local network?

2
  1. do not directly expose your db to the internet
  2. if you think you should see rule #1
  3. some middleware that your app can talk to to get data from the DB so your DB is NOT directly on the internet - a service of some kind
  4. make sure your service and app use TLS (I forget what version is the most current)

I’m sure others will chime in with other recommendations

3

I am not a pro but I think the REST API is such middleware which will keep your database out of the network.

4

If your database is just to be used by employees of one company, you could consider giving them access to the local network or just the database by using a VPN and stop port-forwarding at all.

5

I’ll have to check into doing a VPN. That would probably serve the purpose for my usage.

6

If its just a site to site link, your modem might be able to do a lan to lan vpn so its transparent to your machines and always up.

7

@Neil Burkholder — Just make sure to turn your porn stash off before letting anyone connect to your LAN :slight_smile:

8

I figured if didn’t go to any porn sites or down load pirated software I wouldn’t need to worry too much about hackers. In fact the server wasn’t even linked to a domain, so it had to be accessed directly by IP Address. I also have a very stringent internet filter installed (no news articles even!). Obviously this hack had nothing to do with my internet browsing.

9

@Neil Burkholder — You local network has nothing to do with a text address like NeilBurkholder.com or your internet history. A local network automatically gathers your modem and everything connected to it through Ethernet or WiFi.

That means, your computer(s), your phone(s), your tablet(s), your printer(s)… and everything that can connect to your modem.

So, please, be careful when allowing other people to connect to your local network. Obviously I was kidding about porn, but it is a true security concern.

10

Didn’t you change the port, limit connectors by IP range and use long passwords you can’t get with trying a lot of them? And admin may be renamed to some other name…

There are a lot of ways to make it difficult.

Not to forget that obesity can help to make data useless to thief.

11

Port scans
Once they find a port that appears to be open they can quickly identify what is listening on that port and you’re hosed

12

I’m not sure changing the port helps. It might enable you to hide from scanners who only check the standard port, but I’m sure hackers are using scanners which test the full range. Long passwords are also useless in protecting a PostgreSQL instance on the Internet unless your connection is secure (TLS) since the MD5 hash a client sends can be intercepted and used.

Limiting access to specific IP addresses works well, though you should always ask the question “What happens if a bug or misconfiguration causes the firewall to fail?” So you still want to force TLS, use long passwords, etc.

Note that I’m thinking about admin remote access to the database. For client apps use middleware as Norman said in the first reply.

13

if it was me, I would use something like Hamachi as a easy way to create a virtual network that can control what machines talk to what. Also to add, the last thing I would want from them is a copy of something they stole.

14

ZeroTier works well

15

I guess your password was set to something simple as opposed to something like this : (U-9rYd’5sdY4v#{gT.a

Having the port open is not the issue here but it could be the solution to avoid a repeat, of course setting a password that is not possible to guess would also keep them out.

I’ve had databases listening for years and I know they’re trying every day to get into them but they have not succeeded.

16

The question of leaving a database server listening on the internet has troubled me for some time and a consistent answer I’ve been reading here and there is : Don’t, just put some middleware in between.

But, I can’t help thinking: Why should my -potentially sloppy- middleware I patched together in a hurry be safer than a database server that’s being developed and massively deployed for years, perhaps decades?

1 Like
17

Because you only allow stuff needed, via your middleware and nothing like dropping tables and alike.
Even if they gain access to your data via your middleware, they can only pull „known“ data. And it‘s harder to manipulate your data. If it‘s done right :wink:

18

Because with middleware you are restricting the surface of what an end user can do. For instance, you wouldnÂ’t have any api method which would call

DELETE * FROM tablename

Your middleware would also have different levels of access. Perhaps a read-only level and a read-write level (or whatever groups you need in between), but none of it should be accessible without a valid username and password, and then a limited time token should be issued so a user has to re-authenticate after a certain period of time.

[quote=439499:@Neil McAliece]I guess your password was set to something simple as opposed to something like this : (U-9rYd’5sdY4v#{gT.a

Having the port open is not the issue here but it could be the solution to avoid a repeat, of course setting a password that is not possible to guess would also keep them out.[/quote]
Having a good password isnÂ’t always enough. There have been plenty of database hacks in the past which have been exploited by the database engine being directly exposed to the open internet. Your best bet really is to use an SSH tunnel, a VPN or one of the private networking services (like ZeroTier) if you think you need direct database access.

Consider yourself lucky. Having encountered server hacks several times over the course of my career, thatÂ’s usually what I hear people say just after theyÂ’ve been hacked.

Just some thoughts from a guy that’s been in this rodeo for at least 30 years…

  1. DonÂ’t be low hanging fruit. Make sure your servers are updated on a regular schedule and that you have multiple levels of security. ItÂ’s not uncommon for servers to get set up and never updated because you run the risk of breaking something. With as easy as it is to clone a server these days, make a copy, update it, verify itÂ’s working and then move your domain(s).
  2. DonÂ’t use default server settings. I canÂ’t tell you how many servers IÂ’ve seen that have a firewall, but itÂ’s not set up. Or the root user is directly accessible. Or SELinux has not been enabled. If you know how to manage a server, take the time to do it. If not, hire a service to do it for you.
  3. Make and keep regular backups. While this is more about recovery… Most VPS hosting companies will keep 7 days of snapshots for you at a minimal cost. Turn that feature on and periodically restore one to make sure they are viable.

Lastly, if you do get hacked, donÂ’t trust anything on the compromised machine(s). You should assume that data has been modified, that binaries have been replaced and that the OS itself is working against you. Never copy anything from the compromised servers to your new server. Everything you use going forward should come from a backup that was made before the server was compromised.

19

It would be nice to make some statistics, e.g have Firewall log how often each port is trying to connect on.
So you see if they really scan all 65535 possible port numbers.

Then for database, maybe log all login attempts to see what passwords they try.
Could be fun to just make a fake Postgres server to log requests.

And of course we recommend to use different permissions on the server, so DELETE * is disabled.

20

This seems to be a nice analysis:
https://cseweb.ucsd.edu/~clbailey/PortScans.pdf