Zapora zastosowana dla pojedynczego serwera to jeden z najprostszych sposobów na zmniejszenie powierzchni ataku w środowisku biznesowym. Ogranicza, które systemy mogą się łączyć, skąd i w jakim celu. Ma to znaczenie nawet wtedy, gdy serwer znajduje się za grupą zabezpieczeń chmury, siecią wirtualną lub fizyczną zaporą brzegową.
Najbardziej niezawodnym punktem wyjścia jest polityka domyślnej odmowy: blokowanie niezamówionego ruchu przychodzącego, zezwalanie wyłącznie na udokumentowane usługi oraz kontrolowanie ruchu wychodzącego tam, gdzie uzasadnia to ryzyko. Reguły powinny odzwierciedlać rolę serwera, a nie być kopiowane z ogólnej listy portów. Publiczny serwer WWW, serwer baz danych, przekaźnik poczty i źródło kopii zapasowych mają różne wymagania.
Takie podejście ułatwia także ustalenie odpowiedzialności. Każdy serwer ma jasno określoną politykę sieciową, więc zapomniana usługa nie staje się automatycznie dostępna tylko dlatego, że nasłuchuje.
Zacznij od polityki domyślnej odmowy
Praktyczna zapora serwerowa zwykle obejmuje trzy warstwy podejmowania decyzji:
- Ruch przychodzący: domyślnie odmawiaj, a następnie zezwalaj tylko na porty wymagane przez uzasadnione usługi.
- Ruch wychodzący: zezwalaj na wymagane połączenia, ale w miarę możliwości ograniczaj wrażliwe lub niepotrzebne miejsca docelowe.
- Ruch wewnętrzny: zezwalaj tylko na komunikację potrzebną między określonymi rolami serwerów, sieciami lub systemami zarządzania.
Przed zmianą reguł udokumentuj funkcję serwera, działające na nim usługi, ich oczekiwanych klientów oraz to, czy klienci są publiczni, prywatni czy administracyjni. Przydatnymi źródłami są konfiguracja usług, grupy zabezpieczeń chmury, ustawienia modułu równoważenia obciążenia, rekordy DNS, dokumentacja aplikacji i dzienniki połączeń.
Nie traktuj portu jako bezpiecznego lub niebezpiecznego w oderwaniu od kontekstu. Numer portu wskazuje konwencjonalną usługę, a nie jakość jej konfiguracji. Port 443 może nadal ujawniać podatną aplikację, podczas gdy SSH na porcie 22 może być dobrze chronione, jeśli dostęp jest ograniczony, a uwierzytelnianie odpowiednio zabezpieczone. Zmiana domyślnego portu może ograniczyć skanowanie w tle, ale nie zastępuje kontroli dostępu.
Popularne porty usług i ryzyko ich ekspozycji
Zespoły często wyszukują popularne porty zapory serwera do otwarcia i zablokowania, ale po każdej liście powinna nastąpić decyzja dotycząca dostępu. Ważne pytanie nie brzmi tylko, czy usługa korzysta z danego portu, lecz także kto musi się z nią łączyć i z której sieci.
Porty 80 i 443: publiczne usługi WWW
Porty 80 i 443 są zwykle odpowiednie dla publicznej witryny lub aplikacji internetowej. Port 443 obsługuje HTTPS i powinien być głównym publicznym punktem wejścia. Port 80 może być potrzebny do przekierowań z HTTP do HTTPS, walidacji certyfikatów, zgodności ze starszymi rozwiązaniami lub celowo publicznej usługi HTTP.
Jeśli serwer znajduje się za odwrotnym proxy, CDN-em lub modułem równoważenia obciążenia, serwer źródłowy nie musi przyjmować ruchu WWW z całego internetu. Ograniczenie połączeń przychodzących do opublikowanych zakresów adresów proxy może zmniejszyć liczbę ataków bezpośrednio na serwer źródłowy. Upewnij się, że aplikacja nadal otrzymuje wiarygodne informacje o kliencie oraz że w projekcie uwzględniono kontrole stanu, odnawianie certyfikatów i procesy wdrażania.
W przypadku aplikacji wewnętrznej żaden z tych portów nie musi być publiczny. Zezwól na dostęp z sieci firmowej, VPN-u, bramy aplikacyjnej lub określonych prywatnych podsieci.
Port 22: bezpieczeństwo SSH
SSH jest niezbędne do administracji systemami Linux, automatyzacji i niektórych procesów transferu plików, ale globalna ekspozycja zaprasza do zgadywania haseł, ataków na dane uwierzytelniające oraz wykorzystywania słabości stosu SSH lub jego otaczającej konfiguracji.
Aby zapewnić silne bezpieczeństwo SSH, zezwalaj na port 22 wyłącznie z zakresu adresów VPN, firmowego adresu wyjściowego, odpowiednio zabezpieczonego serwera bastionowego lub prywatnej sieci zarządzania. Preferuj uwierzytelnianie oparte na kluczach, w miarę możliwości wyłącz bezpośrednie logowanie hasłem, ogranicz dostęp uprzywilejowany i stosuj oddzielne nazwane konta z audytowanym podnoszeniem uprawnień. Uwierzytelnianie wieloskładnikowe może dodać kolejną warstwę ochrony, szczególnie gdy dostęp administracyjny przebiega przez niezaufaną sieć.
Przeniesienie SSH na inny port może ograniczyć ilość szumu w logach, ale nie sprawi, że usługa dostępna z internetu stanie się prywatna. Jeśli zdalna administracja jest sporadyczna, VPN lub reguła zapory aktywowana na żądanie są zwykle lepszym zabezpieczeniem niż poleganie na ukrywaniu usługi.
Port 3389: bezpieczeństwo RDP
RDP jest atrakcyjnym celem, ponieważ zapewnia interaktywny dostęp do systemów Windows. Port 3389 nie powinien być normalnie otwarty na publiczny internet. Korzystaj z VPN-u, sieci prywatnej, bramy zdalnego dostępu lub usługi bastionowej i ograniczaj adresy źródłowe do zatwierdzonych sieci administracyjnych.
Dobre bezpieczeństwo RDP zależy także od uwierzytelniania na poziomie sieci, silnych mechanizmów kontroli tożsamości, aktualizacji, blokady kont lub równoważnych zasad wykrywania oraz ograniczenia listy administratorów, którzy mogą się logować. Jeśli dostęp jest potrzebny zewnętrznemu zespołowi wsparcia, zapewnij mu określoną trasę i uprawnienia ograniczone czasowo zamiast stałej reguły zezwalającej na dostęp z dowolnego źródła.
Port 25: SMTP
Port 25 służy do dostarczania poczty między serwerami. Serwer pocztowy, który bezpośrednio wysyła lub odbiera pocztę, może go wymagać, choć dostawcy i sieci nadrzędne czasami ograniczają wychodzący SMTP w celu zmniejszenia nadużyć. Serwer, który nie obsługuje usług pocztowych, nie powinien udostępniać portu 25.
Nie zakładaj, że zezwolenie na wychodzący port 25 na każdym serwerze jest nieszkodliwe. Zainfekowany serwer aplikacyjny może stać się źródłem spamu lub zaszkodzić reputacji organizacji w zakresie poczty. Jeśli to możliwe, kieruj pocztę aplikacyjną przez zatwierdzony przekaźnik i zezwalaj na wychodzący SMTP wyłącznie do tego przekaźnika. Przychodzący port 25 powinien być ograniczony do rzeczywistej roli związanej z obsługą poczty, a mechanizmy przeciwdziałania nadużyciom należy zarządzać oddzielnie.
Port 53: DNS
DNS korzysta zarówno z portu UDP 53, jak i TCP 53. Rekursor może potrzebować odpowiadać na zapytania klientów z sieci wewnętrznej, natomiast autorytatywny serwer DNS może odpowiadać na zapytania publiczne. Są to różne role i nie należy ich bezrefleksyjnie łączyć.
Nigdy nie udostępniaj w internecie otwartego rekursora. Ogranicz rekursję do zatwierdzonych sieci, zezwalaj na transfery stref wyłącznie między wyznaczonymi serwerami nazw i zezwalaj na TCP 53 tam, gdzie wymagają tego duże odpowiedzi, DNSSEC lub operacje transferu stref. Serwer, który tylko korzysta z DNS, powinien zwykle wysyłać zapytania wychodzące do określonych resolverów, a nie przyjmować przychodzącego ruchu DNS.
Porty 3306 i 5432: MySQL i PostgreSQL
MySQL zwykle nasłuchuje na porcie 3306, a PostgreSQL na porcie 5432. Porty te niemal nigdy nie powinny być publiczne. Bazy danych zawierają cenne dane biznesowe i często stają się celami ataków na dane uwierzytelniające, prób wykrywania błędnej konfiguracji oraz wykorzystywania niezałatanych luk w oprogramowaniu.
Zezwalaj na ruch do bazy danych wyłącznie z serwerów aplikacyjnych, systemów raportowych, administracyjnego serwera bastionowego lub prywatnej sieci, które rzeczywiście tego potrzebują. Korzystaj z uwierzytelniania właściwego dla bazy danych, szyfrowania, jeśli jest obsługiwane, kont o minimalnych uprawnieniach oraz reguł sieciowych zgodnych z topologią aplikacji. Powiązanie bazy danych z prywatnym interfejsem jest przydatne, ale powinno uzupełniać zaporę, a nie ją zastępować.
Panele sterowania, interfejsy orkiestracji, konsole hipernadzorców i punkty końcowe monitoringu wymagają takiego samego podejścia. Powinny być dostępne wyłącznie przez sieć zarządzania, VPN lub ściśle kontrolowaną listę dozwolonych adresów. Publicznie dostępny interfejs zarządzania może sprawić, że jedno skradzione hasło lub niezałatany komponent doprowadzi do przejęcia serwera, a potencjalnie także jego połączonego środowiska.
Oddziel ruch publiczny, aplikacyjny i zarządzający
Reguły portów są skuteczniejsze, gdy sieć jest podzielona na segmenty. Typowe wdrożenie w małej firmie może rozdzielać:
- Usługi publiczne: usługi WWW lub pocztowe, które muszą przyjmować połączenia z internetu.
- Usługi aplikacyjne: API, kolejki i wewnętrzne komponenty aplikacji dostępne wyłącznie z zatwierdzonych systemów.
- Usługi danych: bazy danych i pamięć masowa dostępne tylko z sieci aplikacyjnych lub administracyjnych.
- Usługi zarządzania: SSH, RDP, panele sterowania, monitoring i narzędzia orkiestracji dostępne wyłącznie przez prywatne ścieżki administracyjne.
- Łączność z kopiami zapasowymi: połączenia wychodzące z chronionych serwerów do zatwierdzonego miejsca przechowywania kopii, bez ogólnego dostępu przychodzącego do repozytorium kopii.
Ten model ogranicza ruch boczny. Jeśli publiczna usługa WWW zostanie przejęta, atakujący nie powinien automatycznie mieć możliwości połączenia z bazą danych, hipernadzorcą ani systemem kopii zapasowych. Reguły zapory powinny określać rolę źródła i miejsca docelowego, a nie zezwalać na całą sieć wirtualną tylko dlatego, że jest to wygodne.
Ruch wewnętrzny również wymaga kontroli. Prywatne adresy IP nie są automatycznie zaufane. Zainfekowany serwer wewnętrzny może skanować i atakować inny system równie skutecznie jak host internetowy. Stosuj zasadę najmniejszych uprawnień między podsieciami i rolami serwerów oraz unikaj szerokich reguł, takich jak zezwolenie na każdy port z każdego adresu wewnętrznego.
Chroń łączność z kopiami zapasowymi i kopiami odtworzeniowymi
Ruch kopii zapasowych wymaga zaplanowanej ścieżki, ponieważ systemy kopii są cennymi celami. Często bezpieczniejszy jest model, w którym kontrolowany przez klienta serwer źródłowy inicjuje połączenie wychodzące z usługą kopii zapasowych, podczas gdy połączenia przychodzące z internetu do repozytorium pozostają zablokowane. Zezwalaj wyłącznie na miejsce docelowe, protokół i kierunek wymagane przez projekt kopii zapasowych.
Nie publikuj bezpośrednio w internecie repozytorium kopii, punktu końcowego pamięci masowej ani interfejsu zarządzania kopiami. Jeśli produkt do tworzenia kopii wymaga komunikacji przychodzącej, umieść ją za siecią prywatną, VPN-em lub ściśle ograniczoną listą dozwolonych adresów i udokumentuj, dlaczego jest konieczna. Oddziel dane uwierzytelniające kopii od danych produkcyjnych i unikaj używania konta administratora domeny do operacji związanych z kopiami.
Safenix zapewnia pozasiedzibowe kopie zapasowe dla serwerów biznesowych kontrolowanych przez klienta. Kopie są szyfrowane kluczem, którego Safenix nigdy nie przechowuje, przechowywane w Niemczech i niezmienne przez cały okres retencji. Klient nadal powinien ograniczyć połączenia kopii na zaporze źródłowej i zezwolić wyłącznie na ruch potrzebny do połączenia z usługą. Szczegóły dotyczące biznesowych kopii zapasowych serwerów i ochrony pozasiedzibowego odtwarzania Safenix można przeanalizować wraz z projektem zapory klienta.
Ujawniona łączność z kopiami stwarza dwa zagrożenia. Atakujący może wykorzystać ją jako drogę do platformy kopii lub zakłócić działanie, usunąć albo zaszyfrować kopie odtworzeniowe. Ograniczenie ruchu kopii i zapewnienie jego jednokierunkowości tam, gdzie to możliwe, zmniejsza ryzyko, że przejęcie serwera produkcyjnego stanie się także przejęciem środowiska odtwarzania.
Reguły IPv4 i IPv6 muszą być zgodne
Częstym błędem w konfiguracji zapory jest zabezpieczenie IPv4 przy jednoczesnym pozostawieniu szerokiej dostępności przez IPv6. Jeśli serwer ma publiczny adres IPv6, potrzebuje polityki zapory IPv6 z taką samą zasadą domyślnej odmowy, ograniczeniami usług i oczekiwaniami dotyczącymi logowania jak w przypadku IPv4.
Nie zakładaj, że wyłączenie reguły IPv4 chroni usługę. Sprawdź adresy nasłuchu, grupy zabezpieczeń chmury, konfigurację zapory hosta i mechanizmy kontroli na poziomie dostawcy dla obu protokołów. Jeśli IPv6 nie jest potrzebne, wyłącz je dopiero po potwierdzeniu, że aplikacje, monitoring, DNS i zależności sieciowe nadal będą działać. W przeciwnym razie odpowiednio je utrzymuj.
Analizuj ruch wychodzący IPv6 tak samo jak przychodzący. Aplikacja, która może łączyć się z systemami zewnętrznymi przez niemonitorowaną rodzinę adresów, może ominąć założenia przyjęte w projekcie bezpieczeństwa opartym wyłącznie na IPv4.
Reguły wychodzące, logowanie i alerty
Blokowanie całego ruchu wychodzącego rzadko jest praktyczne w przypadku serwera biznesowego. Aktualizacje, DNS, synchronizacja czasu, poczta elektroniczna, API, monitoring i kopie zapasowe mogą wymagać dostępu wychodzącego. Rozsądna polityka zaczyna się od zidentyfikowania tych zależności, a następnie ograniczenia miejsc docelowych i portów tam, gdzie uzasadnia to ryzyko operacyjne.
Na przykład serwer aplikacyjny może potrzebować HTTPS do określonych usług programowych, DNS do zatwierdzonych resolverów, NTP do zatwierdzonych źródeł czasu oraz wychodzącego połączenia z systemem kopii zapasowych. Może nie mieć żadnego powodu, aby łączyć się z dowolnymi serwerami SMTP, portami baz danych lub usługami zdalnej administracji w internecie.
Rejestruj odrzucony ruch, ale dbaj o to, aby logi były użyteczne, a nie przytłaczające. Zapisuj źródło, miejsce docelowe, port, protokół, interfejs, działanie i znacznik czasu. Ograniczaj częstotliwość powtarzających się zdarzeń i przesyłaj ważne logi do lokalizacji, którą atakujący nie może łatwo zmienić. Generuj alerty dotyczące wzorców takich jak powtarzające się próby SSH lub RDP, skanowanie wielu portów, nieoczekiwany wychodzący SMTP, nowy dostęp do portów baz danych lub nagła zmiana zachowania połączeń z systemem kopii zapasowych.
Logowanie powinno wspierać analizę, a nie zastępować zapobieganie. Reguła generująca codziennie tysiące alertów prędzej czy później będzie ignorowana. Dostosuj progi do normalnego ruchu i określ, kto przegląda alerty, jak szybko to robi oraz jakie dowody należy przechowywać.
Jak agencje mogą zarządzać wieloma środowiskami klientów
Agencje potrzebują spójności, ale nie powinny udawać, że każdy klient ma taką samą architekturę. Rozwiązaniem jest kontrolowana baza standardowa z udokumentowanymi wyjątkami.
- Twórz szablony oparte na rolach dla serwerów WWW, aplikacyjnych, baz danych, pocztowych, administracji Windows i źródeł kopii zapasowych.
- Używaj zmiennych dla zakresów adresów klienta, adresów VPN, prywatnych podsieci i zatwierdzonych miejsc docelowych usług zamiast wpisywać założenia na stałe.
- Jeśli platforma na to pozwala, przechowuj reguły zapory jako konfigurację objętą kontrolą wersji, z przeglądem równorzędnym i rejestrem zmian.
- Stosuj standardową konwencję nazewnictwa reguł, obejmującą cel, źródło, miejsce docelowe, właściciela i datę przeglądu.
- Wykorzystuj automatyzację do testowania składni, potwierdzania, że wymagane porty nasłuchują, oraz sprawdzania zgodności polityk IPv4 i IPv6.
- Procedury awaryjnego dostępu przechowuj oddzielnie i ograniczaj czasowo, w miarę możliwości z automatycznym wygasaniem.
Przed wdrożeniem szablonu przygotuj wykaz usług. Sprawdź dokumentację aplikacji, aktywne połączenia i zadania zaplanowane, a także zapytaj klienta, którzy zewnętrzni dostawcy potrzebują dostępu. Krótki etap rozpoznania jest tańszy niż przerwanie działania integracji rozliczeniowej, agenta monitoringu lub potoku wdrożeniowego.
Wprowadzaj zmiany etapami. Jeśli jest to możliwe, zastosuj proponowaną politykę w trybie audytu lub logowania, porównaj zaobserwowany ruch z zamierzonym projektem, a następnie egzekwuj ją w oknie serwisowym. Zachowaj dostępną konsolę poza pasmem lub ścieżkę odzyskiwania, aby administrator nie został zablokowany przez błędną regułę.
Zapory VPS a hosting współdzielony
VPS daje klientowi kontrolę nad systemem operacyjnym, zainstalowanymi usługami i zwykle zaporą na poziomie hosta. Oznacza to, że klient lub jego agencja odpowiada za decyzję, które porty nasłuchują i które źródła mogą się z nimi łączyć, wraz z uwzględnieniem mechanizmów kontroli oferowanych przez platformę hostingową.
Hosting współdzielony działa inaczej. Wielu klientów korzysta ze środowiska zarządzanego przez dostawcę, a dostawca kontroluje zabezpieczenia brzegowe, izolację sieci i ekspozycję usług. Klient zazwyczaj nie może zastosować kompletnej polityki zapory dla pojedynczego serwera do hosta bazowego ani zmienić przychodzących reguł dostawcy. Aby poznać przydatne rozróżnienie między infrastrukturą VPS zarządzaną przez klienta a usługami hostingu współdzielonego, zobacz to źródło informacji o infrastrukturze VPS i hostingu.
To rozróżnienie ma znaczenie dla planowania bezpieczeństwa. Witryna na hostingu współdzielonym nie jest tym samym co kontrolowany przez klienta serwer biznesowy z zaporą systemu operacyjnego. Safenix chroni serwery kontrolowane przez klienta; nie zapewnia planu tworzenia kopii dla witryny tylko dlatego, że jest ona hostowana współdzielone. Możliwości dostawcy hostingu i odpowiedzialność klienta należy potwierdzić przed zaprojektowaniem procedur tworzenia kopii i odtwarzania.
Przeglądaj reguły zapory w ramach działań operacyjnych
Polityka zapory staje się nieaktualna, gdy tylko zmienią się usługi, dostawcy, sieci lub administratorzy. Przeglądaj reguły co najmniej okresowo oraz po istotnych zmianach architektury, migracjach, incydentach bezpieczeństwa lub zmianach personelu.
Podczas przeglądu usuń reguły bez właściciela, źródła lub udokumentowanego celu biznesowego. Sprawdź tymczasowe listy dozwolonych adresów, których nigdy nie odwołano, zbyt szerokie zakresy sieci, zduplikowane wpisy, nieużywane usługi nasłuchujące i porty zarządzania ujawnione przez IPv6. Potwierdź, że interfejsy baz danych i kopii zapasowych nadal pozostają prywatne oraz że usługi publiczne korzystają z aktualnych certyfikatów i bezpiecznych konfiguracji.
Prowadź prosty rejestr każdego wyjątku: co umożliwia, dlaczego istnieje, kto go zatwierdził, kiedy należy go przejrzeć i co mogłoby go zastąpić. Dzięki temu administracja zaporą przestaje być zbiorem doraźnych poprawek i staje się powtarzalnym mechanizmem kontroli.
Zapora dla pojedynczego serwera z domyślną odmową nie zapobiegnie każdemu przejęciu, ale może zablokować wiele niepotrzebnych dróg do systemu i ograniczyć przemieszczanie się atakującego po incydencie. Połącz ją z utwardzonym uwierzytelnianiem, zarządzaniem poprawkami, segmentacją, monitoringiem i chronionymi pozasiedzibowymi kopiami zapasowymi. Rezultatem jest mniejsza powierzchnia ataku i bardziej niezawodna droga do odtworzenia działania, gdy serwer lub sieć przestają być godne zaufania.