LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Software (https://www.linuxquestions.org/questions/linux-software-2/)
-   -   MySql-ban brute force attacks? (https://www.linuxquestions.org/questions/linux-software-2/mysql-ban-brute-force-attacks-746246/)

qwertyjjj 08-09-2009 01:38 PM

MySql-ban brute force attacks?
 
Is there a way in mySQL to ban brute force attacks?
My 3306 port is open as I need to connect to it this way to run backups and store these backups on a separate machine.

unSpawn 08-09-2009 08:37 PM

Quote:

Originally Posted by qwertyjjj (Post 3636807)
My 3306 port is open as I need to connect to it this way to run backups and store these backups on a separate machine.

When you want to "ban brute force attacks" then I'm thinking you run port TCP/3306 accessable from the 'net. If that's the case the MySQL docs clearly state the port should not be accessible from untrusted hosts. I suggest you bind your mysqld to localhost, run Logwatch (and read the emailed reports), run an appropriate iptables ruleset (rate limit, log and block), mod_security, Snort, maybe GreenSQL, and use another way to run your backups. There are plenty of options like tunneling Rsync-over-SSH, SCP, FTPS et cetera.

qwertyjjj 08-10-2009 04:01 AM

Quote:

Originally Posted by unSpawn (Post 3637126)
When you want to "ban brute force attacks" then I'm thinking you run port TCP/3306 accessable from the 'net. If that's the case the MySQL docs clearly state the port should not be accessible from untrusted hosts. I suggest you bind your mysqld to localhost, run Logwatch (and read the emailed reports), run an appropriate iptables ruleset (rate limit, log and block), mod_security, Snort, maybe GreenSQL, and use another way to run your backups. There are plenty of options like tunneling Rsync-over-SSH, SCP, FTPS et cetera.

If 3306 is blocked, is it necessary to run other SQL blocks & logwatch or is that only for webserver SQL injections that it's necessary?

unSpawn 08-10-2009 06:28 AM

In short: yes, do run tools that help protect your machine.

Slightly longer: setting up your host and configuring it to run your web site, web log, content management system, server management or reseller panel or forum is an investment. It is good practice to protect investments. You do this by hardening a host before allowing access to it. Hardening a host means preparing it for (public) network access (like setting good passwords, not allowing root SSH access, removing test databases, test accounts, shells from user accounts that do not need them), configuring services to take away possible avenues of entry (for example public access to MySQL or the hosts MTA or shares), restricting access (for example unauthenticated access to /phpadmin/ or writable FTP directories) and making it more resilient to attacks (good firewall rules, intrusion detection, logging). Especially logging (and watching those logs) is important because a lot of telltale signs you can find in advance (recon noise). All of this goes especially for running any PHP-based apps because since PHP was invented the 'net is rife with accounts of breaches of security and advisories. PHP stands for Pretty Horrific Programming and as such it requires your care and attention.

If you have any questions about host and network security, hardening or security incidents you're invited to read the documentation and security information that comes with the products you run, read the sticky threads in the Linux Security forum, search the Linux Security forum for accounts of security incidents and the lessons you can learn from them.

Of course you can chose to say that security is a nuisance and that hardening is too much work but I remind you that once you put a host on the 'net you are responsable for what happens to and with it. Fallout from incidents will not affect you alone but all of us.


All times are GMT -5. The time now is 04:28 PM.