Z pamiętnika admina #2

Firewall, który segmentował tylko na diagramie

„Z pamiętnika admina” to cykl artykułów opartych na autentycznych doświadczeniach – bez podręcznikowej teorii, za to z konkretami prosto z placu boju. 

Pełna lista odcinków: tutaj

Jeżeli AI ma pomagać w pracy sieciowca, to nie może zaczynać od „napisz mi reguły firewall”. To dokładnie ten moment, w którym model brzmi „najmądrzej”, a ryzyko jest największe. Bo reguły firewall bez wiedzy o realnym ruchu są jak projektowanie objazdu bez sprawdzenia, którędy ludzie faktycznie jeżdżą.

Ten odcinek jest o jednej z najładniejszych fikcji w IT: segmentacji na czuja.

Audyt za trzy tygodnie. Manager pyta, czy sieć jest posegmentowana. Odpowiedź przychodzi szybko: Tak, mamy VLAN-y. Jest diagram – USERS, SERVERS, MGMT, BACKUP, GUEST, IOT. Każdy prostokąt ma inny kolor. Strzałki wyglądają rozsądnie. Na poziomie PowerPointa infrastruktura wygląda jak małe dzieło sztuki.

Potem ktoś odpala NetFlow.

I nagle okazuje się, że diagram opowiada historię aspiracyjną, a ruch sieciowy opowiada historię prawdziwą. IoT łączy się z panelem hipernadzorcy. Guest próbuje łączyć się po SSH do serwerów. USERS mają dziwnie dużo ruchu administracyjnego. Backup VLAN jako całość ma dostęp do połowy infrastruktury, chociaż realnie potrzebuje dostępu tylko do części hostów. A w konfiguracji MikroTika siedzi klasyk: accept LAN -> LAN, reguła tymczasowa, która została na tyle długo, że zdążyła stać się częścią kultury organizacyjnej.

To jest moment, w którym AI wydaje się idealnym ratunkiem. Mamy konfigurację RouterOS. Mamy opis VLAN-ów. Mamy politykę bezpieczeństwa. Można poprosić model: „Zaproponuj segmentację i reguły firewall”. Model odpowie. Będzie pewny siebie. Dostaniemy address-listy, allow, deny, komentarze, może nawet plan migracji. Wszystko będzie wyglądało profesjonalnie.

Problem polega na tym, że model nie zna Twojej sieci. Zna tekst, który mu dałeś. Jeśli dasz mu diagram, będzie myślał diagramem. Jeśli dasz mu politykę, będzie myślał polityką. Jeśli nie dasz mu flow, będzie zgadywał, co naprawdę dzieje się między segmentami.

A sieci rzadko są czyste. ERP ma comiesięczny job do starego serwera licencji. Monitoring wygląda jak skanowanie. Backup inicjuje dziwne połączenia o drugiej w nocy. Drukarki mają swoje małe królestwo protokołów. System kontroli dostępu gada z czymś, co według dokumentacji już nie istnieje. Stary wyjątek firewallowy miał zostać usunięty po migracji, której nikt nie pamięta. Każdy admin zna taką archeologię.

Dlatego sensowny proces zmiany powinien zacząć się od obserwacji.

Najpierw trzeba zobaczyć, co naprawdę płynie w kablach. MikroTik Traffic Flow, czyli w zasadzie IPFIX albo przynajmniej same logi z firewalla – źródła mogą być różne. Ważne, żeby dane pochodziły z realnego ruchu, a nie z ręcznie stworzonej tabelki. Dopiero wtedy AI ma materiał do analizy.

Potem dane trzeba zagęścić. Model nie potrzebuje miliona rekordów. Potrzebuje konkretnych danych, takich jak: VLAN-y, subnety, porty, kierunki, reguły firewalla w kolejności, spis usług, polityka docelowa, rzeczy niepewne. Dobre wejście do pracy z LLM to streszczenie faktów, które admin sam rozumie i może zweryfikować.

Dopiero wtedy pytamy AI o analizę. Nie: „Napisz firewall”, tylko: „Które przepływy są zgodne z polityką, które wyglądają podejrzanie, które wymagają decyzji właściciela, gdzie reguły są zbyt szerokie, gdzie brakuje log-only (fazy obserwacyjnej), jaki będzie wpływ proponowanych zmian na zaobserwowany ruch”.

Najważniejszy moment dzieje się po odpowiedzi modelu. Admin patrzy na wynik i zaczyna go „psuć” – w dobrym sensie. „Tego nie blokujemy od razu, bo to może być backup”. „To idzie do właściciela ERP”. „Ta reguła ma sens, ale nie w tej kolejności”. „Tu najpierw logujemy przez dwa tygodnie”. „Guest możemy przyciąć szybciej”. „IoT do MGMT to czerwone światło”.

To jest prawdziwa wartość: AI w takim procesie nie zastępuje admina, tylko skraca drogę od chaosu z flow do listy pytań, hipotez, ryzyk i propozycji zmian. Wciąż potrzebujesz człowieka, który rozumie kierunek reguł, okna serwisowe, zależności aplikacyjne i to, że „Brak ruchu w 24 h” nie znaczy: „Usługa nie istnieje”.

Warto też zachować pokorę wobec danych. NetFlow nie mówi wszystkiego. Nie powie, czy dana komunikacja jest zgodna z intencją biznesu. Nie powie, czy brak ruchu w ciągu 24 godzin oznacza, że usługa nie jest potrzebna. Nie powie, czy ruch do starego serwera jest zależnością krytyczną, czy historycznym śmieciem. NetFlow mówi: „To się wydarzyło”. To już bardzo dużo, ale nadal nie wszystko.

Dlatego w dobrym procesie AI nie klasyfikuje ruchu jako „do usunięcia” i „do zostawienia” w sposób ostateczny. Lepiej, żeby używała kategorii: potwierdzone jako potrzebne, podejrzane, niezgodne z polityką, wymagające właściciela, brak danych. Ta ostatnia kategoria jest szczególnie ważna. W sieciach produkcyjnych brak danych bywa normalny.

Dobry plan zmian na firewallu powinien składać się z poszczególnych etapów. Najpierw address-listy i komentarze. Potem reguły jawnych allow dla znanych zależności. Potem log-only dla rzeczy podejrzanych. Dopiero później drop. Najpierw Guest i IoT, jeśli ryzyko jest niskie i wpływ przewidywalny. Później bardziej wrażliwe segmenty. Default deny na końcu, po obserwacji i analizie ostatecznej.

Wartość AI polega na tym, że może przygotować materiał do rozmowy: macierz komunikacji, listę dziwnych przepływów, mapę właścicieli usług, draft reguł i listę pytań. Ale ostatecznie sieciowiec musi wiedzieć, czy zmiana jest bezpieczna operacyjnie. Bo awaria po złej regule firewall też jest incydentem. Tylko takim, który sami sobie wdrożyliśmy.

Morał? Segmentacja bez nagranego flow to zgadywanie.

VLAN-y na diagramie nie są dowodem segmentacji. Reguły w firewallu nie są dowodem, że ruch jest kontrolowany. Dowód stanowi połączenie konfiguracji, flow, polityki, walidacji i decyzji człowieka. AI może w tym bardzo pomóc. Ale jeśli zaczynasz od „AI, napisz mi reguły”, to nie robisz sieciówki. Robisz promptologię z potencjalnym outage.

Dobry finał takiego procesu to: mamy macierz komunikacji, listę wyjątków, draft konfiguracji MikroTika, symulację wpływu na sieć, plan wdrożenia fazami i plan na ewentualny rollback. A także listę rzeczy, których nie wiemy i których nie wolno rozstrzygać modelem.

PS Podobny problem rozwiązaliśmy na żywo, podczas darmowego szkolenia – AI dla admina. NetFlow, segmentacja i firewallowanie sieci bez zgadywania, gdzie przygotowaliśmy najpierw dane (interfejsy z danymi), z których agent AI mógł skorzystać i dać sensowne rekomendacje. Następnie zamieniliśmy to w cykliczny proces. Nagranie ze szkolenia jest dostępne za darmo tutaj.

~ Maciej Szymczak