W poprzednim artykule o bezpieczeństwie protokołu EIGRP zostały omówione takie zagadnienia jak uwierzytelnianie komunikatów protokołu routingu za pomocą hasła w pliku kluczy, interfejsy pasywne pozwalające w prosty sposób zablokować możliwość nawiązywania sąsiedztwa przy jednoczesnym rozgłaszaniu podsieci oraz modyfikacje wartości parametrów „K”. Pamiętajmy jednak, że bezpieczeństwo protokołów routingu to nie tylko zapobieganie nawiązywaniu niepożądanych relacji sąsiedztwa z innymi urządzeniami. To także dbałość o stan tablicy routingu, topologii protokołu routingu i informacji o podsieciach jakie są rozgłaszane.
Stub routing
W protokole OSPF możemy definiować kilka typów obszarów – backbone area, normal area, stub area, totally stub area czy not-so-stubby area. W zależności od typu obszaru pewne informacje dotyczące podsieci w danym obszarze są wymieniane pomiędzy routerami w różnych obszarach, modyfikowane lub blokowane. Przykładowo, do obszaru typu stub nie są rozgłaszane szczegółowe informacje o prefiksach pochodzących z innego protokołu routingu, a jedynie domyślna trasa informująca router w jaki sposób zewnętrzne sieci mogą zostać osiągnięte. Wpływało to na bezpieczeństwo (brak możliwości „wstrzyknięcia” niepożądanych informacji o zewnętrznych podsieciach) jak i zmniejszało rozmiar tablicy routingu.
W EIGRP znajdziemy pojęcie Stub Routing. Zastosowanie tej techniki pozwala na zwiększenie bezpieczeństwa oraz stabilności sieci, upraszcza konfigurację i obciążenie procesora urządzeń sieciowych (choć w dzisiejszych czasach to akurat nie ma już znaczenia). Ze stub routingiem zazwyczaj spotkamy się w sieciach w topologii Hub-and-Spoke. W takim rozwiązaniu urządzenia końcowe (spoke) rozgłaszają do centralnych koncentratorów (hub) informacje o podłączonych do końcówek podsieciach. W takiej topologii cały ruch przechodzi przez koncentratory. Nie ma zatem potrzeby, aby urządzenia końcowe przetwarzały i przechowywały informacje o wszystkich prefikach, które rozgłaszane są w systemie autonomicznym przez protokół EIGRP.
W konfiguracji typu Stub router rozgłasza jedynie określone trasy do sąsiada. O tym, jakie informacje zostaną rozgłoszone decyduje administrator. W szczególności nie rozgłasza on tras, które potencjalnie uzyskał od innych swoich sąsiadów. Zapobiega to nieoptymalnemu routingowi w takiej sieci, który powstałby, gdyby routery końcowe służyły jako węzły tranzytowe dla ruchu. Jest to także zabezpieczenie w sytuacji, gdy atakującemu uda się podłączyć do naszej sieci i nawiązać relację sąsiedztwa EIGRP z naszym routerem. W takim przypadku wstrzykiwane przez niego informacje o podsieciach nie będę przez nasz router dalej rozgłaszane do hub-a.
Domyślna konfiguracja routera jako stub powoduje, że wysyła on jedynie informacje o podsieciach bezpośrednio podłączonych do niego (connected routes) oraz trasach pochodzących z agregacji (summary routers).
router eigrp 65530
eigrp stub connected summary
Za pomocą dodatkowych parametrów możemy ograniczać typy rozgłaszanych tras. Przykładowo, jeżeli chcemy rozgłaszać jedynie informacje po podsieciach przyłączonych bezpośrednio do routera musimy wprowadzić następującą konfigurację.
router eigrp 65530
eigrp stub connected
Filtrowanie tras
Kolejną techniką, zapobiegającą przetwarzaniu informacji o niepożądanych prefiksach jest filtrowanie informacji rozgłaszanych (out) i odbieranych (in) przez nasz router. Filtrowanie konfigurujemy za pomocą distribute-list, w ramach której informacje o akceptowanych lub odrzucanych prefiksach definiujemy w liście kontrolnej ACL. Lista dystrybucyjna może zostać aktywowana w całym procesie EIGRP na routerze lub tylko na wybranych interfejsach.
Jeżeli chcemy, aby nasz router rozgłaszał jedynie trasy z podsieci 10.0.0.0/8 musimy wprowadzić poniższą konfigurację:
router eigrp 65530
distribute-list 10 out
!
access-list 10 permit 10.0.0.0 0.255.255.25
access-list 10 deny any
Gdybyśmy chcieli podłączyć filtr jedynie do interfejsu GigabitEthernet0/0 konfiguracja wyglądałaby następująco:
router eigrp 65530
distribute-list 10 out GigabitEthernet0/0
!
access-list 10 permit 10.0.0.0 0.255.255.25
access-list 10 deny any
W topologii hub-and-spoke zarządzanie rozgłaszanymi trasami na poziomie routerów końcowych (spoke) może być dość nieefektywne. Odpowiednie filtry możemy wtedy wdrożyć na routerach centralnych (hub) tak, aby odbierały jedynie informacje o określonych podsieciach.
Pamiętajmy, że ta metoda filtrowania nie wpływa bezpośrednio na tablicę routingu, a na tablicę topologii EIGRP na podstawie między innymi której budowana jest tablica routingu. Zatem odfiltrowane informacje o podsieciach nie będą w ogóle brane pod uwagę w algorytmie elekcji najlepszej trasy w protokole EIGRP.
… [Trackback]
[…] Find More Information here on that Topic: wladcysieci.pl/2020/10/06/bezpieczenstwo-eigrp-czesc-ii/ […]
… [Trackback]
[…] Find More on on that Topic: wladcysieci.pl/2020/10/06/bezpieczenstwo-eigrp-czesc-ii/ […]
… [Trackback]
[…] Read More Info here on that Topic: wladcysieci.pl/2020/10/06/bezpieczenstwo-eigrp-czesc-ii/ […]