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.

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:

<VirtualHost _default_:443>
SSLProtocol -all +TLSv1.2
SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:!NULL:!RC4:!RC2:!DES:!3DES:!SHA:!SHA256:!SHA384:!MD5+HIGH:+MEDIUM:!KRB5
#…
<IfModule mod_proxy.c>
SSLProxyProtocol all
SSLProxyEngine on
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire off
ProxyRequests On
    <Proxy *>
        Require all granted
    </Proxy>
    # backend server and forwarded path
    ProxyPass / https://10.10.14.101/
    ProxyPassReverse / https://10.10.14.101/
</IfModule>
</VirtualHost>

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.

iftop provides various filtering options, allowing you to limit the output to specific hosts, networks, or ports. It supports IPv6 and can display source and destination IP addresses, port numbers, and protocols.

It is particularly useful for monitoring traffic in real time and identifying which services or hosts consume the most bandwidth. It can also help detect network performance issues and assist in troubleshooting.

Overall, iftop is a lightweight yet powerful tool and a valuable addition to any network administrator’s toolkit.

One of the most useful network monitoring tools I use is iftop. It becomes especially helpful when the network link is saturated. In practice, it can also help detect abnormal traffic patterns, including DoS attacks. In the example below, I will transfer a large file to a remote machine with a bandwidth limit and observe the traffic using iftop.

First, install iftop on the local machine (in this case, Kali Linux):

# apt install iftop

The distribution does not matter — iftop is available in most Linux repositories, including Debian.

Now install iftop on the remote machine (Debian Linux):

# apt install iftop

To start monitoring network traffic, run iftop with the parameters -PpNn:

# iftop -PpNn

Since I am connected to the remote machine via SSH, I can see my active SSH session in the traffic list.

Now let’s go back to the local machine and create a large file:

# truncate -s 1G 1G-file.txt

After creating the 1GB file, let’s transfer it to the remote machine with a bandwidth limit:

# scp -l 800 -P2222 1G-file.txt soban@soban.pl:~

In this example, the -l 800 option limits the transfer rate to 800 Kbit/s. To convert this to KB/s, divide by 8. That gives approximately 100 KB/s (800 / 8 = 100).

To learn more about scp and secure file transfers over SSH, see: Securely Copy Files (scp) tool for copying files via SSH.

When sending the file, the traffic on the local machine (outgoing traffic) looks like this:

# iftop -PpNn

At the same time, on the remote machine (incoming traffic) it looks like this:

# iftop -PpNn

As you can see, this approach allows you to observe both outgoing and incoming traffic in real time. Although iftop is simple, it provides powerful visibility into live network activity.

During brute-force attempts, you will usually observe many short-lived connections. In contrast, a DoS attack aims to saturate the bandwidth, which results in high incoming traffic. However, there are situations where traffic spikes are legitimate. In such cases, you may consider limiting connection speed — tools like iptables can help manage that effectively.

Artykuł iftop as a good network traffic monitoring tool pochodzi z serwisu soban.

The primary function of Netcat is to create network connections between two hosts, allowing data to be transferred between them. It can establish a connection as a client or a server, and it supports both TCP and UDP protocols. This makes it useful for testing network services, troubleshooting network issues, and performing security assessments.

Netcat can be used to scan for open ports on a remote host, allowing system administrators to identify potential security vulnerabilities. It can also be used to transfer files between hosts, similar to the way that the “cp” command works in Linux. Additionally, it can be used to create a simple web server, allowing files to be served over HTTP.

One of the key features of Netcat is its ability to operate in both interactive and non-interactive modes. In interactive mode, it acts like a chat program, allowing users to communicate with each other in real-time. In non-interactive mode, it can be used as a background process that quietly sends or receives data without any user interaction.

Overall, Netcat is a powerful and flexible tool that can be used for a wide range of networking tasks. Its simplicity and ease of use make it a popular choice among system administrators, network engineers, and security professionals.

Sometimes network connections are blocked by various network devices. In the verification of the connection over TCP, we can use, for example, telnet. After all, before we start a server-side service like jboss, we can use a simple utility like netcat to open the port.

In this example we will be using two machines. However, one of them is “host-soban-pl” with the IP address: 10.10.14.100:

$ ip a

The second is “soban-pl” with the IP address: 10.10.11.105:

# ip a

Below, for example, I will show you how to check an already open tcp connection and one that is closed. On the other side, on port 80, I have an open port with nginx:

$ telnet 10.10.11.105 80

Nmap below confirms port opening, additionally identified the service as http:

$ nmap 10.10.11.105 -p 80

The conclusion is that the service has network transitions and you can correctly connect over TCP. Now it will try to open a connection that does not exist, e.g. on port 81.

$ telnet 10.10.11.105 81

As you can see, the connection is not possible because the port is closed. The assumption is that the port may be open, but for example the firewall blocks it. Then you need to set the appropriate rules on it.

After all, in this case I know that the firewall does not block anything, so it will try to open the port with netcat. First we need to install netcat in debian, it is done like this:

# apt install netcat-traditional

Now let’s move on to running netcat on port 81:

# netcat -l -p 81 &

In this case, I specially gave the command ‘&’ at the end to leave the netcat process in the background. At this point, netcat is listening on port 81.

Now we can proceed to checking the correctness of the connection with the use of telnet:

$ telnet 10.10.11.105 81

In the meantime, on the server machine, we can use the netstat tool to verify the connection and check from which machine the traffic is coming:

As you can see, a correct connection from the 10.10.14.100 host has been established with the server on 10.10.11.105 on port 81.

To end the call, hit ‘^]‘ (ctrl +]), then type quit and enter.

In this way, we can verify the correctness of the network connection and whether any firewall or other network problem is an obstacle to its correct establishment. Netcat is a very powerful and useful tool, you can use it to transfer files etc. Netstat is also very useful in situations where network congestion occurs and one of the hosts is attacked. It is then easy to notice that a large number of network connections are made.

Artykuł Check network connection and open TCP port via netcat pochodzi z serwisu soban.