# protection against mysql burglary



## Muczamajana (Jul 26, 2019)

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


----------



## SirDice (Jul 26, 2019)

Yes, don't configure it to listen on an internet address. In other words, don't make it accessible from the internet. 



Muczamajana said:


> some iptables


IPTables is a Linux firewall.


----------



## Muczamajana (Jul 26, 2019)

I know iptables but I can not see this program on freebsd


----------



## SirDice (Jul 26, 2019)

You won't find it because it's a Linux firewall. FreeBSD is not a Linux. 

Handbook: Chapter 30. Firewalls


----------



## Muczamajana (Jul 26, 2019)

I know about it but there is no alternative? Mainly wants to secure port 3306


----------



## SirDice (Jul 26, 2019)

Muczamajana said:


> I know about it but there is no alternative?


What alternative are you talking about? I already linked you to the handbook section covering firewalls.


----------



## SirDice (Jul 26, 2019)

Bind MySQL to 127.0.0.1: https://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html#sysvar_bind_address

Which is actually the default: https://svnweb.freebsd.org/ports/he.../my.cnf.sample.in?revision=431919&view=markup


----------



## Remington (Jul 26, 2019)

Muczamajana said:


> I know about it but there is no alternative? Mainly wants to secure port 3306



Use different port other than 3306.  Most attacks target well known ports.


----------



## anlashok (Jul 26, 2019)

Remington said:


> Use different port other than 3306.  Most attacks target well known ports.



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.


----------



## ralphbsz (Jul 26, 2019)

anlashok said:


> Security through obscurity doesn't work.


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.


----------



## Remington (Jul 27, 2019)

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.



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.


----------



## shkhln (Jul 27, 2019)

This is your daily reminder that SSH port forwarding _exists_.


----------



## SirDice (Jul 27, 2019)

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.


----------



## Remington (Jul 27, 2019)

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.


----------



## CoTones (Jul 28, 2019)

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?


----------



## Datapanic (Jul 28, 2019)

If the mysql server can be local, then use sockets instead.


----------



## debguy (Jul 29, 2019)

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.


----------



## debguy (Jul 29, 2019)

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


----------



## SirDice (Jul 29, 2019)

debguy You have absolutely no idea what you're talking about, do you?


----------



## Muczamajana (Sep 4, 2019)

And would anyone know how to get this effect using ipfw rules? I think these rules have helped me achieve the required effect

I want to cut all addresses and unblock only one address for port 3306

SirDice debguy Datapanic


----------

