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.
Install CrowdSec
Shell
1
2
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.
Install firewall bouncer
Shell
1
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.
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),
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.
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:
Jeśli chcesz zobaczyć co skrypt zrobi, ale bez wykonywania zmian:
Dry run
Shell
1
2
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.
Debug wget/PATH
Shell
1
2
3
4
echo"$PATH"
command-vwget||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.
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:
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.
Disable USB autosuspend (temporary)
Shell
1
echo-1>/sys/module/usbcore/parameters/autosuspend
Następnie uruchom aktualizację:
Run update
Shell
1
2
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:
Dock requires unplug
Shell
1
2
The update will continuewhen the device USB cable has been unplugged.
WD19S ispending activation;usefwupdmgr activate tocomplete 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ę:
Activate staged update
Shell
1
fwupdmgr activate
Na końcu sprawdź status:
Verify
Shell
1
2
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:
# 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"
exit1
}
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:
Run script
Shell
1
2
chmod+xdell_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.
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ę.
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.
.bash_tmux
Shell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
#!/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)
forarg 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
commandssh"$@"
# Restore the original window name after logout
tmux rename-window"$local_host"
else
# Not in Tmux — just run ssh normally
commandssh"$@"
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:
Reload tmux config
Shell
1
tmux source-file~/.tmux.conf
Dodatkowo możesz przeładować bieżącą powłokę z .bash_tmux ręcznie:
Reload shell
Shell
1
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 💪
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:
Instalacja SSHFS i sshpass
Shell
1
2
sudo apt-getupdate
sudo apt-getinstall 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.
Pełny Skrypt Bash
Shell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
#!/bin/bash
TARGET_USAGE=70
MOUNT_POINT="/mnt/qnapskorupki"
TARGET_DIRS="$MOUNT_POINT/up*.soban.pl"
# Function to check and mount SSHFS
functioncheck_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
ifmountpoint-q$MOUNT_POINT;then
echo"Unmounting $MOUNT_POINT..."
fusermount-u$MOUNT_POINT
sleep5
fi
# Remount
echo"Mounting SSHFS: $user_remote@$remote_host:$remote_path to $MOUNT_POINT..."
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.
iftop to narzędzie wiersza poleceń służące do monitorowania przepustowości sieci w czasie rzeczywistym. Wyświetla na bieżąco aktualizowaną listę połączeń sieciowych wraz z ilością przesłanych danych między nimi. Połączenia prezentowane są w formie tabeli i mogą być sortowane według wykorzystania pasma.
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):
Shell
1
# 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):
Shell
1
# apt install iftop
Aby rozpocząć monitorowanie ruchu sieciowego, uruchamiamy iftop z parametrami -PpNn:
Shell
1
# 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:
Shell
1
# truncate -s 1G 1G-file.txt
Po utworzeniu pliku 1GB przesyłamy go na maszynę zdalną z ograniczeniem przepustowości:
Shell
1
# 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.
Nmap – skanowanie SSL/TLS i szyfrów na Debianie 11
W tym przykładzie pracujemy na systemie Debian 11 (Bullseye). Najpierw sprawdźmy wersję systemu:
Shell
1
2
# cat /etc/issue
Debian GNU/Linux11\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:
Shell
1
# apt install nmap
Po instalacji możemy przeskanować zdalny serwer HTTPS. Przykład:
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.
