20.2 Securing Your System

In this section you will learn some basic facts about security and you will be guided through the most important principles.

20.2.1 Server Security

When talking about security, it is time to have a closer look at operating systems. What is an operating system? Well, the core of an operating system is a kernel, which is surrounded by various tools and components. The first thing you have to keep in mind is that every piece of software that has been installed on your system is a potential danger. The more packages you have installed on your machine, the more likely it is that one of these packages contains a security leak that can be used by a remote cracker to hack your system.

The network interfaces especially are security-critical. The more ports your system is listening to, the more insecure it will be. To find out which ports your system listens to, you can use a tool such as nmap. nmap is a software package for performing port scans and finding out information about a remote host. It is a perfect tool for having a look at what is up and running on your machine. Let's scan the local machine:

 [root@duron root]# nmap localhost Starting nmap V. 2.54BETA30 ( www.insecure.org/nmap/ ) Interesting ports on duron (127.0.0.1): (The 1539 ports scanned but not shown below are in state: closed) Port       State       Service 22/tcp     open        ssh 25/tcp     open        smtp 80/tcp     open        http 111/tcp    open        sunrpc 139/tcp    open        netbios-ssn 443/tcp    open        https 515/tcp    open        printer 3128/tcp   open        squid-http 5432/tcp   open        postgres 6000/tcp   open        X11 Nmap run completed -- 1 IP address (1 host up) scanned in 1 second 

As you can see, many ports are open. Fortunately, the local machine is behind a firewall, so this is not a problem. With the help of nmap you can scan every host on the Internet. In this way an offender can gain information about the target and work on a strategy to hack the remote machine.

Let's take a look at a secure BSD workstation on the Net:

 [root@duron root]# nmap bsd Starting nmap V. 2.54BETA30 ( www.insecure.org/nmap/ ) Interesting ports on bsd (62.116.21.150): (The 1548 ports scanned but not shown below are in state: closed) Port       State       Service 22/tcp     open        ssh Nmap run completed -- 1 IP address (1 host up) scanned in 9 seconds 

Only one port is open, which is used for working with SSH. This is the far better configuration of the two because it is the more restrictive one.

Again, the less software you have installed on your system and the more restrictive your configuration is, the more secure your server will be. In addition, you should think about using firewalls. Today many powerful tools for firewalling are available. Think of all those software routers that are packed on just one floppy disk these tools can help you to build more secure and more reliable IT environments.

However, having a restrictive configuration is not always enough to guarantee the security of your network. After a system has been installed, it takes permanent maintenance in order to keep the system secure. Make sure that you update your system if security problems are found. It is no use running a highly restrictive system if some key components such as the Web server, Bind, or SSH have severe security leaks that haven't been discovered yet when setting up your machines. If you run a business-critical application, go through the newsgroups and Web sites related to security regularly and make sure that there are no problems with the software running on your system.

All the things I have been talking about in this section seem pretty obvious. However, most people start building secure systems and forget about security when the system is up and running. This is dangerous and security demands increase permanently. Crackers don't sleep, so there is no reason for you to sleep either.

20.2.2 Security on an Application Level

After you have secured your server, you must not forget about security on an application level. It is not enough if you take care of your server but forget about your applications.

There are some dangers you have to take care of when running PHP applications. The following scenario is not a bug in PHP, but it shows what can happen if you implement a PHP application the wrong way. You will see that this can lead to real security problems.

Let's start with a PHP program called start.php:

 <?php         include ($includedir."inc.php");         echo "hello $x<br>\n"; ?> 

The script does nothing except include a library and display the content of $x. If $includedir is not defined, the file called inc.php located in the local directory is returned. This is a flexible implementation because it is possible to change the location of your files easily. Let's take a look at inc.php:

 <?php         $x = "Charles ...<br>\n"; ?> 

Execute the script using the following URL:

http://localhost/start.php

One line is displayed. It contains the variable in inc.php:

 hello Charles ... 

Up to now, nothing seems dangerous. However, with just four lines you have implemented a security hole. What happens if the URL is called like this:

http://localhost/start.php?includedir=incdir/

$includedir is defined by the URL, so the file in incdir is called instead of inc.php, which can be found in the local directory.

Take a look at inc.php in incdir:

 <?php         $x = "from a hacker ...<br>\n"; ?> 

If you execute the script, you will get a result like this:

 hello from a hacker ... 

As you can see, the person using the program can modify the libraries that are included by your application. In this scenario nothing bad has happened, but what happens if libraries are included and the cracker passes the name of a library located on his machine to the script? This is extremely dangerous because now the cracker is allowed to do everything the Web server is allowed to do. He could read your source code containing all passwords; he could delete all data from the Web server if the user rights are not set properly; or he could modify the data on your Web server by loading data from his Web server on your machine. If the cracker finds out which libraries your application includes, it would be an easy task to do something very nasty to your system.

There are many potential security threats like the one you just saw, and it is necessary to think about these when building an application. Make yourself think like a hacker and try to find potential threats like the one you just saw. Never pass the name of a library to the next script via a URL. PHP is capable of retrieving libraries from a remote host, so it is an easy task to change the library your system includes. Make sure that the user rights on your system are set correctly. This means that you need not allow the Web server to write in a directory where it need not write.

This is important because all rights the Web server has are a potential security problem.

20.2.3 Database Security

After you have dealt with the server, you can start looking at PostgreSQL. PostgreSQL is a secure system and there are not so many things you have to take care of.

One important thing is that you should not turn on TCP/IP unless you really need it. If TCP/IP is turned off, PostgreSQL will work via Unix sockets. If the Web server and the database server are on the same machine, you won't need TCP/IP because everything can be done with the help of Unix sockets.

In addition, you should try to configure a restrictive database configuration. Keep in mind that if a cracker gets one of the passwords, he should not be able to delete the entire database.

When working across insecure networks, we recommend using an encrypted protocol. PostgreSQL supports SSL connections. This means that data is transmitted via a secure channel and not as plain text. The benefit is that the user need not worry that a sniffer listens to what is being transmitted to you across the network. However, using SSL will lead to a significantly slower authentication process. To get around the problem, it can be useful to establish a permanent secure tunnel so that a lot of authentication overhead can be avoided. For performance-critical systems, this is an essential advantage because if authentication takes much longer than processing the data, it can be slightly annoying.

If you have configured your database properly, PostgreSQL is a secure piece of software. Just take care of your network configuration as well as your user rights, and everything will be just fine. In addition, we recommend using firewalls. The more you protect your server, the more secure it will be and the more unlikely it is to be hacked.