Jak prawidłowo interpretować dane wydajnościowe Sophos Firewall

Dane wydajnościowe Sophos Firewall są ważne dla określenia rozmiaru, ale często są źle interpretowane. Najwyższa przepustowość zapory w arkuszu danych nie jest automatycznie wydajnością, jaką osiąga lokalizacja z włączonymi funkcjami IPS, Ochroną sieci, Inspekcją TLS, VPN, NAT, raportowaniem i wieloma jednoczesnymi użytkownikami.

Przy wyborze modelu nie należy skupiać się tylko na jednej liczbie Gbit/s. Kluczowe jest, które funkcje ochrony są aktywne, jaki ruch przechodzi przez zaporę i jakie rezerwy są potrzebne w codziennym użytkowaniu. Przewodnik po rozmiarze Sophos Firewall wyjaśnia wybór modelu; ten artykuł wyjaśnia, jak interpretować podstawowe metryki wydajności.

Krótka zasada dotycząca określania rozmiaru

W praktyce czysta przepustowość zapory nie jest zazwyczaj najlepszym punktem wyjścia.

• Tylko routing i proste reguły zapory: Zwróć uwagę na przepustowość zapory i IMIX.
• Typowa sieć firmowa z IPS i Kontrolą aplikacji: Większą wagę przyłóż do wartości NGFW lub Ochrony przed zagrożeniami.
• Wiele połączeń HTTPS z deszyfracją: Zaplanuj wydajność inspekcji TLS i rezerwy CPU.
• Wiele połączeń VPN: Rozważ osobno wymagania dotyczące IPsec lub Zdalnego dostępu.
• Wirtualna zapora: Weź pod uwagę hypervisor, CPU, RAM, pamięć masową i wirtualne karty sieciowe tak samo poważnie jak licencję Sophos.

Jeśli nie jest jasne, czy lepiej pasuje sprzęt czy wirtualna aplikacja, pomocny będzie Sophos Firewall - Sprzęt czy wirtualna aplikacja?.

Dlaczego wartości z arkusza danych nie wystarczą jeden do jednego

Wartości wydajnościowe są określane w zdefiniowanych warunkach laboratoryjnych. Jest to sensowne, ponieważ modele stają się porównywalne. Jednak środowisko produkcyjne zachowuje się inaczej:

• Rozmiary pakietów są mieszane.
• Użytkownicy generują równoległe sesje.
• Profile bezpieczeństwa różnie sprawdzają ruch.
• Ruch HTTPS wymaga znacznie więcej zasobów przy inspekcji TLS.
• VPN, SD-WAN, NAT, logowanie i raportowanie działają równolegle.
• WLAN, przełączniki, klienci, serwery i dostawcy wpływają na odczuwaną wydajność.

Wartość z arkusza danych jest zatem wartością porównawczą, a nie obietnicą dla każdego pojedynczego przepływu. Dla solidnego określenia rozmiaru należy planować z rezerwami i uwzględniać późniejsze funkcje operacyjne przed zakupem.

Przed porównaniem liczb sprawdź warunki testu

Przypisy w kartach katalogowych Sophos są częścią każdej metryki. Sophos mierzy wartości maksymalne w idealnych warunkach przy użyciu Keysight-Ixia BreakingPoint. Firewall Throughput wykorzystuje ruch HTTP z odpowiedziami 512 KB, a Firewall IMIX miesza pakiety UDP o rozmiarach 66, 570 i 1518 bajtów. IPS Throughput bazuje na ruchu HTTP, domyślnym zestawie reguł IPS i obiektach 512 KB. TLS Inspection jest mierzone przy aktywnym IPS, sesjach HTTPS i różnych zestawach szyfrów. Threat Protection łączy firewall, IPS, Application Control i Malware Prevention z Enterprise Traffic Mix. NGFW Throughput jest mierzone przy aktywnych IPS i Application Control, z użyciem ruchu HTTP i obiektów 512 KB. IPsec VPN wykorzystuje ruch HTTP przez wiele tuneli z odpowiedziami 512 KB.

Takie warunki pozwalają porównywać modele na tej samej podstawie. Nie należy jednak sumować wartości ani traktować ich jako gwarancji dla własnego profilu ruchu. Małe pakiety, krótkie sesje, inne zestawy szyfrów i dodatkowe usługi mogą zmienić wynik.

Najważniejsze metryki

• Firewall Throughput: Pomaga porównać proste przetwarzanie warstwy 3/warstwy 4. Typowym błędem jest uznanie tej wartości za rzeczywistą przepustowość internetu ze wszystkimi funkcjami bezpieczeństwa.
• Firewall IMIX: Używa bardziej realistycznej mieszanki rozmiarów pakietów. Często jest pomijany, choć sieci produkcyjne nie przenoszą wyłącznie dużych pakietów.
• IPS Throughput: Opisuje ruch z Intrusion Prevention. Nabiera znaczenia, gdy IPS kontroluje dużą część ruchu.
• NGFW Throughput: Opisuje wydajność z dodatkowymi funkcjami, takimi jak IPS i Application Control. Nie należy mylić jej z czystą przepustowością zapory.
• Threat Protection: Lepiej przybliża środowisko z kilkoma aktywnymi zabezpieczeniami. Nadal jest to metryka porównawcza, a nie gwarantowane minimum.
• TLS Inspection: Dotyczy deszyfrowania i kontroli HTTPS. To potencjalnie duże obciążenie jest często pomijane podczas doboru modelu.
• IPsec VPN: Dotyczy szyfrowanego ruchu między lokalizacjami. Peer, rozmiary pakietów, ustawienia kryptograficzne i CPU są równie ważne jak łącze internetowe.
• Concurrent Connections: Określa liczbę połączeń, które firewall może śledzić jednocześnie. Jest to limit pojemności, a nie wartość przepustowości.
• New Connections per second: Określa liczbę nowych połączeń, które zapora może przetworzyć w ciągu sekundy. Duża liczba krótkich połączeń webowych, API lub DNS może obciążyć ten limit mimo niskiego użycia pasma.

Przepustowość zapory i IMIX

Czysta przepustowość zapory opisuje stosunkowo prostą obróbkę ruchu. Ta wartość jest przydatna, gdy zapora głównie routuje, wykonuje NAT i przetwarza klasyczne reguły zapory.

IMIX jest bliższy rzeczywistemu obciążeniu sieci, ponieważ mieszane są różne rozmiary pakietów. Jest to ważne, ponieważ małe pakiety obciążają zaporę inaczej niż duże pobrania. W sieciach firmowych rzadko występuje tylko jeden czysty duży strumień danych. Dostępy do sieci, DNS, VoIP, aplikacje chmurowe, aktualizacje i transfery plików generują różne wzorce.

Dla lokalizacji z normalnym ruchem użytkowników IMIX jest często bardziej wymowny niż najpiękniejsza wartość maksymalna.

IPS, NGFW i Ochrona przed zagrożeniami

Gdy IPS, Kontrola aplikacji, Ochrona sieci lub sprawdzanie złośliwego oprogramowania są aktywne, zapora musi robić więcej niż tylko przekazywać pakiety. Zapora musi klasyfikować ruch, rozpoznawać wzorce, stosować reguły i w zależności od polityki sprawdzać treści.

Terminy te są często mylone:

• IPS ocenia ruch na podstawie sygnatur i reguł dla znanych wzorców ataków.
• NGFW opisuje wydajność zapory z dodatkowymi funkcjami, takimi jak IPS i Kontrola aplikacji.
• Ochrona przed zagrożeniami to silniejsza wartość przybliżona dla środowisk, w których jednocześnie aktywne są różne funkcje ochrony.

Dla firmy, która rzeczywiście używa Sophos Firewall jako bramy bezpieczeństwa, wartości NGFW i Ochrony przed zagrożeniami są zazwyczaj bardziej istotne niż czysta przepustowość zapory.

Realistyczne planowanie inspekcji TLS

Inspekcja TLS jest jednym z największych czynników wpływających na wydajność. Zapora deszyfruje połączenia HTTPS, sprawdza zawartość i ponownie szyfruje połączenie. To generuje obciążenie CPU i może być zauważalne w zależności od zestawu szyfrów, serwera docelowego, klienta, wyjątków i polityki.

Inspekcja TLS nie powinna być aktywowana mimochodem. Sensowne jest stopniowe wdrażanie z grupą pilotażową, wyjątkami, monitorowaniem i jasnym rozwiązywaniem problemów. Artykuł Jak prawidłowo wprowadzić inspekcję TLS w Sophos Firewall opisuje operacyjny przebieg.

Również certyfikat CA musi być poprawnie rozprowadzony. Dla klientów odpowiednim wprowadzeniem jest Instalacja certyfikatu CA Sophos Firewall dla skanowania HTTPS.

Oddzielne rozważanie wydajności VPN

Wydajność VPN nie zależy tylko od modelu zapory. Istotne są również punkt końcowy, łącze internetowe, opóźnienia, rozmiary pakietów, MTU/MSS, parametry szyfrowania, routing i równoległe tunele.

Dla połączeń Site-to-Site należy realistycznie oszacować planowane strumienie danych: transfery plików, kopie zapasowe, ERP, VoIP, RDP, monitorowanie i replikacja zachowują się różnie. Dla Zdalnego dostępu dochodzą dodatkowo urządzenie klienckie, WLAN, dostawca i klient VPN.

Jeśli połączenie VPN wydaje się wolne, nie należy sprawdzać tylko wartości z arkusza danych. Zdefiniowany test połączenia z iPerf jest zazwyczaj bardziej wymowny niż test prędkości przeglądarki.

Co wpływa na rzeczywistą wydajność

W praktyce działa jednocześnie wiele czynników:

• aktywne profile bezpieczeństwa dla każdej reguły zapory
• Inspekcja TLS i wyjątki
• Polityka IPS i zakres sygnatur
• Ochrona sieci, Kontrola aplikacji i sprawdzanie złośliwego oprogramowania
• NAT, DNAT, publikowanie serwerów i WAF
• IPsec, SSL VPN, Sophos Connect i tunele Site-to-Site
• Logowanie, raportowanie, Central Reporting i Syslog
• wiele małych sesji zamiast kilku dużych pobrań
• Przyspieszenie zapory, FastPath, Przyspieszenie IPsec i ruch, który nie może być offloadowany
• Tryb HA, wersja oprogramowania i poprawki
• zasoby wirtualne w przypadku aplikacji programowych lub chmurowych

Dlatego wydajność należy zawsze sprawdzać w kontekście konkretnej polityki. Reguła zapory bez profili bezpieczeństwa zachowuje się inaczej niż reguła z IPS, filtrem sieciowym, Kontrolą aplikacji i Inspekcją TLS.

Prawidłowe zrozumienie FastPath i Offloading

Nowoczesne zapory Sophos nie przetwarzają każdego strumienia danych w ten sam sposób. W zależności od urządzenia, oprogramowania, reguły, profilu bezpieczeństwa i rodzaju ruchu, ruch może być częściowo przyspieszony lub sprawdzany w wolniejszej ścieżce przetwarzania. Ważne pojęcia to FastPath, przyspieszenie zapory, przyspieszenie PKI i przyspieszenie IPsec.

Wstępna klasyfikacja nadal odbywa się w SlowPath: jądro i, w stosownych przypadkach, silnik DPI sprawdzają połączenie. Po zakończeniu uzgadniania TCP lub przesłaniu jednego pakietu w każdym kierunku SFOS może umieścić kwalifikujący się strumień w pamięci podręcznej połączeń FastPath. FastPath nie jest więc niekontrolowanym obejściem; przetwarza tylko stan zaprogramowany przez jądro. Niekwalifikujące się protokoły, takie jak IP-in-IP, pozostają w SlowPath.

Dla doboru wydajności jest to ważne, ponieważ szybki test nie dowodzi, że każdy strumień produkcyjny korzysta z tej samej ścieżki. Sophos wymienia Firewall i IPsec Acceleration dla wszystkich XGS Appliance. Dedykowana PKI Acceleration do przetwarzania certyfikatów inspekcjonowanych strumieni TLS jest udokumentowana tylko dla XGS 4300, 4500, 5500, 6500, 7500 i 8500. Modele desktop Gen. 2 XGS 88/88w, 108/108w, 118/118w i 128/128w używają Virtual FastPath w jądrze x86 zamiast dedykowanego Xstream Flow Processor.

Dla appliance wirtualnych i software obowiązują jeszcze węższe granice. Według pomocy SFOS 22 Virtual FastPath jest obsługiwany tylko z VMware ESXi oraz sterownikami NIC igc, e1000, e1000e i vmxnet3. Na innych hypervisorach, w środowiskach cloud lub z nieobsługiwanymi sterownikami VFP wyłącza się automatycznie. Firewall nadal działa, ale bez tego usprawnienia FastPath. Dla e1000 i e1000e Sophos podaje maksymalną MTU 3500 bajtów, a dla pozostałych obsługiwanych sterowników maksymalnie 9000 bajtów. Są to granice platformy, a nie powód do włączania jumbo frames bez testu end-to-end.

PKI Acceleration nie przyspiesza całego przetwarzania TLS. W przypadku strumieni TLS 1.2 i TLS 1.3 sprawdzanych przez silnik DPI odciąża tylko ponowne podpisywanie certyfikatów serwera X.509 z uwierzytelnianiem RSA do 4096 bitów. Szyfrowanie symetryczne, ruch web proxy i połączenia SSL VPN kończące się na zaporze nie korzystają z tego mechanizmu.

Niektóre funkcje lub rodzaje ruchu mogą ograniczać albo uniemożliwiać offloading, na przykład:

• SSL VPN
• WAF i ruch proxy
• QoS i DoS
• Bezprzewodowe, RED, LAG i PPPoE
• zfragmentowany ruch IP
• niektóre scenariusze mostkowania, HA lub wirtualizacji

W przypadku IPsec stos XFRM odciąża enkapsulację, szyfrowanie, dekapsulację i deszyfrowanie ESP na podstawie SA fazy 2. SA korzystające z 3DES, BlowFish lub MD5, SA na interfejsach wirtualnych, takich jak VLAN, oraz ruch IPsec przez interfejsy VLAN lub bezprzewodowe nie są offloadowane. Tunel może nadal działać, ale zużywa wtedy więcej CPU hosta.

Polityki bezpieczeństwa nie wykluczają offloadingu w sposób bezwzględny. Reguła bez IPS, filtrowania stron, antywirusa lub kontroli aplikacji może przełączyć się po uzgodnieniu albo po pierwszych pakietach; przy kontroli aplikacji Sophos podaje, że decyzja następuje po około ośmiu pakietach. W przypadku STARTTLS z Don’t decrypt następuje to po około 15 pakietach. Pierwsze pakiety mogą więc być jeszcze widoczne w SlowPath, mimo że dalszy strumień jest przyspieszany.

Reguła praktyczna: Offloading nie jest celem bezpieczeństwa. Nie usuwa się profili ochrony ani inspekcji tylko po to, aby osiągnąć FastPath. Liczą się wymagany poziom ochrony oraz powtarzalne pomiary przepustowości, CPU i aplikacji.

Przy HA trzeba zachować szczególną ostrożność. Active-Active HA nie obsługuje Firewall Acceleration. Sophos obsługuje natomiast IPsec Acceleration w HA Active-Active i Active-Passive na węźle podstawowym; w Active-Passive również funkcja Firewall Acceleration jest ograniczona do węzła podstawowego. Dlatego przy doborze rozwiązania HA nie należy zakładać, że laboratoryjne wartości dla pojedynczego urządzenia dotyczą obu węzłów.

Rozwiązywanie problemów również może wpływać na pomiary. Przy Packet Capture lub iftop SFOS domyślnie tymczasowo kieruje ruch przez SlowPath. Jeśli offloading pozostaje aktywny podczas przechwytywania, standardowy Packet Capture nie może zarejestrować ruchu FastPath. Brak pakietu nie dowodzi więc, że firewall nie przetworzył strumienia; przy potrzebie przechwycenia FastPath Sophos odsyła do Support. Pomiary wydajności i wyniki przechwytywania zawsze dokumentuje się wraz z czasem, metodą testu, wersją firmware, typem interfejsu i aktywną polityką.

Przyspieszenia są domyślnie aktywne na obsługiwanych platformach. Włączenie lub wyłączenie Firewall albo PKI Acceleration ponownie uruchamia usługę IPS (silnik DPI), a zmiana IPsec Acceleration restartuje wszystkie tunele IPsec. Takie zmiany należą do okna serwisowego, a nie improwizowanego testu wydajności. Najpierw potwierdza się podejrzenie za pomocą Log Viewer, Packet Capture, Rozwiązywanie problemów z IPsec i jasno zdefiniowanego przypadku testowego.

Prawidłowe odczytywanie i sterowanie PKI Acceleration

Stan skonfigurowany i stan faktycznie aktywny nie są tym samym. Ustawienie odczytuje się poleceniem:

show ips-settings

PKI Acceleration jest domyślnie włączone na obsługiwanych modelach XGS Appliance. Stan enabled jest skuteczny tylko wtedy, gdy działa również Firewall Acceleration. Jeśli PKI Acceleration jest włączone, ale Firewall Acceleration jest wyłączone, SFOS wyświetla enabled (inactive). Na nieobsługiwanych wersjach SFOS lub modelach pojawia się disabled; zmiana ustawienia w CLI nie zastąpi brakującej obsługi sprzętowej lub platformowej.

Ustawienie globalne zmienia się w drzewie poleceń IPS:

set ips pki-acceleration disable
set ips pki-acceleration enable

Przełączenie ponownie uruchamia usługę IPS (silnik DPI), dlatego należy wykonać je w oknie serwisowym. Najpierw trzeba zapisać bieżącą wartość i stan Firewall Acceleration. Następnie ponownie sprawdza się show ips-settings, stan IPS i DPI oraz rzeczywisty przepływ TLS odszyfrowywany przez silnik DPI. Tylko tak można potwierdzić, że ponowne podpisywanie certyfikatów, opóźnienia, CPU i aplikacja nadal działają prawidłowo. Jeśli oczekiwany efekt nie wystąpi, należy przywrócić wcześniej zapisaną wartość.

Kontrolowane sprawdzanie IPsec Acceleration

Najpierw należy odczytać stan globalny:

system ipsec-acceleration show

IPsec Acceleration jest domyślnie enabled i przenosi kwalifikujące się SA fazy 2 poza SlowPath. Aktywny stan globalny nie dowodzi, że konkretna SA jest offloaded. 3DES, BlowFish i MD5 są wykluczone, a opisane wyżej ograniczenia interfejsów i platform nadal obowiązują.

Zmiana dotyczy całej zapory i restartuje wszystkie tunele IPsec. disable nie jest więc testem jednego tunelu. Jeśli wyraźny błąd uzasadnia test A/B, należy najpierw udokumentować stan tuneli, SA, CPU, przepustowość i ruch testowy. W oknie serwisowym dostępne są dwie przeciwne zmiany:

system ipsec-acceleration disable
system ipsec-acceleration enable

Po każdej rzeczywiście wykonanej zmianie ponownie sprawdza się show, zestawienie tuneli, SA fazy 2, routing, reguły i rzeczywisty ruch w obu kierunkach. Bez powtarzalnej poprawy przywraca się wartość pierwotną. Nie należy utrzymywać przestarzałego profilu kryptograficznego tylko po to, aby umożliwić porównanie wydajności.

Przełączanie Firewall Acceleration tylko w oknie konserwacji

Najpierw należy odczytać bieżący stan w Device Console:

system firewall-acceleration show

Na obsługiwanych platformach Firewall Acceleration ma domyślnie wartość enable. Według Sophos każda zmiana powoduje przerwę i ponowne uruchomienie usługi IPS (silnika DPI). disable nie jest więc swobodnym testem A/B podczas pracy produkcyjnej. Zapora nadal w pełni przetwarza ruch, ale bez korzyści wydajnościowych FastPath.

Do zaplanowanej zmiany służą te dwa polecenia. Nie wykonuje się ich bezpośrednio jedno po drugim jako bloku testowego, ponieważ każde przejście może ponownie przerwać ruch:

system firewall-acceleration disable
system firewall-acceleration enable

Po każdej rzeczywiście wymaganej zmianie ponownie sprawdza się show, stan IPS i DPI, nowe sesje, opublikowane usługi, VPN, przepustowość, CPU i Log Viewer. Wyświetlonego disabled nie należy bez zastanowienia zastępować przez enable: DoS, HA active-active, niezaładowany FastPath albo nieobsługiwana kombinacja VM, hypervisora lub sterownika NIC również mogą uniemożliwić akcelerację. enable nie wymusi działającego FastPath na technicznie nieobsługiwanej platformie.

Sprawdzanie wydajności w działaniu

Wartości z arkusza danych pomagają przed zakupem. W działaniu potrzebne są inne narzędzia. Ważne jest rozróżnienie pojęć: Control Center nie pokazuje wydajności z arkusza danych, lecz aktualne wskaźniki operacyjne. Kafelek Performance bazuje na load average liczonym względem rdzeni CPU. Wartości powyżej liczby dostępnych rdzeni oznaczają, że w danym momencie system ma więcej pracy, niż może przetworzyć.

Kolor kafelka jest oparty na stałych progach Sophos: Normal przy load average poniżej 2, Warning od 2 do 5 oraz Alert powyżej 5 rdzeni CPU. Ten wskaźnik daje szybki sygnał, ale nie jest tożsamy z indywidualnym progiem przeciążenia appliance. Dlatego status kafelka należy interpretować razem z rzeczywistą liczbą rdzeni i przebiegiem w czasie.

Istotne są także CPU, memory, bandwidth, sessions, Decryption Capacity i Decrypt Sessions. Szczególnie przy TLS Inspection Decryption Capacity jest przydatne, ponieważ pokazuje, jak mocno bieżące deszyfrowanie SSL/TLS wykorzystuje dostępną wydajność deszyfrowania. Szczegóły decryption nie są aktualizowane jako pomiar live co sekundę, lecz zwykle co pięć minut. Te wartości należy zawsze czytać razem z polityką, regułą, profilem bezpieczeństwa, godziną i typem ruchu.

Używanie System Graphs jako osi czasu

W Diagnostics > System graphs można porównywać CPU Usage, Memory Usage, Load Average, Disk Usage, Live Users, Data Transfer Speed through WAN Zone i poszczególne interfejsy w różnych okresach. Najpierw wybiera się okres zdarzenia, a następnie tylko wykresy pasujące do funkcji, której dotyczy problem.

Szczyt jest korelacją, a nie jeszcze przyczyną. Dlatego CPU, memory lub load average należy porównać z ruchem na interfejsach, liczbą użytkowników, logami, polityką i dokładnym czasem testu. Oś czasu pomaga przede wszystkim odróżnić krótki skok od powtarzającego się albo utrzymującego się wysokiego obciążenia; sama nie dowodzi ani niewystarczającej wydajności urządzenia, ani usterki konkretnej usługi.

Prawidłowe odczytywanie jednostek i agregacji

Wykres CPU rozdziela użycie przez procesy użytkownika, komponenty systemowe i pozostały czas bezczynności. Memory pokazuje Used, Free i Total w MB. Load Average nie jest natomiast wartością procentową: trzy krzywe oznaczają średnie z jednej, pięciu i piętnastu minut. Dlatego należy go interpretować razem z liczbą dostępnych rdzeni CPU.

Disk Usage pokazuje procent miejsca zajętego przez sygnatury, pliki konfiguracyjne, raporty i dane tymczasowe. Jest to funkcjonalny podział na wykresie, a nie ten sam widok co partycje z df -kh lub watermark raportów. Live Users liczy użytkowników połączonych z Internetem w wybranym okresie i pokazuje także minimum, maksimum oraz średnią. Nie jest to liczba skonfigurowanych kont użytkowników.

Dla strefy WAN dostępne są osobne wykresy wysyłania i pobierania, łącznej szybkości oraz szybkości według gateway. Zależnie od widoku pojawiają się wartości bieżąca, minimalna, maksymalna i średnia. Sophos dokumentuje istotny błąd etykiety: WebAdmin pokazuje KBps, ale wartości są w rzeczywistości podane w kbit/s. Odczyt jako kilobajty na sekundę powoduje błąd o współczynnik osiem.

Ważne w przypadku VLAN: Osobne wykresy interfejsów są dostępne dla interfejsów fizycznych, Wireless LAN, interfejsów WAN oraz interfejsów VLAN w strefie WAN. VLAN z innych stref są na wykresie łączone z nadrzędnym interfejsem fizycznym. Bez dodatkowego pomiaru nie można więc przypisać skoku na porcie nadrzędnym do jednego wewnętrznego VLAN.

Wykresy interfejsów pokazują odebrane i wysłane bity, a także dropy, błędy i kolizje. Rozdzielczość jest agregowana dla dłuższych okresów: dziś i wczoraj używają średnich pięciominutowych, tydzień 15-minutowych, miesiąc sześciogodzinnych, a rok jednodniowych. Krótkie skoki mogą więc zniknąć w widoku miesięcznym lub rocznym; dla incydentu należy zacząć od najwęższego odpowiedniego okresu.

Praktyczny przebieg:

1. Sprawdź Centrum Kontroli: Obserwuj CPU, RAM, obciążenie interfejsu i ostrzeżenia.
2. Otwórz Log Viewer: Czy działa oczekiwana reguła zapory i czy logowanie jest aktywne?
3. Kontroluj politykę i profile bezpieczeństwa: Jakie funkcje wpływają na dany ruch?
4. Użyj Packet Capture: Czy widać pakiety, pakiety odpowiedzi, NAT i odrzuty?
5. Przeprowadź test połączenia: Sprawdź z iPerf lub zdefiniowanym pobraniem, która ścieżka jest naprawdę wolna.
6. Zanotuj kontekst offloadingu: Typ interfejsu, tryb HA, rodzaj VPN, PPPoE, WAF, SSL VPN lub Packet Capture mogą wpływać na pomiar.
7. Zanotuj czas: Szczyty obciążenia, kopie zapasowe, aktualizacje lub raporty mogą zniekształcać wyniki.

Dla szybkiego rozgraniczenia łącza WAN pomocny jest Przeprowadzenie testu prędkości internetu Sophos Firewall przez SSH. Dla testów end-to-end między dwoma systemami lepiej nadaje się Testowanie wydajności Sophos Firewall za pomocą iPerf. Jeśli reguła nie działa zgodnie z oczekiwaniami, odpowiedni jest Testowanie reguł Sophos Firewall.

Codzienna lista administratora Sophos Firewall pokazuje, jak połączyć Control Center, System graphs, raporty i zdarzenia administracyjne w krótkiej, cyklicznej procedurze.

Typowe błędy przy określaniu rozmiaru

• Porównywana jest tylko najwyższa przepustowość zapory.
• Planowana jest inspekcja TLS, ale nie jest uwzględniana w rezerwie wydajności.
• VPN i Zdalny dostęp są oceniane na podstawie liczby użytkowników, a nie rzeczywistego użytkowania.
• Uwzględniane jest łącze internetowe, ale nie wewnętrzny ruch wschód-zachód.
• Wirtualne zapory są uruchamiane na przeciążonych hostach.
• Raportowanie, logowanie i połączenie z Central są rozważane dopiero później.
• Wzrost, nowe lokalizacje, dodatkowe VLAN-y lub publikowanie serwerów nie są uwzględniane w planowaniu.
• Nie ma rozróżnienia między wartością laboratoryjną, rzeczywistą a doświadczeniem użytkownika.

Praktyczna lista kontrolna dotycząca określania rozmiaru

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

1. Przepustowość internetu dziś i planowana na najbliższe lata.
2. Liczba użytkowników, urządzeń, serwerów i lokalizacji.
3. Udział ruchu sieciowego, aplikacji chmurowych, VoIP, kopii zapasowych i transferów plików.
4. Planowane funkcje bezpieczeństwa dla każdej grupy ruchu.
5. Zakres inspekcji TLS i konieczne wyjątki.
6. Liczba i wykorzystanie połączeń IPsec, SSL VPN i Sophos Connect.
7. Potrzeba WAF, Ochrony poczty, RED, WLAN lub Central Reporting.
8. Oczekiwane rezerwy na aktualizacje, wzrost i szczyty obciążenia.
9. Model operacyjny: XGS Appliance, wirtualna aplikacja, chmura lub klaster HA.

FAQ