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 mod_autoindex.so. In Ubuntu, you just need to remove the following files:
/etc/apache2/mods-enabled/autoindex.load
/etc/apache2/mods-enabled/autoindex.conf
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/foo.bar/:/usr/local/php/ 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
</Location>
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
</Directory>
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 176.31.0.0/16
Or by IP:
Order Deny,Allow
Deny from all
Allow from 127.0.0.1
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.
SecRule rules should be added to secure from SQL injection attack.
ReplyDelete