Empowering you with the knowledge to master Linux web hosting, DevOps and Cloud

 Linux Web Hosting, DevOps, and Cloud Solutions

Tag: nginx

Installing PHP GEOS module on a RunCloud Server

PHP GEOS is a PHP extension for geographic objects support, while RunCloud is a cloud server control panel designed for PHP applications. With PHP GEOS module installed on RunCloud, PHP applications can take advantage of geographic data and use the GEOS (Geometry Engine – Open Source) library to perform spatial operations.

In this blog post, I will show you how to install PHP GEOS module on RunCloud module.

Steps
1. Install the required development tools

Before installing the PHP GEOS module, make sure that the required development tools are installed on your Ubuntu server. You can install them by running the following command:

apt-get install autoconf

2. Install GEOS library
Next, download and install the latest GEOS (Geometry Engine – Open Source)

wget http://download.osgeo.org/geos/geos-3.9.4.tar.bz2
tar xvf geos-3.9.4.tar.bz2
cd geos-3.9.4/
./configure
make
make install

3. Install PHP GEOS module

Now, it’s time to install the PHP GEOS module. Follow the steps below to install it for PHP 8.2:

# Set module name
MODULE_NAME="geos"

Download the latest module files

git clone https://git.osgeo.org/gitea/geos/php-geos.git
mv php-geos/ php-geos_PHP82

# make clean will always fail if you never compile it before
make clean
/RunCloud/Packages/php82rc/bin/phpize --clean
/RunCloud/Packages/php82rc/bin/phpize
./configure --with-php-config=/RunCloud/Packages/php82rc/bin/php-config
make && make install

This will install geos.so in the correct php extension directory

4. Add the module to PHP.ini file
echo "extension=$MODULE_NAME.so" > /etc/php82rc/conf.d/$MODULE_NAME.ini

And finally restart the PHP FPM service
systemctl restart php82rc-fpm

It’s important to note that the above steps are specific to PHP 8.2. If you wish to install the module for a different version, you will need to modify the commands accordingly. For instance, you can replace PHP 8.2 with 8.1 with below changes:
Replace /RunCloud/Packages/php82rc/bin/phpize with /RunCloud/Packages/php81rc/bin/phpize, replace ./configure –with-php-config=/RunCloud/Packages/php82rc/bin/php-config with ./configure –with-php-config=/RunCloud/Packages/php81rc/bin/php-config, replace /etc/php82rc/conf.d/$MODULE_NAME.ini with /etc/php81rc/conf.d/$MODULE_NAME.ini, and replace systemctl restart php82rc-fpm with systemctl restart php81rc-fpm.

You can contact me if you need help with installing any custom modules on RunCloud control panel.

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

Install Ajenti V on Ubuntu 16.04 on Ubuntu 16.04

Install Ajenti v on Ubuntu 16.04

Ajenti is an open source, web-based control panel that can be used for a large variety of server management tasks. Optionally, an add-on package called Ajenti V allows you to manage multiple websites from the same control panel


Step 1: First make sure that all your system packages are up-to-date

sudo apt-get update
sudo apt-get upgrade

Step 2: Installing Ajenti Control Panel.
wget -O- https://raw.github.com/ajenti/ajenti/1.x/scripts/install-ubuntu.sh | sudo sh

Step 3: Start the service:
systemctl start ajenti

Step4: Install Agenti hosting module + nginx+ mail+ftp

If you have Apache installed, but don’t use it, remove it first:
apt-get remove apache2

If you have Sendmail or Postfix installed, remove them too
apt-get remove sendmail postfix

Install Ajenti-v

apt-get install ajenti-v ajenti-v-nginx ajenti-v-mysql ajenti-v-php7.0-fpm php7.0-mysql

# If you need Python
apt-get install ajenti-v-python-gunicorn

# If you want FTP
apt-get install ajenti-v-ftp-pureftpd

# If you want mail
apt-get install ajenti-v-mail

# If you want POP support (for gmail etc.)
apt-get install courier-pop

Step 5: Restart All Services
systemctl restart nginx
systemctl restart php7.0-fpm
systemctl restart mysql
systemctl restart exim4
systemctl restart pure-ftpd
systemctl restart ajenti

Step 6: Accessing Anjeti control panel.

Anjeti will be available on HTTP port 8000 by default. Open your favourite browser and navigate to http://yourdomain.com:8000 or http://server-ip:8000 and enter default username “admin” or “root” and password is “admin”.

Change the password immediately to something secure.

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.linuxwebhostingsupport.in
    service_description            url_check
    check_command                  check_http!-H linuxwebhostingsupport.in -t 30 -R "Cpanel and WHM" -f follow
}

The above will check for the keyword “Cpanel and WHM” on the page “linuxwebhostingsupport.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.linuxwebhostingsupport.in
    service_description            url_check
    check_command                  check_http!-H linuxwebhostingsupport.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.linuxwebhostingsupport.in
    service_description            url_check_protected
    check_command                  check_http!-H linuxwebhostingsupport.in -a user:password -t 30 -R "Cpanel and WHM" -f follow --ssl 
}

Replace the username and password appropriately.

Strong TLS/SSL Security on your server

SSL Report : www.linuxwebhostingsupport.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.

Powered by WordPress & Theme by Anders Norén