Linux Server Security (2nd Edition( [Electronic resources] نسخه متنی

8.2. Server Location

Where should you place a database server? The main factors
are:

Who will access the database?

How important is the data?

Exposing a database directly to the public might earn you a call from
the Society for the Prevention of Cruelty to Databases. A
public database
server is normally an internal server,
accessed only by other servers and clients behind the firewall. In
this chapter, we'll look at examples of the most
common database users: web servers and
database administrators. We'll
also show how to insert multiple layers of protection between the
sensitive database server and the harsh weather of the public
Internet.

The MySQL server listens for connections on
a socketa Unix socket for connections on the same machine or a
TCP socket for other machines. Its IANA-registered TCP port number is
3306, and I'll use this value in examples, but other
port numbers can be used if needed.

How far from the Internet should the database be placed? Truly
precious data (such as financial records) should be far back, on a
dedicated database server within a second DMZ (internal to the DMZ
that contains public-facing things such as web servers). The
intervening firewall should pass traffic only between the database
client (e.g., the web server) and database server on a specific TCP
port. iptables should be configured on each machine so that the
database client talks to that database port (3306) on the database
server and the database server accepts a connection to port 3306 only
from the host containing the web server.

For less precious data, the MySQL server may be on a dedicated
machine in the outer DMZ, side by side with its clients. This is a
common configuration for security, performance, and economic reasons.
Configure iptables on the database server to accept connections on
port 3306 only from the web server, and configure iptables on the web
server to allow access to the database server on port 3306.

For local client access, MySQL can use a local Unix domain socket,
avoiding TCP exploits. If a client accesses the host as
localhost, MySQL automatically uses a Unix
domain socket. By default, this socket is the special file
/tmp/mysql.sock.

8.2.1. Secure Remote Administration

Although we worry most about the security
of the connection between the database server and its major clients,
we also need to pay attention to the back door: administrative use.

Database administration includes creating and modifying databases and
tables, changing permissions, loading and dumping data, creating
reports, and monitoring performance. The main methods for
administrative access are:

VPN to the server ssh to the server Tunneling a local port to the server Using the Web

8.2.1.1 VPN to the server

If you have a VPN (virtual private
network) connecting your local machine and the database server, you
can access the server as though you were in the DMZ. Open source VPNs
include FreeS/WAN
(http://www.freeswan.org),
Openswan
(http://www.openswan.org/),
OpenVPN (http://openvpn.sourceforge.net/), and
strongSwan (http://www.strongswan.org/). All are under
active development except FreeS/WAN.

Cisco and many other vendors sell commercial VPN products.

8.2.1.2 ssh to the server

If you don't have a VPN, you can do what I do:
ssh to the database server and run
command-line clients such as mysql,
mysqladmin, and mytop. The
command line may give you more control (if you're
used to text-filled terminal windows), but it can also be more
tedious and error-prone. Still, it's a quick way to
get in, fix a problem, and get out.

8.2.1.3 Tunneling a local port to the server

If you'd like to use GUI tools like MySQL Control Center,
Administrator, or Query Browser on your local machine, you can tunnel
your MySQL port through the intervening firewalls with
ssh (see Chapter 4) or
stunnel (see Chapter 5).
If your server is db.hackenbush.com and your
Unix account name is wally, enter:

ssh -fNg -L 3306:127.0.0.1:3306 wally@db.hackenbush.com If you haven't generated a public key on your
machine and copied it to the database server (see Chapter 5), you'll be prompted for
your ssh passphrase. This command tunnels port
3306 on your machine over ssh to port 3306 on
the database server.

Test it with a client on your own machine. Try this:

mysql -h 127.0.0.1 -u wally -p

Use 127.0.0.1 instead of localhost. MySQL uses a Unix-domain socket for the latter and will not accept TCP connections.

Type your MySQL password when prompted. If this works, all of your
local clients will be able to access the database.

If it doesn't work, look at the MySQL error
messages. You may not have a MySQL account for
wally or the proper permissions for him to
access the database. I'll provide the details later
in this chapter, but the MySQL command to create a user looks like
this:

grant all on *.* to wally@localhost identified by 'password' If you are running MySQL on your local machine and already using TCP
port 3306, use a different port for the first value and specify that
port in your client calls later. Let's use port
3307:

ssh -fNg -L 3307:127.0.0.1:3306 wally@db.hackenbush.com
mysql -P 3307 -h 127.0.0.1 -u wally -p Using ssh to tunnel your MySQL traffic makes you
dependent on the security of the SSH server on the database machine.
A safer approach, which I recommend in Chapter 4 (see Sidebar 4-2), is to use a VPN to connect
to another machine in the DMZ (an access point),
then ssh or stunnel to the
database server. This two-step approach is a little safer than a
direct VPN or ssh connection between your local
machine and the database server.

Chapter 5 shows how to tunnel with
stunnel rather than ssh.
Both work well.

8.2.1.4 Using the Web

There are many
web-based MySQL administrative
interfaces, but my favorite is
phpMyAdmin
(http://www.phpmyadmin.net). You
should use HTTP over SSL (URLs start with
https:) to protect your connection. Even so, as
Chapter 10 shows, the Web is a tough environment
to secure. I never feel quite safe using web-based admin tools and
tend to fall back on ssh or tunneling. You might
compromise by using web tools during the design phase with a test
database and move to other administrative tools for
deployment.