Posts Tagged ‘web server’

What is Vertical scaling and Horizontal scaling – Vertical and Horizontal hardware / services scaling

Friday, June 13th, 2014

horizontal-vs-vertical-scaling-vertical-and-horizontal-scaling-explained-diagram

If you're coming from a small or middle-sized company to a corporations like HP or IBM probably you will not a clear defined idea on the 2 types (2 dimensions) of system Scaling (Horizontal and Vertical scaling). I know from my pesronal experience that in small companies – all needed is to guarantee a model for as less probels as possible without too much of defining things and with much less planning. Other thing is being a sysadmin in middle-sized companies, often doesn't give you opportunity to discuss issues to solve with other admins but you have to deal as "one man (machine) for all" and thus often to solve office server and services tasks you do some custom solution.
hence for novice system administrators probably it will be probably unclear what is the difference between Horizontal and Vertical Scaling?

horizontal-vertical-scaling-scale-up-and-scale-out-server-infrastructure-diagram

 

Vertical Scaling (scale vertically or scale up) :- adding more resources(CPU/RAM/DISK) to your server (database or application server is still remains one).
Vertical Scaling is much more used in small and middle-sized companies and in applications and products of middle-range. Very common example for Virtual Scaling nowdays is to buy an expensive hardware and use it as a Virtual Machine hypervisor (VMWare ESX). Where a database is involved using Vertical Scaling without use of multiple virtual machines might be not the best solution, as even though hardware might suffice (creation of database locks might impose problems). Reasons to scale vertically include increasing IOPS (Input / Ouput Operations), increasing CPU/RAM capacity, and increasing disk capacity.
Because Vertical Scaling usually means upgrade of server hardware – whenever an improved performance is targeted, even though if Virtualization is used, the risk for downtimes with it is much higher than whenever horizontal scaling.

Horizontal Scaling (scale horizontally or scale out):- adding more processing units (phyiscal machine) to your server (infrastructure be it application web/server or database).
Horizontal scaling, means increasing  the number of nodes in the cluster, reduces the responsibilities of each member node by spreading the keyspace wider and providing additional end-points for client connections. The capacity of each individual node does not change, but its load is decreased (because load is distributed between separate server nodes). Reasons to scale horizontally include increasing I/O concurrency, reducing the load on existing nodes, and increasing disk capacity.
Horizontal Scaling has been historically much more used for high level of computing and for application and services. The Internet and particular web services gave a boom of Horizontal Scaling use, most companies nowadays that provide well known web services like Google (Gmail, Youtube), Yahoo, Facebook, Ebay, Amazon etc. are using heavily horizontal scaling. Horizontal Scaling is a must use technology – whenever a high availability of (server) services are required.

PHP: Better Webhosting Security – Disable exec(), exec_shell(), system(), popen(), eval() … shell fork functions

Sunday, June 23rd, 2013

increase php security better php security by disabling fork shell system and eval functions

If you work as System Administrator of WebHosting company, you definitely know how often it is that some automated cracker scripts (working as worms) intrude through buggy old crappy custom coded sites or unupdated obsolete Joomla / WordPress etc. installs. and run themselves trying to harvest for other vulnerable hosts. By default PHP enables running commands via shell with PHP functions like exec();, shell_exec(); , system();. and those script kiddie scripts use mainly this functions to spawn shell via vulnerable PHP app. Then scripts use whether php curl support is installed (i.e. php5-curl) to download and replicate itself to next vulnerable hop.

With that said it is a must after installing new Linux based server for hosting to disable this functions, to save yourself from future hassles …
Earlier, I blogged how to disable PHP system system(); and exec(); functions to raise Apache security using suhosin however this method requires php suhosin being used.

Yesterday, I had to configure new web hosting server with Debian 7, so I tried installing suhosin to use it to protect PHP from having enabled dangerous system();, eval(); exec(); .
I remember disabling system(); using suhosin php extension was working fine on older Debian releases, however in Debian 6.0, php5-suhosin package was causing severe Apache crashes and probably that's why in latest Debian Wheezy 7.0, php suhosin extension is no longer available. Therefore using suhosin method to disable system();, exec(); and other fork functions is no longer possible in Debian.

Since, suhosin is no longer there, I decided to use conventional PHP method via php.ini.

Here is how to do it

Edit:

/etc/php5/apache2/php.ini

debian:~# vim /etc/php5/apache2/php.ini
And near end of file placed:

disable_functions =exec,passthru,shell_exec,system,proc_open,
popen,curl_exec, curl_multi_exec,parse_ini_file,show_source

allow_url_fopen Off
allow_url_include Off

It is good to explain few of above functions – shell_exec, proc_open, popen, allow_url_fopen,show_source  and allow_url_include.

Disabling shell_exec – disables from PHP scripts executing commands with bash slash ` `, i.e. `ls`. proc_open and popen allows reading files from file system.

show_source – makes possible also reading other PHP source files or can be used to display content of other files from fs.

To read newly placed config vars in php.ini usual apache restart is necessary:

debian:~# /etc/init.d/apache2 restart
[….] Restarting web server: apache2
. ok

Further on tо test whether system();, exec();, passthru(); … etc. are disabled. Make new PHP file with content:

<?php
error_reporting(E_ALL);
$disabled_functions = ini_get('disable_functions');
if ($disabled_functions!='')
{
    $arr = explode(',', $disabled_functions);
    sort($arr);
    echo 'Disabled Functions:
        ';
    for ($i=0; $i<count($arr); $i++)
    {
        echo $i.' - '.$arr[$i].'<br />';
    }
}
else
{
    echo 'No functions disabled';
}
?>

php show disabled functions screenshot improve php security by disabling shell spawn functions

Copy of above source code show_disabled_php_functions.php is here for download
. To test your Apache PHP configuration disabled functions download it with wget or curl and rename it to .php:

# cd /var/www # wget -q http://www.pc-freak.net/files/show_disabled_php_functions.php.txt
mv show_disabled_php_functions.php.txt show_disabled_php_functions.php

After disabling functions on those newly setup Debian hosting Apache webserver, I remembered, same functions were still active on another CentOS Linux server.

To disable it there as well, had to edit:

/etc/php.ini

[root@centos:~]# vim /etc/php.ini

And again place after last file line;

disable_functions =exec,passthru,shell_exec,system,proc_open,popen,
curl_exec, curl_multi_exec,parse_ini_file,show_source

allow_url_fopen Off
allow_url_include Off

Finally on CentOS host, had to restart Apache:

[root@centos:~]# /etc/init.d/httpd restart

For Security paranoids, there are plenty of other PHP functions to disable including, basic functions like ln, mv, mkdir, cp, cat etc.

Below is list of all functions to disable – only disable this whether you you're a PHP security freak and you're 100% some server hosted website will not use it:

disable_functions = "ln, cat, popen, pclose, posix_getpwuid, posix_getgrgid, posix_kill, parse_perms, system, dl, passthru, exec, shell_exec, popen, proc_close, proc_get_status, proc_nice, proc_open, escapeshellcmd, escapeshellarg, show_source, posix_mkfifo, mysql_list_dbs, get_current_user, getmyuid, pconnect, link, symlink, pcntl_exec, ini_alter, pfsockopen, leak, apache_child_terminate, posix_kill, posix_setpgid, posix_setsid, posix_setuid, proc_terminate, syslog, fpassthru, stream_select, socket_select, socket_create, socket_create_listen, socket_create_pair, socket_listen, socket_accept, socket_bind, socket_strerror, pcntl_fork, pcntl_signal, pcntl_waitpid, pcntl_wexitstatus, pcntl_wifexited, pcntl_wifsignaled, pcntl_wifstopped, pcntl_wstopsig, pcntl_wtermsig, openlog, apache_get_modules, apache_get_version, apache_getenv, apache_note, apache_setenv, virtual, chmod, file_upload, delete, deleted, edit, fwrite, cmd, rename, unlink, mkdir, mv, touch, cp, cd, pico"

How to disable nginx static requests access.log logging

Monday, March 5th, 2012

NGINX logo Static Content Serving Stop logging

One of the companies, where I'm employed runs nginx as a CDN (Content Delivery Network) server.
Actually nginx, today has become like a standard for delivering tremendous amounts of static content to clients.
The nginx, server load has recently increased with the number of requests, we have much more site visitors now.
Just recently I've noticed the log files are growing to enormous sizes and in reality this log files are not used at all.
As I've used disabling of web server logging as a way to improve Apache server performance in past time, I thought of implying the same little "trick" to improve the hardware utilization on the nginx server as well.

To disable logging, I proceeded and edit the /usr/local/nginx/conf/nginx.conf file, commenting inside every occurance of:

access_log /usr/local/nginx/logs/access.log main;

to

#access_log /usr/local/nginx/logs/access.log main;

Next, to load the new nginx.conf settings I did a restart:

nginx:~# killall -9 nginx; sleep 1; /etc/init.d/nginx start

I expected, this should be enough to disable completely access.log, browser request logins. Unfortunately /usr/local/nginx/logs/access.log was still displaying growing with:

nginx:~# tail -f /usr/local/nginx/logs/access.log

After a bit thorough reading of nginx.conf config rules, I've noticed there is a config directive:

access_log off;

Therefore to succesfully disable logging I had to edit config occurance of:

access_log /usr/local/nginx/logs/access.log main

to

After a bit thorough reading of nginx.conf config rules, I've noticed there is a config directive:

access_log off;

Therefore to succesfully disable logging I had to edit config occurance of:

access_log /usr/local/nginx/logs/access.log main

to

access_log /usr/local/nginx/logs/access.log main
access_log off;

Finally to load the new settings, which thanksfully this time worked, I did nginx restart:

nginx:~# killall -9 nginx; sleep 1; /etc/init.d/nginx start

And hooray! Thanks God, now nginx logging is disabled!

As a result, as expected the load avarage on the server reduced a bit 🙂