Zanim cokolwiek ruszysz: Safe Mode
- Przed edycją jakiejkolwiek reguły firewalla, NAT-u czy routingu na routerze pracującym zdalnie lub bez podłączonej konsoli włącz Safe Mode. Jedna błędna reguła potrafi odciąć Cię całkowicie — a domowy router rzadko stoi obok Ciebie z gotowym kablem konsolowym.
- W Safe Mode, jeśli sesja zostanie zerwana (bo właśnie sam się zablokowałeś), router automatycznie wycofuje wszystkie zmiany wprowadzone w trakcie tej sesji. Wracasz tak, jakby nic się nie stało.
- W terminalu przełączasz go skrótem
Ctrl+X. Znak zachęty zmienia się na <SAFE>. Wprowadzasz zmiany, potwierdzasz, że łączność dalej działa, po czym ponownie naciskasz Ctrl+X, aby je zatwierdzić. W WinBoxie służy do tego przycisk Safe Mode w lewym górnym rogu.
- Traktuj to jako żelazną zasadę przy pracy z firewallem. Kosztuje dwa naciśnięcia klawiszy, a oszczędza fizyczną wyprawę do routera — albo frustracji z powodu straty kilku godzin lub dni pracy.
Zasada główna: czytelność przede wszystkim
- Najważniejsza zasada domowego firewalla jest taka, że
Ty musisz go rozumieć za pół roku. Zestaw reguł, którego nie potrafisz już przemyśleć, nie jest bezpiecznym zestawem reguł — jest obciążeniem.
- Każda dodana reguła to reguła, którą trzeba pamiętać, audytować i uwzględniać, gdy o 23:00 coś przestanie działać. Złożoność ma koszt utrzymania, który po cichu narasta.
- Wybieraj mniej, szersze i dobrze nazwane reguły zamiast wielu wąskich. Firewall z dwunastoma regułami, które w pełni rozumiesz, bije ten z czterdziestoma, które pamiętasz w połowie.
- To jest świadomy kompromis.
Mógłbyś dołożyć filtrowanie DNS per aplikacja przez AdGuard, głęboką inspekcję IDS, ziarniste ACL-e per urządzenie i dziesiątki mikroreguł. Czasem właściwą decyzją jest nie dodawać tej reguły — marginalny zysk w bezpieczeństwie nie usprawiedliwia spadku łatwości utrzymania.
- Bezpieczeństwo i łatwość utrzymania nie są przeciwieństwami, ale od pewnego momentu zaczynają się przeciągać. Sztuką jest wyczucie, gdzie leży ten moment dla sieci, którą utrzymujesz w pojedynkę.
Używaj list interfejsów, nie nazw interfejsów
- Grupuj interfejsy według poziomu zaufania w listy zamiast odwoływać się bezpośrednio do portów fizycznych. Reguły pozostają stabilne przy zmianach sprzętu lub VLAN-ów, a intencja jest widoczna na pierwszy rzut oka.
- Typowy zestaw:
WAN dla łącza, LAN dla bridge’a, TRUSTED dla sieci z prawem do zarządzania (Twój główny VLAN użytkowników, VPN, port ratunkowy) oraz WAN_ONLY dla segmentów, które mogą sięgać internetu, ale nigdy reszty LAN-u.
/interface list
add name=WAN
add name=LAN
add name=TRUSTED
add name=WAN_ONLY
/interface list member
add interface=ether1 list=WAN
add interface=vlan1_users list=TRUSTED
add interface=vpn list=TRUSTED
add interface=ether5 list=TRUSTED comment="Rescue port"
add interface=vlan3_iot list=WAN_ONLY
add interface=vlan5_dmz list=WAN_ONLY
- Teraz reguła brzmi
in-interface-list=TRUSTED zamiast nieczytelnej listy nazw portów. Gdy później dodasz nowy zaufany VLAN, dopisujesz jednego członka listy — a nie nową regułę firewalla.
Domyślny deny, z logowaniem
- Zarówno łańcuch
input (ruch do samego routera), jak i forward (ruch przechodzący) powinny kończyć się jawnym dropem. Wszystko, co wcześniej nie zostało zaakceptowane, jest odrzucane.
- Loguj końcowy drop. Gdy coś poprawnego przestanie działać, log pokaże dokładnie, co zostało zablokowane — to właśnie czyni politykę deny-by-default możliwą do debugowania zamiast tajemniczą.
/ip firewall filter
add action=drop chain=input comment="Final drop - protect router" log=yes log-prefix=DROP_
add action=drop chain=forward comment="Final drop - block unauthorized" log=yes log-prefix=DROP_
Łańcuch input: ochrona samego routera
- Kolejność ma znaczenie. Najpierw akceptuj tanie, częste przypadki (połączenia ustanowione), potem obsłuż wyjątki, na końcu odrzuć resztę.
- Akceptuj
established,related,untracked na samej górze — zdecydowana większość pakietów trafia tutaj, co utrzymuje resztę łańcucha poza gorącą ścieżką.
- Odrzucaj
invalid wcześnie. To pakiety w bezsensownym stanie połączenia, bez żadnego uprawnionego zastosowania.
- Z WAN-u zezwalaj tylko na to, co naprawdę wystawiasz: ping do diagnostyki (ograniczony wyłącznie do echo-request, nie całego ICMP) oraz port nasłuchu VPN.
- Pełny dostęp do zarządzania dopuszczaj tylko z
TRUSTED. Ta jedna reguła zastępuje kilkanaście wyjątków per usługa.
/ip firewall filter
add action=accept chain=input connection-state=established,related,untracked \
comment="Accept established & related"
add action=drop chain=input connection-state=invalid \
comment="Drop invalid" log-prefix=invalid_
add action=accept chain=input protocol=icmp icmp-options=8:0 in-interface-list=WAN \
comment="Allow ping from WAN only"
add action=accept chain=input protocol=udp dst-port=22001 in-interface-list=WAN \
comment="WireGuard listen port"
add action=accept chain=input in-interface-list=TRUSTED \
comment="Management access from trusted networks"
# ... final drop trafia tutaj
- Zwróć uwagę, czego tu
nie ma: żadnej osobnej reguły dla SSH, Winboksa, panelu web czy DNS. Wszystkie są pokryte jednym akceptem TRUSTED. Mniej reguł, to samo bezpieczeństwo, znacznie łatwiejsza czytelność.
Łańcuch forward: kontrola tego, co przechodzi
- Najpierw FastTrack dla połączeń ustanowionych ze względu na wydajność, potem akcept established/related jako wolniejsza ścieżka zapasowa, następnie drop invalid.
- Pozwól
TRUSTED swobodnie sięgać zarówno WAN-u, jak i LAN-u — to Twoje urządzenia.
- Pozwól segmentom
WAN_ONLY (IoT, DMZ) sięgać internetu, ale jawnie przypnij je do interfejsu łącza, żeby nie mogły wejść do LAN-u.
- Dopuść ruch z przekierowania portów przez
connection-nat-state=dstnat, a resztę odrzuć.
/ip firewall filter
add action=fasttrack-connection chain=forward connection-state=established,related \
comment="FastTrack"
add action=accept chain=forward connection-state=established,related,untracked \
comment="Accept established & related"
add action=drop chain=forward connection-state=invalid comment="Drop invalid"
add action=accept chain=forward in-interface-list=TRUSTED \
comment="Trusted -> WAN/LAN"
add action=accept chain=forward in-interface-list=WAN_ONLY out-interface=ether1 \
comment="Isolated segments -> internet only"
add action=accept chain=forward connection-nat-state=dstnat \
comment="Allow port forwarding"
# ... final drop trafia tutaj
Kontekst: segmentacja VLAN
- Firewall jest tylko tak dobry, jak topologia pod nim. Podział sieci na VLAN-y — zaufani użytkownicy, IoT, publiczne DMZ — zamienia szerokie intencje firewalla w egzekwowalne granice.
- Zaufane urządzenia żyją w jednym VLAN-ie wewnątrz
TRUSTED. Niezaufany sprzęt (smart home, kamery, wszystko, czego nie da się łatać) trafia do VLAN-u WAN_ONLY z izolacją klientów, więc przejęte urządzenie nie sięgnie reszty sieci.
- Usługa publiczna ląduje we własnym VLAN-ie DMZ, również
WAN_ONLY. Jeśli ten host zostanie włamany, promień rażenia kończy się na DMZ.
- To właśnie pozwala łańcuchowi forward pozostać krótkim: decyzje o zaufaniu są zakodowane w segmencie, do którego należy urządzenie, a nie w dziesiątkach reguł adresowych.
Kontekst: praca za Cloudflare
- Jeśli hostujesz stronę przez Cloudflare, możesz zagwarantować, że nikt nie sięgnie Twojego origin bezpośrednio po IP — cały ruch przychodzący WWW musi przyjść z sieci Cloudflare.
- Utrzymuj listę adresów z opublikowanymi zakresami Cloudflare i odrzucaj ruch z WAN do portów 80/443, którego źródło nie jest na tej liście. Jedna reguła egzekwuje całą politykę.
- Utrzymuj listę aktualną automatycznie skryptem z harmonogramu, który pobiera oficjalny wykaz zakresów, zamiast pielęgnować ją ręcznie.
/ip firewall filter
add action=drop chain=forward protocol=tcp dst-port=80,443 in-interface-list=WAN \
src-address-list=!cloudflare-ipv4 log=yes log-prefix=CF_PROTECT \
comment="Block non-Cloudflare traffic to origin"
- To naturalnie współgra z DMZ: destination NAT kieruje 80/443 do hosta WWW w segmencie publicznym, a reguła Cloudflare gwarantuje, że jedyna droga do niego biegnie przez proxy Cloudflare.
Czego nie dodawać
- Powstrzymaj się przed logowaniem każdego dropa na produkcji — loguj końcowe dropy i naprawdę interesujące zdarzenia, nie każdy zablokowany broadcast, bo logi zmienią się w szum, którego przestaniesz czytać.
- Nie pisz reguły na zagrożenie, któremu Twoja topologia już zapobiega. Jeśli segment jest
WAN_ONLY, rzadko potrzebujesz dodatkowych reguł per urządzenie, żeby trzymać go z dala od LAN-u — segment już to robi.
- Każda reguła powinna odpowiadać na pytanie, które potrafisz wyrazić w jednym zdaniu. Jeśli nie potrafisz, ta reguła prawdopodobnie nie powinna istnieć.
Podsumowanie
- Zanim cokolwiek ruszysz — Safe Mode (
Ctrl+X). Bez wyjątków przy pracy zdalnej.
- Domyślny deny na
input i forward, z logowanymi końcowymi dropami.
- Grupuj interfejsy w listy oparte na zaufaniu; pisz reguły względem list.
- Akceptuj ruch established najpierw, odrzucaj invalid wcześnie, wystawiaj minimum z WAN-u, dawaj zarządzanie tylko
TRUSTED.
- Koduj zaufanie w segmentacji VLAN, aby reguły firewalla mogły pozostać krótkie.
- Za Cloudflare egzekwuj ochronę origin jedną regułą z listą źródeł, utrzymywaną świeżo przez skrypt.
- Przede wszystkim: firewall, który w pełni rozumiesz, jest bezpieczniejszy niż sprytny, którego nie rozumiesz. Wybieraj łatwość utrzymania świadomie.
