Anti-Spoofing (Polski)

Manrs Implementation Guide

  • wprowadzenie
  • koordynacja
  • globalna Walidacja
  • Anti-Spoofing
  • filtrowanie
  • Podsumowanie i listy kontrolne
  • dodatkowe informacje

4.3. Anti-Spoofing-zapobieganie ruchowi ze sfałszowanymi źródłowymi adresami IP

odpowiednie MANRS oczekiwane działania:

  • operator sieci implementuje system, który umożliwia weryfikację adresu źródłowego dla co najmniej pojedynczych sieci klientów stub, ich własnych użytkowników końcowych i infrastruktury., Operator sieci implementuje filtrowanie anti-spoofing, aby zapobiec wprowadzaniu i opuszczaniu sieci przez pakiety o nieprawidłowym źródłowym adresie IP.

spoofing adresów źródłowych IP jest praktyką pozyskiwania datagramów IP z adresami źródłowymi innymi niż te przypisane do hosta pochodzenia. W prostych słowach gospodarz udaje innego gospodarza. Można to wykorzystać na różne sposoby, w szczególności do wykonywania ataków typu Denial of Service (DoS), które powodują, że host reflektora wysyła ruch na fałszywy adres.,

istnieje wiele zaleceń, aby zapobiec spoofingowi IP poprzez filtrowanie wnikające, np. sprawdzanie adresów źródłowych datagramów IP w pobliżu krawędzi sieci. Większość dostawców sprzętu obsługuje filtrowanie wnikające w jakiejś formie. Od 2005 roku stosowanie technik anty-spoofingu nie jest ograniczeniem wydajności sprzętu. Było to ograniczenie chęci i chęci wdrożenia i utrzymania konfiguracji anti-spoofingu.

jak na ironię, znaczące ataki wzmocnienia DoS mogą być kosztowne dla usługodawców., Koszty szkodzą marce, szkodzą operacjom klientów i mają dodatkowy wpływ operacyjny/kosztowy na innych klientów. Tym atakom wzmocnienia DoS można zapobiec. Byłoby to niemożliwe bez fałszowania.

pokazuje to, że filtrowanie wnikające jest zdecydowanie niewystarczająco wdrożone. Niestety, nie ma żadnych korzyści dla dostawcy usług (SP), który wdraża filtrowanie wnikające. Istnieje również powszechne przekonanie, że filtrowanie wnikania pomaga tylko wtedy, gdy jest powszechnie stosowane.,

popularne podejścia do tego problemu obejmowały funkcje oprogramowania, takie jak Walidacja sav (Weryfikacja adresu źródła) w sieciach modemowych kablowych lub ścisła Walidacja uRPF (przekazywanie wstecznej ścieżki unicast) w sieciach routerów. Metody te mogą złagodzić obciążenie administracyjne w przypadkach, gdy routing i topologia są stosunkowo dynamiczne. Innym podejściem mogłoby być użycie inbound prefix filter information do utworzenia filtra pakietów, który pozwalałby tylko na pakiety ze źródłowymi adresami IP, dla których sieć mogłaby legalnie reklamować osiągalność.,

dla większości mniejszych i prostszych architektur sieci najprostszym sposobem zapobiegania spoofingowi jest użycie unicast RPF (uRPF) w trybie ścisłym. Do filtrowania adresów źródłowych używanych przez urządzenia w domenie warstwy 2 można użyć ulepszeń walidacji adresów źródłowych (SAVI). Na urządzeniach, gdzie funkcje automatycznego filtrowania nie są dostępne, można użyć list kontroli dostępu (ACL), aby ręcznie zaimplementować równoważne filtrowanie. Wszystkie te technologie zostały wyjaśnione poniżej.

4.3.1., Zasady przewodnie dla architektur Anti-Spoofing

aby były jak najbardziej skuteczne techniki anti-spoofing powinny być stosowane jak najbliżej źródła. W sieciach korporacyjnych adresy źródłowe używane przez każde urządzenie są często kontrolowane i egzekwowane, dzięki czemu audyty bezpieczeństwa mogą dokładnie określić, które urządzenie wysłało dany pakiet.

dla pomyślnej implementacji MANRS, taka drobna ziarnistość na poziomie urządzenia nie jest konieczna, ponieważ MANRS koncentruje się na zabezpieczeniach routingu i przeciwdziałaniu spoofingowi na poziomie sieci., Dlatego popularne architektury anti-spoofing skupiają się na upewnianiu się, że klienci nie wysyłają pakietów z niewłaściwymi adresami źródłowymi.

wymuszanie używania poprawnych adresów źródłowych na poziomie klienta ma tę zaletę, że klienci nie mogą fałszować swoich adresów, co zapobiega powodowaniu problemów dla siebie nawzajem, które są trudne do debugowania.

Jeśli z jakiegoś powodu nie jest możliwe wymuszenie użycia adresu źródłowego na klienta, alternatywą jest wymuszenie go w punktach agregacji, aby klienci mieli co najmniej ograniczone adresy, które mogą sfałszować., Przynajmniej na poziomie ISP powinna istnieć ochrona przed spoofingiem, aby klienci nie mogli fałszować adresów innych organizacji i powodować problemów na skalę internetową.

4.3.2. Unicast RPF

bcp38 uRPF Strict Mode with RFC1998++ style of multihoming (a BCP for multihoming) to podejście, które działa w konfiguracjach symetrycznych (single homed) i asymetrycznych (MULTIHOMED BGP) i zostało po raz pierwszy wdrożone operacyjnie w 2002 roku. Tak, jest wielu, którzy myślą ,że „uRPF nie działa z powodu asymetrii routingu”, ale to nieprawda., Dokumentacja z 2001 roku, ISP Essentials whitepaper (Google dla wersji 2.9) i ISP Essentials book (ISBN 1587050412) wraz z wdrożeniami w kilku głównych SPs wykazały, że tryb urpf strict jest realną techniką.

istnieją cztery algorytmy dla uRPF – tryb ścisły – sprawdź IP źródła i przyległość), tryb Loose (Sprawdź tylko IP źródła), Reable Path( sprawdź IP źródła z alternatywami FIB) i tryb VRF (Zezwalaj/odmawiaj sprawdzania źródła w oddzielnej tabeli od FIB)., Każda z tych opcji uRPF jest zaprojektowana dla określonych funkcji „anti-spoofing” w różnych częściach sieci.

  • Urpf Strict Mode – BCP38 on the customer-SP edge. Każdy przychodzący Pakiet jest testowany pod kątem FIB i jeśli interfejs przychodzący nie jest najlepszą ścieżką odwrotną, Pakiet jest odrzucany.
  • uRPF Loose Mode-sRTBH w dowolnym miejscu w sieci-ale tylko sprawdzić, czy trasa jest w FIB. Jeśli nie w migotaniu, to spadek. Jeśli jest w migotaniu, to podaj. Dobre dla sRTBH i łagodzenia niektórych fałszywych ruchu na krawędzi peering.,
  • uRPF – sRTBH w sieci i BCP38 dla klientów multihomed i tras asymetrycznych. W trybie wykonalnym FIB utrzymuje alternatywne trasy do danego adresu IP. Jeśli interfejs przychodzący pasuje do którejkolwiek z tras powiązanych z adresem IP, wtedy Pakiet jest przekazywany. W przeciwnym razie pakiet zostanie upuszczony.
  • uRPF VRF Mode-oparty na BGP peering Policy Enforcement lub bardziej szczegółowy sRTBH (Uwaga tryb VRF może być używany jako BCP38, ale nie został udowodniony operacyjnie)

uRPF może być przydatny w wielu miejscach w sieci., Najczęściej jest używany na krawędziach sieci, gdzie klienci, serwery i/lub klienci są podłączeni, ponieważ tryb ścisły działa tam dobrze. Operatorzy sieci wahają się, czy używać uRPF w rdzeniu swoich sieci, ponieważ obawiają się przypadkowego spadku ważnego ruchu, który obrał nieoczekiwaną ścieżkę przez ich sieć. tryb ścieżki wykonalnej uRPF powinien rozwiązać takie problemy.

zarówno Cisco, jak i Juniper implementują zarówno tryb ścisły, jak i tryb luźny. Pokazujemy jak używać trybu ścisłego., Skonfiguruj Urpf Strict Mode na interfejsach skierowanych do klientów za pomocą:

Cisco:

 ip verify unicast source reachable-via rx ipv6 verify unicast source reachable-via rx

Juniper:

 family inet { rpf-check; } family inet6 { rpf-check; }

To sprawi, że klient będzie mógł używać tylko adresów IP, które kierujesz do nich. W sytuacjach, gdy jesteś klientem innego ISP, gdzie masz domyślną trasę wskazującą na tego ISP, powinieneś użyć:

Cisco: 

 ip verify unicast source reachable-via rx allow-default ipv6 verify unicast source reachable-via rx allow-default

Juniper:

routery Juniper automatycznie dostosowują swoje filtrowanie uRPF w zależności od tego, gdzie są wskazywane domyślne trasy. Wystarczy użyć tych samych poleceń, co powyżej.,

opcja allow-default jest konieczna, ponieważ domyślnie adresy źródłowe będą dopasowane tylko do określonych tras, ignorując domyślną trasę. Chociaż dopasowanie do domyślnej trasy wydaje się być takie samo, jak zezwalanie na cokolwiek, nie jest. Zapewnia to, że Twój upstream nie wysyła ruchu, dla którego masz inne bardziej specyficzne trasy wskazujące w innym kierunku, takie jak sieci własne i sieci klientów. To ochroni Cię przed fałszywym ruchem z innych stron.

4.3.3., Dynamiczna Lista dostępu (Radius & Diameter)

standardowym sposobem ustawiania list dostępu dla uwierzytelnionych użytkowników Radius jest atrybut Radius 11 (Filter-Id). Za pomocą tego atrybutu możesz powiedzieć routerowi, aby zastosował istniejącą wcześniej listę dostępu do połączenia użytkownika. Wymaga to jednak użycia metody out-of-band, aby zapewnić wszystkim routerom poprawne listy dostępu.

niektórzy dostawcy mają dodatkowe opcje Radius, które mogą być używane do dynamicznego dostarczania listy dostępu za pośrednictwem Radius., Na przykład Cisco zapewnia dodatkową funkcjonalność za pomocą atrybutów cisco-avpair:

 cisco-avpair = "ip:inacl#5=permit ip 192.0.2.0 0.0.0.255 any" cisco-avpair = "ip:inacl#99=deny ip any any"

pozwoli to tylko pakietom od klienta, które mają adres źródłowy w zakresie 192.0.2.0/24.

4.3.4. SAVI

SAVI to nazwa grupy roboczej IETF zajmującej się poprawą poprawności adresów źródłowych. Do walidacji adresu źródłowego klienta powszechnie używane jest rozwiązanie SAVI dla DHCP w RFC 7513., Ta wersja SAVI śledzi wszystkie adresy IP, które zostały przypisane do każdego urządzenia, szpiegując wymianę wiadomości DHCPv4 i DHCPv6 na przełączniku sieciowym, do którego jest podłączony klient. Jeśli klient użyje nieautoryzowanego adresu źródłowego, przełącznik upuści pakiet.

dostawcy często używają własnej terminologii do opisu funkcji SAVI. Na urządzeniach Cisco funkcje te są określane jako DHCP Snooping, Source Guard i PREFIX Guard.

4.3.5., IP weryfikuje źródło

sieci Ethernet są domenami rozgłoszeniowymi i domyślnie nie ma walidacji kto może wysyłać pakiety z jakimi adresami. Aby skonfigurować przełączniki Cisco w celu weryfikacji adresów źródłowych używanych przez podłączone urządzenia, można użyć ustawienia „IP verify source”.,

istnieją trzy warianty tej funkcji:
● ip verify source
● ip verify source port-security
● ip verify source tracking port-security

pierwszy wariant weryfikuje źródłowy adres IP, drugi wariant weryfikuje również źródłowy adres MAC, a trzeci wariant śledzi powiązania między adresem IP a adresem MAC. Aby uniemożliwić klientom korzystanie z adresu MAC innego klienta, zaleca się ostatni wariant. Wszystko to opiera swoją decyzję na przechwyconych danych DHCP.,

przed weryfikacją adresów źródłowych przełącznik musi być skonfigurowany tak, aby snoop DHCP traffic zbierał dane, aby opierać swoje decyzje naip dhcp snooping. Aby śledzić, który port ethernet łączy się z każdym klientem DHCP, użyj opcji DHCP 82 z ip dhcp snooping information option. Jest to konieczne, ponieważ w przypadku verify port-security przełącznik nie nauczy się adresów MAC, dopóki serwer DHCP nie przydzieli adresu IP do podłączonego urządzenia. Opcja 82 jest zatem konieczna, aby przypomnieć przełącznikowi, gdzie klient był podłączony.,

istnieje kilka kroków niezbędnych do umożliwienia bezpiecznego śledzenia urządzeń i weryfikacji ich adresów źródłowych. Pierwszym krokiem jest włączenie” śledzenia urządzeń ip ” globalnie na przełączniku. Dzięki temu przełącznik może śledzić, który adres IP należy do którego adresu MAC. Następnie na każdym interfejsie zdefiniuj liczbę urządzeń, z którymi można się połączyć ip device tracking maximum num, gdzie num może być liczbą od 1 do 10. Teraz włącz switchport port-security na każdym interfejsie, aby upewnić się, że używane są tylko dozwolone adresy MAC., I na koniec włącz funkcję weryfikacji, która łączy je wszystkie razem z ip verify source tracking port-security.

teraz przełącznik ma wszystkie informacje potrzebne do snoop ruchu DHCP, połączyć adresy IP z adresami MAC i sprawdzić, czy wszystkie pakiety wysyłane przez przełącznik są zgodne ze stanem zebranym, który jest oparty na odpowiedziach z serwera DHCP. Pakiety, które nie są zgodne z tym, co serwer DHCP przypisał, zostaną odrzucone.

4.3.6. Cable Source-Verify

sieci modemowe kablowe są pod wieloma względami podobne do sieci ethernet., O ile nie skonfigurowano inaczej, użytkownicy mogą fałszować adresy źródłowe lub wykradać adresy innych użytkowników sieci kablowej. Funkcja Cisco cable source-verify umożliwia operatorowi CMTS ograniczenie adresów źródłowych, z których użytkownik może korzystać.

istnieją dwa warianty tej funkcji:

●cable source-verify
●cable source-verify dhcp

oba warianty mają wpływ na to, które adresy z podsieci sieci kablowej mogą być używane. Pierwszy wariant tylko uniemożliwia użytkownikom kradzież nawzajem adresów i dlatego nie jest wystarczający dla MANRS., Przyjrzymy się drugiemu wariantowi.

Konfiguracjacable source-verify dhcp informuje CMTS, że wszystkie adresy źródłowe muszą być zweryfikowane pod kątem dzierżaw DHCP, które CMTS widział. Jeśli pakiet zostanie wysłany z innym źródłem, CMTS go upuści. Uniemożliwi to użytkownikom korzystanie z adresów nie przypisanych do nich przez DHCP .

problemy mogą wystąpić podczas przeładowywania CMTS. W takim przypadku CMTS nie pozna wszystkich dzierżaw DHCP od swoich użytkowników i może zmniejszyć legalny ruch. Aby rozwiązać ten problem, CMTS można skonfigurować tak, aby korzystał z protokołu DHCP LeaseQuery., Pozwala to CMTS zapytać serwer DHCP o dzierżawy dla ruchu, który widzi. Gdy serwer DHCP potwierdzi, że istnieje legalna dzierżawa tego adresu, CMTS doda go do swojej pamięci podręcznej i zezwoli na ruch.

aby skonfigurować CMTS tak, aby nie ufał ARP w sieci kablowej, skonfiguruj go za pomocąno cable arp. Zapewni to, że tylko informacje uzyskane z DHCP i LeaseQuery są zaufane podczas weryfikacji adresów źródłowych.

funkcjacable source-verify chroni tylko podsieć samej sieci kablowej., Aby uniemożliwić użytkownikom fałszowanie innych adresów i umożliwić ruch od klientów, którzy mają przekierowaną podsieć, z której mogą korzystać, skonfiguruj ip verify unicast source reachable-via rx, aby włączyć tryb Urpf Strict w sieci kablowej. To sprawdzi wszystkie adresy źródłowe, które nie są bezpośrednio w sieci kablowej i umożliwi sprawdzenie na przykład statycznych tras dla kierowanych podsieci w kierunku klientów.

4.3.7., Lista kontroli dostępu (ACLs)

ACLs są powszechnie wdrażane na granicy dostawcy (PE – – klienta (CE), ale są również bardzo przydatne w innych miejscach, takich jak w kierunku własnego serwera dostawcy, sieci klienckich i infrastrukturalnych, aby zapobiec niewłaściwemu zachowaniu urządzeń. Zoptymalizowana strategia ACL polegałaby na umieszczeniu wyraźnego filtra zezwoleń na interfejsie klienta. Jawne filtry zezwalające zezwalają na określone zakresy adresów, a następnie odrzucają wszystkie inne. Na przykład, jeśli klient operatora zostanie przydzielony 192.0.2.0/24, BCP 38 ACL zezwoli na wszystkie adresy źródłowe z 192.0.2.,0/24 a nastÄ ™ pnie zaprzecza wszystkim pakietom, ktĂłrych adres ĹşrĂłdĹ ' owy nie jest 192.0.2.0/24.

na interfejsach podrzędnych dostawcy usług internetowych powinny znajdować się filtry weryfikujące adresy źródłowe używane przez jego klientów. Jeśli uRPF nie może być użyty, konieczne są ręczne ACL. Weźmy pierwszego klienta z przykładowego diagramu powyżej:

Cisco:

Juniper:

4.3.7.1., Punkty agregacji

gdy ACL na granicy PE-CE nie są możliwe, na przykład dlatego, że wielu klientów jest podłączonych do sieci pojedynczej warstwy-2, a urządzenia warstwy-2 nie mają funkcji filtrowania informacji warstwy-3, filtrowanie w punkcie agregacji jest drugim najlepszym rozwiązaniem.

w tym przykładzie nie jest (z nieokreślonego powodu) możliwe filtrowanie na / 24 dla każdego klienta. W tym przypadku filtrowanie na 192.0.2.0/23 i 198.51.100.,0/23 (podobnie jak w przypadku IPv6) w punkcie agregacji blisko połączeń z klientami ograniczyłoby co najmniej możliwości fałszowania dla tej grupy klientów do niewielkiego zakresu adresów.

konfiguracja odbywa się w taki sam sposób, jak pokazano w poprzedniej sekcji, z tym, że teraz odbywa się na innym routerze w bardziej centralnej lokalizacji w sieci.

4.3.8. Carrier Grade NAT – czy NAT jest narzędziem anty-Spoof?

domyślnie wiele implementacji NAT nie filtruje adresu źródłowego klientów., Weźmy na przykład prostą konfigurację NAT na routerze Cisco, taką jak:

 ip nat inside source list INSIDE pool OUTSIDE overload

Ta reguła nat przetłumaczy pakiety z adresem źródłowym na liście dostępu wewnątrz i zmieni adres źródłowy na adres w Puli Na Zewnątrz. Jednak pakiety, które mają podrobiony adres źródłowy, który nie jest zawarty w wewnętrznej liście dostępu, będą przekazywane bez tłumaczenia, co spowoduje, że pakiety zostaną podrobione w Internecie., Gdy sfałszowany pakiet zgadza się z listą dostępu, zostanie on przetłumaczony przy użyciu podanej puli, więc świat zewnętrzny nie widzi podrobionego adresu źródłowego, ale operator NAT nie będzie mógł prześledzić podrobionych pakietów z powrotem do ich twórcy.

pokazuje to, że NAT nie jest narzędziem anty-spoofingowym. Nawet przy użyciu NAT adresy źródłowe używane przez klientów muszą być sprawdzane jak najbliżej klienta, tak jak w przypadkach bez NAT pokazanych wcześniej w tym rozdziale. Tylko wtedy można zapobiec przedostawaniu się fałszywych i/lub niemożliwych do namierzenia pakietów do Internetu.

4.3.9., Dodatkowa lektura

Leave a Comment