Posted on Leave a comment

Upgrade HAproxy to 2.1.3 – Red Hat Enterprise Linux server/Centos

I was struggling a couple of hours to upgrade HAproxy package to its latest version on a Red Hat Enterprise Linux server 7.6 and as I could not find a well documented page, I decided to create this article in order to explain the procedure.

The latest version that is available and supported from Red Hat for a Red Hat licensed server is 1.5.8. However we can upgrade the version by compiling the source code that is distributed online from the official page. HAproxy package is open source and its code is distributed so it can be built with make.

For the people that do not know HAproxy, it is a very widely known high performance tcp/http load balancer for Linux/Unix operating systems. More information can be also found on its page.

First things first haproxy-2.1.3.tar.gz must be downloaded and uploaded to the server.

In order to compile successfully and do not face hundred of errors during make you have to be sure that the below libraries are installed on your server. If a package from the below is missing you will get make errors.

  • gcc and all its dependencies
  • openssl and all its dependencies
  • systemd-devel
  • readline-devel

LUA is needed in order to make the package. Although LUA 5.1 was installed on the red hat server, during the compilation the variable could not be found so I had to manually install LUA latest version and also use its downloaded directory for the compilation of HAproxy.

Install LUA using the following commands. LUA directory may be needed

curl -R -O http://www.lua.org/ftp/lua-5.3.4.tar.gz
tar -zxf /root/lua-5.3.4.tar.gz
cd lua-5.3.4
make linux test
sudo make install

Finally make source code of HAproxy 2.1.3

make -j $(nproc) TARGET=linux-glibc USE_OPENSSL=1 USE_ZLIB=1 USE_LUA=1 USE_PCRE=1 USE_SYSTEMD=1 LUA_LIB=/root/lua-5.3.5/src/ LUA_INC=/root/lua-5.3.5/src/

sudo make install

Normally you should not get any error with the above commands. If so, then the version should be the upgraded. As a last step, reboot the server and then you will get the updated version.

Posted on 1 Comment

The ultimate Guide of Security – Infrastructure Web application Hardening

This guide is written in order to help the IT Security Administrators secure their Infrastructure (VM in the cloud or something equivalent) that host web applications. It encloses knowledge that has been gained from multiple penetrations test from different vendors in projects that I have participated. It cannot protect you 100% but is a good and detailed way to start your security hardening.

Table of contents:

  • OS patching
  • Strong passwords and permissions
  • SSL Certificate
  • Install fail2ban
  • Set up firewall
  • Limit ssh access
  • PHP Hardening
  • Apache Hardening

OS patching:
Keep always your OS ( Red Hat Linux or equivalent) up to date with the latest security updates and patches. As a result before starting your installations perform an OS update. It is very important also to keep your Apache and PHP packages patched.

Strong passwords and permissions:
Create strong passwords for your users and add users with separate directories and permissions. Each user should have its own directory to manipulate files and should not have root access. For example if user X should be the application owner, then he should have permissions only to write/upload files in /var/www/application folder and no root permissions.

SSL Certificate:
Install a valid SSL Certificate and redirect all http traffic to https. You can view my blog post on how to install your apache SSL certificate from here. Redirection can be implemented by adding the appropriate rule in your .htaccess file.

Install fail2ban:
Fail2Ban scans log files like /var/log/auth.log and bans IP addresses conducting too many failed login attempts. You can find it from Github and configure it appropriately.

Set up firewall:
You should consider enabling a firewall for your infrastructure like Cloudflare that enables WAF/DDOS protection actions. You could also enable the build in Linux firewall and set up rules through iptables.

Limit ssh access:
Limit IP addresses that could access your infrastructure server. You could do that by disabling all from /etc/hosts.deny and allow only the IP addresses that you will use in /etc/hosts.allow . As a result you should

/etc/hosts.deny:
sshd : ALL

/etc/hosts.allow:
sshd : YOUR_IPS/24

PHP Hardening:
open_basedir, if set, limits all file operations to the defined directory and below. When a script tries to access the filesystem for example using fsockopen() the location of the file is checked. If the file is outside the defined directory PHP will refuse access.
Set openbasedir to your site directory. For example if your web application is a drupal installed in the directory /var/www/drupal then your openbasedir should be set to include your app directory and every other directory that you want (see below example).

open_basedir = "/home/X/:/var/www/drupal/:/tmp/"

Also you should consider disabling some php functions for security reasons like the below.

disable_functions = phpinfo,exec,shell_exec,passthru,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source,proc_close,symlink,apache_getenv,apache_get_modules,apache_get_version,apache_lookup_uri,apache_note,apache_request_headers,apache_reset_timeout,apache_response_headers,apache_setenv,closelog,curl_exec,curl_multi_exec,debugger_off,debugger_on,define_syslog_var,define_syslog_variables,diskfreespace,disk_free_space,dl,escapeshellarg,escapeshellcmd,exec,ftok,ftp_connect,ftp_exec,ftp_get,ftp_login,ftp_nb_fput,ftp_put,ftp_raw,ftp_rawlist,getmypid,getmyuid,highlight_file,ignore_user_abord,ini_alter,ini_get_all,ini_restore,leak,limit,link,listen,mysql_list_dbs,openlog,parse_ini_file,passthru,pclose,pcntl_exec,pg_host,php_uname,popen,posix_access,posix_ctermid,posix_getcwd,posix_getegid,posix_geteuid,posix_getgid,posix_getgrgid,posix_getgrnam,posix_getgroups,posix_getlogin,posix_getpgid,posix_getpgrp,posix_getpid,posix_getpwnam,posix_getpwuid,posix_getrlimit,posix_getsid,posix_getuid,posix_isatty,posix_kill,posix_mkfifo,posix_mknod,posix_setegid,posix_seteuid,posix_setgid,posix_setp,posix_setpgid,posix_setsid,posix_setuid,posix_times,posix_ttyname,posix_uname,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,readfile,readlink,safe_dir,satty,scandir,set_time,set_time_limit,shell_exec,show_source,socket_accept,socket_bind,socket_clear_error,socket_close,socket_connect,source,symlink,syslog,system,tmpfile,virtual

Disable allow_url_include and allow_url_fopen

allow_url_fopen=Off
allow_url_include=Off

The previous described actions should be applied on /etc/php.ini file.

Some of them may disable your web application behavior so you should check if you need them.

Apache Hardening:


Disable content or MIME sniffing:

Header set X-Content-Type-Options: "nosniff"

Defense from Clickjacking attack:

Header set X-Frame-Options: "sameorigin"

Set Strict-Transport-Security header settings configured for a timespan of 2 years:

Header set Strict-Transport-Security "max-age=63072000; includeSubDomains;"

Add X-XSS-Protection header to prevent some level of XSS:

Header set X-XSS-Protection "1; mode=block"

Add Referrer-Policy header to your webserver:

Header always set Referrer-Policy "same-origin"

Deny TRACE/TRACK requests:

RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]

Hide Apache Information:

ServerSignature Off
ServerTokens Prod

Of course there are a lot more things that could be applied for your infrastructure hardening per case. The system Administrator should always be up to date with the security standards and discoveries in order to eliminate risks from malicious unauthorized access.