Konfiguracja Sophos Firewall Discover Mode z TAP i SPAN

W trybie Discover Mode Sophos Firewall odbiera kopię ruchu sieciowego przez interfejs TAP. Przełącznik przesyła lustrzaną kopię ruchu z wybranych portów lub sieci VLAN do portu SPAN albo mirror połączonego z nieprzypisanym portem zapory. Zapora nie pracuje inline i nie zmienia produkcyjnej ścieżki pakietów.

Skrócona procedura: Zapewnić oddzielny dostęp administracyjny, skonfigurować na przełączniku dwukierunkowy port SPAN, wybrać nieprzypisany port zapory, wykonać system discover-mode tap add PortD w Device Console i najpierw sprawdzić ruch wejściowy za pomocą Packet Capture. Następnie ocenić Current Activity, raporty i w razie potrzeby Security audit report.

⚠️ Discover Mode jest trybem obserwacyjnym. Do ruchu na interfejsie TAP nie można stosować Security Policies, a zapora nie może go blokować ani odrzucać. HTTPS nie jest obsługiwany w tym trybie. Raport bez wykrytych zdarzeń nie potwierdza więc ani pełnej widoczności, ani skutecznej ochrony.

PortD jest przykładem używanym w tej instrukcji. Należy wykorzystać rzeczywiście wolny port fizyczny urządzenia.

Discover Mode w ośmiu krokach

1. Sprawdzić niezależny port zarządzający zapory i bezpieczną drogę odzyskania dostępu administracyjnego.
2. Określić na przełączniku, które porty lub sieci VLAN mają być kopiowane w obu kierunkach.
3. Połączyć dedykowany port mirror z nieprzypisanym fizycznym portem zapory.
4. W Device Console zapisać stan początkowy za pomocą system discover-mode tap show.
5. Aktywować przykładowy port jako TAP poleceniem system discover-mode tap add PortD.
6. W Network > Interfaces sprawdzić typ Discover, physical (TAP).
7. Wygenerować znany przepływ testowy i potwierdzić jego pakiety na interfejsie TAP.
8. Dopiero potem ocenić raporty, przypisanie użytkowników i Security Audit Report.

Przełącznik i zapora są konfigurowane oddzielnie. Widoczny interfejs TAP nie potwierdza jeszcze, że przełącznik kopiuje właściwe ramki.

Kiedy TAP pasuje, a kiedy nie

Discover Mode sprawdza się podczas pasywnej inwentaryzacji, proof of concept lub analizy wstępnej przed późniejszym wdrożeniem inline. Typowe cele to:

• uwidocznienie relacji ruchu i aktywnych aplikacji;
• klasyfikacja kategorii internetowych i aplikacyjnych w granicach technicznych;
• obserwacja wykryć IPS bez zmiany ścieżki danych;
• gromadzenie raportów do późniejszego planowania polityk i segmentacji;
• ocena nowej zapory równolegle z istniejącą infrastrukturą.

TAP nie jest właściwym wyborem, jeśli ruch musi być już aktywnie blokowany, odszyfrowywany, modyfikowany przez NAT lub kontrolowany regułami opartymi na użytkownikach. Wymaga to trybu gateway, bridge albo innego trybu inline z odpowiednimi regułami zapory.

Discover Mode można łączyć z trybami gateway, mixed i bridge. Reguły bezpieczeństwa działają wtedy na zwykłych interfejsach inline, a nie na interfejsie TAP. Artykuł Planowanie stref i interfejsów Sophos Firewall wyjaśnia zależności między portami fizycznymi, strefami, mostami i innymi typami interfejsów.

Przykładowa topologia i wartości do zastąpienia

W przykładzie używane są następujące elementy:

• Przełącznik rdzeniowy: SW-Core-01
• Kopiowany uplink: Switch-Port 1, odbiór i wysyłanie
• Cel SPAN: Switch-Port 24
• TAP zapory: PortD, nieprzypisany i bez konfiguracji IP
• Zarządzanie zaporą: PortA - 10.10.10.16/24
• Klient testowy: 10.20.30.40

Nazwy i adresy są przykładami. Decydująca jest funkcja: port TAP odbiera wyłącznie lustrzane ramki. Zarządzanie, aktualizacje, DNS i wysyłanie raportów odbywają się przez inny, normalnie skonfigurowany interfejs.

Port mirror musi być co najmniej tak szybki jak obserwowany ruch. Jeśli kilka mocno obciążonych portów źródłowych jest kopiowanych do wolniejszego portu docelowego, przełącznik może odrzucać pakiety z kopii. Połączenie produkcyjne działa nadal, ale raport pozostaje niepełny. TAP nie jest więc bezstratnym zapisem śledczym, a brak zdarzenia nie dowodzi, że ono nie wystąpiło.

Wymagania i granice bezpieczeństwa

Przed aktywacją należy wyjaśnić następujące kwestie:

• Zarządzany przełącznik obsługuje SPAN lub port mirroring.
• Fizyczny port zapory jest nieprzypisany i nieużywany produkcyjnie.
• Administracja pozostaje dostępna przez oddzielny interfejs.
• Zapora ma dostęp do Internetu na potrzeby klasyfikacji w chmurze, aktualizacji IPS i generowania Security Audit Report.
• Jeśli raport ma pokazywać użytkowników, a nie tylko adresy IP, zintegrowano odpowiednie zewnętrzne źródło uwierzytelniania.
• Cel, okres przechowywania i odbiorcy kopiowanych danych spełniają wymagania dotyczące prywatności.

Lustrzane ramki mogą ujawnić adresy wewnętrzne, zapytania DNS, nieszyfrowane protokoły i relacje komunikacyjne. Dlatego Packet Capture i raporty należy przechowywać tylko tak długo, jak jest to konieczne, oraz przekazywać w sposób chroniony.

Prawidłowa ocena Port Affinity

Dla niektórych platform instrukcja Sophos zaleca powiązanie interfejsu TAP z procesorem za pomocą bind-with przed aktywacją. Urządzenia XGS nie wymagają ręcznej konfiguracji Port Affinity, ponieważ przetwarzanie jest automatycznie rozdzielane między rdzenie procesora.

Na innych urządzeniach i platformach wirtualnych właściwe przypisanie CPU zależy od sprzętu, adaptera i obciążenia. Nie należy kopiować wartości CPU z obcego przykładu. Jeśli platforma wymaga ręcznego przypisania, trzeba je zaplanować przed wdrożeniem TAP zgodnie z właściwą dokumentacją urządzenia lub zaleceniami pomocy technicznej. Ogólne polecenie set port-affinity nie należy do standardowej skróconej procedury.

W przypadku zapory wirtualnej trzeba także upewnić się, że hypervisor, vSwitch i wirtualna karta sieciowa rzeczywiście dostarczają lustrzane ramki do maszyny wirtualnej. Sam stan wirtualnej karty sieciowej tego nie potwierdza; decydujący jest dowód pakietowy w SFOS.

Przygotowanie SPAN lub port mirroring na przełączniku

Dokładna konfiguracja zależy od producenta. Na przełączniku trzeba określić co najmniej następujące wartości:

1. Source: obserwowany port fizyczny lub planowane sieci VLAN.
2. Direction: odbiór i wysyłanie, aby były widoczne oba kierunki.
3. Destination: dedykowany port połączony z PortD zapory.
4. Session status: włączony.

Portu docelowego nie należy używać jednocześnie jako normalnego portu access lub trunk dla endpointów. Portu zarządzającego zapory również nie wolno łączyć z portem mirror. W przeciwnym razie ścieżki zarządzania i obserwacji mieszają się albo przełącznik tworzy nieoczekiwaną topologię warstwy 2.

Przed konfiguracją zapory warto udokumentować, które sieci VLAN i kierunki są faktycznie kopiowane przez przełącznik. Na dużych uplinkach pilot lepiej rozpocząć od pojedynczej testowej sieci VLAN lub jasno ograniczonego portu zamiast od razu od całego ruchu rdzeniowego.

Aktywowanie interfejsu TAP na Sophos Firewall

W Network > Interfaces wybrany port musi mieć strefę None i nie może mieć konfiguracji IP ani zależności produkcyjnych. Nie należy odłączać używanego portu tylko na potrzeby testu: może to przerwać działanie interface hosts, DHCP, routingu, reguł lub innych usług.

Po zalogowaniu do Sophos Firewall przez SSH należy otworzyć Option 4: Device Console. Najpierw odczytać bieżący stan:

system discover-mode tap show

Następnie aktywować planowany port przykładowy i ponownie go sprawdzić:

system discover-mode tap add PortD
system discover-mode tap show

Sophos dokumentuje komunikat Discover Interface added successfully dla prawidłowej aktywacji. Port pojawia się następnie w Network > Interfaces jako Discover, physical (TAP).

Polecenie nie konfiguruje SPAN na przełączniku. Jeśli port ma prawidłowy stan SFOS, ale nie odbiera ruchu, najpierw należy sprawdzić stronę przełącznika, zamiast tworzyć regułę zapory na podstawie przypuszczenia.

Weryfikacja ruchu i raportów

1. Przeprowadzenie kontrolowanego testu pakietów

Na kliencie testowym 10.20.30.40 należy wygenerować jednoznaczny test DNS albo nieszyfrowany test HTTP. W Diagnostics > Packet capture użyć wąskiego filtra BPF:

host 10.20.30.40

W przechwytywaniu muszą być widoczne pakiety z In interface PortD. Przy kopiowaniu dwukierunkowym pojawia się zapytanie i odpowiedź. Firewall Rule ID ani stan Forwarded nie są kryterium sukcesu na pasywnej ścieżce TAP, ponieważ SFOS nie przekazuje tego ruchu i nie stosuje do niego Security Policy.

Artykuł Packet Capture w Sophos Firewall WebAdmin wyjaśnia obsługę, filtry i ograniczenia eksportu. Po teście należy zatrzymać przechwytywanie i zachować tylko niezbędny zakres czasu.

2. Merytoryczna weryfikacja widoczności

Po potwierdzeniu pakietów należy sprawdzić Current activities i odpowiednie raporty lokalne. Oczekiwania muszą odpowiadać protokołowi:

• widoczne adresy źródłowe i docelowe odpowiadają testowi;
• kategorii aplikacji lub stron internetowych można oczekiwać tylko tam, gdzie SFOS potrafi sklasyfikować ruch;
• wykrycie IPS jest obserwacją, a nie blokadą;
• użytkownicy pojawiają się tylko przy działającym źródle tożsamości i prawidłowym przypisaniu;
• zawartość HTTPS nie jest obsługiwana w Discover Mode.

Zewnętrzne źródło użytkowników trzeba przetestować oddzielnie. W przypadku Active Directory pomaga artykuł Połączenie Active Directory z Sophos Firewall. Brak nazwy użytkownika nie oznacza wtedy automatycznie braku ruchu TAP.

3. Generowanie Security Audit Report

W Reports > Show report settings > Report scheduling > Add należy wybrać typ Security audit report. Świadomie wprowadzić odbiorców i organizację, a następnie oddzielnie sprawdzić transport poczty i zawartość raportu.

Artykuł Planowanie raportów Sophos Firewall i wysyłanie ich pocztą elektroniczną wyjaśnia granice Send test mail, Generate now, prywatność, język i zachowanie HA. Prawidłowa wiadomość testowa potwierdza tylko ścieżkę poczty. Dopiero wygenerowany raport z wiarygodnymi danymi potwierdza całą ścieżkę.

HA i mieszane tryby pracy

Discover Mode obsługuje tylko HA active-passive. HA active-active nie jest możliwe, gdy jedna z zapór działa w Discover Mode.

Klastra active-passive nie można utworzyć, gdy interfejs TAP jest aktywny. Aby skonfigurować HA, trzeba wyłączyć port TAP na obu urządzeniach, utworzyć HA, a następnie włączyć interfejs TAP oddzielnie na obu urządzeniach. Sophos zaznacza również, że interfejs TAP pozostaje aktywny na urządzeniu pasywnym.

Dlatego po planowanej zmianie ról należy ponownie sprawdzić okablowanie, kopiowanie na przełączniku i odbiór danych. Nie należy zakładać, że istniejący okres raportowania lub obserwacja TAP będą kontynuowane bez przerwy na drugim węźle. Artykuł Konfiguracja HA na Sophos Firewall opisuje role, synchronizację i działanie lokalne węzłów.

W mieszanym projekcie gateway lub bridge granica również pozostaje jasna: normalne interfejsy mogą przekazywać i chronić ruch. Interfejs TAP odbiera tylko lustrzaną kopię.

Rozwiązywanie problemów według objawu

Interfejs TAP nie pokazuje żadnych pakietów

1. Sprawdzić skonfigurowany port poleceniem system discover-mode tap show.
2. W Network > Interfaces sprawdzić typ Discover, physical (TAP) i łącze fizyczne.
3. Porównać cel na przełączniku, porty źródłowe lub sieci VLAN i kierunek kopiowania.
4. Powtórzyć znany przepływ testowy bez zbyt wąskiego filtra przechwytywania.
5. W przypadku VM sprawdzić, czy wirtualna ścieżka sieciowa dostarcza do zapory skopiowane obce ramki.

Reguła zapory nie jest rozwiązaniem, ponieważ ruch TAP nie jest przekazywany przez normalny Rule Engine.

Widoczny jest tylko jeden kierunek

Źródło mirror na przełączniku jest często ustawione tylko na RX albo TX. Należy zmienić sesję na both, czyli oba kierunki, i powtórzyć ten sam test. Przy routingu asymetrycznym ścieżka powrotna może również przebiegać przez inny fizyczny uplink, który nie jest kopiowany.

Pakiety są widoczne, ale raporty są puste lub niepełne

Najpierw należy sprawdzić zakres czasu, typ raportu, dostęp do Internetu, stan sygnatur i rzeczywiście kopiowane protokoły. HTTPS nie jest obsługiwany w Discover Mode. Przeciążony cel SPAN może też tracić kopie bez wpływu na ruch produkcyjny.

Jeśli brakuje użytkowników, trzeba kontynuować od źródła uwierzytelniania. Jeśli nie działa tylko wysyłka poczty, najpierw sprawdzić powiadomienia e-mail. Nie należy restartować usług raportowania na podstawie przypuszczenia ani usuwać lokalnych danych raportów jako pierwszego kroku.

Raport pokazuje ryzyka, ale nic nie jest blokowane

To oczekiwane zachowanie. Discover Mode ocenia kopię. Wykrycie prowadzi do późniejszej polityki inline, segmentacji lub innego środka ochronnego dopiero po analizie technicznej. Zapora TAP nie może później zatrzymać obserwowanego oryginalnego przepływu.

Bezpieczne wycofanie Discover Mode

Przed wycofaniem należy zachować potrzebne raporty, zakresy czasu i ustalenia. Następnie:

1. Wyłączyć sesję SPAN na przełączniku, aby nie docierały kolejne kopie.
2. Usunąć przykładowy port w Device Console:

system discover-mode tap delete PortD
system discover-mode tap show

3. W Network > Interfaces sprawdzić, czy port nie jest już wyświetlany jako Discover, physical (TAP).
4. W kontrolowany sposób usunąć niepotrzebne harmonogramy Security Audit.
5. Dopiero po udokumentowanej kontroli ponownie używać normalnie portu docelowego przełącznika.
6. Jeśli port zapory będzie używany produkcyjnie, zaplanować i przetestować jego strefę, adres IP, zależności i reguły jako oddzielną zmianę.

Nie należy łączyć wycofania TAP z improwizowaną migracją inline. Tryb gateway lub bridge zmienia routing, reguły i ryzyko przerwy i wymaga oddzielnego planu migracji.

Lista kontrolna

• Oddzielny dostęp administracyjny działa.
• Port TAP jest fizyczny, nieprzypisany i nieużywany gdzie indziej.
• Source, Direction i Destination sesji SPAN są udokumentowane.
• Cel mirror nie jest przeciążony.
• system discover-mode tap show pokazuje oczekiwany port.
• Packet Capture widzi znany przepływ testowy w obu kierunkach.
• Raporty są oceniane wyłącznie w ramach obsługiwanej widoczności.
• HTTPS i brak enforcement są udokumentowane.
• Przypisanie użytkowników zostało w razie potrzeby przetestowane oddzielnie.
• Odbiorcy raportów i okres przechowywania są zatwierdzone.
• Granice HA lub VM zostały sprawdzone w rzeczywistym wdrożeniu.
• Wycofanie i późniejsza migracja inline są oddzielnymi zmianami.

FAQ