Wdrożenie i obsługa Sophos Firewall w AWS

Sophos Firewall 22 działa w AWS jako wirtualna appliance EC2 inline w VPC. Najpierw trzeba określić ruch podlegający inspekcji. Firewall standalone może kontrolować ruch przychodzący i wychodzący; template Sophos Auto Scaling jest wyspecjalizowanym projektem PAYG dla przychodzącego DNAT lub WAF.

Bezpieczna ścieżka to wybór architektury i licencji, zapisanie planu IP i routingu, uruchomienie właściwego template Marketplace, ograniczenie zarządzania do stałego IP źródłowego, weryfikacja jednego przepływu end-to-end i dopiero potem publikacja kolejnych usług.

⚠️ AWS Security Groups pozostają drugą warstwą firewalla. Reguła SFOS nie pomoże, jeśli Security Group, NACL lub Route Table blokuje ścieżkę. Otwartego portu AWS nie należy też łączyć z szeroką regułą Sophos. Security Groups są stateful, a Network ACL stateless, więc własna NACL musi zezwalać na żądanie i odpowiedź.

Wybór standalone lub Auto Scaling

AWS nie obsługuje natywnego HA Sophos Firewall. Auto Scaling i Network Load Balancing to inny projekt chmurowy, a nie synchronizacja HA SFOS. Standalone wymaga więc procedury odbudowy i akceptowanego okna przerwy.

Wybór instancji podlega trzem warunkom: typ EC2 musi być dostępny w aktualnie otwartym szablonie Marketplace CloudFormation dla wybranego regionu i AMI, wydajność musi odpowiadać oczekiwanemu przepływowi i profilowi połączeń, a w BYOL vCPU i RAM nie mogą przekraczać zakupionej licencji wirtualnej. Wybrać najmniejszy oferowany rozmiar spełniający te wymagania z zapasem, a następnie zapisać w planie typ EC2, AMI lub wersję SFOS i limit licencji. W PAYG opłaty programowe kończą się dopiero po usunięciu wszystkich właściwych instancji firewall z konta AWS.

Jeśli planowanego typu nie ma w szablonie albo CloudFormation odrzuca kombinację regionu, AMI i rozmiaru, nie wymuszać jej ręczną zmianą szablonu. Wybrać oferowany typ spełniający wymagania obciążenia i licencji albo zatrzymać wdrożenie do czasu wyjaśnienia regionu, oferty lub licencji.

Przygotowanie wdrożenia standalone

Przed startem zapisać:

• konto AWS, region, Availability Zone i ofertę BYOL lub PAYG;
• nową lub istniejącą VPC oraz nienakładające się publiczne i prywatne CIDR;
• stałe źródło zarządzania, np. 198.51.100.27/32, zamiast dostępu globalnego;
• Elastic IP, nazwy DNS i wymagane usługi inbound;
• prywatne sieci docelowe, default route i oczekiwaną drogę powrotną każdego przepływu;
• wspierany typ EC2, limit licencji, właściciela kosztów i tagi;
• procedury backupu, firmware i odbudowy.

198.51.100.27/32 to adres dokumentacyjny, który należy zastąpić prawdziwym publicznym IP administratora. Gdy często się zmienia, VPN lub kontrolowany jump host jest bezpieczniejszy niż szerokie otwarcie TCP 4444.

W istniejącej VPC nie wybiera się subnetów wyłącznie po nazwie: Route Tables muszą odpowiadać planowanemu kierunkowi. AWS opisuje włączenie appliance w przykładach middlebox routing. Source/Destination Check musi być wyłączony na przekazujących ruch ENI firewalla. CloudFormation powinien ustawić te szczegóły, a administrator je zweryfikować bez ślepych zmian.

Wdrożenie standalone przez CloudFormation

1. Otworzyć ofertę Sophos Firewall BYOL lub PAYG w AWS Marketplace, wybrać View purchase options i zaakceptować warunki.
2. W Continue to Configuration wybrać fulfillment, aktualną wersję SFOS i region.
3. W Continue to Launch wybrać Launch CloudFormation i otworzyć template w konsoli AWS CloudFormation.
4. Podać unikatowy Stack name. Dla nowej VPC sprawdzić nakładanie zakresów z istniejącymi VPC, VPN i sieciami lokalnymi.
5. Dla istniejącej VPC przypisać VPC ID, jeden subnet publiczny, jeden prywatny i nowy lub wolny Elastic IP. Pozostawić Network Address Prefix for new VPC bez zmian.
6. Użyć wyłącznie rozmiaru EC2 oferowanego przez otwarty szablon dla regionu i AMI, a w BYOL ponownie sprawdzić go względem zapisanego limitu licencji. Nie przechowywać sekretów w ticketach, screenshotach ani publicznie czytelnych plikach parametrów.
7. Sprawdzić żądane zasoby IAM. Dopiero wtedy potwierdzić I acknowledge that AWS CloudFormation might create IAM resources i kliknąć Submit.
8. Zaczekać na CREATE_COMPLETE. Odczytać Elastic IP w Outputs, a w EC2 sprawdzić oba status checks i oczekiwane ENI.
9. Otworzyć WebAdmin z dozwolonego źródła pod https://<EIP>:4444. Ostrzeżenie początkowego lokalnego certyfikatu pominąć tylko po sprawdzeniu IP i zakończyć rejestrację oraz basic setup. Następnie w Administration > Licensing potwierdzić aktywność oczekiwanej licencji; w razie rozbieżności poprawić rozmiar instancji lub przypisanie licencji przed dopuszczeniem ruchu produkcyjnego.

Parametry Marketplace mogą się zmieniać; przed każdym wdrożeniem produkcyjnym porównaj widoczne nazwy pól z faktycznie otwartym template’em.

Wspólne otwieranie reguł AWS i SFOS

Template włącza początkowo tylko WebAdmin i SSH. IPsec, SSL VPN, RED, WAF, User Portal i publikowane aplikacje wymagają reguł AWS. RED używa na przykład TCP 3410.

Dla każdej publikacji raz udokumentować protokół, port docelowy i źródło, ale wdrożyć je oddzielnie:

1. Security Group pozwala tylko wymaganemu źródłu na port właściwego ENI.
2. Własna NACL pozwala na żądanie i powrót. AWS wyjaśnia różnicę w Security Groups i Network ACLs.
3. Route Table prowadzi ruch przez firewall i zapewnia prawidłowy powrót.
4. Reguły firewall SFOS i w razie potrzeby NAT używają konkretnych stref, hostów i usług, logują ruch i stosują właściwe Security Profiles.

Nigdy nie otwierać SSH ani WebAdmin do 0.0.0.0/0. Wąski dostęp AWS nie zastępuje precyzyjnej reguły SFOS.

Auto Scaling dla ruchu inbound

Auto Scaling wymaga konta AWS, oferty Sophos Cloud Firewall (PAYG) i danych API Sophos Fusion (dawniej Sophos Central). W My products > General settings > API credentials management utworzyć credential z rolą Service principal firewall. Client ID i Client secret traktować jak hasło.

Jako fulfillment wybrać Sophos Auto Scaling Firewall for AWS. Template wymaga dwóch różnych Availability Zones. Dla istniejącej VPC podać dwa subnety publiczne i jeden prywatny; na obu publicznych subnetach włączyć Auto-assign public IPv4 address.

Szczególnie sprawdzić:

• Trusted Network CIDR: publiczne IP administratora jako /32, nigdy 0.0.0.0/0;
• Public Network CIDR: 0.0.0.0/0 otwiera porty inne niż zarządzanie dla całego Internetu. Avanet zaleca znane źródła lub natychmiastowe ograniczenie po wdrożeniu;
• Minimum capacity: minimalna liczba dostępnych workerów;
• Starting capacity: początkowe workery. Przy pierwszym wdrożeniu ustawić Maximum capacity, aby wszystkie razem zarejestrować w Fusion;
• Maximum capacity: twardy limit workerów i kosztów;
• Warm Pool Refresh Period: interwał uruchamiania zatrzymanych instancji i synchronizacji policy Fusion; default to pięć dni;
• Use CloudWatch: wysyła logi firewalla do CloudWatch Logs.

Po CREATE_COMPLETE w My products > Firewall management > Firewalls sprawdzić automatyczną grupę i wszystkie oczekiwane, zatwierdzone workery PAYG. Dopiero potem zmieniać capacity lub scaling policy.

DNAT za Network Load Balancer

Dla publikowanej usługi listener TCP NLB przekazuje ruch do Target Group workerów. W policy grupy Fusion tworzy się zakresy subnetów WAN obu stref, host wewnętrzny i usługę publikowanego portu. Nie obejmować pierwszego adresu IP każdego subnetu AWS.

W tym projekcie single-arm reguła firewall dopasowuje WAN-WAN do zakresów i dokładnej usługi. DNAT tłumaczy do serwera wewnętrznego i używa MASQ jako translated source, aby powrót przeszedł przez ten sam worker. Następnie połączyć Target Group, Auto Scaling Group i listener NLB.

Bezpośrednia publikacja RDP nie jest zalecana. Preferować VPN lub ZTNA. Jeśli DNAT jest konieczny, ograniczyć źródła w NLB, AWS i SFOS, włączyć IPS i logging oraz wykonać test negatywny.

Odbiór jednego przepływu warstwa po warstwie

Zapisać jeden przepływ, np. 198.51.100.27:55000 -> NLB-DNS:443 -> App-Server:443. Port źródłowy jest tylko przykładem efemerycznego portu klienta. Sprawdzić kolejno:

1. DNS i listener NLB wskazują oczekiwany cel, a Target Group pokazuje workery jako healthy.
2. Security Groups i NACL pozwalają dokładnie na żądanie i powrót.
3. Route Tables i ENI prowadzą ruch przez appliance; Source/Destination Check jest wyłączony na interfejsach tranzytowych.
4. SFOS Log Viewer pokazuje oczekiwaną Rule ID. Dla DNAT zgadzają się cel pierwotny, tłumaczony i powrót.
5. Test dozwolony dociera do aplikacji, a test z niedozwolonego źródła jest blokowany.

Jeśli brak logu SFOS, sprawdzić DNS, listener, Target Health, Security Group, NACL i route. Przy dropie z inną Rule ID poprawić strefy, obiekty sieciowe, usługę i kolejność. Gdy żądanie dociera bez odpowiedzi, sprawdzić Route Table, NACL, default gateway serwera i w Auto Scaling ustawienie MASQ.

Eksploatacja i odtwarzanie

Standalone i Auto Scaling wymagają różnych runbooków. Dla standalone udokumentować backup SFOS i przetestowane odtworzenie, proces firmware, parametry CloudFormation i próbę odbudowy. Snapshot EC2 nie zastępuje eksportowanego backupu SFOS.

Workery Auto Scaling są efemeryczne. Z CloudWatch logi trafiają pod /sophos/xg/; jawnie ustawić retencję, szyfrowanie, dostęp i koszty. Zakończone instancje EC2 pozostają w grupie Fusion i trzeba je usunąć ręcznie. Warm Pool nie zastępuje kontroli aktualnej policy na każdym workerze.

Rejestr eksploatacyjny obejmuje tagi właściciela i kosztów, alerty budżetowe, licencję, rotację sekretów, retencję CloudWatch, czyszczenie Fusion, zatwierdzanie firmware, testy zmian i recovery. Po każdej zmianie template, routingu lub policy powtórzyć test pozytywny i negatywny.