Jak działają Access Control Lists (standard oraz extended)?

Dobrze skonfigurowana sieć to podstawa. Samo zadbanie o kwestie takie jak routing, monitoring czy też zarządzanie to jednak za mało – trzeba również położyć nacisk na bezpieczeństwo. Jak możemy zatem zabezpieczyć sieć? Podstawowym narzędziem używanym przez sieciowców są Listy Kontroli Dostępu i to właśnie o nich dzisiaj porozmawiamy.

Na wstępie chciałbym poruszyć kwestię jezykową. Wiele sieciowych terminów ma swoje polskie odpowiedniki i nie inaczej jest w tym przypadku. Access Control Lists (ACL) tłumaczymy po prostu jako Listy Kontroli Dostępu. Pomimo to, będę w tym artykule posługiwał się angielskim nazewnictwem bo to właśnie ono jest najczęściej używane w codziennej pracy. Po tym krótkim wstępie zagłębijmy się w niuanse działania ACL.

Zastosowanie ACL

Access Control Listy są integralną częścią IOSa i znajdziemy je niemal w każdej wersji tego systemu. Stanowią one podstawowy mechanizm bezpieczeństwa w sieci, ale i zastosowanie może być znacznie szersze. ACL mają dwa główne zastosowania:

Pierwsze zastosowanie ACL: filtrowanie ruchu

ACL używane są przede wszystkim do filtrowania ruchu. Z domyślnie skonfigurowanym routingiem mamy pełną komunikację w sieci w zakresie podsieci znajdujących się w tablicy routingu. Istnieją natomiast konkretne scenariusze, w których byśmy chcieli ograniczyć dostęp do pewnych obszarów w sieci. Przykładowo, będąc podłączonymi do Internetu byłoby rozsądnie domyślnie odrzucać wszystkie przychodzące stamtąd pakiety, a akceptować tylko te pożądane.

Filtrowanie na styku z internetem
Filtrowanie na styku z internetem

W przypadku filtrowania, ACL jako mechanizm kontrolny możemy umieścić w trzech miejscach:

inbound ACL

ACL może być zaaplikowana inbound, czyli na interfejsie wejściowym urządzenia sieciowego. W takim przypadku filtrowanie następuje jeszcze zanim pakiet zostanie przekazany do procesu switchingu i routingu.

Inbound ACL
Inbound ACL

outbound ACL

ACL może być zaaplikowana outbound, czyli na interfejsie wyjściowym urządzenia sieciowego. W takim przypadku filtrowanie następuje już po przełączeniu pakietu i po podjęciu wszelkich decyzji związanych z routingiem.

Outbound ACL
Outbound ACL

VTY ACL

ACL może być zaaplikowana do linii VTY, czyli do wirtualnego interfejsu, które urządzenia sieciowe wykorzystują do obsługiwania połączeń telnet oraz SSH. Takie zastosowanie ACL świetnie się sprawdza do zabezpieczania dostępu administracyjnego do urządzeń sieciowych.

VTY ACL

Drugie zastosowanie ACL: klasyfikacja ruchu

Bardzo powszechne jest również wykorzystanie ACL do klasyfikowania ruchu. Jak później zobaczymy, możemy ACL z powodzeniem wykorzystywać np. do określania ruchu, który powinien być transportowany za pośrednictwem tunelu VPN. 

Innym przykładem klasyfikacji może być np wybieranie za pomocą ALC ruchu, który powinien być priorytetyzowany za pomocą mechanzimu QoS.

Wiemy już jakie są dwa główne zastosowania ACL. Przyjrzyjmy się teraz temu jak ACL wyglądają i jak działają.

Działanie ACL

Aby zrozumieć jak działają ACL najlepiej spojrzeć na to jak taka przykładowa ACL wygląda. Skonfigurowane w systemie IOS ACL możemy wyświetlić za pomocą komendy show access-lists:

 Router#show access‐lists
Standard IP access list 1
10 permit 10.0.0.0, wildcard bits 0.255.255.255
20 permit 172.16.0.0, wildcard bits 0.15.255.255
30 permit 192.168.0.0, wildcard bits 0.0.255.255

Jak sama nazwa wskazuje, Access Control List to lista. Widzimy powyżej, że mamy do czynienia z ACL numer 1 oraz, że jest ona typu standard. O typach ACL porozmawiamy już za chwilę. Nasza przykładowa ACL posiada trzy wyrażenia (ang. statements) i są one w tym przypadku ponumerowane 10, 20 oraz 30.

Każde wyrażenie zaczyna się od słowa określającego akcję, która powinna zostać wykonana na pakiecie pasującym do wpisu. Tutaj mamy trzy wyrażenia “permit”, zatem jeżeli pakiet porównywany z ACL będzie pasował do któregokolwiek z naszych trzech wyrażeń to:

  • zostanie on przepuszczony i będzie procesowany dalej jeśli ta ACL była używana do filtrowania ruchu
  • zostanie on zaklasyfikowany jako pakiet, który powinien zostać poddany priorytetyzacji jeśli ta ACL była używana do klasyfikacji QoS

Drugim możliwym wyrażeniem jest “deny” czyli odrzucenie pakietu.

A co jeżeli pakiet nie będzie pasował do żadnego z trzech wyrażeń? Każda ACL posiada na koniec domyślną akcję odrzucającą pakiety, które nie spełniają kryteriów. Jest to tzw. implicit deny i nie jest on wyświetlany (trzeba go zapamiętać!).

Kolejną ważną do zapamiętania zasadą jest to, że ACL przeglądane są od góry do dołu (ang. top-down). Jeżeli dany pakiet zostanie zatem dopasowany np. do wyrażenia nr 20 to procesowanie ACL zakończy się na tym wyrażeniu.

Na koniec tego podrozdziału przyjrzyjmy się bliżej samym wyrażeniom. Weźmy na warsztat np. tę linijkę:

10 permit 10.0.0.0, wildcard bits 0.255.255.255

Mamy tutaj do czynienia z maską sieciową typu wildcard. Jest to tzw. odwrócona maska (gdzieś kiedyś spotkałem się z tłumaczeniem “dzika maska”… don’t do it). Aby ją przekonwertować na “zwykłą” maskę sieciową należy odjąć wartości poszczególnych oktetów maski wildcard od liczby 255. Będzie to zatem:

(255-0).(255-255).(255-255).(255-255) – zatem zwykła maska to 255.0.0.0

Moglibyśmy więc rozpatrywać wyrażenie numer 10 jako:

10 permit 10.0.0.0 255.0.0.0

Wyrażenie to możemy zatem zrozumieć następująco:

dopuść/zaklasyfikuj (permit) wszystkie pakiety posiadające w pierwszym oktecie adresu IP wartość “10”. Wyrażenie to dopuszcza więc wszystkie prywatne IP klasy A 🙂

Pozostało tylko odpowiedzieć na pytanie “jakie IP?”. Źródłowe czy docelowe? W tym przypadku będą to adresy IP źródłowe (source). Wiemy to stąd, że nasza przykładowa ACL jest typu standard:

Router#show access‐lists
Standard IP access list 1
10 permit 10.0.0.0, wildcard bits 0.255.255.255
20 permit 172.16.0.0, wildcard bits 0.15.255.255
30 permit 192.168.0.0, wildcard bits 0.0.255.255

Ale co to w zasadzie oznacza? Już spieszę z odpowiedzią

Różnica między standard ACL a extended ACL

Access Control Listy występują w dwóch odmianach: standardowe (ang. standard) oraz rozszerzone (ang. extended).

Działanie standard ACL

Standard ACL są bardzo proste w swojej konstrukcji ponieważ sprawdzają one jedynie źródłowy adres IP pakietu i podejmują decyzję o filtrowaniu/klasyfikacji pakietu tylko na podstawie tego jednego paramteru. Mamy tu więc do czynienia z filtrowaniem na poziomie warstwy 3 modelu OSI.

Standard ACL
Standard ACL

Działanie extended ACL

Extended ACL są o wiele bardziej granularne ponieważ podejmują decyzję o filtrowaniu/klasyfikacji pakietu na podstawie:

  • adresu źródłowego IP
  • adresu docelowego IP
  • portu źródłowego
  • portu docelowego

Widzimy zatem, że mamy tu do czynienia z filtrowaniem na poziomie warstwy trzeciej i czwartej modelu OSI.

Extended ACL
Extended ACL

Jak określić czy ACL jest standard czy extended?

W jaki sposób możemy stwierdzić czy dana ACL jest typu standard czy extended? Określamy to na podstawie numeru ACL:

  • Standard: 1-99 lub 1300-1999
  • Extended 100-199 lub 2000-2699

Właśnie między innymi po numerze mogliśmy określić, że przykładowa ACL w paragrafie 2. była typu standard:

Router#show access‐lists
Standard IP access list 1
10 permit 10.0.0.0, wildcard bits 0.255.255.255
20 permit 172.16.0.0, wildcard bits 0.15.255.255
30 permit 192.168.0.0, wildcard bits 0.0.255.255

Standard ACL

Rozważmy teraz działanie standard ACL na przykładzie. Będziemy się posługiwać następującą topologią:

Przykładowa topologia
Przykładowa topologia

Zakładamy, że routing statyczny jest poprawnie skonfigurowany oraz, że host C może być spingowany z hosta A i B.

Skonfigurujmy teraz standard ACL na routerze 2:

Router2(config)#access‐list 1 permit 10.0.1.0 0.0.0.255 

Powyższa ACL będzie odpowiadała za dopuszczanie ruchu jedynie z subnetu 10.0.1.0/24, w którym to znajduje się host A.

W następnym kroku musimy tę ACL zaaplikować na interfejsie Routera 2. Dlaczego akurat na Routerze 2? I na którym interfejsie? Generalna zasada dotycząca stosowania standard ACL jest następująca:

Standard ACL powinny być zawsze umieszczane możliwie jak najbliżej sieci docelowej dla komunikacji, którą mają filtrować. Ponieważ standard ACL filtrują na podstawie jedynie źródłowego adresu IP to powinny być umieszczane na interfejsie wejściowym urządzenia sieciowego.

Naszą ACL zaaplikujemy zatem na interfejsie Fa0/1 Routera 2. Wykorzystujemy w tym celu komendę ip access-group podając jako parametr numer ACL oraz kierunek (w tym przypadku in, czyli inbound):

Router2(config)#interface fastEthernet 0/1
Router2(config‐if)#ip access‐group 1 in

Możemy zweryfikować czy na danym interfejsie są zapięte jakieś ACL za pomocą komendy show ip interface:

Router2#show ip interface fastEthernet 0/1 
FastEthernet0/1 is up, line protocol is up
Internet address is 192.168.1.2/24
Broadcast address is 255.255.255.255
Address determined by setup command
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Outgoing access list is not set
Inbound access list is 1

Możemy teraz zweryfikować czy host A jest w stanie spingować hosta C (jako hosty używam routery z bardzo podstawową konfiguracją, stąd też taki a nie inny output z pingowania):

HostA#ping 10.0.3.100

Type escape sequence to abort.
Sending 5, 100‐byte ICMP Echos to 10.0.3.100, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round‐trip min/avg/max = 3/3/3 ms

Sprawdźmy również, czy host B może spingować hosta C:

HostB#ping 10.0.3.100

Type escape sequence to abort.
Sending 5, 100‐byte ICMP Echos to 10.0.3.100, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)

Tym razem próba się kończy niepowodzeniem, a to dlatego, że nasza ACL na Routerze 2 dopuszcza na interfejsie jedynie ruch przychodzący z sieci 10.0.1.0/24. Ping z hosta B znajdującego się w 10.0.2.0/24 wpada zatem w implicit deny.

Możemy sprawdzić czy ACL działa oraz ile pakietów zostało przez nią dopasowanych do wyrażeń w ACL za pomocą komendy show access-lists:

Router2#show access‐lists 
Standard IP access list 1
10 permit 10.0.1.0, wildcard bits 0.0.0.255 (27 matches)

UWAGA: W tym scenariuszu używamy static routing więc nasza ACL nie powoduje problemów. Natomiast gdybyśmy używali któryś z dynamicznych protokołów routingu to zaaplikowana przez nas ACL „wycięłaby” nam routing między Routerem 1 a Routerem 2. Zalecana ostrożność!

Na koniec tego rozdziału jeszcze jeden krótki przykład.