Operacje

Kwartalny drill failover#

Cały sens setupu dual-provider-HA jest taki, że failover działa, gdy główny uplink naprawdę pada. Jedyny sposób, aby na tym polegać, to celowo to testować.

Zalecana kadencja: kwartalnie, w cichym oknie ruchu, z operatorem przy konsoli.

Przebieg:

1. Ogłosić drill na kanale zespołowym — failover ma być niewidzialny, ale gdyby coś poszło źle, chce się o tym wiedzieć natychmiast.
2. Wyłączyć główny uplink na poziomie interfejsu (nie przy modemie operatora — to symuluje zły przypadek błędu).
3. W ciągu pięciu sekund monitor failover powinien przełączyć default-route na drugi uplink.
4. Zweryfikować dostępność zewnętrzną: request ze strefy powinien nadal się rozwiązywać, pobrać i wrócić.
5. Włączyć główny uplink z powrotem.
6. Monitor powinien w swoim skonfigurowanym interwale ustawić default-route z powrotem na główny.
7. Drill zapisać w dzienniku: data, time-to-detect, time-to-recover, cokolwiek niezwykłe.

Jeśli failover trwa dłużej niż oczekiwano, należy stuningować interwał sprawdzania lub progi monitora. Jeśli failover w ogóle się nie odbywa, konfiguracja monitora jest popsuta — naprawić, zanim się pójdzie do domu. Niedziałający monitor failover jest gorszy niż żaden monitor; daje operatorowi fałszywe poczucie bezpieczeństwa.

Review logów#

Trzy strumienie logów są ważne:

• Eventy firewalla. Decyzje drop, rozszerzenia tabel, NAT-state. Głośno przy skanach recon, cicho pod normalnym obciążeniem.
• Eventy SSL-offloading. Błędy terminacji, niepowodzenia walidacji certyfikatu, werdykty skanera. Spike’i znaczą, że coś się zmieniło — rotacja certyfikatu upstream, nowy klient, który nie ufa wewnętrznemu CA-root, lub wzorzec malware, który umknął wcześniejszemu stopniowi filtra.
• Eventy monitora failover. Przejścia linka. Powinno być puste przez większość tygodni. Częste przejścia wskazują na migający uplink — założyć temat u carriera.

Zalecana rutyna operatora: tygodniowo piętnaście minut przewinąć te trzy strumienie. Niezwykłe markować, zakładać ticketsy do kolejnego kwartalnego review.

Weryfikacja granic stref#

Strefy są zdefiniowane w zbiorze reguł. Zbiór reguł może być błędny. Jedyny sposób, aby ustalić, które stwierdzenie jest prawdziwe, to testowanie.

Zalecana kadencja: półrocznie, lub po każdej znaczącej zmianie zbioru reguł.

Dla każdej pary stref (Klienci ↔ DMZ, Klienci ↔ VPN, Anonimizacja ↔ wszystko inne itd.):

1. Z hosta w strefie A próbować dotrzeć do serwisu w strefie B, który nie powinien być dostępny.
2. Potwierdzić, że połączenie pada — TCP-RST, ICMP-unreachable lub timeout, zależnie od typu reguły.
3. Wynik zapisać w tym samym dzienniku.

Jeśli oczekiwana-zablokowana ścieżka jest dostępna, to bug reguły. Naprawić tego samego dnia.

Pielęgnacja blocklisty#

Tabele blocklisty rosną w czasie. Dwa częste obrazy błędu:

• Stałe wpisy. IP, które było abusive sześć miesięcy temu, dziś jest łączem DSL z nowym właścicielem. Periodyczna rotacja pliku blocklisty (patrz dokumentacja Konfiguracja Abusive HTTP Watch) to ogranicza.
• Drift whitelisty. Zakresy IP biura i VPN zmieniają się w czasie. Stałe wpisy whitelisty nie powodują natychmiastowych incydentów, ale obniżają wartość whitelisty jako narzędzia sterującego. Plik whitelisty reviewować kwartalnie.

Rotacja certyfikatów#

Warstwa terminacji TLS używa certyfikatów z Sovereign Certificate Authority. Rotacja odbywa się automatycznie przez ACME, ale:

• Potwierdzać rotację przynajmniej miesięcznie — openssl s_client wobec gateway, sprawdzić, że notAfter certyfikatu leży w przyszłości, sprawdzić, że chain wciąż waliduje się wobec wewnętrznego root.
• Testować zaufanie klienta po każdej zmianie po stronie CA — wybrać reprezentatywnego klienta per strefa, wywołać serwis HTTPS w obrębie sieci, sprawdzić, że nie pojawia się ostrzeżenie certyfikatu.

Obraz błędu: rotacja przechodzi po stronie CA, ale firewall nie przejmuje nowego certyfikatu (brakuje configuration-reload, błędne file-permissions). Stary certyfikat jest jeszcze przez jakiś czas ważny — bug pozostaje ukryty. Miesięczna weryfikacja to wyłapuje.

Rutynowa pielęgnacja#

• Patche OS. Patche istotne bezpieczeństwowo grać w oknie zalecanym przez producenta. Rebootować — firewall nie jest appliancem w stylu cattle, ale uptime poza dziewięcioma miesiącami zaprasza problemy.
• Review zależności. Daemony Tor, I2P, Squid i Privoxy mają każdy własne cykle patchy. Trackować release’y upstream.
• Check pojemności. Wypełnienie state-table, CPU w peak, headroom pamięciowy. Firewall powinien komfortowo działać poniżej połowy pojemności. Jeśli nie, planować następną odnowę sprzętu.

Gdy coś idzie nie tak#

Operacyjny nawyk o najwyższej wartości: spisywać, co się stało.

Krótka notatka per incydent — kiedy, co widziałeś, co zmieniłeś, co zadziałało, co nie — przekształca wystąpienie w trwały przyrost wiedzy. Przy następnym wystąpieniu tego samego wzorca rozwiąże to albo ta sama osoba, albo jej następca w minutach zamiast godzin.

Jeśli incydent przekracza ekspertyzę lub czas twojego zespołu, Wsparcie to ścieżka eskalacji.