Spis treści
Prawdziwy przypadek: sklep, który przestał sprzedawać
Czym właściwie jest atak DDoS?
Skanowanie portów – zwiadowca przed atakiem
Pierwsza linia obrony: zabezpiecz SSH
Prawie każda firma, z którą pracujemy, potrzebuje dziś jakiegoś serwera. W zdecydowanej większości przypadków to prosty hosting z WordPressem – strona wizytówkowa, formularz kontaktowy, może firmowy blog. I to w zupełności wystarcza. Ale coraz częściej trafiają do nas klienci, którzy potrzebują czegoś więcej: kalkulatora wyceny, panelu klienta z logowaniem, własnej bazy danych, integracji z automatyzacjami, albo sklepu internetowego opartego o WooCommerce. Dla takich projektów prosty shared hosting to za mało – stawiamy wtedy VPS-a, często tego samego, na którym trzyma się jednocześnie stronę, bazę danych, a czasem nawet integracje ze smart home czy urządzeniami IoT. Zdecydowana większość takich serwerów działa na Linuksie i to on będzie dziś bohaterem tego artykułu.
Dopóki wszystko działa, nikt się bezpieczeństwem serwera nie interesuje. Problem pojawia się nagle – i zwykle w najgorszym możliwym momencie.
Prawdziwy przypadek: sklep, który przestał sprzedawać
Jeden z takich projektów działał bez zarzutu przez wiele miesięcy. Sklep na WooCommerce, kilkadziesiąt zamówień dziennie, wszystko poukładane. Aż pewnego dnia klienci zaczęli zgłaszać, że strona się „zawiesza” w trakcie składania zamówienia – koszyk się nie ładował, płatność nie przechodziła, a czasem cała witryna po prostu przestawała odpowiadać na kilka minut. Zamówienia stanęły, a każda godzina przestoju sklepu internetowego to realnie stracone pieniądze.
Pierwsze podejrzenie padło oczywiście na wtyczki i limity hostingu. Dopiero przegląd logów serwera pokazał prawdziwy obraz sytuacji: setki prób logowania w krótkim czasie, z różnych adresów IP, non stop, przez całą dobę. Serwer był tak zajęty odpowiadaniem na te próby, że zwyczajnie brakowało mu zasobów, żeby normalnie obsłużyć sklep. To nie była awaria WooCommerce – to był atak.
Czym właściwie jest atak DDoS?
DDoS (Distributed Denial of Service) to atak polegający na zalaniu serwera ogromną liczbą zapytań z wielu różnych miejsc jednocześnie, tak żeby wyczerpać jego zasoby – procesor, pamięć, łącze sieciowe czy liczbę jednoczesnych połączeń. W efekcie serwer nie nadąża obsługiwać normalnego ruchu i strona przestaje działać dla zwykłych użytkowników. Słowo „distributed” jest tu kluczowe – atak nie idzie z jednego adresu IP (to dałoby się łatwo zablokować), tylko z tysięcy zainfekowanych urządzeń rozsianych po całym świecie, tworzących tzw. botnet. Część takiego ruchu to celowe zapytania HTTP, część to właśnie masowe próby logowania – jak w opisanym wyżej przypadku.
Skanowanie portów – zwiadowca przed atakiem
Zanim ktoś w ogóle spróbuje się do serwera dostać, najpierw musi sprawdzić, co na nim „słucha”. Służy do tego skanowanie portów – automatyczne sprawdzanie, które usługi są dostępne z zewnątrz: port 22 (SSH), 3306 (MySQL), 80/443 (strona www) i tak dalej. Narzędzia takie jak nmap potrafią przeskanować całe zakresy adresów IP w sieci w poszukiwaniu otwartych portów i podatnych wersji oprogramowania. To pierwszy krok każdego ataku – rekonesans. Dlatego jednym z podstawowych elementów zabezpieczenia serwera jest ograniczenie tego, co w ogóle jest widoczne z zewnątrz, i pilnowanie, żeby to, co musi być otwarte (np. SSH), było maksymalnie utrudnione do przejęcia.
Pierwsza linia obrony: zabezpiecz SSH
SSH to najczęstszy cel prób logowania na serwer, bo to standardowy sposób administrowania Linuksem. Kilka rzeczy, które warto zrobić od razu:
Wyłącz logowanie na konto root przez SSH. Root to konto z pełnymi uprawnieniami w systemie – jeśli ktoś je przejmie, ma wszystko. Zamiast tego zakładamy zwykłe konto użytkownika, nadajemy mu uprawnienia administracyjne przez sudo, a logowanie bezpośrednio jako root wyłączamy w pliku konfiguracyjnym SSH (/etc/ssh/sshd_config, opcja PermitRootLogin no). Dzięki temu atakujący musi zgadnąć nie tylko hasło, ale też nazwę konta, która nie jest z góry znana.
Włącz logowanie prób połączeń SSH. Chodzi o to, żeby system zapisywał każdą próbę logowania – udaną i nieudaną – wraz z adresem IP, godziną i kontem, którego dotyczyła. Na większości dystrybucji Linuksa te informacje trafiają domyślnie do /var/log/auth.log (Debian/Ubuntu) albo są dostępne przez journalctl -u ssh. To właśnie przegląd tych logów pozwolił w opisanym wyżej przypadku wykryć, że sklep padał ofiarą ataku, a nie zwykłej awarii. Bez logowania jesteśmy ślepi – nie wiemy, kto i jak często puka do naszych drzwi.
Miej zawsze otwartą, aktywną konsolę do serwera. Zanim zaczniesz cokolwiek zmieniać w konfiguracji SSH, otwórz dodatkowe okno terminala i zaloguj się do serwera – albo skorzystaj z konsoli awaryjnej dostępnej w panelu Twojego dostawcy VPS (większość, np. OVH, Hetzner czy DigitalOcean, taką konsolę oferuje). To Twoja siatka bezpieczeństwa. Jeśli coś pójdzie nie tak i stracisz dostęp przez normalne SSH, ta druga, wcześniej otwarta sesja pozwoli Ci naprawić błąd bez konieczności resetowania serwera od zera.
Przetestuj logowanie na nowym koncie, zanim wyłączysz logowanie hasłem. Docelowo najlepiej wyłączyć logowanie po haśle w ogóle i zostawić tylko logowanie kluczem SSH – to znacznie trudniejsze do złamania niż jakiekolwiek hasło. Ale zanim to zrobisz, koniecznie zaloguj się nowym kluczem z zupełnie nowej sesji terminala i upewnij się, że działa. Jeśli wyłączysz logowanie hasłem, a klucz nie jest poprawnie skonfigurowany, zostaniesz zablokowany na własnym serwerze – i wtedy przydaje się właśnie ta druga, otwarta konsola z poprzedniego punktu.
Automatyczna blokada: fail2ban
Ręczne przeglądanie logów i blokowanie adresów IP jednego po drugim nie ma sensu przy większej skali. Tu z pomocą przychodzą narzędzia takie jak fail2ban – działają w tle, na bieżąco analizują logi (np. właśnie ten auth.log) i automatycznie blokują adres IP, jeśli w krótkim czasie wykryją określoną liczbę nieudanych prób logowania – standardowo ustawia się to na 3 do 5 prób. Po przekroczeniu limitu fail2ban dodaje regułę do zapory sieciowej (iptables albo nftables), która na jakiś czas – lub na stałe – blokuje ruch z tego adresu.
Instalacja na Ubuntu/Debianie to w zasadzie dwie komendy:
sudo apt install fail2ban
sudo systemctl enable --now fail2banDomyślna konfiguracja już całkiem nieźle chroni SSH, ale warto dostosować limit prób i czas blokady w pliku /etc/fail2ban/jail.local.
Czasem pojedynczy atakujący próbuje logować się z wielu adresów IP z tej samej puli (np. tego samego dostawcy internetu czy centrum danych). W takich sytuacjach można zablokować całą pulę adresów naraz, korzystając z notacji CIDR, np.:
sudo iptables -A INPUT -s 203.0.113.0/24 -j DROPPowyższa reguła blokuje cały zakres 256 adresów IP zaczynających się od 203.0.113. To przydatne, gdy widzimy w logach powtarzający się wzorzec prób logowania z tej samej „maski” sieciowej.
Czy to nas w 100% uratuje?
Nie. I trzeba to jasno powiedzieć. Fail2ban, wyłączenie roota i mocne hasła świetnie radzą sobie z atakami „ogólnymi” – masowym brute-force’em, który boty prowadzą praktycznie non stop w internecie, próbując zgadnąć dostęp do losowych serwerów, często z zakresów IP kojarzonych z dużą liczbą takich prób. To trochę jak zamek w drzwiach – nie zatrzyma złodzieja, który celowo się do Ciebie włamuje, ale skutecznie zniechęci kogoś, kto po prostu sprawdza wszystkie drzwi na ulicy pod rząd.
Do tego warto dodać naprawdę mocne hasła – najlepiej 32-znakowe, generowane losowo i trzymane w menedżerze haseł, a nie zapamiętywane. Krótkie, „ludzkie” hasła da się złamać metodą brute-force w rozsądnym czasie, długie i losowe – praktycznie nie.
Jeśli jednak ktoś celowo i świadomie postanowił zaatakować akurat Twoją firmę – opłacony, ukierunkowany atak DDoS na dużą skalę – to fail2ban czy silne hasło niewiele tu pomogą, bo problem przenosi się na poziom sieci, a nie logowania. W takiej sytuacji najlepszym rozwiązaniem jest skorzystanie z wyspecjalizowanych usług ochrony przed DDoS (np. na poziomie dostawcy VPS albo CDN) albo firm zajmujących się bezpieczeństwem na poważnie – bo po drugiej stronie stoją wtedy osoby, które robią to zawodowo, i amatorskie środki nie wystarczą.
FAQ – Atak DDoS i skanowanie portów
Tak. Skanowanie portów i próby logowania nie są kierowane w konkretną firmę – boty sprawdzają masowo wszystkie serwery w internecie, niezależnie od tego, co się na nich znajduje.
Trochę ogranicza liczbę „przypadkowych” skanów, ale to nie jest zabezpieczenie samo w sobie – to tylko dodatkowa warstwa utrudnienia, nie zastępuje wyłączenia roota, fail2ban ani kluczy SSH.
Najprostszy sygnał to nietypowe obciążenie serwera bez wyraźnej przyczyny (wzrost ruchu, wolne działanie strony) połączone z dużą liczbą wpisów o nieudanych próbach logowania w logach (auth.log lub journalctl -u ssh).
Nie – to dobre uzupełnienie, nie zamiennik. Warto mieć też skonfigurowaną zaporę sieciową (np. ufw na Ubuntu), która domyślnie blokuje wszystkie porty poza tymi, które faktycznie muszą być otwarte.
Podsumowanie – Atak DDoS i skanowanie portów
Każdy serwer wystawiony do internetu – nawet ten trzymający „tylko” prostą stronę – jest regularnie skanowany i testowany przez boty szukające słabych punktów. Podstawowa higiena: wyłączenie logowania roota, osobne konta, logowanie prób dostępu, fail2ban i mocne, długie hasła – to nie jest opcja „dla zaawansowanych”, tylko absolutne minimum dla każdego serwera, na którym trzymamy dane, sklep czy automatyzacje. Nie zapewni to stuprocentowej ochrony, ale znacząco odciąży serwer i wyeliminuje zdecydowaną większość automatycznych ataków, zanim w ogóle zdążą narobić szkód. A jeśli podejrzewasz, że ktoś atakuje Cię celowo – nie próbuj radzić sobie z tym sam, tylko sięgnij po specjalistów.
O autorze
Kacper Baryłowicz – Software & DevOps Engineer
Specjalizuje się w zaawansowanej automatyzacji procesów biznesowych.
Nie ogranicza się tylko do pisania kodu – działa jako partner technologiczny dla biznesu, przekładając złożone wymagania na stabilne i solidne architektury. Niezależnie od tego, czy chodzi o konfigurację serwerów bare-metal, budowanie dedykowanych rozwiązań dla przedsiębiorstw (TMS/MES), czy projektowanie agentów konwersacyjnych opartych na AI – bierze pełną odpowiedzialność za cykl życia produktu: od samej koncepcji aż po wdrożenie produkcyjne.
