Unicast RPF On the Edge


10

Unicast RPF ma zapobiegać adresom źródłowym, które różnią się od tego, jakie powinny być dozwolone. Czytając dokumentację Cisco dla URPF, zauważyłem, że istnieją opcje pozwalające na użycie jej w interfejsie łącza zwrotnego, pozwalając jej przejść przez tablicę routingu.

Moje pytanie brzmi: jeśli idzie domyślną trasą, czy wszystkie adresy źródłowe nie są dozwolone? Jakie korzyści przyniesie URPF w tym momencie?

Jestem pewien, że coś mi umknęło, więc naprawdę chciałbym znaleźć punkt we właściwym kierunku.

Odpowiedzi:


15

Unicast Reverse Path Forwarding (RPF) działa w trzech różnych trybach i może potencjalnie pomóc w zmniejszeniu wektora ataku routera, szczególnie ze sfałszowanych adresów IP.

tryb ścisły

(config-if)#ip verify unicast source reachable-via rx

W trybie ścisłym router sprawdza i sprawdza źródłowy adres IP pakietu przychodzącego na podstawie tabeli FIB (Forwarding Information Base) pod kątem pasującej trasy. Jeśli trasa do tego źródłowego adresu IP jest osiągalna przez interfejs, na którym został odebrany , pakiet zostanie odebrany. Domyślnie trasa domyślna nie jest rozważana w trybie ścisłym (jak skonfigurowano powyżej).

Opcje trybu ścisłego:

Po skonfigurowaniu trybu ścisłego Unicast RPF na danym interfejsie router nie może już pingować się na tym interfejsie:

#sh ip int bri | ex unas|Int
FastEthernet0/0            11.0.11.1

#ping 11.0.11.1                                    
.....
Success rate is 0 percent (0/5)

Weryfikacja porzuconych pakietów URPF:

#show ip int fa0/0 | i ^  [1-9]+ verification drops
     5 verification drops
#show ip traffic | i unicast
     0 no route, 5 unicast RPF, 0 forced drop

To zachowanie można zmienić, dodając allow-self-pingskładnię:

(config-if)#ip verify unicast source reachable-via rx allow-self-ping

Dodatkowo, jak wspomniano w pytaniu, tryb ścisły może umożliwić sprawdzanie źródłowych adresów IP pakietu względem domyślnej trasy. Jest to możliwe dzięki składni allow-default:

W trybie ścisłym dodanie samej składni allow-defaultzapobiegnie tylko odebraniu przychodzącego źródłowego adresu IP pakietu, który ma trasę przez inny interfejs niż odebrany. Zakłada się, że na routerze nie ma skonfigurowanych list dostępu ani tras zerowych. Wszystkie adresowalne adresy źródłowe, które są osiągalne przez interfejs, który otrzymują, będą albo pasować do określonych tras, albo do trasy domyślnej.

Jeśli jednak zastosujesz trasy zerowe, najbardziej konkretna trasa zostanie oceniona jako pierwsza, zanim kontrola URPF przejdzie do trasy domyślnej i będzie działać jako czarna lista (listy) dla znanych złośliwych zakresów adresów IP.

Przykład - cały ruch pochodzący z 3.0.0.0/8 zostanie odrzucony przez kontrolę URPF:

(config-if)#ip verify unicast source reachable-via rx allow-default
(config)#ip route 3.0.0.0 255.0.0.0 null 0

Bad-Source-RTR#ping 11.0.11.1 so l1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 11.0.11.1, timeout is 2 seconds:
Packet sent with a source address of 3.3.3.3 
.....
Success rate is 0 percent (0/5)

Ponadto można określić listę kontroli dostępu (ACL) zamiast dodawać allow-defaultskładnię w celu uzyskania uporządkowanej listy dozwolonych i odrzuconych adresów. Adresy, które są osiągalne poza interfejsem, na którym zostały odebrane i które są dopasowane do zdefiniowanej listy ACL, są odpowiednio usuwane lub dozwolone.

!
access-list 23 permit 3.0.0.0 0.255.255.255
access-list 23 deny   4.0.0.0 0.255.255.255 log
access-list 23 permit any
!
(config)#int fa0/0                                 
(config-if)#ip verify unicast source reachable-via rx 23

Na koniec możesz określić listę ACL za pomocą allow-defaultskładni, ale nie przyniesie to żadnego efektu. Pakiety nie będą sprawdzane pod kątem list ACL określonych za pomocą allow-defaultopcji.

#ip verify unicast source reachable-via rx allow-default ? 
  <1-199>          A standard IP access list number
  <1300-2699>      A standard IP expanded access list number

Loose Mode

R1(config-if)#ip verify unicast source reachable-via any

W trybie swobodnym router sprawdza źródłowy adres IP pakietu przychodzącego i porównuje go z tabelą FIB pod kątem pasującej trasy. Jeśli droga do tego źródłowego adresu IP jest osiągalna, pakiet może zostać odebrany, niezależnie od interfejsu, na którym został odebrany. Domyślnie trasa domyślna nie jest uwzględniana w trybie swobodnym (jak skonfigurowano powyżej).

Tryb luźny i tryb ścisły mają podobne opcje konfiguracji; Główne różnice to zastosowana składnia ( anyvs. rx) i to, czy źródłowy adres IP pakietu przychodzącego jest osiągalny poprzez interfejs, na którym został odebrany.

(config-if)#ip verify unicast source reachable-via any ?
  <1-199>          A standard IP access list number
  <1300-2699>      A standard IP expanded access list number
  allow-default    Allow default route to match when checking source address
  allow-self-ping  Allow router to ping itself (opens vulnerability in
                   verification)

Tryb VRF

Tryb VRF może wykorzystywać tryb luźny lub ścisły w danym VRF i ocenia źródłowy adres IP pakietu przychodzącego na podstawie tabeli VRF skonfigurowanej dla sąsiada eBGP.


Odniesienia:
biała księga Cisco URPF
Zrozumienie przewodnika konfiguracji URPF Unicast Reverse Path Forwarding


Co z praktycznym zastosowaniem? Czy to naprawdę ma sens / różnica, aby umieścić go na łączu w górę?
codey

3
@codey Nie uruchamiałbym uRPF na łączu w górę, tylko na interfejsach klienta. one.time, +1, dobra robota, solidne odpowiedzi, chciałbym zaznaczyć, że statyczna droga do null0 na niektórych platformach innych niż cisco nie spowoduje awarii trybu „luźnego”. Może zamiast „odpowiedział” powinieneś użyć „odbierać”, tzn. Pakiety, których nie udało się odebrać RPF nie będą odbierane. Być może należy również zmienić opcję „przeciw tablicy routingu” (RIB) na „przeciw tablicy przesyłania” (FIB). Ponieważ istnieje uRPF o nazwie „feasible loose / strict”, który sprawdza w oparciu o RIB (Cisco go nie obsługuje, sprawdzają tylko w oparciu o FIB).
ytti

@ytti Kiedy spojrzałem na dokumenty Cisco, powiedziałem po prostu o tabeli routingu. Nie twierdzę, że to prawda, ale dziwne, że powiedzieliby tak, gdyby to był tylko FIB.
codey

Wyobraź sobie przypadek, w którym klient ogłosił prefiks BGP 192.0.2.0/24, masz również trasę statyczną dla tego wskazania do rdzenia. Jeśli interfejs klienta ma uRPF / strict, usuniesz pakiety od klienta o adresie źródłowym 192.0.2.42, nawet jeśli w RIB (tablica routingu) ten wpis istnieje, to po prostu nie jest / best / entry, a zatem nie jest w FIB. Jednak jeśli uruchomisz pakiet „uRPF / strict feasible”, nie zostanie on odrzucony (JunOS obsługuje wykonalny, więc jego dokumenty podadzą dodatkowe informacje).
ytti
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.