Jeśli korzystasz z serwera Linux z Nginx, SSH lub WordPressem, prawdopodobnie znasz już Fail2Ban. Jest to dobre narzędzie, ale działa lokalnie — blokuje tylko adresy IP, które zaatakowały Twój serwer.

CrowdSec działa zupełnie inaczej. To system ochrony oparty o współdzieloną reputację IP. Jeśli tysiące serwerów na świecie wykryją atakujące IP, Twój serwer może je zablokować zanim jeszcze spróbują ataku.

Jak działa CrowdSec?

• analizuje logi systemowe (nginx, ssh, wordpress)
• wykrywa podejrzane zachowanie
• wymienia informacje o atakujących IP z innymi serwerami
• blokuje ruch na poziomie firewalla

Efekt? Większość botów i skanerów internetu nigdy nie dociera do Twojego Nginxa.

Instalacja CrowdSec na Debian / Ubuntu

Instalacja CrowdSec jest bardzo prosta i dostępna bezpośrednio z repozytoriów Debiana.

apt update
apt install crowdsec

Podczas instalacji CrowdSec automatycznie:

• tworzy lokalne API (LAPI)
• rejestruje serwer w CrowdSec Central API
• pobiera podstawowe scenariusze bezpieczeństwa

Instalacja firewall bouncer

CrowdSec sam wykrywa zagrożenia, ale potrzebuje komponentu wykonawczego — tzw. bouncera, który blokuje ruch w firewallu.

apt install crowdsec-firewall-bouncer

Domyślnie bouncer korzysta z nftables i automatycznie dodaje reguły blokujące adresy IP.

Instalacja kolekcji bezpieczeństwa

Kolekcje zawierają parsery logów oraz scenariusze wykrywania ataków.

cscli collections install crowdsecurity/nginx
cscli collections install crowdsecurity/wordpress
cscli collections install crowdsecurity/base-http-scenarios
cscli collections install crowdsecurity/sshd

Po instalacji przeładuj konfigurację:

systemctl reload crowdsec

Konfiguracja logów Nginx

Aby CrowdSec analizował ruch HTTP, należy wskazać logi Nginx.

Edytuj plik:

nano /etc/crowdsec/acquis.yaml

Dodaj konfigurację:

filenames:
  - /var/log/nginx/access*.log
  - /var/log/nginx/error*.log
labels:
  type: nginx

Następnie uruchom ponownie usługę:

systemctl restart crowdsec

Sprawdzenie działania CrowdSec

Status usługi:

systemctl status crowdsec

Lista aktywnych banów:

cscli decisions list

Statystyki działania:

cscli metrics

Efekt końcowy

Po poprawnej instalacji CrowdSec:

• serwer automatycznie blokuje znane botnety
• ataki WordPress i brute-force SSH są zatrzymywane na firewallu
• Nginx obsługuje mniej złośliwego ruchu
• CPU i IO serwera są znacząco odciążone

CrowdSec można traktować jako ewolucję Fail2Ban — system, który nie tylko reaguje lokalnie, ale korzysta z globalnej inteligencji zagrożeń.

Artykuł CrowdSec – dodatkowa ochrona serwera Linux, Nginx i SSH przed botami oraz atakami brute-force pochodzi z serwisu soban.

Ten poradnik pokazuje kompletną instalację i konfigurację Fail2Ban dla Nginx, zaprojektowaną tak, aby:

• blokować rzeczywiste skanery i próby exploitów (np. żądania do /.env, /.git, /phpmyadmin itp.),
• unikać przypadkowego blokowania administratorów (częsty problem przy banowaniu wyłącznie na podstawie błędów HTTP),
• blokować adresy IP dopiero po powtarzającej się podejrzanej aktywności,
• stosować krótki czas bana (5 minut), aby zmniejszyć ryzyko zablokowania samego siebie.

Dlaczego banowanie wyłącznie na podstawie błędów HTTP może być problematyczne

Wiele poradników sugeruje blokowanie adresów IP jedynie na podstawie kodów statusu HTTP (4xx/499). W praktyce bardzo często prowadzi to do samoblokady, ponieważ nowoczesne aplikacje generują serie zapytań (AJAX, panel administracyjny, przebudowa cache), przez co podczas normalnej pracy mogą pojawiać się błędy HTTP.

Ta konfiguracja wykorzystuje bezpieczniejsze podejście:

• ścieżki exploitów są zawsze traktowane jako podejrzane,
• błędy HTTP są liczone tylko wtedy, gdy zapytanie nie posiada nagłówka Referer (typowe zachowanie skanerów),
• znane złośliwe User-Agenty są uwzględniane.

Krok 1: Instalacja Fail2Ban

Zainstaluj Fail2Ban:

apt update
apt install -y fail2ban

Włącz oraz uruchom usługę:

systemctl enable fail2ban
systemctl start fail2ban

Sprawdź status działania:

fail2ban-client ping
systemctl status fail2ban

Krok 2: Utworzenie filtra nginx-secure

Utwórz plik filtra:

nano /etc/fail2ban/filter.d/nginx-secure.conf

Wklej poniższą konfigurację:

[Definition]

failregex =
    ^<HOST> - .* "(?:GET|POST|HEAD|PUT|DELETE|OPTIONS|PATCH|PROPFIND|CONNECT) (?:/\.env|/wp-config\.php|/phpinfo\.php|/(?:phpmyadmin|adminer)(?:/|$)|/(?:\.git|\.svn|\.hg)(?:/|$)|/vendor/phpunit/|/cgi-bin/).*" \d{3} .*

    ^<HOST> - .* "(?:GET|POST|HEAD|PUT|DELETE|OPTIONS|PATCH|PROPFIND|CONNECT) [^"]*" (?:400|403|404|405|408|413|414|429|444) [^"]* "-" ".*"

    ^<HOST> - .* "(?:GET|POST|HEAD|PUT|DELETE|OPTIONS|PATCH|PROPFIND|CONNECT).*" \d{3} .* "(?:[^"]*)" "(?:[^"]*(?:sqlmap|nikto|masscan|zgrab|nmap|acunetix|wpscan|dirbuster|gobuster)[^"]*)"

ignoreregex =

Krok 3: Utworzenie jail nginx-secure

Utwórz plik konfiguracji jail:

nano /etc/fail2ban/jail.d/nginx-secure.conf

Wklej konfigurację:

[nginx-secure]
enabled  = true
port     = http,https
filter   = nginx-secure

logpath  = /var/log/nginx/access.log
           /var/log/nginx/access-*.log

findtime = 600
maxretry = 20
bantime  = 300

action   = iptables-multiport[name=nginx-secure, port="http,https"]

ignoreip = 127.0.0.1/8 ::1

Krok 4: Restart Fail2Ban

fail2ban-server -t
systemctl restart fail2ban

Krok 5: Sprawdzenie integracji z firewallem

Sprawdź czy łańcuch Fail2Ban istnieje:

iptables -S | grep f2b-nginx-secure
iptables -L f2b-nginx-secure -n -v

Test z zewnętrznej maszyny

Test ścieżki exploita:

for i in 1 2 3 4 5; do
  curl -I https://soban.pl/.env
done

Test logiki błędów bez Referer:

for i in 1 2 3 4 5; do
  curl -sS -o /dev/null -w "%{http_code}\n" https://soban.pl/this-path-should-not-exist-$i
done

Po wykryciu powtarzających się podejrzanych żądań adres IP zostanie zablokowany na 5 minut.

Sprawdzenie zbanowanych adresów IP

fail2ban-client status nginx-secure

Odblokowanie adresu IP

Ręczne zdjęcie bana:

fail2ban-client set nginx-secure unbanip YOUR_IP

Podsumowanie

• blokuje rzeczywiste próby exploitów i skanery,
• minimalizuje ryzyko samoblokady administratora,
• stosuje krótki 5-minutowy ban,
• działa z iptables-nft,
• łatwy test oraz szybkie odblokowanie adresu IP.

Artykuł Konfiguracja Fail2Ban dla Nginx – blokowanie skanerów i exploitów bez blokowania administratora WordPress pochodzi z serwisu soban.

Upgrade Debiana z wersji 12 (bookworm) do 13 (trixie) to operacja, która na serwerach i kontenerach (np. Proxmox LXC / VM) powinna być robiona powtarzalnie i bez niespodzianek. Poniżej masz prosty poradnik oraz gotowe komendy do pobrania i uruchomienia skryptu.

Zanim odpalisz upgrade: zrób backup / snapshot. W Proxmoxie najlepiej vzdump lub snapshot. Na bare-metal chociaż kopia /etc, aplikacji i baz danych.

• Proxmox LXC / VM: backup (vzdump) albo snapshot.
• Serwer: backup /etc, /var/www, bazy danych (MySQL/PostgreSQL), certyfikaty SSL.

Skrypt do pobrania:

https://soban.pl/bash/upgrade_to_debian13.sh

1) Backup przed upgradem (przykłady)

Przykład backupu w Proxmox (na hoście Proxmox, podmień CTID/VMID):

vzdump 101 --mode snapshot --compress zstd --storage local

Przykład prostego backupu katalogów na serwerze (to nie zastąpi pełnego snapshotu, ale lepsze to niż nic):

tar czf /root/backup_before_upgrade.tar.gz /etc /var/www /root

2) Pobranie skryptu (wget / curl)

Najprościej: użyj wget. Jeśli komenda wget nie działa mimo zainstalowanego pakietu, użyj wariantu z pełną ścieżką /usr/bin/wget.

Wariant A (standardowy wget):

apt update
apt install -y wget
cd /root
wget -O upgrade_to_debian13.sh https://soban.pl/bash/upgrade_to_debian13.sh
chmod +x upgrade_to_debian13.sh

Wariant B (wget z pełną ścieżką – pomaga gdy PATH jest skopany):

apt update
apt install -y wget
cd /root
/usr/bin/wget -O upgrade_to_debian13.sh https://soban.pl/bash/upgrade_to_debian13.sh
chmod +x upgrade_to_debian13.sh

Wariant C (curl):

apt update
apt install -y curl
cd /root
curl -fsSL -o upgrade_to_debian13.sh https://soban.pl/bash/upgrade_to_debian13.sh
chmod +x upgrade_to_debian13.sh

3) Pomoc skryptu (parametry)

Zanim odpalisz upgrade, zobacz listę parametrów i przykłady użycia:

cd /root
./upgrade_to_debian13.sh --help

4) Upgrade Debian 12 → Debian 13 (system only)

Jeśli jesteś na Debian 12 (bookworm) i chcesz wykonać tylko upgrade systemu:

cd /root
./upgrade_to_debian13.sh

Skrypt zrobi backup /etc/apt/sources.list, podmieni repozytoria na trixie, wykona apt update oraz apt full-upgrade, a na końcu autoremove i autoclean.

5) Auto-detekcja PHP/nginx i aktualizacja jeśli potrzeba

Jeśli kontener/VM jest webowy i chcesz, żeby skrypt sam wykrył użycie PHP (nginx + fastcgi_pass) i w razie potrzeby zaktualizował PHP oraz nginx:

cd /root
./upgrade_to_debian13.sh --auto

6) Wymuszona aktualizacja PHP i nginx (PHP-FPM socket fix)

Jeśli chcesz wymusić instalację/upgrade PHP oraz automatyczne przestawienie konfiguracji nginx na poprawny socket PHP-FPM:

cd /root
./upgrade_to_debian13.sh --with-php --with-nginx --php-version 8.2

To polecenie instaluje PHP 8.2 (php-fpm + popularne moduły) i podmienia w konfiguracjach nginx stare ścieżki socketów na /run/php/php8.2-fpm.sock. Następnie wykonuje nginx -t oraz restart/reload usług.

7) Debian 13 już jest? Tryb tylko PHP/nginx (bez release upgrade)

Jeżeli system jest już na Debian 13 (trixie) i chcesz wykonać tylko aktualizację PHP/nginx bez ruszania repozytoriów systemowych:

cd /root
./upgrade_to_debian13.sh --php-nginx-only --with-php --with-nginx --php-version 8.2

8) Tryb testowy (dry-run)

Jeśli chcesz zobaczyć co skrypt zrobi, ale bez wykonywania zmian:

cd /root
./upgrade_to_debian13.sh --auto --dry-run

9) Diagnostyka: wget jest zainstalowany, a nie działa

Jeżeli apt mówi, że wget jest zainstalowany, a shell krzyczy command not found, to najczęściej problem z PATH. Najprostsza obejściówka to użycie pełnej ścieżki: /usr/bin/wget.

echo "$PATH"
command -v wget || true
ls -l /usr/bin/wget || true
/usr/bin/wget --version || true

Podsumowanie

To rozwiązanie jest wygodne, bo w jednym miejscu masz upgrade Debian 12 → Debian 13 oraz (opcjonalnie) ogarnięcie problemów z PHP/nginx po upgrade (socket PHP-FPM, test konfiguracji nginx i restart usług). Najważniejsze: zrób backup przed upgradem i zawsze zacznij od --help, żeby widzieć dostępne opcje.

Skrypt: https://soban.pl/bash/upgrade_to_debian13.sh

Artykuł Automatyczny upgrade Debian 12 → Debian 13 z opcjonalną aktualizacją PHP i nginx pochodzi z serwisu soban.

Jeśli próbujesz aktualizować firmware stacji dokującej Dell WD19/WD19S na Proxmoxie (albo Debianie) przez fwupdmgr, możesz trafić na klasyczny błąd typu Operation timed out podczas etapu Erasing…. W praktyce update sypie się przez zarządzanie energią USB (autosuspend). Poniżej masz prosty, skuteczny fix oraz gotowy skrypt do odpalenia na serwerze/laptopie.

Objawy problemu

Najczęściej w trakcie aktualizacji docka (WD19/WD19S) pojawia się błąd podobny do:

failed to write-firmware: failed to erase bank: failed after 5 retries: failed to SetReport: USB error: Operation timed out [-7]

Wtedy fwupdmgr może pokazywać urządzenie WD19S jako Update State: Failed albo stale informować o pending activation, ale sam flash nie przechodzi do końca.

Dlaczego tak się dzieje?

Dock podczas flashowania wykonuje długie operacje, a gdy system próbuje oszczędzać energię na USB (autosuspend), kontrolne transfery USB mogą się wysypywać. Efekt: timeout dokładnie na etapie kasowania banku flash (erase bank).

Szybki fix: wyłącz autosuspend USB na czas aktualizacji

Najprostsze rozwiązanie to tymczasowe ustawienie autosuspend na -1 (czyli wyłączenie). To ustawienie obowiązuje do rebootu (chyba że zrobisz je na stałe w kernel cmdline), ale w zupełności wystarczy na czas update.

echo -1 > /sys/module/usbcore/parameters/autosuspend

Następnie uruchom aktualizację:

fwupdmgr refresh --force
fwupdmgr update

Po update: „pending activation” i wymagane odłączenie kabla

Po udanej instalacji firmware dla WD19/WD19S fwupdmgr często wypisuje komunikat:

The update will continue when the device USB cable has been unplugged.
WD19S is pending activation; use fwupdmgr activate to complete the update.

Wtedy zrób to w tej kolejności:

• Odłącz kabel USB-C od docka (od laptopa).
• (Opcjonalnie) Odłącz zasilanie docka na 10–15 sekund i podepnij ponownie.
• Podepnij USB-C z powrotem.
• Wykonaj aktywację:

fwupdmgr activate

Na końcu sprawdź status:

fwupdmgr get-updates
fwupdmgr get-devices | less

Gotowy skrypt: install + update + wyłączenie autosuspend (z restore)

Poniżej masz gotowy skrypt, który:

• instaluje fwupd
• odświeża metadane LVFS
• tymczasowo wyłącza autosuspend USB (żeby WD19S nie wywalał timeoutów)
• uruchamia aktualizacje
• przywraca poprzednią wartość autosuspend po zakończeniu (nawet jeśli update się wywali)

Skrypt możesz wkleić ręcznie z artykułu, ale jeśli wolisz szybciej: możesz go pobrać bezpośrednio z:

https://soban.pl/bash/dell_updage.sh

Przykład pobrania i uruchomienia:

cd /root/scripts
curl -fsSL https://soban.pl/bash/dell_updage.sh -o dell_updage.sh
chmod +x dell_updage.sh
./dell_updage.sh

Jeśli chcesz, możesz też podejrzeć treść przed uruchomieniem:

curl -fsSL https://soban.pl/bash/dell_updage.sh | less

Jeżeli nie masz less w systemie:

apt update
apt install -y less

Skrypt (pełna treść)

#!/bin/bash
set -euo pipefail

# dell upgrade:
# - installs fwupd
# - refreshes metadata
# - runs fwupdmgr update
# - TEMPORARILY disables USB autosuspend to avoid WD19/WD19S timeouts
# - restores autosuspend setting after update

echo "[INFO] Installing fwupd..."
apt update
apt install -y fwupd

echo "[INFO] Refreshing firmware metadata..."
fwupdmgr refresh --force
fwupdmgr get-updates || true

# Save current autosuspend value (if exists)
AUTOSUSPEND_PATH="/sys/module/usbcore/parameters/autosuspend"
OLD_AUTOSUSPEND=""

if [[ -f "$AUTOSUSPEND_PATH" ]]; then
  OLD_AUTOSUSPEND="$(cat "$AUTOSUSPEND_PATH" || true)"
  echo "[INFO] Current usbcore autosuspend: ${OLD_AUTOSUSPEND}"
else
  echo "[WARN] autosuspend sysfs file not found: $AUTOSUSPEND_PATH"
fi

restore_autosuspend() {
  if [[ -f "$AUTOSUSPEND_PATH" && -n "${OLD_AUTOSUSPEND}" ]]; then
    echo "[INFO] Restoring usbcore autosuspend back to: ${OLD_AUTOSUSPEND}"
    echo "${OLD_AUTOSUSPEND}" > "$AUTOSUSPEND_PATH" || true
  fi
}
trap restore_autosuspend EXIT

# Disable autosuspend to prevent USB timeout during dock firmware erase/write
if [[ -f "$AUTOSUSPEND_PATH" ]]; then
  echo "[INFO] Disabling USB autosuspend (set to -1) to avoid dock update timeouts..."
  echo -1 > "$AUTOSUSPEND_PATH"
fi

read -p "Czy chcesz zaktualizowac wszystkie urzadzenia? (y/n): " answer
if [[ "$answer" == "y" || "$answer" == "Y" ]]; then
  echo "[INFO] Running fwupdmgr update..."
  fwupdmgr update || {
    echo "[ERROR] fwupdmgr update failed."
    echo "[HINT] If this is Dell dock (WD19/WD19S), try: unplug USB-C, replug, then run: fwupdmgr activate"
    exit 1
  }

  echo "[INFO] Update finished."
  echo "[INFO] If you updated a Dell dock and it says 'pending activation':"
  echo "       1) Unplug USB-C cable from the dock"
  echo "       2) (Optional) Unplug dock power for 10 seconds, plug back"
  echo "       3) Run: fwupdmgr activate"
else
  echo "[INFO] Skipping firmware update."
fi

echo "[INFO] Done."

Uruchomienie skryptu

Najprościej:

chmod +x dell_updage.sh
./dell_updage.sh

Najczęstsze pytania i tipy

• Update dalej się sypie? Odłącz wszystkie peryferia od docka (monitory/LAN/USB), zostaw tylko zasilanie i USB-C, zrób hard reset docka (odłącz prąd na 30s) i spróbuj ponownie.
• „pending activation” po update – to normalne dla WD19/WD19S. Musisz wypiąć USB-C, podpiąć ponownie i zrobić fwupdmgr activate.
• To aktualizuje BIOS laptopa? Nie zawsze. fwupdmgr pokaże osobno „System Firmware” (BIOS/UEFI) i osobno dock. W tym artykule skupiamy się na docku i problemie z USB timeout.

Podsumowanie

Jeśli firmware Dell WD19/WD19S wywala się na Proxmox/Debian podczas Erasing…, to w większości przypadków wystarczy na czas aktualizacji wyłączyć autosuspend USB. Skrypt powyżej robi to automatycznie, a potem przywraca poprzednie ustawienie, żeby system dalej działał normalnie.

Artykuł Dell WD19/WD19S: aktualizacja firmware na Proxmox/Debian bez timeoutów USB (fwupd + autosuspend fix) pochodzi z serwisu soban.

Dynamiczne nazwy zakładek w Tmuxie z SSH i hostname

Chcesz, aby Twoje zakładki (okna) w Tmuxie automatycznie pokazywały hostname serwera, do którego się logujesz przez SSH? A po wylogowaniu wracały do nazwy lokalnego hosta? Ten poradnik pokaże Ci, jak to skonfigurować krok po kroku.

1. Konfiguracja Tmux – ~/.tmux.conf

W pliku konfiguracyjnym Tmuxa ustaw domyślną komendę startową na specjalny plik Bash (.bash_tmux), który załatwi całą magię.

set-option -g default-command 'bash --rcfile ~/.bash_tmux'

2. Skrypt startowy Bash – ~/.bash_tmux

Ten plik wykonuje się przy każdym starcie okna Tmux. Ustawia nazwę okna na hostname oraz nadpisuje polecenie ssh, aby aktualizowało zakładkę przy połączeniu i po rozłączeniu.

#!/bin/bash
# ~/.bash_tmux
# Custom Bash init file for Tmux sessions with dynamic tab naming

# Override the default ssh command to dynamically rename the Tmux window
ssh() {
  if [ -n "$TMUX" ]; then
    # Loop through arguments to find the target host (first non-flag argument)
    for arg in "$@"; do
      if [[ "$arg" != -* ]]; then
        if [[ "$arg" == *@* ]]; then
          host="${arg#*@}"  # extract host from user@host
        else
          host="$arg"
        fi
        break
      fi
    done

    # Strip any trailing junk or whitespace
    host="$(echo "$host" | cut -d' ' -f1)"

    # Rename the Tmux window to the SSH target
    [ -n "$host" ] && tmux rename-window "$host"

    # Save the local hostname to restore later
    local_host="$(hostname -s)"

    # Run the actual SSH command
    command ssh "$@"

    # Restore the original window name after logout
    tmux rename-window "$local_host"
  else
    # Not in Tmux — just run ssh normally
    command ssh "$@"
  fi
}

# Load the user's regular bash configuration
source ~/.bashrc

# On shell start, if in Tmux, set the window name to the current hostname
if [ -n "$TMUX" ]; then
  tmux rename-window "$(hostname -s)"
fi

3. Przeładowanie konfiguracji Tmux bez restartu

Aby zastosować zmiany bez restartowania całej sesji Tmux, użyj następującego polecenia:

tmux source-file ~/.tmux.conf

Dodatkowo możesz przeładować bieżącą powłokę z .bash_tmux ręcznie:

exec bash --rcfile ~/.bash_tmux

4. Efekt końcowy

• Nowe okno Tmux ma automatycznie nazwę lokalnego hosta
• Po połączeniu przez SSH — zakładka zmienia się na nazwę zdalnego hosta
• Po wylogowaniu — zakładka wraca do lokalnego hostname

Prosto, czytelnie i mega wygodnie — idealne dla adminów, devopsów i fanów porządku w Tmuxie 💪

Artykuł Dynamiczne nazwy zakładek w Tmuxie z SSH i hostname pochodzi z serwisu soban.

Automatyzacja Zarządzania Przestrzenią Dyskową w Środowisku Linux

W dzisiejszym cyfrowym świecie, gdzie dane gromadzone są w coraz większych ilościach, zarządzanie przestrzenią dyskową staje się kluczowym elementem utrzymania efektywności operacyjnej systemów. W tym artykule przedstawię skrypt, który automatyzuje proces zarządzania przestrzenią na zdalnym dysku montowanym przez SSHFS, szczególnie przydatny dla administratorów systemów, którzy regularnie muszą radzić sobie z zapełniającymi się nośnikami danych.

Wymagania wstępne

Przed rozpoczęciem, upewnij się, że na twoim systemie zainstalowane jest SSHFS oraz wszystkie niezbędne pakiety umożliwiające jego prawidłową pracę. SSHFS pozwala na montowanie systemów plików zdalnych przez SSH, co jest kluczowe dla działania naszego skryptu. Aby zainstalować SSHFS oraz niezbędne narzędzia, w tym pakiet umożliwiający przekazywanie hasła (sshpass), użyj poniższego polecenia:

sudo apt-get update
sudo apt-get install sshfs fuse sshpass -y

Skrypt Bash do zarządzania przestrzenią dyskową

Nasz skrypt Bash skupia się na monitorowaniu i utrzymaniu określonego procentu wolnej przestrzeni dyskowej na zdalnym dysku, montowanym za pomocą SSHFS. Oto główne funkcje skryptu:

Definicja Celów:

TARGET_USAGE=70 – procent przestrzeni dyskowej, który chcemy utrzymać jako zajęty. Skrypt będzie działał na rzecz utrzymania przynajmniej 30% wolnego miejsca na dysku.

Punkt Montowania i Ścieżki:

MOUNT_POINT=”/mnt/qnapskorupki” – lokalny katalog, w którym montowany jest zdalny dysk. TARGET_DIRS=”$MOUNT_POINT/up*.soban.pl” – ścieżki katalogów, w których skrypt będzie szukał plików do usunięcia, jeśli zajdzie taka potrzeba.

Funkcja check_qnap: Ta funkcja sprawdza, czy dysk jest zamontowany i czy katalog montowania nie jest pusty. Jeśli są problemy, skrypt próbuje odmontować i ponownie zamontować dysk, używając sshfs z hasłem przekazanym przez sshpass.

Usuwanie Plików: Skrypt monitoruje użycie dysku i, jeśli przekroczone jest TARGET_USAGE, znajduje i usuwa najstarsze pliki w określonych katalogach aż do osiągnięcia docelowego poziomu wolnej przestrzeni.

#!/bin/bash

TARGET_USAGE=70
MOUNT_POINT="/mnt/qnapskorupki"
TARGET_DIRS="$MOUNT_POINT/up*.soban.pl"

# Function to check and mount SSHFS
function check_qnap {
    local remote_path="/share/MD0_DATA/backup_proxmox/"
    local user_remote="remote_user"
    local remote_host="192.168.1.XX"
    local port=22
    local password='XXXXXXXXXXXXXXXXXXXXXXX'

    # Check if the mounting directory exists and is empty
    if [ ! -d "$MOUNT_POINT" ] || [ -z "$(ls -A $MOUNT_POINT)" ]; then
        echo "Problem: The directory $MOUNT_POINT is missing or empty. Attempting to remount..."

        # Unmount if anything is currently mounted
        if mountpoint -q $MOUNT_POINT; then
            echo "Unmounting $MOUNT_POINT..."
            fusermount -u $MOUNT_POINT
            sleep 5
        fi

        # Remount
        echo "Mounting SSHFS: $user_remote@$remote_host:$remote_path to $MOUNT_POINT..."
        echo $password | sshfs $user_remote@$remote_host:$remote_path $MOUNT_POINT -o password_stdin

        # Check if the mounting was successful
        if mountpoint -q $MOUNT_POINT; then
            echo "QNAP successfully mounted."
        else
            echo "Error: Failed to mount $remote_host:$remote_path to $MOUNT_POINT."
            exit 1
        fi
    fi
}

# Check and mount the disk
check_qnap

# Begin deleting files
current_usage=$(df --output=pcent "$MOUNT_POINT" | tail -n 1 | tr -d '%')
echo "Current usage: $current_usage%"
target_free_space=$((100 - $TARGET_USAGE))

# Continue deleting files until the required free space is achieved
while [[ $current_usage -gt $TARGET_USAGE ]]; do
    # Find the oldest file in the target directories
    oldest_file=$(find $TARGET_DIRS -type f -printf '%T+ %p\n' | sort | head -n 1 | cut -d' ' -f2)

    if [ -z "$oldest_file" ]; then
        echo "No files to delete."
        break
    fi

    # Delete the oldest file
    echo "Deleting file $oldest_file..."
    rm -f "$oldest_file"

    # Check usage again
    current_usage=$(df --output=pcent "$MOUNT_POINT" | tail -n 1 | tr -d '%')
    echo "New usage after deletion: $current_usage%"
done

echo "Target disk usage achieved."

Przykładowe wywołanie skryptu:

skrypt będzie pracować aż do osiągnięcia 70% zgodnie z założeniem:

Pobieranie skryptu i dodawanie do crontaba

Skrypt oczywiście należy dostosować pod swoje wymagania, jednak jeśli chcesz go pobrać i dodać do crontaba to:

wget soban.pl/bash/remove_old_files.sh
chmod +x remove_old_files.sh

Jeśli chcemy zautomatyzować proces usuwania np pod koniec dnia, to warto dodać do crontaba następujący wpis:

crontab -e

Skrypt będzie się uruchamiać w tym przypadku o 23:55 każdego dnia:

45 23 * * * /root/scripts/remove_old_files.sh > /dev/null 2>&1

Należy zachować powyżej odpowiednią ścieżkę do skryptu.

Bezpieczeństwo i optymalizacja

Skrypt używa hasła wprost w linii komend, co może stanowić ryzyko bezpieczeństwa. W praktycznym zastosowaniu zaleca się użycie bardziej zaawansowanych metod autentykacji, na przykład kluczy SSH, które są bezpieczniejsze i nie wymagają jawnej obecności hasła w skrypcie. Jednak w przypadku QNAPa posłużyliśmy się hasłem pisząc ten skrypt.

Podsumowanie

Prezentowany skrypt jest przykładem, jak można automatyzować codzienne zadania administracyjne, takie jak zarządzanie przestrzenią dyskową, zwiększając tym samym efektywność i niezawodność operacji. Jego implementacja w realnych środowiskach IT może znacznie usprawnić procesy zarządzania danymi, zwłaszcza w sytuacjach, gdzie szybkie reagowanie na zmiany w użyciu dysku jest krytyczne.

Artykuł Automatyczne usuwanie najstarszych plików na zdalnym dysku QNAP przez SSHFS pochodzi z serwisu soban.

iftop oferuje różne opcje filtrowania, które pozwalają ograniczyć wyświetlane dane do konkretnych hostów, sieci lub portów. Obsługuje IPv6 oraz umożliwia wyświetlanie adresów IP źródłowych i docelowych, numerów portów oraz używanych protokołów.

Narzędzie to jest szczególnie przydatne do monitorowania ruchu w czasie rzeczywistym i identyfikowania usług lub hostów zużywających najwięcej przepustowości. Może również pomóc w wykrywaniu problemów wydajnościowych sieci oraz w diagnozowaniu usterek.

Podsumowując, iftop to lekkie, a jednocześnie bardzo skuteczne narzędzie stanowiące wartościowe uzupełnienie zestawu narzędzi każdego administratora systemów i sieci.

Jednym z najbardziej przydatnych narzędzi do monitorowania sieci, z których korzystam, jest iftop. Staje się szczególnie pomocne, gdy łącze sieciowe jest wysycone. W praktyce może również pomóc wykryć nietypowe wzorce ruchu, w tym ataki typu DoS. W poniższym przykładzie prześlę duży plik na maszynę zdalną z ograniczeniem przepustowości i będę obserwował ruch przy użyciu iftop.

Najpierw instalujemy iftop na maszynie lokalnej (w tym przypadku Kali Linux):

# apt install iftop

Dystrybucja nie ma większego znaczenia — iftop jest dostępny w większości repozytoriów Linuksa, w tym w Debianie.

Następnie instalujemy iftop na maszynie zdalnej (Debian Linux):

# apt install iftop

Aby rozpocząć monitorowanie ruchu sieciowego, uruchamiamy iftop z parametrami -PpNn:

# iftop -PpNn

Ponieważ jestem połączony z maszyną zdalną przez SSH, widzę swoją aktywną sesję SSH na liście połączeń.

Teraz wracamy na maszynę lokalną i tworzymy duży plik:

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

Po utworzeniu pliku 1GB przesyłamy go na maszynę zdalną z ograniczeniem przepustowości:

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

Opcja -l 800 ogranicza transfer do 800 Kbit/s. Aby przeliczyć to na KB/s, dzielimy przez 8 — otrzymujemy około 100 KB/s.

W ten sposób możemy obserwować zarówno ruch wychodzący, jak i przychodzący w czasie rzeczywistym. Choć iftop jest prostym narzędziem, zapewnia bardzo dobrą widoczność bieżącej aktywności sieciowej.

W przypadku prób brute-force widoczna będzie duża liczba krótkotrwałych połączeń. Natomiast atak DoS ma na celu wysycenie pasma, co objawia się znacznym ruchem przychodzącym. Jeśli wzrost ruchu jest uzasadniony, można rozważyć ograniczenie prędkości połączeń — pomocne będzie np. iptables.

Artykuł iftop jako dobre narzędzie do monitorowania ruchu sieciowego pochodzi z serwisu soban.

W tym przykładzie pracujemy na systemie Debian 11 (Bullseye). Najpierw sprawdźmy wersję systemu:

# cat /etc/issue
Debian GNU/Linux 11 \n \l

Nmap to jedno z najpotężniejszych narzędzi do skanowania sieci w systemach Linux. Umożliwia skanowanie otwartych portów, wykrywanie uruchomionych usług, identyfikację wersji oprogramowania oraz analizę obsługiwanych protokołów SSL/TLS i pakietów szyfrów.

Instalacja na Debianie 11 jest bardzo prosta:

# apt install nmap

Po instalacji możemy przeskanować zdalny serwer HTTPS. Przykład:

# nmap -sV --script ssl-enum-ciphers -p 443 google.com

Opcja -sV włącza wykrywanie wersji usług, natomiast --script ssl-enum-ciphers sprawdza obsługiwane wersje TLS oraz dostępne szyfry. Dzięki temu możemy zweryfikować:

• które wersje TLS są aktywne (TLS 1.0, 1.1, 1.2, 1.3),
• czy serwer obsługuje słabe szyfry, np. 3DES,
• czy występują potencjalne podatności kryptograficzne.

Nmap działa wolniej niż narzędzia takie jak sslscan, ale dostarcza bardzo szczegółowych informacji, co jest szczególnie przydatne podczas testowania infrastruktury wewnętrznej.

TLS 1.0:

TLS 1.1:

TLS 1.2:

Najważniejsze podczas analizy konfiguracji SSL/TLS jest sprawdzenie, czy serwer nie używa przestarzałych lub podatnych szyfrów.

Jeżeli w wynikach zobaczysz komunikat:
„64-bit block cipher 3DES vulnerable to SWEET32 attack”
oznacza to, że serwer obsługuje szyfr 3DES, który jest podatny na atak SWEET32. W środowisku produkcyjnym takie szyfry powinny zostać wyłączone.

Podczas testowania publicznych stron internetowych można również skorzystać z narzędzia online:
https://www.ssllabs.com/ssltest/

Jednak w przypadku serwerów wewnętrznych, środowisk testowych lub infrastruktury prywatnej, użycie Nmap bezpośrednio z systemu Debian jest często najlepszym rozwiązaniem. Regularne skanowanie SSL/TLS pozwala utrzymać wysoki poziom bezpieczeństwa i eliminuje przestarzałe protokoły oraz słabe mechanizmy szyfrowania.

Artykuł skanowanie ssl i szyfrów nmap pochodzi z serwisu soban.