Skip to main content

Hardening Apache2

Security Tip 1Disable Apache Signature and/or Apache Banner
Apache Signature or Apache Banner is basically the same thing. It is an application name together with version name that is printed when performing a web request. Nobody actually needs this information at all, but it is enabled by default. You need to alter the Apache configuration file to disable it. ServerSignature Off ServerTokens ProductOnly In Ubuntu, you need to change the following file: /etc/apache2/conf.d/security Double check that ServerSignature and ServerTokens configuration settings are not enabled in some other parts of the configuration file.

Security Tip 2:The Trace HTTP Request
HTTP TRACE request is used to echo back all received information. It can be tricked to print HTTP cookies and as a result steal HTTP session. Basically this request can be used as part of the Cross Site Scripting attack, or XSS. It is recommended to disable it as a security precaution. Add the following to the web-server's configuration file. For example alter the following file in Ubuntu: /etc/apache2/conf.d/security.

Security Tip 3:Disable directory indexing
Directory indexing is a features found in every web-server by default. When directory indexing is enabled, the web-site prints a list of files found in the website directories when the default page does not exists (for example index.php). Directories reported can be viewed by any visitor. It is vulnerable in the sense that these directories can contain configuration, private and backup files which can be used by the attackers to take your server under control. You can fix this problem by disabling the Apache autoindex module. In some Apache installations it is called In Ubuntu, you just need to remove the following files:
So you can do it running the following commands:
rm -f /etc/apache2/mods-enabled/autoindex.load
rm -f /etc/apache2/mods-enabled/autoindex.conf
We can also use command:
a2dismod autoindex

Security Tip 4:Create a chroot'ed Apache environment
This is a good solution if you want to protect your website from malicious users. The action steps required to create chroot Apache was already covered in a number of websites.The main hidden issue with chrooted environment is that this environment protects the websites from accessing the operating system's files. It does not protect one site from another. In other words, if a malicious script located in one site it can access files located on other site because they are located on the same chrooted environment. A solution to this problem is the following. Create a number of apache instances, each one hosting one website running each one if different chrooted directory. These apache instances will not be able to share IP addresses. You will have to configure different IP for each Apache instance you run.
Chroot Apache2

Security Tip 5: Enable Php Basedir
PHP has built in a kind of chroot environment. It is called “basedir”. You can configure PHP scripts to access files only in specific directory similar to chroot. Basically you can configure each site to access only files located in that site directory which is a very good idea from the security point of view. You can add the following lines to the website configuration file or to .htaccess file to enable PHP basedir: Php_value open_basedir /var/www/ This will specify that your PHP scripts can access only specified directories.

Security Tip 6:Enable Status Module only for localhost
Status module help in getting live information about current condition of apache2 web server.It is a very helpful module from administration perspective.
lets have look at secure /etc/apache2/mods-enabled/status.conf file that allow only localhost to access it status.

ExtendedStatus On
<Location /server-status>
    SetHandler server-status
    Order deny,allow
    Deny from all
    Allow from localhost ip6-localhost

Security Tip 7:Install mod-evasive
As a last measure from a DDOS attach, Apache has a module which black lists IP addresses temporarily. The default rules are:
Requesting the same page more than a few times per second
Making more than 50 concurrent requests on the same child per second
Making any requests while temporarily blacklisted (on a blocking list)
apt-get install libapache2-mod-evasive

Security Tip 8: Install mod-security
Helps stop some injection and Server Side Includes (SSI) attacks:
apt-get install libapache2-mod-security2

Security Tip 9:Ensure that / files are not served
<Directory />
Order Deny,Allow
Deny from all
Options None
AllowOverride None

Security Tip 10:Restricting Access by IP
If you have a resource that should only by accessed by a certain network, or IP address you can enforce this in your apache configuration. For instance if you want to restrict access to your intranet to allow only the 172.31 network:
Order Deny,Allow
Deny from all
Allow from
Or by IP:
Order Deny,Allow
Deny from all
Allow from

Security Tip 11:Server Side Includes
Server Side Includes (SSI) present a server administrator with several potential security risks. The first risk is the increased load on the server. All SSI-enabled files have to be parsed by Apache, whether or not there are any SSI directives included within the files. While this load increase is minor, in a shared server environment it can become significant. SSI files also pose the same risks that are associated with CGI scripts in general. Using the exec cmd element, SSI-enabled files can execute any CGI script or program under the permissions of the user and group Apache runs as, as configured in httpd.conf. There are ways to enhance the security of SSI files while still taking advantage of the benefits they provide. To isolate the damage a wayward SSI file can cause, a server administrator can enable suexec as described in the CGI in General section. Enabling SSI for files with .html or .htm extensions can be dangerous. This is especially true in a shared, or high traffic, server environment. SSI-enabled files should have a separate extension, such as the conventional .shtml. This helps keep server load at a minimum and allows for easier management of risk. Another solution is to disable the ability to run scripts and programs from SSI pages. To do this replace Includes with IncludesNOEXEC in the Options directive. Note that users may still use <--#include virtual="..." --> to execute CGI scripts if these scripts are in directories designated by a ScriptAlias directive.


  1. SecRule rules should be added to secure from SQL injection attack.


Post a Comment

Popular posts from this blog

Hacking Windows 10 UWP App: DLL Injection & common Vulnerabilities

I recently started working on  widows 10 Apps( Apps not Applications) security. Before diving deep in hacking terms lets try to understand what's new in Windows 10 UWP( Universal Platform) as compared to old Apps. Lets begin with how apps actually work on windows 10(desktop/tablet). Now windows 10 comes with a container only for running apps inside the isolated environment. By default, /APPCONTAINER(Linker Flag) is off. This option modifies an executable to indicate whether the app must be run in the appcontainer process-isolation environment. Specify /APPCONTAINER for an app that must run in the appcontainer environment—for example, a Windows Store app. (The option is set automatically in Visual Studio when you create a Windows Store app from a template.) For a desktop app, specify /APPCONTAINER:NO or just omit the option. The /APPCONTAINER option was introduced in Windows 8. Now there is no registry entry concept for these app in the System HIVE rather they install they own hiv

Installing vmware-11.0 on Ubuntu 15.04 Using kernel Patch

curl -o /tmp/vmnet-3.19.patch cd /usr/lib/vmware/modules/source tar -xf vmnet.tar patch -p0 -i /tmp/vmnet-3.19.patch tar -cf vmnet.tar vmnet-only rm -r *-only vmware-modconfig --console --install-all References:

SSI Injection Attack

SSIs are directives present on Web applications used to feed an HTML page with dynamic contents. They are similar to CGIs, except that SSIs are used to execute some actions before the current page is loaded or while the page is being visualized. In order to do so, the web server analyzes SSI before supplying the page to the user. The Server-Side Includes attack allows the exploitation of a web application by injecting scripts in HTML pages or executing arbitrary codes remotely. It can be exploited through manipulation of SSI in use in the application or force its use through user input fields. It is possible to check if the application is properly validating input fields data by inserting characters that are used in SSI directives, like:  Code: < ! # = / . " - > and [a-zA-Z0-9] Another way to discover if the application is vulnerable is to verify the presence of pages with extension .stm, .shtm and .shtml. However, the lack of these type of pages does not mean that th