Linux web hosting and server support tips

Tag: Apache

Password protect phpMyAdmin through CentOS Web panel(CWP)

phpMyAdmin is installed with CentOS Web Panel. By default, it is not protected and there is only MySQL user authentication. This can put your server vulnerable. So it is recommended to add additional layer protection.

phpMyAdmin is available through the following url in a CWP based server.

http:/hostname/phpmyadmin
http:/hostname:2030/pma

CWP panel runs its core services through its own version of Nginx. So normal htaccess based password protection will not work.

Create the Password File

You can do this by using the OpenSSL utilities that may already be available on your server. Alternatively, you can use the purpose-made htpasswd utility included in the apache2-utils package(Debian/ubuntu) or httpd-tools(Redhat/Centos).

Using OpenSSL Utilities

We will create a hidden file called .pma_pass /usr/local/cwpsrv/var/services/ folder. You can use any username. I am using dbadmin here as an example

sudo sh -c "echo -n 'dbadmin:' >> /usr/local/cwpsrv/var/services/.pma_pass"

Next, add an encrypted password entry for the username by typing:

sudo sh -c "openssl passwd -apr1 >> /usr/local/cwpsrv/var/services/.pma_pass"

Using Apache Utilities

This tool is already installed and available on all CWP servers.

/usr/local/apache/bin/htpasswd -c /usr/local/cwpsrv/var/services/.pma_pass dbadmin

Configure Nginx Password Authentication

We will need to configure Nginx to read this file before serving our protected content.
CWP Service Nginx configuration file: /usr/local/cwpsrv/conf/cwp_services.conf

Open the above file add the following to the location block of phpMyAdmin.

auth_basic “Admin Login”;
auth_basic_user_file /usr/local/cwpsrv/var/services/pma_pass;

So the full block should look like this now.

location /pma {
    root /usr/local/cwpsrv/var/services;
    index  index.html index.htm index.php;
    ModSecurityEnabled off;
    ModSecurityConfig /usr/local/cwpsrv/conf/security/conf/pma_rules.conf;

    location ~ \.php$ {
        try_files $uri =404;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_read_timeout 600;
        fastcgi_pass    unix:/usr/local/cwp/php71/var/sockets/cwpsvc.sock;
        fastcgi_index   index.php;
        fastcgi_param   SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        fastcgi_param   SCRIPT_NAME   $fastcgi_script_name;
        include                 fastcgi_params;
    }

    location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
        access_log    off;
        log_not_found    off;
        expires 1M;
    }

       auth_basic "Admin Login";
       auth_basic_user_file /usr/local/cwpsrv/var/services/.pma_pass;
}

Restart CWP nginx service by below commands

systemctl restart cwpsrv.service

Confirm the Password Authentication

To confirm that your content is protected, try to access your restricted content in a web browser. You should be presented with a username and password prompt

How To Install PHP 7 On A cPanel/WHM Server With EasyApache 3

How To Install PHP 7 On A cPanel/WHM Server With EasyApache 3

Latest versions of cPanel come with EasyApache 4 which provides lots of new features like native support for multiple PHP versions, PHP 7 support, very fast, etc. So it is recommended to migrate to EasyApache 4. However, if you cannot migrate EasyApache 4 because of some reason (Example: Tomcat support), you will have to compile the PHP 7 manually from source.

To migrate to EasyApache for, just run the below command. cPanel will try to build a matching PHP setup using EasyApache 4.

/scripts/migrate_ea3_to_ea4 --run

If anything goes wrong during the upgrade process you can always go back with /scripts/migrate_ea3_to_ea4 –revert –run

Manually install PHP 7

Following steps are tested with cPanel 11.64.0.36 and CentOS 6.9 64 bit. The PHP handler should be suphp to get this working.

cd /usr/local/src/
wget http://php.net/distributions/php-7.0.22.tar.gz #Go to php.net site to find the latest version
tar xvf php-7.0.22.tar.gz

Build it.

 #./configure  --enable-bcmath --enable-calendar --enable-exif --enable-ftp --enable-gd-native-ttf --enable-libxml --enable-mbstring --enable-pdo=shared --enable-sockets --enable-zip --prefix=/usr/local/php70  --with-curl=/opt/curlssl/ --with-freetype-dir=/usr --with-gd --with-gettext --with-imap=/opt/php_with_imap_client/ --with-imap-ssl=/usr --with-jpeg-dir=/usr --with-kerberos --with-libdir=lib64 --with-libxml-dir=/opt/xml2/ --with-mcrypt=/opt/libmcrypt/ --with-mysqli --with-openssl=/usr --with-openssl-dir=/usr --with-pcre-regex=/opt/pcre --with-pdo-mysql=shared --with-pdo-sqlite=shared --with-pic --with-png-dir=/usr --with-xpm-dir=/usr --with-zlib --with-zlib-dir=/usr

You may add any additional parameters required. You can run ./configure --help to see all available options first.
Important: Do not forget to set the "--prefix=/usr/local/php70". Otherwise, your existing PHP installation will be lost.

 make
 make install

If everything is successful, the PHP binaries will be installed in "/usr/local/php70/bin/" directory.

Copy the default php.ini:

 cp -pr /usr/local/src/php-7.0.22/php.ini-production /usr/local/php70/lib/php.ini

Add pdo,opcache, other modules to php.ini file.

 echo "extension=pdo.so" >> /usr/local/php70/lib/php.ini
 echo "extension=pdo_mysql.so" >> /usr/local/php70/lib/php.ini
 echo "zend_extension=opcache.so" >> /usr/local/php70/lib/php.ini

Verify the installation

/usr/local/php70/bin/php -v
PHP 7.0.22 (cli) (built: Aug 5 2017 01:56:23) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
with Zend OPcache v7.0.22, Copyright (c) 1999-2017, by Zend Technologies

Now link our new PHP 7 installation with Apache web server

Generate the PHP config:

cat >  /usr/local/apache/conf/php70.conf << EOF
AddType application/x-httpd-php7 .php7 .php

    suPHP_AddHandler application/x-httpd-php7

EOF

Add new handler to suphp

Edit the /opt/suphp/etc/suphp.conf and add below code, at the end of the handlers list to enable PHP7 handler.

;Handler for php-scripts
#... existing handlers are here ... put yours below them
application/x-httpd-php7="php:/usr/local/php70/bin/php-cgi"

Now add our custom php config file to EasyApache list so that the changes will not be lost future EasyApache builds.

There are two options here. You can either go into WHM and edit the post_virtualhost_global.conf file from there or you just run: vi /usr/local/apache/conf/includes/post_virtualhost_global.conf. Add the line below in that file and you should be all done.

Include /usr/local/apache/conf/php70.conf

Now restart Apache

service httpd restart

Configure a website To Use This new PHP 7
Add following code to .htaccess file(/home/username/public_html/.htaccess)

AddType application/x-httpd-php7 .php7 .php

URL Monitoring With Nagios

Capabilities

Nagios provides complete URL monitoring of HTTP and HTTPS servers and protocols as well as full URL transaction monitoring.

Benefits

Implementing effective URL monitoring with Nagios offers the following benefits:
* Increased server, services, and application availability
* Fast detection of network outages and protocol failures
* Monitor user experience when accessing URLs
* Web server performance monitoring
* Web transaction monitoring
* URL monitoring

URL monitoring

By using the ‘check_http’ nagios command, we can monitor a specific url rather than checking the Apache service is up or not. This method is helpful to identify if the website is hacked and url is injected with malicious codes or there is some Apache or php errors and page is throwing an error instead. The normal Apache service check will return successful results in the above case.
We can check for a specific keyword string on the webpage. If that string not present, an error will be returned.

Here is an real example

define service{
    use                            urlmonitoring-service
    host_name                      server.linuxwebservertips.in
    service_description            url_check
    check_command                  check_http!-H linuxwebservertips.in -t 30 -R "Cpanel and WHM" -f follow
}

The above will check for the keyword “Cpanel and WHM” on the page “linuxwebservertips.in”. If the keyword is missing or the page is not responding nagios will retun and error.

URL monitoring +SSL

You can refer to below example if the web page has SSL/TLS enabled.

define service{
    use                            urlmonitoring-service
    host_name                      server.linuxwebservertips.in
    service_description            url_check
    check_command                  check_http!-H linuxwebservertips.in -t 30 -R "Cpanel and WHM" -f follow --ssl
}

Here we added the option “–ssl” to the check command

URL monitoring on ht password protected page

Normal method will not work as we need to validate ht password protection first to see the page. You can use the following example for such pages.

define service{
    use                            urlmonitoring-service
    host_name                      server.linuxwebservertips.in
    service_description            url_check_protected
    check_command                  check_http!-H linuxwebservertips.in -a user:password -t 30 -R "Cpanel and WHM" -f follow --ssl 
}

Replace the username and password appropriately.

CSR generation for UCC certificates

Unified Communications (UC) Certificates (also called SAN Certificates) use Subject Alternative Names o secure multiple sites (e.g. fully qualified domain names) with one certificate. Four SANs are included in the base price of the UC Certificate, but you can purchase additional names at any time during the lifetime of the certificate.

With a UC Certificate, you can secure:

www.linuxwebservertips.in
www.example2.com
www.example3.net
mail.example.net
dev.example2.com

The CSR generation process is little different for creating an UCC certificates. We will have to create a Openssl based configuration file and then create private key and CSR from it.

Step 1: Create a custom OpenSSL Conf file.

The following is an example conf file that can be used for creation of a SAN/UCC cert. Save it as multissl.conf

———–
[ req ]
default_bits = 2048
default_keyfile = privkey.pem
distinguished_name = req_distinguished_name
req_extensions = req_ext # The extentions to add to the self signed cert

[ req_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = US
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = Iowa
localityName = Locality Name (eg, city)
localityName_default = Iowa City
organizationName = Organization Name (eg, company)
organizationName_default = The University of Iowa
organizationalUnitName = Organizational Unit Name (eg, section)
organizationalUnitName_default = Domain Control Validated
commonName = Common Name (eg, YOUR SSL domain name)
commonName_max = 64

[ req_ext ]
subjectAltName = @alt_names

[alt_names]
DNS.1 = www.linuxwebservertips.in
DNS.2 = www.example1.com
DNS.3 = example2.com
———–

Notes:

The alt_names section (DNS.1, DNS.2, ….) are the list of all other domain names you wish to secure with this cert. Additional can be added such as DNS.4, etc.
The following examples assume that you name the above config file file multissl.conf (if it is named differently you must adjust the filename in the below examples accordingly.
Step 2: Generate the Private key and CSR with OpenSSL

Execute the following OpenSSL command

$ openssl req -nodes -newkey rsa:2048 -keyout serverfqdn.key -out multidomain.csr -config multissl.conf

* Replace “serverfqdn” with the fully qualified domain name of the server (ie: sample.server.uiowa.edu). Note: it may also be helpful to add a year to the filename.

You will then see output and be prompted for configuration as seen in the following example. Enter your details accordingly.

——————————————
$ openssl req -nodes -newkey rsa:2048 -keyout serverfqdn.key -out multidomain.csr -config multissl.conf
Generating a 2048 bit RSA private key
………………………………….+++
…………………………………………………………+++
writing new private key to ‘serverfqdn.key’
—–
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.’, the field will be left blank.
—–
Country Name (2 letter code) [US]:US
State or Province Name (full name) [Iowa]:Iowa
Locality Name (eg, city) [Iowa City]:Iowa City
Organization Name (eg, company) [The University of Iowa]:My Company name
Organizational Unit Name (eg, section) [Domain Control Validated]:IT SUPPORT
Common Name (eg, YOUR SSL domain name) []:www.linuxwebservertips.in
——————————————

Note: Replace www.linuxwebservertips.in with the “primary” domain name you want secured with this certificate (likely, but not necessarily the hostname of the machine).

At this point you should have the new key file, and CSR. Save the key file in a secure place, it will be needed to apply the new certificate. The CSR can now be submitted to request the SSL Cert.

Strong TLS/SSL Security on your server

SSL Report : www.linuxwebservertips.in

ssllab

 

 

 

 

This is a simple guide for setting up a strong TLS/SSL configuration on your server.

If you configure a web server’s TLS configuration, you have primarily to take care of three things:

1. disable SSL 2.0 (FUBAR) and SSL 3.01 (POODLE),
2. disable TLS 1.0 compression (CRIME),
3. disable weak ciphers (DES, RC4), prefer modern ciphers (AES), modes (GCM), and protocols (TLS 1.2).

 

Your Server’s Certificate

Let’s start with your digital certificate, which is at the core of HTTPS. The certificate enables clients to verify the identity of servers, through a chain of trust from your server’s certificate through intermediate certificates and up to a root certificate trusted by users’ browsers. Your server certificate should be 2048 bits in length. Using 4096 bit certificate is more secure however it require more computation times and hence slow compared to 2048 bit certs.

 

Basic HTTPS Setup

Here are basic SSL configurations, first for Apache:

;
...
SSLEngine on
SSLCertificateFile /etc/ssl/certs/your_cert
SSLCertificateChainFile /etc/ssl/certs/chained_certs
SSLCertificateKeyFile /etc/ssl/certs/your_private_key
<;/VirtualHost>;

And then for Nginx:

server {
...
ssl on;
ssl_certificate /etc/ssl/certs/your_cert_with_chain;
ssl_certificate_key /etc/ssl/certs/your_private_key;
ssl_session_cache shared:SSL:50m;
ssl_session_timeout 10m;
}

In Nginx, the ssl_certificate parameter is confusing. It expects your certificate plus any necessary intermediate certificates, concatenated together.

Make sure all of these files are at least mode 0444, except your private key, which should be 0400.

 

Software versions

On the server side you should update your OpenSSL to 1.0.1c+ so you can support TLS 1.2, GCM, and ECDHE as soon as possible. Fortunately that’s already the case in Ubuntu 12.04 and later.

On the client side the browser vendors are starting to catch up. As of now, Chrome 30, Internet Explorer 11 on Windows 8, Safari 7 on OS X 10.9, and Firefox 26 all support TLS 1.2.

 

Cipher Suite Configuration

The recommended cipher suites for Apache are follows

SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
SSLHonorCipherOrder on

The recommended cipher suite for backwards compatibility (IE6/WinXP):

SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4
SSLHonorCipherOrder on

 

And here’s the same configuration for Nginx:

ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
ssl_prefer_server_ciphers on;

The recommended cipher suite for backwards compatibility (IE6/WinXP):

ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
ssl_prefer_server_ciphers on;

If your version of OpenSSL is old, unavailable ciphers will be discarded automatically. Always use the full ciphersuite above and let OpenSSL pick the ones it supports.

The ordering of a ciphersuite is very important because it decides which algorithms are going to be selected in priority. The recommendation above prioritizes algorithms that provide perfect forward secrecy.

 

Prioritization logic

ECDHE+AESGCM ciphers are selected first. These are TLS 1.2 ciphers and not widely supported at the moment. No known attack currently target these ciphers.
PFS ciphersuites are preferred, with ECDHE first, then DHE.
AES 128 is preferred to AES 256.  At the moment, AES128 is preferred, because it provides good security, is really fast, and seems to be more resistant to timing attacks.
In the backward compatible ciphersuite, AES is preferred to 3DES. BEAST attacks on AES are mitigated in TLS 1.1 and above, and difficult to achieve in TLS 1.0. In the non-backward compatible ciphersuite, 3DES is not present.
RC4 is removed entirely. 3DES is used for backward compatibility

 

Protocol Support: SSL or no SSL

To prevent downgrade attacks and poodle attack, we will also disable old SSL protocols

For Apache:

SSLProtocol all -SSLv2 -SSLv3

For Nginx:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

This disables all versions of SSL, enabling only TLS 1.0 and up. All versions of Chrome and Firefox support at least TLS 1.0.

Apache: Multiple SSL websites on a single IP address

Apache: Multiple SSL websites on a single IP address

Update: This is a new update from a cPanel Tech
“There is nothing to enable. As long as you are using cPanel & WHM version 11.38 on CentOS, RHEL, or CloudLinux version 6 or newer, SNI works out of the box”.

One of the frustrating limitations in supporting secure websites has been the inability to share IP addresses among SSL websites.
When website administrators and IT personnel are restricted to use a single SSL Certificate per socket (combination of IP Address and socket) it can cost a lot of money. Well we can actually share IP addresses for multiple secure websites. Solving this limitation required an extension to the Transport Layer Security (TLS) protocol that includes the addition of what hostname a client is connecting to when a handshake is initiated with a web server. The name of the extension is Server Name Indication (SNI). SNI is supported in Apache v2.2.12 , and OpenSSL v0.9.8j or later.

With SNI, you can have many virtual hosts sharing the same IP address and port, and each one can have its own unique certificate

Prerequisites to use SNI

Use OpenSSL 0.9.8f or later
Build OpenSSL with the TLS Extensions option enabled (option enable-tlsext; OpenSSL 0.9.8k and later has this enabled by default).
Apache must have been built with that OpenSSL (./configure –with-ssl=/path/to/your/openssl). In that case, mod_ssl will automatically detect the availability of the TLS extensions and support SNI.
Apache must use that OpenSSL at run-time, which might require setting LD_LIBRARY_PATH or equivalent to point to that OpenSSL, maybe in bin/envvars. (You’ll get unresolved symbol errors at Apache startup if Apache was built with SNI but isn’t finding the right openssl libraries at run-time.)

Setting up SNI with Apache

The configuration is pretty simple and straight forward, though I recommend making a backup of your existing httpd.conf file before proceeding.

# Ensure that Apache listens on port 443
Listen 443

# Listen for virtual host requests on all IP addresses
NameVirtualHost *:443

# Go ahead and accept connections for these vhosts
# from non-SNI clients
SSLStrictSNIVHostCheck off

# Because this virtual host is defined first, it will
# be used as the default if the hostname is not received
# in the SSL handshake, e.g. if the browser doesn't support
# SNI.
DocumentRoot /www/example2
ServerName www.linuxwebservertips.in

# Other directives here
SSLEngine On
SSLCertificateFile /path/to/linuxwebservertips.in.crt
SSLCertificateKeyFile /path/to/linuxwebservertips.in.key
SSLCertificateChainFile /path/to/CA.crt

DocumentRoot /www/example2
ServerName www.abdulwahabmp.co.in

# Other directives here
SSLEngine On
SSLCertificateFile /path/to/abdulwahabmp.co.in.crt
SSLCertificateKeyFile /path/to/abdulwahabmp.co.in.key
SSLCertificateChainFile /path/to/CA.crt

 

That it!!!. Just restart APache service. Now go and check your Websites using https. That should be working.

Plesk support SNI from 10.2.x version onwards.

SNI will work on following Operating systems out of box

OpenSuSE Linux 11.3 or later.
Ubuntu Linux 10.4 or later.
Debian Linux 6.0 or later.
RedHat Linux 6.0 or later.
CentOS Linux 60.0 or later

Supported Desktop Browsers
Internet Explorer 7 and later
Firefox 2 and later
Opera 8 with TLS 1.1 enabled
Google Chrome:
Supported on Windows XP on Chrome 6 and later
Supported on Vista and later by default
OS X 10.5.7 in Chrome Version 5.0.342.0 and later
Chromium 11.0.696.28 and later
Safari 2.1 and later (requires OS X 10.5.6 and later or Windows Vista and later).
Note: No versions of Internet Explorer on Windows XP support SNI

 

Powered by WordPress & Theme by Anders Norén