Prerequisites

• A fresh Debian 12 Bookworm installation.
• A user with sudo privileges.
• Internet connectivity.

Installation Scripts

We’ve divided the installation into two scripts. The first script prepares your system and installs the Proxmox VE kernel. The second script continues the process after a system reboot, installing the remaining Proxmox VE packages.

Remember, all these commands need to be executed from the root user level, so:

# sudo su -

First Part: System Preparation and Kernel Installation

Start by downloading the first script which prepares your system and installs the Proxmox VE kernel:

# wget https://soban.pl/bash/install-proxmox-part1.sh
# chmod +x install-proxmox-part1.sh

Run the script with the following command:

# ./install-proxmox-part1.sh

Here is the content of the script:

#!/bin/bash
# The script is an integral part of the article available at (part 1/2)
# https://soban.pl/simplified-proxmox-ve-8-installation-on-debian-12-bookworm/

# Introduction message
echo "Starting the setup for Proxmox VE installation on Debian Bookworm..."

# Display available network interfaces and their IP addresses
echo "Available network interfaces and IP addresses:"
ip -br -c a

# Retrieve the current hostname
CURRENT_HOSTNAME=$(hostname)

# Retrieve the current IP address
CURRENT_IP_ADDRESS=$(hostname -I | awk '{print $1}')

# Set up hostname
echo "Please enter the hostname for your Proxmox server (Press Enter to keep current: $CURRENT_HOSTNAME):"
read HOSTNAME
if [ -z "$HOSTNAME" ]; then
    HOSTNAME=$CURRENT_HOSTNAME
fi

# Set up IP address
echo "Based on the list above, please enter the IP address for your Proxmox server (Press Enter to keep current: $CURRENT_IP_ADDRESS):"
read IPADDRESS
if [ -z "$IPADDRESS" ]; then
    IPADDRESS=$CURRENT_IP_ADDRESS
fi

hostnamectl set-hostname "$HOSTNAME"

# Backup and configure /etc/hosts
cp /etc/hosts /etc/hosts.backup
cat <<EOF > /etc/hosts
127.0.0.1       localhost
$IPADDRESS      $HOSTNAME

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
EOF

# Backup existing sources.list and prepare Proxmox VE repository
cp /etc/apt/sources.list /etc/apt/sources.list.backup
echo "deb [arch=amd64] http://download.proxmox.com/debian/pve bookworm pve-no-subscription" > /etc/apt/sources.list.d/pve-install-repo.list

# Add the Proxmox VE repository key
wget https://enterprise.proxmox.com/debian/proxmox-release-bookworm.gpg -O /etc/apt/trusted.gpg.d/proxmox-release-bookworm.gpg
echo "Verifying the GPG key..."
sha512sum /etc/apt/trusted.gpg.d/proxmox-release-bookworm.gpg | grep '7da6fe34168adc6e479327ba517796d4702fa2f8b4f0a9833f5ea6e6b48f6507a6da403a274fe201595edc86a84463d50383d07f64bdde2e3658108db7d6dc87'
if [ $? -ne 0 ]; then
    echo "GPG key verification failed. Aborting."
    exit 1
fi

# Update and upgrade the system
apt update && apt full-upgrade -y

# Install the Proxmox VE kernel
apt install proxmox-default-kernel -y

# Install Proxmox VE and other necessary packages
apt install proxmox-ve postfix open-iscsi chrony -y

echo "Kernel installation completed. The system will now reboot. After rebooting, continue with the second part of the script."
reboot

After running the first script, your system will reboot. At this stage, you may encounter a few dialogs from the system, which are part of the normal package configuration steps. For this simplified installation, you can accept the default options by pressing Enter.

Screenshots during Installation

GRUB Configuration – A new version of the GRUB bootloader configuration file is available. It’s recommended to keep the local version currently installed unless you are aware of the changes. As with the previous dialogs, pressing Enter will select the default action.

Postfix Configuration – This dialog appears when installing the postfix package, which is a mail transport agent. The default option “Internet Site” is suitable for most cases. Pressing Enter accepts this configuration.

System Mail Name – Here you specify the FQDN (Fully Qualified Domain Name) for the system mail. The default value is usually adequate unless you have a specific domain name for your server. Again, pressing Enter will continue with the default configuration.

There might be issues encountered towards the end of the first script installation, such as:

Errors were encountered while processing:
 ifupdown2
 pve-manager
 proxmox-ve
E: Sub-process /usr/bin/dpkg returned an error code (1)

However, the second part of the script, executed after the reboot, addresses these problems.
After a successful reboot of the machine, log into the system and proceed to the second script.

Second Part: Completing Proxmox VE Installation

After your system has rebooted, proceed with downloading the second script:

# wget https://soban.pl/bash/install-proxmox-part2.sh
# chmod +x install-proxmox-part2.sh

Execute the second part of the installation with the command:

# ./install-proxmox-part2.sh

This is the content of the second script:

#!/bin/bash
# The script is an integral part of the article available at (part 2/2)
# https://soban.pl/simplified-proxmox-ve-8-installation-on-debian-12-bookworm/

# Introduction message
echo "Continuing Proxmox VE installation after reboot..."

# Install upgrade
apt upgrade -y

# Optional: Remove the Debian default kernel
apt remove linux-image-amd64 'linux-image-6.1*' -y
update-grub

# Optionally remove the os-prober package
apt remove os-prober -y

# Clean up installation repository entry
rm /etc/apt/sources.list.d/pve-install-repo.list

# Retrieve the server's IP address for the Proxmox web interface link
IP_ADDRESS=$(hostname -I | awk '{print $1}')
echo "Proxmox VE installation completed."
echo "You can now connect to the Proxmox VE web interface using:"
echo "https://$IP_ADDRESS:8006"
echo "Please log in using the 'root' username and your root password."

Once the second script completes, you will be able to access the Proxmox VE web interface using the URL displayed at the script’s conclusion. Log in with the ‘root’ username and your root password.

Upon loading the page, you may encounter a certificate trust error – this is normal at this stage, and you can safely accept that it is unsafe and proceed to access the page for managing Proxmox. If you don’t know the root password, you can reset it by executing ‘passwd‘ as root. Good luck!

Artykuł Simplified Proxmox VE 8 Installation on Debian 12 Bookworm pochodzi z serwisu soban.

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.

useradd -m soban -s /bin/bash

This way we created the user ‘soban’ and assigned it the default shell ‘/bin/bash’.

We still need to set a password for the user ‘soban’:

# passwd soban

In the next step, let’s add it to ‘/etc/sudoers’ so that it can become root. Keep in mind that once the user can get root, he will be able to do anything on the machine!

# vi /etc/sudoers

Please add this entry below:

#user can made sudo on root (sudo su -)
soban ALL=(ALL) NOPASSWD: ALL

How can we test whether the user has the ability to log in as root? Nothing easier, first we’ll switch to the user we just created:

# su - soban

To list the possible sudo commands, just type the command:

$ sudo -l

Finally, to confirm whether it is possible to log in as root, you should issue the command:

# sudo su -

Now that we have a root user ready, let’s try disabling ssh logon directly and change the default port. To do this, go to the default configuration of the ssh service, which is located in ‘/etc/ssh/sshd_config’:

# vi /etc/ssh/sshd_config

We are looking for a line containing ‘Port’ – it can be hashed, so it should be unhashed and ‘PermitRootLogin’. Then set them as below:

Port 2222
PermitRootLogin no

In this way, we changed the default port 22 to 2222 and disallowed the possibility of logging in directly to the root user. However, the ssh service still needs to be reloaded, in debian or kali linux we do it like this:

# service sshd restart

In this way, we have managed to create a user who can safely log into the ssh service and become root. In addition, after changing the port, we will not go out on port 22 scans, which by default is set and scanned by a potential burglar. Installing the fail2ban service is also a very good improvement in security.

Artykuł Increasing the security of the ssh service 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.

In Linux, scp (Secure Copy) is a command-line utility used for securely transferring files between local and remote systems. It is a secure alternative to cp, which is not secure when transferring files over a network.

The scp command is commonly used for copying files to or from a remote server. It uses the SSH protocol to securely transfer files and provides the same level of security as SSH. The syntax of the scp command is as follows:

scp [options] [source] [destination]

Here, [source] is the file or directory you want to copy, and [destination] is the location where you want to copy the file or directory.

Some common options used with the scp command are:

• -r: Copies directories recursively
• -P: Specifies the port number to use for the SSH connection
• -i: Specifies the path to the identity file used for authentication

For example, to copy a file named file.txt from a remote server to the local machine, you would use the following command:

scp user@remote:/path/to/file.txt /path/to/local/directory/

This command will copy the file from the remote server to the local machine at the specified directory.

Similarly, to copy a directory named dir from the local machine to a remote server, you would use the following command:

scp -r /path/to/local/dir user@remote:/path/to/remote/directory/

This command will copy the directory and its contents from the local machine to the remote server at the specified directory.

Let’s start by creating an example file that we will transfer: 

$ echo “example text” > example_file

in the next step, let’s move on to uploading the file. In my case, the port from ssh has been changed to 2222:

$ scp -P2222 example_file soban@soban.pl:~

The first time you connect, you will be asked for a fingerprint. 
As you can see, the file has been sent correctly. 

Instead of the sign at the end of ‘~‘ we can specify where the target file should be placed (/tmp/example-path): 

$ scp -P2222 example_file soban@soban.pl:/tmp/example-path

There are many combinations, you can send, for example, all files containing the ending (*.tar.gz) to the user’s home directory, which is just symbolized by ‘~‘: 

$ scp -P2222 *.tar.gz soban@soban.pl:~

An interesting parameter is the ‘-r‘ in scp where we can transfer entire folders, example using copying a folder from local machine to remote machine: 

$ scp -P2222 -r /local/directory/ soban@soban.pl:/remote/directory/

OK, after the file has been successfully sent to the target machine, let’s delete the local file we created above and try to download it back: 

$ rm example_file

Next, let’s move on to downloading the file from the remote server to the local machine: 

$ scp -P2222 soban@soban.pl:example_file ~

Above I gave an example of how to send an entire folder from a local machine to a remote machine. The other way around, of course, we can also do it. To download a remote folder to a local machine, use the ‘-r‘ parameter:

$ scp -P2222 -r soban@soban.pl:/remote/directory/ /local/directory/

The scp utility has more parameters, you can get them by reading the man page: 

$ man scp

It is worth paying attention to the ‘-l‘ parameter where we can set the limit of transferred files. This is useful when transferring larger files so as not to overload your connection. 

If you are tired of constantly entering your password, I encourage you to read how you can connect to ssh without providing a password. Then copying files using scp will become more: generate ssh key pair in linux.

In my opinion, scp is good for transferring files quickly one time. However, as often you exchange files between machines a more convenient way is to use sshfs as described here: sshfs great tool to mount remote file system.

Artykuł Securely Copy Files (scp) tool to copying files by ssh pochodzi z serwisu soban.

To use SSHFS, the user needs to have SSHFS installed on their local system as well as the remote system that they want to connect to. Once SSHFS is installed, the user can mount the remote system as a local directory on their system, and access the remote files as if they were stored locally.

SSHFS provides a secure and convenient way to access and manage files on remote systems, without the need for additional software or complicated configuration. It also enables users to access files on remote systems using standard file operations, such as copying, moving, and deleting, making it a simple and effective way to manage files on remote systems.

SSH Filesystem (sshfs) is a very useful tool for remotely transferring files over the ssh protocol. An additional advantage of the whole is encryption. This is a convenient way to mount a remote folder to delete files. Below I will try to briefly introduce how to install sshfs and how to mount the folder remotely. Additionally, we will make an entry in /etc/fstab at the end, so that the resource itself is mounted after restarting the system. Let’s move on to installing the tool itself:

# apt install sshfs

In this case, as you can see, the installation was done on kali linuxe, however the procedure is the same on debian.

Let’s move on to the file mounting itself, at this point I will point out that the default port is 22. In my case, however, the port has been changed to 2222. For services such as ssh, I try to change the default ports so as not to get caught by bots and not end up in the database such as shodan.io. The command itself in this case is very simple, but first we need to create a folder:

$ mkdir /home/kali/myremotedir

Let’s try to mount a remote folder:

$ sshfs soban@soban.pl:/home/soban/ /home/kali/myremotedir -p 2222

During mounting, we will be asked if the fingerprint is correct. Then for the system password. The command itself can be disassembled into ‘soban‘ – this is the username. Then ‘soban.pl‘ is the domain name, you can also put the IP address here. The next ‘/home/soban‘ element is the folder that will be mounted. And after the space ‘/home/kali/myremotedir‘ we give the folder where the remote folder should be mounted. If everything went as planned, we can list ‘/home/kali/myremotedir‘ and it should list the contents of the remotely mounted folder ‘/home/soban‘. Let’s list the contents of the ‘/home/kali/myremotedir‘ folder:

$ ls -ltr /home/kali/myremotedir

Let’s create a remote file:

$ echo 'some text' > /home/kali/myremotedir/example
$ ls -ltr /home/kali/myremotedir

Now let’s unmount the remote folder and try listing it again:

$ umount /home/kali/myremotedir
$ ls -ltr /home/kali/myremotedir

As expected, the folder is empty and the file we created was created on a remotely mounted drive. After unmounting as you can see the file ‘/home/kali/myremotedir/example‘.

The next step is to create a private key to mount the folder without entering a password. It is very important not to send nikmou your private key. How we can generate and add a public key to a remote server can be read here: “Generate SSH key pair in Linux“.

Now we will try to add an entry to /etc/fstab which will allow automatic mounting on startup of the remote folder system.
To do this, edit the /etc/fstab entry and add this entry:

#edit this entry and put correct data
sshfs#soban@soban.pl:/home/soban /home/kali/myremotedir fuse auto,user,_netdev,reconnect,identityfile=/home/kali/.ssh/id_rsa,port=2222,uid=1000,gid=1000,allow_other 0 0

It is important that all data is correct, in order to verify the parameters, you can use the command for this ‘id‘:

# id kali

Now we can move on to mounting the resource:

# mount /home/kali/myremotedir

When mounting for the first time, we may be asked to accept and confirm that the fingerprint is correct. After verifying the correctness of mounting the remote resource, we can restart the system. One note here, the system may get up longer.

Artykuł sshfs great tool to mount remote file system pochodzi z serwisu soban.

$ ssh soban@soban.pl -p2222

During the connection, we will be asked if the fingerprint is correct. Then enter the user password that is set on the remote server. During the ssh command ‘soban@soban.pl -p2222‘ I gave the username ‘soban‘ then the domain ‘soban.pl‘ and ‘-p2222‘ port ‘2222’. The default port after ssh is 22, but in this case I changed it so that it does not come out on scans – this increases security as often bots / hackers look for port 22, which is the default ssh port set.

Let’s move on to generating the key and copying it to the server:

$ ssh-keygen -t rsa

This is how the key generation looks like, I hit enter for each question:

As a result, a private key was generated: (/home/kali/.ssh/id_rsa) and a public key (/home/kali/.ssh/id_rsa) that we will place on the remote server:

$ ssh soban@soban.pl -p2222 "echo \"`cat ~/.ssh/id_rsa.pub`\" >> .ssh/authorized_keys"

The last time we log in to the server by entering the password. When logging in, we will not be asked for a password now. This way we are able to add our public key (.ssh / authorized_keys) to the remote server.

Artykuł Generate SSH key pair in Linux pochodzi z serwisu soban.

location ~ ^/(wp-admin|wp-login\.php) {
           auth_basic "Restricted";
           auth_basic_user_file /etc/nginx/.htpasswd;
           proxy_pass http://upstream-webservers;
           proxy_redirect https://upstream-webservers http://upstream-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;
      }

We still need to provide the username for authorization and save to the file (/etc/nginx/.htpasswd) as we entered in the nginx configuration file. In “my_user_name”, replace the login of the user with which we will be authorized.:

# echo -n 'my_user_name:' >> /etc/nginx/.htpasswd

And the encrypted password has been set by openssl:

# openssl passwd -apr1 >> /etc/nginx/.htpasswd

Openssl will ask you to come up with a password and enter it twice:

As a result, we will get a file with an encrypted password:

Before reloading nginx, we do a configuration verification:

# service nginx configtest

If everything is set correctly, we should receive the following message:

Now we can restart the service nginx:

# service nginx restart

The final verification will be to log in to the backend (e.g. www.example-page-wordpress.pl/wp-admin/), as a result, we should be asked for the login and password that we created above:

This is a simple trick to protect your wordpress from bot attacks. However, it should be remembered that we do not share passwords with anyone and setting default usernames and simple passwords is asking for a problem.

Artykuł More security wp-admin in nginx pochodzi z serwisu soban.

Let’s start by looking at all nginx logs.

In this case, sorting from oldest to newest is very useful as we know where to find the newest log entries:

# cd /var/log/nginx/
# ls -ltr *

If we are interested in the latest data, we will focus on the access-soban.pl.log file.

I know that my website is monitored by uptimerobot.com and I would like to find out, for example, from what IP address the website gets a query, e.g. to add it to the firewall as trusted:

# grep -i uptime access-soban.pl.log

As you can see, in this case, the bot that is querying the server has the IP address: 208.115.191.21. If I wanted to see all calls from this IP address, I could view them this way:

# grep 208.115.199.21 access-soban.pl.log* | less

If I press (shift + g) I’ll go to the bottom of the log:

It is worth noting that in this case the file in which the query is located is also given.

Now suppose I would like the logs, but without the “uptimerobot“:

# grep -v uptimerobot access-soban.pl.log* | less

This way all queries containing the word “uptimerobots” were cut. We can of course diminish the output from the console more by adding “| grep -v” possibly. Let’s cut out “sitemap“:

# grep -v uptimerobot access-soban.pl.log* | grep -v sitemap | less

One handy thing is to direct the stream from the console output to a file. We do this as follows “/tmp/file.log“:

# grep -v uptimerobot access-soban.pl.log | grep -v sitemap >> /tmp/file.log

Additionally, we can pack the file:

# tar -zcf /tmp/file.log.tar.gz /tmp/file.log

After packing the file, we can send it to another person. Sensitive data, such as inquiries or logins, can be cut using grep, as we did above.

Now let’s move on to one of the most useful tools for watching live what happens when someone enters a page:

# tail -f *.log

At this point it is worth noting that we “caught” the logs from the files: “access-soban.pl.log” and “error-soban.pl.log”. However, the “error-soban.pl.log” log is empty, so its content is not shown below. However, if something came up, we would see the contents of the updated file on the console.

Useful at this point is to combine grep and tail. We’re assuming we don’t want uptimerobots to bump into our consoles while observing the logs, so we’re going to cut them like this:

# tail -f *.log | grep -v uptimerobots

The given examples can be modified in any way. I encourage you to use it in various combinations of tail and grep, especially in situations where erros/warning are repeated. Of course, not only in nginx logs you can use these commands. In all logs where we operate on text, be it system or application. Passing the text mentioned above is very helpful.

Artykuł Useful tricks to view and search logs 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.