# OperacjeProwadzić firewall w produkcji: drille failover, review logów, testy granic, pielęgnacja.

## 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](../../abusive-http-watch/configuration/)) 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](../../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](/pl/services/support/) to ścieżka eskalacji.