Osiem precyzyjnych reguł zapory ogniowej blokujących warianty ransomware Akira, zanim pliki zostaną zaszyfrowane

Moment, w którym wszystko się zmienia

Tor hamowania dla szantażystów: osiem konkretnych reguł zapory, które zatrzymują warianty Akira, zanim zdążą zaszyfrować cokolwiek – nie jutro, lecz dzisiaj.

Na wielkim monitorze pulsują wykresy wychodzącego ruchu, potem czerwony pasek na porcie 445: zablokowany. Administrator w bluzie z kapturem krzyżuje ręce, wypuszcza powietrze – ktoś właśnie próbował nawiązać połączenie na zewnątrz. Klika w logi, widzi próbę, widzi nieudaną lawinę handshake'ów, czuje, jak puls opada. Cisza przed alarmem zawsze jest najgłośniejsza. Dwa tygodnie temu dociągnął reguły wyjściowe, między dwoma spotkaniami, prawie niechętnie. Teraz ten niespektakularny moment się opłaca. Rzadko chodzi o magię. Raczej o małe krawędzie, które tępią noże. Osiem reguł decyduje o wszystkim.

Minuty, które przeważają szalę

Ransomware nie szyfruje od razu. Najpierw szuka dróg, otwiera drzwi, podłącza kroplówkę do świata zewnętrznego: kontakt z centrum dowodzenia, ruch boczny, odpływ danych. W tych minutach decyduje mur, nie skaner. Zapora kontrolująca wyjścia i czysto rozdzielająca segmenty odbiera Akirze tlen. Nieefektownie, za to skutecznie.

Pewien szef IT opowiadał mi o nocnej zmianie w zakładzie: wysyłka stanęła, bo serwer plików nie odpowiadał. Na zewnątrz deszcz, w środku jarzeniówki. Nowe reguły blokowały RDP z zewnątrz i odcinały SMB między działami. 23 próby połączenia umarły w próżni, zanim ktokolwiek zdążył zrestartować ekspres do kawy. Wszyscy znamy ten moment, gdy gardło się ściska – a potem nic się nie dzieje, bo coś małego wcześniej było w porządku.

Logicznie biorąc, wystarczy kilka punktów węzłowych: kto nie pozwala RDP swobodnie oddychać, wiąże SMB tylko z określonymi serwerami i trzyma DNS na krótkiej smyczy, zmniejsza powierzchnię ataku o połowę. Blokada wychodzącego ruchu zamienia paniczną reakcję w planowe zapobieganie. Segmentacja bez kontroli ruchu wychodzącego to papierowy tygrys.

Osiem precyzyjnych reguł zapory, które hamują Akira

Wyobraź sobie cztery ruchy: wychodzące zamknięte, boczne wąskie, wejście tylko przez przedsionek, a wszystko, co może się odezwać, jest znane z imienia i nazwiska. Zacznij od trybu monitorowania, zbieraj dane przez tydzień, potem przełączaj kawałek po kawałku na blokowanie. Małe kroki, wyraźne przedziały czasowe, rollback w kieszeni.

Typowe pułapki: RDP otworzyć „tylko na chwilę", bo dostawca usług czeka. Pozwolić urządzeniom końcowym bezpośrednio na publiczny DNS, „bo szybciej idzie". Albo przeczucie, że wewnętrznie „wszyscy są mili". Bądźmy szczerzy: nikt nie sprząta codziennie starych wyjątków. Buduj więc na białych listach, nie na odwadze. Zapisuj wyjątki z datą wygaśnięcia i właścicielem. Tak łańcuch reguł nie przyklei się jako skamielina w systemie.

Doświadczony lider SOC powiedział mi kiedyś:

„Zapory ogniowe to nie sztuka – to higiena. A higiena działa przed gorączką."

Te osiem reguł jest małych, ale chwyta wcześnie.

• RDP tylko przez przedsionek: przychodzące TCP/3389 z internetu twardo zrzucać. Dostęp wyłącznie przez VPN i bastion host, wewnętrzne przepływy RDP wiązać przez ACL.
• SMB nigdy na zewnątrz: wychodzące TCP/445/139 z sieci klienckich do internetu blokować. Zezwalać tylko na określone serwery plików i kontrolery domeny we własnych sieciach.
• Ruch boczny ograniczyć: RPC/WMI (TCP/135, 593, dynamiczne 49152–65535) oraz SMB między segmentami zablokować. Zezwalać tylko dla podsieci zarządzania i zadań backupu.
• Blokada wychodząca jako podstawowa postawa: domyślnie „cały ruch wychodzący blokuj", potem zwalniaj według FQDN/proxy dla HTTPS, poczty, NTP, usług aktualizacji. Nieznane wysokie porty pozostaw w próżni.
• DNS na smyczy: UDP/TCP 53 tylko do wewnętrznych resolverów. DoT/DoH blokować (TCP/853 i popularne punkty końcowe DoH), opcjonalnie przekierowanie DNS na resolver.
• Zdalny dostęp pod nadzorem: służbowo zatwierdzone narzędzia na białej liście, pozostałe sygnatury zdalnego dostępu i nieznane protokoły tunelowe blokować lub inspekcjonować TLS.
• Geo/reputacja jako filtr: przychodzące/wychodzące do regionów bez związku biznesowego odrzucać. Źródła danych o zagrożeniach dla sieci C2/anonimizatorów wprowadzać automatycznie.
• Ograniczenie tempa i wzorców: tempo połączeń na RDP/SSH/SMB/VPN na źródło dławić, skany wcześnie przerywać. Nieudane próby krótkoterminowo blokować.

Co zostaje, gdy opadnie kurz

Te reguły to nie zamek, to hamulce. Zyskują czas. Czas, w którym alarm SOC jest głośniejszy niż proces szyfrowania, w którym kopie zapasowe pozostają offline, w którym zmiana hasła może zadziałać. Kto zawęża wyjście, zmusza atakujących na niewygodne drogi. Nagle potajemne przesyłanie do chmury staje się biegiem przez przeszkody. Nagle dziwna nazwa DNS zwraca uwagę. Piękno polega na tym, że każdą z tych reguł można zmierzyć. Mniej szumu w logach. Mniej nocnych flirtów portowych. I rodzi się nowy odruch w zespole: najpierw zezwól, potem wyjaśnij. Nie odwrotnie. Bezpieczeństwo przestaje przypominać alarm, a zaczyna być rutyną.

Najczęściej zadawane pytania:

• Czy te reguły blokują każdy wariant Akira? Żadna ochrona nie jest absolutna. Ale odcinają typowe drogi: RDP, SMB, nadużycie DNS, wyprowadzenie C2.
• Czy zepsujemy tym legalne przepływy pracy? Tylko jeśli brakuje zwolnień. Zacznij w trybie monitorowania, zinwentaryzuj cele, zezwalaj celowo i z datą wygaśnięcia.
• A co z Linuksem, ESXi i kopiami zapasowymi? Zasady obowiązują tak samo: segmentacja, blokada wychodząca, dostępy zarządcze tylko z dedykowanych sieci, sieć backupu izolowana.
• Jak testować bez przestoju? Włącz reguły najpierw w „Alert/Podgląd zrzutu", wykorzystaj okna zmian, trzymaj gotowy rollback. Dokumentuj każdy wyjątek.
• Które logi pomagają przy dostrajaniu? Zrzuty zapory według celu/portu, zapytania DNS, blokady proxy, błędy uwierzytelniania VPN. Kombinacja pokazuje wzorce, nie pojedyncze pingi.