Wprowadzenie inspekcji TLS w Sophos Firewall

Dzięki kontroli TLS Sophos Firewall kończy szyfrowane połączenie klienta i ustanawia drugie połączenie z serwerem docelowym. Może sprawdzić tekst jawny między nimi. Zapora ponownie podpisuje pierwotnie zaufany certyfikat serwera dla klienta przy użyciu własnego urzędu certyfikacji (CA). Jeśli klient nie ufa temu urzędowi certyfikacji, wyświetli ostrzeżenie o certyfikacie lub zakończy połączenie.

Umożliwia to kontrolę odszyfrowanej zawartości, w tym skanowanie złośliwego oprogramowania i zawartości. Bez odszyfrowania funkcje ochrony mogą zostać ograniczone, w zależności od modułu, do informacji takich jak adres IP, domena, SNI, certyfikat lub metadane protokołu. Nie uzasadnia to początkowego wdrożenia na szeroką skalę: przed wdrożeniem należy uwzględnić przypinanie certyfikatów, prywatność, zgodność aplikacji i dodatkowe obciążenie zapory ogniowej.

Bezpieczna, krótka wersja to: określ, czy chcesz używać ścieżki DPI czy Web Proxy, rozprowadź ponownie podpisujący urząd certyfikacji wśród małej grupy, udokumentuj bieżący stan, utwórz regułę odszyfrowania o wąskim zakresie, przeprowadź jeden test pozytywny i jeden negatywny, a dopiero potem rozszerz zakres.

Decyzje przed projektem pilotażowym

Licencja, CA i odpowiedzialność

Reguły inspekcji SSL/TLS i użyte w nich grupy adresów URL są egzekwowane za pomocą Base License. Web Protection nie jest ogólnym warunkiem wstępnym inspekcji TLS. Jest to wymagane, gdy kategorie internetowe są używane jako kryteria reguł lub gdy potrzebne są odpowiednie funkcje Ochrony sieci. Kontrole złośliwego oprogramowania, Zero-Day i inne wymagają odpowiedniej subskrypcji. Jakie pakiety zapory Sophos są dostępne? i Opis podstawowej licencji Sophos Firewall wyjaśniają różnice.

Przed utworzeniem pierwszej reguły wyjaśnij następujące kwestie:

• Udokumentuj używaną wersję SFOS, dostępną licencję i zamierzoną ścieżkę inspekcji.
• Zdefiniuj zarządzaną grupę pilotażową i jasne okno czasowe. Poniższy przykład wykorzystuje klienta 10.20.30.50 z sieci testowej 10.20.30.0/24; zastąp te wartości własnymi obiektami.
• Uzyskaj zgodę od odpowiedzialnych interesariuszy ds. prywatności w zakresie zakresu, rejestrowania, przechowywania i powiadamiania użytkowników.
• Utwórz kopię zapasową dokładnego stanu początkowego reguły zapory sieciowej, reguł TLS, profilu deszyfrowania, urzędu certyfikacji i wszelkich ustawień globalnych. Zapisz pełną ścieżkę dopasowania sprzed pilota, regułę, która zostanie dopasowana po wyłączeniu pilota (w tym każdą niższą, szerszą regułę Decrypt), oraz każdą zmianę wprowadzoną wyłącznie na potrzeby pilota w regułach zapory sieciowej, trybie DPI/proxy, Web Policy i ustawieniach globalnych. Przed aktywacją określ dokładne, autoryzowane kroki przywracania.
• Podaj nazwę właściciela, kryteria przerwania, proces wyjątku i ścieżkę wycofania.

Ponownie podpisujący urząd certyfikacji musi znajdować się w magazynie zaufania systemów operacyjnych lub przeglądarek, których dotyczy problem. Alternatywnie użyj podrzędnego urzędu certyfikacji przedsiębiorstwa. Do tego celu nie jest dostępny publicznie zaufany urząd certyfikacji, ponieważ zapora sieciowa ponownie podpisuje certyfikaty dla domen stron trzecich. W przypadku zewnętrznego urzędu certyfikacji należy zaimportować zarówno główny, jak i podrzędny urząd certyfikacji; jeśli urząd certyfikacji podpisujący zawiera sekcję EKU, musi zezwalać na TLS Web Server Authentication. Zainstaluj certyfikat CA zapory Sophos do skanowania HTTPS opisuje dystrybucję, natomiast Skonfiguruj podrzędny urząd certyfikacji do inspekcji TLS zapory Sophos obejmuje metodę korporacyjnego urzędu certyfikacji.

⚠️ Nie zaczynaj od wszystkich użytkowników. Urządzenia bez zarządzalnego magazynu zaufania, BYOD i aplikacje korzystające z przypinania certyfikatów powinny początkowo pozostać w odrębnym zakresie. Wyjątek przywraca połączenie, ale usuwa jego zawartość z deszyfrowania.

Oddziel DPI i serwer proxy sieci Web

SFOS domyślnie używa DPI engine. Na tej ścieżce zapora przetwarza najpierw regułę zapory, a następnie reguły inspekcji SSL/TLS. Reguła inspekcji sama w sobie nie zezwala na ruch: nawet Services: Any oznacza jedynie, że ruch TLS dozwolony już przez regułę zapory na dowolnym porcie TCP kwalifikuje się do tej reguły inspekcji.

Dla ścieżki DPI otwórz Rules and policies > Firewall rules, edytuj odpowiednią regułę LAN-to-WAN i sprawdź Security features > Web filtering:

1. Pozostaw Use web proxy instead of DPI engine wyłączony.
2. Wybierz Web Policy tylko wtedy, gdy wymaga tego planowana ochrona; nie jest to warunek wstępny zastosowania reguły deszyfrowania.
3. Scan HTTP and decrypted HTTPS umożliwia skanowanie treści HTTP i już odszyfrowanych treści HTTPS w poszukiwaniu złośliwego oprogramowania. Ta opcja sama w sobie nie umożliwia odszyfrowania protokołu HTTPS.

W Web Proxy Mode serwer proxy obsługuje deszyfrowanie HTTPS. Decrypt HTTPS during web proxy filtering to odpowiednie ustawienie na ścieżce proxy. Reguły DPI w Rules and policies > SSL/TLS inspection rules nie mają zastosowania do połączeń odszyfrowanych przez serwer proxy sieci Web. W przypadku przezroczystego serwera proxy porty 80 i 443 przechodzą przez serwer proxy, podczas gdy protokół SSL/TLS na innych portach może być nadal obsługiwany przez ścieżkę DPI; w przypadku jawnego serwera proxy serwer proxy sieci Web wykonuje odszyfrowanie.

Urzędy certyfikacji są również oddzielne: DPI używa urzędu certyfikacji z ustawień SSL/TLS lub wybranego profilu deszyfrowania. Serwer proxy sieci Web korzysta z urzędu certyfikacji z Web > General settings. Zmieniając tryb, sprawdź nie tylko zasady, ale także faktycznie zaprezentowany urząd certyfikacji. Wybierz poprawnie silnik DPI lub serwer proxy sieci Web wyjaśnia różnice bardziej szczegółowo.

Ta ścieżka kontroli wychodzącej nie jest przeznaczona dla serwerów internetowych publikowanych w Internecie. Ochrona serwera WWW / WAF lub odwrotne proxy to zazwyczaj bardziej odpowiednia architektura. Reguły inspekcji SSL/TLS mają zastosowanie do ruchu wychodzącego, dlatego jako Source zones można wybrać tylko strefy wewnętrzne. Wykrywają TLS na dowolnym porcie TCP, ale nie są wymuszane przez UDP.

Sprzeczność dokumentacji dotycząca kierunku ruchu: Instrukcja tworzenia reguł wspomina połączenia przychodzące i wychodzące, lecz dalej wyraźnie ogranicza Source zones do stref wewnętrznych i ruchu wychodzącego. Ogólne sformułowanie nie potwierdza obsługi inspekcji przychodzącej z WAN. To wdrożenie pozostaje przy opisanej ścieżce klientów wewnętrznych; przed zmianą połączeń przychodzących do serwera potrzebne jest wyjaśnienie Sophos Support dla używanej kompilacji.

Routing, DNS i dozwolony dostęp do Internetu muszą działać przed testem odszyfrowywania. W Rules and policies > NAT rules sprawdź regułę SNAT, która rzeczywiście pasuje; w typowej architekturze IPv4 może to być Default SNAT IPv4 z Translated source (SNAT): MASQ. Nie zastępuj działającej reguły kolejną szeroką regułą NAT. IPv6 i sieci routowane wymagają osobnej decyzji projektowej, nie automatycznie MASQ. Reguła zapory dla pilotażu wymaga Action: Accept oraz zatwierdzonego zakresu źródła, celu i usług.

Dla proxy sprawdź również HTTPS scanning certificate authority (CA), Block unrecognized SSL protocols i Block invalid certificates w Web > General settings > HTTPS decryption and scanning. Dla Direct Proxy udostępnij skonfigurowany listener w Web > General settings > Web proxy configuration oraz Administration > Device access > Other services > Web proxy tylko wymaganym klientom lub strefom. Transparent proxy wymaga usług HTTP/HTTPS; Direct Proxy dodatkowo skonfigurowanego portu listenera. Podlinkowany wcześniej artykuł DPI/proxy opisuje pełny proces i ochronę lokalnych usług WWW zapory.

Nieaktualny przykład zgodności: Zachowana instrukcja konfiguracji SFOS 22/23 wymaga TLS 1.1 w przykładzie proxy, podczas gdy dokumentacja profili uznaje wersje wcześniejsze niż TLS 1.2 za niebezpieczne. TLS 1.1 nie jest więc przyjmowany jako wymaganie wdrożenia. Zachowaj bezpieczne ustawienia protokołów; jeśli starsza aplikacja wymaga wyjątku, najpierw uzgodnij z właścicielem zapory wersję, ścieżkę, ryzyko i wąski zakres. Globalne obniżenie TLS nie jest rozwiązaniem dla pilotażu.

Świadome zarządzanie QUIC

QUIC, czyli HTTP/3, wykorzystuje UDP. Block QUIC protocol w regule zapory sieciowej zrzuca wychodzące pakiety UDP na porty 80 i 443 w zakresie tej reguły, zwykle skłaniając klientów z dostępną, działającą ścieżką awaryjną TCP do ponowienia połączenia przez TCP; klienci bez takiej ścieżki mogą utracić łączność. SFOS wybiera tę opcję domyślnie natychmiast po wybraniu Web Policy w regule lub włączeniu Scan HTTP and decrypted HTTPS. Dotyczy to reguły, a nie globalnej, więc sprawdź regułę zapory sieciowej, która faktycznie pasuje. Ta opcja nie obejmuje UDP na innych portach. Zweryfikuj rzeczywiste połączenie TCP, działanie aplikacji i dopasowanie do zamierzonej ścieżki inspekcji; samo blokowanie UDP nie potwierdza żadnego z tych warunków.

Ten filtr sieciowy nie może skanować QUIC. Nie oznacza to, że wszystkie inne elementy sterujące zapory sieciowej są pomijane, ale oczekiwana ścieżka TCP TLS i filtr sieciowy nie ma zastosowania. Prawidłowe blokowanie QUIC i HTTP/3 w zaporze Sophos pokazuje test reguły; Tworzenie polityki ochrony sieciowej zapory Sophos dotyczy polityki sieciowej.

Wybierz zakres według celu i ryzyka

Zwykle punktem wyjścia jest zarządzany ruch użytkowników z LAN do WAN. Oddzielna korporacyjna sieć bezprzewodowa może działać jako Wi-Fi > WAN. W przypadku dostępu zdalnego VPN > WAN ma zastosowanie tylko wtedy, gdy ruch internetowy użytkowników faktycznie przechodzi przez zaporę sieciową przez pełny tunel. Uwzględniaj połączenia wewnętrzne od LAN do DMZ tylko wtedy, gdy kontrola treści przynosi tam wyraźne korzyści, klient ufa urzędowi certyfikacji ponownie podpisującemu certyfikaty, a zapora sieciowa weryfikuje oryginalny łańcuch certyfikatów serwera. Zwykłe serwery docelowe nie wymagają instalacji tego urzędu certyfikacji używanego do inspekcji. Zgodność z wzajemnym uwierzytelnianiem TLS (mTLS) oceń osobno.

Zgodność techniczna i pozwolenie na odszyfrowanie to osobne decyzje. Portale bankowe, zdrowotne i rządowe, menedżery haseł, dostawcy tożsamości, aktualizacje systemów operacyjnych i dostawców, a także usługi głosowe, wideo i współpracy wymagają oceny funkcjonalnej i prywatności przed ich włączeniem. Przypinanie lub awaria programu pilotażowego nie uzasadnia ogólnego wyjątku dla całej kategorii: najpierw należy zidentyfikować rzeczywiście wymagane źródło, domenę i aplikację.

Skonfiguruj kompletny pilot

W przypadku pilota, który można przetestować bezpośrednio, używamy następujących przykładowych wartości:

• Klient pilotażowy: 10.20.30.50 z udokumentowanej sieci testowej 10.20.30.0/24
• Reguła zapory sieciowej: LAN to WAN - TLS pilot
• Reguła inspekcji SSL/TLS: TLS decrypt pilot client
• Strefa źródłowa: LAN, Strefa docelowa: WAN
• Sieci i usługi docelowe: Any
• Działanie: Decrypt
• Profil deszyfrowania: początkowo Block insecure SSL lub wywodzący się z niego profil pilotażowy
• Rejestrowanie: Log connections włączone dla pilota

10.20.30.0/24, adres IP hosta i nazwy obiektów mają charakter przykładowy. Źródło produkcyjne musi być na tyle wąskie, aby jednoznacznie identyfikować jednego klienta. Any dla miejsca docelowego i usługi ułatwia obserwację TLS poza TCP 443 podczas pilotażu; nie rozszerza to, na co pozwala poprzednia Reguła zapory sieciowej. Jeśli inspekcja jest dozwolona tylko dla określonej grupy docelowej, dodaj grupę adresów URL lub inne odpowiednie kryterium miejsca docelowego.

Wybierz profil deszyfrowania

W Profiles > Decryption profiles dostępne są trzy nieedytowalne profile domyślne:

• Maximum compatibility maksymalizuje kompatybilność i nie ogranicza szyfrów.
• Block insecure SSL blokuje słabe szyfry i umożliwia ruch, którego nie można odszyfrować.
• Strict compliance stosuje rygorystyczne wymagania, w tym wymagania oparte na PCI DSS.

Maximum compatibility może pomóc doraźnie zawęzić przyczynę problemu z klientem, ale jego luźne kontrole sprawiają, że nie nadaje się jako kryterium akceptacji produkcji. Dla pilota Block insecure SSL lub profil celowo z niego wyprowadzony jest bardziej przejrzystym punktem wyjścia. Toleruj stare wersje TLS lub klucze RSA krótsze niż 2048 bitów tylko w przypadku nazwanego starszego serwera i w regule o wąskim zakresie.

Odrzucanie starszych połączeń przy Decrypt: Przy ustawieniu Action: Decrypt Sophos Firewall nadal odrzuca połączenia używające SSL 2.0 and SSL 3.0, SSL compression lub Unrecognized cipher suites, nawet jeśli w profilu wybrano dla nich Allow without decryption. Jawnie zatwierdzone zezwolenie na starsze połączenia o wąskim zakresie wymaga zarówno Allow without decryption w odpowiednich polach profilu, jak i Action: Don’t decrypt; samo zezwolenie w profilu nie wystarcza.

Profil niestandardowy może zastąpić globalne ustawienia protokołu SSL/TLS. Opcje ponownego podpisania urzędu certyfikacji to Use CAs defined in SSL/TLS settings, Re-sign RSA with i Re-sign EC with. W przypadku ruchu, którego nie można odszyfrować, dostępne są następujące opcje: Use SSL/TLS settings default, Allow without decryption, Drop i Reject. Odniesienie do ustawień globalnych nie ma zastosowania do Unrecognized cipher suites; ten przypadek należy ocenić wyraźnie w profilu. W zależności od ustawienia, błędów certyfikatów, minimalnego rozmiaru RSA, wersji TLS i zablokowanych szyfrów, jako Block action użyj Drop, Reject lub Reject and notify.

Kontrola nie sprawia, że ​​certyfikat serwera z podpisem własnym lub certyfikat z niekompletnym łańcuchem jest godny zaufania. Zamiast pochopnie go wykluczać, najpierw sprawdź nazwę hosta, oryginalny certyfikat i cały łańcuch.

Dla samopodpisanego oryginału zapora zastępuje klucz i podpisuje tym kluczem, a nie jako zaufany CA: klient nadal widzi certyfikat samopodpisany. Jeśli brakuje pełnego łańcucha do CA zaufanego przez zaporę, używany jest certyfikat wygenerowany przez system, którego CN wyjaśnia problem. Ostrzeżenie nie oznacza więc automatycznie błędu dystrybucji CA.

Utwórz profil niestandardowy w Profiles > Decryption profiles > Add, podając nazwę i opis, lub sklonuj odpowiedni profil; następnie zapisz go i przypisz do reguły inspekcji. Oryginalne certyfikaty RSA i EC często mogą korzystać z tego samego podpisującego CA. Jeśli aplikacja wymaga konkretnego typu klucza, wybierz odpowiedni CA w Re-sign RSA with lub Re-sign EC with. Pobierz każdy faktycznie używany CA przyciskiem obok wyboru; przy dwóch różnych CA klienci muszą ufać obu.

Przed zapisaniem oceń Certificate errors to block, Minimum RSA key size, Minimum SSL/TLS version, Maximum SSL/TLS version i Cipher algorithms to block. TLS poniżej 1.2 i RSA poniżej 2048 bitów nie są bezpiecznymi ustawieniami domyślnymi. Maximum supported dopuszcza najwyższą obsługiwaną wersję protokołu. Kontrola Revoked wymaga zaimportowanej CRL (Certificate Revocation List); samo zaznaczenie pola nie potwierdza działania kontroli unieważnienia. Web Exception dla HTTPS decryption może dopuścić pasujące połączenia z nieprawidłowymi certyfikatami, więc nie jest jedynie naprawą pinningu.

Błędy certyfikatu obejmują Invalid date, Self-signed, Untrusted user, Revoked, Name mismatch i Invalid for other reasons. Name mismatch porównuje nazwę serwera z Client Hello z nazwami w certyfikacie. Przy wyborze blokowanych algorytmów oceń oddzielnie wymianę kluczy, uwierzytelnianie, szyfry danych i algorytmy hash. Kompresja SSL przed szyfrowaniem ma znane podatności; nieznanych szyfrów nie można odszyfrować.

Ustawienia globalne są w Rules and policies > SSL/TLS inspection rules > SSL/TLS inspection settings. TLS 1.3 decryption oferuje Decrypt as 1.3 i Downgrade to TLS 1.2 and decrypt. Druga opcja wpływa na wszystkie reguły inspekcji SSL/TLS; nie obniżaj TLS globalnie dla zwykłego pilotażu.

When SSL/TLS connections exceed limit określa zachowanie po wyczerpaniu możliwości odszyfrowywania: Allow without decryption zachowuje dostępność, ale wyłącza inspekcję zawartości; Drop odrzuca bez powiadomienia, a Reject wysyła reset. To świadoma decyzja między dostępnością a ochroną pilotażu, nie tylko parametr wydajności. Reject and notify próbuje wyświetlić stronę blokady HTTPS z przyczyną błędu, lecz jej nie gwarantuje; zapobiega przesyłaniu danych do serwera.

W przypadku TLS 1.3 błędy certyfikatów, minimalny rozmiar RSA, globalne obniżenie wersji i Reject and notify zachowują się zgodnie z dokumentacją tylko w przypadku Action: Decrypt. W przypadku Don’t decrypt lub Deny do obsługi tego profilu używany jest Reject. Globalne przejście na wersję TLS 1.2 stwarza zagrożenie bezpieczeństwa i nie stanowi ogólnej poprawki dotyczącej zgodności.

Utwórz regułę i sprawdź jej kolejność

W Rules and policies > SSL/TLS inspection rules > Add ustaw pola w następujący sposób:

1. Rule name: TLS decrypt pilot client
2. Rule position: Top, więc reguła pilotażowa poprzedza ogólne niestandardowe reguły deszyfrowania
3. Action: Decrypt
4. Log connections: włączone do monitorowania pilota
5. Decryption profile: wybrany profil pilota
6. Source zones: LAN
7. Source networks and devices: obiekt hosta dla 10.20.30.50
8. Destination zones: WAN
9. Destination networks: Any
10. Services: Any
11. Categories and websites: puste lub ograniczone do zatwierdzonego zakresu docelowego

Log connections jest opcjonalny i nie jest wymagany do działania reguły. Niemniej jednak jest to przydatne w przypadku pilota ograniczonego czasowo, ponieważ można prześledzić uzgadnianie TLS i zamknięcie połączenia. Przechowywanie musi być zgodne z uzgodnioną polityką prywatności i operacji.

Tabela jest oceniana od góry do dołu, a przetwarzanie zatrzymuje się przy pierwszym dopasowaniu. Wszystkie skonfigurowane kryteria muszą być zgodne jednocześnie. Stała reguła domyślna Exclusions by website or category pozostaje na górze i nie można jej poprzedzić poprzez wybranie Rule position: Top. Umieść niestandardowe wyjątki Don't decrypt bezpośrednio pod nim, po nich określone reguły pilotażowe i na koniec szersze reguły deszyfrowania.

Kryteria użytkowników i grup są wiarygodne tylko wtedy, gdy SFOS zna kontekst użytkownika dla połączenia. Jeśli nie jest to gwarantowane, zacznij od jednoznacznego hosta lub obiektu sieciowego i dodaj kryteria tożsamości dopiero po oddzielnym teście dopasowania.

Po Save ponownie sprawdź stan i pozycję reguły w tabeli. More options umożliwia edycję, klonowanie, wstawianie obok reguły i usuwanie; Rule handle zmienia kolejność. Filtry Source, Destination i Rule ID pomagają w porównaniu; Reset filter przywraca pełną tabelę. Action: Deny uniemożliwia nawiązanie połączenia i nie jest tym samym co Don’t decrypt. Categories and websites jest identyfikowane przez SNI w uzgadnianiu TLS. Nowe instalacje domyślnie włączają reguły inspekcji SSL/TLS, ale ich rzeczywisty stan nadal trzeba sprawdzić przed pilotażem.

Rozróżnianie konfiguracji TLS w XML API

W zautomatyzowanych wdrożeniach Inspection Rule, globalne ustawienia DPI i konfiguracja skanowania HTTP/HTTPS to trzy odrębne obiekty. Wybór CA nie aktywuje ani reguły pilotażowej, ani skanowania w Firewall Rule. Poniższe przyporządkowania opisują strukturę referencyjną SFOS 22/23; pełne żądanie musi odpowiadać zainstalowanej wersji. Przed wykonaniem operacji zapisu należy potwierdzić konkretną operację i pełną treść żądania w API help zainstalowanego buildu. Dopuszczenie źródła, konto, weryfikację TLS, sekrety oraz rozróżnienie między powodzeniem HTTP a statusem XML wyjaśnia artykuł Bezpieczne ograniczanie dostępu do XML API i sprawdzanie odpowiedzi.

Inspection Rule: tożsamość, hierarchia i kolejność

Obiekt nazywa się SSLTLSInspectionRule. Jego bezpośrednie pole Name określa regułę; NewName jest w przykładzie zmienioną nazwą przy zmianie nazwy reguły, a nie nazwą reguły odniesienia przy przenoszeniu. Dla nazwy reguły udokumentowano maksymalnie 60 znaków, UTF-8 i brak przecinka; Description jest ograniczone do 255 znaków. IsDefault jest polem tylko do odczytu i nie służy do ustawiania własnej reguły pilotażowej jako reguły domyślnej.

Pola dopasowania pozostają pod swoimi odpowiednimi węzłami nadrzędnymi, nawet jeśli tabela parametrów wielokrotnie wymienia tę samą nazwę węzła podrzędnego:

• SourceZones > Zone i SourceNetworks > Network: wewnętrzna strefa źródłowa i zatwierdzony obiekt hosta pilotażowego.
• DestinationZones > Zone i DestinationNetworks > Network: strefa docelowa i zatwierdzone obiekty docelowe.
• Identity > Members: użytkownicy lub grupy źródłowe, wyłącznie ze zweryfikowanym dopasowaniem tożsamości.
• Services > Service: obiekty usług dla zatwierdzonego zakresu.
• Websites > Activity > Name i Websites > Activity > Type: nazwa i typ kryterium witryny; przykład podaje Web Category i URL Group.
• MoveTo > Name i MoveTo > OrderBy: reguła odniesienia i pozycja względna; OrderBy używa Before lub After.

Zone, Network, Service i aktywności witryn mogą występować wielokrotnie. Płaskie pole Name lub Network bez właściwego węzła nadrzędnego nie opisuje tego samego przeznaczenia. Nazwy obiektów są przejmowane z istniejącej konfiguracji; zakresu i profilu nie zastępuje się brakującymi polami ani niezweryfikowanymi wartościami domyślnymi.

Position używa Top lub Bottom i służy wyłącznie do początkowego umieszczenia przy ADD. Jeśli nie podano wartości, przykład wskazuje Bottom; dla UPDATE lub APIImport Position nie jest wymagane i nie jest tutaj przyjmowane jako mechanizm przenoszenia. Opcjonalne MoveTo jest stosowane przy ADD po Position. Dlatego w przypadku ustawienia obu pól należy sprawdzić wynikową pozycję względną, a nie tylko początkową wartość Top. Stałe domyślne wykluczenie pozostaje na samej górze; opisana powyżej kolejność zatwierdzonych wyjątków, reguł pilotażowych i szerszych reguł Decrypt nadal obowiązuje.

Bezpośrednie pola Enable, LogConnections, DecryptAction i DecryptionProfile mają odrębne zadania: status reguły, rejestrowanie, decyzję o odszyfrowywaniu i przypisanie profilu. Dla Enable tabela podaje Yes, No, t, f; dla LogConnections — Enable, Disable, t, f. DecryptAction używa dokładnie Decrypt, Do not decrypt lub Deny. Etykieta interfejsu Don’t decrypt nie jest zatem wartością XML, którą można przyjąć bez weryfikacji. Wybrany profil przypisuje się w DecryptionProfile, używając jego rzeczywistej nazwy; wąsko zdefiniowane Source i pełny zatwierdzony zakres celów/usług pozostają obowiązkowe także przy automatyzacji.

Wiersze statusu XML specyficzne dla tego obiektu rozróżniają operację i symbol:

Message.* pozostaje tutaj nierozwiniętym identyfikatorem z dokumentacji, a nie gwarantowanym tekstem zwracanym w czasie działania ani ostateczną przyczyną błędu. Przed każdą ponowną próbą należy porównać oczyszczoną odpowiedź z faktycznie zapisanym stanem: pierwotną lub nową nazwą reguły, statusem, pełnymi kryteriami, DecryptionProfile i pozycją względem innych reguł. Nawet wiersz 200 nie zastępuje ani tego porównania, ani testu z nowymi połączeniami. Jeśli stan jest niejasny, należy zatrzymać działania i wyjaśnić sytuację, zamiast tworzyć drugą lub szerszą regułę przez ponowne ADD albo inną pozycję.

Globalne ustawienia DPI: CA nie jest przełącznikiem włączania/wyłączania

W SSLTLSInspectionSettings pola RSACA i ECCA służą bezpośrednio do wyboru CA ponownie podpisującego odpowiednio certyfikaty serwerów RSA lub EC. Odwołują się do obiektów CA, a nie do ścieżek plików czy wartości aktywujących. Profil może nadpisać wybór CA dla swojej reguły. Dlatego przed zmianą należy łącznie sprawdzić profil, faktycznie prezentowane CA, zaufanie klientów i łańcuch Root/Subordinate; jeśli używane są różne CA, klienci muszą ufać obu.

Odrębne od nich są bezpośrednie pola globalne SSLTLSEngine i SSLTLSInspection, każde z wartościami Enabled lub Disabled. Pierwsze steruje TLS engine, drugie globalną SSL/TLS Inspection, a nie statusem pojedynczej reguły pilotażowej. Wyłączenie Inspection uniemożliwia stosowanie reguł oraz wyświetlanie szczegółów połączeń/odszyfrowywania w Control Center i Log viewer. Wyłączenie Engine dodatkowo usuwa ze ścieżki stosowanie polityki WWW DPI do HTTPS; nie wpływa to na odszyfrowywanie HTTPS przez proxy. Żadne z tych działań nie jest standardowym sposobem wycofania pilotażu.

TLS13Decryption również znajduje się bezpośrednio pod SSLTLSInspectionSettings i używa Decrypt as 1.3 lub Downgrade to TLS 1.2 and decrypt. Określa globalny sposób obsługi TLS 1.3, a nie CA podpisujące ani akcję pojedynczej reguły. Obniżenie wersji dotyczy wszystkich Inspection Rules i nie jest wprowadzane jako poprawka zgodności dla pojedynczego klienta. Objaśnione wcześniej ograniczenia dotyczące TLS 1.3 i Action: Decrypt pozostają wiążące.

Pozostałe bezpośrednie pola SSLv2SSLv3, SSLCompression i SSLConnectionsExceeded używają każdorazowo Allow without decryption, Drop lub Reject. Dotyczą różnych przypadków i nie są utożsamiane z DecryptAction. Po autoryzowanej zmianie należy sprawdzić zapisane wartości globalne, nadpisania w profilach i rzeczywistą ścieżkę ruchu pilotażowego. Przywraca się wyłącznie udokumentowane zmiany wynikające z pilotażu do ich dokładnego poprzedniego stanu, bez zbiorczego wyłączania mechanizmów kontroli.

Skanowanie HTTP/HTTPS: uwzględnienie właściwego węzła nadrzędnego

Odrębny obiekt AntiVirusHTTPsConfiguration zawiera bezpośrednio ScanMode, FileSizeThreshold, AudioVideoFileScanning i PUADetection. Natomiast w węźle podrzędnym HTTPSConfigurations znajdują się HTTPSScanningCA, DenyUnknownProtocol, AllowInvalidCertificate i NoHttpsNotification. HTTPSScanningCA należy zatem do konfiguracji HTTP/HTTPS ścieżki proxy, a nie do RSACA lub ECCA w ustawieniach DPI. Pola te nie zastępują ani dopasowania reguły DPI, ani Decrypt HTTPS during web proxy filtering w odpowiedniej Firewall Rule. Kontekst skanowania wyjaśnia artykuł Skanowanie pod kątem złośliwego oprogramowania na Sophos Firewall — kontekst i zastosowanie.

ScanMode wskazuje RealTime i BatchMode. FileSizeThreshold jest podawane w KB; tabela podaje zakres od 1 do 1572864, maksymalnie 7 cyfr i wartość domyślną 1024. Pliki przekraczające próg nie są skanowane; udokumentowana wartość domyślna nie stanowi zalecenia dla każdego środowiska.

Nierozstrzygnięta sprzeczność wartości: Przykład XML pokazuje dla AudioVideoFileScanning wartość Enable/Disable, natomiast tabela parametrów — on/off i wartość domyślną Disable. Nie wyprowadza się z tego zamiennych aliasów. Również DenyUnknownProtocol i AllowInvalidCertificate pokazują w przykładzie Enable/Disable, podczas gdy tabela podaje tylko odpowiednio on lub on/off; przy PUADetection znajdują się tam wartości symboliczne. Przed zautomatyzowaną zmianą API help lub Support musi potwierdzić wartości obowiązujące dla danego obiektu i buildu. Bez wyjaśnienia nie należy wykonywać żądania zapisu, którego dotyczy ta niejasność; nie należy osłabiać kontroli certyfikatów, aby dopasować import.

Po zatwierdzonej zmianie należy porównać z poprzednim stanem zapisany wybór CA i mechanizmy kontroli w Web > General settings, faktycznie dopasowaną ścieżkę proxy/DPI oraz widocznego wystawcę certyfikatu. Dopiero potem przeprowadza się test funkcjonalny, test pozytywny i test negatywny dla wyjątków. Formalnie zaakceptowana konfiguracja skanowania nie jest dowodem odszyfrowywania ani skutecznego skanowania pod kątem złośliwego oprogramowania.

Staraj się, aby wyjątki były wąskie

Domyślna reguła Exclusions by website or category wykorzystuje Don’t decrypt z Maximum compatibility i pozostaje na pierwszej pozycji. Domyślnie Local TLS exclusion list jest pusta; Managed TLS exclusion list zawiera znane niezgodne witryny i jest aktualizowany poprzez aktualizacje oprogramowania sprzętowego.

Edytuj listę lokalną pod adresem:

Web > URL groups > Local TLS exclusion list

Grupy adresów URL lub dopasowania SNI są bardziej wydajne w przypadku wyjątków domen niż wiele hostów FQDN. Na przykład według Sophos hosty 200 FQDN powodują wyszukiwania 200 dla każdego nowego połączenia SSL/TLS. Ograniczenie łączenia wyjątków źródła i celu trzeba odróżnić od zwykłego dopasowania reguł. Twórz i bezpiecznie używaj grup adresów URL wyjaśnia zakres domeny, symbole wieloznaczne i testy negatywne.

Niestandardowa reguła inspekcji SSL/TLS z Action: Don’t decrypt powinna rejestrować domenę, źródło, którego dotyczy problem, przyczynę, zgłoszenie, właściciela i datę przeglądu. Don’t decrypt nie jest bezwarunkowym obejściem: nadal obowiązują ograniczenia wybranego profilu deszyfrowania. Aby zezwolić na stosowanie SSL 2/3, kompresji lub nieznanych szyfrów w wyraźnie zatwierdzonym starszym przypadku, użyj profilu z Allow without decryption razem z Action: Don’t decrypt. Nie należy stosować tej kombinacji w szerokiej regule ruchu internetowego.

Wyłączenia SSL/TLS i wyjątki internetowe rozwiązują różne problemy. Wyjątek TLS kontroluje deszyfrowanie na dowolnym porcie TCP w trybie DPI. Wyjątek sieciowy zmienia wybrane kontrole zasad sieciowych; w trybie proxy wpływa na odpowiednią ścieżkę proxy. Przed dokonaniem zmiany ustal, czy należy wykluczyć odszyfrowanie, czy tylko sprawdzenie sieci. Bezpiecznie twórz i testuj wyjątki internetowe przedstawia przepływ pracy związany z zaznaczaniem i wyrażeniem regularnym.

Niejasny zakres wyjątku: Instrukcja wykluczania witryn mówi, że nie można łączyć wyjątków źródła i celu; instrukcja reguł udostępnia oba pola dopasowania. Nie potwierdza to dopuszczalności Web Exception łączącego IP źródła i celu. Zachowaj ograniczenie źródła pilotażu z potwierdzoną nazwą hosta lub URL Group. Jeśli oba kryteria wyjątku IP są również obowiązkowe, nie aktywuj ani nie rozszerzaj wykluczenia przed uzyskaniem wyjaśnienia Support dla danej kompilacji. Nie usuwaj kryterium tylko po to, aby uzyskać dopasowanie.

Dla wyraźnie zatwierdzonego starszego przypadku utwórz profil, np. Allow_non-decryptable_profile, w Profiles > Decryption profiles > Add. Ustaw Allow without decryption tylko dla faktycznie potrzebnych pól: SSL 2.0 and SSL 3.0, SSL compression lub Unrecognized cipher suites. W Rules and policies > SSL/TLS inspection rules > Add przypisz profil do wąskiej reguły Don’t decrypt ze źródłem pilotażu, wewnętrznym zakresem źródła, odpowiednim miejscem docelowym i znanym celem. To obniżenie ochrony dla uzasadnionego starszego przypadku, nie ogólna zgoda na te protokoły.

Bez użytecznego SNI grupa URL Group ani regex domeny nie rozpozna celu. Po sprawdzeniu rzeczywistego przepływu odpowiedni może być wąski IP Host w Destination networks; FQDN Host pozostaje alternatywą opartą na DNS z opisanymi kosztami. W regex ważny jest zakotwiczony początek ^ i test negatywny; szerokie symbole wieloznaczne mogą również spowalniać przetwarzanie. Powyższy link Web Exceptions wyjaśnia pełną bezpieczną składnię i różnicę względem list domen.

Obsługa Androida w wąskim zakresie

Niektóre połączenia Androida korzystają z przypinania certyfikatów. Sprawdzanie łączności, Sklep Play lub aktualizacje mogą wówczas zakończyć się niepowodzeniem podczas deszyfrowania. Przepływ pracy udokumentowany przez Sophos wykorzystuje izolowaną sieć VLAN lub sieć bezprzewodową oraz grupę hostów FQDN zawierającą:

• *.play.googlezip.net
• *.gvt1.com
• *.app-measurement.com
• lokalna domena Google, na przykład *.google.ch w Szwajcarii

Utwórz grupę w Hosts and services > FQDN host group > Add. W Hosts and services > FQDN host > Add utwórz po jednym hoście dla każdej domeny i przypisz go bezpośrednio do grupy. Utwórz nową sieć bezprzewodową Sophos w Wireless > Wireless networks > Add, a jej obiekt sieci w Hosts and services > IP host > Add, z IP version: IPv4, Type: Network, własnym adresem sieci i maską. Dla istniejącej izolowanej sieci VLAN lub bezprzewodowej użyj odpowiedniego obiektu, zamiast tworzyć sieć bez potwierdzonej potrzeby. Potwierdź rzeczywistą strefę wejściową przypisaną do tego interfejsu lub sieci VLAN; Wi-Fi jest przykładem sieci bezprzewodowej Sophos, a nie wymogiem dla każdej sieci urządzeń mobilnych.

Ogólna dokumentacja zaleca wyjątek dla wszystkich urządzeń Android; konkretny proces ogranicza go do celów Google w izolowanej sieci mobilnej. To wdrożenie stosuje węższy proces z testami pozytywnymi i negatywnymi, nie ogólne obejście dla wszystkich połączeń Androida. Przejście na Web Proxy to osobna decyzja architektoniczna, nie automatycznie równoważna naprawa pinningu.

Nad ogólną regułą odszyfrowywania dodaj regułę inspekcji SSL/TLS z Action: Don’t decrypt, Decryption profile: Maximum compatibility, Source zone ustawioną na rzeczywistą strefę wejściową sieci urządzeń mobilnych (na przykład Wi-Fi, LAN lub skonfigurowaną strefę niestandardową), sieć urządzeń mobilnych jako Source networks and devices, WAN jako Destination zone i grupę Google jako Destination networks. Znajduje się poniżej stałego domyślnego wykluczenia, ale powyżej ogólnej reguły odszyfrowywania. Trzymaj sieć urządzeń mobilnych odizolowaną od wrażliwych zasobów wewnętrznych.

Zaakceptuj zmianę za pomocą jednego urządzenia pilotażowego z Androidem: sprawdź Connectivity Check i dostęp przez przeglądarkę, pobierz zatwierdzoną aplikację testową z Google Play i zaktualizuj zainstalowaną aplikację przez Google Play. Każda operacja musi zakończyć się powodzeniem. W Log viewer tylko oczekiwane miejsca docelowe Google mogą pasować do wyjątku; inne miejsce docelowe HTTPS z tej samej sieci VLAN musi nadal używać zamierzonej reguły deszyfrowania. Potwierdź rzeczywistą strefę źródłową i obiekt źródłowy, dopasowanie do wyjątku Google oraz dopasowanie do zamierzonej reguły Decrypt dla tych rzeczywistych przepływów. Użyj zarządzanego urządzenia pilotażowego, którego konkretna przeglądarka lub aplikacja testowa ufa urzędowi certyfikacji używanemu do inspekcji; zweryfikuj poprawne działanie oraz potwierdzenie w certyfikacie i dziennikach dla odszyfrowywanego miejsca docelowego. Klientów lub aplikacje, w których nie można zarządzać zaufaniem do inspekcji, pozostaw poza zakresem Decrypt. Ten negatywny test uniemożliwia akceptację wyjątku, który działa, ale jest zbyt szeroki. Bezpiecznie twórz wyjątki internetowe i wykluczenia TLS omawia dalsze metody i ograniczenia SNI.

Weryfikacja działania

Symulacja polityki, prawdziwy klient i logi odpowiadają na różne pytania. Połącz je, aby uzyskać wiarygodny test akceptacyjny.

W Diagnostics > Tools > Pop-out tools > Policy tester wybierz Firewall, SSL/TLS, and web i ustaw źródłowy adres IP, docelowy lub adres URL, protokół i, jeśli to konieczne, port. Bez protokołu narzędzie testuje protokół HTTP przy użyciu domyślnego portu specyficznego dla protokołu. Tester zasad symuluje przejrzysty ruch sieciowy; nie modeluje tras SD-WAN, a reguły z adresami MAC w Source networks and devices tam nie pasują. Web policy only testuje tylko politykę sieciową. Wynik jest zatem przewidywaniem, a nie dowodem rzeczywistej ścieżki danych.

Przeprowadź cztery ukierunkowane testy na kliencie:

1. Przed zmianą zanotuj domenę docelową, wystawcę certyfikatu, czas odpowiedzi oraz to, czy aplikacja biznesowa działa.
2. Otwórz zatwierdzone pozytywne miejsce docelowe i zweryfikuj wybraną ścieżkę inspekcji. W przypadku DPI przeglądarka musi pokazywać ponownie podpisujący urząd certyfikacji wybrany dla DPI jako wystawcę, a Log viewer musi wskazywać oczekiwaną regułę deszyfrowania i profil deszyfrowania. W przypadku Web Proxy zweryfikuj urząd certyfikacji wybrany w Web > General settings > HTTPS scanning certificate authority (CA), faktycznie dopasowaną regułę zapory sieciowej z Use web proxy instead of DPI engine i Decrypt HTTPS during web proxy filtering oraz odpowiadające im wpisy w dziennikach proxy/web potwierdzające pomyślne żądanie. Dla połączenia odszyfrowanego przez proxy nie wymagaj dopasowania do reguły/profilu DPI ani wpisu w widżecie DPI.
3. Otwórz celowo wykluczone miejsce docelowe. Musi pasować do oczekiwanej reguły Don't decrypt; przeglądarka nie może pokazywać tam certyfikatu ponownie podpisanego przez zaporę sieciową.
4. Nadal należy odszyfrować drugie, niewykluczone miejsce docelowe z tego samego zakresu klienta. To jest negatywny test wyjątku.

Jeśli częścią projektu jest polityka sieciowa, zablokuj także kategorię testową lub testowy adres URL specjalnie zatwierdzony do tego celu. Przeprowadź test złośliwego oprogramowania tylko z nieszkodliwym obiektem testowym dostawcy i wstępnie zdefiniowanym oczekiwanym wynikiem. Przed i po pilotażu porównaj obciążenie procesora i pamięci, czas odpowiedzi i błędy użytkownika w tym samym oknie czasowym.

Prawidłowa interpretacja Control Center i Log viewer

Widżet Centrum sterowania nosi nazwę SSL/TLS connections. Jego szczegóły są aktualizowane co pięć minut. Sesje obejmują ostatnie 24 godziny, a błędy ostatnie 7 dni; Failed resetuje się o północy. Dane szczegółowe nie uwzględniają połączeń poprzez serwer proxy WWW. Decryption peak pojawia się tylko w pobliżu szczytu lub powyżej, a Decryption limit tylko w pobliżu limitu specyficznego dla urządzenia. Dlatego nie ma uniwersalnego progu dla wszystkich urządzeń.

Otwórz Log viewer w prawym górnym rogu i wybierz moduł SSL/TLS inspection. Połączenie TLS jest rejestrowane po zakończeniu uzgadniania oraz przy zamykaniu połączenia. Akcja, reguła, profil deszyfrowania, źródło, miejsce docelowe, domena i przyczyna błędu mają znaczenie; same kolory nie są wiarygodnym kryterium akceptacji. W obszarze Manage > Exclude możesz dodać domeny lub subdomeny do listy wykluczeń lokalnych TLS i kategorii do wykluczeń domyślnych. Exclude nie jest dostępny dla błędów o identyfikatorach 19004 i 19005.

Zdarzenie Don't decrypt dowodzi jedynie, że połączenie nie zostało odszyfrowane. Dopiero Reguła, dopasowanie listy i test negatywny pokazują, czy wyjątek jest uzasadniony i wystarczająco wąski.

Rozwiązywanie problemów i bezpieczne przywracanie ustawień

Gdy wystąpi incydent, początkowo ogranicz sprawę do jednego klienta, jednej domeny, jednego punktu w czasie, jednej reguły zapory sieciowej i jednej reguły inspekcji SSL/TLS.

• Jeśli przeglądarka wyświetli ostrzeżenie o certyfikacie, porównaj widocznego wystawcę z urzędem certyfikacji używanym przez rzeczywistą ścieżkę DPI lub proxy. Następnie sprawdź magazyn zaufania klienta, łańcuch główny/podrzędny i nazwę hosta.
• Jeśli brakuje zdarzeń SSL/TLS, najpierw sprawdź zgodność reguły zapory sieciowej i tryb. Następnie potwierdź, że Rules and policies > SSL/TLS inspection rules i Advanced settings > SSL/TLS engine > Enabled są aktywne.
• Jeśli ruch jest dozwolony, ale nie jest odszyfrowany, przeszukaj od góry do dołu stałe domyślne wykluczenia, listę zarządzaną/lokalną lub niestandardową regułę Don't decrypt. Następnie powtórz test negatywny.
• Jeśli filtr sieciowy nie ma zastosowania, sprawdź aktualną regułę zapory sieciowej pod kątem jej zasad sieciowych, Scan HTTP and decrypted HTTPS, Block QUIC protocol i trybu DPI/proxy. Obecność zasad sieciowych nie dowodzi odszyfrowania.
• Jeśli tylko jedna aplikacja zawiedzie, użyj przyczyny błędu, wersji TLS, szyfru, łańcucha certyfikatów i przypinania, aby podjąć kolejną decyzję. Zachowaj wąski zakres tymczasowych wyjątków i podaj datę przeglądu.
• Jeśli obciążenie wzrasta, zmniejsz zakres pilotażu i porównaj to samo okno czasowe przed i po zmianie. Oceń powiadomienia o szczytach lub limitach dla konkretnego urządzenia.

Wyłącz SSL/TLS engine tylko na krótko w celu rozwiązania problemu. Po wyłączeniu nie obowiązują żadne reguły inspekcji SSL/TLS, a silnik DPI nie stosuje zasad sieciowych zapory sieciowej do protokołu HTTPS; Odszyfrowanie HTTPS serwera proxy sieci Web pozostaje niezmienione. Wyłączenie tej funkcji nie jest zatem równoważnym substytutem niskiego ryzyka dla wyłączenia reguły pilotażowej.

Testuj IPS niezależny od portu tylko ze znanym stanem początkowym

Domyślnie SFOS sprawdza odszyfrowany ruch pod kątem sygnatur IPS na każdym porcie TCP. W przypadku powtarzalnego fałszywego alarmu udokumentuj identyfikator sygnatury, źródło, miejsce docelowe, port TCP, regułę zapory sieciowej, regułę inspekcji i kompilację SFOS. Preferuj wąski wyjątek dla sygnatury z Action: Allow packet w aktualnie używanej polityce IPS; Skonfiguruj i przetestuj Sophos Firewall IPS opisuje tę metodę.

Możliwym objawem problemu z inspekcją niezależną od portu są powtarzające się trafienia tej samej sygnatury IPS na tej samej witrynie internetowej. Samo powtarzanie się trafień nie dowodzi fałszywego alarmu. Przed zatwierdzeniem wąsko zakrojonego, odwracalnego wyjątku dla sygnatury sprawdza się dokładną zgodność Signature ID i miejsca docelowego w logach, weryfikuje objęty problemem prawidłowy przepływ pracy i ocenia ryzyko.

Bardziej rozbudowana inspekcja pod kątem potencjalnych zagrożeń może zwiększyć obciążenie i nieznacznie zmniejszyć przepustowość odszyfrowanego ruchu HTTPS w porównaniu ze starszymi wersjami Sophos Firewall. Jest to możliwy efekt związany z wersją, a nie gwarantowany spadek ani dowód regresji aktualnie używanej kompilacji. Aby ocenić wyniki w odpowiednim kontekście, porównuje się przepustowość, obciążenie CPU i pamięci oraz czas odpowiedzi przy porównywalnym obciążeniu ruchem w tym samym oknie czasowym; pojedyncze porównanie nie zastępuje analizy przyczyn.

Globalne porównanie w konsoli urządzeń jest dopuszczalne tylko wtedy, gdy dokładna bieżąca wartość, on lub off, jest już znana z zapisu zmian lub z niezawodnej kopii zapasowej konfiguracji. Oficjalna dokumentacja SFOS 22 nie zawiera wstępnej kontroli tego przełącznika w trybie tylko do odczytu. Jeżeli stan początkowy nie jest znany, nie należy wykonywać badania.

Tylko przy udokumentowanym stanie początkowym on można ustawić następujące ustawienia dla jednego przygotowanego porównania:

set ips scan_decrypted_port_agnostic off
set ips scan_decrypted_port_agnostic on

Druga komenda przywraca jedynie znany stan początkowy on. Jeśli stan początkowy to off, nie włączaj go na ślepo; zachowaj off lub przywróć go dokładnie po każdej autoryzowanej zmianie. To ustawienie globalne wpływa na całą zaporę sieciową i może nieznacznie zmniejszyć przepustowość lub, w przypadku off, zawęzić zakres inspekcji. Udokumentuj wynik i okno czasowe, nie traktując tego samego jako dowodu ogólnej przyczyny.

Wycofywanie zmian w ustalonej kolejności

Wycofywanie przywraca udokumentowany stan początkowy zamiast wprowadzać nową architekturę:

1. Przed wyłączeniem TLS decrypt pilot client sprawdź zapisaną regułę, która przejmie dopasowanie, oraz zatwierdzony plan przywracania: niższa, szersza reguła Decrypt może przejąć ruch. Wyłącz regułę pilota i w przygotowanej kolejności przywróć udokumentowane zmiany wprowadzone wyłącznie na potrzeby pilota w regułach zapory sieciowej, trybie DPI/proxy, Web Policy i ustawieniach globalnych, bez jednoczesnego wprowadzania niepowiązanych zmian.
2. Nawiąż nowe połączenia z klienta pilotażowego i zweryfikuj zapisaną początkową ścieżkę dopasowania, wystawcę certyfikatu, dzienniki i działanie aplikacji. Nie zakładaj, że istniejące sesje zostaną natychmiast poddane ponownej ocenie. Jeśli niższa reguła Decrypt przejmie ruch lub przywracanie się nie powiedzie, wstrzymaj usuwanie elementów pilota: wycofanie zmian nie jest zakończone. Zidentyfikuj rzeczywiste dopasowanie i przywróć wyłącznie autoryzowaną kolejność reguł, kryteria i ustawienia potrzebne do odtworzenia stanu początkowego, a następnie powtórz te kontrole z użyciem nowych połączeń.
3. Tylko jeśli początkowa ścieżka nie była odszyfrowywana i wymaga tego zatwierdzony plan przywracania, użyj ograniczonej czasowo reguły Don't decrypt o wąskim zakresie dla źródła pilota i wymaganych miejsc docelowych, umieszczonej przed niezamierzonym dopasowaniem do niższej reguły Decrypt, ale poniżej odpowiednich zatwierdzonych wykluczeń. Przeprowadź zarówno jej test pozytywny, jak i negatywny; nie twórz doraźnie szerokiego obejścia ani nie zastępuj wcześniej sprawdzonej ścieżki ścieżką niezweryfikowaną.
4. Usuń tymczasowe wyjątki, obiekty testowe oraz zaufanie do CA i ustawienia CA stosowane wyłącznie na potrzeby pilota dopiero po zweryfikowaniu przywrócenia i zatwierdzeniu usunięcia. Zachowaj zaufanie do CA nadal wymagane przez aktywną ścieżkę do czasu pomyślnego zakończenia tych kontroli; nie usuwaj współdzielonych urzędów certyfikacji bez sprawdzenia zależności.
5. Zapisz identyfikator reguły, klienta, miejsce docelowe, widoczny urząd certyfikacji, zdarzenie w dzienniku, czas i przywrócone ustawienia w rekordzie zmian.

Polityka sieciowa może pozostać skonfigurowana, ale bez odszyfrowania nie może skanować zaszyfrowanego ładunku HTTPS. Przywróć serwer proxy sieci Web tylko wtedy, gdy był to zweryfikowany stan początkowy. Nie wyłączaj całego silnika SSL/TLS w ramach standardowego przywracania, ponieważ powoduje to zatrzymanie wszystkich reguł DPI TLS i stosowania zasad sieciowych DPI do protokołu HTTPS.

Zatrzymaj wdrażanie, gdy tylko ulegnie awarii aplikacja o znaczeniu krytycznym dla firmy, pojawią się ostrzeżenia o certyfikatach poza grupą pilotażową, zakres będzie pasował szerzej niż oczekiwano lub obciążenie i błędy przekroczą wstępnie zdefiniowane limity. Rozbuduj grupę Source stopniowo dopiero wtedy, gdy test pozytywny, test negatywny wyjątku, aplikacje biznesowe, logi, opinie użytkowników i profil obciążenia spełniają uzgodnione kryteria przez uzgodniony okres.

Podczas pracy przeglądaj wykluczenia, błędy TLS, nowe aplikacje, obciążenie i opinie użytkowników według określonego harmonogramu. Zachowaj tymczasowe wyjątki tylko wtedy, gdy właściciel, powód i data przeglądu pozostają ważne; w przeciwnym razie usuń je po świeżym pozytywnym i negatywnym teście.

Często zadawane pytania