protection against mysql burglary

M

Muczamajana

Hello, I am a new user of the bsd system. Does anyone know how to limit the burglary to mysql? some iptables / guides are?
I do not know how to do it ;/ preferably in the form of a guide or directing me

thank you in advance for your help
 
Remington said:
Use different port other than 3306. Most attacks target well known ports.
Click to expand...

Security through obscurity doesn't work. Hacking servers is a numbers game, they can and do have time and enough already compromised systems to literally scan every possible port, and scan every ip address combination.

I'm running several services with non-standard ports and they all get probed multiple times a day. Move the service to a different port and within < 24 hrs it is getting probed again.

If you want it secure and don't want it scanned, probed or hacked, don't expose it to the internet in the first place.
 
anlashok said:
Security through obscurity doesn't work.
Click to expand...
It doesn't hurt, and it works reasonably well. For example, just moving ssh and http ports to non-standard numbers reduces the number of attacks by many orders of magnitude. Obviously, you are correct in saying that it is not at all perfect, and if you want a really secure system, you have to close that gap too. But moving to non-standard ports reduces the attack load by enough that compromises between security and convenience become easier. And if you make a mistake in being really secure, just reducing the probability that your hole gets exploited does reduce the chance of a successful exploit.
 
anlashok said:
Security through obscurity doesn't work. Hacking servers is a numbers game, they can and do have time and enough already compromised systems to literally scan every possible port, and scan every ip address combination.
Click to expand...

It does greatly reduce the number of attacks but not completely. Many attacks are run by scripts or bots. Hackers won't waste their time on small mom-and-pop websites with very little traffic. If you're talking about websites like Citibank, Dropbox, Google, etc. then changing to non-standard ports won't help. There are plenty of professional hackers trying to break into corporate websites.
 
For 99% of the LAMP/FAMP setups, binding MySQL/MariaDB to 127.0.0.1 will be sufficient to protect against outside attacks. If the "bad guys" can't connect to it they can't break into it. If you need to do remote management, as shkhln already hinted at, use port forwarding. Something like ssh -L3306:127.0.0.1:3306 me@myserver.example.com usually works for me.

You might need to bind MySQL/MariaDB to some external IP if you need to use replication for example. If possible use an internal interface for that. If you only have one, internet facing, interface then you must protect it with some firewall rules.
 
Are you trying to connect to your mysql server internally or externally? If internally then bind 127.0.0.1 is best option. If externally, you will need to configure your firewall to limit certain external IP addresses to be permitted to connect to your mysql server or use SSH port forwarding. I use pfSense to limit two external IP addresses to my mysql server.
 
Very interresting question.
But this has taken us far afield from interface, which is not a bad
place to be, since I particularly want to move ahead to the kludge.
Why do people have so much trouble understanding the kludge? What
is a kludge, after all, but not enough K's, not enough ROM's, not
enough RAM's, poor quality interface and too few bytes to go around?
Have I explained yet about the bytes?
 
I'm going to say "you can't" unless you have no wires connected to your computer (network) and no built-in wifi on the motherboard (SoC abilities).

But really? Rethink your DB. Why do you want a DB that is "un-hackable" that is accessible? That's your problem.

Perhaps you should use a professional db system (where you are not liable) if you "really need it".

MY ADVICE OTHERWISE IS MYSQL is "linux style software". It has changed standards (causing massive loss of time) for users, over the years. Standards that changed included security standards (where past setups become insecure after upgrade). You'd rather run a DB that doesn't hack the premise of your setup (which is that once you set it up it STAYS set up to do what you set up, that your DB scripts don't start throwing errors after upgrade). And which doesn't force you to upgrade to get updated to an incompatible version when you upgrade your OS - the double-gotcha.

Is there such a DB? Well - Ingress (postgres) is somewhat stable as far as standards go (though minor changes were made).

But Oracle I think has some "major solutions" you'd be interested in: and well documented "migration" operations for those upgrading from last version that "need to fix things to work in the new version" (and even support if you pay for it).

SO. You'd be on a Virtual Private Network with anyone having access to DB or have no connectivity at all. One way to insure no connectivity is: you have the source code. Rip it out so that all packets in our out go into the bit bucket then even mysql can't by mistake send an IP packet - assuming mysql doesn't require talking to localhost while operating (which btw is not a secure thing to do, and it might require that).

So really? If semi-secure isn't good enough then don't make mysql your problem. use a professional db (which i am not an authority on as far as which is bets), and follow it's guides and let that be their problem not yours. why is because once you have IP involved it's SUPER complicated to be "right".

My my we haven't even talked file security for a multi-user multi-thread pc (running many apps as root, then also having a desktop running many apps as some user): that's also a problem and mysql doesn't necessarily have "workable" solutions for that either. Jails are not 100% (per say).

As far as "you can tell mysql" to use sockets only? No. "in unix everything is a file", all networking is a socket of some kind already. what kind of socket? netstat -a shows many open sockets. sockets can be connected or piggy-backed, etc, etc.

You should want people to have access to a DB, if it's a system DB then only system uses it (assume that's safe), and if you actually need to give hackers access to DB software then that's a real problem.

ONE METHOD IS THAT YOU NEVER ALLOW ACCESS TO THE DB. what you do is have a (C program) that filters requests and deletes any request that is not "sure to be secure".

Another method is to use a "file database" (one that is NOT network aware, like BerkelyDB (some people are gasping at that advice!)). But you know - files can be piggy backed to sockets and file security. I mean - there is NO WAY you can be sure.

Finally: your hardware (in silicon) may have back doors. You have no idea what's no that silicon - all those chips and boards. So you're really done before you started. You can try. You can keep out micro-agression attacks. But you can only go so far.

Now, if your a bank you might run some "certified DB" by people who are certified. And if it fails you find the perp if there is a perp in your organization who's "certification needs to be pulled". But you eat the losses. And you have systems to prevent "loss" that go beyond a single DB - and yet that's not good enough either, there are losses.
 
knowing of potential losses (hopefully fully isolated accounts), which you'll have to pay for, you should also have a recovery strategy of finding out who and getting it back
 
You must log in or register to reply here.
Back
Top