De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.
Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.
Cisco heeft verbeteringen geïmplementeerd in Cisco-producten voor kabelmodembeëindiging (CMTS) die bepaalde typen Denial of Service-aanvallen remmen op basis van IP-adresspoofing en IP-adresdiefstal in DOCSIS-kabelsystemen (Data-over-Cable Service Interface Specifications). De referentie voor Cisco CMTS-kabelopdracht beschrijft de reeks kabelbroncontrole van opdrachten die deel uitmaken van deze verbeteringen in IP-adresbeveiliging.
Raadpleeg Cisco Technical Tips Conventions (Conventies voor technische tips van Cisco) voor meer informatie over documentconventies.
Er zijn geen specifieke voorwaarden van toepassing op dit document.
Dit document is niet beperkt tot specifieke software- en hardware-versies.
Een DOCSIS Media Access Control (MAC)-domein is vergelijkbaar met een Ethernet-segment. Indien onbeschermd gelaten, zijn de gebruikers in het segment kwetsbaar aan vele types van Layer 2 en Layer 3 richtend gebaseerde Ontkenning van de dienst aanvallen. Daarnaast is het mogelijk dat gebruikers te lijden hebben van een verslechterd serviceniveau door de slechte configuratie van adressering op apparatuur van andere gebruikers. Voorbeelden hiervan zijn onder meer:
Dubbele IP-adressen op verschillende knooppunten configureren.
Dubbele MAC-adressen configureren op verschillende knooppunten.
Het onbevoegde gebruik van statische IP-adressen in plaats van Dynamic Host Configuration Protocol (DHCP) heeft IP-adressen toegewezen.
Onbevoegd gebruik van verschillende netwerknummers binnen een segment.
Onjuist configureren van eindknooppunten om ARP-verzoeken te beantwoorden namens een deel van het IP-netwerk van het segment.
Terwijl deze soorten problemen in een Ethernet LAN-omgeving eenvoudig te controleren en te verzachten zijn door de inbreukmakende apparatuur fysiek op te sporen en te ontkoppelen, kunnen dergelijke problemen in DOCSIS-netwerken moeilijker te isoleren, op te lossen en te voorkomen zijn vanwege de potentieel grote omvang van het netwerk. Bovendien kunnen eindgebruikers die de CPE (Customer Premise Equipment) besturen en configureren niet het voordeel hebben van een lokaal IS-ondersteuningsteam om ervoor te zorgen dat hun werkstations en pc’s niet opzettelijk of onbedoeld slecht geconfigureerd zijn.
De Cisco-suite van CMTS-producten onderhoudt een dynamisch gevulde interne database van verbonden CPE IP- en MAC-adressen. De CPE-database bevat ook informatie over de corresponderende kabelmodems waartoe deze CPE-apparaten behoren.
Een gedeeltelijke weergave van de CPE-database die overeenkomt met een bepaalde kabelmodem kan worden bekeken door de opdracht CMTS verborgen uit te voeren en interfacekabel X/Y-modem Z te tonen. Hier is X het lijnkaartnummer, Y het downstream poortnummer en Z is het Service Identifier (SID) van de kabelmodem. Z kan op 0 zijn ingesteld om de details van alle kabelmodems en CPE op een bepaalde downstream-interface te bekijken. Zie voorbeeld hieronder van een typische output die door dit bevel wordt geproduceerd.
CMTS# show interface cable 3/0 modem 0 SID Priv bits Type State IP address method MAC address 1 00 host unknown 192.168.1.77 static 000C.422c.54d0 1 00 modem up 10.1.1.30 dhcp 0001.9659.4447 2 00 host unknown 192.168.1.90 dhcp 00a1.52c9.75ad 2 00 modem up 10.1.1.44 dhcp 0090.9607.3831
Opmerking: omdat deze opdracht verborgen is, kan deze worden gewijzigd en is niet gegarandeerd dat deze beschikbaar is in alle releases van Cisco IOS®-software.
In het voorbeeld hierboven, is de methodekolom van de host met IP-adres 192.168.1.90 vermeld als dhcp. Dit betekent dat de CMTS over deze host heeft geleerd door de DHCP-transacties tussen de host en de DHCP-server van de serviceprovider te bekijken.
De host met IP-adres 192.168.1.77 wordt vermeld met methode statisch. Dit betekent dat de CMTS niet eerst van deze host heeft geleerd via een DHCP-transactie tussen dit apparaat en een DHCP-server. In plaats daarvan zag CMTS eerst andere soorten IP verkeer van deze host. Dit verkeer zou kunnen zijn web browsen, e-mail of "ping" pakketten.
Hoewel het kan lijken dat 192.168.1.77 is geconfigureerd met een statisch IP-adres, kan het zijn dat deze host in feite een DHCP-lease heeft verworven, maar de CMTS is mogelijk opnieuw opgestart sinds de gebeurtenis en daarom herinnert het de transactie niet.
De CPE-database wordt normaal ingevuld door de CMTS-overzichtsinformatie van de DHCP-transacties tussen CPE-apparaten en de DHCP-server van de serviceprovider. Bovendien kan CMTS naar ander IP verkeer luisteren dat van CPE apparaten komt om te bepalen welke CPE IP en MAC adressen tot welke Kabelmodems behoren.
Cisco heeft de kabelinterfaceopdrachtkabel bron-verify [dhcp] geïmplementeerd. Dit bevel veroorzaakt CMTS om gebruik te maken van het CPE gegevensbestand om de geldigheid van IP pakketten te verifiëren CMTS op zijn interfaces van de Kabel ontvangt en CMTS toestaat om intelligente besluiten te nemen over of om hen of niet door:sturen.
In het onderstaande stroomschema wordt aangegeven hoe een IP-pakket dat op een kabelinterface is ontvangen, extra moet worden verwerkt voordat het via de CMTS kan worden doorgevoerd.
Stroomschema 1
Het stroomschema begint met een pakket dat door een upstream poort op de CMTS wordt ontvangen en eindigt met het pakket dat verder mag worden verwerkt of dat in het pakket wordt gedropt.
Het eerste Denial of Service-scenario dat we zullen aanpakken, is de situatie met dubbele IP-adressen. Laten we zeggen dat klant A is verbonden met zijn serviceprovider en een geldige DHCP-lease heeft verkregen voor zijn PC. Het IP-adres dat door Klant A is verkregen, wordt X genoemd.
Enige tijd nadat A zijn DHCP-lease verwerft, besluit klant B om zijn PC te configureren met een statisch IP-adres dat toevallig hetzelfde is als het adres dat momenteel wordt gebruikt door de apparatuur van klant A. De informatie van de CPE- Gegevensbank met betrekking tot IP adres X zou veranderen afhankelijk van welk CPE apparaat het laatst een ARP verzoek namens X verzond.
In een onbeschermd DOCSIS-netwerk kan Klant B mogelijk de volgende hop router (in de meeste gevallen CMTS) overtuigen dat hij het recht heeft om IP-adres X te gebruiken door eenvoudig een ARP-verzoek namens X naar de CMTS of next-hop router te verzenden. Dit zou verhinderen dat het verkeer van de dienstverlener naar klant A wordt doorgestuurd.
Door kabel toe te laten bron-verifieert, zou CMTS kunnen zien dat IP en ARP de pakketten voor IP adres X van de verkeerde kabelmodem werden voorzien en vandaar, zouden deze pakketten worden gelaten vallen, zie Stroomschema 2. Dit omvat alle IP pakketten met bronadres X en ARP verzoeken namens X. De CMTS logboeken zouden een bericht langs de lijnen van tonen:
%UBR7200-3 BADIPSOURCE: Interface Cable3/0, IP-pakket uit ongeldige bron. IP=192.168.1.10, MAC=0001.422c.54d0, verwacht SID=10, feitelijk SID=11
Stroomschema 2
Met deze informatie worden beide clients geïdentificeerd en kan de kabelmodem met het aangesloten dubbele IP-adres worden uitgeschakeld.
Een ander scenario is voor een gebruiker om een ongebruikt nog IP adres aan hun PC statisch toe te wijzen die binnen de wettige waaier van CPE adressen valt. Dit scenario veroorzaakt geen verstoring van de diensten aan iedereen in het netwerk. Laat ons zeggen dat klant B adres Y voor hun PC heeft toegewezen.
Het volgende probleem dat zich kan voordoen is dat Klant C zijn werkstation kan verbinden met het netwerk van de serviceprovider en een DHCP-lease voor IP-adres Y kan verkrijgen. De CPE-database zou IP-adres Y tijdelijk markeren als onderdeel van de kabelmodem van Klant C. Het kan echter niet lang duren voordat Klant B, de niet-legitieme gebruiker de juiste volgorde van ARP-verkeer stuurt om de volgende-hop ervan te overtuigen dat hij de legitieme eigenaar van IP-adres Y was, waardoor een onderbreking van de dienst van Klant C.
Op dezelfde manier kan het tweede probleem worden opgelost door de kabelbron aan te zetten-verifieert. Wanneer de kabel-bron-verify is ingeschakeld, kan een CPE-database-ingang die is gegenereerd door informatie te verzamelen uit een DHCP-transactie niet worden verplaatst door andere soorten IP-verkeer. Alleen een andere DHCP-transactie voor dat IP-adres of de ARP-vermelding op de CMTS-timing voor dat IP-adres kan de ingang verplaatsen. Dit zorgt ervoor dat als een eindgebruiker met succes een DHCP-lease voor een bepaald IP-adres verwerft, dat de klant zich geen zorgen hoeft te maken over CMTS dat verward raakt en denkt dat zijn IP-adres aan een andere gebruiker toebehoort.
Het eerste probleem van het verhinderen dat gebruikers nog ongebruikte IP-adressen gebruiken, kan worden opgelost met dhcp via de kabel. Door de dhcp parameter aan het eind van dit bevel toe te voegen, kan CMTS de geldigheid van elk nieuw bronIP adres controleren het over door een speciaal type van DHCP bericht uit te geven genoemd een LEASEQUERY aan de server van DHCP. Zie stroomschema 3.
Stroomschema 3
Voor een bepaald CPE IP-adres vraagt het LEASEQUERY-bericht wat het corresponderende MAC-adres en de kabelmodem zijn.
In deze situatie, als Klant B zijn werkstation met het kabelnetwerk met statisch adres Y verbindt, zal CMTS een LEASEQUERY naar de server van DHCP verzenden om te verifiëren of adres Y aan PC van Klant B is geleased. De DHCP-server kan de CMTS ervan op de hoogte stellen dat er geen lease is verleend voor IP-adres Y en dus zal de toegang voor klant B worden geweigerd.
Gebruikers kunnen werkstations achter hun kabelmodems hebben geconfigureerd met statische IP-adressen die mogelijk niet conflicteren met de huidige netwerknummers van de serviceprovider, maar die in de toekomst problemen kunnen veroorzaken. Daarom met behulp van kabel bron-verify, is een CMTS in staat om pakketten uit te filteren die afkomstig zijn van IP-bronadressen die niet van het bereik zijn dat op de kabelinterface van CMTS is geconfigureerd.
Opmerking: om dit goed te laten werken, moet u ook de opdracht unicast reverse-path configureren om gespoofde IP-bronadressen te voorkomen. Raadpleeg Kabelopdrachten: kabel is voor meer informatie.
Sommige klanten kunnen een router als CPE apparaat hebben en voor de dienstverlener schikken om verkeer aan deze router te leiden. Als CMTS IP verkeer van de CPE router met een bron IP adres van Z ontvangt, dan zal de kabel bron-verifieert dit pakket door laten als CMTS een route aan het netwerk Z tot via dat CPE apparaat behoort heeft. Raadpleeg stroomschema 3.
Neem nu het volgende voorbeeld:
Op de CMTS hebben we de volgende configuratie:
interface cable 3/0 ip verify unicast reverse-path ip address 10.1.1.1 255.255.255.0 ip address 24.1.1.1 255.255.255.0 secondary cable source-verify ! ip route 24.2.2.0 255.255.255.0 24.1.1.2 Note: This configuration shows only what is relevant for this example
Ervan uitgaande dat een pakket met IP-bronadres 172.16.1.10 bij CMTS van kabelmodem 24.2.2.10 is aangekomen, zou CMTS zien dat 24.2.2.10 niet in de CPE-database zit, zou de kabel x/y modem 0 tonen, maar ip verifieert unicast reverse-path Unicast Reverse Path Forwarding (Unicast RPF), die elk pakket controleert dat op een interface wordt ontvangen om te verifiëren dat het IP-bronadres van het pakket wordt weergegeven in de routingstabellen die bij die interface horen zijn. De kabelbron-verify controleert om te zien wat de volgende hop voor 24.2.2.10 is. In de configuratie hierboven hebben we ip route 24.2.2.0 255.255.255.0 24.1.1.2 wat betekent dat de volgende hop 24.1.1.2 is. Aangenomen dat 24.1.1.2 een geldige ingang is in de CPE database, concludeert CMTS dat het pakket OK is en zal dus het pakket verwerken volgens Flowchart 4.
Stroomschema 4
Het configureren van de kabelbron-verify impliceert simpelweg het toevoegen van de kabel-bron-verify-opdracht aan de kabelinterface waarop u de functie wilt activeren. Als u de bundeling van de kabelinterface gebruikt, dan moet u kabel toevoegen bron-verifieert aan de configuratie van de primaire interface.
Hoe te om kabelbron te vormen-verifieer dhcp
Opmerking: Cable Source-verify werd eerst geïntroduceerd in Cisco IOS-softwarerelease 12.0(7)T en wordt ondersteund in Cisco IOS-softwarereleases 12.0SC, 12.1EC en 12.1T.
Het configureren van de kabelbron-verify DHCP vereist een paar stappen.
Zorg ervoor dat uw DHCP-server het speciale DHCP LEASEQUERY-bericht ondersteunt.
Om gebruik te maken van de dhcp-functionaliteit van de kabelbron te verifiëren, moet uw DHCP-server antwoorden op de berichten zoals gespecificeerd door Draft-ietf-dhcp-leasequery-XX.txt. Versie 3.5 en hoger van Cisco Network Registrar kunnen op dit bericht reageren.
Zorg dat de DHCP-server de verwerking van Relay Agent Information Option ondersteunt. Raadpleeg het gedeelte Relay Agent.
Een andere functie die moet worden ondersteund door uw DHCP-server is de verwerking van DHCP Relay Information Option. Dit wordt ook wel Optie 82-verwerking genoemd. Deze optie wordt beschreven in DHCP Relay Information Option (RFC 3046). Versies van Cisco Network Registrar 3.5 en hoger ondersteunen de verwerking van Relay Agent Information Option, maar deze moet worden geactiveerd via het hulpprogramma NRCMD van de opdrachtregel voor Cisco Network Registrar met de volgende reeks opdrachten:
nrcmd -U admin -P change -C 127.0.0.1 dhcp maakt opslaan-relay-agent-data mogelijk
nrcmd -U admin -P changeme -C 127.0.0.1 opslaan
nrcmd -U admin -P change -C 127.0.0.1 dhcp reload
Het kan nodig zijn de juiste gebruikersnaam, wachtwoord en IP-adres van de server te vervangen. De bovenstaande waarden worden standaard weergegeven. Als u de nrcmd-prompt is, >nrcmd, typt u alleen het volgende:
DHCP maakt het opslaan-relay-agent-data mogelijk
sparen
DHCP-herlading
Schakel de verwerking van DHCP-relay-informatie in op de CMTS.
CMTS moet DHCP-verzoeken van kabelmodems en CPE labelen met de Relay Agent Information Option zodat dhcp via de kabel effectief kan worden geverifieerd. De volgende opdrachten moeten in de globale configuratiemodus worden ingevoerd op een CMTS waarop Cisco IOS-softwarereleases 12.1EC, 12.1T of hoger versies van Cisco IOS worden uitgevoerd.
Optie met informatie over IP DHCP-relay
Als in uw CMTS Cisco IOS-softwarereleases 12.0SC worden uitgevoerd, train u Cisco IOS-software en gebruikt u in plaats daarvan de opdracht Cable Relay-Agent-Option Cable Interface.
Zorg ervoor dat u de juiste opdrachten gebruikt, afhankelijk van de versie van Cisco IOS die u uitvoert. Zorg ervoor dat u uw configuratie bijwerkt als u de treinen van Cisco IOS wijzigt.
De opdrachten voor de optie Relay Information voegen een speciale optie, Optie 82, of de optie Relay Information, toe aan het doorgestuurde DHCP-pakket wanneer de CMTS DHCP-pakketten doorgeeft.
Optie 82 is gevuld met een suboptie, de Agent Circuit-ID, die verwijst naar de fysieke interface op de CMTS waarop het DHCP-verzoek werd gehoord. Daarnaast is een andere suboptie, de Agent Remote ID, gevuld met het 6-byte MAC-adres van de kabelmodem waarvan het DHCP-verzoek is ontvangen of doorgegeven.
Zo, bijvoorbeeld, als een PC met het adres van MAC 99:88:77:66:55:44 die achter kabelmodem aa:bb:cc:dd:ee:ff een DHCP- verzoek verzendt, zal CMTS het DHCP- verzoek door:sturen dat de Suboptie van de Agent Remote ID van Optie 82 plaatst aan het adres van MAC van de Kabelmodem, aa:bb:cc:dd:ee:ff.
Door de Optie van de Informatie van het Relay inbegrepen binnen het DHCP- verzoek van een CPE apparaat te hebben, kan de server van DHCP informatie opslaan waarover CPE achter welke Kabelmodems behoort. Dit wordt vooral nuttig wanneer kabel bron-verify dhcp op CMTS is geconfigureerd, aangezien de DHCP-server CMTS betrouwbaar kan informeren over niet alleen wat MAC-adres een bepaalde client moet hebben, maar ook welke kabelmodem-specifieke client moet worden aangesloten.
Schakel de opdracht DHCP via kabelbron verifiëren in onder de juiste kabelinterface.
De laatste stap is om de kabel bron-verify dhcp-opdracht in te voeren onder de kabelinterface waarop u de functie wilt activeren. Als de CMTS kabelinterfacebundeling gebruikt, moet u de opdracht invoeren onder de primaire interface van de bundel.
Met de verificatie van de kabelbron kunnen bepaalde opdrachten een serviceprovider in staat stellen het kabelnetwerk te beschermen tegen gebruikers met onbevoegde IP-adressen om het netwerk te gebruiken.
De kabel bron-verify opdracht is op zichzelf een effectieve en makkelijke manier om IP-adresbeveiliging te implementeren. Hoewel het niet alle scenario's bestrijkt, zorgt het er in ieder geval voor dat klanten met het recht om toegewezen IP-adressen te gebruiken, geen storingen zullen ondervinden door hun IP-adres te laten gebruiken door iemand anders.
In de eenvoudigste vorm zoals beschreven in dit document kan een CPE-apparaat dat niet via DHCP is geconfigureerd geen netwerktoegang verkrijgen. Dit is de beste manier om IP-adresruimte te beveiligen en de stabiliteit en betrouwbaarheid van een Data-over-Cable-service te verhogen. MSO’s die commerciële diensten hebben die hen verplichten om statische adressen te gebruiken, wilden echter strikte beveiliging van de opdrachtkabel implementeren en de dhcp verifiëren.
Cisco Network Registrar versie 5.5 heeft een nieuwe mogelijkheid om te reageren op de lease-query voor "gereserveerde" adressen, ook al is het IP-adres niet verkregen via DHCP. De DHCP-server bevat de gegevens van de huurreservering in de DHCPLEEQUERY-antwoorden. In de vorige versies van Network Registrar waren de DHCPLEEQUERY-antwoorden alleen mogelijk voor geleasede of eerder geleasede klanten waarvoor het MAC-adres was opgeslagen. Cisco uBR relay-agents, bijvoorbeeld, verwerpen DHCP-pretery-datagrammen die geen MAC-adres en -leasetijd hebben (DHCP-lease-time optie).
Network Registrar geeft een standaardleasetijd van één jaar (31536000 seconden) terug voor gereserveerde leases in een DHCPLEEQUERY-antwoord. Als het adres daadwerkelijk wordt geleased, geeft de netwerkregistratieserver de resterende leasetijd terug.