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.
In dit document wordt beschreven hoe u uw Cisco IOS®-systeemapparaten kunt beveiligen om de algehele security van uw netwerk te verbeteren. Gestructureerd rond de drie vlakken waarin de functies van een netwerkapparaat kunnen worden gecategoriseerd, biedt dit document een overzicht van elke meegeleverde functie en verwijzingen naar verwante documentatie.
Er zijn geen specifieke vereisten van toepassing op dit document.
Dit document is niet beperkt tot specifieke software- en hardware-versies.
De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u de potentiële impact van elke opdracht begrijpen.
De drie functionele vlakken van een netwerk, het beheervlak, het controlevlak, en het gegevensvlak, elk verstrekken verschillende functionaliteit die moet worden beschermd.
De dekking van veiligheidseigenschappen in dit document verstrekt vaak genoeg detail voor u om de eigenschap te vormen. In gevallen waarin dit niet het geval is, wordt de functie op een zodanige manier uitgelegd dat u kunt beoordelen of extra aandacht voor de functie vereist is. Waar mogelijk en passend bevat dit document aanbevelingen die, indien geïmplementeerd, helpen een netwerk te beveiligen.
Beveiligde netwerkactiviteiten is een belangrijk onderwerp. Hoewel het grootste deel van dit document is toegewijd aan de beveiligde configuratie van een Cisco IOS-apparaat, zorgen configuraties alleen niet voor de volledige beveiliging van een netwerk. De operationele procedures die in gebruik zijn op het netwerk, dragen net zoveel bij aan de beveiliging als de configuratie van de onderliggende apparaten.
Deze onderwerpen bevatten operationele aanbevelingen die u wordt geadviseerd te implementeren. Deze onderwerpen lichten specifieke essentiële gebieden van netwerkactiviteiten uit en zijn niet allesomvattend.
Het Cisco Product Security Incident Response Team (PSIRT) maakt en onderhoudt publicaties, ook wel PSIRT Advisories genoemd, voor beveiligingsgerelateerde problemen in Cisco-producten. De gebruikte methode voor communicatie van minder ernstige problemen is de Cisco Security Response. Security advisories en reacties zijn beschikbaar op http://www.cisco.com/go/psirt.
Aanvullende informatie over deze communicatiemiddelen is beschikbaar in het Cisco-beleid inzake beveiligingsincidenten.
Om een veilig netwerk te kunnen onderhouden, moet u bekend zijn met de beveiligingsadviezen en antwoorden van Cisco die zijn vrijgegeven. U moet op de hoogte zijn van een kwetsbaarheid voordat de dreiging die deze op een netwerk kan hebben, kan worden geëvalueerd. Raadpleeg Risk Triage voor Security Vulnerability aankondigingen voor hulp bij dit evaluatieproces.
Het AAA-framework (verificatie, autorisatie en accounting) is essentieel voor beveiligde netwerkapparaten. Het AAA-framework biedt verificatie van beheersessies en kan ook gebruikers beperken tot specifieke, door beheerders gedefinieerde opdrachten en alle opdrachten vastleggen die door alle gebruikers worden ingevoerd. Bekijk het gedeelte Verificatie, autorisatie en accounting van dit document voor meer informatie over hoe u AAA kunt inzetten.
Om kennis te verkrijgen over bestaande, opkomende en historische gebeurtenissen die verband houden met beveiligingsincidenten, moet uw organisatie een uniforme strategie hebben voor logboekregistratie en correlatie. Deze strategie moet gebruik maken van vastlegging vanaf alle netwerkapparaten en gebruik maken van voorverpakte en aanpasbare correlatiemogelijkheden.
Nadat gecentraliseerde vastlegging is geïmplementeerd, moet u een gestructureerde aanpak voor loganalyse en incidenttracering ontwikkelen. Aan de hand van de behoeften van uw organisatie kan deze aanpak variëren van een eenvoudige zorgvuldige beoordeling van logboekgegevens tot geavanceerde op regels gebaseerde analyse.
Zie de sectie Best practices voor vastlegging van dit document voor meer informatie over het implementeren van vastlegging op Cisco IOS-netwerkapparaten.
Veel protocollen worden gebruikt om gevoelige netwerkbeheergegevens over te dragen. U moet waar mogelijk gebruik maken van beveiligde protocollen. Een beveiligde protocolkeuze omvat het gebruik van SSH in plaats van Telnet zodat zowel de verificatiegegevens als de beheerinformatie worden versleuteld. Daarnaast moet u beveiligde protocollen voor bestandsoverdracht gebruiken wanneer u configuratiegegevens kopieert. Een voorbeeld is het gebruik van het Secure Copy Protocol (SCP) in plaats van FTP of TFTP.
Zie het gedeelte Interactieve beheersessies beveiligen van dit document voor meer informatie over het beveiligde beheer van Cisco IOS-apparaten.
Met NetFlow kunt u verkeersstromen in het netwerk bewaken. Oorspronkelijk bedoeld om verkeersinformatie naar netwerkbeheertoepassingen uit te voeren, kan NetFlow ook worden gebruikt om stroominformatie over een router te tonen. Met deze mogelijkheid kunt u in real-time zien welk verkeer door het netwerk beweegt. Ongeacht of stroominformatie wordt geëxporteerd naar een externe collector, wordt u aangeraden om netwerkapparaten te configureren voor NetFlow zodat het reactief kan worden gebruikt indien nodig.
Meer informatie over deze functie is beschikbaar in de sectie Traffic Identification and Traceback van dit document en op http://www.cisco.com/go/netflow (alleen geregistreerde klanten).
Configuratiebeheer is een proces waarmee configuratiewijzigingen worden voorgesteld, beoordeeld, goedgekeurd en geïmplementeerd. Binnen de context van een Cisco IOS-apparaatconfiguratie zijn twee aanvullende aspecten van configuratiebeheer essentieel: configuratie-archivering en -beveiliging.
U kunt configuratie archieven gebruiken om veranderingen terug te rollen die aan netwerkapparaten worden gemaakt. In een beveiligingscontext kunnen ook configuratie-archieven worden gebruikt om te bepalen welke beveiligingswijzigingen zijn aangebracht en wanneer deze wijzigingen hebben plaatsgevonden. In combinatie met AAA-loggegevens kan deze informatie helpen bij de veiligheidscontrole van netwerkapparaten.
De configuratie van een Cisco IOS-apparaat bevat veel gevoelige gegevens. Gebruikersnamen, wachtwoorden en de inhoud van toegangscontrolelijsten zijn voorbeelden van dit soort informatie. De opslagplaats die u gebruikt om Cisco IOS-apparaatconfiguraties te archiveren moet worden beveiligd. Onbeveiligde toegang tot deze informatie kan de beveiliging van het volledige netwerk ondermijnen.
De beheerplane bestaat uit functies die de beheerdoelen van het netwerk behalen. Hieronder vallen interactieve beheersessies die SSH gebruiken, evenals statistiekverzameling met SNMP of NetFlow. Wanneer u de veiligheid van een netwerkapparaat overweegt, is het kritiek dat het beheervliegtuig wordt beschermd. Als een veiligheidsincident de functies van het beheervliegtuig kan ondermijnen, kan het voor u onmogelijk zijn om het netwerk terug te krijgen of te stabiliseren.
Deze gedeelten van dit document bespreken de beveiligingsfuncties en configuraties die beschikbaar zijn in Cisco IOS-software die de beheerplane versterken.
Het beheervliegtuig wordt gebruikt om toegang te hebben tot, een apparaat te vormen en te beheren, evenals zijn verrichtingen en het netwerk te controleren waarop het wordt opgesteld. Het managementvliegtuig is het vliegtuig dat verkeer ontvangt en verstuurt voor de werking van deze functies. U moet zowel het managementvliegtuig als het bedieningsvliegtuig van een apparaat beveiligen, omdat de handelingen van het bedieningsvliegtuig rechtstreeks van invloed zijn op de handelingen van het managementvliegtuig. Deze lijst van protocollen wordt gebruikt door het managementvliegtuig:
Er moeten stappen worden ondernomen om ervoor te zorgen dat de beheer- en besturingsplane beveiligingsincidenten doorstaan. Als een van deze vliegtuigen met succes wordt geëxploiteerd, kunnen alle vliegtuigen worden gecompromitteerd.
Wachtwoorden beheren de toegang tot bronnen of apparaten. Dit wordt bereikt door de definitie van een wachtwoord of geheim dat wordt gebruikt om verzoeken te verifiëren. Wanneer een verzoek om toegang tot een middel of een apparaat wordt ontvangen, wordt het verzoek betwist voor controle van het wachtwoord en de identiteit, en de toegang kan worden verleend, worden ontkend, of worden beperkt gebaseerd op het resultaat. Als aanbevolen procedure voor beveiliging moeten wachtwoorden worden beheerd met een TACACS+- of RADIUS-verificatieserver. Houd er echter rekening mee dat een lokaal ingesteld wachtwoord voor geprivilegieerde toegang nog steeds nodig is in geval van een storing van de TACACS+- of RADIUS-services. Op een apparaat kan ook andere wachtwoordinformatie aanwezig zijn binnen de configuratie, zoals een NTP-sleutel, SNMP-communitystring of Routing Protocol-sleutel.
De opdracht Laat geheim toe wordt gebruikt om het wachtwoord in te stellen dat bevoorrechte administratieve toegang tot het Cisco IOS-systeem verleent. De opdracht enable secret moet worden gebruikt in plaats van de oudere opdracht enable password. De opdracht enable password gebruikt een zwak versleutelingsalgoritme.
Als geen inschakelen geheim is ingesteld en een wachtwoord is ingesteld voor de console tty line, kan het console wachtwoord worden gebruikt om geprivilegieerde toegang te ontvangen, zelfs vanaf een externe virtuele tty (vty) sessie. Deze actie is bijna zeker ongewenst en het is nog een reden om te zorgen voor configuratie van de opdracht enable secret.
De globale configuratie-opdracht service password-encryption instrueert de Cisco IOS-software om de wachtwoorden, CHAP-geheimen (Challenge Handshake Authentication Protocol) en vergelijkbare gegevens opgeslagen in het bijbehorende configuratiebestand te versleutelen. Een dergelijke codering is nuttig om te voorkomen dat toevallige waarnemers wachtwoorden kunnen lezen, bijvoorbeeld wanneer zij over het scherm van een beheerder kijken. Het algoritme dat wordt gebruikt door de opdracht service password-encryption is echter een eenvoudige Vigen re-codering. Het algoritme is niet ontworpen om configuratiebestanden te beschermen tegen aanzienlijke analyse door zelfs enigszins geavanceerde aanvallers en mag niet voor dit doel worden gebruikt. Elk Cisco IOS-configuratiebestand dat versleutelde wachtwoorden bevat, moet worden behandeld met dezelfde zorg waarmee een leesbare lijst met diezelfde wachtwoorden wordt behandeld.
Hoewel dit zwakke versleutelingsalgoritme niet wordt gebruikt door de opdracht enable secret, wordt het wel gebruikt door de globale configuratie-opdracht enable password, evenals door de lijnconfiguratie-opdracht password. Wachtwoorden van dit type moeten worden verwijderd en de optie Laat geheime opdracht toe of de optie Verbeterde wachtwoordbeveiliging moet worden gebruikt.
De opdracht enable secret en de functie Verbeterde wachtwoordbeveiliging gebruiken Message Digest 5 (MD5) voor wachtwoordhashing. Dit algoritme heeft aanzienlijke publieke beoordeling ondergaan en staat niet bekend als omkeerbaar. Het algoritme heeft echter te maken met woordenboekaanvallen. Bij een woordenboekaanval probeert een aanvaller elk woord in een woordenboek of een andere lijst met kandidaat-wachtwoorden om een overeenkomst te vinden. Daarom moeten configuratiebestanden beveiligd worden opgeslagen en alleen worden gedeeld met vertrouwde personen.
Met de functie Verbeterde wachtwoordbeveiliging, geïntroduceerd in Cisco IOS-softwarerelease 12.2(8)T, kan een beheerder MD5-hashing van wachtwoorden voor de opdracht username configureren. Voorafgaand aan deze functie waren er twee soorten wachtwoorden: Type 0, dat een cleartext wachtwoord is, en Type 7, dat het algoritme van het Vigen re algoritme gebruikt. De functie Verbeterde wachtwoordbeveiliging kan niet worden gebruikt met protocollen die vereisen dat het leesbare wachtwoord op te halen is, zoals CHAP.
Om een gebruikerswachtwoord te versleutelen met MD5-hashing, moet u de opdracht voor de wereldwijde configuratie van de gebruikersnaam en het geheime wachtwoord opgeven.
!
username <name> secret <password>
!
Raadpleeg Verbeterde wachtwoordbeveiliging voor meer informatie over deze functie.
De functie 'Blokkering voor opnieuw aanmelden met wachtwoord' is toegevoegd in Cisco IOS-softwarerelease 12.3(14)T en hiermee kunt u een lokaal gebruikersaccount blokkeren na een geconfigureerd aantal mislukte aanmeldpogingen. Wanneer een gebruiker is geblokkeerd, is het account van deze gebruiker vergrendeld totdat u dit ontgrendelt. Een geautoriseerde gebruiker die is geconfigureerd met prioriteitsniveau 15 kan niet worden uitgesloten met deze functie. Het aantal gebruikers met voorrangsniveau 15 moet tot een minimum worden beperkt.
Let op: geautoriseerde gebruikers kunnen zichzelf blokkeren voor een apparaat als het aantal mislukte aanmeldpogingen is bereikt. Bovendien kan een kwaadwillende gebruiker een DoS-voorwaarde (denial of service) maken met herhaalde pogingen voor verificatie met een geldige gebruikersnaam.
Dit voorbeeld laat zien hoe u de functie 'Blokkering voor opnieuw aanmelden met wachtwoord' kunt inschakelen:
!
aaa new-model
aaa local authentication attempts max-fail <max-attempts>
aaa authentication login default local
!
username <name> secret <password>
!
Deze optie is ook van toepassing op verificatiemethoden zoals CHAP en Password Authentication Protocol (PAP).
In Cisco IOS-softwarerelease 12.3(14)T en hoger zorgt de functie 'Geen service wachtwoordherstel' ervoor dat niemand met consoletoegang onbeveiligde toegang krijgt tot de apparaatconfiguratie en het wachtwoord kan wissen. Ook wordt voorkomen dat kwaadwillende gebruikers de configuratieregisterwaarde wijzigen en toegang krijgen tot NVRAM.
!
no service password-recovery
!
Cisco IOS-software biedt een wachtwoordherstelprocedure die afhankelijk is van toegang tot de ROM Monitor Mode (ROMMON) met behulp van de Break-toets tijdens het opstarten van het systeem. In ROMMON kan de apparaatsoftware worden herladen om een nieuwe systeemconfiguratie met een nieuw wachtwoord te starten.
Met de huidige wachtwoordherstelprocedure heeft iedereen met consoletoegang toegang tot het apparaat en het bijbehorende netwerk. Met de functie 'Geen service wachtwoordherstel' wordt het voltooien van de Break-toetscombinatie en het invoeren van ROMMON tijdens systeemopstart voorkomen.
Als op een apparaat geen wachtwoordherstel is ingeschakeld, wordt aanbevolen om een offline kopie van de apparaatconfiguratie op te slaan en een oplossing voor configuratie-archivering te implementeren. Als het nodig is om het wachtwoord van een Cisco IOS-apparaat te herstellen zodra deze functie is ingeschakeld, wordt de volledige configuratie verwijderd.
Raadpleeg Voorbeeld van beveiligde ROMMON-configuratie voor meer informatie over deze functie.
Als best practice op het gebied van beveiliging moet alle overbodige service worden uitgeschakeld. Deze onnodige diensten, vooral die die het Protocol van het Datagram van de Gebruiker (UDP) gebruiken, worden niet vaak gebruikt voor wettige doeleinden maar kunnen worden gebruikt om Dos en andere aanvallen te lanceren die anders door pakketfiltering worden verhinderd.
De kleine TCP- en UDP-services moeten worden uitgeschakeld. Deze services zijn onder andere:
Hoewel misbruik van de kleine diensten kan worden voorkomen of minder gevaarlijk kan worden gemaakt door toegangslijsten tegen spoofing, moeten de diensten worden uitgeschakeld op elk apparaat dat binnen het netwerk toegankelijk is. De kleine services worden standaard uitgeschakeld in Cisco IOS-softwarereleases 12.0 en hoger. In eerdere software kunnen de globale configuratieopdrachten geen service-TCP-small-servers en geen service-udp-small-servers worden gegenereerd om ze uit te schakelen.
Dit is een lijst van aanvullende diensten die moeten worden uitgeschakeld als ze niet worden gebruikt:
Om het interval in te stellen dat de EXEC-opdrachttolk wacht op gebruikersinvoer voordat een sessie wordt beëindigd, moet u de opdracht voor configuratie van de exec-tijdlijn uitgeven. De opdracht exec-timeout moet worden gebruikt om sessies uit te loggen op vty of tty lijnen die niet worden gebruikt. Standaard wordt de verbinding van sessies na tien minuten inactiviteit verbroken.
!
line con 0
exec-timeout <minutes> [seconds]
line vty 0 4
exec-timeout <minutes> [seconds]
!
Met de globale configuratie-opdrachten service tcp-keepalives-in en service tcp-keepalives-out kan een apparaat TCP-keepalives verzenden voor TCP-sessies. Deze configuratie moet worden gebruikt om TCP-keepalives op inkomende verbindingen met het apparaat en uitgaande verbindingen vanaf het apparaat in te schakelen. Dit waarborgt dat het apparaat op het verre eind van de verbinding nog toegankelijk is en dat de half-open of orphaned verbindingen worden verwijderd uit het lokale Cisco IOS-apparaat.
!
service tcp-keepalives-in
service tcp-keepalives-out
!
De beheerplane van een apparaat wordt in-band of out-of-band geopend op een fysieke of logische beheerinterface. Idealiter bestaat zowel in-band als out-of-band beheertoegang voor elk netwerkapparaat zodat het beheervliegtuig kan worden benaderd tijdens netwerkuitval.
Een van de meest voorkomende interfaces die gebruikt worden voor in-band toegang tot een apparaat is de logische loopback interface. Loopback-interfaces zijn altijd actief, terwijl fysieke interfaces van status kunnen veranderen, en de interface mogelijk niet toegankelijk is. Aanbevolen wordt om een loopback-interface als beheerinterface aan elk apparaat toe te voegen en deze uitsluitend voor het beheervlak te gebruiken. Zo kan de beheerder beleidsregels toepassen in het netwerk voor de beheerplane. Zodra de loopbackinterface op een apparaat is geconfigureerd, kan deze worden gebruikt door beheerplatformprotocollen zoals SSH, SNMP en syslog om verkeer te verzenden en ontvangen.
!
interface Loopback0
ip address 192.168.1.1 255.255.255.0
!
Met de melding "Memory Stick" die is toegevoegd in Cisco IOS-softwarerelease 12.3(4)T, kunt u omstandigheden die weinig geheugen op een apparaat vereisen, verzachten. Om dit voor elkaar te krijgen gebruikt deze functie twee methoden: Memory Threshold Notification en Memory Reservation.
Memory Threshold Notification genereert een logbericht om aan te geven dat het vrije geheugen op een apparaat is gedaald tot onder de ingestelde drempelwaarde. Dit configuratievoorbeeld laat zien hoe u deze functie kunt inschakelen met de globale configuratie-opdracht memory free low-watermark. Zo kan een apparaat een melding genereren wanneer beschikbaar geheugen een lager niveau bereikt dan de opgegeven drempelwaarde, en opnieuw wanneer beschikbaar geheugen weer vijf procent hoger is dan de opgegeven drempelwaarde.
!
memory free low-watermark processor <threshold>
memory free low-watermark io <threshold>
!
Geheugenreservering wordt gebruikt zodat er voldoende geheugen beschikbaar is voor kritische meldingen. Dit configuratievoorbeeld toont aan hoe deze eigenschap toe te laten. Dit zorgt ervoor dat de beheerprocessen blijven functioneren wanneer het geheugen van het apparaat is uitgeput.
!
memory reserve critical <value> !
Raadpleeg Meldingen voor geheugendrempel voor meer informatie over deze functie.
Geïntroduceerd in Cisco IOS-softwarerelease 12.3(4)T, kunt u met de functie CPU-melding van drempels detecteren en hiervan op de hoogte worden gesteld wanneer de CPU-belasting op een apparaat een geconfigureerde drempel overschrijdt. Wanneer de drempelwaarde wordt overschreden, genereert en verzendt het apparaat een SNMP-trapbericht. Twee methoden voor het toepassen van CPU-drempels worden ondersteund op Cisco IOS-software: Drempelwaarde voor verhoging en dalingsdrempel.
Deze voorbeeldconfiguratie laat zien hoe de drempelwaarden voor het opstijgen en dalen kunnen worden ingeschakeld die een melding van een CPU-drempelwaarde genereren:
!
snmp-server enable traps cpu threshold
!
snmp-server host <host-address> <community-string> cpu
!
process cpu threshold type <type> rising <percentage> interval <seconds>
[falling <percentage> interval <seconds>]
process cpu statistics limit entry-percentage <number> [size <seconds>]
!
Raadpleeg Melding voor CPU-drempel voor meer informatie over deze functie.
In Cisco IOS-softwarerelease 12.4(15)T en hoger kan de functie Geheugen voor console-toegang worden gebruikt om voldoende geheugen te reserveren om de toegang tot een Cisco IOS-apparaat voor beheersen en probleemoplossing te garanderen. Deze eigenschap is vooral voordelig wanneer het apparaat laag op geheugen loopt. U kunt de globale configuratieopdracht voor de geheugenreserveconsole uitgeven om deze functie in te schakelen. Dit voorbeeld configureert een Cisco IOS-apparaat om 4096 kilobytes voor dit doel te reserveren.
!
memory reserve console 4096
!
Raadpleeg Geheugen reserveren voor consoletoegang voor meer informatie over deze functie.
De functie 'Geheugenlekdetector' is geïntroduceerd in Cisco IOS-softwarerelease 12.3(8)T1 en hiermee kunt u geheugenlekken op een apparaat detecteren. Geheugen lek Detector is in staat om lekken te vinden in alle geheugenpools, pakketbuffers en stukjes. Geheugenlekken zijn statische of dynamische toekenningen van geheugen die geen nuttig doel dienen. Deze functie is gericht op geheugentoekenningen die dynamisch zijn. U kunt de show geheugen debug lekken EXEC commando gebruiken om te detecteren als een geheugen lek bestaat.
In Cisco IOS-softwarerelease 12.3(7)T en hoger kan de functie Buffer Overflow: Detectie en correctie van Redzone Corruptie worden ingeschakeld op een apparaat om een overflow van het geheugenblok te detecteren en te corrigeren en de bewerkingen voort te zetten.
Deze globale configuratiebevelen kunnen worden gebruikt om deze eigenschap toe te laten. Na configuratie kan de opdracht overflow van het showgeheugen worden gebruikt om de detectie- en correctiestatistieken van de buffer-overflow weer te geven.
!
exception memory ignore overflow io
exception memory ignore overflow processor
!
De functie 'Verbeterde verzameling van bestand met crashinformatie' verwijdert automatisch oude bestanden met crashinformatie. Deze eigenschap, die in Cisco IOS-softwarerelease 12.3(11)T wordt toegevoegd, staat een apparaat toe om ruimte terug te winnen om nieuwe crashinfo-bestanden te creëren wanneer het apparaat crasht. Met deze functie kan ook het aantal crashinfo-bestanden worden opgeslagen.
!
exception crashinfo maximum files <number-of-files>
!
Het Network Time Protocol (NTP) is geen bijzonder gevaarlijke service, maar elke onnodige service kan een aanvalsvector vertegenwoordigen. Als NTP wordt gebruikt, is het belangrijk om expliciet een vertrouwde tijdbron te configureren en de juiste verificatie te gebruiken. Nauwkeurige en betrouwbare tijd is vereist voor syslogdoeleinden, zoals tijdens forensisch onderzoek naar mogelijke aanvallen, en voor succesvolle VPN-connectiviteit wanneer deze afhankelijk is van certificaten voor fase 1-verificatie.
Voorbeeldconfiguratie met NTP-verificatie:
Klant:
(config)#ntp authenticate
(config)#ntp authentication-key 5 md5 ciscotime
(config)#ntp trusted-key 5
(config)#ntp server 172.16.1.5 key 5
Server:
(config)#ntp authenticate
(config)#ntp authentication-key 5 md5 ciscotime
(config)#ntp trusted-key 5
Aanbevolen procedures voor beveiliging met betrekking tot de functie Cisco Smart Install (SMI, slimme installatie) zijn afhankelijk van hoe de functie wordt gebruikt in een specifieke klantomgeving. Cisco maakt onderscheid tussen deze gebruiksscenario's:
In deze gedeelten wordt elk scenario in detail beschreven:
Opmerking: de opdracht vstack is geïntroduceerd in Cisco IOS Release 12.2(55)SE03.
Dit is voorbeelduitvoer van de opdracht show vstack op een Cisco Catalyst Switch met de functie Smart Install client uitgeschakeld:
switch# show vstack
config Role: Client (SmartInstall disabled)
Vstack Director IP address: 0.0.0.0
Schakel de functionaliteit van de Smart Install-client uit nadat de installatie zonder tussenkomst is voltooid of gebruik de opdracht no stack.
Gebruik een van de volgende methoden om de opdracht no stack in het netwerk te verspreiden:
Om de Smart Install-clientfunctionaliteit later in te schakelen, voert u de opdracht vstack op alle client-switches handmatig of met een script in.
In het ontwerp van een Smart Install-architectuur moet ervoor worden gezorgd dat de IP-adresruimte van de infrastructuur niet toegankelijk is voor onbetrouwbare partijen. In releases die de vstack-opdracht niet ondersteunen, zorg ervoor dat alleen de Smart Install Director TCP-connectiviteit heeft met alle Smart Install-clients op poort 4786.
Beheerders kunnen deze best practices voor beveiliging gebruiken voor Cisco Smart Install-implementaties op getroffen apparaten:
Dit voorbeeld toont een interface ACL met het IP-adres van Smart Install Director als 10.10.10.1 en het IP-adres van de Smart Install-client als 10.10.10.200:
ip access-list extended SMI_HARDENING_LIST
Permit tcp host 10.10.10.1 host 10.10.10.200 eq 4786
deny tcp any any eq 4786
permit ip any any
Deze ACL moet worden geïmplementeerd op alle IP-interfaces op alle clients. Het kan ook via de directeur worden geduwd wanneer de switches eerst worden opgesteld.
Om de toegang tot alle klanten binnen de infrastructuur verder te beperken, kunnen beheerders deze best practices voor beveiliging op andere apparaten in het netwerk gebruiken:
Ontworpen om onbevoegde directe communicatie met netwerkapparaten te voorkomen, zijn toegangscontrolelijsten voor infrastructuur (iACL’s) een van de meest kritieke beveiligingscontroles die in netwerken kunnen worden geïmplementeerd. De hefboomwerking van ACLs van de infrastructuur het idee dat bijna al netwerkverkeer het netwerk oversteekt en niet aan het netwerk zelf bestemd is.
Een iACL wordt geconstrueerd en toegepast om verbindingen van gastheren of netwerken te specificeren die aan netwerkapparaten moeten worden toegestaan. Veel voorkomende voorbeelden van deze typen verbindingen zijn eBGP, SSH en SNMP. Nadat de vereiste verbindingen zijn toegestaan, wordt al het andere verkeer naar de infrastructuur expliciet geweigerd. Al het doorvoerverkeer dat door het netwerk gaat en niet is bedoeld voor infrastructuurapparaten, wordt dan expliciet toegestaan.
De beschermingen die worden geboden door iACL's zijn relevant voor zowel de beheer- als besturingsplane. De implementatie van iACL’s kan worden vergemakkelijkt door het gebruik van verschillende adressering voor netwerkinfrastructuurapparaten. Raadpleeg een security georiënteerde benadering van IP-adressering voor meer informatie over de veiligheidsimplicaties van IP-adressering.
Dit voorbeeld iACL-configuratie illustreert de structuur die als startpunt moet worden gebruikt wanneer u het iACL-implementatieproces start:
!
ip access-list extended ACL-INFRASTRUCTURE-IN
!
!--- Permit required connections for routing protocols and
!--- network management
!
permit tcp host <trusted-ebgp-peer> host <local-ebgp-address> eq 179
permit tcp host <trusted-ebgp-peer> eq 179 host <local-ebgp-address>
permit tcp host <trusted-management-stations> any eq 22
permit udp host <trusted-netmgmt-servers> any eq 161
!
!--- Deny all other IP traffic to any network device
!
deny ip any <infrastructure-address-space> <mask>
!
!--- Permit transit traffic
!
permit ip any any
!
Wanneer de iACL is gemaakt, moet deze worden toegepast op alle interfaces die te maken krijgen met niet-infrastructuurapparaten. Hieronder vallen interfaces die verbinding maken met andere organisaties, externe toegangssegmenten, gebruikerssegmenten en segmenten in datacenters.
Raadpleeg Uw core beschermen: Access Control Lists voor infrastructuurbescherming voor meer informatie over Infrastructuur-ACL's.
Het Internet Control Message Protocol (ICMP) is ontworpen als een IP-besturingsprotocol. Als zodanig kunnen de berichten die worden overgebracht verreikende gevolgen hebben voor de TCP- en IP-protocollen in het algemeen. Terwijl de hulpmiddelen van het netwerkoplossen van problemen pingelen en traceroute gebruik ICMP, is de externe connectiviteit ICMP zelden nodig voor de juiste verrichting van een netwerk.
Cisco IOS-software biedt functionaliteit om ICMP-berichten specifiek te filteren op naam of type en code. Deze voorbeeld-ACL, die moet worden gebruikt met de access control entries (ACE's) van eerdere voorbeelden, biedt de mogelijkheid voor pings van vertrouwde beheerstations en NMS-servers en blokkeert alle andere ICMP-pakketten:
!
ip access-list extended ACL-INFRASTRUCTURE-IN
!
!--- Permit ICMP Echo (ping) from trusted management stations and servers
!
permit icmp host <trusted-management-stations> any echo
permit icmp host <trusted-netmgmt-servers> any echo
!
!--- Deny all other IP traffic to any network device
!
deny ip any <infrastructure-address-space> <mask>
!
!--- Permit transit traffic
!
permit ip any any
!
Het filterproces voor gefragmenteerde IP-pakketten kan een uitdaging vormen voor beveiligingsapparaten. Dit komt doordat Layer 4-informatie die wordt gebruikt om TCP- en UDP-pakketten te filteren alleen aanwezig is in het oorspronkelijke fragment. Cisco IOS-software gebruikt een specifieke methode om niet-initiële fragmenten te controleren aan de hand van geconfigureerde toegangslijsten. Cisco IOS-software evalueert deze niet-initiële fragmenten tegen de ACL en negeert alle Layer 4-filterinformatie. Dit zorgt ervoor dat niet-initiële fragmenten alleen op Layer 3-gedeelte van elk geconfigureerd ACE worden beoordeeld.
In deze voorbeeldconfiguratie, als een TCP-pakket dat bestemd is voor 192.168.1.1 op poort 22 gefragmenteerd is tijdens het transport, wordt het eerste fragment gedropt zoals verwacht door het tweede ACE op basis van Layer 4-informatie binnen het pakket. Alle resterende (niet-initiële) fragmenten worden echter toegestaan door de eerste ACE, volledig gebaseerd op Layer 3-informatie in het pakket en ACE. Dit scenario wordt weergegeven in deze configuratie:
!
ip access-list extended ACL-FRAGMENT-EXAMPLE
permit tcp any host 192.168.1.1 eq 80
deny tcp any host 192.168.1.1 eq 22
!
Vanwege de niet-intuïtieve aard van fragmentverwerking, worden IP-fragmenten vaak onbedoeld toegestaan door ACL's. Fragmentatie wordt ook vaak gebruikt in pogingen om detectie te ontwijken door intrusiedetectiesystemen. Het is om deze redenen dat IP fragmenten vaak in aanvallen worden gebruikt, en waarom zij uitdrukkelijk bij de bovenkant van om het even welke gevormde iACLs moeten worden gefiltreerd. Dit voorbeeld ACL omvat uitgebreide filtering van IP-fragmenten. De functionaliteit uit dit voorbeeld moet worden gebruikt in combinatie met de functionaliteit van de voorgaande voorbeelden.
!
ip access-list extended ACL-INFRASTRUCTURE-IN
!
!--- Deny IP fragments using protocol-specific ACEs to aid in
!--- classification of attack traffic
!
deny tcp any any fragments
deny udp any any fragments
deny icmp any any fragments
deny ip any any fragments
!
!--- Deny all other IP traffic to any network device
!
deny ip any <infrastructure-address-space> <mask>
!
!--- Permit transit traffic
!
permit ip any any
!
Raadpleeg Access Control Lists en IP-fragmenten voor meer informatie over hoe ACL omgaat met gefragmenteerde IP-pakketten.
Cisco IOS-softwarerelease 12.3(4)T heeft ondersteuning toegevoegd voor het gebruik van ACL’s om IP-pakketten te filteren op basis van de IP-opties die in het pakket aanwezig zijn. IP-opties zijn een beveiligingsuitdaging voor netwerkapparaten omdat deze opties moeten worden verwerkt als uitzonderingspakketten. Dit vereist een CPU-inspanningsniveau dat niet vereist is voor normale pakketten die over het netwerk worden verzonden. De aanwezigheid van IP-opties in een pakket kan ook wijzen op een poging om beveiligingscontroles in het netwerk te omzeilen of op een andere manier de transitkenmerken van een pakket te wijzigen. Om deze redenen moeten pakketten met IP-opties aan de rand van het netwerk worden gefilterd.
Dit voorbeeld moet met de ACE's van eerdere voorbeelden worden gebruikt om volledige filtering van IP-pakketten met IP-opties te omvatten:
!
ip access-list extended ACL-INFRASTRUCTURE-IN
!
!--- Deny IP packets containing IP options
!
deny ip any any option any-options
!
!--- Deny all other IP traffic to any network device
!
deny ip any <infrastructure-address-space> <mask>
!
!--- Permit transit traffic
!
permit ip any any
!
Ondersteuning van Cisco IOS-softwarerelease 12.4(2)T met toegevoegde ACL om IP-pakketten te filteren op basis van de waarde van Time to Live (TTL). De TTL-waarde van een IP-datagram wordt verlaagd door elk netwerkapparaat wanneer een pakket van bron naar bestemming stroomt. Hoewel de aanvankelijke waarden per besturingssysteem verschillen, moet het pakket worden gedropt als de TTL van een pakket op nul komt. Het apparaat dat decrements de TTL aan nul, en daarom het pakket laat vallen, wordt vereist om een Overschreden bericht van de Tijd te produceren en te verzenden ICMP aan de bron van het pakket.
Het genereren en overdragen van deze berichten is een uitzonderingsproces. Routers kunnen deze functie uitvoeren wanneer het aantal IP-pakketten dat verloopt, laag is, maar als het aantal pakketten dat verloopt hoog is, kunnen generatie en transmissie van deze berichten alle beschikbare CPU-bronnen gebruiken. Dit duidt op een DoS-aanvalsvector. Het is om deze reden dat de apparaten tegen aanvallen moeten worden gehard van Dos die een hoog tarief IP pakketten gebruiken die zullen verlopen.
Het wordt aanbevolen dat organisaties IP-pakketten met lage TTL-waarden aan de rand van het netwerk filteren. Volledig filteren van pakketten met TTL-waarden onvoldoende om het netwerk te doorkruisen, beperkt de dreiging van op TTL gebaseerde aanvallen.
Deze voorbeeld-ACL filtert pakketten met TTL-waarden lager dan zes. Dit biedt bescherming tegen TTL-vervalaanvallen voor netwerken van maximaal vijf hops in de breedte.
!
ip access-list extended ACL-INFRASTRUCTURE-IN
!
!--- Deny IP packets with TTL values insufficient to traverse the network
!
deny ip any any ttl lt 6
!
!--- Deny all other IP traffic to any network device
!
deny ip any <infrastructure-address-space> <mask>
!
!--- Permit transit traffic
!
permit ip any any
!
Opmerking: sommige protocollen maken legitiem gebruik van pakketten met lage TTL-waarden. eBGP is zo'n protocol. Raadpleeg de TTL-identificatie en -beperking voor meer informatie over het beperken van op TTL-vervaldatum gebaseerde aanvallen.
Raadpleeg ACL-ondersteuning voor filteren op TTL-waarde voor meer informatie over deze functionaliteit.
Beheersessies voor apparaten stellen u in staat om informatie over een apparaat en de werking ervan te bekijken en te verzamelen. Als deze informatie aan een kwaadwillige gebruiker wordt onthuld, kan het apparaat het doel van een aanval worden, gecompromitteerd, en gebruikt om extra aanvallen uit te voeren. Iedereen met bevoegde toegang tot een apparaat heeft de mogelijkheid voor volledige beheerderscontrole over dat apparaat. Het is absoluut noodzakelijk om beheersessies te beveiligen om de openbaarmaking van informatie en ongeoorloofde toegang te voorkomen.
In Cisco IOS-softwarerelease 12.4(6)T en hoger kan een beheerder met behulp van feature Management Plane Protection (MPP) beperken op welke interfaces beheerverkeer door een apparaat kan worden ontvangen. Zo heeft de beheerder meer controle over een apparaat en over hoe toegang wordt verkregen tot het apparaat.
Dit voorbeeld laat zien hoe u MPP kunt inschakelen om alleen SSH en HTTPS op de Gigabit Ethernet0/1 interface toe te staan:
!
control-plane host
management-interface GigabitEthernet 0/1 allow ssh https
!
Raadpleeg Bescherming van beheerplane voor meer informatie over MPP.
Control Plane Protection (CPPr) bouwt voort op de functionaliteit van Control Plane Policing om vliegtuigverkeer dat is bestemd voor de routeprocessor van het IOS-apparaat te beperken en te controleren. CPPr, toegevoegd in Cisco IOS-softwarerelease 12.4(4)T, verdeelt het besturingsvlak in afzonderlijke categorieën van besturingsvlakken die subinterfaces worden genoemd. Er bestaan drie subinterfaces van de besturingsplane: host, Transit en CEF-Exception. Daarnaast omvat CPPr deze extra beveiligingskenmerken van het bedieningsvlak:
CPPr staat een beheerder toe om verkeer te classificeren, te controleren en te beperken dat naar een apparaat voor beheersdoeleinden met de gastheer subinterface wordt verzonden. De voorbeelden van pakketten die voor de categorie van de gastheersubinterface worden geclassificeerd omvatten beheersverkeer zoals SSH of Telnet en het verpletteren van protocollen.
Opmerking: CPPr biedt geen ondersteuning voor IPv6 en is beperkt tot het IPv4-invoerpad.
Raadpleeg Control Plane Protection Feature Guide - 12.4T en Inzicht in bescherming van besturingsplane voor meer informatie over de Cisco CPPr-functie.
Omdat de informatie in een interactieve beheerszitting kan worden onthuld, moet dit verkeer worden versleuteld zodat een kwaadwillige gebruiker geen toegang kan krijgen tot de gegevens die worden doorgegeven. Verkeersversleuteling zorgt voor een beveiligde externe toegangsverbinding met het apparaat. Als het verkeer voor een beheersessie via het netwerk in leesbare tekst wordt verzonden, kan een aanvaller gevoelige informatie over het apparaat en het netwerk verkrijgen.
Een beheerder kan een versleutelde en beveiligde verbinding voor extern toegangsbeheer met een apparaat tot stand brengen met de functies SSH of HTTPS (Secure Hypertext Transfer Protocol). Cisco IOS-software ondersteunt SSH-versie 1.0 (SSHv1), SSH-versie 2.0 (SSHv2) en HTTPS die Secure Sockets Layer (SSL) en Transport Layer Security (TLS) gebruikt voor verificatie en dataversleuteling. SSHv1 en SSHv2 zijn niet compatibel. SSHv1 is onveilig en niet gestandaardiseerd, dus wordt het niet aanbevolen als SSHv2 een optie is.
Cisco IOS-software ondersteunt ook het Secure Copy Protocol (SCP), waarmee een versleutelde en beveiligde verbinding tot stand wordt gebracht om apparaatconfiguraties of softwareafbeeldingen te kopiëren. SCP vertrouwt op SSH. Deze voorbeeldconfiguratie maakt SSH mogelijk op een Cisco IOS-apparaat:
!
ip domain-name example.com
!
crypto key generate rsa modulus 2048
!
ip ssh time-out 60
ip ssh authentication-retries 3
ip ssh source-interface GigabitEthernet 0/1
!
line vty 0 4
transport input ssh
!
Dit configuratievoorbeeld maakt SCP-services mogelijk:
!
ip scp server enable
!
Dit is een configuratievoorbeeld voor HTTPS-services:
!
crypto key generate rsa modulus 2048
!
ip http secure-server
!
Raadpleeg Secure Shell configureren op routers en switches met Cisco IOS en Veelgestelde vragen over Secure Shell (SSH) voor meer informatie over de SSH-functie van de Cisco IOS-software.
De SSHv2-ondersteuningsfunctie die in Cisco IOS-softwarerelease 12.3(4)T is geïntroduceerd, stelt een gebruiker in staat om SSHv2 te configureren. (SSHv1-ondersteuning is geïmplementeerd in een eerdere release van Cisco IOS-software.) SSH wordt uitgevoerd bovenop een betrouwbare transportlaag en biedt sterke verificatie- en versleutelingsmogelijkheden. Het enige betrouwbare transport dat is gedefinieerd voor SSH is TCP. SSH biedt een middel om opdrachten op een andere computer of ander apparaat veilig via een netwerk te openen en uit te voeren. De Secure Copy Protocol (SCP)-functie die via SSH is getunneld, maakt een veilige overdracht van bestanden mogelijk.
Als de opdracht ip sh versie 2 niet expliciet is geconfigureerd, laat Cisco IOS SSH versie 1.9 toe. SSH-versie 1.99 zorgt voor zowel SSHv1- als SSHv2-verbindingen. SSHv1 wordt als onveilig beschouwd en kan nadelige effecten op het systeem hebben. Als SSH is ingeschakeld, wordt aanbevolen om SSHv1 uit te schakelen met de opdracht ip sh versie 2.
Deze voorbeeldconfiguratie schakelt SSHv2 (met SSHv1 uitgeschakeld) in op een Cisco IOS-apparaat:
!
hostname router
!
ip domain-name example.com
!
crypto key generate rsa modulus 2048
!
ip ssh time-out 60
ip ssh authentication-retries 3
ip ssh source-interface GigabitEthernet 0/1
!
ip ssh version 2
!
line vty 0 4
transport input ssh
!
Raadpleeg Ondersteuning voor Secure Shell versie 2 voor meer informatie over het gebruik van SSHv2.
Cisco IOS SSHv2 ondersteunt toetsenbord-interactieve en wachtwoordgebaseerde verificatiemethoden. De functie 'SSHv2-verbeteringen voor RSA-sleutels' ondersteunt ook op RSA gebaseerde openbare sleutelverificatie voor de client en server.
Voor gebruikersverificatie gebruikt op RSA gebaseerde gebruikersverificatie een privé/openbaar sleutelpaar gekoppeld aan elke gebruiker voor verificatie. De gebruiker moet een privaat/publiek sleutelpaar op de client genereren en een openbare sleutel op de Cisco IOS SSH-server configureren om de verificatie te voltooien.
Een SSH-gebruiker die probeert de aanmeldgegevens in te stellen biedt een versleutelde handtekening met de privésleutel. De handtekening en de openbare sleutel van de gebruiker worden verzonden naar de SSH-server voor verificatie. De SSH-server berekent een hash over de openbare sleutel die door de gebruiker is verstrekt. De hash wordt gebruikt om te bepalen of de server een item heeft dat overeenkomt. Als een overeenkomst is gevonden, wordt een op RSA gebaseerde berichtverificatie uitgevoerd met de openbare sleutel. De gebruiker wordt dus geverifieerd of de toegang wordt geweigerd op basis van de versleutelde handtekening.
Voor serververificatie moet de Cisco IOS SSH-client een hostsleutel toewijzen voor elke server. Wanneer de client probeert een SSH-sessie met een server op te stellen, ontvangt deze de handtekening van de server als onderdeel van het bericht voor sleuteluitwisseling. Als de strikte vlag voor het controleren van de hostsleutel op de client is ingeschakeld, controleert de client of de host-sleutelvermelding die overeenkomt met de vooraf ingestelde server, aanwezig is. Als een overeenkomst wordt gevonden, probeert de client de handtekening te valideren met behulp van de serverhostsleutel. Als de server is geverifieerd, wordt doorgegaan met het tot stand brengen van de sessie; anders wordt deze beëindigd en wordt een bericht Serververificatie mislukt weergegeven.
Deze voorbeeldconfiguratie maakt het gebruik van RSA-sleutels met SSHv2 mogelijk op een Cisco IOS-apparaat:
!
! Configure a hostname for the device
!
hostname router
!
! Configure a domain name
!
ip domain-name cisco.com
!
! Specify the name of the RSA key pair (in this case, "sshkeys") to use for SSH
!
ip ssh rsa keypair-name sshkeys
!
! Enable the SSH server for local and remote authentication on the router using
! the "crypto key generate" command
! For SSH version 2, the modulus size must be at least 768 bits
!
crypto key generate rsa usage-keys label sshkeys modulus 2048
!
! Configure an ssh timeout (in seconds)
!
! The following enables a timeout of 120 seconds for SSH connections
!
ip ssh time-out 120
!
! Configure a limit of five (5) authentication retries
!
ip ssh authentication-retries 5
!
! Configure SSH version 2
!
ip ssh version 2
!
Raadpleeg Ondersteuning voor Secure Shell versie 2 voor RSA-sleutels voor meer informatie over het gebruik van RSA-sleutels met SSHv2.
Deze voorbeeldconfiguratie zorgt ervoor dat de Cisco IOS SSH-server op RSA gebaseerde gebruikersverificatie kan uitvoeren. De gebruikersverificatie lukt als de openbare RSA-sleutel die is opgeslagen op de server, wordt geverifieerd met het openbare of privé sleutelpaar dat is opgeslagen op de client.
!
! Configure a hostname for the device
!
hostname router
!
! Configure a domain name
!
ip domain-name cisco.com
!
! Generate RSA key pairs using a modulus of 2048 bits
!
crypto key generate rsa modulus 2048
!
! Configure SSH-RSA keys for user and server authentication on the SSH server
!
ip ssh pubkey-chain
!
! Configure the SSH username
!
username ssh-user
!
! Specify the RSA public key of the remote peer
!
! You must then configure either the key-string command
! (followed by the RSA public key of the remote peer) or the
! key-hash command (followed by the SSH key type and version.)
!
Raadpleeg De Cisco IOS SSH-server configureren om op RSA gebaseerde gebruikersverificatie uit te voeren voor meer informatie over het gebruik van RSA-sleutels met SSHv2.
Deze voorbeeldconfiguratie zorgt ervoor dat de Cisco IOS SSH-client op RSA gebaseerde serververificatie kan uitvoeren.
!
!
hostname router
!
ip domain-name cisco.c
!
! Generate RSA key pairs
!
crypto key generate rsa
!
! Configure SSH-RSA keys for user and server authentication on the SSH server
!
ip ssh pubkey-chain
!
! Enable the SSH server for public-key authentication on the router
!
server SSH-server-name
!
! Specify the RSA public-key of the remote peer
!
! You must then configure either the key-string command
! (followed by the RSA public key of the remote peer) or the
! key-hash <key-type> <key-name> command (followed by the SSH key
! type and version.)
!
! Ensure that server authentication takes place - The connection will be
! terminated on a failure
!
ip ssh stricthostkeycheck
!
Raadpleeg De Cisco IOS SSH-client configureren om op RSA gebaseerde serververificatie uit te voeren voor meer informatie over het gebruik van RSA-sleutels met SSHv2.
In Cisco IOS-apparaten zijn console- en AUX-poorten (auxiliary-poorten) asynchrone lijnen die kunnen worden gebruikt voor lokale en externe toegang tot een apparaat. U moet zich ervan bewust zijn dat consolepoorten op Cisco IOS-apparaten speciale rechten hebben. Deze bevoegdheden zorgen er met name voor dat een beheerder de wachtwoordherstelprocedure kan uitvoeren. Om wachtwoordherstel uit te voeren, zou een niet-geverifieerde aanvaller toegang tot de consolepoort en de mogelijkheid om de voeding van het apparaat te onderbreken of het apparaat te laten crashen moeten hebben.
Elke methode die wordt gebruikt om toegang te krijgen tot de consolepoort van een apparaat moet worden beveiligd op een manier die gelijk is aan de beveiliging die wordt afgedwongen voor bevoorrechte toegang tot een apparaat. De methodes die worden gebruikt om toegang te beveiligen moeten het gebruik van AAA, exec-timeout, en modemwachtwoorden omvatten als een modem aan de console in bijlage is.
Als wachtwoordherstel niet nodig is, kan een beheerder de mogelijkheid verwijderen om de wachtwoordherstelprocedure uit te voeren met de opdracht Geen wachtwoord-herstel globale configuratie; echter, zodra de opdracht Geen wachtwoord-herstel is ingeschakeld, kan een beheerder niet langer wachtwoordherstel op een apparaat uitvoeren.
In de meeste situaties moet de AUX-poort van een apparaat worden uitgeschakeld om onbevoegde toegang te voorkomen. Een AUX-poort kan worden uitgeschakeld met deze opdrachten:
!
line aux 0
transport input none
transport output none
no exec
exec-timeout 0 1
no password
!
Interactieve beheersessies in Cisco IOS-software gebruiken een tty of virtual tty (vty). Een tty is een lokale asynchrone lijn waaraan een terminal kan worden verbonden voor lokale toegang tot het apparaat of tot een modem voor inbeltoegang tot een apparaat. Let op: tty's kunnen worden gebruikt voor verbindingen met consolepoorten van andere apparaten. Deze functie zorgt ervoor dat een apparaat met tty-lijnen kan handelen als een consoleserver waarop verbindingen tot stand kunnen worden gebracht in het netwerk met de consolepoorten van apparaten die zijn verbonden met de tty-lijnen. De tty-lijnen voor deze omgekeerde verbindingen over het netwerk moeten ook worden beheerd.
Een vty-lijn wordt gebruikt voor alle andere externe netwerkverbindingen die worden ondersteund door het apparaat, ongeacht protocol (SSH, SCP of Telnet zijn voorbeelden). Om ervoor te zorgen dat een apparaat via een lokale of externe beheersessie kan worden benaderd, moeten de juiste controles op zowel vty als tty lines worden afgedwongen. Cisco IOS-apparaten hebben een beperkt aantal vty-lijnen; het aantal beschikbare lijnen kan worden bepaald met de EXEC-opdracht show line. Wanneer alle vty lijnen in gebruik zijn, kunnen er geen nieuwe beheersessies worden ingesteld, wat een DoS-voorwaarde creëert voor toegang tot het apparaat.
De eenvoudigste vorm van toegangscontrole tot een vty of tty van een apparaat is door het gebruik van authenticatie op alle lijnen, ongeacht de apparaatlocatie binnen het netwerk. Dit is van cruciaal belang voor vty-lijnen omdat ze via het netwerk toegankelijk zijn. Een tty-lijn die is aangesloten op een modem die wordt gebruikt voor externe toegang tot het apparaat, of een tty-lijn die is aangesloten op de consolepoort van andere apparaten, zijn ook toegankelijk via het netwerk. Andere vormen van vty- en tty-toegangscontroles kunnen worden afgedwongen met de configuratie-opdrachten transport input of access-class, met het gebruik van de functies CoPP en CPPr, of als u toegangslijsten toepast op interfaces op het apparaat.
Verificatie kan worden afgedwongen via het gebruik van AAA. Dit is de aanbevolen methode voor geverifieerde toegang tot een apparaat, met het gebruik van de lokale gebruikersdatabase, of door eenvoudige wachtwoordverificatie direct geconfigureerd op de vty- of tty-lijn.
De opdracht exec-timeout moet worden gebruikt om sessies uit te loggen op vty of tty lijnen die niet worden gebruikt. De opdracht service-tcp-keepalives-in moet ook worden gebruikt om TCP-keepalives op inkomende verbindingen met het apparaat in te schakelen. Dit waarborgt dat het apparaat op het verre eind van de verbinding nog toegankelijk is en dat de half-open of orphaned verbindingen worden verwijderd uit het lokale IOS apparaat.
Een vty en tty zou moeten worden gevormd om slechts gecodeerde en veilige verre toegangsbeheerverbindingen aan het apparaat of door het apparaat te accepteren als het als consoleserver wordt gebruikt. In dit gedeelte worden tty's besproken omdat dergelijke lijnen kunnen worden aangesloten op consolepoorten op andere apparaten, waarmee de tty toegankelijk is via het netwerk. Om informatieopenbaarmaking of onbevoegde toegang tot de gegevens die tussen de beheerder en het apparaat worden verzonden te voorkomen, moeten transport-ingangssh worden gebruikt in plaats van clear-text protocollen, zoals Telnet en rlogin. De transport input geen configuratie kan worden ingeschakeld op een tty, die in feite het gebruik van de tty line voor reverse-console verbindingen verbiedt.
Met zowel vty- als tty-lijnen kan de beheerder verbinding maken met andere apparaten. Om het type transport te beperken dat een beheerder kan gebruiken voor uitgaande verbindingen, gebruikt u de opdracht voor configuratie van de uitvoerlijn. Als er geen uitgaande verbindingen nodig zijn, moet geen transportoutput worden gebruikt. Als echter uitgaande verbindingen zijn toegestaan, moet een versleutelde en beveiligde methode voor externe toegang voor de verbinding worden afgedwongen door het gebruik van transportoutput.
Opmerking: IPSec kan worden gebruikt voor versleutelde en beveiligde externe toegangsverbindingen met een apparaat, indien ondersteund. Als u IPSec gebruikt, wordt ook aanvullende CPU-overhead toegevoegd aan het apparaat. SSH moet echter nog steeds als transport worden afgedwongen, zelfs als IPSec wordt gebruikt.
In sommige rechtsgebieden kan het onmogelijk zijn kwaadwillige gebruikers te vervolgen en illegaal te controleren, tenzij ze op de hoogte zijn gesteld dat ze het systeem niet mogen gebruiken. Eén methode om dit bericht te verstrekken, is door deze informatie in een bannerbericht te plaatsen dat is geconfigureerd met de aanmeldingsopdracht voor de Cisco IOS-softwarebanner.
De wettelijke kennisgevingsvereisten zijn complex, variëren per jurisdictie en situatie en moeten worden besproken met juridische adviseurs. Zelfs binnen rechtsgebieden kunnen juridische meningen verschillen. In samenwerking met een adviseur kan een banner deze informatie geheel of gedeeltelijk verstrekken:
Vanuit een veiligheidsperspectief, eerder dan wettelijk, zou een login banner geen specifieke informatie over de routernaam, het model, de software, of het eigendom moeten bevatten. Deze informatie kan worden misbruikt door kwaadwillende gebruikers.
Het AAA-kader (Verificatie, autorisatie en accounting) is cruciaal om interactieve toegang tot netwerkapparaten te beveiligen. Het AAA-framework biedt een zeer configureerbare omgeving die op maat kan worden gesneden op basis van de behoeften van het netwerk.
TACACS+ is een verificatieprotocol dat Cisco IOS-apparaten kunnen gebruiken voor verificatie van beheergebruikers tegen een externe AAA-server. Deze beheergebruikers kunnen het IOS-apparaat benaderen via SSH, HTTPS, telnet of HTTP.
TACACS+-verificatie, of meer algemeen AAA-verificatie, biedt de mogelijkheid om afzonderlijke gebruikersaccounts te gebruiken voor elke netwerkbeheerder. Wanneer u niet afhankelijk bent van een enkel gedeeld wachtwoord, wordt de beveiliging van het netwerk verbeterd en uw verantwoordelijkheid versterkt.
RADIUS is een protocol dat in doel vergelijkbaar is met TACACS+; het versleutelt echter alleen het wachtwoord dat door het netwerk wordt verzonden. In tegenstelling tot het voorgaande versleutelt TACACS+ de volledige TCP-payload, die zowel de gebruikersnaam als het wachtwoord omvat. Daarom moet TACACS+ worden gebruikt in plaats van RADIUS wanneer TACACS+ wordt ondersteund door de AAA-server. Raadpleeg Vergelijking van TACACS+ en RADIUS voor een gedetailleerdere vergelijking van deze twee protocollen.
TACACS+-verificatie kan worden ingeschakeld op een Cisco IOS-apparaat met een configuratie die lijkt op dit voorbeeld:
!
aaa new-model
aaa authentication login default group tacacs+
!
tacacs-server host <ip-address-of-tacacs-server>
tacacs-server key <key>
!
De vorige configuratie kan worden gebruikt als startpunt voor een organisatiespecifieke AAA-verificatiesjabloon. Raadpleeg Verificatie, autorisatie en accounting voor meer informatie over de configuratie van AAA.
Een methodelijst is een sequentiële lijst die de verificatiemethoden beschrijft die moeten worden opgevraagd om een gebruiker te verifiëren. Met methodelijsten kunt u een of meer beveiligingsprotocollen aanwijzen die voor de verificatie moeten worden gebruikt, en zo een back-upsysteem voor verificatie garanderen voor het geval dat de eerste methode mislukt. Cisco IOS-software gebruikt de eerste vermelde methode die een gebruiker accepteert of weigert. Latere methoden worden alleen geprobeerd in gevallen waarin eerdere methoden falen vanwege serveronbeschikbaarheid of onjuiste configuratie.
Raadpleeg Vermelde methodelijsten voor verificatie voor meer informatie over de configuratie van Vermelde methodelijsten.
Als alle geconfigureerde TACACS+-servers onbeschikbaar worden, kan een Cisco IOS-apparaat vertrouwen op secundaire verificatieprotocollen. Typische configuraties zijn onder andere het gebruik van lokaal of inschakelen van verificatie als alle geconfigureerde TACACS+-servers onbeschikbaar zijn.
De volledige lijst van opties voor verificatie op het apparaat omvat enable, local en line. Elk van deze opties heeft voordelen. Het gebruik van het Enable geheim heeft de voorkeur omdat het geheim is gehakt met een unidirectioneel algoritme dat inherent veiliger is dan het encryptie algoritme dat met de Type 7 wachtwoorden voor lijn of lokale authentificatie wordt gebruikt.
Op Cisco IOS-softwarereleases die het gebruik van geheime wachtwoorden voor lokaal gedefinieerde gebruikers ondersteunen, kan fallback op lokale verificatie echter wenselijk zijn. Hierdoor kan een lokaal gedefinieerde gebruiker worden gemaakt voor een of meer netwerkbeheerders. Als TACACS+ volledig onbeschikbaar zou worden, kan elke beheerder zijn lokale gebruikersnaam en wachtwoord gebruiken. Hoewel deze actie de verantwoordelijkheid van netwerkbeheerders bij TACACS+-storingen verhoogt, wordt de beheerderslast aanzienlijk verhoogd omdat lokale gebruikersaccounts op alle netwerkapparaten moeten worden onderhouden.
Dit configuratievoorbeeld bouwt voort op het vorige TACACS+ verificatievoorbeeld om fall-back-verificatie op te nemen in het wachtwoord dat lokaal is geconfigureerd met de opdracht geheime toegang inschakelen:
!
enable secret <password>
!
aaa new-model
aaa authentication login default group tacacs+ enable
!
tacacs-server host <ip-address-of-tacacs-server>
tacacs-server key <key>
!
Raadpleeg Verificatie configureren voor meer informatie over het gebruik van fallback-verificatie met AAA.
Oorspronkelijk ontworpen om snelle decryptie van opgeslagen wachtwoorden mogelijk te maken, zijn Type 7 wachtwoorden geen veilige vorm van wachtwoordopslag. Er zijn veel tools beschikbaar die deze wachtwoorden gemakkelijk kunnen decoderen. Het gebruik van wachtwoorden van type 7 moet worden vermeden, tenzij dit nodig is voor een functie die op het Cisco IOS-apparaat wordt gebruikt.
Indien mogelijk moet type 9 (crypt) worden gebruikt:
username <username> privilege 15 algorithm-type scrypt secret <secret>
Het verwijderen van wachtwoorden van dit type kan worden vergemakkelijkt door AAA-verificatie en het gebruik van de functie Enhanced Password Security, waarmee geheime wachtwoorden kunnen worden gebruikt met gebruikers die lokaal zijn gedefinieerd via de opdracht gebruikersnaam global configuratie. Als u het gebruik van Type 7-wachtwoorden niet volledig kunt voorkomen, beschouw deze wachtwoorden dan als verhuld, niet als versleuteld.
Raadpleeg het gedeelte Versterking algemene beheerplane van dit document voor meer informatie over het verwijderen van Type 7-wachtwoorden.
Opdrachtautorisatie met TACACS+ en AAA biedt een mechanisme waarmee elke opdracht die wordt ingevoerd door een beheerdersgebruiker wordt toegestaan of geweigerd. Wanneer de gebruiker EXEC-opdrachten invoert, stuurt Cisco IOS elke opdracht naar de geconfigureerde AAA-server. De AAA-server gebruikt vervolgens het ingestelde beleid om de opdracht voor die specifieke gebruiker toe te staan of te weigeren.
Deze configuratie kan aan het vorige AAA-verificatievoorbeeld worden toegevoegd om opdrachtautorisatie te implementeren:
!
aaa authorization exec default group tacacs none
aaa authorization commands 0 default group tacacs none
aaa authorization commands 1 default group tacacs none
aaa authorization commands 15 default group tacacs none
!
Raadpleeg Autorisatie configureren voor meer informatie over opdrachtautorisatie.
Indien geconfigureerd stuurt AAA-opdrachtaccounting informatie over elke EXEC-opdracht die is ingevoerd op de geconfigureerde TACACS+-servers. De informatie die naar de TACACS+ server wordt verzonden omvat het uitgevoerde bevel, de datum het werd uitgevoerd, en de gebruikersbenaming van de gebruiker die het bevel ingaat. Opdrachtaccounting wordt niet ondersteund met RADIUS.
Deze voorbeeldconfiguratie schakelt AAA-opdrachtaccounting in voor EXEC-opdrachten ingevoerd op bevoegdheidsniveaus nul, één en 15. Deze configuratie bouwt voort op eerdere voorbeelden, waaronder de configuratie van de TACACS-servers.
!
aaa accounting exec default start-stop group tacacs
aaa accounting commands 0 default start-stop group tacacs
aaa accounting commands 1 default start-stop group tacacs
aaa accounting commands 15 default start-stop group tacacs
!
Raadpleeg Accounting configureren voor meer informatie over de configuratie van AAA-accounting.
De AAA-servers die in een omgeving worden gebruikt, moeten redundant zijn en op een fouttolerante manier worden geïmplementeerd. Zo wordt ervoor gezorgd dat interactieve beheertoegang, zoals SSH, mogelijk is als een AAA-server onbeschikbaar is.
Wanneer u een overbodige AAA-serveroplossing ontwerpt of implementeert, onthoud dan deze overwegingen:
Raadpleeg De Access Control Servers implementeren voor meer informatie.
Deze sectie benadrukt verscheidene methodes die kunnen worden gebruikt om de plaatsing van SNMP binnen IOS apparaten te beveiligen. Het is van cruciaal belang dat SNMP goed wordt beveiligd om de vertrouwelijkheid, integriteit en beschikbaarheid van zowel de netwerkgegevens als de netwerkapparaten waardoor deze gegevens worden verzonden te beschermen. SNMP biedt u een schat aan informatie over de status van netwerkapparaten. Deze informatie moet worden beschermd tegen kwaadwillige gebruikers die deze gegevens willen gebruiken om aanvallen op het netwerk uit te voeren.
Community-strings zijn wachtwoorden die worden toegepast op een IOS-apparaat om toegang, zowel alleen-lezen als lezen-schrijven, tot de SNMP-gegevens op het apparaat te beperken. Deze community-strings moeten, net als alle wachtwoorden, zorgvuldig worden gekozen om te voorkomen dat ze onbeduidend zijn. De communautaire strings moeten op gezette tijden en in overeenstemming met het beleid inzake netwerkbeveiliging worden gewijzigd. Bijvoorbeeld, de koorden zouden moeten worden veranderd wanneer een netwerkbeheerder rollen verandert of het bedrijf verlaat.
Deze configuratielijnen configureren een alleen-lezen communitystring READONLY en een lezen-en-schrijven communitystring READWRITE:
!
snmp-server community READONLY RO
snmp-server community READWRITE RW
!
Opmerking: de vorige community string voorbeelden zijn gekozen om het gebruik van deze strings duidelijk te verklaren. Voor productieomgevingen moeten communautaire strings met voorzichtigheid worden gekozen en bestaan uit een reeks alfabetische, numerieke en niet-alfanumerieke symbolen. Raadpleeg Aanbevelingen voor het maken van sterke wachtwoorden voor meer informatie over de selectie van niet-onbeduidende wachtwoorden.
Raadpleeg IOS SNMP-opdrachtreferentie voor meer informatie over deze functie.
Naast de community-string moet een ACL worden toegepast die de SNMP-toegang verder beperkt tot een selecte groep IP-bronadressen. Deze configuratie beperkt de alleen-lezen toegang van SNMP tot eindhostapparaten die zich bevinden in de adresruimte 192.168.100.0/24 en beperkt lezen-en-schrijven toegang van SNMP tot alleen het eindhostapparaat op 192.168.100.1.
Opmerking: de apparaten die door deze ACL’s zijn toegestaan, hebben de juiste community-string nodig om toegang te krijgen tot de gevraagde SNMP-informatie.
!
access-list 98 permit 192.168.100.0 0.0.0.255
access-list 99 permit 192.168.100.1
!
snmp-server community READONLY RO 98
snmp-server community READWRITE RW 99
!
Raadpleeg snmp-server community in de Cisco IOS-opdrachtreferentie voor netwerkbeheer voor meer informatie over deze functie.
Infrastructuur ACL’s (iACL’s) kunnen worden geïmplementeerd om ervoor te zorgen dat alleen eindhosts met vertrouwde IP-adressen SNMP-verkeer naar een IOS-apparaat kunnen verzenden. Een iACL moet een beleid bevatten dat niet-geautoriseerde SNMP-pakketten op UDP-poort 161 ontkent.
Zie het gedeelte Toegang tot het netwerk beperken met infrastructuur-ACL's van dit document voor meer informatie over het gebruik van iACL's.
SNMP-weergaven zijn een beveiligingsfunctie die toegang tot bepaalde SNMP MIB's kan toestaan of weigeren. Wanneer een weergave is gemaakt en toegepast op een communitystring met de globale configuratie-opdrachten snmp-server community community-string view, en als u MIB-gegevens opent, is uw toegang beperkt tot de toestemmingen die zijn gedefinieerd door de weergave. Indien van toepassing wordt u aangeraden om weergaven te gebruiken om gebruikers van SNMP te beperken tot de gegevens die ze nodig hebben.
Dit configuratievoorbeeld beperkt SNMP-toegang met de communitystring LIMITED tot de MIB-gegevens die zich in de systeemgroep bevinden:
!
snmp-server view VIEW-SYSTEM-ONLY system include
!
snmp-server community LIMITED view VIEW-SYSTEM-ONLY RO
!
Raadpleeg SNMP-ondersteuning configureren voor meer informatie.
SNMP versie 3 (SNMPv3) wordt gedefinieerd door RFC3410, RFC3411, RFC3412, RFC3413, RFC3414 en RFC3415 en is een interoperabel op standaarden gebaseerd protocol voor netwerkbeheer. SNMPv3 biedt beveiligde toegang tot apparaten omdat dit pakketten via het netwerk verifieert en optioneel versleutelt. Waar ondersteund, kan SNMPv3 worden gebruikt om een andere beveiligingslaag toe te voegen wanneer u SNMP implementeert. SNMPv3 bestaat uit drie primaire configuratie-opties:
Er moet een gezaghebbende engine-ID bestaan om de SNMPv3-beveiligingsmechanismen - verificatie of verificatie en codering - te kunnen gebruiken voor de verwerking van SNMP-pakketten; standaard wordt de engine-ID lokaal gegenereerd. De engine-ID kan worden weergegeven met de opdracht show snmp engineID zoals weergegeven in dit voorbeeld:
router#show snmp engineID
Local SNMP engineID: 80000009030000152BD35496
Remote Engine ID IP-addr Port
Opmerking: als de engine-ID wordt gewijzgd, moeten alle SNMP-gebruikersaccounts opnieuw worden geconfigureerd.
De volgende stap is het configureren van een SNMPv3-groep. Deze opdracht configureert een Cisco IOS-apparaat voor SNMPv3 met een SNMP-servergroep AUTHGROUP en schakelt alleen verificatie voor deze groep in met het trefwoord auth:
!
snmp-server group AUTHGROUP v3 auth
!
Deze opdracht configureert een Cisco IOS-apparaat voor SNMPv3 met een SNMP-servergroep PRIVGROUP en schakelt zowel verificatie als versleuteling voor deze groep in met het trefwoord priv:
!
snmp-server group PRIVGROUP v3 priv
!
Deze opdracht configureert een SNMPv3-gebruiker snmpv3user met een MD5-verificatiewachtwoord authpassword en een 3DES-versleutelingswachtwoord privpassword:
!
snmp-server user snmpv3user PRIVGROUP v3 auth md5 authpassword priv 3des
privpassword
!
Merk op dat de configuratieopdrachten van de snmp-server-gebruiker niet worden weergegeven in de configuratie-uitgang van het apparaat zoals vereist door RFC 3414; daarom is het gebruikerswachtwoord niet zichtbaar vanuit de configuratie. Om de gevormde gebruikers te bekijken, ga het bevel van de show snmp gebruiker zoals in dit voorbeeld in:
router#show snmp user
User name: snmpv3user
Engine ID: 80000009030000152BD35496
storage-type: nonvolatile active
Authentication Protocol: MD5
Privacy Protocol: 3DES
Group-name: PRIVGROUP
Raadpleeg SNMP-ondersteuning configureren voor meer informatie over deze functie.
De functie Management Plane Protection (MPP) in Cisco IOS-software kan worden gebruikt om beveiligde SNMP te ondersteunen, omdat deze de interfaces beperkt waardoor SNMP-verkeer op het apparaat kan eindigen. Met de MPP-functie kan een beheerder een of meer interfaces toewijzen als beheerinterfaces. Beheerverkeer mag alleen via deze beheerinterfaces op een apparaat binnenkomen. Nadat MPP is ingeschakeld, accepteren alleen toegewezen beheerinterfaces netwerkverkeer dat bestemd is voor het apparaat.
Merk op dat MPP een ondergroep van de CPPr-functie is en een versie van IOS vereist die CPPr ondersteunt. Raadpleeg Inzicht in Control Plane Protection voor meer informatie over CPPr.
In dit voorbeeld wordt MPP gebruikt om SNMP- en SSH-toegang tot alleen de Fast Ethernet 0/0-interface te beperken:
!
control-plane host
management-interface FastEthernet0/0 allow ssh snmp
!
Raadpleeg Functiehandleiding voor Management Plane Protection voor meer informatie.
Met gebeurtenisvastlegging kunt u inzicht krijgen in de werking van een Cisco IOS-apparaat en in het netwerk waarin het wordt geïmplementeerd. Cisco IOS-software biedt verschillende flexibele registratieopties die kunnen helpen de doelstellingen voor netwerkbeheer en zichtbaarheid van een organisatie te realiseren.
Deze secties bieden enkele basis best practices voor vastlegging die een beheerder kunnen helpen om met succes te registreren terwijl de impact van vastlegging op een Cisco IOS-apparaat wordt geminimaliseerd.
U wordt geadviseerd logboekinformatie naar een verre syslog server te verzenden. Als u dit doet, kunnen netwerk- en beveiligingsgebeurtenissen op netwerkapparaten effectiever worden gecorreleerd en geaudit. Let op: syslog-berichten worden onbetrouwbaar verzonden door UDP en in leesbare tekst. Om deze reden moet elke bescherming die een netwerk biedt aan beheerverkeer (bijvoorbeeld codering of out-of-band toegang) worden uitgebreid om ook syslog-verkeer op te nemen.
In dit configuratievoorbeeld wordt een Cisco IOS-apparaat geconfigureerd om logboekinformatie naar een externe syslogserver te verzenden:
!
logging host <ip-address>
!
Raadpleeg Incidenten identificeren met firewall en syslog-gebeurtenissen van IOS-router voor meer informatie over logboekcorrelatie.
De functie Logging to Local Nonvolatile Storage (ATA Disk) is geïntegreerd in 12.4(15)T en oorspronkelijk geïntroduceerd in 12.0(26)S en maakt het mogelijk om berichten over systeemvastlegging op een geavanceerde technologie bijlage (ATA)-flitsschijf op te slaan. Berichten die zijn opgeslagen op een ATA-schijf blijven staan nadat een router opnieuw wordt opgestart.
Deze configuratielijnen configureren 134.217.728 bytes (128 MB) van logberichten naar de syslog-map van de ATA-flitser (disk0), waarbij een bestandsgrootte van 16.384 bytes wordt gespecificeerd:
logging buffered
logging persistent url disk0:/syslog size 134217728 filesize 16384
Alvorens berichten te registreren worden geschreven naar een bestand op de ATA-schijf, controleert Cisco IOS-software of er voldoende schijfruimte is. Als dit niet het geval is wordt het oudste bestand met logberichten (door tijdstempel) verwijderd en wordt het huidige bestand opgeslagen. De bestandsnaamnotatie is log_month:day:year::time.
Opmerking: een ATA-flitsstation heeft beperkte schijfruimte en moet dus worden onderhouden om overschrijven van opgeslagen gegevens te voorkomen.
Dit voorbeeld laat zien hoe u logberichten van de router ATA-flitsschijf naar een externe schijf op FTP-server 192.168.1.129 kopieert als onderdeel van onderhoudsprocedures:
copy disk0:/syslog ftp://myuser/mypass@192.168.1.129/syslog
Raadpleeg Logboekregistratie naar lokale niet-vluchtige opslag (ATA-schijf) voor meer informatie over deze functie.
Elk logboekbericht dat door een Cisco IOS-apparaat wordt gegenereerd, krijgt een van de acht serienummers toegewezen die variëren van niveau 0, Noodsituaties, tot niveau 7, Debug. Tenzij specifiek vereist, wordt u aangeraden om vastlegging op niveau 7 te vermijden. Vastlegging op niveau 7 resulteert in een verhoogde CPU-belasting op het apparaat, wat kan leiden tot instabiliteit van apparaat en netwerk.
Het globale niveau van de logboekval van het configuratiebevel wordt gebruikt om te specificeren welke logboekberichten naar verre syslog servers worden verzonden. Het opgegeven niveau geeft het laagste ernstbericht aan dat wordt verzonden. Voor gebufferde logboekregistratie wordt de opdracht logging buffered level gebruikt.
Dit configuratievoorbeeld beperkt logberichten die naar externe syslog-servers en de lokale logbuffer worden verzonden naar severities 6 (informatie) door 0 (noodgevallen):
!
logging trap 6
logging buffered 6
!
Raadpleeg Probleemoplossing, storingsbeheer en logboekregistratie voor meer informatie.
Met Cisco IOS-software is het mogelijk om logberichten naar monitorsessies te verzenden - monitorsessies zijn interactieve beheersessies waarin de EXEC-opdrachtterminalmonitor is uitgegeven - en naar de console. Dit kan echter de CPU-belasting van een IOS-apparaat verhogen en wordt daarom niet aanbevolen. In plaats daarvan, wordt u geadviseerd om registrereninformatie naar de lokale logboekbuffer te verzenden, die met het bevel van het showregistreren kan worden bekeken.
Gebruik de globale configuratiebevelen op logboekconsole en geen logboekmonitor om het registreren aan de console onbruikbaar te maken en zittingen te controleren. Dit configuratievoorbeeld toont het gebruik van deze opdrachten:
!
no logging console
no logging monitor
!
Raadpleeg Referentie Opdracht Cisco IOS-netwerkbeheer voor meer informatie over globale configuratieopdrachten.
Cisco IOS-software ondersteunt het gebruik van een lokale logbuffer, zodat een beheerder lokaal gegenereerde logberichten kan bekijken. Het gebruik van gebufferde logboekregistratie wordt ten zeerste aanbevolen in vergelijking met logboekregistratie voor de console- of monitorsessies.
Er zijn twee configuratieopties die relevant zijn bij het configureren van gebufferde logboekregistratie: de grootte van de logboekbuffer en de berichtbeveiliging die in de buffer is opgeslagen. De grootte van de logging buffer wordt geconfigureerd met de globale configuratie-opdracht logging buffered size. De laagste strengheid die in de buffer is opgenomen, wordt geconfigureerd met de opdracht "logging buffered severity". Een beheerder kan de inhoud van de logboekbuffer bekijken met de opdracht logboekregistratie EXEC.
Dit configuratievoorbeeld omvat de configuratie van een logboekbuffer van 16384 bytes, evenals een strengheid van 6, informatie, die erop wijst dat de berichten op niveaus 0 (noodgevallen) door 6 (informatie) worden opgeslagen:
!
logging buffered 16384 6
!
Raadpleeg de referentie voor Cisco IOS Network Management Command voor meer informatie over gebufferde vastlegging.
Om een verhoogd niveau van consistentie te bieden wanneer u logberichten verzamelt en beoordeelt, wordt u aangeraden om een logboekbroninterface statisch te configureren. Voltooid via de logboekbron-interface-interfaceopdracht, zorgt statisch het vormen van een logboekbroninterface ervoor dat het zelfde IP adres in alle logboekberichten verschijnt die van een individueel Cisco IOS-apparaat worden verzonden. Voor extra stabiliteit, wordt u geadviseerd om een loopback interface als registrerenbron te gebruiken.
Dit configuratievoorbeeld illustreert het gebruik van het globale configuratiebevel van de logboekbron-interface interface om te specificeren dat het IP adres van loopback 0 interface voor alle logboekberichten wordt gebruikt:
!
logging source-interface Loopback 0
!
Raadpleeg de Cisco IOS-opdrachtreferentie voor meer informatie.
De configuratie van logboektijdstempels helpt u gebeurtenissen over netwerkapparaten te correleren. Het is belangrijk om een correcte en consistente logboektijdstempelconfiguratie te implementeren om ervoor te zorgen dat u logboekgegevens kunt correleren. Vastlegtijdstempels moeten zo worden geconfigureerd dat ze de datum en tijd met een precisie van een milliseconde bevatten en de tijdzone die in gebruik is op het apparaat opnemen.
Dit voorbeeld omvat de configuratie van logtijdstempels met milliseconde precisie binnen de gecoördineerde universele tijdzone (UTC):
!
service timestamps log datetime msec show-timezone
!
Als u liever geen tijden met betrekking tot UTC vastlegt, kunt u een specifieke tijdzone configureren en instellen dat informatie aanwezig moet zijn in gegenereerde logboekberichten. Dit voorbeelt toont een apparaatconfiguratie voor de zone Pacific Standard Time (PST):
!
clock timezone PST -8
service timestamps log datetime msec localtime show-timezone
!
Cisco IOS-software bevat verschillende functies die een vorm van configuratiebeheer op een Cisco IOS-apparaat mogelijk kunnen maken. Dergelijke functies omvatten functionaliteit om configuraties te archiveren en de configuratie terug te draaien naar een vorige versie en een gedetailleerd logboek van de configuratieverandering te maken.
In Cisco IOS-softwarerelease 12.3(7)T en hoger kunt u met de functies 'Configuraties vervangen' en 'Configuratie terugdraaien' de Cisco IOS-apparaatconfiguratie archiveren op het apparaat. De configuraties in dit archief, die handmatig of automatisch worden opgeslagen, kunnen worden gebruikt om de huidige actieve configuratie te vervangen door de opdracht Vervang bestandsnaam. Dit staat in contrast met de opdracht copy filename running-config. De opdracht Configure replace filename vervangt de actieve configuratie in plaats van de samenvoeging die wordt uitgevoerd door de opdracht Copy.
U wordt geadviseerd deze functie op alle Cisco IOS-apparaten in het netwerk in te schakelen. Als deze optie is ingeschakeld, kan een beheerder ervoor zorgen dat de huidige actieve configuratie wordt toegevoegd aan het archief met de opdracht archiefconfiguratie geprivilegieerd EXEC. De gearchiveerde configuraties kunnen worden weergegeven met de EXEC-opdracht show archive.
Dit voorbeeld illustreert de configuratie van automatische configuratie archivering. Dit voorbeeld instrueert het Cisco IOS-apparaat om gearchiveerde configuraties op te slaan als bestanden met de naam archived-config-N op de schijf0: bestandssysteem, om maximaal 14 back-ups te maken, en om één keer per dag te archiveren (1440 minuten) en wanneer een beheerder de opdracht schrijfgeheugen EXEC uitgeeft.
!
archive
path disk0:archived-config
maximum 14
time-period 1440
write-memory
!
Hoewel de configuratie-archieffunctionaliteit maximaal 14 back-upconfiguraties kan opslaan, wordt u aangeraden om rekening te houden met de ruimtevereisten voordat u de maximale opdracht gebruikt.
Toegevoegd aan Cisco IOS-softwarerelease 12.3(14)T, zorgt de functie Exclusive Configuration Change Access ervoor dat slechts één beheerder op een bepaald moment configuratiewijzigingen aanbrengt in een Cisco IOS-apparaat. Met deze functie wordt de ongewenste invloed van gelijktijdige wijzigingen die worden aangebracht aan gerelateerde configuratiecomponenten weggenomen. Deze functie is geconfigureerd met de globale configuratie commando configuratie modus exclusieve mode en werkt in een van de twee modi: auto en handleiding. In de automatische modus wordt de configuratie automatisch vergrendeld wanneer een beheerder de EXEC-opdracht configure terminal gebruikt. In handmatige modus, gebruikt de beheerder de configuratie terminal lock commando om de configuratie te vergrendelen wanneer het de configuratie modus invoert.
Dit voorbeeld toont de configuratie van deze functie voor automatische configuratievergrendeling:
!
configuration mode exclusive auto
!
Toegevoegd in Cisco IOS-softwarerelease 12.3(8)T, maakt de functie Resilient Configuration het mogelijk om een kopie van de Cisco IOS-softwareafbeelding en -apparaatconfiguratie die momenteel door een Cisco IOS-apparaat wordt gebruikt, veilig op te slaan. Wanneer deze functie is ingeschakeld, is het niet mogelijk om deze back-upbestanden aan te passen of te verwijderen. U wordt geadviseerd deze functie in te schakelen om zowel onbedoelde als kwaadaardige pogingen om deze bestanden te verwijderen te voorkomen.
!
secure boot-image
secure boot-config!
Zodra deze functie is ingeschakeld, is het mogelijk om een verwijderde configuratie of Cisco IOS-software-installatiekopie te herstellen. De huidige lopende staat van deze eigenschap kan met het show veilige laars EXEC bevel worden getoond.
Toegevoegd in Cisco IOS-softwarerelease 15.0(1)M voor de routers van Cisco 1900, 2900 en 3900 Series, maakt de functie Digitaal Ondertekende Cisco-software het gebruik mogelijk van Cisco IOS-software die digitaal is ondertekend en dus vertrouwd, met het gebruik van beveiligde asymmetrische (public-key) cryptografie.
Een digitaal ondertekende installatiekopie bevat een versleutelde (met een privésleutel) hash van zichzelf. Na controle, het apparaat decrypteert de hash met de bijbehorende openbare sleutel van de sleutels het heeft in zijn belangrijkste winkel en berekent ook zijn eigen hash van het beeld. Als de ontsleutelde hash overeenkomt met de berekende installatiekopie-hash, is er niet geknoeid met de installatiekopie en kan deze worden vertrouwd.
Digitaal ondertekende Cisco-softwaresleutels worden geïdentificeerd door het type en de versie van de sleutel. Een sleutel kan een productie-, rollover- of speciaal sleuteltype zijn. Productie en speciale sleuteltypen hebben een gekoppelde sleutelversie die alfabetisch toeneemt wanneer de sleutel wordt ingetrokken en vervangen. ROMMON en reguliere Cisco IOS-installatiekopieën worden beide ondertekend met een speciale sleutel of productiesleutel wanneer u de functie 'Digitaal ondertekende Cisco-software' gebruikt. De ROMMON-installatiekopie kan worden geüpgraded en moet worden ondertekend met dezelfde sleutel als de productie- of speciale installatiekopie die is geladen.
Deze opdracht verifieert de integriteit van installatiekopie c3900-universalk9-mz.SSA in flash met de sleutels in de key store van het apparaat:
show software authenticity file flash0:c3900-universalk9-mz.SSA
De functie 'Digitaal ondertekende Cisco-software' is ook geïntegreerd in Cisco IOS XE Release 3.1.0.SG voor de Cisco Catalyst-switches uit de 4500 E-serie.
Raadpleeg Digitaal ondertekende Cisco-software voor meer informatie over deze functie.
In Cisco IOS-softwarerelease 15.1(1)T en hoger is Sleutelvervanging voor digitaal ondertekende Cisco-software geïntroduceerd. Key replacement and revocation vervangt en verwijdert een sleutel die wordt gebruikt voor een digitaal ondertekende Cisco-softwarecontrole uit de toetsopslag van een platform. Alleen productie- en speciale sleutels kunnen worden ingetrokken wanneer een sleutel is gehackt.
Een nieuwe (speciale of productie) sleutel voor een (speciale of productie) beeld wordt geleverd in een (productie of herroeping) beeld dat wordt gebruikt om de vorige speciale of productie sleutel in te trekken. De integriteit van de intrekkingsinstallatiekopie wordt gecontroleerd met een rollover-sleutel die op het platform is geïntegreerd. Een rollover-sleutel wordt niet gewijzigd. Wanneer u een productiesleutel intrekt, nadat het herroepingsbeeld is geladen, wordt de nieuwe sleutel die het draagt toegevoegd aan de sleutelwinkel en kan de corresponderende oude sleutel worden ingetrokken zolang ROMMON-beeld wordt opgewaardeerd en het nieuwe productiebeeld wordt opgestart. Wanneer u een speciale sleutel intrekt, wordt een productie-installatiekopie geladen. Deze installatiekopie voegt de nieuwe speciale sleutel toe en kan de oude speciale sleutel intrekken. Nadat u ROMMON hebt geüpgraded, kan de nieuwe speciale installatiekopie worden opgestart.
Dit voorbeeld beschrijft het intrekken van een speciale sleutel. Deze opdrachten voegen de nieuwe speciale toets toe aan de toetsopslag van het huidige productiebeeld, kopiëren een nieuwe ROMMON-afbeelding (C3900_rom-monitor.srec.SSB) naar het opslaggebied (usbflash0:), upgraden van het ROMMON-bestand en herroepen van de oude speciale toets:
software authenticity key add special
copy tftp://192.168.1.129/C3900_rom-monitor.srec.SSB usbflash0:
upgrade rom-monitor file usbflash0:C3900_PRIV_RM2.srec.SSB
software authenticity key revoke special
Een nieuwe speciale installatiekopie (c3900-universalk9-mz.SSB) kan vervolgens naar de flash worden gekopieerd om te worden geladen en de handtekening van de installatiekopie wordt gecontroleerd aan de hand van de zojuist toegevoegde speciale sleutel (.SSB):
copy /verify tftp://192.168.1.129/c3900-universalk9-mz.SSB flash:
Intrekken en vervangen van sleutels wordt niet ondersteund op Catalyst-switches van de 4500 E-serie waarop Cisco IOS XE-software wordt uitgevoerd, hoewel deze switches wel ondersteuning bieden voor de functie 'Digitaal ondertekende Cisco-software'.
Raadpleeg het gedeelte Intrekken en vervangen van sleutels voor digitaal ondertekende Cisco-software van de handleiding Digitaal ondertekende Cisco-software voor meer informatie over deze functie.
De functie 'Melding en logboekregistratie van configuratiewijziging' is toegevoegd in Cisco IOS-softwarerelease 12.3(4)T en maakt het mogelijk om de configuratiewijzigingen die zijn aangebracht aan een Cisco IOS-apparaat vast te leggen. Het logbestand wordt onderhouden op het Cisco IOS-apparaat en bevat de gebruikersinformatie van het individu dat de wijziging heeft aangebracht, het ingevoerde configuratiebevel en het tijdstip waarop de wijziging is aangebracht. Deze functionaliteit wordt ingeschakeld met de opdracht logging enable voor loggerconfiguratiemodus voor configuratiewijziging. De optionele opdrachten hidekeys en vermeldingen in de loggrootte worden gebruikt om de standaardconfiguratie te verbeteren, omdat ze het vastleggen van wachtwoordgegevens voorkomen en de lengte van het wijzigingslogbestand vergroten.
U wordt geadviseerd om deze functionaliteit in te schakelen zodat de geschiedenis van de configuratieverandering van een Cisco IOS-apparaat gemakkelijker te begrijpen is. Bovendien, wordt u geadviseerd om het bevel van de syslog configuratie te gebruiken om de generatie van syslog berichten toe te laten wanneer een configuratieverandering wordt aangebracht.
!
archive
log config
logging enable
logging size 200
hidekeys
notify syslog
!
Nadat de optie Melding van wijzigingen in configuratie en vastlegging is ingeschakeld, toont de geprivilegieerde opdracht EXEC archieflogbestand dat alle kunnen worden gebruikt om het configuratielogboek te bekijken.
De functies van het controlevliegtuig bestaan uit de protocollen en de processen die tussen netwerkapparaten communiceren om gegevens van bron aan bestemming te bewegen. Dit omvat routeringsprotocollen zoals het Border Gateway Protocol en protocollen zoals ICMP en het Resource Reservation Protocol (RSVP).
Het is belangrijk dat gebeurtenissen in de beheer- en dataplanes geen negatief effect hebben op de besturingsplane. Mocht een dataplaat gebeurtenis zoals een DoS-aanval van invloed zijn op het besturingsplane, dan kan het gehele netwerk instabiel worden. Deze informatie over Cisco IOS-softwarefuncties en -configuraties kan mede zorgen voor de veerkracht van de besturingsplane.
Bescherming van het bedieningsvlak van een netwerkapparaat is van cruciaal belang omdat het bedieningsvlak ervoor zorgt dat de besturings- en dataplanen worden onderhouden en operationeel zijn. Als het besturingsplane tijdens een veiligheidsincident instabiel zou worden, kan het onmogelijk zijn voor u om de stabiliteit van het netwerk te herstellen.
In veel gevallen, kunt u de ontvangst en de transmissie van bepaalde types van berichten op een interface onbruikbaar maken om de hoeveelheid cpu lading te minimaliseren die wordt vereist om onnodige pakketten te verwerken.
Een ICMP-omleidingsbericht kan worden gegenereerd door een router wanneer een pakket op dezelfde interface wordt ontvangen en verzonden. In deze situatie stuurt de router het pakket door en stuurt een ICMP-omleidingsbericht naar de afzender van het oorspronkelijke pakket. Dankzij dit gedrag kan de afzender de router omzeilen en toekomstige pakketten direct doorsturen naar de bestemming (of naar een router dichterbij de bestemming). In een goed functionerend IP-netwerk stuurt een router omleidingen alleen naar hosts op zijn eigen lokale subnetten. Met andere woorden, ICMP-omleidingen moeten nooit verder gaan dan een Layer 3-grens.
Er zijn twee typen ICMP-omleidingsberichten: omleiden voor een hostadres en omleiden voor een volledig subnet. Een kwaadwillige gebruiker kan de capaciteit van de router exploiteren om ICMP te verzenden omleidt door voortdurend pakketten naar de router te verzenden, die de router dwingt om met ICMP te antwoorden om berichten om te leiden, en resulteert in een negatief effect op de CPU en de prestaties van de router. Om te voorkomen dat de router ICMP-omleidingen verstuurt, gebruikt u de opdracht geen ip-omleidingen voor interfaceconfiguratie.
Het filtreren met een lijst van de interfacetoegang brengt de transmissie van onbereikbare berichten ICMP terug naar de bron van het gefilterde verkeer teweeg. De generatie van deze berichten kan CPU-gebruik op het apparaat verhogen. In Cisco IOS-software is de onbereikbare ICMP-generatie standaard beperkt tot één pakket per 500 milliseconden. Het genereren van berichten 'ICMP onbereikbaar' kan worden uitgeschakeld met de interfaceconfiguratie-opdracht no ip unreachables. ICMP-onbereikbare snelheidsbeperking kan worden gewijzigd ten opzichte van de standaardinstelling met de onbereikbare interval-in-ms-limiet van het globale configuratiebevel ip icmp-snelheid.
Proxy ARP is de techniek waarin één apparaat, gewoonlijk een router, ARP verzoeken beantwoordt die voor een ander apparaat bedoeld zijn. Door zijn identiteit "na te doen", neemt de router de verantwoordelijkheid op zich voor het routeren van pakketten naar de echte bestemming. Proxy ARP kan machines op een subnetnetwerk op afstand helpen zonder routing of een standaardgateway te configureren. Proxy ARP is gedefinieerd in RFC 1027 .
Er zijn verscheidene nadelen aan volmachtARP gebruik. Het kan leiden tot een toename in de hoeveelheid ARP-verkeer op het netwerksegment en bronuitputting en man-in-the-middle-aanvallen. Proxy ARP is een aanvalsvector voor bronuitputting omdat elke ARP-aanvraag waarvoor een proxy is uitgevoerd, een kleine hoeveelheid geheugen verbruikt. Een aanvaller kan al beschikbaar geheugen uitputten als het een groot aantal ARP verzoeken verzendt.
Man-in-the-middle aanvallen stellen een host op het netwerk in staat om het MAC-adres van de router te parodiëren, wat resulteert in nietsvermoedende hosts die verkeer naar de aanvaller verzenden. Proxy ARP kan worden uitgeschakeld met de interfaceconfiguratie-opdracht no ip proxy-arp.
Raadpleeg Proxy ARP inschakelen voor meer informatie over deze functie.
Bescherming van de besturingsplane is essentieel. Omdat de toepassingsprestaties en de eindgebruikerservaring zonder de aanwezigheid van gegevens en beheersverkeer kunnen lijden, zorgt de overlevingskans van het controlevliegtuig ervoor dat de andere twee vliegtuigen worden gehandhaafd en operationeel zijn.
Om het besturingsplane van het Cisco IOS-apparaat goed te beveiligen, is het essentieel om de typen verkeer te begrijpen die door de CPU worden verwerkt. Het proces switched verkeer bestaat normaal uit twee verschillende typen verkeer. Het eerste type verkeer wordt naar het Cisco IOS-apparaat geleid en moet rechtstreeks door het Cisco IOS-apparaat CPU worden verwerkt. Dit verkeer bestaat uit de categorie Aangrenzend verkeer ontvangen. Dit verkeer bevat een ingang in de CEF-tabel (Cisco Express Forwarding) waarin de volgende routerhop het apparaat zelf is, dat wordt aangegeven door de term Ontvangen in de CLI-uitvoer van de show ip cef. Deze indicatie is van toepassing op elk IP-adres dat directe verwerking door de CPU van het Cisco IOS-apparaat vereist, en hierbij is inbegrepen interface-IP-adressen, multicast-adresruimte en uitzend-adresruimte.
Het tweede type verkeer dat door de CPU wordt verwerkt, is dataplatformverkeer - verkeer met een bestemming buiten het Cisco IOS-apparaat zelf - waarvoor een speciale verwerking door de CPU is vereist. Hoewel dit geen uitputtende lijst is van CPU-verkeer met gevolgen voor dataplatformverkeer, worden deze typen verkeer via een proces geschakeld en kunnen deze daarom de werking van het besturingsplane beïnvloeden:
Deze lijst detailleert verschillende methoden om te bepalen welke typen verkeer door de Cisco IOS-apparaat CPU worden verwerkt:
Infrastructuur-ACL's (iACL's) beperken externe communicatie tot de apparaten van het netwerk. ACL’s voor infrastructuur worden uitgebreid behandeld in de sectie Toegang tot netwerk met infrastructuur-ACL’s van dit document.
U wordt geadviseerd om iACLs uit te voeren om het controlevliegtuig van alle netwerkapparaten te beschermen.
Voor gedistribueerde platformen kunnen Receive ACL's (rACL's, ontvangst-ACL's) een optie zijn voor Cisco IOS-softwarereleases 12.0(21)S2 voor de 12000 (GSR), 12.0(24)S voor de 7500 en 12.0(31)S voor de 10720. De rACL beschermt het apparaat tegen schadelijk verkeer voordat het verkeer invloed heeft op de routeprocessor. Ontvang ACL’s zijn ontworpen om alleen het apparaat te beschermen waarop het is geconfigureerd en het transitverkeer wordt niet beïnvloed door een rACL. Dientengevolge, verwijst het bestemmingsIP adres om het even welk die in de voorbeeldACL ingangen hieronder slechts naar de fysieke of virtuele IP adressen van de router wordt gebruikt. Ontvang ACL's worden ook beschouwd als best practice voor netwerkbeveiliging en moeten worden beschouwd als een langetermijntoevoeging aan goede netwerkbeveiliging.
Dit is de ontvangstpad-ACL die wordt geschreven om SSH-verkeer (TCP-poort 22) van vertrouwde hosts op het 192.168.100.0/24-netwerk toe te staan:
!
!--- Permit SSH from trusted hosts allowed to the device.
!
access-list 151 permit tcp 192.168.100.0 0.0.0.255 any eq 22
!
!--- Deny SSH from all other sources to the RP.
!
access-list 151 deny tcp any any eq 22
!
!--- Permit all other traffic to the device.
!--- according to security policy and configurations.
!
access-list 151 permit ip any any
!
!--- Apply this access list to the receive path.
!
ip receive access-list 151
!
Verwijs naar GSR: Ontvang Toegangscontrolelijsten om te helpen wettig verkeer aan een apparaat identificeren en toestaan en alle ongewenste pakketten ontkennen.
De CoPP-functie kan ook worden gebruikt om IP-pakketten die bestemd zijn voor het infrastructuurapparaat, te beperken. In dit voorbeeld mag alleen SSH-verkeer van vertrouwde hosts de CPU van het Cisco IOS-apparaat bereiken.
Opmerking: als u verkeer laat vallen van onbekende of onbetrouwbare IP-adressen, kunnen hosts met dynamisch toegewezen IP-adressen geen verbinding maken met het Cisco IOS-apparaat.
!
access-list 152 deny tcp <trusted-addresses> <mask> any eq 22
access-list 152 permit tcp any any eq 22
access-list 152 deny ip any any
!
class-map match-all COPP-KNOWN-UNDESIRABLE
match access-group 152
!
policy-map COPP-INPUT-POLICY
class COPP-KNOWN-UNDESIRABLE
drop
!
control-plane
service-policy input COPP-INPUT-POLICY
!
In het vorige CoPP-voorbeeld leiden de ACL-vermeldingen die overeenkomen met de onbevoegde pakketten met de toestemmingsactie tot het verwijderen van deze pakketten door de functie 'policy-map drop', terwijl pakketten die overeenkomen met de weigeringsactie niet worden beïnvloed door de functie 'policy-map drop'.
CoPP is beschikbaar in Cisco IOS-softwarerelease 12.0S, 12.2SX, 12.2S, 12.3T, 12.4 en 12.4T.
Raadpleeg Control Plane Policing implementeren voor meer informatie over de configuratie en het gebruik van de CoPP-functie.
Control Plane Protection (CPPr), geïntroduceerd in Cisco IOS-softwarerelease 12.4(4)T, kan worden gebruikt om vliegtuigverkeer dat bestemd is voor de CPU van het Cisco IOS-apparaat, te beperken of te bewaken. Hoewel vergelijkbaar met CoPP, CPPr heeft de mogelijkheid om verkeer te beperken met fijnere granulariteit. CPPr verdeelt het geaggregeerde controlevlak in drie afzonderlijke categorieën van bedieningsvlakken, bekend als subinterfaces. Subinterfaces bestaan voor de verkeerscategorieën Host, Doorgifte en CEF-uitzondering. Bovendien bevat CPPr de volgende beschermingsfuncties voor besturingsplanes:
Raadpleeg Control Plane Protection en Inzicht in bescherming van besturingsplane (CPPr) voor meer informatie over de configuratie en het gebruik van de CPPr-functie.
Cisco Catalyst 6500 Series Supervisor Engine 32 en Supervisor Engine 720 ondersteunen platform-specifieke, op hardware gebaseerde snelheidsbegrenzers (HWRL’s) voor speciale netwerkscenario’s. Deze hardwaresnelheidsbegrenzers worden ook wel snelheidsbegrenzers voor speciale scenario's genoemd omdat ze een specifieke vooraf gedefinieerde set IPv4-, IPv6-, unicast- en multicast-DoS-scenario's dekken. HWRL’s kunnen het Cisco IOS-apparaat beveiligen tegen een verscheidenheid aan aanvallen waarvoor pakketten moeten worden verwerkt door de CPU.
Er zijn verschillende HWRL's die standaard zijn ingeschakeld. Raadpleeg de standaardinstellingen van de PFC3 op hardware gebaseerde snelheidsbegrenzer voor meer informatie.
Raadpleeg Hardwaregebaseerde snelheidsbeperkers op de PFC3 voor meer informatie over HWRL's.
De Border Gateway Protocol (BGP) is de routeringsfundering van internet. Dat betekent dat elke organisatie met meer dan bescheiden connectiviteitsvereisten vaak BGP gebruikt. BGP wordt vaak geviseerd door aanvallers vanwege zijn alomtegenwoordigheid en de set en vergeet de aard van BGP-configuraties in kleinere organisaties. Er zijn echter veel BGP-specifieke beveiligingsfuncties die kunnen worden gebruikt om de beveiliging van een BGP-configuratie te verbeteren.
Dit geeft een overzicht van de belangrijkste BGP-beveiligingsfuncties. Indien van toepassing worden aanbevelingen voor de configuratie gedaan.
Elk IP-pakket bevat een veld van 1-byte dat bekendstaat als de Time to Live (TTL). Elk apparaat waar een IP-pakket doorheen beweegt, vermindert deze waarde met één. De startwaarde varieert per besturingssysteem en varieert doorgaans van 64 tot 255. Een pakket wordt verwijderd wanneer de TTL-waarde nul bereikt.
Gekend als zowel het Generalized TTL-gebaseerde Security Mechanism (GTSM) als BGP TTL Security Hack (BTSH), benut een op TTL gebaseerde security bescherming de TTL-waarde van IP-pakketten om ervoor te zorgen dat de BGP-pakketten die worden ontvangen van een direct aangesloten peer afkomstig zijn. Deze optie vereist vaak coördinatie van peering routers; echter, eenmaal ingeschakeld, kan het veel TCP-gebaseerde aanvallen tegen BGP volledig verslaan.
GTSM voor BGP wordt ingeschakeld met de optie ttl-security voor de configuratie-opdracht neighbor van de BGP-router. Dit voorbeeld toont de configuratie van deze functie:
!
router bgp <asn>
neighbor <ip-address> remote-as <remote-asn>
neighbor <ip-address> ttl-security hops <hop-count>
!
Aangezien BGP-pakketten worden ontvangen, wordt de TTL-waarde gecontroleerd. Deze moet groter of gelijk zijn aan 255 min de opgegeven hoptelling.
Peer-verificatie met MD5 maakt een MD5-digest van elk pakket verzonden als onderdeel van een BGP-sessie. Met name delen van de IP en TCP headers, TCP payload en een geheime key worden gebruikt om de vertering te genereren.
De gemaakte digest wordt vervolgens opgeslagen in TCP-optie Kind 19, die specifiek voor dit doel is gemaakt door RFC 2385 . De ontvangende BGP-luidspreker gebruikt hetzelfde algoritme en dezelfde geheime sleutel om de berichtsamenvatting te regenereren. Als de ontvangen en berekende digests niet identiek zijn, wordt het pakket verwijderd.
Peer-verificatie met MD5 wordt geconfigureerd met de optie password op de configuratie-opdracht neighbor van de BGP-router. Het gebruik van deze opdracht wordt als volgt geïllustreerd:
!
router bgp <asn>
neighbor <ip-address> remote-as <remote-asn>
neighbor <ip-address> password <secret>
!
Raadpleeg Verificatie van aangrenzende router voor meer informatie over BGP-peerverificatie met MD5.
BGP-prefixes worden door een router opgeslagen in het geheugen. Hoe meer prefixes een router moet bevatten, hoe meer geheugen BGP moet verbruiken. In sommige configuraties, kan een ondergroep van alle prefixes van Internet, zoals in configuraties worden opgeslagen die hefboomwerking slechts een standaardroute of routes voor de klantennetwerken van een leverancier.
Om geheugenuitputting te voorkomen, is het belangrijk om het maximale aantal prefixes te configureren dat per peer wordt geaccepteerd. Aanbevolen wordt om voor elke BGP-peer een limiet te configureren.
Wanneer u deze functie configureert met de opdracht voor routerconfiguratie van de buurmaximum-prefix BGP, is één argument vereist: het maximale aantal prefixes dat wordt geaccepteerd voordat een peer wordt uitgeschakeld. U kunt ook een cijfer van 1 tot 100 invoeren. Dit getal vertegenwoordigt het percentage van de maximale waarde voor prefixes waarop een logbericht wordt verzonden.
!
router bgp <asn>
neighbor <ip-address> remote-as <remote-asn>
neighbor <ip-address> maximum-prefix <shutdown-threshold> <log-percent>
!
Raadpleeg De functie BGP maximale prefix configureren voor meer informatie over maximale prefixes per peer.
Met prefixlijsten kan een netwerkbeheerder specifieke prefixes toestaan of weigeren die via BGP worden verzonden of ontvangen. Waar mogelijk moeten prefixlijsten worden gebruikt om er zeker van te zijn dat netwerkverkeer via de bedoelde paden wordt verzonden. De prefixlijsten moeten op elke eBGP-peer worden toegepast in zowel de inkomende als de uitgaande richting.
De gevormde prefixlijsten beperken de prefixes die worden verzonden of ontvangen naar die specifiek toegelaten door het routeringsbeleid van een netwerk. Als dit niet haalbaar is vanwege het grote aantal ontvangen prefixes, moet een prefixlijst worden geconfigureerd om bekende slechte prefixes specifiek te blokkeren. Deze bekende slechte prefixes omvatten niet-toegewezen IP-adresruimte en netwerken die zijn gereserveerd voor interne of testdoeleinden door RFC 330. Uitgaande prefixlijsten moeten zo worden geconfigureerd dat ze alleen de prefixes toestaan die een organisatie wil adverteren.
Dit configuratievoorbeeld gebruikt prefix-lijsten om de geleerde en geadverteerde routes te beperken. Alleen een standaardroute is inkomend toegestaan door prefix-lijst BGP-PL-INBOUND, en de prefix 192.168.2.0/24 is de enige route die mag worden geadverteerd door BGP-PL-OUTBOUND.
!
ip prefix-list BGP-PL-INBOUND seq 5 permit 0.0.0.0/0
ip prefix-list BGP-PL-OUTBOUND seq 5 permit 192.168.2.0/24
!
router bgp <asn>
neighbor <ip-address> prefix-list BGP-PL-INBOUND in
neighbor <ip-address> prefix-list BGP-PL-OUTBOUND out
!
Raadpleeg Verbinding maken met een serviceprovider met behulp van externe BGP voor volledige dekking van BGP-prefixfiltering.
BGP-toegangslijsten voor autonoom systeem (AS)-pad maken het de gebruiker mogelijk om ontvangen en geadverteerde prefixes te filteren op basis van het AS-path attribuut van een prefix. Dit kan worden gebruikt in combinatie met prefixlijsten om een robuuste reeks filters te definiëren.
Dit configuratievoorbeeld gebruikt AS-toegangslijsten om inkomende prefixes te beperken tot prefixes die door de externe AS en uitgaande prefixes zijn gegenereerd tot prefixes die door het lokale autonome systeem zijn gegenereerd. Prefixes die afkomstig zijn van alle andere autonome systemen worden gefilterd en niet geïnstalleerd in de routeringstabel.
!
ip as-path access-list 1 permit ^65501$
ip as-path access-list 2 permit ^$
!
router bgp <asn>
neighbor <ip-address> remote-as 65501
neighbor <ip-address> filter-list 1 in
neighbor <ip-address> filter-list 2 out
!
De capaciteit van een netwerk om verkeer behoorlijk door:sturen en van topologieveranderingen of fouten terug te krijgen is afhankelijk van een nauwkeurige mening van de topologie. U kunt vaak een Interior Gateway Protocol (IGP) uitvoeren om deze weergave te bieden. IGP's zijn standaard dynamisch en ontdekken aanvullende routers die communiceren met de specifieke IGP die in gebruik is. IGP's ontdekken ook routes die kunnen worden gebruikt tijdens een netwerkverbindingsfout.
Deze subsecties bieden een overzicht va de belangrijkste IGP-beveiligingsfuncties. Aanbevelingen voor en voorbeelden van Routing Information Protocol Version 2 (RIPv2), Enhanced Interior Gateway Routing Protocol (EIGRP) en Open Shortest Path First (OSPF) worden indien nodig geboden.
Als de uitwisseling van routeringsinformatie niet wordt beveiligd, kan een aanvaller ongeldige routeringsinformatie in het netwerk plaatsen. Door wachtwoordverificatie met routeringsprotocollen tussen routers te gebruiken, kunt u de beveiliging van het netwerk verbeteren. Deze verificatie wordt verzonden als leesbare tekst en daarom kan het heel eenvoudig zijn voor een aanvaller om deze beveiligingscontrole te ondermijnen.
Door MD5-hashmogelijkheden aan het verificatieproces toe te voegen, bevatten routingupdates geen duidelijke wachtwoorden meer en is de volledige inhoud van de routingupdate beter bestand tegen manipulatie. MD5-authenticatie is echter nog steeds vatbaar voor brute kracht en woordenboekaanvallen indien er zwakke wachtwoorden worden gekozen. Aangeraden wordt om wachtwoorden met voldoende willekeur te gebruiken. MD5-verificatie is een stuk veiliger in vergelijking met wachtwoordverificatie en daarom zijn deze voorbeelden specifiek voor MD5-verificatie. IPSec kan ook worden gebruikt om routeringsprotocollen te valideren en te beveiligen, maar deze voorbeelden geven geen details over het gebruik ervan.
EIGRP en RIPv2 gebruiken sleutelketens als deel van de configuratie. Raadpleeg sleutel voor meer informatie over de configuratie en het gebruik van sleutelketens.
Dit is een voorbeeldconfiguratie voor EIGRP-routerverificatie met MD5:
!
key chain <key-name>
key <key-identifier>
key-string <password>
!
interface <interface>
ip authentication mode eigrp <as-number> md5
ip authentication key-chain eigrp <as-number> <key-name>
!
Dit is een voorbeeld van configuratie van MD5-routerverificatie voor RIPv2. RIPv1 biedt geen ondersteuning voor verificatie.
!
key chain <key-name>
key <key-identifier>
key-string <password>
!
interface <interface>
ip rip authentication mode md5
ip rip authentication key-chain <key-name>
!
Dit is een voorbeeldconfiguratie voor OSPF-routerverificatie met MD5. OSPF gebruikt geen sleutelketens.
!
interface <interface>
ip ospf message-digest-key <key-id> md5 <password>
!
router ospf <process-id>
network 10.0.0.0 0.255.255.255 area 0
area 0 authentication message-digest
!
Raadpleeg OSPF configureren voor meer informatie.
De lekken van de informatie, of de introductie van valse informatie in een IGP, kunnen door gebruik van het passief-interfacebevel worden verlicht dat in het controleren van de reclame van het verpletteren van informatie bijstaat. U wordt geadviseerd om geen informatie aan netwerken te adverteren die buiten uw administratieve controle zijn.
Dit voorbeeld laat het gebruik van deze functie zien:
!
router eigrp <as-number>
passive-interface default
no passive-interface <interface>
!
Om de mogelijkheid te verminderen dat u valse routerinformatie in het netwerk introduceert, moet u Routerfiltering gebruiken. In tegenstelling tot de opdracht voor routerconfiguratie met passieve interfaces, vindt routing op interfaces plaats zodra routefiltering is ingeschakeld, maar de informatie die wordt geadverteerd of verwerkt, is beperkt.
Voor EIGRP en RIP beperkt het gebruik van de opdracht verdeel-lijst met het uit sleutelwoord welke informatie wordt geadverteerd, terwijl het gebruik van de in sleutelwoord beperkt welke updates worden verwerkt. De distribute-list opdracht is beschikbaar voor OSPF, maar het voorkomt niet dat een router gefilterde routes verspreidt. In plaats daarvan kan de opdracht area filter-list worden gebruikt.
Dit EIGRP-voorbeeld filtert uitgaande advertenties met de opdracht distribute-list en een prefix-lijst:
!
ip prefix-list <list-name> seq 10 permit <prefix>
!
router eigrp <as-number>
passive-interface default
no passive-interface <interface>
distribute-list prefix <list-name> out <interface>
!
Dit EIGRP-voorbeeld filtert inkomende updates met een prefix-lijst:
!
ip prefix-list <list-name> seq 10 permit <prefix>
!
router eigrp <as-number>
passive-interface default
no passive-interface <interface>
distribute-list prefix <list-name> in <interface>
!
Zie IP Routing Protocol-Onafhankelijke functies configureren voor meer informatie over hoe u de advertenties en verwerking van routingupdates kunt controleren.
Dit OSPF-voorbeeld gebruikt een prefix-lijst met de OSPF-specifieke opdracht area filter-list:
!
ip prefix-list <list-name> seq 10 permit <prefix>
!
router ospf <process-id>
area <area-id> filter-list prefix <list-name> in
!
Routing Protocol prefixes worden opgeslagen door een router in het geheugen, en het resourceverbruik neemt toe met extra prefixes die een router moet houden. Om middeluitputting te verhinderen, is het belangrijk om het routeringsprotocol te vormen om middelconsumptie te beperken. Dit kan worden uitgevoerd met OSPF als u de functie 'Bescherming van databaseoverbelasting linkstatus' gebruikt.
Dit voorbeeld toont de configuratie van de OSPF-functie 'Bescherming van databaseoverbelasting linkstatus':
!
router ospf <process-id>
max-lsa <maximum-number>
!
Raadpleeg Het aantal zelfgenererende LSA's beperken voor een OSPF-proces voor meer informatie over OSPF Bescherming van databaseoverbelasting linkstatus.
First Hop Redundancy Protocols (FHRP's) bieden veerkracht en redundantie voor apparaten die functioneren als standaardgateways. Deze situatie en deze protocollen zijn standaard in omgevingen waarin een set Layer 3-apparaten standaardgateway-functionaliteit biedt voor een netwerksegment of set VLAN's die servers of werkstations bevatten.
Het Gateway Load-Balancing Protocol (GLBP), Hot Standby Router Protocol (HSRP) en Virtual Router Redundancy Protocol (VRRP) zijn allemaal FHRP's. Standaard communiceren deze protocollen met niet-geverifieerde communicaties. Dit soort communicatie kan een aanvaller toestaan om te poseren als een FHRP-sprekend apparaat om de standaardgatewayrol op het netwerk over te nemen. Deze overname zou een aanvaller in staat stellen een man-in-the-middle aanval uit te voeren en al het gebruikersverkeer dat het netwerk verlaat, te onderscheppen.
Om dit type aanval te voorkomen, bevatten alle FHRP's die worden ondersteund door Cisco IOS-software een verificatiemogelijkheid met MD5 of tekststrings. Vanwege de dreiging van niet-geverifieerde FHRP's wordt aanbevolen dat exemplaren van deze protocollen MD5-verificatie gebruiken. Dit configuratievoorbeeld toont het gebruik van GLBP-, HSRP- en VRRP MD5-verificatie.
!
interface FastEthernet 1
description *** GLBP Authentication ***
glbp 1 authentication md5 key-string <glbp-secret>
glbp 1 ip 10.1.1.1
!
interface FastEthernet 2
description *** HSRP Authentication ***
standby 1 authentication md5 key-string <hsrp-secret>
standby 1 ip 10.2.2.1
!
interface FastEthernet 3
description *** VRRP Authentication ***
vrrp 1 authentication md5 key-string <vrrp-secret>
vrrp 1 ip 10.3.3.1
!
Hoewel het gegevensvlak verantwoordelijk is voor het verplaatsen van gegevens van bron naar bestemming, is binnen de context van veiligheid het gegevensvlak het minst belangrijke van de drie vlakken. Daarom is het belangrijk om de beheer- en besturingsplanen bij voorkeur te beschermen boven het dataplane wanneer u een netwerkapparaat beveiligt.
Binnen de dataplane zelf zijn er echter veel functies en configuratie-opties die kunnen helpen bij het beveiligen van verkeer. In deze secties worden deze functies en opties gedetailleerd, zodat u uw netwerk eenvoudiger kunt beveiligen.
De overgrote meerderheid van de verkeersstromen van het dataplatform over het netwerk zoals bepaald door de routerconfiguratie van het netwerk. IP-netwerkfunctionaliteit is echter aanwezig om het pad van pakketten door het netwerk te wijzigen. Functies zoals IP-opties, met name de optie voor bronrouting, vormen een beveiligingsuitdaging in de huidige netwerken.
Het gebruik van transitACL’s is ook relevant voor de verharding van het gegevensvlak.
Raadpleeg het gedeelte Overgangsverkeer filteren met overgangs-ACL's van dit document voor meer informatie.
IP-opties kennen twee beveiligingskwesties. Het verkeer dat IP-opties bevat, moet via proces-switched worden door Cisco IOS-apparaten, wat kan leiden tot een hogere CPU-belasting. IP-opties bevatten ook de functionaliteit om het pad te wijzigen dat het verkeer door het netwerk neemt, waardoor het mogelijk beveiligingscontroles kan omkeren.
Vanwege deze kwesties is de globale configuratie-opdracht ip options {drop | ignore} toegevoegd aan Cisco IOS-softwarereleases 12.3(4)T, 12.0(22)S en 12.2(25)S. In de eerste vorm van deze opdracht, ip-opties drop, worden alle IP-pakketten die IP-opties bevatten die worden ontvangen door het Cisco IOS-apparaat gedropt. Hiermee wordt de verhoogde CPU-belasting en de mogelijke ondermijning van beveiligingscontroles voorkomen die door IP-opties mogelijk kunnen worden.
De tweede vorm van deze opdracht, ip-opties negeren, configureert het Cisco IOS-apparaat om IP-opties die in ontvangen pakketten zitten, te negeren. Terwijl dit de bedreigingen met betrekking tot IP opties voor het lokale apparaat verlicht, is het mogelijk dat de stroomafwaartse apparaten door de aanwezigheid van IP opties zouden kunnen worden beïnvloed. Het is om deze reden dat de drop vorm van deze opdracht wordt ten zeerste aanbevolen. Dit wordt aangetoond in het configuratievoorbeeld:
!
ip options drop
!
Sommige protocollen, zoals de RSVP, maken legitiem gebruik van IP-opties. De functionaliteit van deze protocollen wordt beïnvloed door deze opdracht.
Als IP Options Selective Drop eenmaal is ingeschakeld, kan de opdracht IP traffic EXEC worden gebruikt om het aantal pakketten te bepalen dat vanwege de aanwezigheid van IP-opties wordt verbroken. Deze informatie is aanwezig in de teller voor gedwongen verwijderingen.
Raadpleeg ACL IP-opties selectief verlies voor meer informatie over deze functie.
IP-bronrouting maakt gebruik van de opties Loose Source Route en Record Route in tandem of de strikte bronroute samen met de optie Record Route om de bron van het IP-datagram in staat te stellen het netwerkpad te specificeren dat een pakket neemt. Deze functionaliteit kan worden gebruikt in pogingen om verkeer rond veiligheidscontroles in het netwerk te leiden.
Als IP-opties niet volledig zijn uitgeschakeld via de functie IP-opties selectieve drop, is het belangrijk dat IP-bronrouting is uitgeschakeld. IP-bronrouting, die standaard is ingeschakeld in alle Cisco IOS-softwarereleases, is uitgeschakeld via de globale configuratieopdracht geen IP-bronroute. Dit configuratievoorbeeld toont het gebruik van deze opdracht:
!
no ip source-route
!
ICMP-omleidingen worden gebruikt om een netwerkapparaat te informeren over een beter pad naar een IP-bestemming. Standaard stuurt de Cisco IOS-software een omleiding als deze een pakket ontvangt dat door de interface waarop het is ontvangen, moet worden gerouteerd.
In sommige situaties, zou het voor een aanvaller kunnen zijn om het Cisco IOS apparaat te veroorzaken om vele ICMP te verzenden opnieuw richt berichten, die in een verhoogde lading van cpu resulteren. Om deze reden wordt aanbevolen om de transmissie van ICMP-omleidingen uit te schakelen. ICMP-omleidingen zijn uitgeschakeld met de interfaceconfiguratie op IP-omleidingen, zoals in de voorbeeldconfiguratie:
!
interface FastEthernet 0
no ip redirects
!
IP-omgeleide uitzendingen zorgen voor dat een IP-uitzendpakket naar een extern IP-subnet kan worden verzonden. Zodra het het externe netwerk bereikt, verstuurt het doorsturen IP-apparaat het pakket als Layer 2-uitzending naar alle stations op het subnetnetwerk. Deze direct uitgezonden functionaliteit is gebruikt als een versterker en reflectie hulp in verschillende aanvallen, waaronder de smurf aanval.
Bij de huidige versies van Cisco IOS-software is deze functionaliteit standaard uitgeschakeld. U kunt deze echter inschakelen via de opdracht voor de configuratie van de ip direct-broadcast interface. Releases van Cisco IOS-software vóór 12.0 hebben deze functionaliteit standaard ingeschakeld.
Als een netwerk absoluut een gerichte uitzendfunctionaliteit nodig heeft, moet het gebruik ervan worden gecontroleerd. Dit is mogelijk met het gebruik van een toegangscontrolelijst als optie voor de opdracht ip directed-broadcast. Dit configuratievoorbeeld beperkt geleide uitzendingen tot die UDP-pakketten die afkomstig zijn van een vertrouwd netwerk, 192.168.1.0/24:
!
access-list 100 permit udp 192.168.1.0 0.0.0.255 any
!
interface FastEthernet 0
ip directed-broadcast 100
!
Het is mogelijk om te beheren welk verkeer door het netwerk beweegt met het gebruik van overgangs-ACL's (tACL's). Dit in tegenstelling tot infrastructuur ACL’s die verkeer willen filteren dat bestemd is voor het netwerk zelf. Het filteren door tACL’s is gunstig wanneer het wenselijk is om verkeer te filteren op een bepaalde groep apparaten of verkeer die het netwerk doorvoert.
Dit type van het filtreren wordt traditioneel uitgevoerd door firewalls. Er zijn echter gevallen waarin het nuttig kan zijn om dit filteren op een Cisco IOS-apparaat in het netwerk uit te voeren, bijvoorbeeld waar filtering moet worden uitgevoerd maar geen firewall aanwezig is.
Transit ACL’s zijn ook een geschikte plaats om statische bescherming tegen spoofing te implementeren.
Raadpleeg het gedeelte Beschermingen voor anti-spoofing van dit document voor meer informatie.
Raadpleeg Transit Access Control Lists: filteren aan uw zijde voor meer informatie over tACL's.
Het Internet Control Message Protocol (ICMP) is ontworpen als een beheerprotocol voor IP. Als zodanig kunnen de berichten die worden overgebracht verreikende gevolgen hebben voor de TCP- en IP-protocollen in het algemeen. ICMP wordt gebruikt door de tools voor netwerkprobleemoplossing ping en traceroute en door Path MTU Discovery. Externe ICMP-connectiviteit is echter zelden nodig voor de juiste werking van een netwerk.
Cisco IOS-software biedt functionaliteit om ICMP-berichten specifiek op naam of type en code te filteren. Dit voorbeeld ACL staat ICMP toe van vertrouwde netwerken terwijl het alle ICMP-pakketten uit andere bronnen blokkeert:
!
ip access-list extended ACL-TRANSIT-IN
!
!--- Permit ICMP packets from trusted networks only
!
permit icmp host <trusted-networks> any
!
!--- Deny all other IP traffic to any network device
!
deny icmp any any
!
Zoals eerder in de sectie Toegang tot netwerk met infrastructuur-ACL’s van dit document is uiteengezet, kan het filteren van gefragmenteerde IP-pakketten een uitdaging vormen voor beveiligingsapparaten.
Vanwege de niet-intuïtieve aard van fragmentverwerking worden IP-fragmenten vaak onbedoeld toegestaan door ACL’s. Fragmentatie wordt ook vaak gebruikt in pogingen om detectie te ontwijken door intrusiedetectiesystemen. Het is om deze redenen dat IP fragmenten vaak in aanvallen worden gebruikt en uitdrukkelijk bij om het even welke gevormde tACLs zouden moeten worden gefiltreerd. In de ACL hieronder vindt u uitgebreide filtering van IP-fragmenten. De functionaliteit die in dit voorbeeld wordt geïllustreerd, moet worden gebruikt in combinatie met de functionaliteit van de voorgaande voorbeelden:
!
ip access-list extended ACL-TRANSIT-IN
!
!--- Deny IP fragments using protocol-specific ACEs to aid in
!--- classification of attack traffic
!
deny tcp any any fragments
deny udp any any fragments
deny icmp any any fragments
deny ip any any fragments
!
Raadpleeg Toegangscontrolelijsten en IP-fragmenten voor meer informatie over ACL-verwerking van gefragmenteerde IP-pakketten.
In Cisco IOS-softwarerelease 12.3(4)T en hoger ondersteunt Cisco IOS-software het gebruik van ACL’s om IP-pakketten te filteren op basis van de IP-opties die in het pakket aanwezig zijn. De aanwezigheid van IP-opties in een pakket kan wijzen op een poging om beveiligingscontroles in het netwerk te omzeilen of op een andere manier de transitkenmerken van een pakket te wijzigen. Om deze redenen moeten pakketten met IP-opties aan de rand van het netwerk worden gefilterd.
Dit voorbeeld moet met de inhoud van eerdere voorbeelden worden gebruikt om volledige filtering van IP-pakketten met IP-opties te omvatten:
!
ip access-list extended ACL-TRANSIT-IN
!
!--- Deny IP packets containing IP options
!
deny ip any any option any-options
!
Veel aanvallen gebruiken spoofing van bron-IP-adressen om effectief te zijn of om de echte bron van een aanval te verhullen en goede traceback te verhinderen. Cisco IOS-software biedt Unicast RPF en IP Source Guard (IPSG) om aanvallen te voorkomen die afhankelijk zijn van IP-bronadresspoofing. Bovendien worden ACL's en null-routering vaak geïmplementeerd als handmatige methode om spoofing te voorkomen.
IP Source Guard werkt aan het minimaliseren van spoofing voor netwerken die onder directe bestuurlijke controle staan door switch poort, MAC-adres en bronadresverificatie uit te voeren. Unicast RPF biedt verificatie van het bronnetwerk en kan gespoofde aanvallen van netwerken die niet onder directe administratieve controle staan, verminderen. Poortbeveiliging kan worden gebruikt om MAC-adressen op de toegangslaag te valideren. Dynamic Address Resolution Protocol (ARP) Inspection (DAI) vermindert aanvalsvectoren die ARP-poisoning op lokale segmenten gebruiken.
Unicast PDF stelt een apparaat in staat om te verifiëren dat het bronadres van een doorgestuurd pakket kan worden bereikt via de interface die het pakket heeft ontvangen. U mag niet vertrouwen op Unicast RPF als de enige bescherming tegen spoofing. Gespoofte pakketten kunnen het netwerk binnenkomen via een interface met Unicast RPF als een geschikte retourneringsroute naar het bron-IP-adres bestaat. Unicast RPF vertrouwt erop dat u Cisco Express Forwarding inschakelt op elk apparaat en wordt op interfacebasis geconfigureerd.
Unicast RPF kan in twee modi worden geconfigureerd: vrij of strikt. Wanneer er sprake is van asymmetrische routering, heeft de vrije modus de voorkeur omdat van de strikte modus bekend is dat in deze situaties pakketten worden verwijderd. Tijdens de configuratie van de interfaceconfiguratie-opdracht ip verify configureert het trefwoord any de vrije modus terwijl het trefwoord rx de strikte modus configureert.
Dit voorbeeld toont de configuratie van deze functie:
!
ip cef
!
interface <interface>
ip verify unicast source reachable-via <mode>
!
Raadpleeg Inzicht in Unicast Reverse Path Forwarding voor meer informatie over de configuratie en het gebruik van Unicast RPF.
IP-bronbewaker is een effectieve methode voor spoofing-preventie die kan worden gebruikt als u het beheer over Layer 2-interfaces hebt. IP Source Guard gebruikt informatie van DHCP-controle om dynamisch een poorttoegangscontrolelijst (PACL) op Layer 2-interface te configureren en ontkent daarbij elk verkeer vanaf IP-adressen die niet in de bindende IP-brontabel zijn gekoppeld.
IP Source Guard kan worden toegepast op Layer 2-interfaces die behoren tot DHCP-snooping-enabled VLAN’s. Deze opdrachten maken DHCP-snooping mogelijk:
!
ip dhcp snooping
ip dhcp snooping vlan <vlan-range>
!
Nadat DHCP-snooping is ingeschakeld, maken deze opdrachten IPSG mogelijk:
!
interface <interface-id>
ip verify source
!
Poortbeveiliging kan worden ingeschakeld met de opdracht van de configuratie van de IP-verify-bronpoortbeveiliging. Hiervoor is de globale configuratie-opdracht ip dhcp snooping information option vereist; bovendien moet de DHCP-server DHCP-optie 82 ondersteunen.
Raadpleeg DHCP-functies en IP-bronbewaking configureren voor meer informatie over deze functie.
Poortbeveiliging wordt gebruikt om MAC-adresspoofing op de toegangsinterface te beperken. Poortbeveiliging kan dynamisch geleerde (persistente) MAC-adressen gebruiken om de initiële configuratie eenvoudiger te maken. Zodra poortbeveiliging een MAC-overtreding heeft vastgesteld, kan deze functie een van de vier overtredingsmodi gebruiken. Deze modi zijn VLAN beveiligen, beperken, afsluiten en afsluiten. In gevallen waarin een poort alleen toegang biedt voor één werkstation met behulp van standaardprotocollen, kan een maximum aantal van één voldoende zijn. Protocollen die gebruik maken van virtuele MAC-adressen zoals HSRP werken niet wanneer het maximum aantal is ingesteld op één.
!
interface <interface>
switchport
switchport mode access
switchport port-security
switchport port-security mac-address sticky
switchport port-security maximum <number>
switchport port-security violation <violation-mode>
!
Raadpleeg Poortbeveiliging configureren voor meer informatie over de configuratie van Poortbeveiliging.
Dynamic ARP Inspection (DAI) kan worden gebruikt om ARP-vergiftigingsaanvallen op lokale segmenten te verlichten. Een ARP-poisoning-aanval is een methode waarmee een aanvaller vervalste ARP-informatie naar een lokaal segment stuurt. Deze informatie wordt ontworpen om het ARP geheim voorgeheugen van andere apparaten te corrumperen. Vaak gebruikt een aanvaller ARP-vergiftiging om een man-in-the-middle aanval uit te voeren.
DAI onderschept en valideert de relatie IP-naar-MAC-adres van alle ARP-pakketten op niet-vertrouwde poorten. In DHCP-omgevingen gebruikt DAI de gegevens die worden gegenereerd door de functie DHCP-snooping. ARP-pakketten die worden ontvangen op vertrouwde interfaces worden niet gevalideerd en ongeldige pakketten op onbetrouwbare interfaces worden verworpen. In niet-DHCP-omgevingen is het gebruik van ARP ACL's vereist.
Deze opdrachten maken DHCP-snooping mogelijk:
!
ip dhcp snooping
ip dhcp snooping vlan <vlan-range>
!
Zodra DHCP-snooping is ingeschakeld, maken deze opdrachten DAI mogelijk:
!
ip arp inspection vlan <vlan-range>
!
In niet DHCP-omgevingen zijn ARP ACL’s vereist om DAI in te schakelen. Dit voorbeeld toont de basisconfiguratie van DAI met ARP ACL's:
!
arp access-list <acl-name>
permit ip host <sender-ip> mac host <sender-mac>
!
ip arp inspection filter <arp-acl-name> vlan <vlan-range>
!
DAI kan ook per interface worden ingeschakeld als dat wordt ondersteund.
ip arp inspection limit rate <rate_value> burst interval <interval_value>
Raadpleeg Dynamische ARP-inspectie configureren voor meer informatie over het configureren van DAI.
Handmatig geconfigureerde ACL's kunnen statische anti-spoofing-bescherming bieden tegen aanvallen die bekende ongebruikte en niet-vertrouwde adresruimte gebruiken. Deze anti-spoofing ACL's worden vaak toegepast op inkomend verkeer bij netwerkgrenzen als een component van een grotere ACL. Anti-spoofing ACL’s vereisen regelmatige bewaking omdat ze vaak kunnen veranderen. Spoofing kan worden geminimaliseerd in verkeer dat zijn oorsprong heeft in het lokale netwerk als u uitgaande ACL's toepast die het verkeer naar geldige lokale adressen beperken.
Dit voorbeeld toont aan hoe ACL’s kunnen worden gebruikt om IP-spoofing te beperken. Deze ACL wordt inkomend toegepast op de gewenste interface. De ACE's waaruit deze ACL bestaat, zijn niet allesomvattend. Als u deze typen ACL’s configureert, zoekt u een actuele referentie die beslissend is.
!
ip access-list extended ACL-ANTISPOOF-IN
deny ip 10.0.0.0 0.255.255.255 any
deny ip 192.168.0.0 0.0.255.255 any
!
interface <interface>
ip access-group ACL-ANTISPOOF-IN in
!
Raadpleeg Veelgebruikte IP-ACL's configureren voor meer informatie over het configureren van Access Control Lists.
De officiële lijst van niet-toegewezen internetadressen wordt onderhouden door Team Cymru. Aanvullende informatie over het filteren van ongebruikte adressen is beschikbaar op de Bogon Reference Page .
Het primaire doel van routers en switches is om pakketten en frames via het apparaat door te sturen naar eindbestemmingen. Deze pakketten, die door de apparaten bewegen die zijn geïmplementeerd in het netwerk, kunnen invloed hebben op de CPU-activiteiten van een apparaat. Het gegevensvlak, dat bestaat uit verkeer dat het netwerkapparaat doorkruist, moet worden beveiligd om de werking van de beheer- en bedieningsvlakken te waarborgen. Indien het transitoverkeer ertoe kan leiden dat een switch het verkeer verwerkt, kan dit gevolgen hebben voor het controlevlak van een inrichting, wat kan leiden tot een verstoring van de werking.
Hoewel niet uitputtend, omvat deze lijst types van gegevensvliegtuigverkeer die speciale verwerking van cpu vereisen en door cpu proces geschakeld zijn:
Raadpleeg het gedeelte Versterking algemene dataplane van dit document voor meer informatie over versterking van dataplane.
U kunt de ACL-ondersteuning voor filtering op TTL-waarde, geïntroduceerd in Cisco IOS-softwarerelease 12.4(2)T, in een uitgebreide IP-toegangslijst gebruiken om pakketten te filteren op basis van TTL-waarde. Deze functie kan worden gebruikt om een apparaat te beveiligen dat transitoverkeer ontvangt wanneer de TTL-waarde een nul of een is. Filterpakketten op basis van TTL-waarden kunnen ook worden gebruikt om ervoor te zorgen dat de TTL-waarde niet lager is dan de diameter van het netwerk, waardoor het besturingsplane van stroomafwaartse infrastructuurapparaten wordt beschermd tegen TTL-expiratieaanvallen.
Merk op dat sommige toepassingen en hulpmiddelen zoals traceroute TTL-vervalpakketten voor test- en diagnostische doeleinden gebruiken. Sommige protocollen, zoals IGMP, gebruiken op een legitieme manier een TTL-waarde van één.
Dit ACL-voorbeeld maakt een beleid dat IP-pakketten filtert wanneer de TTL-waarde lager is dan 6.
!
!--- Create ACL policy that filters IP packets with a TTL value
!--- less than 6
!
ip access-list extended ACL-TRANSIT-IN
deny ip any any ttl lt 6
permit ip any any
!
!--- Apply access-list to interface in the ingress direction
!
interface GigabitEthernet 0/0
ip access-group ACL-TRANSIT-IN in
!
Raadpleeg de TTL-pakketidentificatie en -beperking voor meer informatie over filtreerpakketten op basis van de TTL-waarde.
Raadpleeg ACL-ondersteuning voor filteren op TTL-waarde voor meer informatie over deze functie.
In Cisco IOS-softwarerelease 12.4(4)T en hoger kan een beheerder met Flexible Packet Matching (FPM) overeenkomsten in willekeurige stukjes van een pakket zoeken. Met dit FPM-beleid worden pakketten met een TTL-waarde van minder dan zes verlaagd.
!
load protocol flash:ip.phdf
!
class-map type access-control match-all FPM-TTL-LT-6-CLASS
match field IP ttl lt 6
!
policy-map type access-control FPM-TTL-LT-6-DROP-POLICY
class FPM-TTL-LT-6-CLASS
drop
!
interface FastEthernet0
service-policy type access-control input FPM-TTL-LT-6-DROP-POLICY
!
Raadpleeg Flexible Packet Matching, te vinden op de startpagina Cisco IOS Flexible Packet Matching, voor meer informatie over de functie.
In Cisco IOS-softwarerelease 12.3(4)T en hoger kunt u de ACL-ondersteuning voor de functie Filterende IP-opties in een benoemde, uitgebreide IP-toegangslijst gebruiken om IP-pakketten met aanwezige IP-opties te filteren. Filterende IP-pakketten die zijn gebaseerd op de aanwezigheid van IP-opties kunnen ook worden gebruikt om te voorkomen dat het besturingsplane van infrastructurele apparaten deze pakketten op CPU-niveau moet verwerken.
Merk op dat de ACL-ondersteuning voor filtering van IP-opties alleen kan worden gebruikt met benoemde, uitgebreide ACL’s. Er moet ook worden opgemerkt dat RSVP, Multiprotocol Label Switching Traffic Engineering, IGMP versies 2 en 3 en andere protocollen die IP-optiepakketten gebruiken, mogelijk niet goed kunnen functioneren als pakketten voor deze protocollen worden gedropt. Als deze protocollen in het netwerk worden gebruikt, kan de ACL-ondersteuning voor IP-filtering worden gebruikt. De functie voor selectieve drop van ACL-opties kan echter dit verkeer uitschakelen en deze protocollen werken mogelijk niet goed. Als er geen protocollen in gebruik zijn die IP-opties vereisen, is 'ACL IP-opties selectief verlies' de voorkeursmethode om deze pakketten te verwijderen.
Dit ACL-voorbeeld stelt een beleid op waarmee IP-pakketten worden gefilterd die IP-opties bevatten:
!
ip access-list extended ACL-TRANSIT-IN
deny ip any any option any-options
permit ip any any
!
interface GigabitEthernet 0/0
ip access-group ACL-TRANSIT-IN in
!
Deze voorbeeld-ACL toont een beleid dat IP-pakketten met vijf specifieke IP-opties filtert. Pakketten die deze opties bevatten, worden geweigerd:
!
ip access-list extended ACL-TRANSIT-IN
deny ip any any option eool
deny ip any any option record-route
deny ip any any option timestamp
deny ip any any option lsr
deny ip any any option ssr
permit ip any any
!
interface GigabitEthernet 0/0
ip access-group ACL-TRANSIT-IN in
!
Zie het gedeelte Algemeen gegevensvlak voor verharding van dit document voor meer informatie over selectieve drop van ACL-opties voor IP-beveiliging.
Raadpleeg Transit Access Control Lists: filtering aan uw edge voor meer informatie over het filteren van transit- en randverkeer.
Een andere eigenschap in Cisco IOS-software die kan worden gebruikt om pakketten met IP-opties te filteren is CoPP. In Cisco IOS-softwarerelease 12.3(4)T en hoger kan een beheerder met CoPP de verkeersstroom van besturingsplanepakketten filteren. Een apparaat dat CoPP en ACL-ondersteuning voor filtering van IP-opties ondersteunt, dat is geïntroduceerd in Cisco IOS-softwarerelease 12.3(4)T, kan een toegangslijstbeleid gebruiken om pakketten te filteren die IP-opties bevatten.
Dit CoPP-beleid verwijdert overgangspakketten die worden ontvangen door een apparaat wanneer er IP-opties aanwezig zijn:
!
ip access-list extended ACL-IP-OPTIONS-ANY
permit ip any any option any-options
!
class-map ACL-IP-OPTIONS-CLASS
match access-group name ACL-IP-OPTIONS-ANY
!
policy-map COPP-POLICY
class ACL-IP-OPTIONS-CLASS
drop
!
control-plane
service-policy input COPP-POLICY
!
Dit CoPP-beleid verwijdert overgangspakketten die worden ontvangen door een apparaat wanneer deze IP-opties aanwezig zijn:
!
ip access-list extended ACL-IP-OPTIONS
permit ip any any option eool
permit ip any any option record-route
permit ip any any option timestamp
permit ip any any option lsr
permit ip any any option ssr
!
class-map ACL-IP-OPTIONS-CLASS
match access-group name ACL-IP-OPTIONS
!
policy-map COPP-POLICY
class ACL-IP-OPTIONS-CLASS
drop
!
control-plane
service-policy input COPP-POLICY
!
In het voorafgaande CoPP beleid, resulteren de ingangen van de toegangscontrolelijst (ACEs) die pakketten met de vergunningsactie aanpassen in deze pakketten die door de beleid-kaart drop-functie worden verworpen, terwijl de pakketten die de ontkennen actie (niet getoond) aanpassen niet door de beleid-kaart drop-functie worden beïnvloed.
Raadpleeg Control Plane Policing implementeren voor meer informatie over de CoPP-functie.
In Cisco IOS-softwarerelease 12.4(4)T en hoger kan CPPr (Control Plane Protection) worden gebruikt om vliegverkeer via de CPU van een Cisco IOS-apparaat te beperken of te bewaken. Hoewel vergelijkbaar met CoPP, CPPr heeft de mogelijkheid om verkeer te beperken of te controleren met behulp van fijnere granulariteit dan CoPP. CPPr verdeelt de geaggregeerde besturingsplane in drie afzonderlijke planecategorieën, bekend als subinterfaces: de subinterfaces Host, Transit en CEF-Exception bestaan.
Dit CPPr-beleid verwijdert overgangspakketten die zijn ontvangen door een apparaat wanneer de TTL-waarde lager is dan 6, en overgangs- of niet-overgangspakketten die zijn ontvangen door een apparaat wanneer de TTL-waarde nul of één is. Het CPPr-beleid verwijdert ook pakketten met geselecteerde IP-opties ontvangen door het apparaat.
!
ip access-list extended ACL-IP-TTL-0/1
permit ip any any ttl eq 0 1
!
class-map ACL-IP-TTL-0/1-CLASS
match access-group name ACL-IP-TTL-0/1
!
ip access-list extended ACL-IP-TTL-LOW
permit ip any any ttl lt 6
!
class-map ACL-IP-TTL-LOW-CLASS
match access-group name ACL-IP-TTL-LOW
!
ip access-list extended ACL-IP-OPTIONS
permit ip any any option eool
permit ip any any option record-route
permit ip any any option timestamp
permit ip any any option lsr
permit ip any any option ssr
!
class-map ACL-IP-OPTIONS-CLASS
match access-group name ACL-IP-OPTIONS
!
policy-map CPPR-CEF-EXCEPTION-POLICY
class ACL-IP-TTL-0/1-CLASS
drop
class ACL-IP-OPTIONS-CLASS
drop
!
!-- Apply CPPr CEF-Exception policy CPPR-CEF-EXCEPTION-POLICY to
!-- the CEF-Exception CPPr sub-interface of the device
!
control-plane cef-exception
service-policy input CPPR-CEF-EXCEPTION-POLICY
!
policy-map CPPR-TRANSIT-POLICY
class ACL-IP-TTL-LOW-CLASS
drop
!
control-plane transit
service-policy input CPPR-TRANSIT-POLICY
!
In het vorige CPPr beleid, de ingangen van de toegangscontrolelijst die pakketten met het resultaat van de vergunningsactie aanpassen in deze pakketten die door de beleid-kaart drop-functie worden verworpen, terwijl de pakketten die de ontkennen actie (niet getoond) aanpassen niet door de beleid-kaart drop-functie worden beïnvloed.
Raadpleeg Inzicht in bescherming van besturingsplane en Control Plane Protection voor meer informatie over de CPPr-functie.
Soms moet u netwerkverkeer snel identificeren en een traceback erop uitvoeren, voornamelijk tijdens incidentrespons of slechte netwerkprestaties. NetFlow en Classificatie ACL’s zijn de twee primaire methoden om dit te bereiken met Cisco IOS-software. NetFlow kan inzicht in al het verkeer op het netwerk bieden. Bovendien kan NetFlow worden geïmplementeerd met verzamelaars die trending- en geautomatiseerde analyses voor de lange termijn kunnen bieden. Classificatie-ACL's zijn een component van ACL's en vereisen pre-planning om specifiek verkeer en handmatige interventie tijdens analyse te identificeren. Deze gedeelten bieden een kort overzicht van elke functie.
NetFlow identificeert abnormale en aan beveiliging gerelateerde netwerkactiviteit door netwerkstromen te volgen. NetFlow-gegevens kunnen worden bekeken en geanalyseerd via de CLI, of de gegevens kunnen worden geëxporteerd naar een commerciële of freeware NetFlow Collector voor aggregatie en analyse. NetFlow Collectors, door lange termijn trending, kunnen netwerkgedrag en gebruiksanalyse leveren. NetFlow functioneert door analyse uit te voeren op specifieke kenmerken binnen IP-pakketten en stromen te maken. Versie 5 is de meest gebruikte versie van NetFlow, maar versie 9 is meer uitbreidbaar. NetFlow-stromen kunnen in omgevingen met hoog volume worden gemaakt van sampled verkeersgegevens.
CEF, of gedistribueerde CEF, is een voorwaarde voor het inschakelen van NetFlow. NetFlow kan worden geconfigureerd op routers en switches.
Dit voorbeeld illustreert de basisconfiguratie van deze functie. In eerdere releases van Cisco IOS-software is de opdracht om NetFlow in te schakelen op een interface ip route-cache flow in plaats van ip flow {ingress | egress}.
!
ip flow-export destination <ip-address> <udp-port>
ip flow-export version <version>
!
interface <interface>
ip flow <ingess|egress>
!
Dit is een voorbeeld van NetFlow-uitvoer van de CLI. Het SrcIf-kenmerk kan helpen bij de traceback.
router#show ip cache flow
IP packet size distribution (26662860 total packets):
1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480
.741 .124 .047 .006 .005 .005 .002 .008 .000 .000 .003 .000 .001 .000 .000
512 544 576 1024 1536 2048 2560 3072 3584 4096 4608
.000 .000 .001 .007 .039 .000 .000 .000 .000 .000 .000
IP Flow Switching Cache, 4456704 bytes
55 active, 65481 inactive, 1014683 added
41000680 ager polls, 0 flow alloc failures
Active flows timeout in 2 minutes
Inactive flows timeout in 60 seconds
IP Sub Flow Cache, 336520 bytes
110 active, 16274 inactive, 2029366 added, 1014683 added to flow
0 alloc failures, 0 force free
1 chunk, 15 chunks added
last clearing of statistics never
Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec)
-------- Flows /Sec /Flow /Pkt /Sec /Flow /Flow
TCP-Telnet 11512 0.0 15 42 0.2 33.8 44.8
TCP-FTP 5606 0.0 3 45 0.0 59.5 47.1
TCP-FTPD 1075 0.0 13 52 0.0 1.2 61.1
TCP-WWW 77155 0.0 11 530 1.0 13.9 31.5
TCP-SMTP 8913 0.0 2 43 0.0 74.2 44.4
TCP-X 351 0.0 2 40 0.0 0.0 60.8
TCP-BGP 114 0.0 1 40 0.0 0.0 62.4
TCP-NNTP 120 0.0 1 42 0.0 0.7 61.4
TCP-other 556070 0.6 8 318 6.0 8.2 38.3
UDP-DNS 130909 0.1 2 55 0.3 24.0 53.1
UDP-NTP 116213 0.1 1 75 0.1 5.0 58.6
UDP-TFTP 169 0.0 3 51 0.0 15.3 64.2
UDP-Frag 1 0.0 1 1405 0.0 0.0 86.8
UDP-other 86247 0.1 226 29 24.0 31.4 54.3
ICMP 19989 0.0 37 33 0.9 26.0 53.9
IP-other 193 0.0 1 22 0.0 3.0 78.2
Total: 1014637 1.2 26 99 32.8 13.8 43.9
SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts
Gi0/1 192.168.128.21 Local 192.168.128.20 11 CB2B 07AF 3
Gi0/1 192.168.150.60 Gi0/0 10.89.17.146 06 0016 101F 55
Gi0/0 10.89.17.146 Gi0/1 192.168.150.60 06 101F 0016 9
Gi0/1 192.168.150.60 Local 192.168.206.20 01 0000 0303 11
Gi0/0 10.89.17.146 Gi0/1 192.168.150.60 06 07F1 0016 1
Raadpleeg Cisco IOS NetFlow voor meer informatie over NetFlow-mogelijkheden.
Raadpleeg Een inleiding tot Cisco IOS NetFlow - Een technisch overzicht voor een technisch overzicht van NetFlow.
Classificatie-ACL's bieden inzicht in verkeer dat door een interface beweegt. Classificatie-ACL's wijzigen het beveiligingsbeleid van een netwerk niet en worden normaal gesproken opgebouwd om afzonderlijke protocollen, bronadressen of bestemmingen te classificeren. Een ACE die bijvoorbeeld al het verkeer toestaat, kan worden gescheiden in specifieke protocollen of poorten. Deze meer granulaire classificatie van verkeer in specifieke ACE's kan helpen om een begrip van het netwerkverkeer te geven omdat elke verkeerscategorie zijn eigen hit teller heeft. Een beheerder zou impliciet ook kunnen scheiden ontkent aan het eind van een ACL in korrelige ACE's om te helpen de types van ontkend verkeer identificeren.
Een beheerder kan een incidentele reactie versnellen door classificatie ACL's met de show access-list te gebruiken en IP access-list tellers EXEC te wissen.
Dit voorbeeld illustreert de configuratie van een classificatie ACL om SMB verkeer te identificeren voorafgaand aan een gebrek ontkennen:
!
ip access-list extended ACL-SMB-CLASSIFY
remark Existing contents of ACL
remark Classification of SMB specific TCP traffic
deny tcp any any eq 139
deny tcp any any eq 445
deny ip any any
!
Om het verkeer te identificeren dat classificatie ACL gebruikt, gebruik het show access-list acl-name EXEC bevel. De ACL-tellers kunnen worden gewist met de duidelijke IP-toegangslijst tellers van de acl-name EXEC-opdracht.
router#show access-list ACL-SMB-CLASSIFY
Extended IP access list ACL-SMB-CLASSIFY
10 deny tcp any any eq 139 (10 matches)
20 deny tcp any any eq 445 (9 matches)
30 deny ip any any (184 matches)
Raadpleeg Logboekregistratie toegangscontrolelijst begrijpen voor meer informatie over het inschakelen van registratiemogelijkheden binnen ACL’s.
VLAN Access Control Lists (VACL's), of VLAN-kaarten en Poort-ACL's (PACL's), bieden de mogelijkheid om toegangscontrole toe te passen op niet-gerouteerd verkeer dat zich dichter bij eindpuntapparaten bevindt dan ACL's die worden toegepast op gerouteerde interfaces.
Deze secties geven een overzicht van de functies, voordelen en mogelijke gebruiksscenario’s van VACL’s en PACL’s.
VACL’s of VLAN-kaarten die van toepassing zijn op alle pakketten die het VLAN invoeren, bieden de mogelijkheid om toegangscontrole op verkeer binnen VLAN af te dwingen. Dit is niet mogelijk met ACL's op gerouteerde interfaces. Een VLAN-kaart kan bijvoorbeeld worden gebruikt om te voorkomen dat hosts die binnen hetzelfde VLAN zijn opgenomen, met elkaar communiceren, waardoor de mogelijkheden voor lokale aanvallers of wormen om een host op hetzelfde netwerksegment te exploiteren, worden beperkt. Om pakketten te ontkennen van het gebruik van een VLAN-kaart, kunt u een toegangscontrolelijst (ACL) maken die overeenkomt met het verkeer en, in de VLAN-kaart, de actie instellen om te laten vallen. Wanneer een VLAN-map is geconfigureerd, worden alle pakketten die de LAN binnenkomen opvolgend geëvalueerd aan de hand van de geconfigureerde VLAN-kaart. VLAN-toegangskaarten ondersteunen IPv4- en MAC-toegangslijsten. Ze ondersteunen echter geen vastlegging of IPv6-ACL’s.
Dit voorbeeld gebruikt een uitgebreide benoemde toegangslijst die de configuratie van deze functie toont:
!
ip access-list extended <acl-name>
permit <protocol> <source-address> <source-port> <destination-address>
<destination-port>
!
vlan access-map <name> <number>
match ip address <acl-name>
action <drop|forward>
!
Dit voorbeeld toont het gebruik van een VLAN-kaart aan om TCP-poorten 139 en 445 en het wijnstokken-ip-protocol te ontkennen:
!
ip access-list extended VACL-MATCH-ANY
permit ip any any
!
ip access-list extended VACL-MATCH-PORTS
permit tcp 192.168.1.0 0.0.0.255 192.168.1.0 0.0.0.255 eq 445
permit tcp 192.168.1.0 0.0.0.255 192.168.1.0 0.0.0.255 eq 139
!
mac access-list extended VACL-MATCH-VINES
permit any any vines-ip
!
vlan access-map VACL 10
match ip address VACL-MATCH-VINES
action drop
!
vlan access-map VACL 20
match ip address VACL-MATCH-PORTS
action drop
!
vlan access-map VACL 30
match ip address VACL-MATCH-ANY
action forward
!
vlan filter VACL vlan 100
!
Raadpleeg Netwerkbeveiliging configureren met ACL's voor meer informatie over de configuratie van VLAN-kaarten.
PACL's kunnen alleen worden toegepast op de inkomende richting op Layer 2 fysieke interfaces van een switch. Net zoals VLAN-kaarten bieden PACL's toegangscontrole op niet-gerouteerd Layer 2-verkeer. De syntaxis voor het maken van PACL's, die prioriteit heeft over VLAN-kaarten en router-ACL's, is hetzelfde als router-ACL's. Als een ACL is toegepast op een Layer 2-interface, wordt hiernaar verwezen met PACL. Configuratie omvat het maken van een IPv4, IPv6 of MAC-ACL en toepassing hiervan op de Layer 2-interface.
Dit voorbeeld gebruikt een uitgebreide genoemde toegangslijst om de configuratie van deze eigenschap te illustreren:
!
ip access-list extended <acl-name>
permit <protocol> <source-address> <source-port> <destination-address>
<destination-port>
!
interface <type> <slot/port>
switchport mode access
switchport access vlan <vlan_number>
ip access-group <acl-name> in
!
Raadpleeg het gedeelte Poort-ACL van Netwerkbeveiliging configureren met ACL's voor meer informatie over de configuratie van PACL's.
MAC-toegangscontrolelijsten of uitgebreide lijsten kunnen op IP-netwerk worden toegepast met het gebruik van deze opdracht in interfaceconfiguratiemodus:
Cat6K-IOS(config-if)#mac packet-classify
Opmerking: Layer 3-pakketten moeten worden geclassificeerd als Layer 2-pakketten. De opdracht wordt ondersteund in Cisco IOS-softwarerelease 12.2(18)SXD (voor Sup 720) en Cisco IOS-softwarereleases 12.2(33)SRA of nieuwer.
Dit interfacebevel moet op de toegangsinterface worden toegepast en het draagt de het door:sturen motor op om de IP kopbal niet te inspecteren. Het resultaat is dat u een MAC-toegangslijst kunt gebruiken in de IP-omgeving.
Private VLAN’s (VLAN’s) zijn een Layer 2-beveiligingsfunctie die connectiviteit tussen werkstations of servers binnen een VLAN beperkt. Zonder PVLAN's kunnen alle apparaten op een Layer 2 VLAN naar wens communiceren. Er bestaan netwerksituaties waarin beveiliging kan worden ondersteund door de communicatie tussen apparaten op één VLAN te beperken. Zo worden VLAN’s vaak gebruikt om communicatie tussen servers in een openbaar toegankelijke subnetverbinding te verbieden. Mocht één server gecompromitteerd raken, dan kan het gebrek aan verbinding met andere servers door de toepassing van PVLAN’s ertoe bijdragen dat het compromis beperkt blijft tot één server.
Er zijn drie typen Prive-VLAN's: geïsoleerde VLAN's, community-VLAN's en primaire VLAN's. De configuratie van PVLAN's maakt gebruik van primaire en secundaire VLAN's. De primaire VLAN bevat alle promiscuous-poorten, die later worden beschreven, en omvat een of meer secundaire VLAN's die ofwel community- ofwel geïsoleerde VLAN's zijn.
De configuratie van een secundair VLAN als geïsoleerd VLAN voorkomt volledig communicatie tussen apparaten in het secundaire VLAN. Mogelijk is er slechts één geïsoleerd VLAN per primair VLAN en kunnen alleen losse poorten communiceren met poorten in een geïsoleerd VLAN. Geïsoleerde VLAN’s moeten worden gebruikt op onbetrouwbare netwerken zoals netwerken die gasten ondersteunen.
Dit configuratievoorbeeld configureert VLAN 11 als een geïsoleerde VLAN en koppelt deze aan de primaire VLAN, VLAN 20. In het onderstaande voorbeeld wordt ook de interface Fast Ethernet 1/1 als een geïsoleerde poort in VLAN 11 geconfigureerd:
!
vlan 11
private-vlan isolated
!
vlan 20
private-vlan primary
private-vlan association 11
!
interface FastEthernet 1/1
description *** Port in Isolated VLAN ***
switchport mode private-vlan host
switchport private-vlan host-association 20 11
!
Een secundair VLAN dat als gemeenschap VLAN wordt gevormd staat communicatie onder leden van VLAN evenals met om het even welke promiscuous havens in primair VLAN toe. Er is echter geen communicatie mogelijk tussen twee community-VLAN's of van een community-VLAN naar een geïsoleerde VLAN. Community VLAN’s moeten worden gebruikt om servers te groeperen die onderlinge connectiviteit nodig hebben, maar waarbij verbinding met alle andere apparaten in het VLAN niet nodig is. Dit scenario is gemeenschappelijk in een openbaar toegankelijk netwerk of overal dat de servers inhoud aan onbetrouwbare cliënten verstrekken.
Dit voorbeeld configureert een enkele community-VLAN en configureert switch-poort FastEthernet 1/2 als een lid van die VLAN. De community-VLAN, VLAN 12, is een secundaire VLAN voor primaire VLAN 20.
!
vlan 12
private-vlan community
!
vlan 20
private-vlan primary
private-vlan association 12
!
interface FastEthernet 1/2
description *** Port in Community VLAN ***
switchport mode private-vlan host
switchport private-vlan host-association 20 12
!
Switch-poorten die in het primaire VLAN zijn geplaatst, staan bekend als promiscuous ports. Beloftevolle poorten kunnen communiceren met alle andere poorten in de primaire en secundaire VLAN’s. Router- of firewall-interfaces zijn de meest gebruikte apparaten op deze VLAN's.
Het configuratievoorbeeld combineert de vorige voorbeelden van community- en geïsoleerde VLAN's en voegt de configuratie van interface FastEthernet 1/12 toe als een promiscuous-poort:
!
vlan 11
private-vlan isolated
!
vlan 12
private-vlan community
!
vlan 20
private-vlan primary
private-vlan association 11-12
!
interface FastEthernet 1/1
description *** Port in Isolated VLAN ***
switchport mode private-vlan host
switchport private-vlan host-association 20 11
!
interface FastEthernet 1/2
description *** Port in Community VLAN ***
switchport mode private-vlan host
switchport private-vlan host-association 20 12
!
interface FastEthernet 1/12
description *** Promiscuous Port ***
switchport mode private-vlan promiscuous
switchport private-vlan mapping 20 add 11-12
!
Wanneer u PVLAN’s implementeert, is het belangrijk om ervoor te zorgen dat Layer 3-configuratie op zijn plaats de beperkingen ondersteunt die worden opgelegd door PVLAN’s en niet toestaat dat de PVLAN-configuratie wordt omgekeerd. Layer 3-filtering met een routerACL of firewall kan de subversie van de VLAN-configuratie voorkomen.
Raadpleeg Privé-VLAN's (PVLAN's) - Promiscuous, geïsoleerd, community, te vinden op de startpagina LAN-beveiliging, voor meer informatie over het gebruik en de configuratie van Privé-VLAN's.
Dit document geeft u een breed overzicht van de methoden die kunnen worden gebruikt om een Cisco IOS-systeemapparaat te beveiligen. Als u de apparaten beveiligen, verhoogt het de algemene veiligheid van de netwerken die u beheert. In dit overzicht worden bescherming van de beheer-, besturing- en dataplanes besproken en worden aanbevelingen verstrekt voor configuratie. Waar mogelijk wordt voldoende detail geboden voor de configuratie van elke gekoppelde functie. In alle gevallen worden echter uitgebreide referenties geboden zodat u beschikt over de benodigde informatie voor verdere evaluatie.
Sommige functiebeschrijvingen in dit document zijn geschreven door informatie-ontwikkelingsteams van Cisco.
Deze controlelijst is een verzameling van alle verhardende stappen die in deze handleiding worden weergegeven. Beheerders kunnen deze lijst gebruiken als herinnering van alle versterkingsfuncties die worden gebruikt en overwogen voor een Cisco IOS-apparaat, zelfs als een functie niet is geïmplementeerd omdat deze niet van toepassing is. Beheerders worden geadviseerd om elke optie te evalueren op potentiële risico's voordat ze de optie implementeren.