artykuły

Powrót do listy artykułów

Temat artykułu: Jak zoptymalizować ACLkę ?
Tekst napisał Cisco_FAQ dnia 07-03-2006

Nie jest to pytanie proste, ale spróbujmy na nie zgrubnie odpowiedzieć.

Na początek warto wiedzieć, że ACLki z dodanym słowem kluczowym log (czyli logujące trafienie), powodują przejście procesora routera w tryb process switching. Dla dużego ruchu, korzyści z wykorzystania innych optymalizacji, w tym optymalniejszych ścieżek komutacji, zostają w tym momencie zniweczone.

Po pierwsze, dla długich ACLek (od 6 wpisów i więcej), w niektórych IOSach (od 12.0(6) linii S, oraz od 12.3 dla niektórych routerów mniejszych) istnieje możliwość pre-kompilowania reguł w kod optymalniejszy do testowania na każdym pakiecie. Funkcjonalność ta nazywa się Turbo Access List (Cisco używa jej zamiennie z compiled Access List i jako takie pojawiają się w słowach kluczowych konfiguracji routera) i włącza się ją poleceniem `access-list compiled'. Router wykona w tym momencie proces optymalizacji ACLek dłuższych niż 5 reguł, a później przy każdej zmianie w ACLkach, powtórzy ten proces. Skuteczność działania tej funkcji, oraz listę ACLek które zostały skompilowane można sprawdzić poleceniem `show access-lists compiled':

router# show access-lists compiled
Compiled ACL statistics:
ACL         State        Entries  Config  Fragment  Redundant
10          Operational      1        1         0         0
98          Operational      1        1         0         0
99          Operational      7        7         0         0
100         Operational      2        2         0         0
110         Operational     14       12         2         0
antispoof   Operational     42       43         0         1
block_mswin Operational     14       14         0         0
nachi_worm  Operational      3        2         1         0
8 ACLs, 8 active, 1 builds, 89 entries, 3 mem fill, 762 updates
  L0: 1805Kb    5/6     42/43    11/12     2/3      2/3     13/14    14/15     4/5
  L1:    9Kb   67/250   11/36    13/42    15/75
  L2:   55Kb   69/350  105/300
  L3:  217Kb  337/500
Misc:   30Kb
Totl: 2119Kb  710 equivs (617 dynamic)

Należy pamiętać, że wykorzystanie tej funkcjonalności pochłonie trochę pamięci (w zależności od ilości i wielkości istniejących i tworzonych list), jednak w zamian za to, każdy pakiet zostanie sprawdzony najwyżej pięć razy (dla list rozszerzonych) - adres źródłowy, adres docelowy, protokół, opcje protokołu - i wynik, powodujący przejście do przetwarzania następnego pakietu. Funkcjonalność tą opisano szerzej pod tym adresem: http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120s/120s6/turboacl.htm.

Po drugie, staraj się ograniczyć liczbę reguł, zawierając w poszczególnych warunkach jak najogólniejsze stwierdzenia (jeśli nie powoduje to oczywiście przepuszczania niechcianego ruchu). Innymi słowy, na przykład zamiast wpisać ACLkę z 254 wpisami typu permit ip 192.168.0.1, permit ip 192.168.0.2, permit ip 192.168.0.3 zastosuj jeden wpis w ramach listy rozszerzonej, który będzie brzmiał permit ip 192.168.0.0 0.0.0.255 any.

Po trzecie, przemyśl konstrukcję ACLki starając się ocenić, jaki ruch najczęściej będzie docierał do Twojego routera - i jak najwcześniej w liście reguł akceptuj go lub odrzucaj. Pomocne jest w tym momencie polecenie `show ip access-lists'. Przeanalizujmy taką ACLkę:

     10 permit ip host 169.254.10.1 host 169.254.9.4
     20 permit gre any host 169.254.20.6
     30 permit udp host 150.254.183.15 eq ntp host 169.254.9.4 eq ntp (11460 matches)
     40 deny ip 192.168.0.0 0.0.255.255 any (9865451 matches)
     50 deny ip 173.0.0.0 0.255.255.255 any (124 matches)
     60 deny ip 10.0.0.0 0.255.255.255 any
     70 deny ip 172.16.0.0 0.15.255.255 any (42 matches)
     80 deny ip 0.0.0.0 1.255.255.255 any
     90 deny ip 2.0.0.0 0.255.255.255 any
    100 deny ip 5.0.0.0 0.255.255.255 any
    110 deny ip 7.0.0.0 0.255.255.255 any
    120 deny ip 23.0.0.0 0.255.255.255 any (847618 matches)
    130 deny ip 27.0.0.0 0.255.255.255 any
    140 deny ip 31.0.0.0 0.255.255.255 any
    150 deny ip 36.0.0.0 1.255.255.255 any
    160 deny ip 39.0.0.0 0.255.255.255 any
    170 deny ip 41.0.0.0 0.255.255.255 any
    180 deny ip 42.0.0.0 0.255.255.255 any
    190 deny ip 49.0.0.0 0.255.255.255 any
    200 deny ip 50.0.0.0 0.255.255.255 any
    210 deny ip 58.0.0.0 1.255.255.255 any (749 matches)
    220 deny ip 70.0.0.0 1.255.255.255 any
    230 deny ip 72.0.0.0 7.255.255.255 any (6 matches)
    250 deny ip 88.0.0.0 7.255.255.255 any
    260 deny ip 169.254.0.0 0.0.255.255 any
    270 deny ip 174.0.0.0 1.255.255.255 any
    280 deny ip 176.0.0.0 7.255.255.255 any
    290 deny ip 184.0.0.0 3.255.255.255 any
    300 deny ip 189.0.0.0 0.255.255.255 any
    310 deny ip 190.0.0.0 0.255.255.255 any
    320 deny ip 192.0.2.0 0.0.0.255 any
    330 deny ip 197.0.0.0 0.255.255.255 any
    340 deny ip 198.18.0.0 0.1.255.255 any
    350 deny ip 223.0.0.0 0.255.255.255 any
    360 deny tcp any any range 135 139 (138750 matches)
    370 deny ip 96.0.0.0 31.255.255.255 any (6974 matches)
    380 deny udp any any range 135 netbios-ss (79235152 matches)
    390 deny tcp any range 135 139 any (8371 matches)
    400 deny udp any range 135 netbios-ss any

Widać od razu, że reguła pasująca do zdecydowanie największej ilości pakietów (nr. 380, 79,235,152 trafienia) znajduje się na szarym końcu - jest sprawdzana dopiero 38. Powoduje to niewielkie, ale jednak opóźnienia i oczywiście przyczyna się do zwiększonego obciążenia na routerze (pamiętaj, że ACLka przeglądana jest za każdym razem, gdy do interfejsu dotrze, lub ma go opuścić pakiet!). Porządkując listę według trafień otrzymamy coś takiego:

     10 deny udp any any range 135 netbios-ss (79235152 matches)
     20 deny ip 192.168.0.0 0.0.255.255 any (9865451 matches)
     30 deny ip 23.0.0.0 0.255.255.255 any (847618 matches)
     40 deny tcp any any range 135 139 (138750 matches)
     50 permit udp host 150.254.183.15 eq ntp host 169.254.9.4 eq ntp (11460 matches)
     60 deny tcp any range 135 139 any (8371 matches)
     70 deny ip 96.0.0.0 31.255.255.255 any (6974 matches)
     80 permit ip host 169.254.10.1 host 169.254.9.4
     90 deny ip 58.0.0.0 1.255.255.255 any (749 matches)
    100 deny ip 173.0.0.0 0.255.255.255 any (124 matches)
    110 deny ip 172.16.0.0 0.15.255.255 any (42 matches)
    120 deny ip 72.0.0.0 7.255.255.255 any (6 matches)
    130 permit gre any host 169.254.20.6
    140 deny ip 10.0.0.0 0.255.255.255 any
    150 deny ip 0.0.0.0 1.255.255.255 any
    160 deny ip 2.0.0.0 0.255.255.255 any
    170 deny ip 5.0.0.0 0.255.255.255 any
    180 deny ip 7.0.0.0 0.255.255.255 any
    190 deny ip 27.0.0.0 0.255.255.255 any
    200 deny ip 31.0.0.0 0.255.255.255 any
    210 deny ip 36.0.0.0 1.255.255.255 any
    220 deny ip 39.0.0.0 0.255.255.255 any
    230 deny ip 41.0.0.0 0.255.255.255 any
    240 deny ip 42.0.0.0 0.255.255.255 any
    250 deny ip 49.0.0.0 0.255.255.255 any
    260 deny ip 50.0.0.0 0.255.255.255 any
    270 deny ip 70.0.0.0 1.255.255.255 any
    280 deny ip 88.0.0.0 7.255.255.255 any
    290 deny ip 169.254.0.0 0.0.255.255 any
    300 deny ip 174.0.0.0 1.255.255.255 any
    310 deny ip 176.0.0.0 7.255.255.255 any
    320 deny ip 184.0.0.0 3.255.255.255 any
    330 deny ip 189.0.0.0 0.255.255.255 any
    340 deny ip 190.0.0.0 0.255.255.255 any
    350 deny ip 192.0.2.0 0.0.0.255 any
    360 deny ip 197.0.0.0 0.255.255.255 any
    370 deny ip 198.18.0.0 0.1.255.255 any
    380 deny ip 223.0.0.0 0.255.255.255 any
    390 deny udp any range 135 netbios-ss any

Warto taką "optymalizację" przeprowadzić raz na jakiś czas - charakterystyki ruchu zmieniają się okresowo i coś co polepszyło sytuację pół miesiąca temu, może teraz ją pogarszać.

Po czwarte, w większości topologii w jakich router może się znaleźć, warto unikać filtrowania na interfejsie ruchu w obu kierunkach. Jeśli router posiada dwa interfejsy, to zakładając, że filtrujemy ruch wchodzący na obu interfejsach, nie trzeba już specjalnie sprawdzać ruchu wychodzącego drugim interfejsem - wiadomo, że przefiltrowaliśmy go już, gdy wchodził interfejsem pierwszym. Jeśli jednak wykonujesz routing, a jakiś ruch może być generowany z routera, być może będziesz musiał jednak coś filtrować - wszystko zależy od Twojej polityki bezpieczeństwa.

Po piąte, warto zastępować reguły odrzucające ruch do konkretnych adresów IP czy podsieci, statycznymi wpisami routingu wskazującymi na odpowiednio skonfigurowany interfejs Null 0. Routery dużo lepiej radzą sobie z routowaniem ruchu (nawet jeśli chodzi o routowanie do interfejsu będącego "czarną dziurą") niż jego filtrowaniem, czy wykonywaniem skomplikowanych operacji. Innymi słowy, po skonfigurowaniu wirtualnego interfejsu Null 0 w ten sposób:

interface Null0
 description Interfejs wyrzucający pakiety
 no ip unreachables

Wpisy w ACLce odrzucającej ruch w ten sposób:

    [...]
    deny ip 10.0.0.0 0.255.255.255 any
    deny ip 0.0.0.0 1.255.255.255 any
    deny ip 2.0.0.0 0.255.255.255 any
    deny ip 5.0.0.0 0.255.255.255 any
    deny ip 7.0.0.0 0.255.255.255 any
    deny ip 27.0.0.0 0.255.255.255 any
    deny ip 31.0.0.0 0.255.255.255 any
    deny ip 36.0.0.0 1.255.255.255 any
    deny ip 39.0.0.0 0.255.255.255 any
    deny ip 41.0.0.0 0.255.255.255 any
    [...]

Można zastąpić następującymi wpisami statycznymi routingu (zwróć jednak uwagę, by nie dopisać takiego filtrowania dla adresów sieci, które w twojej konkretnej instalacji występują!):

router# ip route 10.0.0.0 255.0.0.0 null 0
router# ip route 0.0.0.0 254.0.0.0 null 0

router# ip route 2.0.0.0 255.0.0.0 null 0
router# ip route 5.0.0.0 255.0.0.0 null 0
router# ip route 7.0.0.0 255.0.0.0 null 0
router# ip route 27.0.0.0 255.0.0.0 null 0
router# ip route 31.0.0.0 255.0.0.0 null 0
router# ip route 36.0.0.0 254.0.0.0 null 0

router# ip route 39.0.0.0 254.0.0.0 null 0
router# ip route 41.0.0.0 255.0.0.0 null 0

Po szóste i ostatnie, jeśli filtrujesz ruch na interfejsach wewnętrznych pod kątem poprawności adresów (tzn. nie chcesz, by ktoś w Twojej sieci 192.168.0.0/24 mógł wysyłać pakiety z adresem źródłowym np. 172.16.0.0/16), a masz lub możesz włączyć mechanizm CEF, możesz ACLkę w tej postaci:

ip access-list extended RuchLAN
 deny tcp any any range 135 139
 deny udp any any range 135 139
 deny tcp any range 135 139 any
 deny udp any range 135 netbios-ss any
 permit ip 192.168.0.0 0.0.0.255 any
 deny ip any any

...zmodyfikować do postaci:

ip access-list extended RuchLAN
 deny tcp any any range 135 139
 deny udp any any range 135 139
 deny tcp any range 135 139 any
 deny udp any range 135 netbios-ss any
 permit ip any any

A w zamian za to, włączyć na interfejsie do którego przypisana była ta ACLka, mechanizm uRPF, czyli unicast Reverse-Path-Filtering, w ten sposób:

router# ip cef
router# conf t
router(config)# interface FastEthernet 0

router(config-if)# ip verify unicast reverse-path

Jak to działa? uRPF opiera swoje działanie o tablicę budowaną przez CEF - FIB (ang. Forwarding Information Base). Po otrzymaniu przez router pakietu, przechodzi on następującą drogę:

Sprawdzana jest wejściowa ACLka przypisana do interfejsu.
uRPF sprawdza, czy droga powrotna dla pakietu wskazuje na interfejs, którym dotarł on do routera - jeśli nie, pakiet jest odrzucany
CEF sprawdza FIB, by wyznaczyć dalszą drogę dla pakietu (jeśli nie został odrzucony)
Na interfejsie, którym pakiet ma opuścić router, sprawdzana jest ACLka wyjściowa
Pakiet jest wysyłany przez interfejs.

Innymi słowy, załóżmy, że masz router z dwoma interfejsami - Ethernetowym, o adresie 192.168.0.1/24 i szeregowy, z adresem 169.254.10.2/30. Po włączeniu mechanizmu CEF, budowany jest FIB. Znajdzie się w nim wpis dla sieci 192.168.0.0/24 jako "zaczepionej" na interfejsie Ethernet. Zarażona stacja w sieci LAN zaczyna generować pakiety, z losowo wybranymi adresami źródłowymi. Dla każdego pakietu otrzymanego interfejsem Ethernet, router sprawdza, czy jeśli przyszłaby na niego odpowiedź, miałby wysłać ją interfejsem, z którego właśnie ją odebrał. Załóżmy, że router otrzymał pakiet ze sfałszowanego adresu 10.7.65.2. Sprawdza tablicę FIB i nie znajduje wpisu, który mówiłby, że do sieci 10 należy wychodzić interfejsem Ethernetowym - pakiet jest w związku z tym odrzucany. Na tej samej zasadzie działa ochrona ruchu, otrzymywanego przez interfejs szeregowy - jeśli tylko włączono na nim mechanizm uRPF. Pakiet, który chciałby zostać "wstrzelony" do sieci LAN (załóżmy, że przyszedł z adresem należącym do Twojej sieci LAN), zostanie odrzucony, ponieważ przyszedł złym interfejsem.

Działanie funkcji uRPF na konkretnym interfejsie potwierdzić można wydając polecenie:

router# show ip interface fastethernet 0

FastEthernet0 is up, line protocol is up
  [...]
  IP verify source reachable-via RX, allow default
  ! włączona weryfikacja adresów źródłowych

  642 verification drops
  ! ilość odrzuconych pakietów z uwagi na zły adres źródłowy

A ogólnie dla całego routera:

router# show ip traffic

IP statistics:
[...]
  Drop:  0 encapsulation failed, 0 unresolved, 0 no adjacency
         0 no route, 2512 unicast RPF, 0 forced drop