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.

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.

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.

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.

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ą ACL ruchu, który powinien być priorytetyzowany za pomocą mechanizmu 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.

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.

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ą:

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.

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ą:

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. To jednak nie wszystko, istnieją jeszcze 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!