Archiwa Proxy - soban

Proxy through nginx frontend to the second virtual server wordpress

soban — Sun, 07 Nov 2021 11:48:33 +0000

In a situation where we have one public IP address and we have many domains directed to that IP address, it is worth considering spreading the traffic to other servers. Proxmox, which allows you to create a pair of virtual machines, is perfect in such a situation. In my case, each virtual machine is separated and the traffic is broken down by nginx, which distributes the traffic to other servers. The virtual machine on my website will redirect traffic, I have the IP address for wordpress: 10.10.11.105 on port 80. In this case, no encryption is required, but the frontend itself, which manages the traffic, will present itself with encryption and security on port 443.

Two machines with the following configuration will participate throughout the process:
up-page IP: 10.10.14.200
soban-pl IP: 10.10.11.105

So let’s move on to the frontend that distributes traffic to other machines.
The frontend is done by linux debian 11 (bullseye), in addition, I have the following entry in the repository (/etc/apt/sources.list):

#...
deb http://nginx.org/packages/debian/ bullseye nginx
deb-src http://nginx.org/packages/debian/ bullseye nginx

To install nginx, run the following commands:

# apt update
# apt install nginx

You should make sure that the traffic from the frontend has the appropriate port 80 transitions. You can read how to check the network transitions here: Check network connection and open TCP port via netcat.

The configuration of the frontend that distributes the traffic is as follows (/etc/nginx/conf.d/soban.pl.ssl.conf):

upstream soban-pl-webservers {
    server 10.10.11.105:80;
}

server {
    if ($host = www.soban.pl) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    if ($host = soban.pl) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


        listen 80;
        server_name soban.pl www.soban.pl;
        return 301 https://soban.pl$request_uri;
}

server {
    listen 443 ssl http2;
    server_name  www.soban.pl;
    ssl_certificate /etc/letsencrypt/live/www.soban.pl/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/www.soban.pl/privkey.pem; # managed by Certbot
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
    return 301 https://soban.pl$request_uri;
}

server {
    listen 443 ssl http2;
    server_name  soban.pl _;
    ssl_certificate /etc/letsencrypt/live/soban.pl/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/soban.pl/privkey.pem; # managed by Certbot
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
}

    location / {
        access_log /var/log/nginx/access-soban.pl.log;
        error_log /var/log/nginx/error-soban.pl.log;
        proxy_pass http://soban-pl-webservers;
        proxy_redirect https://soban-pl-webservers http://soban-pl-webservers;
        expires off;

        proxy_read_timeout       3500;
        proxy_connect_timeout    3250;

        proxy_set_header   X-Real-IP          $remote_addr;
        proxy_set_header   Host               $host;
        proxy_set_header   X-Forwarded-For    $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto  https;
        proxy_set_header   SSL_PROTOCOL $ssl_protocol;
        proxy_set_header   SSL_CLIENT_CERT $ssl_client_cert;
        proxy_set_header   SSL_CLIENT_VERIFY $ssl_client_verify;
        proxy_set_header   SSL_SERVER_S_DN $ssl_client_s_dn;

                proxy_set_header X-Scheme $scheme;
                proxy_ssl_session_reuse off;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "upgrade";
    }
      location ~ ^/(wp-admin|wp-login\.php) {
            auth_basic "Restricted";
            auth_basic_user_file /etc/nginx/conf.d/htpasswd;
           proxy_pass http://soban-pl-webservers;
           proxy_redirect https://soban-pl-webservers http://soban-pl-webservers;
           expires off;
           proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;
           proxy_set_header        Host            $host;
           proxy_set_header        X-Real-IP       $remote_addr;
           proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
      }

}

Configuration of the above-mentioned wordpress, additional authorization is also set when you try to log in to wp-admin, you can read about it here: More security wp-admin in nginx.

In the next step, check if the nginx configuration is correct by:

# service nginx configtest

If everything is fine, restart nginx:

# service nginx restart

In a virtual machine with nginx it should also be installed. This is the same as debian linux 11 (bullseye), so the respository should look like this:

#...
deb http://nginx.org/packages/debian/ bullseye nginx
deb-src http://nginx.org/packages/debian/ bullseye nginx

Just installing nginx looks the same as on a machine that acts as a proxy.

# apt update
# apt install nginx

All configuration is in /etc/nginx/conf.d/soban.pl.conf:

server {
    listen   80;

   client_max_body_size 20M;

    server_name soban.pl www.soban.pl;
    access_log /var/log/nginx/access-soban.pl.log; #access logi
    error_log /var/log/nginx/error-soban.log; # error logi
    port_in_redirect off;
    set_real_ip_from  10.10.11.105;
    real_ip_header    X-Forwarded-For;
    real_ip_recursive on;
       root /home/produkcja/wordpress/;
       index index.html index.php;

if ($host ~* ^www\.(.*))
{
    set $host_without_www $1;
    rewrite ^/(.*)$ $scheme://$host_without_www/$1 permanent;
}

    error_page 404 /index.php;


        location ~ \.php$ {
                root /home/produkcja/wordpress/; # dir where is wordpress
                fastcgi_split_path_info ^(.+\.php)(/.+)$;
                fastcgi_pass unix:/var/run/php/php-fpm.sock;
                fastcgi_index index.php;
                include fastcgi_params;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

        }

        location / {
                try_files $uri $uri/ /index.php?$args;
        }
        location = /sitemap.xml {
                rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.xml$ "/index.php?xml_sitemap=params=$2" last;
                rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.xml\.gz$ "/index.php?xml_sitemap=params=$2;zip=true" last;
                rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.html$ "/index.php?xml_sitemap=params=$2;html=true" last;
                rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.html.gz$ "/index.php?xml_sitemap=params=$2;html=true;zip=true" last;
       }

location = /favicon.ico {
  return 204;
  access_log     off;
  log_not_found  off;
}

location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
expires 365d;
        }location ~* \.(pdf)$ {
expires 30d;
}

}

Also in this case, check the correctness of the nginx service configuration:

# service nginx configtest

Everything looks fine, so let’s move on to restarting the service:

# service nginx restart

If the whole configuration was done correctly, the page should be directed without encrypted traffic to the virtual machine with wordpress. A wordpress service with nginx is not the only one that can be hosted or proxied. We can direct traffic from nginx to e.g. jboss, apacha and all other web services. Of course, this requires a corresponding modification of the configuration presented above, but the general outline of the concept as an nginx proxy has been presented. You should also remember about the appropriate configuration of keys and certificates. In my case let’s encrypt works perfectly for this.

Artykuł Proxy through nginx frontend to the second virtual server wordpress pochodzi z serwisu soban.

Improving encryption on old red hat 5 by new Oracle Linux 7 using apache mod_proxy

soban — Sat, 06 Nov 2021 13:54:17 +0000

There are situations when we need to increase the encryption level on the old system – according to the PCI audit requirements. However, the old system is no longer supported, so updating the encryption level is not possible. This is not a recommended solution, because we should try to transfer the application to a new system. After all, when we have little time, it is possible to hide the old version of the system and allow only the new machine to move to it. In this particular example, we will use mod_proxy as a proxy to redirect traffic to the old machine, while using iptables we will only allow communication with the new machine. It is not a recommended solution, but it works and I would like to present it here. The systems that I will be basing on in this example are the old red hat 5 and the new oracle linux 7. Recently, it has become very important to use a minimum of tls 1.2 and none below for banking transactions. Let’s start with the proxy server configuration oracle linux 7.

As of this writing, the addressing is as follows:
new_machine IP: 10.10.14.100
old_machine IP: 10.10.14.101
Traffic will be routed on port 443 from new_machine to old_machine.

Before we go to proxy configuration, please make sure there are network transitions from new_machine (10.10.14.100) to old_machine (10.10.14.101) to port 443. You can read how to verify network connections here: check network connection and open tcp port via netcat.

We go to the installation of apache and mod_proxy:

# yum install httpd mod_proxy

After installing apache, go to the edition:

# vi /etc/httpd/conf.d/ssl.conf

Below are the news on the check level, what are the updates, and ip on the next service update:


SSLProtocol -all +TLSv1.2
SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:!NULL:!RC4:!RC2:!DES:!3DES:!SHA:!SHA256:!SHA384:!MD5+HIGH:+MEDIUM:!KRB5
#…

SSLProxyProtocol all
SSLProxyEngine on
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire off
ProxyRequests On
    
        Require all granted
    
    # backend server and forwarded path
    ProxyPass / https://10.10.14.101/
    ProxyPassReverse / https://10.10.14.101/

In order to verify the correctness of apache configuration, you can issue a command that will check it:

# service httpd configtest

If the apache configuration is correct, we can proceed to reloading apache:

# service httpd restart

At this point, we have a configured proxy connection. Before we move on to limiting traffic with iptables, I suggest you go to the site – with the new mod_proxy configured and test if everything is working properly and if there are any problems with the application.

Once everything is working fine, the network transitions are there, we can go to the iptables configuration for red hat 5. Let’s start by checking the system version:

# cat /etc/redhat-release

Now we are going to prepare iptables so that the network traffic is available on port 443 from the new_machine (10.10.14.100). To do this, edit the file /etc/sysconfig/iptables:

# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp --dport 443 -s 10.10.14.100 -j ACCEPT
-A INPUT -p tcp --dport 443 -j DROP
-A INPUT -p tcp --dport 80 -j DROP
-A INPUT -j ACCEPT
COMMIT

After iptables settings are correct, we can reload the service:

# /etc/init.d/iptables restart

In this way, we managed to cover up the weak encryption by proxying and diverting traffic to the new machine. This is not a recommended solution and you should try to transfer the application to a new environment compatible with the new system. However, in crisis situations, we can use this solution. Network traffic is not allowed by other IP addresses, so scanners will not be able to detect weak encryption on the old machine, and users using the old environment will not be able to use it. This does not change the fact that weak encryption is still set in the old environment and needs to be corrected. The example I gave is for the old red hat 5 and the new oracle linux 7, but it can be assumed that a similar solution and configuration is possible for other versions of the system.

Artykuł Improving encryption on old red hat 5 by new Oracle Linux 7 using apache mod_proxy pochodzi z serwisu soban.