Anti-Spoofing (Svenska)

Manrs Implementation Guide

• introduktion
• samordning
• Global validering
• anti-Spoofing
• filtrering
• sammanfattning och checklistor
• ytterligare information

4.3. Anti-Spoofing-förhindra trafik med spoofed källa IP-adresser

relevanta MANRS förväntade åtgärder:

• nätoperatör implementerar ett system som möjliggör källadress validering för åtminstone single-homed stub kundnätverk, sina egna slutanvändare och infrastruktur., Nätoperatören genomför anti-spoofing filtrering för att förhindra paket med felaktig källa IP-adress från att komma in och lämna nätverket.

ip-källadress spoofing är praxis att Ursprung IP-datagram med andra källadresser än de som tilldelats värd för Ursprung. I enkla termer låtsas värden vara någon annan värd. Detta kan utnyttjas på olika sätt, framför allt för att utföra Reflektionsförstärkningsattacker (dos) som orsakar att en reflektorvärd skickar trafik till den spoofed-adressen.,

det finns många rekommendationer för att förhindra IP-spoofing genom ingressfiltrering, t.ex. kontroll av källadresser för IP-datagram nära nätverkskanten. De flesta utrustningsleverantörer stöder ingressfiltrering i någon form. Sedan 2005 har användningen av anti-spoofing-tekniker inte varit en begränsning av utrustningens prestanda. Det har varit en begränsning av lust och vilja att distribuera och upprätthålla anti-spoofing konfiguration.

ironiskt nog kan betydande DoS-förstärkningsattacker vara dyra för tjänsteleverantörer., Kostnaderna skadar varumärket, skadar kundverksamheten och har säkerheter operativa/kostnadspåverkan på andra kunder. Dessa DoS förstärkning attacker kan förebyggas. De skulle vara omöjliga utan spoofing.

detta visar att ingressfiltrering definitivt inte är tillräckligt utplacerad. Tyvärr finns det inga fördelar för en tjänsteleverantör (SP) som distribuerar ingressfiltrering. Det finns också en allmänt tro på att ingressfiltrering bara hjälper när den är allmänt utplacerad.,

vanliga metoder för detta problem har inneburit programfunktioner som sav (validering av källadress) i kabelmodemnätverk eller strikt uRPF (unicast Reverse – Path Forwarding)-validering i routernätverk. Dessa metoder kan underlätta administrationskostnader i fall där routing och topologi är relativt dynamisk. Ett annat tillvägagångssätt skulle kunna vara att använda inkommande prefix-filterinformation för att skapa ett paketfilter, vilket bara skulle tillåta paket med källip-adresser för vilka nätverket legitimt skulle kunna annonsera reachability.,

För de flesta mindre och enklare nätverksarkitekturer det enklaste sättet att förhindra förfalskning är att använda Unicast RPF (uRPF) i Strikt Läge. För filtrering av källadresser som används av enheter på en layer-2-domän kan förbättringar av Källadressvalidering (Savi) användas. På utrustning där automatiska filtreringsfunktioner inte är tillgängliga kan du använda Access Control Lists (ACLs) för att manuellt implementera motsvarande filtrering. Alla dessa tekniker förklaras nedan.

4.3.1., Vägledande principer för anti-Spoofing arkitekturer

för att vara så effektiva som möjligt anti-spoofing tekniker bör tillämpas så nära källan som möjligt. I företagsnätverk styrs och verkställs ofta källadresserna som används av varje enhet så att säkerhetsrevisioner kan ange exakt vilken enhet som skickas vilket paket.

för ett framgångsrikt genomförande av MANRS är sådan fin granularitet på enhetsnivå inte nödvändig eftersom MANRS fokuserar på routningssäkerhet och anti-spoofing på nätverksnivå., Därför fokuserar vanliga anti-spoofing-arkitekturer på att se till att kunderna inte skickar paket med fel källadresser.

genom att använda giltiga källadresser på kundnivå har kunderna fördelen att de inte kan förfalska varandras adresser, vilket hindrar dem från att orsaka problem för varandra som är svåra att felsöka.

om det av någon anledning inte är möjligt att genomdriva källadressanvändning per kund, är ett alternativ att genomdriva den vid aggregeringspunkter så att kunderna är åtminstone begränsade i vilka adresser de kan spoof., Åtminstone bör det finnas anti-spoofing på ISP-nivå så att kunderna inte kan spoof-adresser till andra organisationer och orsaka problem på Internet.

4.3.2. Unicast RPF

BCP38 uRPF Strikt Läge med RFC1998++ stil av multihoming (a BCP för multihoming) är en metod som fungerar i symmetriska (enda hem) och asymmetrisk (multihomed BGP) – konfigurationer, och för första gången blev utplacerade operativt 2002. Ja, det finns många som tror att” uRPF fungerar inte på grund av routing asymmetri”, men det här är inte sant., Dokumentation från 2001, ISP Essentials whitepaper (Google för version 2.9) och ISP Essentials bok (ISBN 1587050412) tillsammans med installationer i flera stora SPs har visat att uRPF strikt läge är en gångbar teknik.

det finns fyra algoritmer för uRPF – strikt läge (kontrollera källa IP och adjacency), Lös läge (kontrollera endast källa IP), genomförbar väg (kontrollera källa IP med FIB: s Alternativ), och VRF-läge (tillstånd/neka kontroll på källa i en separat tabell från FIB)., Var och en av dessa uRPF alternativ som är utformade för specifika ”anti-spoofing” funktioner i olika delar av nätverket.

• uRPF Strikt Läge – BCP38 på kund-SP kanten. Varje inkommande paket testas mot FIB och om det inkommande gränssnittet inte är den bästa omvända vägen, släpps paketet.
• uRPF Loose Mode – sRTBH var som helst i nätverket – men kontrollera bara om rutten är i FIB. Om inte i FIB, släpp sedan. Om det är i FIB, passera sedan. Bra för sRTBH och mildra några spoofed trafik på peering kanten.,
• uRPF Möjlig Väg – sRTBH var som helst i nätverket och BCP38 för multihomed kunder och asymmetriska linjer. I det genomförbara läget upprätthåller FIB alternativa vägar till en given IP-adress. Om det inkommande gränssnittet matchar någon av de rutter som är associerade med IP-adressen vidarebefordras paketet. Annars släpps paketet.
• uRPF VRF Mode – BGP baserat Peering Policy Verkställighet eller mer detaljerad sRTBH (NOT VRF Läge kan användas som BCP38, men har inte varit operativt bevisat)

uRPF kan vara användbart på många platser i nätverket., Det används oftast på kanterna av de nätverk där kunder, servrar och/eller klienter är anslutna eftersom strikt läge fungerar bra där. Nätoperatörer är tveksamma till att använda uRPF i kärnan i sina nätverk på grund av rädslan för att oavsiktligt släppa giltig trafik som har tagit en oväntad väg genom sitt nätverk. uRPF genomförbart vägläge bör lösa sådana problem.

både Cisco och Juniper implementerar både strikt läge och löst läge. Vi visar hur man använder strikt läge., Konfigurera uRPF strikt läge på gränssnitt mot kunder med:

Cisco:

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

Juniper:

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

det kommer att se till att kunden endast kan använda IP-adresser som du rutten till dem. I situationer där du är kund till en annan Internetleverantör där du har en standardrutt som pekar på den Internetleverantören bör du använda:

Cisco:

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

Juniper:

Juniper routrar anpassar automatiskt sin uRPF-filtrering baserat på var standardrutterna pekar mot. Använd bara samma kommandon som ovan.,

alternativet Tillåt-standard är nödvändigt eftersom källadresserna som standard endast matchas mot specifika rutter och ignorerar standardrutten. Medan matchning mot standardvägen verkar vara densamma som att tillåta något, det är inte. det ser till att din uppströms inte skickar dig trafik som du har andra mer specifika rutter pekar i en annan riktning, till exempel dina egna nätverk och dina kunders nätverk. Detta kommer att skydda dig mot spoofed trafik från andra.

4.3.3., Dynamisk åtkomstlista (radie & Diameter)

det vanliga sättet att ställa in åtkomstlistor för Radius-autentiserade användare är genom Radiusattribut 11 (Filter-Id). Med det här attributet kan du be routern att tillämpa en befintlig åtkomstlista på användarens anslutning. Detta kräver dock en out-of-band-metod för att tillhandahålla alla routrar med rätt åtkomstlistor.

vissa leverantörer har extra Radiealternativ som kan användas för att dynamiskt tillhandahålla åtkomstlistan själv genom radie., Cisco till exempel ger extra funktionalitet genom cisco-avpair attribut är tillåtna:

 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"

Detta skulle bara tillåta paket från kunden som har en källa med adress i 192.0.2.0/24 sortiment.

4.3.4. Savi

Savi är namnet på den IETF-arbetsgrupp som arbetar med förbättringar av Källadressvalidering. För validering av en kunds källadress används savi för DHCP-lösning i RFC 7513 vanligen., Denna version av SAVI håller reda på alla IP-adresser som har tilldelats varje enhet genom att snooping på DHCPv4 och DHCPv6 meddelandeutbyten på nätverksomkopplaren som kunden är ansluten till. Om en kund använder en obehörig källadress kommer omkopplaren att släppa paketet.

leverantörer använder ofta sin egen terminologi för att beskriva savi-funktioner. På Cisco-enheter kallas dessa funktioner DHCP Snooping, Source Guard och Prefix Guard.

4.3.5., IP verifiera källa

Ethernet-nätverk sänds domäner, och som standard finns det Ingen validering av vem som får skicka paket med vilka adresser. För att konfigurera Cisco-switchar för att verifiera källadresserna som används av de anslutna enheterna kan inställningen” ip verify source ” användas.,

det finns tre varianter av den här funktionen:
●ip verify source
●ip verify source port-security
●ip verify source tracking port-security

den första varianten verifierar källans IP-adress, den andra varianten verifierar också källans MAC-adress och den tredje varianten spårar bindningarna mellan IP-adress och MAC-adress. För att förhindra kunder från att använda en annan kunds MAC-adress rekommenderas den sista varianten. Alla dessa baserar sitt beslut på snooped DHCP-data.,

innan du kan verifiera källadresser måste omkopplaren konfigureras för att snoop DHCP-trafik ska kunna samla in data för att basera sina beslut på ip dhcp snooping. För att hålla reda på vilken ethernet-port som ansluts till varje DHCP-klient, använd DHCP option 82 med ip dhcp snooping information option. Detta är nödvändigt eftersom med verifiera port-säkerhet omkopplaren inte kommer att lära MAC-adresser tills DHCP-servern har tilldelat en IP-adress till den anslutna enheten. Alternativ 82 är därför nödvändigt för att påminna omkopplaren där klienten var ansluten.,

det finns flera steg som krävs för att möjliggöra säker spårning av enheter och verifiera deras källadresser. Det första steget är att aktivera” ip-enhetsspårning ” globalt på strömbrytaren. Detta säkerställer att omkopplaren kan spåra vilken IP-adress som tillhör vilken MAC-adress. Sedan på varje gränssnitt, definiera antalet enheter som får ansluta med ip device tracking maximum num där num kan vara ett nummer från 1 till 10. Aktivera nu switchport port-security på varje gränssnitt för att säkerställa att endast tillåtna MAC-adresser används., Och slutligen aktivera verifieringsfunktionen som länkar alla dessa tillsammans med ip verify source tracking port-security.

nu har omkopplaren all information den behöver för att snoka DHCP-trafik, länka IP-adresserna till MAC-adresser och verifiera att alla paket som skickas via omkopplaren överensstämmer med det insamlade tillståndet som baseras på svar från DHCP-servern. Paket som inte överensstämmer med vad DHCP-servern har tilldelat kommer att släppas.

4.3.6. Kabelkälla-verifiera

Kabelmodemnätverk liknar på många sätt ethernet-nätverk., Om inte annat har konfigurerats kan användarna förfalska källadresser eller stjäla adresserna till andra användare i kabelnätet. Cisco cable source-verify-funktionen gör det möjligt för CMTS-operatören att begränsa vilka källadresser en användare får använda.

det finns två varianter av den här funktionen:

●cable source-verify
●cable source-verify dhcp

båda varianterna påverkar vilka adresser från kabelnätets subnät som får användas. Den första varianten hindrar bara användare från att stjäla varandras adresser och är därför inte tillräcklig för MANRS., Vi kommer att titta på den andra varianten.

konfigureracable source-verify dhcp talar om för CMTS att alla källadresser måste verifieras mot DHCP-leasingavtal som CMTS har sett. Om ett paket skickas med en annan källa kommer CMTS att släppa det. Detta kommer att hindra användare från att använda adresser som inte tilldelats dem via DHCP .

problem kan uppstå när CMTS laddas om. I ett sådant fall kommer CMTS inte att känna till alla DHCP-leasingavtal från sina användare och kan släppa legitim trafik. För att lösa detta CMTS kan konfigureras för att använda DHCP LeaseQuery protokoll., Detta gör det möjligt för CMTS att fråga DHCP-servern om leasingavtal för trafik som den ser. När DHCP-servern bekräftar att det finns ett legitimt leasingavtal för den adressen kommer CMTS att lägga till den i cachen och tillåta trafiken genom.

för att konfigurera CMTS att inte lita på ARP på kabelnätverket konfigurera det medno cable arp. Detta kommer att se till att endast information som lärt sig från DHCP och LeaseQuery är betrodd vid verifiering av källadresser.

funktionencable source-verify skyddar endast delnätet för själva kabelnätet., För att hindra användare från att förfalska andra adresser och tillåta trafik från kunder som har ett dirigerat subnät som de får använda, konfigurera även ip verify unicast source reachable-via rx för att aktivera uRPF strikt läge i kabelnätet. Det kommer att kontrollera alla källadresser som inte är direkt på kabelnätet och tillåta validering mot till exempel statiska vägar för dirigerade subnät till kunder.

4.3.7., Access Control List (ACLs)

ACLs distribueras vanligen på gränsen Provider Edge (PE) – Customer Edge (CE), men är också mycket användbara på andra ställen som mot leverantörens egna server -, klient-och infrastrukturnätverk för att förhindra att enheter där inte missköter sig. Optimerad ACL strategi skulle vara att placera ett uttryckligt tillståndsfilter på kundgränssnittet. Explicit tillståndsfilter tillåter specifika adressintervall och nekar sedan allt annat. Till exempel, om operatörens kund tilldelas 192.0.2.0/24, BCP 38 ACL skulle tillåta alla källadresser från 192.0.2.,0/24 och Neka sedan alla paket vars källadress inte är 192.0.2.0 / 24.

på ISP: s nedströmsgränssnitt bör det finnas filter som verifierar källadresserna som används av dess kunder. Om uRPF inte kan användas krävs manuella ACL. Låt oss ta den första kunden från exempeldiagrammet ovan:

Cisco:

Juniper:

4.3.7.1., Aggregeringspunkter

När ACL vid pe-CE-gränsen inte är möjliga, till exempel eftersom flera kunder är anslutna till ett enda lager-2-nätverk och layer-2-enheterna inte har funktionerna att filtrera på layer-3-information, är filtrering vid en aggregeringspunkt den näst bästa lösningen.

i det här exemplet är det (av någon ospecificerad anledning) inte möjligt att filtrera på / 24 för varje kund. I så fall filtrering på 192.0.2.0 / 23 och 198.51.100.,0/23 (och på samma sätt för IPv6) vid en aggregeringspunkt nära kundanslutningarna skulle åtminstone begränsa spoofing möjligheterna för denna grupp av kunder till ett litet antal adresser.

konfigurationen görs på samma sätt som visas i föregående avsnitt, förutom nu görs det på en annan router på en mer central plats i nätverket.

4.3.8. Carrier Grade NAT-är Nat en anti-Spoof verktyg?

som standard filtrerar många nat-implementeringar inte källadressen för klienterna., Ta till exempel en enkel nat-konfiguration på en Cisco-router som:

 ip nat inside source list INSIDE pool OUTSIDE overload

denna nat-regel kommer att översätta paket med en källadress i åtkomstlistan inuti och ändra källadressen till en adress i poolen utanför. Paket som har en spoofed källadress som inte ingår i inside access-listan kommer dock att vidarebefordras utan någon översättning, vilket resulterar i spoofed paket på Internet., När ett spoofed-paket matchar åtkomstlistan kommer det att översättas med den angivna poolen, så omvärlden ser inte en spoofed källadress, men det blir omöjligt för Nat-operatören att spåra de spoofed-paketen tillbaka till deras upphovsman.

detta visar att NAT inte är ett anti-spoofing-verktyg. Även vid användning av NAT måste de källadresser som kunderna använder kontrolleras så nära kunden som möjligt, precis som i de fall utan NAT som visas tidigare i detta kapitel. Först då kan spoofed och / eller untraceable paket förhindras att nå Internet.

4.3.9., Ytterligare läsning