Jak monitorować port TCP (i kiedy alertować o jego otwarciu)

Monitorowanie portów to dwa zadania w jednym. Czasami chcesz wiedzieć, że usługa nasłuchuje, na przykład baza danych lub relay SMTP. Czasami chcesz mieć pewność, że port pozostaje odcięty przez firewall, jak SSH na instancji wystawionej do internetu. Ta sama sonda odpowiada na oba pytania, ale alertujesz na przeciwne wyniki. Ten przewodnik omawia, kiedy używać każdego trybu, na co alertować i które porty często sprawiają problemy.

Jak właściwie działa monitor portu TCP

Monitor portu TCP otwiera gniazdo do celu na wybranym porcie i czeka na zakończenie trójetapowego uzgadniania. Jeśli uzgadnianie się powiedzie, port jest otwarty. Jeśli połączenie zostanie odrzucone, port jest zamknięty. Jeśli połączenie wygaśnie, coś między próbnikiem a Twoim hostem odrzuca pakiet, zwykle firewall.

Sonda nie obsługuje żadnego protokołu ponad gniazdem. Nie negocjuje TLS, nie wymienia banerów SSH ani nie wykonuje zapytania do bazy danych. Mówi tylko, czy port odpowiada. Dla zdrowia warstwy aplikacji potrzebujesz dodatkowo sprawdzenia HTTP lub niestandardowego.

Kiedy chcesz, aby port był OTWARTY

Używaj monitorowania portów jako sondy zdrowia usługi, gdy nie możesz łatwo wykonać sprawdzenia HTTP. Pojawia się pięć typowych przypadków.

• Serwery baz danych na porcie 5432 (Postgres), 3306 (MySQL), 6379 (Redis), 27017 (MongoDB). Jeśli nasłuchiwacz się zawiesi, każda zależna usługa przestaje działać, ale nie możesz uruchomić sondy HTTP.
• Relaye SMTP na porcie 25 lub 587. Sprawdzenia banera SMTP wychwytują awarie nasłuchiwacza, których wewnętrzne endpointy zdrowia nie wykrywają.
• Serwery gier i inne niestandardowe protokoły TCP, które nie obsługują HTTP.
• Wewnętrzne load balancery, które udostępniają port zdrowia inny niż HTTP usługom upstream.
• Punkty końcowe VPN na portach UDP-ale-też-TCP, takich jak 443 dla OpenVPN-TCP i WireGuard.

Kiedy chcesz, aby port był ZAMKNIĘTY

Odwrócone monitorowanie portów to zabezpieczenie. Ustawiasz monitor, aby alertował, gdy port stanie się otwarty, ponieważ nigdy nie powinien być otwarty z publicznego internetu. Ten wzorzec wychwytuje rzeczy, które idą nie tak podczas normalnego tygodnia zmian w infrastrukturze.

Ktoś tymczasowo otwiera regułę firewalla do debugowania i zapomina ją cofnąć. Usługa Kubernetes przez przypadek otrzymuje typ LoadBalancer. Nowa instancja dostaje niewłaściwą grupę bezpieczeństwa. Zmiana modułu Terraform wystawia port, który miał być wewnętrzny. W każdym przypadku odwrócony monitor portu wychwytuje ekspozycję w ciągu jednego interwału sprawdzania.

Wartościowe porty do odwróconego monitorowania już teraz

Pięć portów warto skonfigurować z odwróconym sprawdzeniem dla każdego hosta wystawionego do internetu, który nie powinien ich udostępniać.

• 22 (SSH) na produkcyjnych serwerach aplikacji. Dostęp wyłącznie przez bastion jest normą, a przypadkowo otwarty port SSH pojawia się w logach masowego skanowania w ciągu kilku godzin.
• 3306 (MySQL) i 5432 (Postgres). Publiczne porty baz danych odpowiadają za znaczącą część ataków credential-stuffing.
• 6379 (Redis). Otwarty Redis bez uwierzytelniania to jedna z najczęściej wykorzystywanych błędnych konfiguracji w branży.
• 27017 (MongoDB). Ta sama historia co Redis. Domyślna konfiguracja, brak uwierzytelniania, publiczny port równa się utracie danych.
• 9200 (Elasticsearch). Otwarte klastry są skanowane, wykorzystywane do kopania kryptowalut i okupowane w ciągu kilku godzin.

Progi alertowania dla monitorowania portów

Zdrowie usługi (port powinien być OTWARTY) wymaga tego samego wzorca progu co HTTP: alertuj po 3 kolejnych niepowodzeniach, tłum krótkie wahania. Drobne awarie sieci, które zamykają pojedynczą sondę, to szum.

Bezpieczeństwo (port powinien być ZAMKNIĘTY) wymaga przeciwnego podejścia. Alertuj przy pierwszym wykryciu. Przypadkowo otwarty port SSH lub Redis to zdarzenie najwyższej wagi. Boty nieustannie skanują publiczny internet, a okno między ekspozycją a kompromitacją na znanym porcie mierzone jest w minutach.

Początkowa lista kontrolna monitorowania portów bezpieczeństwa

Dla każdego adresu IP wystawionego do internetu, którym zarządza Twój zespół, ustaw odwrócone monitory na 22, 3306, 5432, 6379 i 27017 w interwale 60 sekund. Kieruj alerty do kanału bezpieczeństwa, oddzielnie od alertów zdrowia usługi. Raz na kwartał uruchom prawdziwy skan portów względem własnych adresów IP jako kontrolę. Koszt jest niewielki, zasięg szeroki, a tryby awarii, które wychwytuje, są katastrofalne.