Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Kinda.....The only way that comes to mind is to use the built in user authorization system to do it. What you'd do is set up a user account for remote connections and limit all other users to localhost. You can specify any user's host in the "host" field of the "user" table in the "mysql" database. You can use a hardcoded single IP or you can also use wildcards such as % to allow connections from certain domains, IP subnets, and etc.
Yeah, personally, I think it best not too allow remote connections to mysql at all. Instead I usually op for building tools via PHP and/or Perl that can do whatever needs doing locally through a webserver and etc. Then everything that interacts with mysql is server side and you don't have to worry as much about stuff like that. Course you still can't control everything.. Anyway, you stop mysql from listening on anything except localhost by enabling a directive in the my.cnf. Here's the directive as stated in my.cnf:
# Don't listen on a TCP/IP port at all. This can be a security enhancement,
# if all processes that need to connect to mysqld run on the same host.
# All interaction with mysqld must be made via Unix sockets or named pipes.
# Note that using this option without enabling named pipes on Windows
# (via the "enable-named-pipe" option) will render mysqld useless!
Hmm, never really messed with it much on Windows, so I'm not certain what the difference in the exe's are. Might check the lengthy mysql doc for that. Best I remember the small, medium, huge stuff has to do with the settings of the config file only, depending on how big your database is, but don't quote me on that..
mysqld Compiled with full debugging and automatic memory allocation checking, symbolic links, InnoDB, and BDB tables.
mysqld-opt Optimised binary with no support for transactional tables in version 3.23. For version 4.0, InnoDB is enabled.
mysqld-nt Optimised binary for NT/2000/XP with support for named pipes.
mysqld-max Optimised binary with support for symbolic links, InnoDB and BDB tables.
mysqld-max-nt Like mysqld-max, but compiled with support for named pipes.
So it's just a difference of options compiled into the binary. And yeah, the difference in the config files is just a difference in options there as well for different needs based on your needs.
Currently there are sample configuration files for small, medium, large, and very large systems. You can copy `my-xxxx.cnf' to your home directory (rename the copy to `.my.cnf') to experiment with this.
Distribution: OpenBSD 4.6, OS X 10.6.2, CentOS 4 & 5
Originally posted by sopiaz57 yea, mainly im concerned about script kiddes and the different worms out there exploiting mysql. Slammer is the big one that comes to mind.
Regardless of how you set up users, i think as long as the daemon is listening on 3306, it would be attacked.
Incorrect, SQL Slammer only affected MS SQL Server, any other SQL compliant databases were not affected (Oracle, MySQL, mSQL, PostgreSQL, etc).
A good example of a remote MySQL vulnerability (although it was a configuration error, not really a vulnerability in MySQL itself) can be found here. That one could easily be scripted into a worm, but I doubt there are enough hosts with that vulnerability to make it worthwhile.
guess a firewall is the next step in the process.
A firewall in front of a database highly recommended. However, the presence of a firewall should not discourage you from hardening the database itself (for instance, setting it to not listen on TCP ports).