Posts Tagged ‘security practice’

How to remove parameters from URL on Apache (Reverse Proxy) with .htaccess and mod_rewrite – Remove query string from Link

Thursday, December 11th, 2014

Desktop/How_to_remove_parameters_from_URL_on_Apache_with_htaccess_and_SAP
Recently I had a task to delete number of set variables (listed parameters) from URL address on a Apache webserver serving as Reverse Proxy. 
To make it more clear exact task was when customers call the URL https://companywebsite-url.com (all subdomains included) the following URL parameters should always be deleted by the reverse proxy

– ebppMode 
– ebppObjectKey 
– ebppObjectType 
– ebppSystem 
– logSys 

The paramets are part of SAP Biller Direct in a Portal (based on the famous SAP database) which is often deployed as a component of Internet Sales (ISA) / Supplier Relationship Management (SRM) / CRM
, if a user is logged in with his Credentials (KID (Key ID) / Admin KID)  into the system. The EBPP part of most variables stands for (Electronic Bill Presentment and Payment).

 By passing above parameters to Website, modes of use, user accounts switched with which user is logged into the system system logs read and other stuff which can turn to be a severe security hole.
As most of Big Companies, does pass there web traffic via a "transparent" Reverse Proxy,it is a good security practice for SAP Biller Direct (including CRM systems( to wipe out this variables

Here is the mod_rewrite working rules that I used to achieve the delete variable from URL address task:
 

   RewriteEngine On
   RewriteCond %{QUERY_STRING} ^(.*)bebppMode=(w*)b(.*)
   RewriteRule (.*) $1?%1%3

   RewriteCond %{QUERY_STRING} ^(.*)bebppObjectKey=(w*)b(.*)
   RewriteRule (.*) $1?%1%3

   RewriteCond %{QUERY_STRING} ^(.*)bebppObjectType=(w*)b(.*)
   RewriteRule (.*) $1?%1%3

   RewriteCond %{QUERY_STRING} ^(.*)bebppSystem=(w*)b(.*)
   RewriteRule (.*) $1?%1%3

   RewriteCond %{QUERY_STRING} ^(.*)logSys=(w*)b(.*)
   RewriteRule (.*) $1?%1%3

   RewriteCond %{QUERY_STRING} ^(.*)&&(.*)
   RewriteRule (.*) $1?%1%3


P.S. I've implemented above Rewrite rules into all Virtualhosts of Applications (in that case all living in the same httpd.conf on SuSE (SLES) 11 SP1 Enterprise Linux server).
To make changes affective, restarted HTTPD Webserver:
 

/etc/init.d/httpd restart


The sesult is:

https://companywebsite-url.com/start.html?page=start&ebppMode=A&ebppSystem=Test

leads to a internal URL redirection

https://companywebsite-url.com/start.html?page=start

without parameters ebppSystem, ebppMode, ebppObjectKey, ebppSystem,   logSys .

Other mod_rewrite rule that works but is too ugly and when I tried it on Debian Linux host was behaving strange (including in the rewrited URL address the directory address of the PHP twice):

RewriteCond %{QUERY_STRING} (.*)(^|&|%26|%20)ebppMode(=|%3D)([^&]+)(.*)$ [OR]
RewriteCond %{QUERY_STRING} (.*)(^|&|%26|%20)ebppObjectKey(=|%3D)([^&]+)(.*)$ [OR]
RewriteCond %{QUERY_STRING} (.*)(^|&|%26|%20)ebppObjectType(=|%3D)([^&]+)(.*)$ [OR]
RewriteCond %{QUERY_STRING} (.*)(^|&|%26|%20)ebppSystem(=|%3D)([^&]+)(.*)$ [OR]
RewriteCond %{QUERY_STRING} (.*)(^|&|%26|%20)logSys(=|%3D)([^&]+)(.*)$

RewriteRule (.*) /$1?%1%5 [R=307]

 Well anyways, with the first bunch of mod_rewrite rule it works fine.

Thanks God Problem Solved 🙂

How to disable IPv6 on Debian / Ubuntu / CentOS and RHEL Linux

Friday, December 9th, 2011

I have few servers, which have automatically enabled IPv6 protocols (IPv6 gets automatically enabled on Debian), as well as on most latest Linux distribituions nowdays.

Disabling IPv6 network protocol on Linux if not used has 2 reasons:

1. Security (It’s well known security practice to disable anything not used on a server)
Besides that IPv6 has been known for few criticil security vulnerabilities, which has historically affected the Linux kernel.
2. Performance (Sometimes disabling IPv6 could have positive impact on IPv4 especially on heavy traffic network servers).
I’ve red people claiming disabling IPv6 improves the DNS performance, however since this is not rumors and did not check it personally I cannot positively confirm this.

Disabling IPv6 on all GNU / Linuces can be achieved by changing the kernel sysctl settings net.ipv6.conf.all.disable_ipv6 by default net.ipv6.conf.all.disable_ipv6 equals 1 which means IPv6 is enabled, hence to disable IPv6 I issued:

server:~# sysctl net.ipv6.conf.all.disable_ipv6=0

To set it permanently on system boot I put the setting also in /etc/sysctl.conf :

server:~# echo 'net.ipv6.conf.all.disable = 1 >> /etc/sysctl.conf

The aforedescribed methods should be working on most Linux kernels version > 2.6.27 in that number it should work 100% on recent versions of Fedora, CentOS, Debian and Ubuntu.

To disable IPv6 protocol on Debian Lenny its necessery to blackist the ipv6 module in /etc/modprobe.d/blacklist by issuing:

echo 'blacklist ipv6' >> /etc/modprobe.d/blacklist

On Fedora / CentOS there is a another universal “Redhat” way disable IPv6.

On them disabling IPv6 is done by editting /etc/sysconfig/network and adding:

NETWORKING_IPV6=no
IPV6INIT=no

I would be happy to hear how people achieved disabling the IPv6, since on earlier and (various by distro) Linuxes the way to disable the IPv6 is probably different.
 

Alto to stop Iptables IPV6 on CentOS / Fedora and RHEL issue:

# service ip6tables stop

# service ip6tables off

Tracking graphically MySQL, Apache and Network performance in web with Munin on Debian Linux

Saturday, March 19th, 2011

munin_monitor_cpu_network_hard_drive_apache_mysql_performance-in-web-on-linux_logo

Munin is great software for surveillance software for your MySQL, Apache, Qmail, Postfix and many other of the classical daemon services which most of the Linux, BSD servers online are running on.

1. Munin on Debian Linux is really easy to be installed and comes to executing:

debian:~# apt-get install munin munin-node munin-plugins-extra

2. Link /var/www/munin/ to some VirtualHost or ServerHost
For instance if your munin is to be placed on the domain www.pc-freak.net.net which has the DocumentRoot of /var/www

debian:~# cd /var/www
debian:/var/www# ln -sf /var/www/munin munin

3. Add some extra MySQL related plugins

To check whole list of pmunin plugins you can enable check in /etc/munin/plugins directory

Lets say our Munin will be providing statistics mainly for MySQL, enable this bunch of plugins:

cd /etc/munin/plugins
ln -s /usr/share/munin/plugins/mysql_ mysql_
ln -s /usr/share/munin/plugins/mysql_bytes mysql_bytes
ln -s /usr/share/munin/plugins/mysql_innodb mysql_innodb
ln -s /usr/share/munin/plugins/mysql_isam_space_ mysql_isam_space_
ln -s /usr/share/munin/plugins/mysql_queries mysql_queries
ln -s /usr/share/munin/plugins/mysql_slowqueries mysql_slowqueries
ln -s /usr/share/munin/plugins/mysql_threads mysql_threads


Though above command would enable mysql monitoring it will be not working out of the box. You will find in munin logs error like:

Missing dependency Cache::Cache at /usr/share/munin/plugins/mysql_ line 716."

To fix this install libcache-perl and libcache-cache-perl

apt-get install --yes libcache-perl libcache-cache-perl
 

Then regenerate munin plugin configuration issue cmd:

munin-node-configure --suggest --shell | sh

and restart Munin-node server

service munin-node restart
 

Munin Node should be able login to the MySQL server using the Debian System Maintenance user however if you should need to create a custom user you can add the following configuration to:
 

/etc/munin/plugin-conf.d/munin-node

 

[mysql*]
    user root
    env.mysqluser muninmonitor
    env.mysqlpassword Your-Secret-Password

4. Edit Munin config

Make sure you have at least the following variables enabled in /etc/munin/munin.conf
 

 dbdir  /var/lib/munin
 htmldir /var/cache/munin/www
 logdir /var/log/munin
 rundir  /var/run/munin

 tmpldir    /etc/munin/templates

includedir /etc/munin/munin-conf.d

[localhost.localdomain]
    address 127.0.0.1
    use_node_name yes

 

5. Add Munin Alias or Virtualhost

To make Munin Accessible from Webserver you need to at least add an alias create a file
/etc/apache2/conf.d/munin with following content:

vim /etc/apache2/conf.d/munin

Alias /munin /var/cache/munin/www

<Directory /var/cache/munin/www>
        Order allow,deny
        #Allow from localhost 127.0.0.0/8 ::1
        Allow from all
        Options None
        php_value engine off

    <IfModule mod_expires.c>
        ExpiresActive On
        ExpiresDefault M310
    </IfModule>

</Directory>


If you want to access Munin from Apache subdomain create it lets say you want to access it via stats.www.pc-freak.net, use following config file:

vi /etc/apache2/sites-enabled/stats.www.pc-freak.net
 

<VirtualHost *>
   ServerAdmin hipo@www.pc-freak.net
   ServerName stats.www.pc-freak.net
   DocumentRoot /var/cache/munin/www
   <Directory />
       Options FollowSymLinks
       #AllowOverride All
       php_value engine off
   </Directory>
   LogLevel debug
   CustomLog /var/log/apache2/munin/access.log combined
   ErrorLog /var/log/apache2/munin/error.log
   ServerSignature On
<Directory /var/cache/munin/www>
        Order allow,deny
        #Allow from localhost 127.0.0.0/8 ::1
        Allow from all
        Options FollowSymlinks
        #AllowOverride All
        php_value engine off

</Directory>

</VirtualHost>

 


6. Restart Apache;

debian:~# /etc/init.d/apache2 restart

Now to access the newly installed munin point your favorite browser to (either the subdirectory configured for access or the Virtualhost subdomain):

https://www.pc-freak.net/munin/
or
http://munin.www.pc-freak.net

eth0-network-traffic-munin-server-statistics

connections_through_firewall-statistics-munin-debian-linux
7. Protecting Munin with a password

As it could be a security leak to expose statistics regarding your server (Disk I/O, Memory, Load Avarage, Apache, MySQL Postfix) operations it is good security practice to protect munin with a password.

I've earlied blogged on how to protect your server munin web-statistics wtih an htaccess password (read it here)


munin-cup-statistics-by-day-and-by-month-screenshot

Happy Monitoring

Client Denied By Server Configuration Linux Apache error solution

Thursday, August 1st, 2013

Client denied by server configuration fix solution Apache feather logo

If you run Apache server on Debian Linux / Ubuntu / CentOS whatever Linux OS and you try to install a new PHP application under lets say /var/www/ getting an error in Apache error.log like:
 

[Wed Jul 31 03:36:21 2013] [error] [client 192.168.10.2] client denied by server configuration: /var/www/vea/index.php, referer: http://192.168.10.9/vea/


This is due to misconfigured AllowOverrides in some of your main configuration files.

So what is causing the error?

Reason is by default in most current Linux distributions Apache is configured to have restrictive policy following the good security practice (Restrictive by default).
Apache is configured by default to not accept AllowOverrides – i.e. AllowOverride None for DocumentRoot /, because there are plenty of administrators who run Apache without having profound understanding leaving it to interpret by default mod_rewrite rules from .htaccess files etc.

To fix this issue, hence you have to add extra configuration for AllowOverride directive for directory giving the err. In this case /vea:

<Directory /var/www/vea/> 
Options -Indexes FollowSymLinks
AllowOverride AuthConfig
FileInfo Order allow,deny
Allow from all
</Directory> 

Above rules are a bit restrictive and will allow only to have .htaccess with only for protecting directory with htaccess passsword for exmpl. – (AuthUserFile, AuthGroupFile, AuthName, AuthType) .htaccess.
-Indexes – instructs /var/www/vea directory listing to be disabled, below two lines:

Order allow, deny
Allow from all

Makes the directory Allowed to be visible by all, however note that it is possible in some of other Apache configuration files to have other rules configured for /vea documentroot /var/www/ which are preventive (Default Deny) – if this is the case just walk through all Apache configs and change where necessary to Allow from all.

In some cases it is possible Web application or Website placed requires AllowOverride All directive instead. If above <Directory>

does not help and you continue to get:

[Wed Jul 31 03:36:21 2013] [error] [client xxx.xxx.xx.x] client denied by server configuration: /var/www/php-application/index.php, referer: http://xxx.xxx.xx.xx/php-application/  

Try setting Directory rules with AllowOverride All ;

<Directory /var/www/php-application/> 
Options -Indexes FollowSymLinks
AllowOverride All
FileInfo Order allow,deny
Allow from all
</Directory> 

Debian / Ubuntu server admins should check closely for AllowOverride rules in files /etc/apache2/conf.d/*

as well as in /etc/apache2/mods-available/*:

Usually there are AllowOverride rules set from files:

/etc/apache2/conf.d/apache2-doc
/etc/apache2/conf.d/localized-error-pages
/etc/apache2/conf.d/security

and also in

/etc/apache2/mods-available/alias.conf
/etc/apache2/mods-available/userdir.conf

On Debian GNU / Linux, very common reason for getting client denied by server configuration is AllowOverride definitions in /etc/apache2/conf.d/security, default AllowOverride there are set to None, i.e.:

<Directory />
AllowOverride None
Order Deny,Allow
Deny from all
</Directory>

If that's the case with you make sure you config rules to become:

# <Directory />
# AllowOverride None
# Order Deny,Allow
# Deny from all
# </Directory>

A very useful command to find where there is occurance of AllowOverride in Apache many configs is:

root@linux:~# cd /etc/apache2
root@linux:/etc/apache2# grep -rli AllowOverride *
apache2.conf
conf.d/localized-error-pages
conf.d/apache2-doc
conf.d/security
mods-available/userdir.conf
mods-available/alias.conf
sites-available/www.website1.com
sites-available/www.website2.com
...


 

Once you did all necessary config Restart Apache:

root@linux:~# /etc/init.d/apache2 restart
....