🥇Nie otwieraj portów na świat — zostaniesz złamany (ryzyko)

Ciągle, po przeprowadzeniu audytu, napotykam na mur niezrozumienia moich rekomendacji dotyczących ukrywania portów za białą listą. Nawet bardzo doświadczeni administratorzy/DevOps pytają: „Po co?!?”

Proponuję rozważyć ryzyko w kolejności malejącej prawdopodobieństwa wystąpienia i szkód.

Błąd konfiguracji
DDoS po IP
Brute-force
Vulnerabilities of services
Vulnerabilities in the kernel stack
Wzmacnianie ataków DDoS

Błąd konfiguracji

Najbardziej typowa i niebezpieczna sytuacja. Jak to się zdarza. Programista musi szybko zweryfikować hipotezę, uruchamia tymczasowy serwer z mysql/redis/mongodb/elastic. Hasło, oczywiście, jest skomplikowane, używa go wszędzie. Otwiera usługę dla świata — wygodnie mu podłączyć się bez tego VPN na swoim PC. A przypomnienie składni iptables jest mu leniwym, w końcu serwer jest tymczasowy. Jeszcze kilka dni programowania — wyszło świetnie, można pokazać klientowi. Klientowi się podoba, nie ma czasu na poprawki, uruchamiamy w PRODUKCJI!

Przykład celowo przesadzony, aby przejść przez wszystkie pułapki:

Nie ma nic bardziej stałego niż tymczasowe — nie lubię tego wyrażenia, ale z subiektywnych odczuć, 20-40% takich tymczasowych serwerów pozostaje na długo.
Skomplikowane hasło uniwersalne, które jest używane w wielu usługach — to zło. Ponieważ jedna z usług, w których to hasło było używane, mogła zostać zhakowana. Tak czy inaczej, bazy zhakowanych usług trafiają do jednej, która jest używana do [bruteforcingu]*.
Warto dodać, że redis, mongodb i elastic po instalacji są w ogóle dostępne bez uwierzytelnienia, i często uzupełniają zbiór otwartych baz.
Może się wydawać, że w ciągu kilku dni nikt nie przeskanuje twojego portu 3306. To złudzenie! Masscan — doskonały skaner, może skanować z prędkością 10M portów na sekundę. A w internecie jest tylko 4 miliardy IPv4. W związku z tym, wszystkie porty 3306 w internecie są skanowane w 7 minut. Karol!!! Siedem minut!
„Kto się tym przejmuje?” — odparysz. I ja się dziwię, patrząc na statystyki odrzuconych pakietów. Skąd w ciągu jednej doby 40 tysięcy prób skanowania z 3 tysięcy unikalnych IP? Teraz skanują wszyscy, mający na to ochotę, od hakerów po rząd. Sprawdzić to bardzo prosto — weź dowolną VPSkę za 3-5 $ u jakiegoś** lowcostera, włącz logowanie odrzuconych pakietów i zajrzyj do logu po dobie.

Włączenie logowania

W /etc/iptables/rules.v4 dodaj na końcu:
-A INPUT -j LOG —log-prefix „[FW — WSZYSTKO] ” —log-level 4

A w /etc/rsyslog.d/10-iptables.conf
:msg,contains,»[FW — » /var/log/iptables.log
& stop

DDoS po IP

Jeśli napastnik zna twój adres IP, może przez kilka godzin lub dni przeprowadzać ataki DDoS na twój serwer. Niewielu tanich dostawców hostingu ma zabezpieczenia przed DDoS, dlatego twój serwer może zostać odcięty od sieci. Jeśli ukryłeś serwer za CDN, nie zapomnij zmienić IP, w przeciwnym razie hacker znajdzie go w Internecie i będzie atakował twój serwer omijając CDN (bardzo popularny błąd).

Vulnerabilities of services

Wszystkie popularne oprogramowania prędzej czy później mają jakieś błędy, nawet te najsolidniej testowane i krytyczne. W środowisku specjalistów od bezpieczeństwa krąży pół-żart — bezpieczeństwo infrastruktury można oceniać po dacie ostatniej aktualizacji. Jeśli twoja infrastruktura ma wiele otwartych portów i nie była aktualizowana od roku, każdy specjalista od bezpieczeństwa powie bez wahania, że jesteś dziurawy i prawdopodobnie już włamanie się zdarzyło.
Warto również wspomnieć, że wszystkie znane podatności były kiedyś nieznane. Wyobraź sobie hakera, który znalazł taką podatność i przeskanował cały internet w 7 minut… Oto nowa epidemia wirusowa) Należy się aktualizować, ale to może zaszkodzić produkcji, powiesz. I masz rację, jeśli pakiety są instalowane z nieoficjalnych repozytoriów systemu. Z doświadczenia, aktualizacje z oficjalnego repozytorium rzadko łamią produkcję.

Brute-force

Jak wspomniałem wcześniej, istnieje baza pół miliarda haseł, które można wygodnie wpisywać na klawiaturze. Innymi słowy, jeśli nie wygenerowałeś hasła, a wpisałeś na klawiaturze sąsiadujące znaki, bądź pewny — zostaniesz złamany.

Podatności stosu jądra.

Zdarza się, że nie jest istotne, który serwis otwiera port, gdy podatny jest sam stos sieciowy jądra. To znaczy, że każdy soket tcp/udp w systemie dwuletnim jest podatny na podatność prowadzącą do DDoS.

Wzmocnienie ataków DDoS

Bezpośrednio nie przyniesie szkód, ale może zablokować twój kanał, zwiększyć obciążenie systemu, twój adres IP trafi na jakiś czarną listę, a ty dostaniesz ostrzeżenie od hostera.

Czy naprawdę potrzebujesz wszystkich tych ryzyk? Dodaj swój domowy i służbowy adres IP do białej listy. Nawet jeśli jest dynamiczny — zaloguj się przez panel hostera, przez konsolę webową i po prostu dodaj jeszcze jeden.

Od 15 lat zajmuję się budowaniem i zabezpieczaniem infrastruktury IT. Wypracowałem zasadę, którą wszystkim gorąco polecam — żaden port nie powinien być otwarty na świat bez białej listy..

Na przykład, najbardziej zabezpieczony serwer webowy*** to taki, który ma otwarte porty 80 i 443 tylko dla CDN/WAF. A porty serwisowe (ssh, netdata, bacula, phpmyadmin) powinny być przynajmniej za białą listą, a jeszcze lepiej za VPN. W przeciwnym razie ryzykujesz bycie skompromitowanym.

To wszystko. Trzymajcie porty zamknięte!

(1) UPD1: Tutaj możesz sprawdzić swoje świetne uniwersalne hasło (nie rób tego nie zmieniając tego hasła na losowe we wszystkich serwisach.), nie ujawnij się w wyciekłej bazie. A tutaj można zobaczyć, ile serwisów zostało zhakowanych, w których figurował Twój email, i odpowiednio ustalić, czy Twoje świetne uniwersalne hasło zostało skompromitowane.
(2) Ku chwale Amazon — na LightSail minimum skanów. Wygląda na to, że coś tam filtrują.
(3) Jeszcze bardziej zabezpieczony serwer webowy to taki, który ma dedykowaną zaporę ogniową, własny WAF, ale mowa o publicznych VPS/Dedykowanych.
(4) Segmentsmak.
(5) Firehol.

Tylko zarejestrowani użytkownicy mogą brać udział w ankiecie. Zaloguj się, proszę.