Apache, PHP, MySQL with basic security settings.
Not sure weather it's any good, but it is a result of one of my courseworks.
This tutorial is aimed at a newbe with a little knowlege.
Any additions and coments are wellcome, as I still consider myself a newbe in this are, mistakes are very much possible:
Foreword
The World Wide Web was started around 1989. It was based on a number of university and military networks and was mostly aimed at the professionals and scientists to exchange information. The back bone of WWW was and still is an American military network Internet. Ever since then, the use of WWW increased exponentially.
As more and more people are using WWW, the questions of security become more apparent. In our days WWW, or as people still refer to it, Internet, is used in many areas of everyday life. We use it to get information we need, to communicate with other people, to buy things online etc. There is a huge amount of personal data being passed through the internet every second. Yet, this data can still be very vulnerable.
As most of the internet users don’t know much about security, it is up to server administrators and web designers to make sure that the customer’s data is safe.
As people use Internet, in technical terms, there only two identities, client and server:
1. Client – a user’s computer, which accesses information.
2. Server – a computer which provides information and services.
Despite there being only two identities, there is a number of other computer devises between them. These devises work as relays for the information. They can also be used to intercept communication between computers.
As more and more people start to use internet for financial transactions, the chances of being “overheard” worry them ever more. This is why when setting up a web server, one has to consider all the possibilities.
There are a number of issues when using the web:
1) Crackers – there is a number of Internet users, who have the technical knowledge and desire to break in to a system for their own reasons, many of which are malicious.
2) Viruses - A program or piece of code that is loaded onto your computer without your knowledge and runs against your wishes. Viruses can also replicate themselves. All computer viruses are manmade. A simple virus that can make a copy of itself over and over again is relatively easy to produce. Even such a simple virus is dangerous because it will quickly use all available memory and bring the system to a halt. An even more dangerous type of virus is one capable of transmitting itself across networks and bypassing security systems. (Webopedia.com)
3) Trojans - A destructive program that masquerades as a benign application. Unlike viruses, Trojan horses do not replicate themselves but they can be just as destructive. One of the most insidious types of Trojan horse is a program that claims to rid your computer of viruses but instead introduces viruses onto your computer. (Webopedia.com)
4) Spyware - Any software that covertly gathers user information through the user's Internet connection without his or her knowledge, usually for advertising purposes. Spyware applications are typically bundled as a hidden component of freeware or shareware programs that can be downloaded from the Internet; however, it should be noted that the majority of shareware and freeware applications do not come with spyware. Once installed, the spyware monitors user activity on the Internet and transmits that information in the background to someone else. Spyware can also gather information about e-mail addresses and even passwords and credit card numbers. (Webopedia.com)
These are only few that can cause trouble to the Internet user. As it stands these are the most relevant to this work.
In my experience most of the crackers will be aiming just to prove themselves, yet there is a number of them who will be using their skills for personal gain. Most of them are highly skilled and knowledgeable. In my knowledge many of them will target servers rather then separate users.
Servers are often used to redistribute malicious software produced or used by the crackers.
One of the more common attacks is intercepting the data transitions between a client and a server. There is a number of ways to combat this.
SSL:
Secure Sockets Layer, a protocol developed by Netscape for transmitting private documents via the Internet. SSL works by using a private key to encrypt data that's transferred over the SSL connection. Both Netscape Navigator and Internet Explorer support SSL, and many Web sites use the protocol to obtain confidential user information, such as credit card numbers. By convention, URLs that require an SSL connection start with https: instead of http:
(Webopedia.com)
Secure HTTP or S-HTTP:
An extension to the HTTP protocol to support sending data securely over the World Wide Web. Not all Web browsers and servers support S-HTTP. Another technology for transmitting secure communications over the World Wide Web -- Secure Sockets Layer (SSL) -- is more prevalent. However, SSL and S-HTTP have very different designs and goals so it is possible to use the two protocols together. Whereas SSL is designed to establish a secure connection between two computers, S-HTTP is designed to send individual messages securely. Both protocols have been submitted to the Internet Engineering Task Force (IETF) for approval as a standard.
S-HTTP was developed by Enterprise Integration Technologies (EIT), which was acquired by Verifone, Inc. in 1995.
(Webopedia.com)
Some more information on SSL can be found here:
http://httpd.apache.org/docs-2.0/ssl/
As these technologies complement each other, they both take care of the basic security of the transfers. Unfortunately, that doesn’t mean that the user will be secure. As the servers becomes compromised, not only the cracker gets all the information stored on the server, this also allows the cracker to use the server for further attacks.
As a possible uses for the server, we could remember use of the images to redistribute small scripts. Once the server is compromised, the cracker has an opportunity to change original images and to insert modified ones.
As the question of the secure communication is taken care about, we have to work out how to secure our server? Which technologies to use? And other questions.
When thinking about setting up and securing the web server the first thing one has to consider is the technologies to use. At the moment the most popular technologies are open source technologies:
Apache web server
PHP for server side scripting
MySQL server for web based databases .
Further, I’ll use these technologies to explore and try to setup a secure server.
When setting up a server, same as any system we have to consider the risks.
Why would anyone try and break in to the server?
There are a number of reasons for an attack one could consider:
1) Could the attacker use the server for the further attacks?
2) Does the server have a high amount of visitors, to place spy wear on it?
3) Does the server contain any passwords or other personal info?
4) Will there be any financial transactions made through the server?
These are the four main questions one should ask when setting up a server. As well as these, there is a question of so called “Script Kiddies”, who will attempt to break in to the server machine or deface the site for no reason.
As Internet becomes used more widely, more and more servers are being run from the home PCs. No matter if it’s being done by a school kid or by a granny, these sites are often become a target of the hackers as they are the easiest to break in. As most of the home users run a version of Windows, in my setup I am going to use Windows XP Professional edition.
As the result we are going to have a next setup:
Windows XP
Apache2 Web Server
PHP 5
MySQL 5
Next pages will look at the secure settings for the server.
Apache
When working with Apache, in my opinion, the documentation is lacking the specifics. A great care was put into the creation of the server, yet the program was not documented properly. As I researched the documentation over the internet, I found that it mostly copies the Apache official site.
The documentation given there is very abstract and requires a person to have much wider understanding of the technologies then mine. This means that the 200 hours planed for the project are not enough.
Compared to MySQL and PHP documentation, Apache documentation requires more time to work a way around the system and to find a secure configuration I’d be looking for.
Installing Apache on the system
Apache installer can be downloaded from the official Apache website. The process is generally automatised.
Configuring Apache
To configure Apache Web Server one has to edit “httpd.conf” file which is based in “C:\Program Files\Apache Group\Apache2\conf” directory if the user follows the basic installation process or in the ‘conf’ folder in the directory chosen by the user.
The basic setting for the user are to set up the directory where is the website served from and which server technology the user is going to use. The server technology which I am using is PHP, the installation of which is going to be discussed in more detail in ‘PHP’ section.
To set up the path to the files of the site:
DocumentRoot "D:/Uni/Year 2/Application/Site"
# DocumentRoot: The directory out of which you will serve your
# documents. By default, all requests are taken from this directory, but
# symbolic links and aliases may be used to point to other locations.
Securing Apache
As I noted before, in my opinion, the documentation on Apache is confusing and overly complicated. Personally for me it turned out to be a great problem. When writing here I will try to explain in as plain way as possible.
First thing the user has to do.
Is to take a look at the next feature.
# Each directory to which Apache has access can be configured with respect
# to which services and features are allowed and/or disabled in that
# directory (and its subdirectories).
#
# First, we configure the "default" to be a very restrictive set of
# features.
#
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
I suggest keeping it default and changing only as the gains more knowledge and at their own risk.
The next few lines are separated by comments in the original configuration files.
<Directory "D:/Uni/Year 2/Application/Site">
Options Indexes FollowSymLinks
AllowOverride None
Order allow,deny
Allow from all
</Directory>
This statement controls the level of access anyone connecting to the server will have to the files of the website. The default is set to read. I suggest keeping it this way.
# ServerTokens
# This directive configures what you return as the Server HTTP response
# Header. The default is 'Full' which sends information about the OS-Type
# and compiled in modules.
# Set to one of: Full | OS | Minor | Minimal | Major | Prod
# where Full conveys the most information, and Prod the least.
#
ServerTokens Prod
This is the next setting the user has to pay attention to. Minimising the amount of information a cracker can get about your server, makes sure that it is harder to break in to.
# Optionally add a line containing the server version and virtual host
# name to server-generated pages (internal error documents, FTP directory
# listings, mod_status and mod_info output etc., but not CGI generated
# documents or custom error documents).
# Set to "EMail" to also include a mailto: link to the ServerAdmin.
# Set to one of: On | Off | EMail
#
ServerSignature Off
Same as above
As Apache is already set up to log the events, one needs to set up a level at which the logs will be written.
# LogLevel: Control the number of messages logged to the error.log.
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
#
LogLevel info
Examining logs regularly can give a necessary warning if the server was compromised or if the attempts were made to do it. A number of log monitoring programs are awailable now, which will do the bulk of the job, yet, the Server Administrator still needs to do it on regular bases.
Next statement allows to get access to a CGI directory, read only
# "C:/Program Files/Apache Group/Apache2/cgi-bin" should be changed to whatever your ScriptAliased
# CGI directory exists, if you have that configured.
#
<Directory "C:/Program Files/Apache Group/Apache2/cgi-bin">
AllowOverride None
Options None
Order allow,deny
Allow from all
</Directory>
To better protect the server, I personally preferred to disallow this access. To do this, the best way is to comment it out
# "C:/Program Files/Apache Group/Apache2/cgi-bin" should be changed to whatever #your ScriptAliased
# CGI directory exists, if you have that configured.
#
#<Directory "C:/Program Files/Apache Group/Apache2/cgi-bin">
# AllowOverride None
# Options None
# Order allow,deny
# Allow from all
#</Directory>
“To run a really tight ship, you'll want to stop users from setting up .htaccess files which can override security features you've configured. Here's one way to do it.
In the server configuration file, put
<Directory />
AllowOverride None
</Directory>
This prevents the use of .htaccess files in all directories apart from those specifically enabled.”
Information about password protecting files or directories of the server one can find here:
http://httpd.apache.org/docs-2.0/howto/auth.html
To my best knowledge, these settings will keep your server reasonably secure.
PHP
When configuring PHP. There are a number of issues to consider. Starting from the server one uses and the way one connects to it, finishing to which information PHP should be giving to the outside world.
One could write a book on how to set up PHP with which server and Operating System.
At the moment we are going to take a look at the setting up a PHP with Apache Web Server and the security issues arising.
We will also try to work out the most secure setup. To do that we will have togo through the whole process of setting PHP up on your server system.
InstalingPHP on the System.
In my opinion the best description of PHP installation on the system, in this case Windows XP can be found in the “install.txt” file which comes with the PHP distribution.
This is a small part of the installation description:
“Chapter 2. Installation on Windows systems
This section applies to Windows 98/Me and Windows NT/2000/XP/2003. PHP
will not work on 16 bit platforms such as Windows 3.1 and sometimes we
refer to the supported Windows platforms as Win32. Windows 95 is no
longer supported as of PHP 4.3.0.
There are two main ways to install PHP for Windows: either manually or
by using the installer.
If you have Microsoft Visual Studio, you can also build PHP from the
original source code.
Once you have PHP installed on your Windows system, you may also want
to load various extensions for added functionality.
Warning
There are several all-in-one installers over the Internet, but none of
those are endorsed by PHP.net, as we believe that the manual
installation is the best choice to have your system secure and
optimised.”
Further on the explanation goes on to detailed description of the installation process. As we are not looking at it as such, we don’t need to know every detail.
For this particular instance, I chose the manual installation. I did it for a number of reasons:
1. As none of the installers are actually produced by an authorised company, they can be a security risk by themselves.
2. Manual installation is faster.
3. Manual installation is more controllable
In short the installation process looked like this:
1. I downloaded PHP files in a Zip folder from PHP website.
2. I unzipped these files in to ‘C:\PHP’ directory in my computer.
3. Found ‘php.ini-recommended’ and renamed it in to ‘php.ini’
4. Copied ‘php.ini’ in to ‘C:\WINDOWS’ so that it can be used by PHP
5. Made ‘php.ini’ readable for all the users of my system, so that anyone can use it.
Note: ‘php.ini’ is PHP’s configuration file
Next step is to set up PHP to work with Apache Web Server
Setting up PHP to Work with Apache
At the moment there are two ways to get PHP and Apache to work together:
1) Run PHP as a CGI binary
2) Run PHP as an Apache module
Although CGI allows for some extra functionality, it also allows for a number of possible attacks on the server. These attacks and defence against them will be discussed later on.
For the person setting up things up for the first time, I suggest installing PHP as an Apache module, as this will be more secure.
To do this one has to edit Apache configuration file. And to add next options:
• LoadModule php5_module c:/php/php5apache2.dll
• AddType application/x-httpd-php .php
• # configure the path to php.ini
PHPIniDir C:/WINDOWS
Note: In Apache and PHP configuration files the path to the files in Windows OS is given with forward slashes and not back slashes like in Windows itself.
As we are going to run PHP together with the MySQL server the next step would be to set up PHP to run with MySQL server
Configuring to work with MySQL
To configure PHP to work with MySQL one has to enable one of the following extensions ‘php_mysql.dll’ for the older versions of MySQL or ‘php_mysqli.dll’ for the newer version of the server.
In PHP 5, these extensions would be kept in the folder ‘C:\PHP\ext’.
To enable extensions, PHP has to know where are they based. This can be done by adding the path to the ‘extension_dir’ option of the php.ini file, which is situated in the “Paths and Directories” part of the file. The final line should look like this:
extension_dir = "C:/PHP/ext"
The extensions are enabled in the “Dynamic Extensions” part of the file. To enable them one either has to add a line:
extension=’name of extension’
or by deleting the prefix which turns the extension line in to a comment.
Yet when trying to enable the extensions, running PHP as an apache module, Apache doesn’t seem to be able to find the extension files. I wasn’t able to find a solution to the problem in the time given. The solution is to set up PHP with Apache as CGI.
To do that one has to add next line to the php.ini file:
ScriptAlias /php/ "C:/PHP/”
AddType application/x-httpd-php .php
Action application/x-httpd-php "/php/php-cgi.exe"
Securing PHP
The main source for information on securing your PHP is a ‘php.ini’ file, as an influence of every option in it is clearly marked. For more advanced options on the security can be found on a number of websites around the web.
At first, we are going to work through ‘php.ini’ file and make sure it’s secure.
As we go through the file we will be able to find a number of references to the official PHP site.
register_globals = Off [Security, Performance]
; Global variables are no longer registered for input data (POST, GET, cookies,
; environment and other server variables). Instead of using $foo, you must use
; you can use $_REQUEST["foo"] (includes any variable that arrives through the
; request, namely, POST, GET and cookie variables), or use one of the specific
; $_GET["foo"], $_POST["foo"], $_COOKIE["foo"] or $_FILES["foo"], depending
; on where the input originates. Also, you can look at the
; import_request_variables() function.
; Note that register_globals is going to be depracated (i.e., turned off by
; default) in the next version of PHP, because it often leads to security bugs.
; Read http://php.net/manual/en/security.registerglobals.php for further
As we are trying to secure the server and to foresee possible programmer mistakes, in my personal opinion, it should be set to ‘Off’
display_errors = Off [Security]
; With this directive set to off, errors that occur during the execution of
; scripts will no longer be displayed as a part of the script output, and thus,
; will no longer be exposed to remote users. With some errors, the error message
; content may expose information about your script, web server, or database
; server that may be exploitable for hacking. Production sites should have this
; directive set to off.
log_errors = On [Security]
; This directive complements the above one. Any errors that occur during the
; execution of your script will be logged (typically, to your server's error log,
; but can be configured in several ways). Along with setting display_errors to off,
; this setup gives you the ability to fully understand what may have gone wrong,
; without exposing any sensitive information to remote users.
error_reporting = E_ALL [Code Cleanliness, Security(?)]
; By default, PHP surpresses errors of type E_NOTICE. These error messages
; are emitted for non-critical errors, but that could be a symptom of a bigger
; problem. Most notably, this will cause error messages about the use
; of uninitialized variables to be displayed.
Setting ‘error_reporting’ to ‘E_ALL’ means that all even the smallest errors will be recorded in the server log. This allows to notice possible hacking attempts if the regu;ar checks are made.
expose_php = Off
; Decides whether PHP may expose the fact that it is installed on the server
; (e.g. by adding its signature to the Web server header). It is no security
; threat in any way, but it makes it possible to determine whether you use PHP
; on your server or not.
In my personal opinion, this setting should be set to ‘Off’. It is not going to stop more serious crackers but it might deter less proficient ones, who make for the majority of crackers on the web.
display_startup_errors = Off
; Even when display_errors is on, errors that occur during PHP's startup
; sequence are not displayed. It's strongly recommended to keep
; display_startup_errors off, except for when debugging.
register_globals = Off
; Whether or not to register the EGPCS variables as global variables. You may
; want to turn this off if you don't want to clutter your scripts' global scope
; with user data. This makes most sense when coupled with track_vars - in which
; case you can access all of the GPC variables through the $HTTP_*_VARS[],
; variables.
;
; You should do your best to write your scripts so that they do not require
; register_globals to be on; Using form variables as globals can easily lead
; to possible security problems, if the code is not very well thought of.
doc_root = D:/Uni/Year2/Application/Site
; The root of the PHP pages, used only if nonempty.
; if PHP was not compiled with FORCE_REDIRECT, you SHOULD set doc_root
; if you are running php as a CGI under any web server (other than IIS)
; see documentation for security issues. The alternate is to use the
; cgi.force_redirect configuration below
cgi.force_redirect = 1
; cgi.force_redirect is necessary to provide security running PHP as a CGI under
; most web servers. Left undefined, PHP turns this on by default. You can
; turn it off here AT YOUR OWN RISK
; **You CAN safely turn this off for IIS, in fact, you MUST.**
Some more information on this subject can be found:
http://www.php.net/release_4_3_1.php
http://www.php.net/security-note.php
“A Note on Security in PHP
PHP is a powerful and flexible tool. This power and flexibility comes from PHP being a very thin framework sitting on top of dozens of distinct 3rd-party libraries. Each of these libraries have their own unique input data characteristics. Data that may be safe to pass to one library may not be safe to pass to another.
A recent Web Worm known as NeverEverSanity exposed a mistake in the input validation in the popular phpBB message board application. Their highlighting code didn't account for double-urlencoded input correctly. Without proper input validation of untrusted user data combined with any of the PHP calls that can execute code or write to the filesystem you create a potential security problem. Despite some confusion regarding the timing of some unrelated PHP security fixes and the NeverEverSanity worm, the worm didn't actually have anything to do with a security problem in PHP.
When we talk about security in a web application we really have two classes. Remote and Local. Every remote exploit can be avoided with very careful input validation. If you are writing an application that asks for a user's name and age, check and make sure you are only getting characters you would expect. Also make sure you are not getting too much data that might overflow your backend data storage or whatever manipulation functions you may be passing this data to. A variation of the remote exploit is the XSS or cross-site scripting problem where one user enters some javascript that the next user then views.
For Local exploits we mostly hear about open_basedir or safemode problems on shared virtual hosts. These two features are there as a convenience to system administrators and should in no way be thought of as a complete security framework. With all the 3rd-party libraries you can hook into PHP and all the creative ways you can trick these libraries into accessing files, it is impossible to guarantee security with these directives. The Oracle and Curl extensions both have ways to go through the library and read a local file, for example. Short of modifying these 3rd-party libraries, which would be difficult for the closed-source Oracle library, there really isn't much PHP can do about this.
When you have PHP by itself with only a small set of extensions safemode and open_basedir are generally enough to frustrate the average bad guy, but for critical security situations you should be using OS-level security by running multiple web servers each as their own user id and ideally in separate jailed/chroot'ed filesystems. Better yet, use completely separate physical servers. If you share a server with someone you don't trust you need to realize that you will never achieve airtight security. “
MySQL
When working with MySQL, there are a number of security concerns, yet many of them will be more of the coding issues rather then the actual setup ones.
Most information about this issues can be found in a tutorial supplied with MySQL.
Installing MySQL
Up till MySQL 4, to install MySQL one could simply download the files from their website and copy them in to a necessary directory. As of version 5, MySQL comes with an installer program.
When running an installer, the user is given a number of options to fill in before their server will be launched. As everything is automated we will look only at the few options.
At the start, I suggest installing MySQL in “C:\mysql” folder, as it makes it easier to work with if using command line.
Another option which interests us is that automatic installer offers to run MySQL as a Windows Service. This is the way I prefer to run it. The installer also offers to install a password on to your root account, one MUST do it when asked.
If using an older version of MySQL the Windows service can be installed by using command line.
The statements shown on the picture, will install MySQL as Windows servise.
More information on the subject can be found in MySQL tutorial in the chapter “2.3.12 Starting MySQL as a Windows Service”
Everything written further will assume that a user has some knowledge of MySQL and have chosen their way of working with it.
Securing MySQL
Make sure that you don’t have any accounts without password.
When just installed, older versions of MySQL server have a number of default accounts. To see them one has to use the next statement:
“SELECT Host, User FROM mysql.user;”
To make sure that the server is more secure, I suggest deleting all of the default accounts and renaming a root account and setting up a password for it. This will make sure that the crackers won’t be able to connect to the default names, making their life much harder.
To delete unnecessary accounts one can use next statement
“mysql> DELETE FROM mysql.user WHERE User = ' ';
mysql> FLUSH PRIVILEGES;”
To update the root account;
Password:
“mysql> UPDATE mysql.user SET Password = PASSWORD('newpwd')
-> WHERE User = '';
mysql> FLUSH PRIVILEGES;”
MySQL automatically encrypts all the passwords, making it harder for a cracker to read them, even if he manages to see them.
Further on, one will need to set up an account or accounts for other users or a web page. When doing this an administrator has to seriously consider which privileges will they have.
Privileges – in MySQL this refers to the actions a user is allowed to do on the server.
Detailed information on privileges can be found here:
http://dev.mysql.com/doc/mysql/en/pr...-provided.html
To set up a new account the next statement can be used:
grant privilege(s) on database/table name to 'username'@'hostname/ip address' identified by 'Password';
Sample:
grant insert, select on test to 'php'@'localhost' identified by '*******';
If the user connects from another computer, as of 4th version of the server, one can make the connection more secure by using Secure Socket Layer. Another way of setting up secure connection is to use Secure Shell.
Details on how to do it can be found in the tutorial Chapter 5.6.7 Using Secure Connections
If there are no users which will connect from other machines, one should block MySQL TCP/IP port with a firewall. A default port for MySQL is TCP 3306.
Miscellaneous
As well as setting up the server, one has to make sure that the page code is secure. Having good validation rules in the pages makes a major improvement to the server security. This help to defend against the attacks like ‘Buffer Overflow’ and ‘SQL Injections’.
Another good idea is running a firewall. Using it one can close all the ports that are not used by the server, making it virtually impossible to break in. If I wanted my personal server secure and all it was doing was just serving pages, I would keep just a ‘ping’ port open an ‘http’ port (80) open.
As it was already mentioned, regular checks of the logs should be practiced.
Conclusion
The settings shown in this work are made to the best of my knowledge. Although they might be not the optimal ones, to improve on them I would need to spend more time learning given technologies.
Bibliography
Books
Hacking Exposed 4th Edition by Stuart McClure, Joel Scambray and George Kurz
Network Seurity First-Step by Tom Thomas
A Complete Hackers Handbook by Dr-K
PHP - For Dummies - PHP and MySQL for Dummies, Second Edition by Janet Valade
Beginning PHP5 by Cave W.Mercer, Allan Kent, Steven D. Nowicki, David Mercer, Dan Squier, Wankyu Choi
Websites
http://www.php.net/
http://www.apache.org/
http://httpd.apache.org/
http://www.mysql.com/
http://www.antionline.com/
http://www.rupoint.co.uk/
