Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
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.
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:
Quote:
# 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!
#
skip-networking
Hey thats awesome, exactly what i needed. I agree, I like having php/perl do the work with the database locally (Server side) and dont do anything remotly on 3306.
A few questoins:
1. What are the my-large, my-huge, my-medium and my-small icons in the root folder.
2. whats the difference between the following servers:
Directory of C:\mysql\bin
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.
Quote:
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.
I've written a tutorial setting up mysql incl. chroot (and details how to chroot it). This tutorial has been published at my website. You can go directly tutorial.
So if you require more information and a additional layer of security (chroot), you can take a look there. Most MySQL installations by distributions are by default not chrooted.
Distribution: OpenBSD 4.6, OS X 10.6.2, CentOS 4 & 5
Posts: 3,660
Rep:
Quote:
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.
Quote:
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).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.