Security

From TYPO3Wiki

Jump to: navigation, search

<< Back to Administrators page

[edit]

Contents

[edit]

Security

Security is a must for any webserver, big or small. The primary focus of this page is to educate webmasters, site administrators and host masters in web page security.

There are two sections:

  • General Security
    • Basic security applicable to any setup.
  • PHP Security
    • Security options available to PHP.
  • TYPO3 Security
    • Security as it pertains to TYPO3.
[edit]

General Security

There are a few different ways to help safeguard your website. We'll briefly discuss them, pros and cons.

[edit]

Secure Your Server

While basic network topology is paramount to securing and defending against would be intruders. There are several additional items you should take into consideration.

  • Firewall configuration
    • Drop all packets that are not approved ports or that are not needed.
    • Allow ports that you will use, or will accept incoming traffic to, which usually include ports 80 (http) and 443 (https). By limiting the incoming connections and only accepting specific types (ports), you can prevent a tremendous amount of succcessful attacks.
  • Server configuration
    • Turn off all services that are not being used. Services that are not being used, but are enabled and running have a two-fold problem.
      • Unneccessary use of resources. The more stuff you run, the more memory and resources you need.
      • Could potentially open a security breach, or allow a denial of service (DoS) attack.
    • Limit the number people who have administrator (superuser) capabilities.
    • Use a secure or encrypted connection when configuring or performing maintenance.
      • Utilize the Secure Shell (SSH) or other similarly encrypted connection.
[edit]

Remove Default Pages

Most of us have seen them: a website that has not been configured. Whether is says, "Welcome to Apache" or "Welcome to IIS", these default sites that are shipped with most web servers are a "Welcome Hackers" style introduction. If a hacker sees that you haven't changed the default site, it only makes breaking in that much easier. What if that default site exposes usernames, passwords, is unencrypted, has symlinks to other secured places, etc? Well, the hacker now has the keys.

Prevent this!! If you do not have content for your site, do one of the following:

  1. Disable your webserver until you have replaced all the default content.
  2. Delete all the default content.
  3. Change your sites web root / document root directory to new directory.
[edit]

Remove Server Information

As a general rule of thumb, if I am hacking a website, I am only going to target ones that either uses a specific web server that has numerous problems or known exploits, or one that is so difficult to configure that there are high numbers of misconfigured sites out there.

One simple way is to remove all banners exposing the server technology that you use. Sure, NetCraft wouldn't like it, but they are not responsible for your downtime, now are they? I like to keep my banners as vague as possible.

If a surfer gets a 404 - Page Not Found, they only see that I am running a "Webserver - www.mysite.com"

[edit]

Remove Content Handlers

Going along with the idea of removing server information, I should also point out that utilizing the url rewrite capabilities of your webserver is another fantastic idea. The idea behind rewriting urls is that a user is presented with a document that differs from the request, but references the same document.


To the same effect, if you wake up tomorrow and PHP, ASP, etc suddenly has over 5,000 security exploits, but end users only see html documents, it will slow down potential attacks.

When the user sees a directory not a file, the style of RealURL, that user doesn't know exactly what type of document was returned. Much the same as simulateStaticDocuments gives the impression of a static web page, not one that could be exploited because of a buffer overflow in the scripting technology. Because of rewriting, your site could potentially be overlooked.

TYPO3 has the capabilities to use rewrites to make navigation simpler for end users and to combat / assist in regards to security.

  • See simulateStaticDocuments
  • See RealURL
[edit]

Open Directories

[edit]

What is an open directory?

An open directory is a directory (folder) on your webserver that does not contain a default html page. Depending on your server, this file may vary.

  • Common Apache Default Documents
    • index.html index.htm index.php
  • Common Microsoft IIS Default Documents
    • default.htm default.asp index.htm

The presence of a default document prevents web surfers from seeing a directory listing thus securing a potential security risk.

[edit]

Fixing open directories

There are a few ways to counter this "feature".

[edit]
Configure your webserver so that directory indexes are not displayed.

If you're using Apache 1.3, edit your server config (httpd.conf), insert Options -Indexes

httpd.conf 

##
# Example configuration
# Adjust for your personal need.
##

<Directory />
 Options -Indexes
 AllowOverride None
</Directory>

For details, see Apache documentation about the Options directive

[edit]
Place a default document in every directory and subdirectory on your webserver.

(Read the annotation in this paragraph, why NOT!)

Your default document does not need to be overly complex. In fact, many sites use a redirect to forward them to another page. This is quite simple and easy to do.

Here are a couple of simple examples:

index.php 

<?php
Header("Location: http://example.net/index.php"); 
?>

index.html 

<HTML>
 <HEAD>
  <TITLE>Page Not Found</TITLE>
 </HEAD>
 <BODY>
  Sorry, that page was not found.
  <A HREF="/index.php">Click here to continue</A>
 </BODY>
</HTML>

An even simpler default document is a blank document. Remember, the goal is to prevent easy access to data. Just having a default document in all directories does not prevent access to those directories, on the contrary, it only prevents a person from viewing all files in that directory. A web surfer could, in theory, still guess files that may or may not exist in that directory, but not seeing the files would make this task drastically more difficult.


Annotation: The second solution is a bad idea. If a page is not allowed to be viewed, the webserver should answer with error code "403 - Forbidden" and not 200. Otherwise searchbots will try to index the (nonsense) page and if they realize nonsense, you're site will be ranked lower.

[edit]

General Security Links

Here are a few links that will help you secure your web server, or at least give you an idea of what else you should do:

[edit]

PHP Security

NOTE: This section applies to any PHP enabled webserver running in a production environment. If these tips are applied, development and debugging will become a daunting and frustrating task.

[edit]

PHP.INI Configuration

This section will give you a brief walkthrough of the security options available in the PHP.INI file.

[edit]

Hide Error Messages

If your script bombs, you may not want the details displayed to Joe Websurfer. What if the error contains sensitive data such as a username and password? The following two options will enable logging of errors, yet suppress them from being displayed. 

log_errors = On
display_errors = Off

These options are a nightmare for extension programmers or general development because they hide all the normal debug messages. This however, can allow you to make a more attractive error message that end-users would potentially see.

[edit]

Turn Register Globals Off

What does Register Globals do?

Variables sent to PHP (ie GET/POST) are accessible to the PHP script, after all, how else is a web surfer to interact with a website? In the early days of PHP (prior to PHP v4.20), all GET/POST data sent was automatically converted into a variable.

Update your PHP.INI to include: 

register_globals = Off

To demonstrate register globals on, take the url http://domain.tld/index.php?id=123

With Register Globals ON, the id GET variable is converted and is accessible to PHP via the $id variable as so:

index.php 

<?php
echo "You requested id #" . $id;
?>

This feature allowed for very easy access to GET/POST data.

Where is the problem?

The problem is that if your PHP script is looking for id to be sent as a POST variable, a web user could potentially override it with a GET variable instead. Depending on the purpose your the script, the consequences far out weigh the risks.

Refer to the following link for a more detailed description:

[edit]

PHP Security Links

Some additional resources you may want to consider covering include:

For Administrators:

For Developers:

[edit]

TYPO3 Security

TYPO3 was designed to be very flexible; and to that extent, there are times where it is more of a Content Management Framework (CMF) than a Content Management System (CMS). Security has been an integral part since the beginning, and continues today.

[edit]

Post Installation Security

After you have successfully installed TYPO3, you may want to consider a few of these tips. I personally recommend all of them, but your requirements may be different.

Since I have successfully configured TYPO3 using the install tool, I am not going to need to use it immediately. I first want to start with the easy security first.

  • Change the default install utility password. Of course, we all know the default password, "joh316". Go ahead and change it to something super secret and difficult to guess? After all, we all know the default password.

Theoretically we could stop here, but I'm a little more security minded.

I know the following to be true:

  • I am not going to be accessing the install tool very frequently, so I can make using it difficult.
  • I have shell access to the webserver (or the ability to edit files directly on the site).
  • I am only going to use the install tool from either the webserver itself, or another machine on my network.
[edit]

Disable the Install Tool

First, the only time I am going to need to access the install tool is when something drastic changes on my webserver. The times when I need access to the install tool could be a result of a new webserver, an upgrade of software, an upgrade of hardware or a database change. Since it is so powerful, I want to basically cripple it.

Edit /webserverroot/typo3/install/index.php and add a die() statement.

an example of a secured install index.php is: 

<?php
/***************************************************************
*  Copyright notice
*
*  (c) 1999-2004 Kasper Skaarhoj (kasperYYYY@typo3.com)
*  All rights reserved
*
*  This script is part of the TYPO3 project. The TYPO3 project is
*  free software; you can redistribute it and/or modify
*  it under the terms of the GNU General Public License as published by
*  the Free Software Foundation; either version 2 of the License, or
*  (at your option) any later version.
*
*  The GNU General Public License can be found at
*  http://www.gnu.org/copyleft/gpl.html.
*  A copy is found in the textfile GPL.txt and important notices to the license
*  from the author is found in LICENSE.txt distributed with these scripts.
*
*
*  This script is distributed in the hope that it will be useful,
*  but WITHOUT ANY WARRANTY; without even the implied warranty of
*  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
*  GNU General Public License for more details.
*
*  This copyright notice MUST APPEAR in all copies of the script!
***************************************************************/
/**
 * Starter-script for install screen
 *
 * $Id: index.php,v 1.11 2004/09/13 22:57:22 typo3 Exp $
 *
 * @author      Kasper Skaarhoj <kasperYYYY@typo3.com>
 * @package TYPO3
 * @subpackage core
 */
// **************************************************************************
// Insert some security here, if you don't trust the Install Tool Password:
// **************************************************************************
die("Disabled.");
// *****************************************************************************
// Defining constants necessary for the install-script to invoke the installer
// *****************************************************************************
define('TYPO3_MOD_PATH', 'install/');
$BACK_PATH='../';
// Defining this variable and setting it non-false will invoke the install-screen called from init.php
define('TYPO3_enterInstallScript', '1');
require ('../init.php');
?>

In order to get the install tool to run, one would have to remove or comment out the die() statement. Performing the needed changes would require edit/write capabilities on the web server.

[edit]

Restrict Access to the Install Tool

Webserver's often allow you to restrict access to directories according to specific IP addresses, hosts or networks. You can also utilize passwords, but there are some instances where passwords are sent in clear text allowing for sniffers to catch and use it.

On Apache, I like to use an .htaccess file in every directory I want to restrict. Your Apache server configuration may require some modification to allow for this. If it does, please refer to your Apache manual for assistance.

The .htaccess I use looks like: 

order deny,allow
deny from all
allow from 127.0.0.1
allow from 192.168.1.0
allow from 192.168.10.100

This denies access from everywhere but permits access from the localhost (127.0.0.1), my local network (192.168.1.0) and one computer whose ip is 192.168.10.100. This will prevent anyone on the outside from getting far enough to see that it's been disabled!

If you are using Microsoft IIS, the method is slightly different, but the results are the same.

[edit]

Remove the Default Admin Account

By simply removing the default admin user, you can prevent a lot of craziness. The default administrator has complete power over your TYPO3 installation. The admin user also has a default password, which most of us know.

Some people recommend just changing the admin user's password. I, for one, have a different opinion. I create another admin user with a different username. For example, you could create any of the following: superadmin, super or hostmaster. Be creative and make it difficult to guess.

For passwords, everyone has their own methods, personally I use a minimum of 8 characters with 5 letters 2-3 uppercase and 2 numbers and 1 special character ( !@#$%^&*()., ).

After you create a new admin user or change the username to something else, along with the password of course, delete the old one if applicable.

[edit]

Remove access to localconf.php

NOTE: Summarization of Kasper's recommendation.

What we will do here is eliminate the ability for remote users to view your localconf.php file. While this in and of itself is an EXTREMELY RARE occurance, please be advised that in the event of misconfiguration of this step, your site will not be accessible.

First we will create a safe directory outside the scope of our website.

For example, on Linux, if your document root is /var/www/localhost/htdocs, we could create a new directory /var/www/localhost/securedata. We then will move our /var/www/localhost/htdocs/typo3conf/localconf.php to /var/www/localhost/securedata. After moving, we'll create a new localconf.php containing the following: 

<?php
require("/var/www/localhost/securedata/localconf.php");
?>

The purpose here is to prevent someone from accidentally or intentionally getting your configuration options.

Example: steps on Linux: 

update your paths, backup your data, etc
NOTE: You may also pick an arbitrary name for your moved localconf.php
# cd /var/www/localhost
# mkdir securedata
# mv htdocs/typo3conf/localconf.php securedata
# echo "<?php \
> require(\"/var/www/localhost/securedata/localconf.php\"); \
> ?>" > \
> htdocs/typo3conf/localconf.php
# chown -R apache:apache securedata
# chown -R apache:apache htdocs/typo3conf/localconf.php

You will want to double, triple and quadruple check all of these settings are correct.

[edit]

Change the TYPO3 BE directory

Follow the directions found here to change your typo3 directory to something else.

[edit]

Use Separate Database Users for FE and BE

Create two databse users. One with restriced rights for the FE. This user should not have any rights to creat e, alter or delete tables. It's also advisable to have only read-only access for all tables, except thos few which are manipulated by extensions. The other user must have extended rights, to allow the extension manager to install new extensions. Neither user must have any rights to grant database rights, change the database server status (shutdown) or expose database server information (server status, list of databases).

To use this setup, change the setting of the database user in localconf.php to this (example): 

if (TYPO3_MODE=='FE') {
 $typo3_user_name = 'restricted_user';
} else {
 $typo3_user_name = 'extended_user';
}
[edit]

TYPO3 Security Links

Some links about security in Typo3:

--Joshua Preston 21:16, 24 Apr 2005 (CEST)

Retrieved from "http://wiki.typo3.org/index.php/Security"
Personal tools
content
help 'N' beginners