Results 1 to 10 of 10

Thread: Apache, PHP, MySQL with basic security settings.

  1. #1
    Senior Member
    Join Date
    Apr 2004
    Posts
    228

    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/
    Don\'t post if you\'ve got nothing constructive to say. Flooding is annoying

  2. #2
    Though some would argue that there really and truely is no such thing as the term "world wide web" without the world wide web that we now know today but I'd say it all gained it's start more likely close to around some 1970s era actually.

    keep just a ‘ping’ port open an ‘http’ port (80) open.
    Ping port, say what? Errrr... yeah ok.

    This help to defend against the attacks like ‘Buffer Overflow’
    ummm... ok.

  3. #3
    Senior Member
    Join Date
    Jan 2002
    Posts
    1,207
    Another thing you could do to mysql, is if you're not planning on using it from external machines, in my.cnf have it bind to localhost (127.0.0.1) only. This is the default on Debian Linux.

    That way, even if your firewall somehow accidentally lets mysql traffic in, it won't get anywhere:

    in my.cnf
    Code:
    [mysqld]
    bind-address            = 127.0.0.1
    Slarty

  4. #4
    Senior Member
    Join Date
    Apr 2004
    Posts
    228
    Originally posted here by ¤The¤Spe©ialist
    Ping port, say what? Errrr... yeah ok.
    Protocol: ICMP
    Port: 8

    Allows to ping a machine . Enjoy
    Don\'t post if you\'ve got nothing constructive to say. Flooding is annoying

  5. #5
    Just a Virtualized Geek MrLinus's Avatar
    Join Date
    Sep 2001
    Location
    Redondo Beach, CA
    Posts
    7,323
    nightcat, where do you get this? The IANA indicates that port 8 is unassigned. Are you thinking of ICMP Type 8 (echo reply). AFAIK, there is no specific port assigned to ICMP.
    Goodbye, Mittens (1992-2008). My pillow will be cold without your purring beside my head
    Extra! Extra! Get your FREE copy of Insight Newsletter||MsMittens' HomePage

  6. #6
    Senior Member
    Join Date
    Apr 2004
    Posts
    228
    Originally posted here by MsMittens
    nightcat, where do you get this? The IANA indicates that port 8 is unassigned. Are you thinking of ICMP Type 8 (echo reply). AFAIK, there is no specific port assigned to ICMP.
    That's the stting on my router as I got it. This was the only port which was allowed to be contacted from the outside world.

    Yet, as I said, I am not exactly an expert, so I could get the terminology wrong.

    Edited: And the link you give doesn't deal with ICMP, it only covers TCP and UDP. Check this.
    http://www.webopedia.com/TERM/I/ICMP.html
    Don\'t post if you\'ve got nothing constructive to say. Flooding is annoying

  7. #7
    Senior Member
    Join Date
    Apr 2004
    Posts
    228
    Just went through a white paper on ICMP.
    MsMittens is right, they have ICMP Type 8 for echo requests, that's the same one the ping uses
    Don\'t post if you\'ve got nothing constructive to say. Flooding is annoying

  8. #8
    Senior Member ShippMA's Avatar
    Join Date
    Oct 2002
    Posts
    165
    Hi nightcat,

    Thank you very much for the tutorial. I have recently installed Apache2, PHP and MySQL and was having a right nightmare deciphering (is that spealt correctly) security settings. This is the first time i have found something that advises on specific settings to use and then gives a reason for the setting and does not use overly technical language that a newbie doesn't understand.

    As you have said the document covers basic settings and i know that there are plenty more precautions that should be taken (just not sure what they are yet), however at least now i have a starting point and not just a ton of uniterpretable documentation (at least to me it is)

    I would also be pleased if i was you at the responses you have got from the other members as they all appear to be minor corrections and noone has picked up any "big" errors in the document, well done.

    Thank you very much.

    ShippMA
    www.simpleits.co.uk
    www.tazforum.**********.com
    Google is god ....... of the Internet

  9. #9
    Banned
    Join Date
    May 2003
    Posts
    1,004
    First off, this subject has been done before in several tutorials, kindly search next time before posting, unless of course you feel that you could improve upon prior attempts with either more modern or more advanced information, which was not the case here.

    Second, if you are going to give a history lesson, know your history.

    The World Wide Web was started around 1989.
    Around 1989... May 17, 1991... it's all the same, right?

    The back bone of WWW was and still is an American military network Internet.
    The Military ceased to be involved with ARPANET (which ceased to exist back in 89 anyhow) back in 1982. And was not involved with the private development of what we call the internet.

    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.
    Actually, it is up to server administrators to follow procedure developed by the InfoSec department and it is up to web designers to make pretty pages that are easy to use. Would you actually buy things online if you thought security was being handled by some artsy kid with a six week certificate of completion in "Mastering Dreamweaver"? I know I wouldn't

    1. Client – a user’s computer, which accesses information.
    2. Server – a computer which provides information and services.
    Um, my desktop provides information and services (netbios for example) does this mean it is a server? These terms are defined by their relationships, not content. Client is a many to one system and server is a one to many or many to many system.

    After this you more or less copied and pasted Webpedia.com, for whatever value that adds.


    At the moment the most popular technologies are open source technologies:
    It's a good thing you selected Microsoft Windows XP then.

    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.
    Ah ok, so your targeting grandmas and kids, yet you decided against using the webserver included with their OS or the database most likely included with their office package or the scripting language included with their OS?
    Seems an odd choice, but I suppose not outright wrong.

    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.
    200 hours?!?! You expect grandma to spend eight hours a day for 25 days to set up her home webserver?

    Directory "C:/Program Files/Apache Group/Apache2/cgi-bin"
    For security reasons, I understand placing your http_root on a non-system drive, but why then place the cgi-bin on the system drive?
    For that matter, if you are using mod_php, why even have a cgi-bin? Seems to make little sense with regard to security.

    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.
    Are you setting up a web hosting server? Otherwise I don't see how this is relevant.

    To my best knowledge, these settings will keep your server reasonably secure.
    Without a single mention of user permission? I guess we have very different ideas about what "reasonably secure" means.

    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.
    So... in other words, you've just wasted the reader's time and are instead providing what you have called a less secure solution in a security tutorial? Brilliant. And seriously, in 200 hours you could find the solution? You could have rewritten Apache's extention handling in that amount of time, after learning C.

    AddType application/x-httpd-php .php
    Earlier you make every effort to hide the servers identification, and now you let the world know what scripting language you are using? You shouldn't halfass security by obscurity.

    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.
    In reality this creates an unusably large amount of logs, and really I just don't think that grandma is going to pay attention to them, better to have fewer more important logs to hold her attention.

    expose_php = Off ... 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.
    Yes, especially after: AddType application/x-httpd-php .php

    Oh... gee, a whole PHP security tutorial that makes no more than passing mention of "safe_mode" and "open_basedir" or even how to disable unused features.

    At the start, I suggest installing MySQL in “C:\mysql” folder, as it makes it easier to work with if using command line.
    You know grandma and her command line... and to hell with running such things on a non-system drive, right?

    The mySQL section is really very brief and dosn't contain much to comment on learn from.

    aving good validation rules in the pages makes a major improvement to the server security.
    Good thing grandma knows all about these already so you have no reason to explain.

    I would keep just a ‘ping’ port open an ‘http’ port (80) open.
    This has already been commented on.

    As it was already mentioned, regular checks of the logs should be practiced.
    Checks for what? When milling through the endless terabytes of log data that your configuration will generate, what should we be looking for?

    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.
    Real security begins at the OS level, with no mention of how to secure you Apache, PHP, and mySQL installations from the OS perspective, the whole thing is useless.

    cheers,

    catch

  10. #10
    Senior Member
    Join Date
    Apr 2004
    Posts
    228
    Catch, I'm very grateful for your comments.

    Yet I think you take some things to literaly. You also seem to have a tendency to take a line out of a paragraph and to coment on it, rather then getting the whole thing.

    I do admit that I am not as good as you and hardly going to become better then you in any near time.

    As you say yourself security is a very complex thing, it starts from the OS and finishes with the page itself. If I were to write the way you want, then I'd have to write a book .

    I will also be glad to hear your advise on the settings and will correct my mistakes.

    And I guess you'll be surprised, but I spent far more then 200 hours on this thing. I am not a technowiz, so it took me a long time to make at least some sence out of some of the literature on the subject.

    So please, help us all, don't write anything that'll just make others angry at you.

    Thanks. Nightcat
    Don\'t post if you\'ve got nothing constructive to say. Flooding is annoying

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •