External Attack Surface Management (EASM): jak odkryć wszystko, co firma wystawiła do Internetu

Typowy audyt ekspozycji zaczyna się od listy, która wygląda na kompletną: kilka serwerów, strona firmowa, poczta i jeden znany adres publiczny. Dopiero sprawdzenie domen, DNS, certyfikatów, historii rekordów i adresów IP pokazuje, że obraz jest szerszy. Pojawiają się zapomniane VPS-y, stare subdomeny, panele administracyjne, środowiska testowe i usługi, których nikt już nie przypisuje do konkretnego właściciela.

Żadna z tych rzeczy zwykle nie powstaje ze złej woli. Każda miała jakiś powód: szybki test, migrację, kampanię, wdrożenie klienta, chwilowy dostęp dla wykonawcy, awaryjne obejście problemu. Problem zaczyna się wtedy, gdy rozwiązanie tymczasowe nie ma daty końca. Tymczasowość bez właściciela zamienia się w stały element infrastruktury, tyle że niewidoczny dla firmy i doskonale widoczny dla każdego, kto potrafi korzystać z publicznych źródeł informacji.

Na tym polega różnica między tym, co firma we własnym przekonaniu wystawia do sieci, a tym, co realnie z niej widać. Atakujący nie pyta administratora, co jest w użyciu. Skanuje, koreluje dane, sprawdza dzienniki certyfikatów, historyczne rekordy DNS, wyszukiwarki urządzeń i stare ślady w Internecie. Potem wybiera najsłabszy punkt. Jego przewaga często nie polega na wyrafinowanym exploicie, tylko na tym, że zna publiczną część Twojej infrastruktury lepiej niż Ty.

External attack surface management, w skrócie EASM, odwraca tę asymetrię. Zamiast patrzeć na środowisko od środka, z listy w arkuszu, z konsoli hiperwizora i z pamięci administratora, patrzy z zewnątrz, dokładnie tak jak atakujący. Odpowiada na pytanie, które wiele organizacji zadaje sobie dopiero po incydencie: co my właściwie mamy wystawione do Internetu i skąd to się tam wzięło.

Ten tekst pokazuje, jak podejść do EASM praktycznie: jak zmapować powierzchnię ataku, gdzie szukać zapomnianych usług, jak ocenić ryzyko, co wpisać do rejestru infrastruktury i jak połączyć ten proces z monitoringiem IT, bezpieczeństwem Linux oraz codziennym utrzymaniem serwerów.

Czym jest powierzchnia ataku widziana z Internetu

Powierzchnia ataku to zbiór wszystkich punktów, przez które ktoś z zewnątrz może wejść w interakcję z Twoją infrastrukturą. Każdy adres IP odpowiadający na pakiety, każdy otwarty port, każda subdomena, każdy rekord DNS, każdy certyfikat SSL/TLS, każdy formularz logowania i każda publiczna usługa są elementem tej powierzchni. Nie liczy się to, czy dana usługa jest „w użyciu” z punktu widzenia biznesu. Liczy się to, czy odpowiada z Internetu.

Sedno EASM to perspektywa. Wewnętrzna inwentaryzacja mówi, co administrator uważa za istniejące. External attack surface management mówi, co faktycznie widać z sieci publicznej, bez dostępu do żadnego systemu wewnętrznego. Te dwa obrazy rzadko pokrywają się w pełni, a rozjazd między nimi jest realnym ryzykiem. To, czego nie ma na wewnętrznej liście, zwykle nie jest aktualizowane, monitorowane ani przypisane do właściciela, a mimo to pozostaje osiągalne dla każdego.

Druga cecha to ciągłość. Powierzchnia ataku nie jest stanem raz ustalonym na audycie, tylko strumieniem zmian. Deweloper wystawia nowy endpoint API, marketing uruchamia kampanię na świeżej subdomenie, ktoś stawia serwer do jednorazowego testu i zapomina go wyłączyć, dostawca chmury przydziela nowy adres z puli, a stary VPS po migracji nadal działa. Audyt wykonany raz w roku opisuje stan, który za kilka tygodni może być nieaktualny. Dlatego EASM jest bliżej monitoringu niż jednorazowego pentestu.

Powierzchnia ataku dzieli się na trzy główne warstwy. Warstwa sieciowa obejmuje adresy IPv4 i IPv6, otwarte porty, protokoły oraz usługi nasłuchujące. Warstwa nazw obejmuje domeny, subdomeny, rekordy DNS i certyfikaty. Warstwa aplikacyjna to konkretne panele, formularze logowania, API, aplikacje WWW i interfejsy administracyjne widoczne po wejściu na dany adres. EASM pracuje na wszystkich trzech, bo atakujący też przemieszcza się między nimi swobodnie: od bloku IP do nazwy, od nazwy do certyfikatu, od certyfikatu do panelu.

Dlaczego firmy nie znają własnej infrastruktury

Pierwszy powód jest organizacyjny: wiedza o środowisku żyje w głowach ludzi, nie w dokumentacji. Administrator, który dwa lata temu stawiał serwer testowy, znał jego cel i kontekst. Po jego odejściu zostaje działająca maszyna, ale znika wiedza, dlaczego powstała, kto jej używał i czy nadal jest potrzebna. To jeden z powodów, dla których warto prowadzić CMDB i dokumentację infrastruktury IT, zamiast pozwalać, żeby kontrola nad środowiskiem rozpłynęła się w pamięci zespołu. Bez tego każda zmiana kadrowa oznacza utratę części mapy.

Drugi powód to tempo. Infrastruktura przyrasta szybciej, niż ktokolwiek ją dokumentuje. Nowa subdomena powstaje w minutę, wpis do rejestru zasobów wymaga dyscypliny. W rozpędzonym projekcie łatwo uznać dokumentację za rzecz, do której wróci się później. Później zwykle nie nadchodzi. W efekcie dokumentacja opisuje przeszłość i z każdym miesiącem coraz słabiej przystaje do rzeczywistości.

Trzeci czynnik to rozproszenie dostawców. Domena zarejestrowana u jednego rejestratora, DNS delegowany do drugiego, serwery Linux u trzeciego, chmura u czwartego, poczta u piątego, a monitoring u szóstego. Nikt nie widzi całości, bo całość nie istnieje w żadnym pojedynczym panelu. Każdy dostawca pokazuje swój wycinek, a granice między tymi wycinkami to miejsca, w których najczęściej gubią się zasoby.

Na końcu tej listy stoi zjawisko, które w firmach rozrasta się cicho: shadow IT, czyli infrastruktura powstająca poza wiedzą i kontrolą działu odpowiedzialnego za bezpieczeństwo. Prywatny VPS uruchomiony przez dewelopera, konto w chmurze założone na firmową kartę, testowa aplikacja wystawiona na subdomenie, klucz API wrzucony do publicznego repozytorium. EASM jest zewnętrznym uzupełnieniem wykrywania shadow IT. Tam, gdzie wewnętrzna inwentaryzacja nie sięga, bo nie wie, czego szukać, spojrzenie z Internetu wyłapuje zasób po jego publicznym śladzie.

Skąd bierze się niekontrolowana ekspozycja usług

Najczęstsze źródło to migracje. Firma przenosi usługi na nowy serwer, przełącza ruch, a stara maszyna zostaje włączona „na wszelki wypadek”. Po miesiącu przestaje istnieć w czyjejkolwiek świadomości, po roku działa na niej Apache lub Nginx z nieaktualną konfiguracją, a host nadal odpowiada na publicznym adresie IP. Migracja bez świadomego wyłączenia i wyrejestrowania starego zasobu to fabryka porzuconej ekspozycji.

Ta sama logika dotyczy bram zdalnego dostępu. Stary VPN, który przeżył migrację i działa na nieaktualizowanym oprogramowaniu, bywa szczególnie groźny, bo prowadzi wprost do sieci wewnętrznej. Udany atak nie zatrzymuje się wtedy na jednym hoście. Otwiera drogę do środowiska za firewallem, często z aktywnymi kontami byłych pracowników lub wykonawców.

Tuż za migracjami idą środowiska nieprodukcyjne. Staging, dev, demo, UAT: każde z nich bywa wystawione do Internetu dla wygody. Często z mniejszym rygorem niż produkcja. Słabsze hasła, brak MFA, testowe dane, które okazują się kopią prawdziwej bazy klientów, debugowanie włączone na stałe. Atakujący nie rozróżnia stagingu od produkcji. Dla niego to kolejny endpoint, zwykle słabiej broniony.

Osobną kategorią są projekty z datą ważności, której nikt nie egzekwuje. Wygasła kampania, zakończona współpraca z klientem, aplikacja, która miała działać przez kwartał. Kod i serwer zostają, a wraz z nimi biblioteki, które od dawna nie dostają aktualizacji. Stara aplikacja PHP na zapomnianej subdomenie bywa groźniejsza niż nowa, świeżo wdrożona usługa, bo łączy dwie cechy: jest osiągalna i nikt jej nie pilnuje.

Do tej samej grupy należą porzucone narzędzia zespołowe. Stary Mantis, firmowa wiki, Git, Jenkins, panel statystyk, narzędzie do podglądu logów. Po latach bez aktualizacji wciąż odpowiadają z sieci, a razem z nimi cała historia zgłoszeń, wewnętrzne adresy, nazwy serwerów, dane projektowe i nierzadko sekrety wklejone kiedyś do treści zgłoszenia. Taki zasób nie tylko sam jest podatny. Oddaje atakującemu mapę wnętrza firmy.

Listę zamykają usługi pomocnicze, które miały być „tylko na chwilę” dostępne z zewnątrz. Otwarte SSH na standardowym porcie, panel administracyjny bez ograniczenia po IP, interfejs bazy danych udostępniony deweloperowi na czas pracy zdalnej, stary FTP, katalog z plikami do pobrania, tymczasowe API. Każda z tych rzeczy zaczyna życie jako racjonalny kompromis, a kończy jako trwała luka w bezpieczeństwie infrastruktury.

DNS jako źródło informacji dla atakującego

DNS to jedno z najbogatszych publicznych źródeł wiedzy o firmie. Zanim ktokolwiek wyśle pakiet do Twoich serwerów, może zbudować mapę infrastruktury wyłącznie z rekordów, które sam publikujesz. Rekordy A i AAAA mówią, na jakich adresach IPv4 i IPv6 stoją usługi. Rekord MX zdradza, kto obsługuje pocztę. Rekord CNAME pokazuje zależności od zewnętrznych dostawców. Rekordy TXT bywają kopalnią informacji o używanych usługach SaaS, tokenach weryfikacyjnych, SPF, DKIM, DMARC i dawnych integracjach.

Kolejny front to enumeracja subdomen. Nazwy takie jak vpn, mail, git, jenkins, test, staging, dev, panel, backup, old czy admin są przewidywalne i sprawdzane automatycznie. Do tego dochodzą źródła pasywne: dzienniki certyfikatów, historyczne bazy DNS, archiwa i wyszukiwarki urządzeń. Subdomena, która istniała rok temu, często zostaje w tych zbiorach, nawet jeśli dziś nie jest już publikowana. To, co raz trafiło do publicznego DNS, praktycznie nie znika z Internetu.

Najpoważniejszym błędem jest otwarty transfer strefy. Serwer nazw skonfigurowany tak, że odpowiada na zapytanie AXFR od dowolnego klienta, oddaje całą zawartość strefy jednym poleceniem: komplet rekordów, subdomen i wskazań, bez potrzeby zgadywania. Zakres ma znaczenie: transfer oddaje rekordy konkretnej strefy na danym serwerze, więc nazwy delegowane do innych stref mogą w nim nie wystąpić, ale to, co jest w strefie, wypływa w całości. Transfer strefy powinien być ograniczony do znanych serwerów podrzędnych i do niczego więcej.

Subdomain takeover jako klasa ryzyka

Szczególnie podstępny scenariusz to przejęcie subdomeny. Powstaje wtedy, gdy rekord CNAME wskazuje na zasób u zewnętrznego dostawcy, na przykład bucket, platformę hostingową lub usługę SaaS, który został skasowany, ale rekord DNS nadal istnieje. Atakujący rejestruje zwolnioną nazwę u tego dostawcy i przejmuje kontrolę nad tym, co odpowiada pod Twoją subdomeną.

Od tej chwili cokolwiek.twojafirma.pl może serwować obcą treść pod adresem należącym do firmy. Atakujący może też uzyskać poprawny certyfikat TLS dla przejętej nazwy, bo z punktu widzenia mechanizmów walidacji kontroluje zasób wskazywany przez DNS. Dla użytkownika wygląda to wiarygodnie: domena się zgadza, certyfikat jest poprawny, przeglądarka nie ostrzega.

Mechanizm jest cichy, bo z perspektywy DNS nic nie musi wyglądać na zepsute. Rekord działa, tylko wskazuje na coś, co przestało być Twoje. Wykrycie wymaga regularnego przeglądania rekordów CNAME pod kątem wskazań na nieistniejące zasoby. To klasyczny przypadek, w którym stary, niesprzątnięty rekord DNS staje się aktywnym ryzykiem dla bezpieczeństwa firmy.

Certyfikaty i Certificate Transparency

Wiele firm traktuje certyfikat SSL/TLS jako element prywatnej konfiguracji serwera. W praktyce każdy publicznie zaufany certyfikat trafia do jawnych, przeszukiwalnych dzienników Certificate Transparency, w skrócie CT Logs. To mechanizm zaprojektowany dla bezpieczeństwa, bo pozwala wykrywać certyfikaty wystawione bezprawnie, ale ma istotny efekt uboczny: tworzy publiczną mapę nazw używanych przez organizację.

Dla atakującego to bardzo cenne źródło. Wystarczy odpytać dzienniki CT o domenę, żeby zobaczyć subdomeny, dla których kiedykolwiek wystawiono certyfikat. panel-admin.twojafirma.pl, vpn-test.twojafirma.pl, git.twojafirma.pl, staging.twojafirma.pl: każda z tych nazw ujawnia się w momencie wystawienia publicznego certyfikatu, nawet jeśli usługa nigdy nie miała być szeroko promowana.

Automatyczne wystawianie certyfikatów przez narzędzia typu certbot jest wygodne, ale trzeba rozumieć konsekwencje. Jeżeli generujesz publiczne certyfikaty SSL/TLS dla nazw technicznych, to jednocześnie publikujesz te nazwy w dziennikach CT. Wyjątkiem są certyfikaty wildcard, na przykład *.twojafirma.pl, które ujawniają w dziennikach samą gwiazdkę, a nie konkretne nazwy hostów. Inaczej zachowują się też certyfikaty z prywatnego CA i self-signed, które nie trafiają do publicznych dzienników, ale mają własne ograniczenia operacyjne.

Dobra praktyka jest prosta: traktuj CT Logs jak system wczesnego ostrzegania. Skoro atakujący dowiaduje się o nowej subdomenie w momencie wystawienia certyfikatu, Ty też możesz. Regularne sprawdzanie dzienników pod kątem swoich domen pozwala wychwycić certyfikaty, o których nikt w zespole nie wie. Taki wpis może oznaczać zapomniany zasób, shadow IT albo dostawcę działającego w Twoim imieniu bez właściwej kontroli.

Shodan, Censys i wyszukiwarki urządzeń

DNS mówi o nazwach, CT Logs o certyfikatach, ale nadal trzeba odpowiedzieć na pytanie: co faktycznie nasłuchuje na portach. Tu wchodzą wyszukiwarki urządzeń, takie jak Shodan i Censys. Regularnie skanują duże części publicznego Internetu, zapisują banery usług, wersje oprogramowania, certyfikaty i odpowiedzi protokołów, a potem udostępniają te dane w formie przeszukiwalnej bazy.

Dla EASM to bardzo praktyczne źródło, bo pozwala zobaczyć własną infrastrukturę cudzym skanem. Zapytanie o domenę, certyfikat, organizację albo blok adresowy może zwrócić listę usług, których firma nie ma w rejestrze. RDP wystawiony wprost do Internetu, panel phpMyAdmin, otwarty Jenkins, stary interfejs urządzenia sieciowego, Proxmox dostępny z każdego adresu, serwer pocztowy z nieaktualnym banerem. Każdy taki wpis jest wskazówką, od czego zacząć porządkowanie ekspozycji usług.

Warto jednak traktować te narzędzia jako źródło pomocnicze, a nie jedyną prawdę. Dane mogą być opóźnione, niepełne albo zależne od aktualnego modelu konta i limitów wyszukiwania. Censys i Shodan oferują ograniczone możliwości wyszukiwania bez pełnego planu komercyjnego, ale zakres wyników, filtry i limity zależą od aktualnych zasad danej platformy. Pełny, powtarzalny proces EASM zwykle łączy źródła pasywne z własnym, kontrolowanym sprawdzaniem aktualnego stanu.

Osobną pułapką jest IPv6. Przestrzeń IPv4 da się skanować szeroko, bo jest relatywnie mała. Przestrzeni IPv6 nie da się przemiatać w ten sam sposób. Hosty IPv6 są zwykle odkrywane przez rekordy AAAA, dzienniki certyfikatów, logi, gotowe listy adresów i inne ślady. To oznacza, że higiena DNS i certyfikatów jest dla ekspozycji IPv6 jeszcze ważniejsza niż dla IPv4.

ASN i bloki adresowe jako punkt wyjścia

Profesjonalne mapowanie często zaczyna się nie od pojedynczej domeny, tylko od numeru systemu autonomicznego, czyli ASN. To identyfikator przypisany operatorowi sieci albo większej organizacji, który pozwala powiązać bloki adresów IP z konkretnym podmiotem. Mając własny ASN lub znane zakresy adresowe, można odwrócić kierunek analizy: zamiast pytać „na jakim IP stoi ta domena”, pytasz „co jeszcze stoi w naszych zakresach”.

Do powiązania adresu z organizacją służą rejestry WHOIS oraz RDAP. Zapytanie o adres IP pokazuje, do kogo należy blok, jaki jest zakres przydziału i kto jest kontaktem administracyjnym lub abuse. Analiza WHOIS domeny pokazuje rejestratora, datę rejestracji i, o ile dane nie są ukryte, informacje kontaktowe. Historia domeny i pasywny DNS pomagają ustalić, na jakie adresy dana nazwa wskazywała wcześniej.

To ma praktyczną wartość. Zdarza się, że domena przestała wskazywać na konkretny adres kilka lat temu, ale serwer pod tym adresem nadal działa i odpowiada na ruch. Nikt go nie widzi w aktualnym DNS, ale wyszukiwarki urządzeń i historia rekordów mogą nadal do niego prowadzić. Tak odnajduje się wiele starych serwerów po migracjach.

IPv4 kontra IPv6

Inną pułapką jest podwójny stos adresowy. Wiele firm pilnuje adresów IPv4, bo to na nich historycznie działała większość usług, i ignoruje IPv6. Tymczasem serwer często ma oba adresy, a firewall bywa skonfigurowany starannie tylko dla jednego z nich. Usługa zamknięta od strony IPv4 potrafi być całkowicie otwarta na IPv6, bo reguła filtrująca nigdy nie została powielona.

To częsty błąd w bezpieczeństwie Linux i całej infrastruktury sieciowej. Administrator sprawdza port na IPv4, widzi, że jest zamknięty, i uznaje temat za zakończony. Atakujący sprawdza rekord AAAA, łączy się po IPv6 i trafia na usługę, której nikt nie uwzględnił w regułach. Każdy audyt infrastruktury powinien obejmować oba protokoły. Każda reguła firewall, każdy test dostępności i każdy monitoring IT powinny być świadome IPv4 oraz IPv6.

Poczta jako osobna powierzchnia ataku

Usługi pocztowe wymagają osobnej analizy, bo w porównaniu z WWW ich ekspozycja wygląda inaczej. Rekord MX mówi wprost, który serwer przyjmuje pocztę dla domeny, a reverse DNS, czyli rekord PTR, ujawnia dodatkowy kontekst o hoście. Niespójność między nazwą serwera pocztowego, rekordem PTR a rekordem MX bywa sygnałem zaniedbanej konfiguracji albo zasobu, który wypadł z ewidencji.

Rdzeniem analizy poczty są rekordy uwierzytelniania nadawcy. SPF w rekordzie TXT deklaruje, które serwery mogą wysyłać pocztę w imieniu domeny. Zbyt szeroki SPF, kończący się na +all albo obejmujący dawne, nieużywane bloki dostawców, zwiększa ryzyko podszywania się. DKIM podpisuje wiadomości kluczem prywatnym, a odpowiadający mu klucz publiczny jest opublikowany w DNS pod nazwą selektora. Porzucone selektory, stare klucze i krótkie klucze osłabiają cały mechanizm.

DMARC spina SPF i DKIM oraz mówi odbiorcom, co robić z wiadomościami, które nie przeszły weryfikacji. Najczęstszy błąd to ustawienie DMARC na p=none i pozostawienie tej polityki na stałe. Polityka none tylko raportuje i nie wymusza odrzucania ani kwarantanny wiadomości, więc sama w sobie nie zapewnia ochrony przed podszywaniem się na poziomie DMARC. Firma ma poczucie, że „ma DMARC”, ale realna egzekucja nie działa.

Analiza SPF, DKIM i DMARC razem pokazuje, czy ktoś może wysyłać wiarygodnie wyglądający phishing z domeny firmy. Tę część powierzchni ataku łatwo zlekceważyć, bo nie widać jej w klasycznym skanie portów. Dla bezpieczeństwa firmy ma jednak ogromne znaczenie, bo atak na pocztę często jest pierwszym krokiem do przejęcia kont, wyłudzenia płatności albo kradzieży danych.

Panele, monitoring i backupy wystawione do Internetu

Trzy kategorie zasobów wymagają szczególnej uwagi, bo ich ekspozycja bywa najgroźniejsza i jednocześnie najczęściej niezauważona.

Pierwsza to panele administracyjne. Proxmox, cPanel, phpMyAdmin, panele routerów, firewalle, interfejsy zarządzania serwerami, konsole chmurowe i panele aplikacyjne. Każdy z nich daje po zalogowaniu szeroką kontrolę, więc każdy wystawiony wprost do Internetu staje się atrakcyjnym celem. Panel administracyjny nie powinien być publiczną usługą dostępną dla całego świata. Jego miejsce jest za VPN-em, za listą dozwolonych adresów, za MFA i pod stałym nadzorem.

Druga kategoria to usługi monitoringu i narzędzia deweloperskie. Otwarty Jenkins, Grafana bez uwierzytelniania, Prometheus dostępny z Internetu, Git z repozytoriami, endpointy metryk oddające wewnętrzną topologię, publiczne logi aplikacji. Te usługi bywają wystawiane w dobrej wierze, żeby zespół miał wygodny dostęp, ale ujawniają nie tylko siebie. Pokazują strukturę środowiska, nazwy hostów, zależności, błędy aplikacji i czasem sekrety. To bezpośrednio łączy się z tym, dlaczego sekrety, hasła i dostęp administracyjny w Linuksie trzeba trzymać pod kontrolą, a nie w plikach konfiguracyjnych.

Trzecia, najboleśniejsza kategoria to backupy dostępne z Internetu. Katalog z kopiami zapasowymi udostępniony przez FTP, bucket z backupami bazy bez uwierzytelniania, plik dump.sql leżący w katalogu WWW, archiwum .tar.gz dostępne pod przewidywalnym adresem, snapshot aplikacji pozostawiony po migracji. Backup jest z definicji kompletną kopią danych. Jego wyciek odsłania wszystko naraz, bez potrzeby włamywania się do produkcyjnej aplikacji.

Jak przechowywać i testować kopie, rozwijamy w tekście o tym, co w backupie i odtwarzaniu po awarii trzeba testować regularnie. Z perspektywy EASM najważniejsza jest jedna zasada: żaden backup nie powinien być osiągalny z publicznej sieci. Nie „trudny do zgadnięcia”. Nie „ukryty pod długim adresem”. Po prostu niedostępny z Internetu.

Jak samodzielnie przeprowadzić pierwszy audyt

Pierwszy audyt ekspozycji nie wymaga od razu drogiego narzędzia ani zewnętrznego projektu. Wymaga metody i konsekwencji. Narzędzia są drugorzędne. Liczy się kolejność: od domen i nazw, przez certyfikaty, adresy, porty, aplikacje, aż po decyzję, co z każdym zasobem zrobić.

Krok pierwszy: ustal punkt wyjścia. Zbierz wszystkie domeny i marki, jakie firma kiedykolwiek posiadała. Uwzględnij dawne nazwy, przejęte podmioty, domeny kampanijne, domeny projektowe i domeny techniczne. Dorzuć znane bloki adresowe, dostawców hostingu, konta chmurowe i, jeśli firma go posiada, numer ASN. Im szerzej zakreślisz materiał wejściowy, tym mniej zostanie w cieniu.

Krok drugi: rozbierz DNS na części. Dla każdej domeny wyciągnij rekordy A, AAAA, MX, TXT, NS i CNAME. Sprawdź, czy serwery autorytatywne nie pozwalają na transfer strefy. Zbuduj listę subdomen, łącząc enumerację słownikową ze źródłami pasywnymi. Na tym etapie chodzi o kompletną listę nazw, jeszcze bez oceny, co jest żywe.

Krok trzeci: sięgnij po Certificate Transparency. Odpytaj dzienniki CT o wszystkie domeny. Każda nazwa z certyfikatem, której nie ma na Twojej liście, to odkrycie. Dopisz ją do zbioru subdomen. Ten krok regularnie ujawnia zasoby, o których nie mówi żaden wewnętrzny dokument.

Krok czwarty: rozwiąż nazwy na adresy i odwrotnie. Zamień subdomeny na adresy IPv4 i IPv6, a potem sprawdź reverse DNS dla znanych zakresów, żeby wychwycić hosty, do których nie prowadzi żadna znana nazwa. Zestaw dane z WHOIS/RDAP, żeby potwierdzić, że dany blok faktycznie należy do firmy albo jest przez nią używany.

Krok piąty: sprawdź, co odpowiada. Dla każdego żywego adresu ustal otwarte porty i usługi, które na nich nasłuchują. Pomagają tu źródła pasywne i własne, kontrolowane sprawdzenie aktualnego stanu. Zapisuj wersje oprogramowania, banery, protokoły i certyfikaty. To one później decydują o priorytecie napraw.

Krok szósty: zajrzyj w warstwę aplikacyjną. Dla usług WWW sprawdź, co realnie się serwuje: panele logowania, interfejsy administracyjne, otwarte katalogi, endpointy API, błędy aplikacji, nagłówki HTTP. To moment, w którym „host odpowiada na porcie 443” zamienia się w „na tym hoście stoi panel administracyjny stagingu”.

Krok siódmy: skataloguj i oceń. Każdy odkryty zasób opisz: co to jest, na czym stoi, kto powinien być właścicielem, czy ma prawo być publiczny, kiedy był ostatnio aktualizowany i czy jest objęty monitoringiem. Podziel wyniki na trzy grupy: zasoby znane i uzasadnione, zasoby znane, ale wystawione nadmiarowo, oraz zasoby, których w ogóle nie powinno być w sieci. O tym, że dana usługa jest uzasadniona, nie decyduje osoba, która ją znalazła. Potwierdza to właściciel techniczny albo biznesowy.

Pierwszy audyt warto zrobić szeroko, a nie przesadnie głęboko. Nie chodzi o zbadanie jednej usługi do ostatniej podatności. Chodzi o to, żeby po raz pierwszy zobaczyć całość. Głębsze badanie przychodzi później, na etapie hardeningu usług publicznych i skanów podatności zamienianych w plan napraw. EASM odpowiada na pytanie wcześniejsze: co w ogóle trzeba skanować, monitorować i utrzymywać.

Najczęstsze błędy

Poniższe błędy powtarzają się w środowiskach niezależnie od branży i wielkości. Każdy osobno może wyglądać niegroźnie. Razem tworzą powierzchnię ataku, której firma nie kontroluje.

Traktowanie audytu jako zdarzenia jednorazowego. Zmapowanie ekspozycji raz i odhaczenie zadania daje fałszywe poczucie bezpieczeństwa. Ekspozycja zmienia się z każdą zmianą w środowisku, więc raport sprzed kilku miesięcy jest już historią. Sens ma proces powtarzalny, najlepiej połączony z monitoringiem.

Ignorowanie IPv6. Firewall dopięty starannie dla IPv4 i pominięty dla IPv6 zostawia usługi otwarte na drugim protokole. To częsty błąd, bo nic nie sygnalizuje problemu, dopóki ktoś nie sprawdzi rekordu AAAA i dostępności po IPv6.

Pozostawianie środowisk testowych w sieci publicznej. Staging i dev wystawione do Internetu, często ze słabszym rygorem niż produkcja, są łatwym celem. Środowisko nieprodukcyjne powinno być domyślnie odcięte od otwartej sieci i dostępne tylko przez kontrolowany kanał.

Zapominanie o starych rekordach DNS. Rekordy wskazujące na skasowane zasoby otwierają drogę do przejęcia subdomeny. DNS trzeba sprzątać tak samo konsekwentnie jak serwery, konta i reguły firewall.

Wystawianie paneli administracyjnych wprost do Internetu. Proxmox, phpMyAdmin, panele routerów i inne interfejsy zarządzania nie powinny być publiczne. Dostęp administracyjny musi być ograniczony, monitorowany i chroniony MFA.

Automatyczne wystawianie certyfikatów bez świadomości CT Logs. Certyfikaty SSL/TLS dla nazw technicznych ujawniają te nazwy w publicznych dziennikach. To nie jest powód, żeby rezygnować z TLS, ale powód, żeby świadomie projektować nazewnictwo i dostępność usług.

Zbyt szeroka lub porzucona konfiguracja poczty. SPF z +all, stare selektory DKIM, DMARC pozostawiony na p=none, dawne integracje pocztowe wciąż dopuszczone do wysyłki. Poczta jest częścią powierzchni ataku, nawet jeśli nie wygląda jak klasyczna usługa serwerowa.

Otwarty transfer strefy DNS. Serwer autorytatywny odpowiadający na AXFR od każdego oddaje mapę strefy jednym poleceniem. To błąd konfiguracyjny, który powinien być sprawdzany regularnie.

Nieograniczony dostęp do usług pomocniczych. Otwarte SSH bez ograniczenia po IP, interfejs bazy wystawiony dla wygody, FTP z plikami, tymczasowe API bez wygaszenia. Domknięcie takich dostępów to część zarządzania dostępami uprzywilejowanymi w Linuksie i całym IT, a nie osobne, poboczne zadanie.

Backupy osiągalne z publicznej sieci. Adres pliku z kopią bywa przewidywalny, a automaty masowo odpytują typowe ścieżki. „Nikt nie zna adresu” nie jest zabezpieczeniem. Backupy muszą być poza publiczną ekspozycją.

Brak właściciela odkrytego zasobu. Znalezienie serwera to połowa pracy. Druga połowa to ustalenie, kto za niego odpowiada. Zasób bez właściciela nie zostanie ani załatany, ani wyłączony, bo każdy będzie zakładał, że zajmie się nim ktoś inny.

Rozdzielenie skanu od reakcji. Lista problemów pozostawiona bez decyzji nie zmniejsza ryzyka. Wynik EASM musi trafiać do procesu, który wymusza decyzję: zasób zostaje pod opieką, zostaje ograniczony albo znika z Internetu.

Co powinno znaleźć się w rejestrze infrastruktury

Odkrycie zasobów ma wartość tylko wtedy, gdy zostaje zapisane w miejscu, do którego firma faktycznie wraca. Tym miejscem jest rejestr infrastruktury, w praktyce prowadzony jako CMDB. Nie chodzi o powielanie całego tematu CMDB, tylko o to, co konkretnie z EASM powinno do niego trafić.

Dla każdego publicznego zasobu rejestr powinien zawierać nazwę, adres IP, protokół, porty, dostawcę, powiązaną domenę lub subdomenę, typ usługi, system operacyjny, właściciela technicznego, właściciela biznesowego, certyfikat wraz z datą wygaśnięcia, status monitoringu oraz informację, czy zasób ma prawo być publiczny. To ostatnie pole jest szczególnie ważne. Bez niego rejestr opisuje stan, ale nie ocenia, czy ten stan jest dopuszczalny.

Największa wartość pojawia się na styku dwóch obrazów. CMDB mówi, co firma uważa za istniejące i publiczne. EASM mówi, co realnie widać z Internetu. Zestawienie jednego z drugim ujawnia trzy rodzaje rozjazdu: zasoby w CMDB, których już nie widać z sieci, zasoby widoczne z sieci, których nie ma w CMDB, oraz zasoby zgodne w obu miejscach, ale oznaczone jako niepubliczne. Ta trzecia grupa wymaga najszybszej reakcji.

Sam rejestr jest jednak statyczny. Ożywia go dopiero opis, co robić, gdy dane się zmienią. Kiedy EASM wykrywa nowy zasób, ktoś musi wiedzieć, komu go zgłosić, jak zweryfikować, kiedy wyłączyć i kiedy eskalować. To domena runbooków IT i dokumentacji operacyjnej, które opisują reakcję na konkretne zdarzenia. Rejestr mówi „co mamy”, runbook mówi „co z tym zrobić”. Dopiero razem zamieniają odkrycie w działanie.

Jak monitoring ogranicza powierzchnię ataku

Jednorazowy audyt pokazuje stan na dziś. Żeby powierzchnia ataku nie odrastała w cieniu, odkrywanie musi stać się ciągłe. To zadanie dla monitoringu IT i procesów bezpieczeństwa. Różnica jest zasadnicza: audyt odpowiada na pytanie „co mamy teraz”, monitoring odpowiada na pytanie „co się właśnie zmieniło”.

Monitoring ekspozycji opiera się na kilku sygnałach. Pierwszy to nowe usługi na znanych adresach: port, który wczoraj był zamknięty, a dziś odpowiada, powinien wywołać alert. Drugi to zmiany DNS: nowy rekord, zmiana wskazania, subdomena, której wcześniej nie było. Trzeci to nowe certyfikaty w dziennikach CT. Czwarty to zmiany w widocznych banerach, wersjach usług i odpowiedziach aplikacji.

Narzędzia, które firma zwykle już ma, da się wykorzystać w tym procesie. Zabbix może cyklicznie sprawdzać dostępność portów i usług, kontrolować oczekiwany stan oraz alarmować o odchyleniach. Wazuh może analizować logi, zdarzenia bezpieczeństwa, próby nadużyć i nietypową aktywność na wystawionych usługach. Logi z brzegu sieci pokazują, kto i skąd próbuje łączyć się z nowo odkrytym zasobem. Monitoring IT nie zastępuje EASM, ale sprawia, że odkrycia nie zostają w raporcie.

Trzeba tylko uważać, żeby nie zbudować kolejnego źródła szumu. Alert o nowej ekspozycji ma być rzadki, konkretny i przypisany do reakcji. Jeżeli system będzie generował setki nieistotnych powiadomień, ludzie przestaną je czytać. Jak budować monitoring infrastruktury IT z alertami bez szumu, rozwijamy w osobnym tekście. W kontekście EASM najważniejsza zasada brzmi: nowo odkryty zasób albo trafia do rejestru i pod obserwację jako uzasadniony, albo idzie do ograniczenia lub wyłączenia.

Domknięciem pętli jest utrzymanie. Odkrycie zasobu, wpis do rejestru, decyzja o jego losie, hardening, aktualizacje, monitoring i okresowy przegląd. To normalna część administracji serwerami Linux, którą warto poukładać, zanim wymusi to awaria. EASM nie zastępuje dobrej administracji. Pokazuje tylko, gdzie jej brakuje, i pilnuje, żeby lista publicznych usług była kompletna.

Podsumowanie

Większość firm nie zna własnej powierzchni ataku, bo patrzy na infrastrukturę od środka: przez dokumentację, panele dostawców, pamięć administratorów i założenie, że stare rzeczy zostały kiedyś wyłączone. Atakujący patrzy z zewnątrz. Widzi zapomniane subdomeny, stare rekordy DNS, środowiska testowe, panele administracyjne, backupy, publiczne usługi i serwery Linux, które dawno wypadły z firmowej ewidencji.

External attack surface management odwraca tę przewagę. Pozwala spojrzeć na firmę tak, jak patrzy ktoś z Internetu: przez DNS, certyfikaty SSL/TLS, CT Logs, Shodan, Censys, WHOIS, RDAP, historię domen, otwarte porty i widoczne aplikacje. Bezpieczeństwo infrastruktury zaczyna się od tej wiedzy. Nie da się skutecznie chronić czegoś, o czego istnieniu nikt nie wie.

Najważniejsze są trzy wnioski. Po pierwsze, ekspozycja usług rośnie sama, jeżeli nie ma procesu sprzątania po migracjach, testach i projektach tymczasowych. Po drugie, publiczne źródła pozwalają zmapować znaczną część infrastruktury bez żadnego dostępu wewnętrznego. Po trzecie, jednorazowy audyt nie wystarczy, bo powierzchnia ataku zmienia się z każdą decyzją techniczną. EASM musi zasilać rejestr infrastruktury, monitoring IT, runbooki i codzienną administrację.

Porządkowanie powierzchni ataku nie ma końca w sensie projektu. Ma rytm: odkrycie, weryfikacja, wpis do ewidencji, decyzja, ograniczenie ekspozycji, hardening, monitoring i ponowny przegląd. Firma, która ten rytm ma, nie staje się magicznie odporna na incydenty. Przestaje jednak być zaskakiwana własną infrastrukturą.

Jeżeli chcesz zobaczyć swoją firmę oczami atakującego i uporządkować to, co realnie wystaje do Internetu, pomagamy w tym w ramach bezpieczeństwa środowiska IT, obejmujemy odkryte zasoby monitoringiem infrastruktury IT i układamy ich utrzymanie w ramach administracji serwerami Linux. Dobry moment na pierwszy audyt jest zawsze przed incydentem, nie po nim.