Ransomware 2025: Hardening Serwerów i Reguła Backupu 3-2-1 dla MŚP

Ransomware ewoluuje: cel to już nie dane, lecz kopie zapasowe

Jeszcze kilka lat temu standardową odpowiedzią na incydent ransomware było: „Mamy backup, odtworzymy dane". Dziś to zdanie może okazać się fałszywym pocieszeniem. Nowoczesne grupy cyberprzestępcze — RansomHub, LockBit 4.0, Akira czy BlackSuit — poświęcają tygodnie na niezauważone penetrowanie sieci firmowej, zanim uruchomią właściwy ładunek szyfrujący. W tym czasie kartografują infrastrukturę, identyfikują serwery backupowe, udziały sieciowe NAS i harmonogramy zadań kopii zapasowych. Cel jest jeden: zniszczyć lub zaszyfrować kopie zapasowe przed zaszyfrowaniem danych produkcyjnych, pozbawiając organizację możliwości samodzielnego odtworzenia.

Z perspektywy ponad 23 lat pracy inżynierskiej w AbejaIT przy projektowaniu i zabezpieczaniu infrastruktury dla firm z sektora MŚP, widzę ten problem jako fundamentalny błąd architektoniczny — nie tylko techniczny. Firmy inwestują w zapory ogniowe i antywirus, a zaniedbują spójną strategię odtwarzania po katastrofie (Disaster Recovery). Ten artykuł to inżynieryjna odpowiedź na rosnące zagrożenie: konkretna checklista hardeningu i architektura backupu, którą możesz wdrożyć lub zlecić swojemu zespołowi IT już teraz.

Anatomia nowoczesnego ataku ransomware na infrastrukturę MŚP

Faza 1 — Wejście do sieci (Initial Access)

Najczęstsze wektory wejścia to:

• Phishing z załącznikiem lub linkiem — wiadomość e-mail podszywająca się pod fakturę, dokument HR lub powiadomienie z banku.
• Podatne usługi eksponowane na internet — RDP (port 3389) bez VPN, stare wersje Fortinet VPN, PulseSecure, Citrix.
• Słabe hasła lub brak MFA na koncie administratora domeny lub panelu zarządzania chmurą.
• Złośliwe oprogramowanie w oprogramowaniu firm trzecich — atak łańcucha dostaw (supply chain attack).

Faza 2 — Rozpoznanie i eskalacja uprawnień (Reconnaissance & Privilege Escalation)

Po wejściu do sieci atakujący cierpliwie (często przez 14–30 dni) mapują infrastrukturę. Używają narzędzi takich jak BloodHound, Mimikatz, Cobalt Strike. Ich cel to konto Domain Admin lub lokalne konto administratora na serwerze backupowym. W tym momencie firma najczęściej nie ma żadnej świadomości incydentu.

Faza 3 — Uderzenie w backup i szyfrowanie

Atakujący najpierw kasują lub szyfrują kopie zapasowe (VSS Shadow Copies, Veeam repositories, NAS udziały), a dopiero potem uruchamiają szyfrowanie produkcyjne. Średni czas między wejściem a aktywacją ransomware to według raportów Mandiant i Sophos około 9–11 dni. To czas, w którym zainfekowane kopie mogły być już wielokrotnie nadpisane przez harmonogram backupu.

Kluczowy wniosek inżynierski: Backup podłączony do sieci firmowej i dostępny przez te same konta domenowe co serwery produkcyjne NIE jest prawdziwym backupem — to dodatkowy cel ataku.

Reguła 3-2-1 — fundament, który dziś wymaga rozszerzenia do 3-2-1-1-0

Klasyczna reguła 3-2-1 głosi:

• 3 kopie danych (oryginał + 2 kopie),
• 2 różne nośniki (np. dysk lokalny + taśma lub NAS),
• 1 kopia poza siedzibą firmy (off-site).

W obliczu nowoczesnych ataków ransomware branża przeszła do modelu 3-2-1-1-0:

• +1 — jedna kopia musi być immutable (niezmienna, air-gapped lub WORM), niedostępna przez standardowe konta sieciowe,
• +0 — zero błędów przy testowym odtwarzaniu: backup nieprzetestowany to backup nieistniejący.

Technologie immutable backup w praktyce

• Veeam Backup & Replication z Hardened Linux Repository — dedykowany serwer Linux z single-use credentials, immutable flag w systemie plików XFS, brak możliwości logowania przez konta domenowe.
• Object storage z Object Lock (S3 API) — np. MinIO on-premise, Wasabi, Backblaze B2 lub AWS S3 z włączonym Object Lock w trybie COMPLIANCE lub GOVERNANCE.
• Taśmy LTO z air-gap — fizyczne odłączenie nośnika od sieci; kosztowne, ale w kontekście krytycznych danych niezbędne.
• Offsite backup do chmury publicznej z osobnym kontem i MFA odizolowanym od środowiska produkcyjnego (AWS, Google Cloud, Azure).

Inżynieryjna checklista hardeningu serwerów — Linux i Windows

Serwery Linux (Debian, Ubuntu, RHEL/Rocky Linux)

• ✅ Wyłącz logowanie root przez SSH (PermitRootLogin no w /etc/ssh/sshd_config).
• ✅ Logowanie wyłącznie kluczami SSH — hasła wyłączone (PasswordAuthentication no).
• ✅ Zmień domyślny port SSH (lub użyj port knocking / VPN jako bramy).
• ✅ Wdróż fail2ban lub sshguard — automatyczne blokowanie IP po nieudanych próbach logowania.
• ✅ Zapora systemowa: UFW lub nftables — reguła domyślna DENY, białe listy IP dla administracji.
• ✅ Automatyczne aktualizacje bezpieczeństwa: unattended-upgrades (Debian/Ubuntu) lub dnf-automatic (RHEL).
• ✅ Audyt uprawnień: Lynis lub OpenSCAP — regularne skanowanie konfiguracji pod kątem CIS Benchmarks.
• ✅ AppArmor (Ubuntu) lub SELinux (RHEL) w trybie enforcing — ograniczenie uprawnień procesów do minimum.
• ✅ Monitorowanie integralności plików: AIDE lub Wazuh — alerty przy nieautoryzowanych zmianach w systemie.
• ✅ Centralne logowanie: wszystkie logi systemowe przesyłane do zewnętrznego SIEM (np. Wazuh, Graylog) — uniemożliwia atakującemu zatarcie śladów.

Serwery Windows Server (2019/2022)

• ✅ Wyłącz SMBv1 — protokół eksploatowany przez WannaCry i jego następców.
• ✅ Włącz Windows Defender Credential Guard i LSA Protection — ochrona przed Mimikatz.
• ✅ RDP wyłącznie przez VPN lub Microsoft Entra ID Application Proxy — zero ekspozycji na publiczny internet.
• ✅ LAPS (Local Administrator Password Solution) — unikalne, rotowane hasła lokalnych administratorów na każdej maszynie.
• ✅ Zasada najmniejszych uprawnień (Least Privilege) — żaden użytkownik dzienny nie pracuje na koncie Domain Admin.
• ✅ Windows Event Forwarding do centralnego serwera logów — zdarzenia 4624, 4625, 4648, 4688, 4698 (harmonogramy zadań) jako sygnały wczesnego ostrzegania.
• ✅ Wyłącz PowerShell v2 (Disable-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2Root) — brak modułu logging.
• ✅ Constrained Language Mode w PowerShell dla kont nieuprzywilejowanych.
• ✅ Regularne testy odtwarzania VSS Shadow Copies — i jednoczesne wdrożenie immutable backup (VSS to za mało!).

Monitoring 24/7 jako system wczesnego ostrzegania

Hardening to prewencja. Monitoring to detekcja. Obydwa elementy są niezbędne — bez monitoringu nie wiesz, że hardening działa (lub nie działa). Dla środowisk MŚP rekomendujemy stack:

• Zabbix lub Prometheus + Grafana — monitoring zasobów, anomalii w ruchu sieciowym, procesów systemowych.
• Wazuh (open-source SIEM/EDR) — korelacja zdarzeń, detekcja technik MITRE ATT&CK, alerty o podejrzanych procesach.
• Alerty SMS/email przy krytycznych zdarzeniach — nieudane logowania, zmiany plików systemowych, wyłączenie usług backupowych.

Zespół AbejaIT oferuje monitoring serwerów 24/7 z reakcją inżynierską i zdefiniowanymi SLA — zarówno dla środowisk on-premise, jak i chmurowych. Wdrożony stack monitoringu wielokrotnie pozwolił naszym klientom wykryć incydent w fazie rozpoznania, zanim atakujący zdążył zaszyfrować jakiekolwiek dane.

Architektura disaster recovery dla MŚP — krok po kroku

Krok 1: Inwentaryzacja i klasyfikacja danych

Zidentyfikuj, które dane są krytyczne dla ciągłości operacji (dane klientów, faktury, baza ERP, konfiguracje serwerów). Określ RTO (Recovery Time Objective) — maksymalny dopuszczalny czas przerwy, i RPO (Recovery Point Objective) — maksymalną dopuszczalną utratę danych w czasie.

Krok 2: Wdrożenie backupu zgodnego z 3-2-1-1-0

Lokalny backup automatyczny (Veeam, Bacula, Restic), kopia na NAS lub taśmę (inny nośnik), kopia offsite do chmury (izolowane konto), co najmniej jedna kopia immutable z Object Lock. Testy odtwarzania: minimum raz na kwartał, wyniki dokumentowane.

Krok 3: Segmentacja sieci

Serwer backupowy musi być w oddzielnym VLAN-ie, bez dostępu z sieci domenowej przez standardowe konta. Komunikacja jednokierunkowa — serwer backupowy „pobiera" dane, nie jest dostępny jako udział sieciowy.

Krok 4: Plan reagowania na incydenty (IRP)

Pisemna procedura: kto co robi w przypadku detekcji ransomware? Izolacja segmentu sieci, powiadomienie zarządu, kontakt z CERT Polska, ocena zakresu szyfrowania, decyzja o odtworzeniu z backupu. Bez pisemnego planu każda firma improwizuje w najgorszym możliwym momencie.

Jak AbejaIT wspiera firmy w budowie odporności na ransomware

Od ponad 23 lat projektujemy, wdrażamy i administrujemy infrastrukturą IT dla polskich przedsiębiorstw — od małych firm wieloosobowych po rozbudowane środowiska produkcyjne z setkami stacji roboczych. Nasze usługi administracji serwerami i infrastruktury IT obejmują pełen cykl: od audytu podatności, przez hardening konfiguracji, po wdrożenie systemu backupu z immutable repository i monitoring 24/7.

Niezależnie od tego, czy prowadzisz skup surowców z systemem ESSW (zlom.io), skład węgla z wegiel.io, czy zarządzasz finansami firmy przez mojafirma.io — wszystkie te systemy operują na danych, których utrata lub zaszyfrowanie oznacza bezpośrednie straty operacyjne i prawne. Ochrona infrastruktury to ochrona ciągłości Twojego biznesu.

Podsumowanie — co zarząd i dyrektor IT powinni zrobić w ciągu 30 dni

• 🔐 Tydzień 1: Audyt uprawnień — usuń zbędne konta admin, wdróż MFA na wszystkich usługach zdalnego dostępu.
• 💾 Tydzień 2: Weryfikacja backupu — sprawdź, czy kopie są izolowane od sieci domenowej i przetestuj odtworzenie.
• 🛡️ Tydzień 3: Hardening — zastosuj checklistę dla Linux i Windows, uruchom automatyczne aktualizacje bezpieczeństwa.
• 📊 Tydzień 4: Monitoring — wdróż SIEM lub zleć monitoring 24/7, opracuj pisemny plan IRP.

Ransomware to nie kwestia „czy" uderzy, lecz „kiedy". Firmy, które traktują cyberbezpieczeństwo jako jednorazowy projekt, a nie ciągły proces, płacą okup lub tracą dane. Firmy, które traktują je jako architekturę — przetrwają incydent i wznowią działanie w godzinach, nie tygodniach.

Jeśli chcesz przeprowadzić audyt bezpieczeństwa swojej infrastruktury lub wdrożyć opisaną architekturę backupu i hardeningu — skontaktuj się z naszym zespołem inżynierów AbejaIT. Przeanalizujemy Twoje środowisko i zaproponujemy konkretny, skrojony na miarę plan działania.

Źródło inspiracji: CERT Polska