Po co ACL w ogóle? Kontekst bezpieczeństwa w sieci
Czym jest ACL i czego nie załatwia
Lista kontroli dostępu (Access Control List – ACL) to mechanizm na routerze lub switchu, który decyduje, jaki ruch IP może przejść przez interfejs, a jaki ma być zablokowany. Działa na poziomie pakietów: patrzy na adres źródłowy, docelowy, protokół, porty i na tej podstawie wykonuje akcję permit lub deny.
ACL nie zastępuje pełnoprawnej zapory ogniowej nowej generacji, systemów IPS/IDS, DLP czy UTM. Nie analizuje treści aplikacyjnej, nie rozumie kontekstu użytkownika ani logowania. To filtr pakietów, który podejmuje proste decyzje na podstawie kilku pól nagłówka. Mimo tej prostoty, dobrze zaprojektowane ACL-e potrafią mocno podnieść poziom bezpieczeństwa, szczególnie w mniejszych sieciach, gdzie nie ma rozbudowanych firewalli.
ACL to narzędzie „niskopoziomowe”, ale przez to niezwykle przewidywalne: jeśli reguła jest poprawna, urządzenie będzie jej się trzymać w każdej sytuacji. Dzięki temu nadaje się idealnie do egzekwowania podstawowych zasad separacji i ograniczania uprawnień, bez skomplikowanej infrastruktury dodatkowych systemów bezpieczeństwa.
Problemy bezpieczeństwa, które da się ogarnąć samymi ACL
Najczęstsze realne kłopoty w firmowych sieciach, które można rozwiązać samymi ACL, bez kupowania nowego sprzętu:
Pełna widoczność między VLAN-ami – pracownicy z sieci biurowej mają bezpośredni dostęp do serwerów, drukarek, systemów produkcyjnych czy IoT, chociaż nie jest im to potrzebne.
Brak ograniczeń do serwerów krytycznych – każdy host w LAN może podłączyć się do serwera baz danych, systemu ERP czy serwera kopii zapasowych, bo router pozwala na dowolną komunikację między podsieciami.
Router wystawiony „na świat” – brak ACL na interfejsie WAN oznacza, że dowolny adres z Internetu może próbować łączyć się z usługami na routerze (SSH, telnet, HTTP/HTTPS do panelu zarządzania).
Słaba separacja sieci gościnnej – goście lub urządzenia BYOD mają dostęp do zasobów wewnętrznych, bo jedynym „izolatorem” jest inne SSID, ale trasowanie nadal jest możliwe.
Brak kontroli ruchu zarządczego – SNMP, RDP, SSH czy WinRM są dostępne z całego LAN, zamiast tylko z dedykowanej podsieci administracyjnej.
W wielu z tych scenariuszy dobrze ułożone ACL-e załatwiają 80% problemu przy niewielkim wysiłku: parę reguł na routerze lub switchu L3, kilka testów, prosta dokumentacja. Bez dokładania nowego sprzętu ani licencji.
Zasada minimum uprawnień egzekwowana pakietami
Zasada minimum uprawnień mówi, że każdy element systemu (użytkownik, aplikacja, urządzenie) powinien mieć wyłącznie takie uprawnienia, jakie są niezbędne do realizacji jego zadań – ani trochę więcej. W sieciach IP tę zasadę można bardzo dobrze wyrazić za pomocą ACL. Zamiast myślenia „wszystko do wszystkiego”, wdraża się proste reguły typu:
„Użytkownicy w VLAN 10 mogą łączyć się z serwerem plików po SMB i z Internetem po HTTP/HTTPS, ale nie mają dostępu do serwera baz danych ani do podsieci zarządczej”.
„Urządzenia IoT w VLAN 30 mogą łączyć się wyłącznie z serwerem MQTT oraz DNS, nic poza tym”.
„Sieć gościnna ma tylko dostęp do Internetu przez NAT, żadnych innych podsieci wewnętrznych”.
Wprowadzenie takiej separacji w postaci ACL sprawia, że pojedyncze naruszenie (np. zainfekowany laptop) nie „zaleje” całej organizacji. Atakujący może mieć trudniej z poruszaniem się „na boki” po sieci, bo ruch między segmentami jest mocno ograniczony.
Efekt vs wysiłek: gdzie ACL daje największy zwrot
Przy ograniczonym czasie i budżecie lepiej skupić się na kilku miejscach, gdzie jedna lista ACL daje bardzo duży wzrost bezpieczeństwa:
Interfejs WAN routera – zablokowanie dostępu do usług zarządczych z Internetu, dopuszczenie tylko konkretnych portów potrzebnych do publikowanych usług (np. 443 do VPN) i ewentualnie dostępu z określonych adresów administracyjnych.
Gateway VLAN-ów „wrażliwych” – ACL na interfejsie SVI/VLAN dla sieci serwerów, systemów finansowych lub IoT, które ograniczają liczbę dozwolonych źródeł i usług.
Ruch zarządczy – separacja podsieci administracyjnej, z której można zarządzać routerami, switchami, serwerami, ale z pozostałych VLAN-ów taki ruch jest blokowany.
Sieci gościnne i BYOD – ACL, która po prostu wycina cały ruch w stronę adresów prywatnych poza gatewayem i DNS, zostawiając tylko wyjście do Internetu.
W wielu małych i średnich sieciach już sama kombinacja tych czterech elementów eliminuje większość najpoważniejszych luk. Konfiguracja to zwykle kilkanaście reguł na routerze i ewentualnie kilka na switchu L3, więc koszt wdrożenia jest minimalny w porównaniu z efektem.
Źródło: Pexels | Autor: Pixabay
Podstawy ACL: pojęcia, typy, logika działania
Standardowe i rozszerzone ACL oraz ich numeracja
Najczęściej spotykany model (np. w Cisco) wyróżnia kilka typów ACL:
Standardowe ACL – filtrują wyłącznie po adresie źródłowym IP. Nadają się do prostych zastosowań, np. ograniczenie, kto może w ogóle przejść przez router do innej sieci.
Rozszerzone ACL – pozwalają filtrować po:
adresie źródłowym i docelowym,
protokole (IP, TCP, UDP, ICMP, itp.),
portach źródłowych i docelowych (np. 80/443, 3389, 1433),
dodatkowych parametrach (typ ICMP, flagi TCP – zależnie od producenta).
Numerowane ACL – identyfikowane numerem (np. 1–99 standardowe, 100–199 rozszerzone w tradycyjnym Cisco IOS).
Nazwane ACL – identyfikowane przyjazną nazwą (np. „ACL-SERVERY”, „ACL-GOSCIE”). Łatwiejsze w utrzymaniu i dokumentowaniu niż numery.
Współcześnie w większości przypadków bardziej opłaca się używać ACL nazwanych. Dają lepszą czytelność konfiguracji i łatwiej je później modyfikować (edytowanie wstawianych reguł, komentarze). Numerowane ACL nadal istnieją, ale warto je zostawić dla prostych, mało zmiennych filtrów lub gdy dany sprzęt ma ograniczone wsparcie dla nazw.
Portu/zakresu portów – tylko w protokołach TCP/UDP, może być to konkretna usługa (np. eq 80) lub zakres (range 1024 65535).
Router lub switch przetwarza pakiet, przechodząc od góry do dołu listy ACL i szukając pierwszej reguły pasującej do pakietu. W momencie dopasowania decyzja jest podjęta – kolejne reguły nie są już sprawdzane. Na końcu każdej listy (nawet jeśli nie jest pokazana w konfiguracji) istnieje domyślna reguła implicit deny any, która blokuje wszystko, co nie zostało wcześniej explicite dozwolone.
Ten model ma kilka praktycznych konsekwencji:
Jeśli chcesz coś zablokować selektywnie, reguła deny musi się pojawić przed ogólnym permit.
Jeżeli utworzysz ACL składającą się wyłącznie z reguł deny, a nie dodasz niczego, co by permitowało ruch, efekt będzie taki, że dany interfejs stanie się „czarną dziurą”.
Kolejność ma kluczowe znaczenie – dwie listy z tym samym zestawem reguł, ale w innej kolejności, mogą działać zupełnie inaczej.
Różnica między ACL inbound a outbound
ACL jest przypinana do interfejsu w kierunku wejścia (inbound) lub wyjścia (outbound):
ACL inbound – filtruje pakiety przychodzące na dany interfejs, jeszcze zanim zostaną zrouterowane. To dobre miejsce, aby od razu odrzucać niechciany ruch u źródła, nie obciążając dalszej części urządzenia.
ACL outbound – filtruje pakiety wychodzące z interfejsu, już po decyzji routingu. Przydatne, gdy chcesz kontrolować, co konkretnie ma wyjść do danej sieci.
Z punktu widzenia wydajności i przejrzystości konfiguracji często opłaca się blokować ruch jak najbliżej źródła (edge filtering), czyli na interfejsach wejściowych VLAN-u źródłowego. Przy małych sieciach dopuszczalne jest także filtrowanie na interfejsach „docelowych” – kluczowe, aby nie mieszać bez potrzeby obu podejść w jednym projekcie.
Jak różni producenci nazywają ACL i co sprawdzić w dokumentacji
Chociaż zasada działania jest podobna, producenci używają różnych terminów:
Cisco – „access-list”, „ip access-group”, „standard/extended ACL”, coraz częściej object-groups.
HPE/Aruba – „ACL”, „VLAN ACL”, „Routed ACL”, czasem „port ACL” dla filtrowania na portach fizycznych.
MikroTik – klasyczne ACL-e funkcjonują pod hasłami „/ip firewall filter”, „/interface list”, „bridge filter”; logika jest podobna (chain, action, src/dst, protocol, port).
Inni producenci – „packet filter”, „firewall rules”, „security policy” – nierzadko pełnią podobną rolę co ACL, nawet jeśli nazwa brzmi bardziej „marketingowo”.
Przed wdrożeniem dobrze jest zajrzeć do dokumentacji i sprawdzić:
czy ACL działa tylko na warstwie 3 (IP), czy również na warstwie 2 (MAC, VLAN),
ile maksymalnie reguł obsługuje urządzenie (w tym TCAM na switchach),
jak wygląda proces dopasowywania (od góry, domyślne deny),
czy są dostępne grupy obiektów (adresowe, portowe),
czy konfiguracja daje możliwość logowania i monitorowania trafień w reguły.
Różnice między ACL na routerze i na switchu
ACL na routerze: filtrowanie między sieciami i ochrona brzegowa
Router jest naturalnym miejscem do stosowania ACL, ponieważ to on podejmuje decyzje o routingu między podsieciami oraz łączem do Internetu. Typowe zastosowania ACL na routerze:
Kontrola ruchu między VLAN-ami/podsieciami – np. blokada ruchu z sieci biurowej do sieci serwerów, z wyjątkiem niezbędnych portów.
Ochrona interfejsu WAN – przycięcie niechcianego ruchu z Internetu (np. drop wszystkiego oprócz ruchu VPN do konkretnego portu i ewentualnie ICMP z wybranych adresów).
Filtrowanie dostępu do samego routera – ACL-e na liniach vty, listy do zarządzania SNMP, ograniczenie, z których adresów można się logować.
Reguły NAT + ACL – dopuszczanie tylko tych połączeń, które mają być przekierowane do wewnętrznych serwerów (port forwarding) i blokowanie reszty.
Router często stanowi jedyny punkt styku sieci lokalnej z Internetem, więc od jakości ACL na interfejsie WAN zależy, czy administracyjne i wewnętrzne usługi będą narażone na skanowanie i ataki z zewnątrz, czy też pozostaną widoczne jedynie z zaufanych lokalizacji.
Switch L2 kontra L3: gdzie w ogóle można zastosować ACL
Zwykły switch warstwy 2 (L2) z reguły nie implementuje klasycznych ACL IP. Przełącza ruch na podstawie adresów MAC, bez patrzenia w warstwę 3. W takim przypadku filtrowanie między VLAN-ami odbywa się na routerze lub na osobnym firewallu.
Switch warstwy 3 (L3) ma możliwość routowania między VLAN-ami (inter-VLAN routing) i na tych interfejsach logicznych (SVI – Switched Virtual Interface) można już wieszać ACL-e IP, podobnie jak na routerze. W skrócie:
Gdzie ACL na switchu ma sens, a gdzie lepiej zostać przy routerze
Przy małej sieci z jednym routerem i prostym switchem L2 często rozsądniej jest utrzymać całe filtrowanie na routerze. Konfiguracja jest wtedy w jednym miejscu, łatwiej ją przejrzeć i zrobić backup. Dodawanie funkcji L3 tylko po to, żeby „też mieć ACL na switchu”, zwykle generuje więcej pracy niż realnych korzyści.
Switch L3 z ACL-ami zaczyna się opłacać, gdy:
masz kilka–kilkanaście VLAN-ów i spory ruch między nimi – przepychanie wszystkiego przez router stanie się wąskim gardłem,
router jest słaby wydajnościowo, a switch ma sensowny TCAM i zapas mocy,
chcesz ograniczać ruch już przy „wejściu” do sieci szkieletowej, np. separując segmenty produkcji, magazynu, biura.
W takim scenariuszu router zostawia się głównie do:
routingu na WAN/VPN,
kilku reguł brzegowych (antyspoofing, podstawowe filtry na Internet),
kontroli dostępu do samego routera.
Między VLAN-ami filtrowanie realizuje już switch L3, zwykle na interfejsach SVI. Konfiguracja jest podzielona, ale nadal do opanowania: „ruch lokalny” – switch, „świat zewnętrzny” – router.
Ograniczenia sprzętowe i pułapki przy ACL na switchu
Na switchu największym ograniczeniem bywa pamięć TCAM, w której trzymane są wpisy ACL. Ta pamięć jest szybka, ale droga, więc jej ilość bywa zaskakująco mała. W praktyce oznacza to:
nie da się bezkarnie dodać setek bardzo szczegółowych reguł na każdy VLAN,
czasem trzeba dzielić TCAM między „ACL”, „QoS”, „routing” – coś kosztem czegoś,
po przekroczeniu limitu część nowych reguł może być po prostu ignorowana.
Przy budżetowym sprzęcie warto sprawdzić w dokumentacji, czy:
liczony jest łączny limit wpisów ACL dla całego urządzenia,
limit dotyczy pojedynczej listy czy sumy wszystkich list,
producent nie stosuje „kompresji” reguł (scalania podobnych wpisów).
Przy tanich switchach L3 dobrym kompromisem jest podejście:
jedna ACL per kierunek ruchu (np. „FROM-LAN-TO-SERVERS”),
ewentualnie jedna wspólna ACL na kilka VLAN-ów,
agresywne użycie obiektów/adres-groups zamiast powielania pojedynczych IP.
Zminimalizujesz w ten sposób zużycie TCAM i liczbę pozycji do utrzymania, a nadal osiągniesz sensowny poziom separacji.
Źródło: Pexels | Autor: panumas nikhomkhai
Projektowanie polityki ACL krok po kroku
Inwentaryzacja: kto z kim ma rozmawiać i po co
Zanim zaczną powstawać pierwsze reguły, trzeba wiedzieć, jaki ruch w ogóle ma być dopuszczony. Nie chodzi o pełną dokumentację klastra Kubernetes, tylko o prostą listę:
jakie są główne strefy sieci (VLAN-y: biuro, serwery, produkcja, goście, IoT),
z której strefy do której naprawdę musi iść ruch,
jakie protokoły są do tego potrzebne (RDP, HTTP/HTTPS, SMB, bazy danych, drukarki).
W praktyce da się to zrobić w 1–2 godziny, siedząc z kimś od aplikacji i właścicielem biznesowym. Zamiast pytać „czego potrzebujecie?”, lepiej przejść po kluczowych systemach:
„Kto łączy się do systemu X i w jaki sposób?”
„Czy ten serwer musi wychodzić w Internet, a jeśli tak, to do czego?”
Z takiej rozmowy powstaje prosty szkic macierzy „strefa → strefa” z kilkoma portami przypiętymi do każdej relacji.
Model strefowy zamiast „ACL na wszystko”
Zamiast tworzyć dziesiątki ACL dla pojedynczych hostów, dużo taniej w utrzymaniu jest podejście strefowe. Strefa to zwykle:
cały VLAN (np. VLAN-20-BIURO),
podsieć z adresem i maską,
czasem logiczna „grupa” serwerów wydzielona w osobną podsieć.
Na tej bazie można zbudować prosty zestaw zasad:
BIURO → SERWERY: tylko określone porty (np. RDP, HTTP/HTTPS do aplikacji, SMB do plików),
GOSCIE → wewnątrz: nic, tylko Internet,
IoT → SERWERY: tylko potrzebne endpointy (np. do logowania, MQTT, HTTP do konkretnego hosta),
SERWERY → INTERNET: tylko wychodzący HTTP/HTTPS i aktualizacje.
Z czasem, jeśli zajdzie potrzeba, można tę siatkę doprecyzować o pojedyncze wyjątki. Rdzeń pozostaje jednak prosty i łatwy do analizy.
Strategia „domyślnie blokuj” czy „domyślnie pozwalaj”
Dla bezpieczeństwa najlepsze jest podejście default deny: wypisujesz, co wolno, a reszta leci na implicit deny. W realnych, żywych sieciach bywa to trudne, bo:
brakuje dokumentacji aplikacji,
nie ma pełnej listy portów (np. stare systemy ERP),
awarie przy „zaostrzeniu” reguł uderzają w codzienną pracę.
Dobry kompromis na start:
Weryfikacja i uszczelnienie najbardziej ryzykownych kierunków (np. GOSCIE → SERWERY = deny).
Stopniowe ograniczanie ruchu z sieci użytkowników do serwerów – najpierw blokady oczywistych rzeczy (np. blok SMB z gościnnej, RDP z całego świata na routerze WAN).
Dopiero gdy macierz ruchu jest w miarę znana, przechodzenie na „domyślnie blokuj” między wybranymi strefami.
Pozwala to budować politykę krok po kroku, nie paraliżując pracy użytkowników.
Planowanie kierunku ACL: przy źródle czy przy celu
Dwa podstawowe podejścia do lokalizacji ACL:
przy źródle – filtrujesz ruch jak najbliżej miejsca, z którego wychodzi,
przy celu – chronisz konkretne „cenne” segmenty (np. VLAN z serwerami).
Z punktu widzenia wydajności sieci przewagę ma filtrowanie przy źródle, ale przy małej instalacji z 5–6 VLAN-ami prostsze konfiguracyjnie bywa filtrowanie przy celu:
każdy VLAN „cenny” ma na swoim SVI jedną ACL,
zasada: „kto może dotknąć serwerów/administracji, a kto nie”.
Jeżeli switch/ router ma ograniczone możliwości sprzętowe, sensowna jest mieszanka:
twarda blokada „dzikich” segmentów przy źródle (GOSCIE, IoT),
bardziej granularne ACL przy serwerach i sieci administracyjnej.
Testowanie i wdrażanie zmian bez wyłączania sieci
Najbardziej kosztowne błędy przy ACL to takie, które wychodzą na jaw dopiero po godzinie lub następnego dnia. Wystarczy źle ustawiony any lub literówka w masce, żeby zablokować pół biura. Kilka prostych nawyków mocno obniża ryzyko:
Najpierw logowanie – wielu producentów pozwala dodać akcję log do reguły. Można najpierw stworzyć „deny log” bez faktycznego blokowania (lub z akcją count), obejrzeć ruch i dopiero potem włączyć twardy deny.
Okno zmian – bardziej agresywne ACL-e wdrażać po godzinach szczytu. W małej firmie często wystarczy późne popołudnie.
Roll-back w kieszeni – trzymać gotową komendę przywracającą poprzednią konfigurację ACL, najlepiej w osobnym pliku/ notatce.
Dostęp awaryjny – mieć choć jeden port/ VLAN administracyjny z inną ścieżką dostępu (np. out-of-band, lokalna konsola), aby nie „odstrzelić” sobie zarządzania.
Prosty, ale przydatny trik: zamiast od razu zmieniać istniejącą ACL, utwórz jej kopię z nowymi regułami i przepnij interfejs na nową listę dopiero wtedy, gdy konfiguracja ma ręce i nogi. Łatwiej wtedy wrócić do pierwotnej wersji jednym poleceniem.
Źródło: Pexels | Autor: cottonbro studio
Standardowe i rozszerzone ACL w praktyce
Standardowe ACL: gdzie nadal mają sens
Standardowe ACL, choć proste, są nadal przydatne w kilku scenariuszach:
Ograniczenie dostępu administracyjnego – np. lista adresów, z których wolno się logować na router (vty),
Proste listy dla SNMP, syslog, NTP – jedna podsieć zarządzająca, reszta zablokowana,
Filtr „kto może w ogóle wyjść przez ten router” – np. tylko kilka zaufanych podsieci.
Konfiguracja bywa banalna:
access-list 10 permit 192.168.10.0 0.0.0.255
access-list 10 deny any
line vty 0 4
access-class 10 in
Efekt: tylko użytkownicy z danej podsieci biurowej mogą się logować na router. Dla małych instalacji taki minimalny zestaw reguł czasem załatwia 80% problemu „każdy może się dostać na urządzenie”.
Rozszerzone ACL: filtrowanie „po usłudze”
Rozszerzone ACL pozwalają uzależnić decyzję od portu i protokołu. To główne narzędzie do separacji segmentów aplikacyjnych. Typowy przykład – dostęp z biura do serwerów tylko po niezbędnych portach:
ip access-list extended BIURO-DO-SERWEROW
permit tcp 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255 eq 3389
permit tcp 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255 eq 443
deny ip any any
Taką listę podpina się zwykle na interfejsie SVI VLAN-u serwerowego w kierunku in. Ruch z biura do serwerów korzystający z RDP i HTTPS przechodzi, reszta jest cięta.
Jeżeli urządzenie wspiera grupy obiektów (adresowe i portowe), warto z nich korzystać. Zamiast edytować 10 reguł przy zmianie jednego serwera, koryguje się pojedynczy obiekt.
Typowe błędy przy tworzeniu rozszerzonych ACL
Przy bardziej szczegółowych ACL-ach pojawia się kilka powtarzalnych wpadek:
Pomylenie kierunku – wpisywanie portu tylko po stronie destination, mimo że aplikacja używa nietypowego portu źródłowego; w większości przypadków filtruje się po docelowym, ale niektóre systemy (np. część trunków VoIP) wymagają kontroli także źródła.
Maszkolanie – zamiana maski sieci na wildcard (0.0.0.255 vs 255.255.255.0) bywa źródłem błędów. Dobrym nawykiem jest przeliczenie jej na kartce lub użycie kalkulatora przed wklejeniem konfiguracji.
Brak „permit ip any any” przy ACL nakładanej tylko na część ruchu – jeśli ACL ma blokować tylko kilka rzeczy, a cała reszta powinna przechodzić, trzeba jawnie dopuścić ruch na końcu listy.
Przy budżetowych wdrożeniach opłaca się zachować prostotę: kilka krótkich, czytelnych reguł zamiast „firewalla w stylu enterprise budowanego na ACL-ach”.
Łączenie standardowych i rozszerzonych ACL na jednym urządzeniu
Nic nie stoi na przeszkodzie, żeby na tym samym routerze mieć:
standardowe ACL-e do kontroli dostępu administracyjnego (vty, SNMP, zarządzanie),
rozszerzone ACL-e na interfejsach danych (VLAN-y, WAN).
Przykładowo:
! ACL standardowa do zarządzania
access-list 15 permit 192.168.100.0 0.0.0.255
! ACL rozszerzona między VLAN-ami
ip access-list extended VLAN10-TO-VLAN20
permit tcp 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255 eq 443
deny ip any any
interface Vlan20
ip access-group VLAN10-TO-VLAN20 in
line vty 0 4
access-class 15 in
Konfiguracja jest nadal zwięzła i zrozumiała, a jednocześnie rozdziela dostęp administracyjny od polityki ruchu między segmentami.
ACL na VLAN-ach i interfejsach – gdzie podpiąć reguły
ACL na SVI (interfejsach VLAN) – filtr między podsieciami
Przy switchu L3 najczęściej ACL podczepia się do interfejsów SVI. Wadą jest to, że:
lista obowiązuje dla całego VLAN-u,
ACL na interfejsach fizycznych – ruch do/ z Internetu
Interfejs WAN to najczęstsze miejsce, gdzie ACL robią realną różnicę dla bezpieczeństwa. Nawet jeśli stoi tam prosty router z tanim firewallem, kilka reguł na wejściu potrafi odciążyć urządzenie i obciąć najbardziej ryzykowny ruch.
Przykładowy zestaw minimalny na interfejsie zewnętrznym w kierunku in:
blokada prywatnych adresów źródłowych (RFC1918, APIPA, lokalne link-local),
blokada ruchu zarządzającego na sam router (Telnet, Winbox, HTTP/HTTPS admina) z Internetu,
jawne dopuszczenie tylko tego, co naprawdę musi przyjść z zewnątrz (np. 443 do jednego serwera),
reszta – implicit deny.
ip access-list extended WAN-IN
! anty-spoofing: prywatne adresy nie powinny przychodzić z Internetu
deny ip 10.0.0.0 0.255.255.255 any
deny ip 172.16.0.0 0.15.255.255 any
deny ip 192.168.0.0 0.0.255.255 any
deny ip 169.254.0.0 0.0.255.255 any
! dopuszczamy tylko HTTPS do wystawionego serwera
permit tcp any host 203.0.113.10 eq 443
! opcjonalnie: ICMP echo, jeśli potrzebna diagnostyka
permit icmp any host 203.0.113.1 echo
! reszta ruchu: blokada (implicit deny)
W małej firmie już taki prosty filtr przed Internetem potrafi „uspokoić” logi z firewalla i zmniejszyć ilość śmieci, które atakują wystawione usługi. Konfiguracja jest krótka, a potencjalny zysk duży.
Jeżeli router ma małą wydajność, na interfejsie WAN buduje się możliwie zwięzłe ACL, bez dziesiątek wyjątków. Bardziej szczegółowe filtrowanie robi się bliżej serwerów lub na dedykowanym firewallu.
ACL na portach dostępowych – kiedy się opłaca
Filtracja bezpośrednio na portach dostępowych switcha (port ACL, PACL) ma sens głównie w dwóch sytuacjach:
porty „specjalne” – np. pojedynczy terminal płatniczy czy kasa fiskalna, która ma mówić tylko z jednym serwerem,
miejsca „publiczne” – gniazdka w sali konferencyjnej, holu, gdzie chcesz od razu przyciąć niektóre protokoły.
Zamiast wprowadzać nowy VLAN dla jednego urządzenia, da się na porcie wymusić prostą ACL blokującą wszystko poza jednym kierunkiem. To nie jest elegancja w stylu dużego data center, ale bywa najtańszym kompromisem: 5 minut pracy, zero zmian w trasowaniu.
ip access-list extended TYLKO-DO-SERWERA
permit tcp any host 192.168.50.10 eq 443
deny ip any any
interface FastEthernet0/10
ip access-group TYLKO-DO-SERWERA in
Minusem takiego podejścia jest skalowalność – przy kilkudziesięciu portach łatwo się pogubić. Dlatego port ACL rezerwuje się raczej na jednostkowe, krytyczne przypadki, a nie jako główne narzędzie segmentacji.
ACL vs. VLAN: kiedy co ma większy sens
Segmentację da się robić „po taniości” samymi ACL-ami, ale szybciej dochodzi się do granic czytelności konfiguracji. Tańsze i rozsądniejsze w dłuższej perspektywie bywa:
wydzielenie osobnego VLAN-u dla grupy urządzeń,
zastosowanie jednej, dobrej ACL na SVI tego VLAN-u.
Przykład z życia: w biurze pojawia się nowa grupa gości korzystających z VPN-ów „z domów” i różnych narzędzi P2P. Zamiast pisać kilkanaście ACL na portach, lepiej:
utworzyć VLAN GOSCIE i podpiąć do niego porty w salach konferencyjnych,
na SVI VLAN GOSCIE dodać jedną ACL blokującą wszystko oprócz wyjścia do Internetu na 80/443 i DNS.
Efektem jest prostsza administracja i jasny podział – jeśli trzeba dołożyć kolejne gniazdko „gościnne”, wystarczy przełączyć port do konkretnego VLAN-u, nie trzeba kopiować ACL.
ACL na VLAN-ach „uplinkowych” – połączenia między switchami
Na łączach między switchami (trunki) lepiej unikać skomplikowanych ACL. Filtrowanie na uplinku:
utrudnia diagnostykę – trudno od razu wyłapać, czy problem jest w ACL na SVI, czy na trunku,
bywa mylące: ruch między VLAN-ami i tak idzie przez urządzenie L3, więc podwójna filtracja tworzy chaos.
Sens ma jedynie kilka prostych blokad, takich jak zatrzymanie niechcianych multicastów lub ograniczenie ruchu specyficznych protokołów (np. niepotrzebne discovery między budynkami). Nawet wtedy lepiej najpierw sprawdzić, czy nie da się tego zrobić innym mechanizmem (storm control, IGMP snooping), który jest do tego stworzony.
ACL a routing między VLAN-ami (router-on-a-stick, małe L3)
W małych sieciach często działa router-on-a-stick: jeden router z kilkoma subinterfejsami trunkującymi do switcha. W takim układzie są dwa miejsce na ACL:
na subinterfejsach routera (dotyczących danego VLAN-u),
na SVI na switchu L3 (jeśli przełącznik też routuje).
Najprościej jest trzymać się jednej zasady: filtracja tam, gdzie zapada decyzja routingu. Jeżeli routing między VLAN-ami robi router, ACL-e nakłada się na subinterfejsy routera. Jeśli L3 jest na switchu, router dostaje tylko filtrowanie WAN.
Mieszanie obu podejść („trochę blokujemy na routerze, trochę na switchu”) kończy się tym, że nawet autor konfiguracji po pół roku nie wie, gdzie coś jest ucięte. W budżetowych wdrożeniach wygrywa wariant mniej „idealny architektonicznie”, ale czytelny dla tego, kto będzie to utrzymywał.
Wsparcie sprzętowe: kiedy ACL zaczynają boleć wydajnościowo
Tanie switche i routery mają ograniczoną liczbę wpisów ACL wspieranych sprzętowo (TCAM, ASIC). Po przekroczeniu limitu ruch idzie programowo, czyli wolno. Skutki:
spadki prędkości tylko dla części ruchu,
dziwne „przytykanie się” sieci pod obciążeniem,
brak oczywistego komunikatu o problemie – z zewnątrz wszystko wygląda „ok”.
Przy planowaniu polityki lepiej więc:
konsolidować reguły – zamiast 10 wpisów na pojedyncze IP, jeden wpis na podsieć,
używać obiektów adresowych, jeżeli sprzęt i system operacyjny je wspierają,
unikać niepotrzebnych duplikatów między listami (copy-paste bez refleksji).
Dobrym nawykiem jest sprawdzenie, ile ACL sprzęt obsłuży w dokumentacji, i trzymanie się bezpiecznego marginesu. Lepiej mieć o 20% mniej reguł, niż potem szukać „ducha w maszynie”, bo część ruchu zaczęło tłuc CPU.
Monitorowanie i logowanie ruchu z ACL
ACL działają najskuteczniej, gdy nie są „wypalone w kamieniu”. Bez podstawowego monitoringu łatwo przeoczyć:
nowe aplikacje, które użytkownicy zaczęli wykorzystywać,
próby skanowania lub lateral movement wewnątrz sieci,
zapomniane wyjątki, które zostają „na zawsze”.
Kilka tanich, ale pożytecznych praktyk:
oznaczanie kluczowych reguł akcją log tylko przy deny (nie logować wszystkich permit),
wysyłanie logów na prosty serwer syslog – może to być nawet mały Linux/VM z darmowym oprogramowaniem,
okresowy przegląd – raz na kwartał przejrzeć, które reguły nic nie łapią (kandydaci do usunięcia).
Przy dobrze opisanych ACL-ach (komentarze w konfiguracji) łatwiej wtedy decydować, co wyrzucić, a co zostawić. Koszt: kilkanaście minut co parę miesięcy. Zysk: mniej śmieci w polityce i mniejsza szansa na „historyczne wyjątki” otwierające za dużo.
Dokumentowanie i wersjonowanie ACL w małych środowiskach
Duże firmy mają CMDB i systemy zarządzania konfiguracją. W mniejszych realiach kończy się na notatniku admina albo pliku „config-final-v2-na-pewno.txt”. Da się to ogarnąć niewielkim nakładem sił:
trzymać konfiguracje urządzeń (przynajmniej ich fragmenty z ACL) w repozytorium Git lub na dysku sieciowym z wersjonowaniem,
w komentarzach przy listach dopisywać cel i datę zmiany,
przy większych modyfikacjach dopisać krótki opis „co, po co i dla kogo”.
Przykład komentarzy bez przesady:
ip access-list extended BIURO-DO-SERWEROW
remark Dostęp z biura do serwerów aplikacyjnych (RDP/HTTPS)
remark 2025-01-15: dodano RDP dla działu księgowości
permit tcp 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255 eq 3389
permit tcp 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255 eq 443
deny ip any any
Po pół roku taka drobna dyscyplina oszczędza godziny grzebania w historii maili i zgadywania „kto to dodał i po co”. Dla jednoosobowego IT to też rodzaj notatnika, który nie ginie przy zmianie laptopa.
Stopniowa migracja z „płaskiej” sieci do segmentacji z ACL
Większość budżetowych sieci startuje jako „jeden wielki VLAN” – wszystko z wszystkim. Całkowite przepisanie w jeden weekend kończy się zwykle lawiną zgłoszeń. Bezpieczniejsza i tańsza w nerwach jest migracja etapami:
Etap 1 – inwentaryzacja: zebrać listę podstawowych systemów i tego, skąd są używane (użytkownicy, goście, VPN).
Etap 2 – pierwszy podział VLAN: wydzielić GOSCIE i IoT, resztę zostawić w jednym VLAN-ie BIURO.
Etap 3 – twarde ACL dla GOSCIE/IoT: blokada dostępu do BIURO i SERWERY, tylko Internet oraz pojedyncze, udokumentowane wyjątki.
Etap 4 – podział BIURO na 2–3 strefy: np. KADRY/FINANSE, RESZTA, ADMIN – z ACL opartymi na macierzy ruchu.
Na każdym etapie da się zatrzymać na dłużej, jeśli brakuje czasu lub zasobów. Kluczowe, by nie mnożyć skomplikowanych ACL w starym, płaskim VLAN-ie, tylko przy okazji porządków „wycinać” kolejne grupy do nowych segmentów z czytelną polityką.
Najczęściej zadawane pytania (FAQ)
Co to jest ACL na routerze lub switchu i do czego służy?
ACL (Access Control List, lista kontroli dostępu) to zestaw reguł na routerze lub switchu L3, który decyduje, jaki ruch IP może przejść przez dany interfejs, a jaki ma zostać zablokowany. Reguły sprawdzają m.in. adres źródłowy i docelowy IP, protokół (TCP/UDP/ICMP) oraz porty, a następnie wykonują akcję permit (przepuść) lub deny (zablokuj).
W praktyce ACL pozwala wymusić separację między VLAN-ami, ograniczyć dostęp do serwerów krytycznych, przyciąć uprawnienia sieci gościnnej czy zabezpieczyć interfejs WAN przed „szperaniem” z Internetu. To proste narzędzie, ale przy rozsądnym projekcie znacząco podnosi poziom bezpieczeństwa bez dokładania nowego sprzętu.
Czym ACL różni się od firewalla i czego ACL nie załatwi?
ACL to filtr pakietów na poziomie sieciowym. Nie analizuje treści aplikacyjnej, nie rozumie kontekstu użytkownika ani sesji, nie zrobi zaawansowanego IPS/IDS. Firewall nowej generacji potrafi np. rozpoznać aplikację (YouTube, Teams, DNS over HTTPS), filtrować po użytkownikach z AD, skanować pliki – ACL tego nie potrafi.
ACL natomiast wygrywa prostotą i przewidywalnością. Idealnie nadaje się do:
odcinania niepotrzebnych ścieżek między VLAN-ami,
zamykania dostępu do portów zarządczych,
ograniczania ruchu tylko do kilku wymaganych usług.
Nie zastąpi pełnego firewalla, ale w małej lub średniej sieci potrafi „załatwić” 70–80% najpilniejszych problemów bezpieczeństwa praktycznie bez kosztów sprzętowych.
Gdzie najlepiej zastosować ACL, żeby był największy efekt przy małym wysiłku?
Największy zwrot z czasu poświęconego na konfigurację ACL zwykle dają cztery miejsca:
Interfejs WAN – zablokowanie dostępu z Internetu do usług zarządczych routera, pozostawienie tylko portów absolutnie niezbędnych (np. 443 do VPN).
Gateway VLAN-ów wrażliwych – interfejsy SVI dla sieci serwerów, finansów czy IoT; dopuszczasz tylko źródła i usługi, które faktycznie muszą tam wchodzić.
Podsieć administracyjna – ACL, która pozwala na SSH/RDP/SNMP/WebGUI tylko z określonej sieci adminów, a blokuje taki ruch z pozostałych VLAN-ów.
Sieci gościnne/BYOD – goście widzą tylko Internet (ew. DNS i gateway), a adresy prywatne poza wyjściem są „ucięte”.
Najczęściej jest to kilkanaście reguł, które redukują powierzchnię ataku znacznie bardziej niż kolejny drogi gadżet bezpieczeństwa.
Jak działa kolejność reguł w ACL i co oznacza „implicit deny any”?
Urządzenie sprawdza reguły ACL od góry do dołu. Pierwsza pasująca reguła decyduje o losie pakietu – dalsze wpisy są ignorowane. Dlatego selektywne deny muszą być umieszczone przed ogólnymi permit, inaczej nigdy się nie „odpalą”.
Na końcu każdej ACL istnieje ukryta reguła „deny any”. Jeśli pakiet nie zostanie dopasowany do żadnej wcześniejszej reguły, zostanie odrzucony. To oznacza, że ACL z samymi regułami deny i bez choć jednego permit zamienia dany interfejs w „czarną dziurę”. Dlatego przy projektowaniu najpierw planuje się, co ma być dozwolone, a dopiero potem dorzuca blokady szczegółowe.
Jaka jest różnica między ACL standardową a rozszerzoną i kiedy której użyć?
Standardowa ACL filtruje tylko po adresie źródłowym IP. Nadaje się do najprostszych zastosowań, np. „ta podsieć może przechodzić przez router”, ale już nie odróżni ruchu HTTP od RDP. Rozszerzona ACL pozwala filtrować po adresie źródłowym i docelowym, protokole (TCP/UDP/ICMP itp.) oraz numerach portów – np. „VLAN biurowy może tylko HTTP/HTTPS do Internetu, ale bez RDP i SMB do serwerów”.
W praktyce:
standardowe ACL – do prostych, statycznych filtrów „kto w ogóle może przejść”,
rozszerzone ACL – do kontroli konkretnych usług, segmentacji VLAN-ów, ochrony serwerów i WAN.
W nowoczesnych sieciach większość sensownych polityk bezpieczeństwa wymaga już ACL rozszerzonych.
Czym się różni ACL inbound od outbound i co jest lepsze na start?
ACL inbound filtruje ruch wchodzący na interfejs, zanim zostanie zrouterowany. To dobre miejsce, aby od razu odrzucić niechciane pakiety przy wejściu (np. skanowanie portów z Internetu na interfejsie WAN). ACL outbound działa na ruchu wychodzącym z interfejsu – po decyzji routingu, tuż przed wysłaniem pakietu dalej.
Na początek prościej jest zwykle myśleć „od strony źródła” i stosować ACL inbound tam, gdzie to możliwe – ogranicza to zbędne przetwarzanie pakietów w urządzeniu. Zdarza się jednak, że z powodów organizacyjnych lub technicznych wygodniej jest filtrować outbound (np. ruch wychodzący z VLAN-u serwerów na inne sieci). Warto wybrać ten wariant, który minimalizuje liczbę reguł i ułatwia ci testowanie.
Czy ACL wystarczy do zabezpieczenia małej firmowej sieci bez kupowania firewalla?
W wielu małych i średnich sieciach dobrze zaprojektowany zestaw ACL na routerze i ewentualnie switchu L3 rozwiązuje większość realnych problemów: pełną widoczność między VLAN-ami, brak ograniczeń do serwerów krytycznych, otwarty interfejs WAN czy dostęp do usług zarządczych z „całego świata”.
Jeśli budżet jest napięty, rozsądne podejście to:
najpierw wyegzekwować zasadę minimum uprawnień za pomocą ACL w kluczowych punktach,
dopiero potem, gdy pojawią się środki i potrzeby (np. inspekcja ruchu, ochrona przed malware), dołożyć wyspecjalizowany firewall NGFW.
Wiele firm po wdrożeniu kilku logicznych ACL odkrywa, że najpilniejsze dziury dało się załatać bez nowych urządzeń i licencji.
Najważniejsze punkty
ACL to prosty filtr pakietów na routerze lub switchu, który bazując na adresach, protokołach i portach decyduje o przepuszczeniu lub zablokowaniu ruchu, ale nie zastępuje zaawansowanych firewalli czy systemów IDS/IPS.
Dobrze zaprojektowane ACL-e potrafią znacząco podnieść bezpieczeństwo w małych i średnich sieciach bez inwestowania w nowy sprzęt – kilka precyzyjnych reguł często usuwa większość realnych problemów.
ACL idealnie nadają się do egzekwowania zasady minimum uprawnień w sieci: każdy VLAN, host czy typ urządzeń dostaje tylko te połączenia, które są mu niezbędne (np. IoT tylko do MQTT i DNS, goście tylko do Internetu).
Największy zwrot z czasu administratora dają ACL-e na interfejsie WAN, gatewayach VLAN-ów wrażliwych, dla ruchu zarządczego oraz w sieciach gościnnych/BYOD – te cztery miejsca często „czyszczą” najpoważniejsze luki.
Typowe bolączki, jak pełna widoczność między VLAN-ami, brak ograniczeń do serwerów krytycznych czy dostęp do zarządzania z całego LAN, można rozwiązać samymi ACL-ami, bez dokupowania licencji i urządzeń UTM.
Standardowe ACL-e filtrują jedynie po adresie źródłowym, natomiast rozszerzone pozwalają precyzyjnie określać źródło, cel, protokół i porty, dzięki czemu da się bardzo dokładnie zdefiniować „kto, do czego i po czym może się łączyć”.
Stosowanie nazwanych ACL zamiast numerowanych ułatwia utrzymanie i dokumentację (np. „ACL-GOSCIE”, „ACL-SERWERY”), co przyspiesza wdrożenia i ogranicza koszt błędów konfiguracyjnych.
