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.

Przykładowa topologia
Przykładowa topologia

Załóżmy, że administratorem sieci jest Host B i tylko ten host może uzyskiwać jakikolwiek dostęp do Routera 2. W takiej sytuacji wykorzystamy VTY ACL, która może wyglądać tak:

Router2(config)#access‐list 2 permit 10.0.2.100 0.0.0.0  

Listę tą aplikujemy inbound na liniach VTY za pomocą komendy access-class:

Router2(config)#line vty 0 15
Router2(config‐line)#access‐class 2 in

Dzięki takiej konfiguracji jedynie Host B będzie w stanie zalogować się zdalnie na Router 2. To wszystko w temacie standard ACL. Spójrzmy teraz na działanie extended ACL.

Extended ACL

Extended ACL dzięki temu, że pozwalają na filtrowanie zarówno na podstawie warstwy 3. jak i 4. pozwalają nam na tworzenie znacznie bardziej granularnych wyrażeń. W extended ACL podajemy parametry w następującej kolejności:

  1. IP źródłowe
  2. Port źródłowy
  3. IP docelowe
  4. Port docelowy

W poprzednim scenariuszu zezwoliliśmy jedynie Hostowi B na dostęp do Routera 2. Przytnijmy teraz to jeszcze bardziej i zdefiniujmy dodatkowe wymaganie:

  • Host B ma mieć możliwość jedynie Telnetowania się do Routera 2
  • Cały pozostały ruch ma być dropowany

Po raz kolejny posłużymy się naszą topologią:

Przykładowa topologia
Przykładowa topologia

Zanim przejdziemy do pisania naszej extended ACL zwróć proszę uwagę na bardzo ważną zasadę:

Extended ACL powinny być zawsze umieszczane możliwie jak najbliżej sieci źródłowej dla komunikacji, którą mają filtrować.

Ta ACL powinna być zatem umieszczona na Routerze 1, na porcie Gi0/2. Przejdźmy do konfiguracji ACL. Wiemy już, że ACL extended zaczynają się od numeru 100 i wymagana będzie akcja permit:

Router1(config)#access‐list 100 permit ?

Ponieważ mamy do czynienia z extended ACL to mamy teraz możliwość wyboru protokołu, który nas interesuje. Telnet wykorzystuje TCP zatem wybieramy TCP:

Router1(config)#access-list 100 permit ?
<0-255> An IP protocol number
ahp Authentication Header Protocol
eigrp Cisco's EIGRP routing protocol
esp Encapsulation Security Payload
gre Cisco's GRE tunneling
icmp Internet Control Message Protocol
igmp Internet Gateway Message Protocol
ip Any Internet Protocol
ipinip IP in IP tunneling
nos KA9Q NOS compatible IP over IP tunneling
ospf OSPF routing protocol
pcp Payload Compression Protocol
pim Protocol Independent Multicast
tcp Transmission Control Protocol
udp User Datagram Protocol

Następnie mamy do wyboru następujące opcje:

Router1(config)#access-list 100 permit tcp ?
A.B.C.D Source address
any Any source host
host A single source host

Naszym hostem źródłowym jest Host B więc musimy go podać. Moglibyśmy podać jako następny argument adres IP z maską wildcard (10.0.2.100 0.0.0.0), ale IOS nam trochę ułatwia życie dzięki możliwości użycia słowa kluczowego „host”. Sprawdźmy co dalej:

Router1(config)#access-list 100 permit tcp host 10.0.2.100 ? 
A.B.C.D Destination address
any Any destination host
eq Match only packets on a given port number
gt Match only packets with a greater port number
host A single destination host
lt Match only packets with a lower port number
neq Match only packets not on a given port number
range Match only packets in the range of port numbers

Mamy teraz możliwość podania portu/portów źródłowych. Jest to opcja, którą używa się stosunkowo rzadko ponieważ porty źródłowe w większości wypadków są losowe (ephemeral ports). Przechodzimy zatem prosto do podania adresu docelowego. Tutaj również przyda nam się słówko kluczowe „host”:

Router1(config)#access-list 100 permit tcp host 10.0.2.100 host 192.168.1.2 ? 
  ack          Match on the ACK bit
  dscp         Match packets with given dscp value
  eq           Match only packets on a given port number
  established  Match established connections
  fin          Match on the FIN bit
  fragments    Check non‐initial fragments
  gt           Match only packets with a greater port number
  log          Log matches against this entry
  log‐input    Log matches against this entry, including input interface
  lt           Match only packets with a lower port number
  neq          Match only packets not on a given port number
  precedence   Match packets with given precedence value
  psh          Match on the PSH bit
  range        Match only packets in the range of port numbers
  rst          Match on the RST bit
  syn          Match on the SYN bit
  time‐range   Specify a time‐range
  tos          Match packets with given TOS value
  urg          Match on the URG bit

Kolejna potężna dawka granularności! Chcemy zezwolić jedynie dostęp po Telnecie, zatem użyjemy słówka kluczowego „eq”, po którym należy podać numer portu. Nasza pełna komenda będzie zatem wyglądać następująco:

Router1(config)#access-list 100 permit tcp host 10.0.2.100 host 192.168.1.2 eq 23 

Wyświetlmy ACL na naszym routerze:

Router1#show access‐lists 
Extended IP access list 100 
    10 permit tcp host 10.0.2.100 host 192.168.1.2 eq telnet 

Pozostaje nam zaaplikować extended ACL na interfejsie:

Router1(config)#interface Gi 0/2
Router1(config‐if)#ip access‐group 100 in 

Iiii… gotowe! Mamy za sobą konfigurację extended ACL 🙂

Temat dotyczący ACL jest bardzo rozległy. Celem tego artykułu było przede wszystkim wytłumaczenie czym są Access Listy i jak działają w najbardziej podstawowych odmianach. Przyjdzie jeszcze czas na dodatkowe komponenty tej zabawy: tworzenie ACL za pomocą edytora w IOS, tworzenie Named ACL, VACL… dużo by wymieniać. Mam nadzieję, że ten artykuł dostarczył Ci wartości!

O jakim temacie byś najchętniej przeczytał/a na naszej stronie w jednym z kolejnych artykułów? 🙂

🗳 Jak przydatna była ta publikacja?

Średnia ocena 5 / 5. Ilość głosów: 24

Brak ocen. Bądź pierwszy!

Dziękujemy za ocenę! Zapraszamy Cię do obserwowania NSS w mediach społecznościowych!

Przykro nam, że ta publikacja okazała się być dla Ciebie nieprzydatna!

Uwaga: Twój głos będzie liczony tylko jeśli udzielisz feedbacku używając formularza poniżej.

Jak możemy poprawić tę publikację?

Damian Michalak
Network Consultant, Twórca Na Styku Sieci