Więcej

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

    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

    6 KOMENTARZE

    guest
    6 - Ilość komentarzy
    Sortuj wg najstarszych
    Sortuj wg najnowszych Sortuj wg najlepszych
    Inline Feedbacks
    View all comments
    cyberwektor

    Panowie, jestem pod wrażeniem ogromu pracy włożonej w tworzenie NSS. Wysoce specjalistyczna wiedza prezentowana na stronie, z oczywistych względów będzie przyciągać o wiele mniej czytelników od tych miejsc skierowanych do masowego odbiorcy (potwierdzeniem czego są prezentowane comiesięczne podsumowania i statystyki). I tutaj moja propozycja, proszę zastanowić się nad gościnnym wpisem na jakiejś popularnej platformie blogowej (np. dobreprogramy.pl), który napędzi nowych czytelników i pasjonatów sieci komputerowych. Można też dodać znalezisko na Wykopie, które zwiększy aktywność na Panów stronie. Każdy chyba słyszał o \”Wkop efekt\”, czyli zjawisku polegającym na przekroczeniu dopuszczalnej przepustowości danego serwera w wyniku aktywności Wykopowiczów. Ważne jest aby nie zapomnieć dobrze otagować dodane znalezisko.

    Rafal

    Cześć,
    Na samym końcu tekstu dot. rozszerzonych ACL do poprawy nr. interfejsu z Gi 0/1 na 0/2 🙂
    \”Router1(config)#interface Gi 0/1\”

    Pozdrawiam!

    Monika

    Czy tutaj Router1(config)#access-list 100 permit tcp host 10.0.1.100 host 192.168.1.2 …
    w hoście źródłowym nie wkradł się przypadkiem błąd? Powinno chyba być
    Router1(config)#access-list 100 permit tcp host 10.0.2 .100 host 192.168.1.2 …

    Sprawdź swoją wiedzę z CCNA

    Otrzymuj nasz cotygodniowy mailing "Czwartest" i sprawdź swoją wiedzę rozwiązując wyzywające zadania z zakresu certyfikacji CCNA. Dasz radę?

    Uzupełniając powyższe pole wyrażasz zgodę na otrzymywanie od GetGoodNet Damian Michalak z siedzibą we Wrocławiu newslettera zawierającego treści edukacyjne. Zgodę możesz wycofać w każdym czasie.

    NSS na Social Media

    1,611FaniLubię
    72ObserwującyObserwuj
    133ObserwującyObserwuj
    1,220SubskrybującySubskrybuj

    Najnowsze artykuły

    spot_img

    Może Cię też zainteresować...

    6
    0
    Co sądzisz na temat tej publikacji? Zostaw proszę komentarzx
    ()
    x