Sichern von IOS-Geräten

Einleitung

In diesem Dokument wird beschrieben, wie Sie Ihre Cisco IOS^®-Systemgeräte schützen und die allgemeine Sicherheit Ihres Netzwerks erhöhen können.

Voraussetzungen

Anforderungen

Es gibt keine spezifischen Anforderungen für dieses Dokument.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Hintergrund

Indem Sie Ihre Cisco IOS-Systemgeräte sichern, erhöhen Sie die Sicherheit Ihres Netzwerks insgesamt.

Die Sicherheit Ihres Netzwerks ist im Allgemeinen in drei Ebenen strukturiert, auf denen die Funktionen eines Netzwerkgeräts kategorisiert werden können.  Die drei Funktionsebenen eines Netzwerks teilen sich in Management-, Kontroll- und Datenebene. Je nach Ebene müssen unterschiedliche Funktionalitäten geschützt werden. Dieses Dokument bietet einen Überblick über die Funktionen, die diese jeweils beinhalten, und Verweise auf zugehörige Dokumentation.

• Managementebene: Auf der Managementebene wird der an das Cisco IOS-Gerät gesendete Datenverkehr gemanagt. Sie setzt sich aus Anwendungen und Protokollen wie SSH (Secure Shell) und SNMP (Simple Network Management Protocol) zusammen.
  
  
• Steuerfläche - Die Steuerfläche eines Netzgerätes verarbeitet den Verkehr, der entscheidend ist, die Funktionalität der Netzwerk-Infrastruktur beizubehalten. Die Kontrollebene umfasst Anwendungen und Protokolle zwischen Netzwerkgeräten, z. B. BGP (Border Gateway Protocol) und IGPs (Interior Gateway Protocols). Außerdem gehören dazu EIGRP (Enhanced Interior Gateway Routing Protocol) und OSPF (Open Shortest Path First).
  
  
• Daten-Fläche - Die Daten der Datenfläche vorwärts durch ein Netzgerät. Zur Datenebene zählt kein Datenverkehr, der an das lokale Cisco IOS-Gerät gesendet wird.

Die in diesem Dokument beschriebenen Sicherheitsfunktionen sind häufig detailliert genug, um die jeweilige Funktion zu konfigurieren. Wo keine Detailinformationen verfügbar sind, wird die Funktion so erläutert, dass Sie beurteilen können, ob Sie ihr zusätzliche Aufmerksamkeit widmen sollten. Wo immer möglich und angemessen, enthält dieses Dokument Empfehlungen, deren Umsetzung zum Schutz des Netzwerks beiträgt.

Sichern Sie Operationen

Sichere Netzoperationen ist ein erhebliches Thema. Obgleich die meisten dieses Dokuments der sicheren Konfiguration eines Cisco IOS-Gerätes gewidmet wird, sichern Konfigurationen allein nicht vollständig ein Netz. Die Arbeitsabläufe, die im Netz gebräuchlich sind, tragen so viel zur Sicherheit wie die Konfiguration der zugrunde liegenden Geräte bei.

Diese Themen enthalten Betriebsempfehlungen, denen Ihnen geraten werden einzuführen. Diese Themen markieren kritische Bereiche des Besonderen von Netzoperationen und sind nicht umfassend.

Überwachen Sie Cisco-Sicherheits-Advisories und Antworten

Das Cisco-Produkt-Sicherheits-Vorfall-Warteteam (PSIRT) erstellt und behält die Veröffentlichungen bei, geläufig gekennzeichnet als PSIRT-Advisories, für sicherheitsbezogene Fragen in Cisco-Produkten. Die Methode, die für Kommunikation von weniger schweren Fragen angewendet wird, ist die Cisco-Sicherheits-Antwort. Näheres zu Sicherheitshinweisen und -reaktionen finden Sie in den Cisco Sicherheitshinweisen.

Zusätzliche Information über diese Kommunikationsfahrzeuge ist in der Cisco-Sicherheitslücke-Politik verfügbar.

Um die Sicherheit Ihres Netzwerks zu wahren, müssen Sie die von Cisco veröffentlichten Sicherheitshinweise und -reaktionen kennen. Sie müssen Wissen einer Verwundbarkeit haben, bevor die Drohung, die sie zu einem Netz aufwerfen kann, ausgewertet werden kann. Hinweise zu diesem Bewertungsprozess finden Sie auf der Webseite zur Risikoselektierung bei Bekanntgabe von Sicherheitslücken.

Setzen Sie Authentisierung, Ermächtigung und Buchhaltung wirksam ein

Der Authentisierungs-, Ermächtigungs- und Buchhaltungs(AAA) Rahmen ist wesentlich, Netzgeräte zu sichern. Der aaa-Rahmen liefert Authentisierung von Managementsitzungen und kann Benutzer auf die spezifischen, Verwalter-definierten Befehle auch begrenzen und alle Befehle protokollieren, die von allen Benutzern eingegeben werden. Sehen Sie das Authentisierungs-, Ermächtigungs- und Buchhaltungskapitel dieses Dokuments zu mehr Information über, wie man AAA wirksam einsetzt.

Zentralisierung der Protokollerfassung und des Überwachungsprozesses

Um Informationen über bestehende, neue und bisherige Ereignisse im Zusammenhang mit Sicherheitsvorfällen zu erhalten, benötigt Ihr Unternehmen eine einheitliche Strategie zur Protokollierung und Korrelation von Ereignissen. Diese Strategie muss die Erfassung der Protokolle sämtlicher Netzwerkgeräte und vorkonfigurierte, anpassbare Korrelationsfunktionen beinhalten.

Nach der Implementierung der zentralen Protokollierung müssen Sie einen strukturierten Ansatz für Protokollanalysen und die Nachverfolgung von Vorfällen entwickeln. Basiert auf dem Bedarf Ihrer Organisation, kann diese Annäherung von einer einfachen sorgfältigen Zusammenfassung von Journaldaten bis zu hoch entwickelter Regel-basierter Analyse reichen.

Weitere Informationen zur Implementierung der Protokollierung auf Cisco IOS-Netzwerkgeräten finden Sie in diesem Dokument im Abschnitt Best Practices für die Protokollierung.

Verwenden Sie sichere Protokolle, wenn möglich

Für den Transport vertraulicher Netzwerkmanagementdaten wird eine Vielzahl von Protokollen verwendet. Arbeiten Sie nach Möglichkeit stets mit sicheren Protokollen. Ein sicheres Protokoll ist beispielsweise SSH anstelle von Telnet, damit sowohl Authentifizierungsdaten als auch Managementinformationen verschlüsselt werden. Arbeiten Sie außerdem mit sicheren Protokollen zur Dateiübertragung, wenn Sie Konfigurationsdaten kopieren. Ein Beispiel ist der Gebrauch von dem sicheren Kopien-Protokoll (SCP) anstelle ftp oder TFTPS. 

Sehen Sie das sichere interaktive Management-Sitzungskapitel dieses Dokuments zu mehr Information über das sichere Management von Cisco IOS-Geräten.

Gewinnen Sie Verkehrs-Sicht mit NetFlow

Mit NetFlow können Sie die Datenverkehrsströme im Netzwerk überwachen. Ursprünglich war NetFlow für den Export von Informationen zum Datenverkehr in Anwendungen für das Netzwerkmanagement vorgesehen. Das Protokoll kann jedoch auch verwendet werden, um Informationen zu Datenströmen auf einem Router anzuzeigen. Diese Fähigkeit erlaubt Ihnen, zu sehen, welcher Verkehr das Netz in der Istzeit überquert. Unabhängig davon, ob Informationen zu Datenströmen für eine Remote-Erfassung exportiert werden oder nicht, sollten Sie Ihre Netzwerkgeräte in jedem Fall für NetFlow konfigurieren, damit Sie bei Bedarf reaktiv darauf zurückgreifen können.

Weitere Informationen zu dieser Funktion finden Sie im Abschnitt Traffic Identification and Traceback (Identifizierung und Rückverfolgung von Datenverkehr) dieses Dokuments sowie unter Cisco IOS NetFlow.

Hinweis: Nur registrierte Cisco Benutzer haben Zugriff auf interne Tools und Informationen.

Konfigurationsverwaltung

Konfigurationsverwaltung ist ein Prozess, durch den Konfigurationsänderungen vorgeschlagen, wiederholt, genehmigt und eingesetzt werden. Im Kontext einer Cisco IOS-Gerätekonfiguration sind zwei weitere Aspekte des Konfigurationsmanagements wichtig: Archivierung und Sicherheit von Konfigurationen.

Konfigurationsarchive können Sie verwenden, um an Netzwerkgeräten vorgenommene Änderungen zurückzusetzen. Im Sicherheitskontext helfen Konfigurationsarchive zudem bei der Ermittlung, welche sicherheitsbezogenen Änderungen zu welchem Zeitpunkt vorgenommen wurden. Ebenso wie AAA-Protokolldaten können diese Informationen bei der Sicherheitsüberwachung von Netzwerkgeräten hilfreich sein.

Die Konfiguration eines Cisco IOS-Gerätes enthält viele empfindlichen Details. Benutzernamen, Kennwörter und der Inhalt von Zugriffskontrolllisten sind Beispiele für diese sensiblen Informationen. Das zur Archivierung von Cisco IOS-Gerätekonfigurationen verwendete Repository muss daher geschützt werden. Unsicherer Zugriff zu diesen Informationen kann die Sicherheit des gesamten Netzes untergraben.

Management-Fläche

Die Managementfläche besteht aus Funktionen, die die Managementziele des Netzes erzielen. Dieses schließt interaktive Managementsitzungen, die SSH verwenden, sowie mit SNMP oder NetFlow Statistik-erfassen ein. Für die Sicherheit eines Netzwerkgeräts ist es unabdingbar, die Managementebene zu schützen. Wenn bei einem Sicherheitsvorfall die Funktionen der Managementebene ausgehebelt werden, ist es für Sie unter Umständen unmöglich, das Netzwerk wiederherzustellen oder zu stabilisieren.

Diese Kapitel dieses Dokuments führen die Sicherheitsmerkmale und die Konfigurationen einzeln auf, die in Cisco IOS-Software verfügbar sind, die helfen, die Managementfläche zu verstärken.

Geschäftsleitungs-Flächen-Verhärtung

Die Managementebene wird verwendet, um auf ein Gerät zuzugreifen, es zu konfigurieren und zu managen sowie seinen Betrieb und das Netzwerk, in dem es bereitgestellt wird, zu überwachen. Die Managementebene empfängt und sendet den Datenverkehr für den Betrieb dieser Funktionen. Zusätzlich zur Managementebene müssen Sie auch die Kontrollebene eines Geräts schützen, da sich die Abläufe auf der Kontrollebene direkt auf den Betrieb der Managementebene auswirken. Die von der Managementebene verwendeten Protokolle umfassen:

• Simple Network Management Protocol
• Telnet
• Sichern Sie Shell Protocol
• File Transfer Protocol
• Hypertext-Übergangsprotokoll/sicheres Hypertext-Übergangsprotokoll

• Triviales File Transfer Protocol
• Sichern Sie Kopien-Protokoll
• TACACS+
• RADIUS
• NetFlow
• Network Time Protocol
• Syslog

Schritte müssen unternommen werden, um das Überleben des Managements sicherzustellen und Flächen während der Sicherheitsvorfälle zu steuern. Erfolgreiche Exploits dieser Ebenen haben zur Folge, dass alle Ebenen kompromittiert werden können.

Passwortverwaltung

Passwortsteuerzugriff zu den Betriebsmitteln oder zu den Geräten. Möglich wird dies über das Kennwort, das zur Authentifizierung von Anfragen verwendet wird. Wenn eine Anfrage für Zugriff auf eine Ressource oder ein Gerät eingeht, wird sie auf das Kennwort und die Identität hin überprüft. Der Zugriff kann dann basierend auf dem Ergebnis gewährt, verweigert oder eingeschränkt werden. Als Sicherheitsoptimales verfahren müssen Passwörter mit Server einer TACACS+- oder RADIUS-gehandhabt werden Authentisierung. Bei einem Ausfall der TACACS+- oder RADIUS-Services wird jedoch weiterhin ein lokal konfiguriertes Kennwort für den privilegierten Zugriff benötigt. Ein Gerät kann andere Passwortinformationen auch haben, die innerhalb seiner Konfiguration, wie eine NTP-Tasten-, SNMP-Gemeinschaftszeichenkette oder Wegewahl-Protokolltaste vorhanden sind.

Mit dem enable secret Befehl wird das Kennwort festgelegt, das dem Cisco IOS-System privilegierten Administratorzugriff gewährt. Derenable secretBefehl muss verwendet werden, nicht der ältereenable passwordBefehl. Die Fehlermeldung enable passwordverwendet einen schwachen Verschlüsselungsalgorithmus.

Wenn "no" enable secret gesetzt und ein Kennwort für die Konsole tty-Zeile konfiguriert ist, kann das Konsolenkennwort verwendet werden, um privilegierten Zugriff zu erhalten, selbst von einer virtuellen Remotetty (vty)-Sitzung. Diese Aktion ist fast zweifellos unerwünscht und ist ein anderer Grund, Konfiguration eines Aktivierungsgeheimnisses sicherzustellen.

Der service password-encryption globale Konfigurationsbefehl weist die Cisco IOS-Software an, Kennwörter, CHAP-Schlüssel (Challenge Handshake Authentication Protocol) und ähnliche Daten, die in der Konfigurationsdatei gespeichert werden, zu verschlüsseln. Anhand einer solchen Verschlüsselung lässt sich verhindern, dass zufällige Beobachter Kennwörter vom Bildschirm ablesen, beispielsweise wenn sie einem Admin über die Schulter blicken. Der vom Befehl verwendete Algorithmus service password-encryption ist jedoch eine einfache Vigen re-Verschlüsselung. Der Algorithmus wird, um konzipiert Konfigurationsdateien gegen ernste Analyse zu schützen nicht von sogar etwas hoch entwickelten Angreifern und darf nicht zu diesem Zweck verwendet werden. Jede mögliche Cisco IOS-Konfigurationsdatei, die verschlüsselte Passwörter enthält, muss mit der gleichen Sorgfalt behandelt werden, die für eine Klartextliste jener gleichen Passwörter verwendet wird.

Dieser schwache Verschlüsselungsalgorithmus wird vom enable secret Befehl zwar nicht verwendet, jedoch vom Befehl für die enable password globale Konfiguration und vom Befehl für die password Leitungskonfiguration. Diese Art von Kennwörtern muss entfernt werden, und der enable secret Befehl oder die erweiterte Kennwortsicherheit muss verwendet werden.

Derenable secretBefehl und die Funktion für die erweiterte Kennwortsicherheit verwenden Message Digest 5 (MD5) für das Hashing von Kennwörtern. Dieser Algorithmus hat beträchtliche allgemeine Zusammenfassung gehabt und nicht bekannt, um umschaltbar zu sein. Jedoch ist der Algorithmus abhängig von Wörterbuchangriffen. Bei einem Wörterbuch-Angriff testet ein Angreifer jedes Wort aus einem Wörterbuch oder einer anderen Liste möglicher Kennwörter, um eine Übereinstimmung zu finden. Deshalb müssen Konfigurationsdateien mit verlässlichen Einzelpersonen sicher gespeichert werden und nur geteilt werden.

Erhöhte Passwort-Sicherheit

Die in Version 12.2(8)T der Cisco IOS-Software eingeführte Funktion "Enhanced Password Security" (Erweiterte Kennwortsicherheit) ermöglicht es einem Administrator, für denusernameBefehl MD5-Hashing von Kennwörtern zu konfigurieren. Vor Einführung dieser Funktion gab es zwei Arten von Kennwörtern: Typ 0, d. h. Klartextkennwörter, und Typ 7 mit dem Algorithmus aus der Vigenère-Chiffre. Das erhöhte Passwort-Sicherheitsmerkmal kann nicht mit Protokollen, die das Klartextpasswort, benötigen wieder gutzumachend zu sein, wie TYPEN benutzt werden.

Um ein Benutzerkennwort mit MD5-Hashing zu verschlüsseln, geben Sie den username secret globalen Konfigurationsbefehl ein.

!

username <name> secret <password>

!

LOGON-Passwort-Wiederholungs-Aussperrung

Das LOGON-Passwort-Wiederholungs-Ausrück-Merkmal, hinzugefügt im Cisco IOS-Software-Release 12.3(14)T, erlaubt Ihnen, ein lokales Benutzerkonto heraus zu sperren, nachdem eine konfigurierte Zahl des erfolglosen LOGON versucht. Sobald ein Benutzer heraus gesperrt wird, ist ihr Konto verschlossen, bis Sie es freisetzen. Autorisierte BenutzerInnen, die mit der Berechtigungsstufe 15 konfiguriert sind, können mit dieser Funktion nicht gesperrt werden. Beschränken Sie die Anzahl der BenutzerInnen mit Berechtigungsstufe 15 auf ein Mindestmaß.

Beachten Sie, dass berechtigte Benutzer aus einem Gerät heraus sich sperren können, wenn die Anzahl von erfolglosen LOGON-Versuchen erreicht wird. Zusätzlich kann ein böswilliger Benutzer eine Leistungsverweigerung (DOS) Zustand mit wiederholten Versuchen erstellen, mit einem gültigen username zu beglaubigen.

Dieses Beispiel zeigt, wie man das LOGON-Passwort-Wiederholungs-Ausrück-Merkmal aktiviert:

!

aaa new-model
aaa local authentication attempts max-fail <max-attempts>
aaa authentication login default local

!

username <name> secret <password>

!

Diese Funktion gilt auch für Authentifizierungsmethoden wie CHAP und PAP (Password Authentication Protocol).

Kein Service-Passwort-Wiederanlauf

Im Cisco IOS-Software-Release 12.3(14)T und später, lässt das kein Service-Passwort-Wiederanlaufmerkmal niemand mit Konsolenzugriff auf die Geräteausstattung unsicher zugreifen und das Passwort löschen. Es auch erlaubt nicht böswilligen Benutzern, den Konfigurationsregisterwert zu ändern und auf NVRAM zuzugreifen.

!

no service password-recovery

!

Die Cisco IOS-Software bietet ein Verfahren zur Kennwortwiederherstellung, für das ein Zugriff auf den ROM-Überwachungsmodus (ROM Monitor Mode, ROMMON) mithilfe der Unterbrechungstaste während des Systemstarts erforderlich ist. Im ROMMON kann die Gerätesoftware neu geladen werden, damit eine neue Systemkonfiguration angefordert wird, die ein neues Kennwort beinhaltet.

Die aktuelle PasswortWiederherstellungsprozedur aktiviert jedermann mit Konsolenzugriff, das Gerät und auf sein Netz zuzugreifen. Das kein Service-Passwort-Wiederanlaufmerkmal verhindert die Fertigstellung der Unterbrechungstastereihenfolge und das Hereinkommen von ROMMON während des Einschaltens der Anlage.

Wenn auf einem Gerät aktiviert no service password-recovery ist, wird empfohlen, eine Offline-Kopie der Gerätekonfiguration zu speichern und eine Konfigurationsarchivierungslösung zu implementieren. Wenn es notwendig ist, das Passwort eines Cisco IOS-Gerätes einmal wieder herzustellen, wird dieses Merkmal, die gesamte Konfiguration wird gelöscht aktiviert.

Sprechen Sie sicheres ROMMON-Konfigurations-Beispiel zu mehr Information über dieses Merkmal an.

Sperrungs-unbenutzte Dienstleistungen

Als Best Practice für die Sicherheit gilt, alle nicht benötigten Services zu deaktivieren. Nicht benötigte Services, insbesondere solche, die UDP (User Datagram Protocol) verwenden, werden selten für legitime Zwecke verwendet, können aber eingesetzt werden, um DoS- und andere Angriffe zu starten, die sonst durch die Paketfilterung verhindert werden.

Deaktivieren Sie die „kleinen“ TCP- und UDP-Services (Small Service). Diese Dienstleistungen umfassen:

• Echo (Anschlussnummer 7)
  
  
• verwerfen Sie (Anschlussnummer 9)
  
  
• Tageszeit (Anschlussnummer 13)
  
  
• chargen (Anschlussnummer 19)

Ein Missbrauch der kleinen Services durch Anti-Spoofing-Zugriffslisten kann zwar vermieden oder entschärft werden. Dennoch sollten Sie die Services auf jedem Gerät deaktivieren, auf das im Netzwerk zugegriffen werden kann. Die kleinen Services sind in Cisco IOS-Software ab Version 12.0 standardmäßig deaktiviert. In früheren Softwareversionen können die Befehle no service tcp-small-servers und no service udp-small-servers global ausgegeben werden, um sie zu deaktivieren.

Zu den weiteren Services, die bei Nichtverwendung deaktiviert werden müssen, gehören:

• Geben Sie den Befehl für dieno ip fingerglobale Konfiguration ein, um den Fingerdienst zu deaktivieren. In Cisco IOS-Software nach Version 12.1(5) und 12.1(5)T ist dieser Service standardmäßig deaktiviert.
• Geben Sie den Befehl für dieno ip bootp serverglobale Konfiguration ein, um das Bootstrap-Protokoll (BOOTP) zu deaktivieren.
• In Cisco IOS-Software ab Version 12.2(8)T müssen Sie im globalen Konfigurationsmodus den Befehl ip dhcp bootp ignore ausführen, um BOOTP zu deaktivieren. Dieses lässt Dienstleistungen des dynamischer Hauptrechner-Konfigurations-Protokolls (DHCP) aktiviert.
• DHCP-Dienstleistungen können behindert sein, wenn DHCP-Relaisdienstleistungen nicht benötigt werden. Geben Sie den keinen Service-DHCP-Befehl im globalen Konfigurationsmodus heraus.
• Führen Sie im Modus zur Schnittstellenkonfiguration den Befehl no mop enabled aus, um den MOP-Service (Maintenance Operation Protocol) zu deaktivieren.
• Führen Sie den globalen Konfigurationsbefehl no ip domain-lookup aus, um Services zur DNS-Auflösung (Domain Name System) zu deaktivieren.
• Führen Sie im globalen Konfigurationsmodus den Befehl no service pad aus, um den PAD-Service (Packet Assembler/Disassembler) zu deaktivieren, der für X.25-Netzwerke verwendet wird.
  Der HTTP-Server kann mit dem keinem IPhttp-Serverbefehl im globalen Konfigurationsmodus deaktiviert werden, und sicherer Server HTTP (HTTPS) kann mit dem keinem globalen Konfigurationsbefehl IPhttp-sicher-Servers deaktiviert werden.
  Es sei denn, dass Cisco IOS-Geräte Konfigurationen vom Netz während des Starts zurückholen, muss der kein globale Konfigurationsbefehl Service Config verwendet werden. Dieses verhindert das Cisco IOS-Gerät an einem Versuch, eine Konfigurationsdatei auf dem Netz mit TFTP zu lokalisieren.
  CDP (Cisco Discovery Protocol) ist ein Netzwerkprotokoll, das zur Erkennung anderer CDP-fähiger Geräte im Hinblick auf Adjacency mit Nachbarn und Netzwerktopologie verwendet wird. CDP kann von NMS (Network Management Systems) oder bei der Fehlerisolierung verwendet werden. CDP muss für alle Schnittstellen deaktiviert werden, die mit nicht vertrauenswürdigen Netzwerken oder Hosts verbunden sind. Dieses wird mit dem keinem Verdichteraustrittsdruck aktivieren Schnittstellenbefehl vollendet. Wechselweise kann Verdichteraustrittsdruck mit dem keinem Verdichteraustrittsdruck ausgeführten globalen Konfigurationsbefehl global deaktiviert werden. Beachten Sie, dass CDP von böswilligen BenutzerInnen für Ausspähaktivitäten und zur Zuordnung von Netzwerken verwendet werden kann.
• LLDP (Link Layer Discovery Protocol) ist ein in 802.1AB definiertes IEEE-Protokoll, ähnlich dem CDP. Jedoch erlaubt dieses Protokoll Interoperabilität zwischen anderen Geräten, die nicht Verdichteraustrittsdruck unterstützen. LLDP muss auf die gleiche Weise wie Verdichteraustrittsdruck behandelt werden und auf allen Schnittstellen deaktiviert werden, die an untrusted Netze anschließen. Um dies zu erreichen, führen Sie zur Schnittstellenkonfiguration die Befehle no lldp transmit und no lldp receive aus. Führen Sie den globalen Konfigurationsbefehl no lldp run aus, um LLDP global zu deaktivieren. Auch LLDP kann von böswilligen BenutzerInnen für Ausspähaktivitäten und die Abbildung von Netzwerken verwendet werden.

• Für Switches, die das Booten von sdflash unterstützen, kann die Sicherheit durch das Booten von Flash und das Deaktivieren von sdflash mit dem Konfigurationsbefehl „no sdflash“ verbessert werden.

LEITPROGRAMM Unterbrechung

Um festzulegen, wie lange der EXEC-Befehlsinterpreter auf eine Benutzereingabe warten soll, bevor er eine Sitzung beendet, führen Sie den Konfigurationsbefehl exec-timeout aus. Verwenden Sie zum Abmelden von Sitzungen bei inaktiv gelassenen VTY- oder TTY-Verbindungen den Befehl exec-timeout. Standardmäßig sind Sitzungen nach zehn Minuten Untätigkeit getrennt.

!

line con 0
 exec-timeout <minutes> [seconds]
line vty 0 4
 exec-timeout <minutes> [seconds]
!

Keepalives für TCP-Sitzungen

Der Service TCP-keepalives-in und globalen die Konfigurationsbefehle Service TCPKeepalives-heraus aktivieren ein Gerät, TCP-Keepalives für TCP-Sitzungen zu senden. Verwenden Sie diese Konfiguration, um TCP-Keepalives bei eingehenden Verbindungen zum Gerät und ausgehenden Verbindungen vom Gerät zu aktivieren. Dadurch wird sichergestellt, dass das Gerät am Remote-Ende der Verbindung weiterhin verfügbar bleibt und dass halb offene oder verwaiste Verbindungen vom lokalen Cisco IOS-Gerät entfernt werden.

!

service tcp-keepalives-in
service tcp-keepalives-out
!

Management-Schnittstellen-Gebrauch

Die Managementfläche eines Gerätes ist auf einer körperlichen oder logischen Managementschnittstelle erreichtes Inband- oder nicht auf Band aufgenommen. Im Idealfall ist sowohl In-Band- als auch Out-of-Band-Managementzugriff für jedes Netzwerkgerät gegeben, sodass bei Netzwerkausfällen dennoch auf die Managementebene zugegriffen werden kann.

Eine der gängigsten Schnittstellen, die für den In-Band-Zugriff auf ein Gerät verwendet wird, ist die logische Loopback-Schnittstelle. Schleifenbetriebschnittstellen sind immer oben, während körperliche Schnittstellen Zustand ändern können und die Schnittstelle nicht zugänglich möglicherweise sein kann. Es wird empfohlen, jedem Gerät eine Loopback-Schnittstelle als Managementschnittstelle hinzuzufügen und diese ausschließlich für die Managementebene zu verwenden. Dieses erlaubt dem Verwalter, Politik während des Netzes für die Managementfläche anzuwenden. Sobald die Loopback-Schnittstelle auf einem Gerät konfiguriert ist, kann sie von Protokollen der Managementebene wie SSH, SNMP und syslog verwendet werden, um Datenverkehr zu senden und zu empfangen.

!
interface Loopback0
 ip address 192.168.1.1 255.255.255.0
!

Speicher-Schwellwert-Mitteilungen

Mit der in Cisco IOS-Software 12.3(4)T eingeführten Funktion für Benachrichtigungen zum Arbeitsspeicherschwellenwert können Sie verhindern, dass der Arbeitsspeicher auf einem Gerät unbemerkt knapp wird. Hierzu bringt diese Funktion zwei Methoden zur Anwendung: Benachrichtigung zu Arbeitsspeicher-Schwellenwerten und Reservierung von Arbeitsspeicher.

Die Funktion für Benachrichtigungen zu Arbeitsspeicher-Schwellenwerten generiert eine Protokollmeldung, um darauf hinzuweisen, dass der freie Arbeitsspeicher auf einem Gerät den konfigurierten Grenzwert unterschritten hat. Dieses Konfigurationsbeispiel zeigt, wie man dieses Merkmal mit dem Konfigurationsbefehl NiedrigWaterMarks des Speichers freien globalen aktiviert. Dieses aktiviert ein Gerät, eine Mitteilung festzulegen, wenn verfügbarer freier Speicher niedriger als der spezifizierte Schwellwert fällt, und wieder, wenn verfügbarer freier Speicher auf fünf Prozent höher als der spezifizierte Schwellwert steigt.

!

memory free low-watermark processor <threshold>
memory free low-watermark io <threshold>
!

Die Reservierung von Arbeitsspeicher wird verwendet, um ausreichend Arbeitsspeicher für kritische Benachrichtigungen vorzuhalten. In diesem Konfigurationsbeispiel wird gezeigt, wie sich mit dieser Funktion gewährleisten lässt, dass Managementprozesse weiterhin funktionieren, wenn der Arbeitsspeicher des Geräts erschöpft ist.

!

memory reserve critical <value>
!

Siehe Speicher-Schwellwert-Mitteilungen zu mehr Information über dieses Merkmal.

CPU-Thresholding-Mitteilung

Mit der in Cisco IOS-Software 12.3(4)T eingeführten Funktion für die Benachrichtigung zum CPU-Schwellenwert können Sie erkennen und sich benachrichtigen lassen, wenn die CPU-Load eines Geräts einen konfigurierten Schwellenwert überschreitet. Wenn der Schwellwert überschritten wird, legt das Gerät fest und sendet eine SNMP-Blockiermeldung. Cisco IOS-Software unterstützt zwei Methoden zur Definition von Schwellenwerten für die CPU-Auslastung: steigender Schwellenwert und fallender Schwellenwert.

Diese Beispielkonfiguration zeigt, wie Sie die steigenden und fallenden Schwellenwerte aktivieren, die eine Benachrichtigung zum CPU-Schwellenwert auslösen:

!

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>]
!

Siehe CPU-Thresholding-Mitteilung zu mehr Information über dieses Merkmal.

Reserve-Speicher für Konsolen-Zugriff

In Cisco IOS-Software ab Version 12.4(15)T können Sie mit der Funktion zum Reservieren von Arbeitsspeicher für Konsolenzugriff genügend Arbeitsspeicher reservieren, um den Konsolenzugriff auf ein Cisco IOS-Gerät für administrative und Fehlerisolierungszwecke zu gewährleisten. Diese Funktion ist besonders nützlich, wenn der Arbeitsspeicher auf dem Gerät knapp wird. Sie können den globalen Konfigurationsbefehl memory reserve console ausführen, um diese Funktion zu aktivieren. Dieses Beispiel konfiguriert ein Cisco IOS-Gerät, um 4096 Kilobytes zu diesem Zweck aufzuheben.

!
memory reserve console 4096
!

Speicher-Leck-Detektor

Eingeführt im Cisco IOS-Software-Release 12.3(8)T1, erlaubt das Speicher-Leck-Detektormerkmal Ihnen, Speicherlecks auf einem Gerät zu entdecken. Anhand der Speicherleckerkennung lassen sich Lecks in sämtlichen Arbeitsspeicherpools, Paketpuffern und Chunks aufspüren. Speicherlecks sind statische oder dynamische Belegungen des Speichers, die keinen nützlichen Zweck dienen. Dieses Merkmal konzentriert sich auf Speicherzuweisungen, die dynamisch sind. Mit dem EXEC-Befehl show memory debug leaks können Sie ermitteln, ob ein Speicherleck vorliegt.

Pufferüberlauf: Erkennung und Korrektur von Beschädigungen in der „roten Zone“

In Cisco IOS-Software ab Version 12.3(7)T kann die Funktion zur Erkennung und Korrektur von infolge eines Pufferüberlaufs entstandenen Beschädigungen in der „roten Zone“ auf einem Gerät aktiviert werden, um einen Speicherblocküberlauf zu erkennen und zu korrigieren und den Betrieb aufrechtzuerhalten.

Die Funktion lässt sich mit globalen Konfigurationsbefehlen aktivieren. Nach der Konfiguration können Sie Statistiken zur Erkennung und Korrektur von Pufferüberläufen mit dem Befehl show memory overflow anzeigen.

!
exception memory ignore overflow io
exception memory ignore overflow processor
!

Erhöhte Crashinfo-Datei-Sammlung

Das erhöhte Crashinfo-Datei-Sammlungsmerkmal löscht automatisch alte crashinfo Dateien. Diese in Cisco IOS-Software 12.3(11)T eingeführte Funktion ermöglicht es Geräten, Platz zurückzugewinnen, damit bei einem Absturz des Geräts neue Crashinfo-Dateien erstellt werden können. Außerdem können Sie mit dieser Funktion konfigurieren, wie viele Crashinfo-Dateien gespeichert werden sollen.

!
exception crashinfo maximum files <number-of-files>
!

Network Time Protocol

NTP (Network Time Protocol) ist zwar kein gefährlicher Service, jedoch kann jeder nicht benötigte Service einen Angriffsvektor darstellen. Wenn NTP benutzt wird, ist es wichtig, eine verlässliche Zeitquelle ausdrücklich zu konfigurieren und richtige Authentisierung zu verwenden. Für Syslog-Zwecke ist eine genaue und zuverlässige Zeitangabe erforderlich, beispielsweise für forensische Untersuchungen potenzieller Angriffe. Diese Anforderung gilt auch für erfolgreiche VPN-Verbindungen, wenn Zertifikate für die Phase-1-Authentifizierung eingesetzt werden.

• NTP-Zeitzone: Wenn Sie NTP konfigurieren, muss die Zeitzone so konfiguriert werden, dass Zeitstempel genau zugeordnet werden können. Es gibt zwei klassische Methoden zur Konfiguration der Zeitzone für Geräte in einem Netzwerk mit globaler Präsenz. Eine Methode ist, alle Netzgeräte mit der koordinierten Weltzeit (UTC) (vorher die Greenwich-Zeit (GMT) zu konfigurieren). Alternativ können die Netzwerkgeräte mit der lokalen Zeitzone konfiguriert werden. Mehr Informationen über dieses Merkmal können in „Uhr Timezone“ in der Cisco-Produktdokumentation gefunden werden.
  
  
• NTP-Authentisierung - Wenn Sie NTP-Authentisierung konfigurieren, liefert sie Versicherung, dass NTP-Meldungen zwischen verlässlichen NTP-Gleichen ausgetauscht werden.

Nachfolgend eine Beispielkonfiguration mit NTP-Authentifizierung:

Kunde:

(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

Sperrung Smart installieren

Die Best Practices für die Sicherheit der Cisco Smart Install-Funktion (SMI) hängen davon ab, wie die Funktion in einer bestimmten Benutzerumgebung verwendet wird. Cisco unterscheidet diese Anwendungsfälle:

• Benutzer, die die SMI-Funktion nicht verwenden.
• Benutzer, die die SMI-Funktion nur für Bereitstellungen ohne Benutzereingriff nutzen.
• Benutzer, die die Smart InstallSMI-Funktion für mehr als Zero-Touch-Bereitstellungen (Konfiguration und Image-Management) nutzen.

Diese Kapitel beschreiben jedes Szenario im Detail:

• Benutzer, die die SMI-Funktion nicht verwenden.
• Benutzer, die die SMI-Funktion nicht verwenden und eine Version der Cisco IOS- und Cisco IOS XE-Software ausführen, auf der der Befehl verfügbar ist, können die SMI-Funktion mit dem Befehl no vstack deaktivieren.

Hinweis: Der Befehl vstack wurde mit Cisco IOS 12.2(55)SE03 eingeführt.

Dies ist eine Beispielausgabe des Befehls show vstack auf einem Cisco Catalyst Switch, bei dem die SMI-Client-Funktion deaktiviert ist:

switch# show vstack 
config Role: Client (SmartInstall disabled) 
Vstack Director IP address: 0.0.0.0

Kunden, die die SMI-Funktion nur für die Zero-Touch-Bereitstellung nutzen

Deaktivieren Sie die SMI-Client-Funktion nach Abschluss der Zero-Touch-Installation, oder verwenden Sie den Befehl no vstack.

Um den Befehl no vstack auf das gesamte Netzwerk zu übertragen, verwenden Sie eine der folgenden Methoden.

• Geben Sie den Befehl no vstack entweder manuell oder mit einem Skript auf allen Client-Switches ein.
• Fügen Sie den Befehl no vstack als Teil der Cisco IOS-Konfiguration hinzu, die im Zuge der Zero-Touch-Installation per Push an alle SMI-Clients gesendet wird.
• Verwenden Sie in Versionen, die den vstack-Befehl nicht unterstützen (Cisco IOS 12.2(55)SE02 und frühere Versionen), eine Zugriffskontrollliste (Access Control List, ACL) auf den Client-Switches, um den Datenverkehr an TCP-Port 4786 zu blockieren.

Wenn Sie die SMI-Client-Funktion zu einem späteren Zeitpunkt aktivieren möchten, geben Sie den vstack-Befehl entweder manuell oder mit einem Skript auf allen Client-Switches ein.

Kunden, die die SMI-Funktion für mehr als nur die Zero-Touch-Bereitstellung nutzen

Achten Sie beim Design einer SMI-Architektur darauf, dass der IP-Adressbereich der Infrastruktur nur für vertrauenswürdige TeilnehmerInnen zugänglich ist. Achten Sie bei Versionen ohne Unterstützung für den vstack-Befehl darauf, dass nur für den SMI-Director TCP-Konnektivität zu allen SMI-Clients an Port 4786 besteht.

Admins können folgende Best Practices für die Sicherheit von SMI-Bereitstellungen auf betroffenen Geräten nutzen:

• Schnittstelle ACLs
• Steuern Sie das Flächen-Polizeilich überwachen (CoPP). Dieses Merkmal ist nicht in allen Cisco IOS-Software-Releases verfügbar.

Das folgende Beispiel zeigt eine Schnittstellen-ACL mit der SMI-Director-IP-Adresse „10.10.10.1“ und der SMI-Client-IP-Adresse „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

Dieser ACL muss auf allen IP-Schnittstellen auf allen Kunden eingesetzt werden. Sie kann auch bei der anfänglichen Switch-Bereitstellung per Push vom Director übertragen werden.

Um den Zugriff auf alle Clients innerhalb der Infrastruktur weiter einzuschränken, können Admins folgende Best Practices für die Sicherheit auf anderen Geräten im Netzwerk umsetzen:

• InfrastrukturZugriffskontrolllisten (iACLs)
• VLAN-Zugriffskontrolllisten (VACLs)

Grenzzugriff zum Netz mit Infrastruktur ACLs

iACLs sollen die nicht autorisierte direkte Kommunikation mit Netzwerkgeräten verhindern und sind damit eine der wichtigsten Sicherheitsmaßnahmen, die in Netzwerken implementiert werden können. Die Grundidee hinter iACLs besteht darin, dass ein Großteil des Datenverkehrs das Netzwerk nicht zum Ziel hat, sondern es nur durchläuft.

Eine iACL wird erstellt und angewendet, um Verbindungen von Hosts oder Netzwerken anzugeben, die für Netzwerkgeräte zugelassen werden müssen. Gängige Beispiele für diese Verbindungstypen sind eBGP, SSH und SNMP. Nachdem die erforderlichen Verbindungen die Erlaubnis gehabt worden sind, weitere wird ganzer Verkehr zur Infrastruktur ausdrücklich verweigert. Aller Durchgangsverkehr, der das Netz kreuzt und nicht zu den Infrastrukturgeräten vorgesehen wird, wird dann ausdrücklich die Erlaubnis gehabt.

Der Schutz, der von den iACLs geboten wird, ist zum Management relevant und steuert Flächen. Die Implementierung von iACLs lässt sich anhand einer eindeutigen Adressierung für Netzwerkinfrastrukturgeräte vereinfachen. Weitere Informationen zu Sicherheitsaspekten bei IP-Adressen finden Sie im Dokument zum sicherheitsorientierten Ansatz bei der IP-Adressierung.

Diese iACL-Beispielkonfiguration veranschaulicht die Struktur, die als Ausgangspunkt verwendet werden muss, wenn Sie mit dem iACL-Implementierungsprozess beginnen:

!

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
!

Sobald erstellt, muss das iACL an allen Schnittstellen angewendet werden, die Nichtinfrastrukturgeräte gegenüberstellen. Dieses schließt Schnittstellen ein, die an andere Organisationen, Fernzugriffsegmente, Benutzersegmente und Segmente in den Rechenzentren anschließen.

Im Dokument zum Thema Schützen des Core mit Zugriffskontrolllisten für den Infrastrukturschutz finden Sie weitere Informationen zu Infrastruktur-ACLs.

ICMP-Paket-Entstörung

Das Internet Control Message Protocol (ICMP) ist als IP-Steuerprotokoll konzipiert. Dementsprechend können die über dieses Protokoll vermittelten Nachrichten im Allgemeinen erhebliche Interaktionen mit den TCP- und IP-Protokollen aufweisen. Während die Netzwerk-Tools ping und traceroute ICMP zur Fehlerbehebung verwenden, werden für den ordnungsgemäßen Betrieb eines Netzwerks nur selten externe ICMP-Verbindungen benötigt.

Cisco IOS-Software liefert Funktionalität, um ICMP-Meldungen speziell namentlich zu filtern oder zu schreiben und zu codieren. Dieses Beispiel ACL, das mit den Zugriffssteuerungseinträgen (Asse) von den vorhergehenden Beispielen verwendet werden muss, erlaubt Klingeln von den Vermögensverwaltungsstationen und VON Nanometer-Servers und blockt alle weiteren ICMP-Pakete:

!

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
!

Filter IP-Fragmente

Der Filterprozess für fragmentierte IP-Pakete kann für Sicherheitsgeräte eine Herausforderung darstellen. Dies ist darauf zurückzuführen, dass die zum Filtern von TCP- und UDP-Paketen verwendeten Layer-4-Informationen nur im anfänglichen Fragment vorhanden sind. Die Cisco IOS-Software verwendet eine bestimmte Methode, um nicht anfängliche Fragmente anhand konfigurierter Zugriffslisten zu überprüfen. Diese nicht anfänglichen Fragmente werden von der Cisco IOS-Software anhand der ACL bewertet. Alle auf Layer 4- gefilterten Informationen werden ignoriert. Dies führt dazu, dass nicht anfängliche Fragmente nur im Hinblick auf den Layer-3-Teil eines konfigurierten ACE bewertet werden. 

Wenn in dieser Beispielkonfiguration ein an 192.168.1.1 und Port 22 gerichtetes TCP-Paket bei der Übertragung fragmentiert ist, wird das anfängliche Fragment ausgehend von den Layer-4-Informationen aus dem Paket gemäß dem zweiten ACE erwartet verworfen. Alle verbleibenden (nicht anfänglichen) Fragmente sind gemäß dem ersten ACE allein auf Basis der Layer-3-Informationen aus dem Paket und dem ACE zulässig. Dieses Szenario wird in dieser Konfiguration gezeigt:

!

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
!

Wegen der nonintuitive Art des Fragments handhabend, werden IP-Fragmente häufig unbeabsichtigt durch ACLs die Erlaubnis gehabt. Fragmentierung wird bei Versuchen zur Umgehung der Erkennung durch Intrusion-Detection-Systeme verwendet. Aus diesen Gründen werden IP-Fragmente häufig in Angriffen verwendet und müssen daher zusätzlich zu den konfigurierten iACLs explizit gefiltert werden. Diese Beispiel-ACL beinhaltet eine umfassende Filterung von IP-Fragmenten. Die Funktionen aus diesem Beispiel müssen in Verbindung mit den Funktionen aus den vorherigen Beispielen verwendet werden.

!

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
!

Siehe Zugriffskontrolllisten und IP-Fragmente zu mehr Information über, wie ACL zersplitterte IP-Pakete handhabt.

ACL-Unterstützung für das Filtern von IP-Optionen

Mit Cisco IOS-Software 12.3(4)T wurde die Unterstützung für die Verwendung von ACLs zum Filtern von IP-Paketen basierend auf den im Paket enthaltenen IP-Optionen eingeführt. IP-Optionen stellen eine Sicherheitsherausforderung für Netzgeräte dar, weil diese Optionen als Ausnahmepakete verarbeitet werden müssen. Dies erfordert einen CPU-Aufwand, der für typische Pakete, die das Netzwerk durchlaufen, nicht erforderlich ist. Das Vorhandensein von IP-Optionen in einem Paket kann auch auf den Versuch hindeuten, Sicherheitskontrollen im Netzwerk zu untergraben oder die Transit-Eigenschaften eines Pakets anderweitig zu ändern. Deshalb müssen Pakete mit IP-Optionen am Netzwerk-Edge gefiltert werden.

Dieses Beispiel muss zusammen mit den ACEs aus den vorherigen Beispielen verwendet werden, um eine vollständige Filterung von IP-Paketen mit enthaltenen IP-Optionen zu erreichen:

!

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
!

Acl-Support, zum auf TTL-Wert zu filtern

Mit Cisco IOS-Software 12.4(2)T wurde die ACL-Unterstützung zum Filtern von IP-Paketen anhand des TTL-Werts (Time to Live, Gültigkeitsdauer) hinzugefügt. Der TTL-Wert eines IP datagram wird durch jedes Netzgerät verringert, während ein Paket von Quelle zu Zieleinheit fließt. Die anfänglichen Werte variieren je nach Betriebssystem. In jedem Fall muss das Paket jedoch verworfen werden, wenn die TTL eines Pakets den Wert 0 erreicht. Das Gerät, das den TTL-Wert auf Null verringert und daher das Paket verwirft, ist erforderlich, damit eine Nachricht zur ICMP-Zeitüberschreitung generiert und an die Quelle des Pakets gesendet wird.

Die Generation und die Übertragung dieser Meldungen ist ein Ausnahmeprozeß. Router können diese Funktion übernehmen, wenn die Anzahl der IP-Pakete, die ablaufen, gering ist. Ist die Anzahl der in Kürze ablaufenden Pakete dagegen hoch, kann die Generierung und Übertragung dieser Nachrichten alle verfügbaren CPU-Ressourcen verbrauchen. Dieses stellt einen DOS-Angriffsvektor dar. Deshalb müssen Geräte vor DoS-Angriffen geschützt werden, bei denen eine hohe Anzahl von in Kürze ablaufenden IP-Paketen eingesetzt wird.

Es wird empfohlen, dass Organisationen IP-Pakete mit niedrigen TTL-Werten am Rand des Netzes filtern. Das vollständige Filtern von Paketen mit TTL-Werten, die zum Durchqueren des Netzwerks nicht ausreichen, verringert das Risiko TTL-basierter Angriffe.

Dieses Beispiel ACL filtert Pakete mit TTL-Werten weniger als sechs. Dieses bietet Schutz gegen TTL-Endangriffe für Netze bis zu fünf einsteigt Breite.

!

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
!

Hinweis: Bei einigen Protokollen werden Pakete mit niedrigen TTL-Werten zu legitimen Zwecken genutzt. eBGP ist ein solches Protokoll. Weitere Informationen zum Mindern des Risikos von auf TTL-Ablauf basierenden Angriffen finden Sie im Dokument zum Thema Erkennung und Verhinderung von TTL-Ablauf-Angriffen.

Sichern Sie interaktive Management-Sitzungen

Mit Managementsitzungen auf Geräten können Sie Informationen über ein Gerät und dessen Betrieb anzeigen und erfassen. Wenn diese Informationen in die Hände böswilliger BenutzerInnen gelangen, kann das Gerät zum Ziel eines Angriffs werden, wodurch es kompromittiert und dann zum Durchführen weiterer Angriffe verwendet werden kann. Jedermann mit privilegiertem Zugriff zu einem Gerät hat die Fähigkeit für volle Verwaltungskontrolle dieses Gerätes. Es ist unerlässlich, Managementsitzungen zu schützen, um die Offenlegung von Informationen und den nicht autorisierten Zugriff zu verhindern.

Management-flacher Schutz

In Cisco IOS Software, Version 12.4(6)T und höher, ermöglicht die Funktion zum Schutz der Verwaltungsebene (MPP) einem Administrator, Einschränkungen für den Verwaltungsverkehr der verschiedenen Schnittstellen festzulegen, der von einem Gerät empfangen wird. Dieses erlaubt die Verwalterzusätzliche kontrolle über einem Gerät und wie das Gerät erreicht wird.

Das folgende Beispiel zeigt, wie Sie MPP aktivieren, um nur SSH und HTTPS an der Schnittstelle „GigabitEthernet0/1“ zuzulassen:

!

control-plane host
  management-interface GigabitEthernet 0/1 allow ssh https
!

Sprechen Sie Management-flachen Schutz zu mehr Information über MPP an.

Hinweis: MPP unterstützt IPv6 nicht und ist auf den IPv4-Eingabepfad beschränkt. Da IPv6 nicht gefiltert wird, sollten Sie in gemischten IPv4-/IPv6-Umgebungen CoPP verwenden.

Steuern Sie flachen Schutz

Control Plane Protection (CPPr) baut auf der Funktionalität von Control Plane Policing auf, um den Datenverkehr auf der Kontrollebene, der an den Routingprozessor des Cisco IOS-Geräts gerichtet ist, zu beschränken und zu regeln. CPPr wurde mit Cisco IOS-Software 12.4(4)T eingeführt und unterteilt die Kontrollebene in separate Kontrollebenenkategorien, die als Unterschnittstellen bezeichnet werden. Auf Kontrollebene gibt es drei Unterschnittstellen: Host, Transit und CEF-Exception. Darüber hinaus umfasst CPPr die folgenden Schutzfunktionen für die Kontrollebene:

• Funktion zur Portfilterung: Ermöglicht Admins das Policing oder Verwerfen von Paketen, die an geschlossene oder nicht empfangsbereite TCP- und UDP-Ports übermittelt werden.
  
  
• Funktion für Richtlinien zum Warteschlangen-Schwellenwert: Damit wird die Anzahl der Pakete für ein bestimmtes Protokoll eingeschränkt, die in der IP-Eingabewarteschlange der Kontrollebene zulässig sind.

Mithilfe von CPPr können Admins den an ein Gerät gesendeten Datenverkehr für Managementzwecke anhand der Host-Unterschnittstelle klassifizieren, kontrollieren und einschränken. Beispiele für Pakete, die anhand der Host-Unterschnittstellenkategorie klassifiziert werden, sind Managementdatenverkehr wie SSH oder Telnet und Routing-Protokolle.

Hinweis: CPPr unterstützt IPv6 nicht und ist auf den IPv4-Eingabepfad beschränkt.

Sprechen Sie Steuerflache Schutz-Merkmals-Anleitung - 12.4T und Verständnis des Steuerflachen Schutzes zu mehr Information über das Merkmal Ciscos CPPr an.

Verschlüsseln Sie Management-Sitzungen

Da in einer interaktiven Managementsitzung Informationen offengelegt werden können, muss dieser Datenverkehr verschlüsselt werden, damit sich böswillige BenutzerInnen keinen Zugriff auf die übertragenen Daten verschaffen können. Verkehrsverschlüsselung erlaubt eine sichere Fernzugriffverbindung zum Gerät. Wenn der Verkehr für eine Managementsitzung über das Netz im Klartext gesendet wird, kann ein Angreifer vertrauliche Information über das Gerät und das Netz einholen.

Ein Verwalter ist in der Lage, verschlüsselt herzustellen und Fernzugriffmanagementverbindung zu einem Gerät mit den Merkmalen SSHs oder HTTPS (sicheres Hypertext-Übergangsprotokoll) zu sichern. Cisco IOS-Software Support SSH-Version 1,0 (SSHv1), SSH-Version 2,0 (SSHv2) und HTTPS, das Secure Sockets Layer (SSL) und Transport Layer Security (TLS) für Authentisierung und Datenverschlüsselung verwendet. SSHv1 und SSHv2 sind nicht kompatibel. SSHv1 ist unsicher und nicht standardisiert, daher sollte das Protokoll nicht verwendet werden, solange SSHv2 eine Option ist.

Die Cisco IOS-Software unterstützt auch SCP (Secure Copy Protocol), das eine verschlüsselte, sichere Verbindung zum Kopieren von Gerätekonfigurationen oder Software-Images ermöglicht. SCP beruht auf SSH. Diese Beispielkonfiguration aktiviert SSH auf einem Cisco IOS-Gerät:

!

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
!

Dieses Konfigurationsbeispiel aktiviert SCP-Dienstleistungen:

!

ip scp server enable
!

Hier ein Konfigurationsbeispiel für HTTPS-Services:

!

crypto key generate rsa modulus 2048
!

ip http secure-server
!

Sprechen Sie konfigurierendes sicheres Shell auf den Routern und Schaltern an, die Cisco IOS ausführen und sichern Sie Shell (SSH) FAQ zu mehr Information über das Cisco IOS-Software SSH-Merkmal.

SSHv2

Über die mit Cisco IOS-Software 12.3(4)T eingeführte SSHv2-Unterstützungsfunktion können BenutzerInnen SSHv2 konfigurieren. (Die SSHv1-Unterstützung wurde in einer früheren Version der Cisco IOS-Software implementiert.) SSH wird auf einer zuverlässigen Transportschicht ausgeführt und bietet Funktionen für starke Authentifizierung und Verschlüsselung. Der einzige für SSH definierte zuverlässige Transport ist TCP. SSH bietet eine Möglichkeit, über ein Netzwerk sicher auf einen anderen Computer oder ein anderes Gerät zuzugreifen und darauf sicher Befehle auszuführen. Die über SSH getunnelte SCP-Funktion (Secure Copy Protocol) ermöglicht die sichere Übertragung von Dateien.

Wenn der Befehl ip ssh version 2 nicht explizit konfiguriert ist, aktiviert Cisco IOS stattdessen SSH Version 1.99. SSH-Version 1,99 erlaubt Verbindungen SSHv1 und SSHv2. SSHv1 gilt als unsicher und kann negative Auswirkungen auf das System haben. Wenn SSH aktiviert ist, wird empfohlen, SSHv1 mit dem Befehl ip ssh version 2 zu deaktivieren.

Diese Beispielkonfiguration aktiviert SSHv2 (wenn SSHv1 deaktiviert ist,) auf einem Cisco IOS-Gerät:

!
    
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    

!
 

Sprechen Sie sicheren Support Shell Versions 2 zu mehr Information über den Gebrauch SSHv2 an.

Verbesserungen SSHv2 für RSA-Tasten

Cisco IOS SSHv2 unterstützt die Tastatur-interaktiven und Passwort-basierten Authentisierungsmethoden. Die Verbesserungen SSHv2 für RSA-Hauptmerkmal unterstützt auch RSA-basierte Authentisierung der allgemeinen Taste für den Kunden und den Server.

Für Benutzerauthentisierung verwendet RSA-basierte Benutzerauthentisierung ein privates/allgemeines Schlüsselpaar, das mit jedem Benutzer für Authentisierung verbunden ist. Die BenutzerInnen müssen auf dem Client ein Schlüsselpaar (privat/öffentlich) generieren und auf dem Cisco IOS-SSH-Server einen öffentlichen Schlüssel konfigurieren, um die Authentifizierung abzuschließen.

Ein SSH-Benutzer, der versucht, die Bescheinigungen herzustellen, versieht eine verschlüsselte Unterzeichnung mit der privaten Taste. Die verschlüsselte Signatur und der öffentliche Schlüssel der BenutzerInnen werden zur Authentifizierung an den SSH-Server gesendet. Der SSH-Server berechnet ein Hasch über der allgemeinen Taste, die vom Benutzer zur Verfügung gestellt wird. Der Hash wird verwendet, um zu bestimmen, ob für den Server ein passender Eintrag vorhanden ist. Wenn eine Abgleichung gefunden wird, wird RSA-basierte Meldungsüberprüfung mit der allgemeinen Taste durchgeführt. Folglich wird der Benutzer beglaubigt, oder verweigerter Zugriff basiert auf der verschlüsselten Unterzeichnung.

Für Serverauthentisierung muss der Kunde Cisco IOS SSH eine Hauptrechnertaste für jeden Server zuweisen. Wenn der Kunde versucht, eine SSH-Sitzung mit einem Server herzustellen, empfängt er die Unterzeichnung des Servers als Teil der Schlüsselaustauschmeldung. Wenn das Flag für strenge Hostschlüsselprüfung auf dem Client aktiviert ist, überprüft der Client, ob er über den Hostschlüsseleintrag verfügt, der zum vorkonfigurierten Server passt. Wenn eine Abgleichung gefunden wird, versucht der Kunde, die Unterzeichnung mit der Serverhauptrechnertaste zu validieren. Wenn der Server erfolgreich authentifiziert wird, wird der Sitzungsaufbau fortgesetzt. Andernfalls wird er mit einer Meldung zu einer fehlgeschlagenen Serverauthentifizierung beendet.

Diese Beispielkonfiguration aktiviert den Gebrauch von RSA-Tasten mit SSHv2 auf einem Cisco IOS-Gerät:

!
! 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 
!

  

Sprechen Sie sichere Shell Version 2 Verbesserungen für RSA-Tasten zu mehr Information über den Gebrauch von RSA-Tasten mit SSHv2 an.

Diese Beispielkonfiguration aktiviert den Server Cisco IOS SSH, RSA-basierte Benutzerauthentisierung durchzuführen. Die Benutzerauthentisierung ist erfolgreich, wenn die allgemeine Taste RSA, die auf dem Server gespeichert wird, mit der Öffentlichkeit oder den privaten Schlüsselpaaren überprüft wird, die auf dem Kunden gespeichert werden.

!
! 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.)
!

Siehe das Konfigurieren des Servers Cisco IOS SSH, um RSA-basierte Benutzer-Authentisierung zu mehr Information über den Gebrauch von RSA-Tasten mit SSHv2 durchzuführen.

Diese Beispielkonfiguration aktiviert den Kunden Cisco IOS SSH, RSA-basierte Serverauthentisierung durchzuführen.

!
!

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 
!

Siehe das Konfigurieren des Kunden Cisco IOS SSH, RSA-basierte Server-Authentisierung zu mehr Information über den Gebrauch von RSA-Tasten mit SSHv2 durchzuführen.

Konsole und ZUSATZkanäle

In Cisco IOS-Geräten sind Konsole und zusätzliche (ZUSATZ) Kanäle asynchrone Zeilen, die für lokalen und Fernzugriff zu einem Gerät benutzt werden können. Wichtig zu wissen ist, dass die Konsolenports auf Cisco IOS-Geräten über spezielle Berechtigungen verfügen. Insbesondere erlauben diese Privilegien einem Verwalter, die PasswortWiederherstellungsprozedur durchzuführen. Um die Kennwortwiederherstellung durchzuführen, müsste sich ein nicht authentifizierter Angreifer Zugriff auf den Konsolenport verschaffen und die Möglichkeit haben, die Stromversorgung des Geräts zu unterbrechen oder das Gerät zum Absturz zu bringen.

Jede zum Zugreifen auf den Konsolenport eines Geräts verwendete Methode muss so sicher sein, dass sie der Sicherheit entspricht, die für den privilegierten Zugriff auf ein Gerät erzwungen wird. Bei den Methoden zum Schützen des Zugriffs müssen AAA, exec-timeout und moderne Kennwörter verwendet werden, wenn ein Modem an die Konsole angeschlossen ist.

Wenn keine Kennwortwiederherstellung erforderlich ist, kann ein Admin die Möglichkeit zur Kennwortwiederherstellung mit dem globalen Konfigurationsbefehl no service password-recovery entfernen. Nach Aktivierung des Befehls no service password-recovery ist es für Admins nicht mehr möglich, eine Kennwortwiederherstellung auf einem Gerät durchzuführen.

In den meisten Fällen muss der Geräte-AUX-Port deaktiviert werden, um nicht autorisierte Zugriffe zu verhindern. Ein ZUSATZkanal kann mit diesen Befehlen deaktiviert werden:

!

line aux 0
 transport input none
 transport output none
 no exec
 exec-timeout 0 1
 no password
!

Steuern Sie die vty und tty-Zeilen

Interaktive Managementsitzungen in Cisco IOS-Software benutzen einen tty oder virtuellen tty (vty). Ein tty ist eine lokale asynchrone Zeile, zu der ein Terminal für lokalen Zugriff zum Gerät oder zu einem Modem für Wählleitung zu einem Gerät befestigt werden kann. Beachten Sie, dass ttys für Verbindungen zu den Konsolenkanälen anderer Geräte benutzt werden können. Diese Funktion lässt ein Gerät mit tty-Zeilen als ein Konsolenserver, in dem auftreten Verbindungen über dem Netz hergestellt werden können zu den Konsolenkanälen von den Geräten, die an die tty-Zeilen angeschlossen werden. Die tty-Zeilen für diese Rückverbindungen über dem Netz müssen kontrolliert auch sein.

Eine vty Zeile wird für alle weiteren Netzs- mit größerer geographischer Ausdehnungverbindungen benutzt, die durch das Gerät, unabhängig davon Protokoll unterstützt werden (SSH, SCP oder telnet sind Beispiele). Um sicherzustellen, dass über eine lokale oder Remote-Managementsitzung auf ein Gerät zugegriffen werden kann, müssen die richtigen Kontrollen sowohl für VTY- als auch für TTY-Leitungen durchgesetzt werden. Cisco IOS-Geräte verfügen über eine begrenzte Anzahl von VTY-Leitungen. Die Anzahl der verfügbaren Leitungen kann mit dem EXEC-Befehl show line ermittelt werden. Wenn alle VTY-Leitungen belegt sind, können keine neuen Managementsitzungen hergestellt werden. Dadurch kann eine DoS-Bedingung für den Zugriff auf das Gerät entstehen.

Die einfachste Kontrolle für den Zugriff die VTY- oder TTY-Leitung eines Geräts besteht im Einsatz von Authentifizierung bei allen Leitungen, unabhängig vom Standort des Geräts im Netzwerk. Dies ist besonders bei VTY-Leitungen wichtig, da diese über das Netzwerk erreichbar sind. TTY-Leitungen, die mit einem Modem verbunden sind, das für den Remote-Zugriff auf das Gerät verwendet wird, oder TTY-Leitungen, die mit dem Konsolenport anderer Geräte verbunden sind, sind ebenfalls über das Netzwerk erreichbar. Andere Formulare von vty und tty-Zugriffssteuerungen können mit dem Transportinput oder Zugriff-klasseden konfigurationsbefehlen, mit dem Gebrauch von den Merkmalen CoPP und CPPr erzwungen werden oder, wenn Sie Zugriffslisten an den Schnittstellen auf dem Gerät anwenden.

Authentisierung kann durch den Gebrauch AAA erzwungen werden, der die empfohlene Methode für beglaubigten Zugriff zu einem Gerät, mit dem Gebrauch von der lokalen Benutzerdatenbank oder durch die einfache Passwortauthentisierung ist, die direkt auf der vty oder tty-Zeile konfiguriert wird.

Zum Abmelden von Sitzungen bei inaktiv gelassenen VTY- oder TTY-Leitungen muss der Befehl exec-timeout verwendet werden. Der Befehl service tcp-keepalives-in muss ebenfalls verwendet werden, um TCP-Keepalives bei eingehenden Verbindungen mit dem Gerät zu aktivieren. Dadurch wird sichergestellt, dass das Gerät am Remote-Ende der Verbindung weiterhin verfügbar bleibt und dass halb offene oder verwaiste Verbindungen vom lokalen Cisco IOS-Gerät entfernt werden.

Steuern Sie Transport für die vty und tty-Zeilen

Konfigurieren Sie VTY und TTY, um nur verschlüsselte und sichere Verbindungen für das Remote-Zugriffsmanagement mit dem Gerät oder über das Gerät zuzulassen, wenn es als Konsolenserver verwendet wird. Dieses Kapitel adressiert ttys, weil solche Zeilen an Konsolenkanäle auf anderen Geräten angeschlossen werden können, die den tty über dem Netz zugänglich sein lassen. Um die Offenlegung von Informationen oder den nicht autorisierten Zugriff auf die zwischen dem Admin und dem Gerät übertragenen Daten zu verhindern, verwenden Sie transport input ssh anstelle von unverschlüsselten Protokollen wie Telnet und rlogin. Die Konfiguration transport input none kann bei TTY aktiviert werden, wodurch letztlich die Verwendung der TTY-Leitung für umgekehrte Konsolenverbindungen verhindert wird.

erlauben vty und tty-Zeilen einem Verwalter, an andere Geräte anzuschließen. Um einzuschränken, welche Art von Transport Admins für ausgehende Verbindungen verwenden können, verwenden Sie den Konfigurationsbefehl transport output. Wenn keine ausgehenden Verbindungen benötigt werden, verwenden Sie transport output none. Wenn jedoch ausgehende Verbindungen zulässig sind, setzen Sie mit transport output ssh eine verschlüsselte, sichere Methode zum Remote-Zugriff für die Verbindung durch.

Hinweis: Sofern unterstützt, kann IPsec für verschlüsselte, sichere Remote-Zugriffsverbindungen zu einem Gerät verwendet werden. Wenn Sie IPSec verwenden, fügt es auch zusätzliche CPU-Unkosten dem Gerät hinzu. Allerdings muss SSH weiterhin als Transport durchgesetzt werden, auch wenn IPsec verwendet wird.

Warnende Banner

In einigen Gerichtsbarkeiten ist unter Umständen keine strafrechtliche Verfolgung böswilliger BenutzerInnen möglich, und die Überwachung dieser BenutzerInnen kann illegal sein, sofern sie nicht darauf hingewiesen wurden, dass sie das System nicht verwenden dürfen. Sie können die entsprechende Benachrichtigung in Form eines Banners platzieren, das Sie mit dem Cisco IOS-Befehl für ein Banner bei Anmeldung konfigurieren.

Die rechtlichen Auflagen für Benachrichtigungen sind komplex, variieren je nach Gerichtsbarkeit und Situation und müssen mit einem Rechtsbeistand besprochen werden. Sogar innerhalb der Rechtsprechungen, können sich Rechtsgutachten unterscheiden. In Absprache mit dem Rechtsbeistand kann ein Banner einige oder alle dieser Informationen beinhalten:

• Beachten Sie, dass das System in protokolliert werden oder verwendet werden soll nur durch speziell berechtigtes Personal und möglicherweise Informationen über, wem Gebrauch autorisieren kann.
  
  
• Beachten Sie, dass jede mögliche unbefugte Benutzung des Systems ungesetzlich ist und abhängig von den Zivil- und kriminellen Strafen sein kann.
  
  
• Beachten Sie, dass jede Nutzung des Systems ohne weitere Benachrichtigung protokolliert oder überwacht werden kann und dass die daraus resultierenden Protokolle als Beweismittel vor Gericht verwendet werden können.
  
  
• Spezifische Begriffe benötigt durch örtliche Gesetze.

Was die Sicherheit angeht, so sollte ein Anmeldebanner in keinem Fall konkrete Informationen über den Namen, das Modell, die Software oder den Besitzer des Routers enthalten. Diese Informationen können von den böswilligen Benutzern missbraucht werden.

Authentisierung, Ermächtigung und Buchhaltung

Das Framework für Authentifizierung, Autorisierung und Accounting (Nutzungsverfolgung) (AAA) ist wichtig für den sicheren interaktiven Zugriff auf Netzwerkgeräte. Das AAA-Framework bietet eine umfassend konfigurierbare Umgebung, die an die jeweiligen Netzwerkanforderungen angepasst werden kann.

TACACS+-Authentisierung

TACACS+ ist ein Authentifizierungsprotokoll, das von Cisco IOS-Geräten für die Authentifizierung von ManagementbenutzerInnen bei einem AAA-Remote-Server verwendet werden kann. Diese ManagementbenutzerInnen können über SSH, HTTPS, Telnet oder HTTP auf das IOS-Gerät zugreifen.

TACACS+-Authentisierung oder im Allgemeinen AAA-Authentisierung, liefert die Fähigkeit, einzelnen Benutzer zu verwenden erklärt jeden Netzwerkadministrator. Wenn Sie nicht von einem einzelnen geteilten Passwort abhängen, wird die Sicherheit des Netzes verbessert und Ihre Verantwortlichkeit wird verstärkt.

RADIUS ist ein Protokoll, das TACACS+ ähnelt. Dabei wird jedoch nur das Kennwort verschlüsselt, das über das Netzwerk gesendet wird. Demgegenüber verschlüsselt TACACS+ die gesamte TCP-Nutzlast, die das username und Passwort einschließt. Verwenden Sie daher TACACS+ anstatt RADIUS, wenn TACACS+ vom AAA-Server unterstützt wird. Siehe TACACS+- und RADIUS-Vergleich für einen ausführlicheren Vergleich dieser zwei Protokolle.

TACACS+-Authentisierung kann auf einem Cisco IOS-Gerät mit einer Konfiguration aktiviert werden, die diesem Beispiel ähnlich ist:

!

aaa new-model
aaa authentication login default group tacacs+
!

tacacs-server host <ip-address-of-tacacs-server>
tacacs-server key <key>
!

Die oben genannte Konfiguration kann als Ausgangspunkt für eine organisationsspezifische AAA-Authentifizierungsvorlage dienen. 

Eine Methodenliste ist eine sequenzielle Liste mit Angaben zu den Authentifizierungsmethoden, die abgefragt werden müssen, um BenutzerInnen zu authentifizieren. Mit Methodenlisten können Sie Sicherheitsprotokolle (eines oder mehrere) festlegen, die für die Authentifizierung verwendet werden sollen. So entsteht ein Backup-System für die Authentifizierung, falls die anfänglich verwendete Methode fehlschlägt. Cisco IOS-Software wendet die erste ausgedruckte Methode an, die erfolgreich einen Benutzer annimmt oder zurückweist. Die darunter aufgeführten Methoden werden versucht, wenn die weiter oben stehenden Methoden aufgrund von Nichtverfügbarkeit oder falscher Konfiguration des Servers fehlschlagen.

Authentisierungs-Reserve

Wenn alle konfigurierten TACACS+-Servers nicht verfügbar werden, dann kann ein Cisco IOS-Gerät auf Sekundärauthentisierungsprotokollen beruhen. Typische Konfigurationen umfassen den Gebrauch des Einheimischen oder aktivieren Authentisierung, wenn alle konfigurierten TACACS+-Servers nicht verfügbar sind.

Die komplette Liste von Optionen für Aufgerätauthentisierung umfasst aktivieren, Einheimisches und Zeile. Jede Option hat ihre Vorteile. Die Verwendung des enable secret ist vorzuziehen, da der Schlüssel mit einem unidirektionalen Algorithmus gehasht wird, der von Natur aus sicherer ist als der Verschlüsselungsalgorithmus, der mit den Typ-7-Kennwörtern für die Leitungs- oder lokale Authentifizierung verwendet wird.

Jedoch auf Cisco IOS-Software-Releases, die den Gebrauch von geheimen Passwörtern für lokal definierte Benutzer unterstützen, kann Reserve zur lokalen Authentisierung wünschenswert sein. Auf diese Weise können lokal definierte BenutzerInnen für einen oder mehrere Netzwerkadmins erstellt werden. Sollte keinerlei Verfügbarkeit von TACACS+ bestehen, kann jeder Admin seinen lokalen Benutzernamen und sein lokales Kennwort verwenden. Obgleich diese Aktion die Verantwortlichkeit von Netzwerkadministratoren in TACACS+-Ausfällen erhöht, erhöht sie erheblich die Verwaltungsbelastung, weil lokale Benutzerkonten auf allen Netzgeräten aufrechterhalten werden müssen.

Dieses Konfigurationsbeispiel baut auf dem vorherigen Beispiel für die TACACS+-Authentifizierung auf und umfasst die Fallback-Authentifizierung für das Kennwort, das lokal mit dem folgenden enable secret Befehl konfiguriert wurde:

!

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>
!

Gebrauch von Typen 7 Passwörter

Typ-7-Kennwörter wurden ursprünglich für die schnelle Entschlüsselung gespeicherter Kennwörter entwickelt. Sie sind daher keine sichere Möglichkeit zum Speichern von Kennwörtern. Es gibt viele Tools, die diese Kennwörter leicht entschlüsseln können. Vermeiden Sie die Verwendung von Typ-7-Kennwörtern, sofern sie nicht für eine auf dem Cisco IOS-Gerät genutzte Funktion erforderlich ist.

Verwenden Sie nach Möglichkeit stets Typ-9-Kennwörter (scrypt):

username <username> privilege 15 algorithm-type scrypt secret <secret>

Das Entfernen solcher Kennwörter kann durch AAA-Authentifizierung und die Verwendung der Funktion für die erweiterte Kennwortsicherheit erfolgen, die die Verwendung geheimer Kennwörter für Benutzer ermöglicht, die lokal durch den username globalen Konfigurationsbefehl definiert wurden. Wenn Sie den Gebrauch von Typen 7 Passwörter nicht völlig verhindern können, betrachten Sie diese Passwörter als verdunkelt, nicht verschlüsselt.

Weitere Informationen zum Entfernen von Typ-7-Kennwörtern finden Sie im Abschnitt Allgemeine Verwaltungsebenen-Sicherung.

TACACS+-Befehls-Ermächtigung

Befehlsermächtigung mit TACACS+ und AAA liefert einen Mechanismus, der ermöglicht oder verweigert jeden Befehl, der von einem Verwaltungsbenutzer eingegeben wird. Wenn der Benutzer Bedienungsaufrufe an den Ablaufteil eingibt, schickt Cisco IOS jeden Befehl zum konfigurierten AAA-Server. Der AAA-Server verwendet seine konfigurierten Richtlinien, um den Befehl für die jeweiligen BenutzerInnen zuzulassen oder zu verweigern.

Diese Konfiguration kann zum vorherigen AAA-Authentifizierungsbeispiel hinzugefügt werden, um die Befehlsautorisierung zu implementieren:

!

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
!

TACACS+-Befehls-Buchhaltung

Bei entsprechender Konfiguration sendet das AAA-Befehls-Accounting Informationen zu allen eingegebenen EXEC-Befehlen an die konfigurierten TACACS+-Server. Die an die TACACS+-Server gesendeten Informationen beinhalten den ausgeführten Befehl, das Ausführungsdatum und den Benutzernamen der Person, die den Befehl eingegeben hat. Befehlsbuchhaltung wird nicht mit RADIUS unterstützt.

Diese Beispielkonfiguration aktiviert AAA-Befehl die erklärenden Bedienungsaufrufe an den Ablaufteil, die auf Privilegstufen null, eine und 15 eingegeben werden. Diese Konfiguration baut auf den vorherigen Beispielen auf, die die Konfiguration der TACACS-Server beinhalten.

!

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
!

Überflüssige AAA-Servers

Die in einer Umgebung genutzten AAA-Server können redundant und fehlertolerant bereitgestellt werden. Dieses hilft, zu garantieren, dass interaktiver Managementzugriff, wie SSH, möglich ist, wenn ein AAA-Server nicht verfügbar ist.

Wenn Sie eine überflüssige AAA-Serverlösung konzipieren oder einführen, erinnern Sie sich an diese Erwägungen:

• Verfügbarkeit von AAA-Servern bei potenziellen Netzwerkausfällen
  
  
• Geographisch zerstreute Platzierung von AAA-Servers
  
  
• Laden Sie auf einzelnen AAA-Servers im Dauerzustand und in den Bruchbedingungen
  
  
• Netzlatenzzeit zwischen Netzzugang-Servers und AAA-Servers
  
  
• Aaa-Serverdatenbank- Synchronisierung

Sprechen Sie einsetzen die Zugriffssteuerungs-Servers zu mehr Information an.

Verstärken Sie das Simple Network Management Protocol

In diesem Abschnitt werden verschiedene Methoden vorgestellt, die zum Absichern der SNMP-Bereitstellung in IOS-Geräten verwendet werden können. Es ist wichtig, dass SNMP ordnungsgemäß geschützt wird, um die Vertraulichkeit, Integrität und Verfügbarkeit der Netzwerkdaten und der Netzwerkgeräte, über die diese Daten übertragen werden, zu wahren. SNMP bietet eine Vielzahl von Informationen zur Integrität von Netzwerkgeräten. Schützen Sie diese Informationen vor böswilligen BenutzerInnen, die diese Daten für Angriffe auf das Netzwerk nutzen möchten.

SNMP-Gemeinschaftszeichenketten

Gruppenzeichenfolgen sind Kennwörter, die auf ein Cisco IOS-Gerät angewendet werden, um den Zugriff (sowohl Lese- als auch Lese- und Schreibzugriff) auf die SNMP-Daten auf dem Gerät einzuschränken. So wie auch alle anderen Kennwörter sind diese Gruppenzeichenfolgen sorgfältig ausgewählt, damit sie nicht zu leicht zu erraten sind. Ändern Sie Gruppenzeichenfolgen in regelmäßigen Abständen und in Übereinstimmung mit den Netzwerksicherheitsrichtlinien. Ändern Sie die Zeichenfolgen beispielsweise, wenn ein Netzwerkadmin die Rolle wechselt oder das Unternehmen verlässt.

Diese Konfigurationszeilen konfigurieren eine Read-only-Gemeinschaftszeichenkette von READ-ONLY und eine Lese-Schreibgemeinschaftszeichenkette von LESE-SCHREIB:

!

snmp-server community READONLY RO
snmp-server community READWRITE RW  
!

Hinweis: Die obigen Beispiele für Gruppenzeichenfolgen wurden ausgewählt, um die Verwendung dieser Zeichenfolgen zu verdeutlichen. Für Produktionsumgebungen gilt es, die Gruppenzeichenfolgen mit Bedacht auszuwählen. Verwenden Sie daher eine Kombination aus alphabetischen, numerischen und nicht alphanumerischen Zeichen. 

Weitere Informationen zu dieser Funktion finden Sie in der Cisco IOS SNMP-Befehlsreferenz.

SNMP-Gemeinschaftszeichenketten mit ACLs

Wenden Sie zusätzlich zur Gruppenzeichenfolge eine ACL an, die den SNMP-Zugriff auf eine ausgewählte Gruppe von Quell-IP-Adressen weiter einschränkt. Diese Konfiguration schränkt SNMP-Read-only-Zugriff zu den Endenhauptrechnergeräten, die im 192.168.100.0/24 Adressbereich sich befinden ein und schränkt SNMP-Lese-Schreibzugriff nur zum Endenhauptrechnergerät bei 192.168.100.1 ein.

Hinweis: Die Geräte, die gemäß diesen ACLs zugelassen sind, benötigen die richtige Gruppenzeichenfolge, um auf die angeforderten SNMP-Informationen zugreifen zu können.

!

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
!

Sprechen Sie SNMPservergemeinschaft in der Cisco IOS-Netzführungs-Befehlsreferenz zu mehr Information über dieses Merkmal an.

Infrastruktur ACLs

Mit Infrastruktur-ACLs (iACLs) können Sie sicherstellen, dass nur End-Hosts mit vertrauenswürdigen IP-Adressen SNMP-Datenverkehr an ein Cisco IOS-Gerät senden können. Idealerweise sollte eine iACL eine Richtlinie zum Ablehnen nicht autorisierter SNMP-Pakete an UDP-Port 161 enthalten.

Sehen Sie den Begrenzungszugriff zum Netz mit Infrastruktur ACLs-Kapitel dieses Dokuments zu mehr Information über den Gebrauch von iACLs.

SNMP-Ansichten

SNMP-Ansichten sind ein Sicherheitsmerkmal, das Zugriff zu bestimmtem SNMP MIBs ermöglichen oder verweigern kann. Sobald eine Ansicht an einer Gemeinschaftszeichenkette mit den globalen Konfigurationsbefehlen der SNMPservergemeinschaftsgemeinschaftzeichenkettenansicht erstellt und angewendet wird, wenn Sie auf MIB-Daten zugreifen, werden Sie auf die Erlaubnis eingeschränkt, die durch die Ansicht definiert werden. Verwenden Sie ggf. Ansichten, damit SNMP-BenutzerInnen nur auf die von ihnen benötigten Daten zugreifen können.

Dieses Konfigurationsbeispiel schränkt SNMP-Zugriff mit der Gemeinschaftszeichenkette ein, die zu den MIB-Daten BEGRENZT ist, die in der Systemgruppe ist:

!

snmp-server view VIEW-SYSTEM-ONLY system include
!

snmp-server community LIMITED view VIEW-SYSTEM-ONLY RO
!

Sprechen Sie konfigurierenden SNMP-Support zu mehr Information an.

SNMP-Version 3

SNMP-Version 3 (SNMPv3) wird durch RFC3410, RFC3411, RFC3412, RFC3413, RFC3414 und RFC3415 definiert und ist ein dialogfähiges Standard-basiertes Protokoll für Netzführung. SNMPv3 bietet sicheren Zugang zu den Geräten, weil es beglaubigt und beliebig Pakete über dem Netz verschlüsselt. Sofern unterstützt, kann SNMPv3 verwendet werden, um beim Bereitstellen von SNMP eine weitere Sicherheitsebene hinzuzufügen. SNMPv3 besteht aus drei Primärkonfigurationsoptionen:

• no auth: Bei diesem Modus ist weder eine Authentifizierung noch eine Verschlüsselung von SNMP-Paketen erforderlich.
  
  
• authentisch - Dieser Modus benötigt Authentisierung des SNMP-Pakets ohne Verschlüsselung
  
  
• priv - Dieser Modus benötigt Authentisierung und Verschlüsselung (Privatleben) jedes SNMP-Pakets

Es muss die ID einer autoritativen Engine vorhanden sein, damit die SNMPv3-Sicherheitsmechanismen, nämlich die Authentifizierung oder Authentifizierung und Verschlüsselung, für die Handhabung von SNMP-Paketen verwendet werden können; die Engine-ID wird standardmäßig lokal generiert. Die Engine-ID kann mit dem folgenden show snmp engineID Befehl angezeigt werden:

router#show snmp engineID 
   Local SNMP engineID: 80000009030000152BD35496
   Remote Engine ID          IP-addr    Port

Hinweis: Wenn der Wert von engineID geändert wird, müssen alle SNMP-Benutzerkonten neu konfiguriert werden.

Der nächste Schritt ist, eine Gruppe SNMPv3 zu konfigurieren. Dieser Befehl konfiguriert ein Cisco IOS-Gerät für SNMPv3 mit einer SNMP-Servergruppe AUTHGROUP und aktiviert nur Authentisierung für diese Gruppe mit dem authentischen Schlüsselwort:

!
snmp-server group AUTHGROUP v3 auth
!

Dieser Befehl konfiguriert ein Cisco IOS-Gerät für SNMPv3 mit einer SNMP-Servergruppe PRIVGROUP und aktiviert Authentisierung und Verschlüsselung für diese Gruppe mit dem priv Schlüsselwort:

!
snmp-server group PRIVGROUP v3 priv
!

Mit diesem Befehl wird ein SNMPv3-Benutzer snmpv3user mit einem MD5-Authentifizierungskennwort von authpassword und einem 3DES-Verschlüsselungskennwort von konfiguriert: privpassword.

!

snmp-server user snmpv3user PRIVGROUP v3 auth md5 authpassword priv 3des 
     privpassword
!

Beachten Sie, dass snmp-server user Konfigurationsbefehle nicht wie von RFC 3414 gefordert in der Konfigurationsausgabe des Geräts angezeigt werden. deshalb ist das Benutzerpasswort nicht von der Konfiguration sichtbar. Um die konfigurierten Benutzer anzuzeigen, geben Sie den show snmp user Befehl ein, wie in diesem Beispiel gezeigt:

router#show snmp user 
User name: snmpv3user
Engine ID: 80000009030000152BD35496
storage-type: nonvolatile        active
Authentication Protocol: MD5
Privacy Protocol: 3DES
Group-name: PRIVGROUP

Sprechen Sie konfigurierenden SNMP-Support zu mehr Information über dieses Merkmal an.

Management-flacher Schutz

Mit der Funktion zum Schutz der Managementebene (Management Plane Protection, MPP) in Cisco IOS-Software können Sie SNMP zusätzlich schützen, da sie die Schnittstellen einschränkt, über die der SNMP-Datenverkehr auf dem Gerät enden kann. Das mpp-Merkmal erlaubt einem Verwalter, eine oder mehrere Schnittstellen als Managementschnittstellen zu kennzeichnen. Managementverkehr wird die Erlaubnis gehabt, um ein Gerät nur durch diese Managementschnittstellen einzutragen. Nachdem MPP aktiviert ist, keine Schnittstellen, ausgenommen gekennzeichnete Managementschnittstellen Netzführungsverkehr annehmen, der zum Gerät vorgesehen wird.

MPP ist ein Teil der CPPr-Funktion und erfordert eine Version von Cisco IOS, die CPPr unterstützt. Siehe Verständnis des Steuerflachen Schutzes zu mehr Information über CPPr.

In diesem Beispiel wird MPP verwendet, um den SNMP- und SSH-Zugriff exklusiv auf die FastEthernet 0/0-Schnittstelle zu beschränken:

!
control-plane host
 management-interface FastEthernet0/0 allow ssh snmp 
!

Sprechen Sie Management-flache Schutz-Merkmals-Anleitung zu mehr Information an.

Protokollierende optimale Verfahren

Die Ereignisprotokolle bieten Ihnen Einblick in den Betrieb eines Cisco IOS-Geräts und das Netzwerk, in dem sie bereitgestellt werden. In der Cisco IOS-Software sind mehrere flexible Protokoll-Optionen vorhanden, die dazu beitragen können, die Unternehmensziele bezüglich Netzwerkmanagement und -transparenz zu erreichen.

Diese Abschnitte enthalten einige grundlegende Best Practices für die Protokollierungsfunktion, die Admins helfen kann, die Protokollierung erfolgreich und bei minimalen Auswirkungen auf Cisco IOS-Geräte zu nutzen.

Schicken Sie Logs zu einem zentralen Standort

Es wird empfohlen, Protokoll-Informationen an einen Remote-Syslog-Server zu senden. Dieses macht es möglich, effektiv aufeinander zu beziehen und Revisionsnetz- und -sicherheitsereignisse über Netzgeräten. Beachten Sie, dass syslog-Meldungen unzuverlässig durch UDP und in Klartext übertragen werden. Daher können alle Schutzmaßnahmen, die ein Netzwerk für den Managementdatenverkehr bietet (z. B. Verschlüsselung oder Out-of-Band-Zugriff), unter Einbeziehung des Syslog-Datenverkehrs erweitert werden.

In diesem Beispiel wird ein Cisco IOS-Gerät für das Senden von Protokoll-Informationen an einen Remote-Syslog-Server konfiguriert:

!
logging host <ip-address>
!

Weitere Informationen zur Protokollkorrelation finden Sie unter Identifying Incidents Using Firewall and Cisco IOS Router Syslog Events (Identifizieren von Vorfällen mithilfe von Firewall- und Cisco IOS-Router-Syslog-Ereignissen).

Mit der in Cisco IOS 12.4(15)T integrierten und ursprünglich mit Version 12.0(26)S eingeführten Funktion zur Protokollierung auf permanentem Speicher (ATA-Laufwerk) können Nachrichten zu Systemprotokollen auf einem ATA-Flash-Laufwerk (Advanced Technology Attachment) gespeichert werden. Die Meldungen, die auf einem ATA-Laufwerk gesichert werden, bestehen weiter, nachdem ein Router neu geladen ist.

Mit den folgenden Konfigurationszeilen werden 134.217.728 Byte (128 MB) für Protokollnachrichten im Syslog-Verzeichnis des ATA-Flash-Laufwerks (disk0) mit einer auf 16.384 Byte definierten Dateigröße konfiguriert:

logging buffered
logging persistent url disk0:/syslog size 134217728 filesize 16384

Bevor Protokollnachrichten in eine Datei auf dem ATA-Laufwerk geschrieben werden, überprüft die Cisco IOS-Software, ob genügend Speicherplatz vorhanden ist. Ist dies nicht der Fall, wird die (nach Zeitstempel) älteste Protokollnachrichten-Datei gelöscht, und die aktuelle Datei wird gespeichert. Das Format des Dateinamens ist log_month:day:year::time.

Hinweis: Der Speicherplatz auf einem ATA-Flash-Laufwerk ist begrenzt und muss daher gezielt verwaltet werden, um zu vermeiden, dass gespeicherte Daten überschrieben werden können.

Das folgende Beispiel zeigt, wie Sie im Rahmen der Wartung Protokollnachrichten von der ATA-Flash-Festplatte des Routers auf eine externe Festplatte auf dem FTP-Server 192.168.1.129 kopieren können:

copy disk0:/syslog ftp://myuser/mypass@192.168.1.129/syslog

Siehe das Protokollieren zur lokalen nichtflüssigen Speicherung (ATA Disk) zu mehr Information über dieses Merkmal.

Protokollierende Stufe

Jeder von einem Cisco IOS-Gerät generierte Protokollnachricht wird einer von acht Schweregraden zwischen Ebene 0 (Notfälle) und Ebene 7 (Debugging) zugewiesen. Sofern nicht ausdrücklich erforderlich, sollten Sie keine Protokolle auf Ebene 7 erfassen. Auf Ebene 7 erhöht die Erfassung von Protokollen die CPU-Load auf dem Gerät, was Instabilität auf Geräten und Netzwerken nach sich ziehen kann.

Mit der globalen Befehlsebene für logging trap die Konfiguration wird festgelegt, welche Protokollmeldungen an Syslog-Remoteserver gesendet werden. Die spezifizierte Stufe zeigt die niedrigste Schweremeldung an, die gesendet wird. Bei gepufferten Protokollen wird der Befehl logging buffered "level" verwendet.

Im folgenden Konfigurationsbeispiel werden die an Remote-Syslog-Server gesendeten Protokollnachrichten und der lokale Protokollpuffer auf Schweregrad 6 (Informationsmeldungen) bis 0 (Notfälle) beschränkt:

!

logging trap 6
logging buffered 6
!

Siehe Störungssuche, Störungs-Management und das Protokollieren zu mehr Information.

Protokollieren Sie nicht, um zu trösten oder Monitorläufe

Mit der Cisco IOS-Software ist es möglich, Protokollmeldungen an die Konsole zu senden, um Sitzungen zu überwachen, bei denen es sich um interaktive Verwaltungssitzungen handelt, in denen der EXEC-Befehl ausgegeben terminal monitor wurde. Dies kann jedoch die CPU-Load eines Cisco IOS-Geräts erhöhen und wird daher nicht empfohlen. Senden Sie stattdessen Protokollinformationen an den lokalen Protokollpuffer, der mit dem show logging Befehl angezeigt werden kann.

Verwenden Sie die globalen Konfigurationsbefehle no logging console und no logging monitor , um Protokolle an der Konsole zu deaktivieren und Sitzungen zu überwachen. Dieses Konfigurationsbeispiel zeigt den Gebrauch von diesen Befehlen:

!

no logging console
no logging monitor
!

Siehe Cisco IOS-Netzführungs-Befehlsreferenz zu mehr Information über globale Konfigurationsbefehle.

Verwenden gepufferter Protokolle

Die Cisco IOS-Software unterstützt die Verwendung eines lokalen Protokollpuffers, damit Admins lokal generierte Protokollnachrichten anzeigen können. Es wird dringend empfohlen, gepufferte Protokolle anstelle der Erfassung von Protokollen auf der Konsole oder in Monitoring-Sitzungen zu verwenden.

Wenn Sie gepufferte Protokolle konfigurieren, gibt es zwei relevante Konfigurationsoptionen: die Größe der Protokollpuffer und die im Puffer gespeicherten Schweregrade der Nachrichten. Die Größe des logging buffer wird mit dem globalen Konfigurationsbefehl konfiguriert. Der niedrigste Schweregrad, der im Puffer enthalten ist, wird mit dem Befehl log buffered severity logging buffered size. (protokollierter gepufferter Schweregrad) konfiguriert. Ein Administrator kann den Inhalt des Protokollpuffers über den Befehl show logging EXEC anzeigen.

Im folgenden Konfigurationsbeispiel werden ein Protokollpuffer von 16.384 Byte und der Schweregrad 6 konfiguriert. Letzteres bedeutet, dass Nachrichten von Ebene 0 (Notfälle) bis Ebene 6 (Informationsmeldungen) gespeichert werden.

!

logging buffered 16384 6
!

Weitere Informationen zu gepufferten Protokollen finden Sie in der Cisco IOS-Befehlsreferenz für das Netzwerkmanagement.

Konfigurieren Sie protokollierende Quellschnittstelle

Um die Konsistenz beim Erfassen und Prüfen von Protokollnachrichten zu erhöhen, sollten Sie eine Quellschnittstelle zur Protokollierung statisch konfigurieren. Dies wird durch den Befehl "logging source-interfaceinterface" erreicht. Mit einer statisch konfigurierten Quellschnittstelle zur Protokollierung stellen Sie sicher, dass in allen von einem bestimmten Cisco IOS-Gerät gesendeten Protokollnachrichten dieselbe IP-Adresse enthalten ist. Verwenden Sie für zusätzliche Stabilität eine Loopback-Schnittstelle als Protokollquelle.

In diesem Konfigurationsbeispiel wird die Verwendung des globalen Konfigurationsbefehls für die logging source-interface Schnittstelle veranschaulicht, mit dem die IP-Adresse der Loopback 0-Schnittstelle für alle Protokollmeldungen festgelegt wird:

!
logging source-interface Loopback 0
!

Sprechen Sie die Cisco IOS-Befehlsreferenz zu mehr Information an.

Konfigurieren von Protokoll-Zeitstempeln

Die Konfiguration von Protokollzeitstempeln erleichtert Ihnen das Korrelieren von Ereignissen über mehrere Netzwerkgeräte hinweg. Eine korrekte, konsistente Konfiguration für Protokollzeitstempel ist wichtig, damit Sie die Protokolldaten korrelieren können. Konfigurieren Sie die Protokollierungszeitstempel so, dass Datum und Uhrzeit millisekundengenau angegeben und auch die auf dem Gerät verwendete Zeitzone erfasst wird.

Das folgende Beispiel beinhaltet die Konfiguration von millisekundengenauen Protokollzeitstempeln in der UTC-Zone (Coordinated Universal Time):

!
service timestamps log datetime msec show-timezone
!

Wenn Sie, es vorziehen Zeiten nicht im Verhältnis zu UTC zu protokollieren, können Sie eine spezifische Ortszeitzone konfigurieren und diese Informationen konfigurieren, um in festgelegten Logmeldungen anwesend zu sein. Dieses Beispiel zeigt eine Geräteausstattung für die Zone der pazifischen Standardzeit (PST):

!

clock timezone PST -8
service timestamps log datetime msec localtime show-timezone
!

Cisco IOS-Software-Konfigurationsverwaltung

Die Cisco IOS-Software beinhaltet verschiedene Funktionen zur Umsetzung einer bestimmten Art des Konfigurationsmanagements auf einem Cisco IOS-Gerät. Hierzu zählen Funktionen zum Archivieren von Konfigurationen und zum Rollback der Konfiguration auf eine frühere Version sowie zum Erstellen eines detaillierten Protokolls der Konfigurationsänderungen.

Konfiguration ersetzen und Konfigurations-Preissenkung

Im Cisco IOS-Software-Release 12.3(7)T und später, ersetzen die Konfiguration und Konfigurations-Preissenkungsmerkmale erlauben Ihnen, die Cisco IOS-Geräteausstattung auf dem Gerät zu archivieren. Die manuell oder automatisch gespeicherten Konfigurationen in diesem Archiv können verwendet werden, um die aktuelle Konfiguration durch den Befehl configure replace filename zu ersetzen. Dies steht im Gegensatz zum Befehl copy filename running-config . Der configure replace Befehl filename ersetzt die aktuelle Konfiguration, nicht die Zusammenführung durch den copy Befehl.

Es wird empfohlen, diese Funktion auf allen Cisco IOS-Geräten im Netzwerk zu aktivieren. Sobald diese Funktion aktiviert ist, kann der Administrator die aktuelle Konfiguration mit dem archive config EXEC Befehl zum Archiv hinzufügen. Die archivierten Konfigurationen können mit dem show archive EXEC Befehl angezeigt werden.

Dieses Beispiel veranschaulicht die Konfiguration der automatischen Konfigurationsarchivierung. In diesem Beispiel wird das Cisco IOS-Gerät angewiesen, archivierte Konfigurationen als Dateien mit dem Namen archived-config-N auf dem Dateisystem disk0: zu speichern, maximal 14 Sicherungen zu verwalten und einmal täglich (1440 Minuten) zu archivieren, wenn ein Administrator den write memory EXEC Befehl ausgibt.

!

archive
 path disk0:archived-config
 maximum 14
 time-period 1440
 write-memory
!

Obwohl die Konfigurationsarchivierungsfunktion bis zu 14 Backup-Konfigurationen speichern kann, wird empfohlen, die Speicheranforderungen zu berücksichtigen, bevor Sie den maximum Befehl verwenden.

Exklusiver Konfigurations-Änderungs-Zugriff

Die mit Cisco IOS-Software 12.3(14)T neu hinzugekommene Funktion für den Exklusivzugriff für Konfigurationsänderungen sorgt dafür, dass immer nur ein Admin auf einmal Konfigurationsänderungen an einem Cisco IOS-Gerät vornimmt. Dieses Merkmal hilft, die unerwünschte Auswirkung von den simultanen Änderungen zu beseitigen, die an in Verbindung stehenden Konfigurationskomponenten vorgenommen werden. Diese Funktion wird mit dem globalen Konfigurationsbefehlsmodus konfiguriert und configuration mode exclusive in einem von zwei Modi ausgeführt: "auto" oder "manual". Im Auto-Modus wird die Konfiguration automatisch gesperrt, wenn ein Administrator den configure terminal EXEC Befehl ausgibt. Im manuellen Modus sperrt der Administrator mit dem configure terminal lock Befehl die Konfiguration, wenn dieser in den Konfigurationsmodus wechselt.

Dieses Beispiel veranschaulicht die Konfiguration dieses Merkmals für das automatische Konfigurationssperrung:

!
configuration mode exclusive auto
!

Cisco IOS-Software-elastische Konfiguration

Die in Cisco IOS-Software 12.3(8)T eingeführte Funktion für eine ausfallsichere Konfiguration ermöglicht das sichere Speichern einer Kopie des Cisco IOS-Software-Image und der aktuellen Gerätekonfiguration eines Cisco IOS-Geräts. Wenn dieses Merkmal aktiviert wird, ist es nicht möglich, diese Sicherungsdateien zu ändern oder zu löschen. Es wird empfohlen, diese Funktion zu aktivieren, um unbeabsichtigte und böswillige Dateilöschungen zu verhindern.

!
secure boot-image
secure boot-config!

Sobald dieses Merkmal aktiviert wird, ist es möglich, ein gelöschtes Konfigurations- oder Cisco IOS-Software-Bild zurückzustellen. Der aktuelle Status dieser Funktion kann mit dem show secure boot EXEC Befehl angezeigt werden.

Digital gekennzeichnete Cisco-Software

Die in Cisco IOS-Software 15.0(1)M für die Cisco Router der Serien 1900, 2900 und 3900 eingeführte Funktion für digital signierte Cisco Software vereinfacht die Verwendung von digital signierter und damit vertrauenswürdiger Cisco IOS-Software mithilfe von sicherer asymmetrischer Kryptografie (öffentlicher Schlüssel).

Ein digital gekennzeichnetes Bild trägt ein verschlüsseltes (mit einer privaten Taste) Hasch von sich. Bei der Überprüfung entschlüsselt das Gerät den Hash mit dem zugehörigen öffentlichen Schlüssel aus den Schlüsseln in seinem Schlüsselspeicher und berechnet auch seinen eigenen Hash für das Image. Wenn das entschlüsselte Hasch das berechnete Bildhasch abgleicht, ist das Bild nicht mit abgegeben worden und kann vertraut werden.

Digital gekennzeichnete Cisco-Software-Tasten werden nach dem Typen und der Version der Taste identifiziert. Eine Taste kann ein Special, eine Produktion oder ein Unfallschlüsseltyp sein. Produktions- und Spezialschlüsseln ist eine Schlüsselversion zugeordnet, die alphabetisch ansteigt, wenn der Schlüssel widerrufen und ersetzt wird. ROMMON und regelmäßige Cisco IOS-Bilder werden mit einer Special- oder Produktionstaste gekennzeichnet, wenn Sie die Digital gekennzeichnete Cisco-Programmiereinrichtung benutzen. Das ROMMON-Bild ist erweiterungsfähig und muss mit der gleichen Taste wie das Special- oder Produktionsbild gekennzeichnet werden, das geladen wird.

Dieser Befehl überprüft die Integrität des Bildes c3900-universalk9-mz.SSA im Blitz mit den Tasten im Gerättastenspeicher:

show software authenticity file flash0:c3900-universalk9-mz.SSA

Die Digital gekennzeichnete Cisco-Programmiereinrichtung wurde auch in Freigabe 3.1.0.SG Cisco IOS XE für den Cisco-Katalysator die 4500 E-Serien-Schalter integriert.

Sprechen Sie Digital gekennzeichnete Cisco-Software zu mehr Information über dieses Merkmal an.

Im Cisco IOS-Software-Release 15.1(1)T und später, wurde Schlüsselersatz für Digital gekennzeichnete Cisco-Software eingeführt. Bei Schlüsselersetzung und -widerruf wird ein Schlüssel, der zur Überprüfung von digital signierter Cisco Software anhand des plattformeigenen Schlüsselspeichers verwendet wird, ersetzt und entfernt. Nur spezielle und Produktionstasten können im Falle eines Schlüsselkompromisses widerrufen werden.

Ein neuer Spezial- oder Produktionsschlüssel für ein Spezial- oder Produktions-Image wird in einem Produktions- oder Widerrufs-Image bereitgestellt, das zum Widerrufen des vorherigen Spezial- oder Produktionsschlüssels verwendet wird. Die Rücknahmebildintegrität wird mit einer Unfalltaste überprüft, die vorgespeichert auf der Plattform kommt. Eine Unfalltaste ändert nicht. Wenn Sie einen Produktionsschlüssel widerrufen, nachdem das Widerrufs-Image geladen wurde, wird der enthaltene neue Schlüssel dem Schlüsselspeicher hinzugefügt, und der zugehörige alte Schlüssel kann widerrufen werden, sofern ein Upgrade des ROMMON-Image durchgeführt und das neue Produktions-Image gebootet wird. Wenn Sie eine spezielle Taste widerrufen, wird ein Produktionsbild geladen. Dieses Bild fügt die neue spezielle Taste hinzu und kann die alte spezielle Taste widerrufen. Nachdem Sie ROMMON ausbauen, kann das neue spezielle Bild aufgeladen werden.

Dieses Beispiel beschreibt Rücknahme einer speziellen Taste. Mit folgenden Befehlen wird der neue Spezialschlüssel aus dem aktuellen Produktions-Image dem Schlüsselspeicher hinzugefügt, ein neues ROMMON-Image (C3900_rom-monitor.srec.SSB) in den Speicherbereich (usbflash0:) kopiert, ein Upgrade der ROMMON-Datei durchgeführt und der alte Spezialschlüssel widerrufen:

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

Ein neues spezielles Bild (c3900-universalk9-mz.SSB) kann zu ladenden Blitz und zur Unterzeichnung des Bildes dann kopiert werden wird überprüft mit der eben hinzugefügten speziellen Taste (.SSB):

copy /verify tftp://192.168.1.129/c3900-universalk9-mz.SSB flash:

Schlüsselrücknahme und Ersatz wird nicht auf Katalysator die 4500 E-Serien-Schalter unterstützt, die Software Cisco IOS XE ausführen, obgleich diese Schalter die Digital gekennzeichnete Cisco-Programmiereinrichtung unterstützen.

Sprechen Sie das Digital gekennzeichnete Cisco-Software-Tasten-Rücknahme- und Ersatzkapitel der Digital gekennzeichneten Cisco-Software-Anleitung zu mehr Information über dieses Merkmal an.

Konfigurations-Änderungs-Mitteilung und protokollieren

Die Konfigurations-Änderungs-Mitteilung und das protokollierende Merkmal, hinzugefügt im Cisco IOS-Software-Release 12.3(4)T, macht es möglich, die Konfigurationsänderungen zu protokollieren, die an einem Cisco IOS-Gerät vorgenommen werden. Das Protokoll wird auf dem Cisco IOS-Gerät verwaltet und enthält die Benutzerinformationen der Person, die die Änderung vorgenommen hat, den eingegebenen Konfigurationsbefehl und den Zeitpunkt, zu dem die Änderung vorgenommen wurde. Diese Funktion wird mit dem Konfigurationsmodus-Befehl zur logging enable Konfigurationsänderung der Protokollierung aktiviert. Die optionalen Befehle hidekeys und logging size Einträge werden verwendet, um die Standardkonfiguration zu verbessern, da sie Protokolle mit Kennwortdaten verhindern und die Länge des Änderungsprotokolls erhöhen.

Es wird empfohlen, diese Funktion zu aktivieren, damit sich der Verlauf der Konfigurationsänderungen bei einem Cisco IOS-Gerät leichter nachvollziehen lässt. Außerdem wird empfohlen, mit dem notify syslog Konfigurationsbefehl die Generierung von Syslog-Meldungen zu aktivieren, wenn eine Konfigurationsänderung vorgenommen wird.

!

archive
 log config
  logging enable
  logging size 200
  hidekeys
  notify syslog
!

Nachdem die Funktion für Konfigurationsänderungsbenachrichtigungen und -protokollierung aktiviert wurde, show archive log config all kann das Konfigurationsprotokoll mithilfe des privilegierten EXEC-Befehls angezeigt werden.

Steuern Sie Fläche

Die Funktionen der Kontrollebene umfassen die Protokolle und Prozesse für die Kommunikation zwischen Netzwerkgeräten zur Übertragung der Daten von der Quelle zum Ziel. Hierzu zählen Routing-Protokolle wie BGP (Border Gateway Protocol) sowie Protokolle wie ICMP und RSVP (Resource Reservation Protocol).

Es ist wichtig, dass Ereignisse in den Management- und Datenflächen nicht nachteilig die Steuerfläche beeinflussen. Wenn ein Ereignis auf der Datenebene, beispielsweise ein DoS-Angriff, die Kontrollebene beeinflusst, kann das gesamte Netzwerk instabil werden. Diese Informationen über Cisco IOS-Programmiereinrichtungen und Konfigurationen können helfen, die Beweglichkeit der Steuerfläche sicherzustellen.

Allgemeines Steuerflache Verhärtung

Der Schutz der Kontrollebene eines Netzwerkgeräts ist wichtig, da die Kontrollebene sicherstellt, dass die Management- und Datenebene gewartet werden und betriebsbereit bleiben. Wird die Kontrollebene bei einem Sicherheitsvorfall instabil, ist es unter Umständen nicht mehr möglich, die Stabilität des Netzwerks wiederherzustellen.

In vielen Fällen können Sie den Empfang und die Übertragung bestimmter Arten von Nachrichten für eine Schnittstelle deaktivieren, um die auf die Verarbeitung nicht benötigter Pakete entfallende CPU-Load zu minimieren.

IP-ICMP adressiert um

Ein ICMP adressieren Meldung kann durch einen Router festgelegt werden um, wenn ein Paket auf die gleiche Schnittstelle empfangen und übertragen wird. In dieser Situation sendet der Router vorwärts das Paket und ein ICMP umadressieren Meldung zurück zu dem Absender des ursprünglichen Pakets. Dieses Verhalten erlaubt dem Absender, den Router und die vorderen zukünftigen Pakete direkt zur Zieleinheit zu umgehen (oder zu einem Router näher an der Zieleinheit). In einem richtig arbeitenden IP-Netz sendet ein Router umadressiert nur zu den Hauptrechnern auf seinen eigenen lokalen Teilnetzen. Das heißt, dass die ICMP-Umleitungen in der Regel nie über eine Layer-3-Grenze hinausgehen.

Es gibt zwei Arten von ICMP-Umleitungsnachrichten: die Umleitung für eine Host-Adresse und die Umleitung für ein komplettes Subnetz. Böswillige BenutzerInnen können die Fähigkeit des Routers zum Senden von ICMP-Umleitungen ausnutzen, indem sie fortlaufend Pakete an den Router senden, worauf der Router mit ICMP-Umleitungsnachrichten reagieren muss. Dies wirkt sich negativ auf die CPU-Auslastung und Leistung des Routers aus. Um zu verhindern, dass der Router ICMP-Umleitungen überträgt, verwenden Sie den no ip redirects Schnittstellenkonfigurationsbefehl.

ICMP Unreachables

Das Filtern anhand einer Schnittstellenzugriffsliste führt zur Übertragung von Nachrichten zur ICMP-Nichterreichbarkeit zurück an die Quelle des gefilterten Datenverkehrs. Durch die Generierung dieser Nachrichten kann sich die CPU-Auslastung auf dem Gerät erhöhen. In der Cisco IOS-Software ist die Generierung von Paketen zur ICMP-Nichterreichbarkeit standardmäßig auf ein Paket alle 500 Millisekunden begrenzt. Die Erzeugung von nicht erreichbaren ICMP-Nachrichten kann mit dem Schnittstellenkonfigurationsbefehl no ip unreachablesdeaktiviert werden. Die Durchsatzbegrenzung "ICMP Unreachable" kann mit dem globalen Konfigurationsbefehl "interval-in ms" ip icmp rate-limit unreachable vom Standardwert abgesetzt werden.

Proxy ARP

Proxy-ARP ist die Technik, bei der ein Gerät, in der Regel ein Router, ARP-Anfragen beantwortet, die für ein anderes Gerät bestimmt sind. Der Router übernimmt die Verantwortung für die Weiterleitung von Paketen an das echte Ziel, indem er seine Identität verfälscht. Mithilfe von Proxy-ARP können Computer in einem Subnetz Remote-Subnetze ohne Routenkonfiguration oder Standardgateway erreichen. Proxy ARP wird in RFC 1027 definiert.

Die Verwendung eines ARP-Proxy geht mit Nachteilen einher. Es kann eine Zunahme der Menge von ARP-Verkehr auf der Netzsegment- und -ressourcenabführung und den Mann-in-d-mittleren Angriffen ergeben. Proxy ARP stellt einen Ressourcenabführungs-Angriffsvektor dar, weil jede proxied ARP-Anfrage eine kleine Menge des Speichers verbraucht. Angreifer können den gesamten verfügbaren Arbeitsspeicher auslasten, wenn sie eine hohe Anzahl von ARP-Anfragen senden.

Man-in-the-Middle-Angriffe ermöglichen es einem Host im Netzwerk, die MAC-Adresse des Routers zu manipulieren, was dazu führt, dass Hosts ungewollt Datenverkehr an den Angreifer übermitteln. Proxy-ARP kann mit dem Schnittstellenkonfigurationsbefehl deaktiviert werden. no ip proxy-arp.

Grenze-CPU-Auswirkung des Steuerflächen-Verkehrs

Schutz der Steuerfläche ist- kritisch. Da die Anwendungsleistung und die Benutzererfahrung ohne Daten- und Managementverkehr beeinträchtigt werden können, stellen Sie durch eine widerstandsfähige Kontrollebene sicher, dass die anderen beiden Ebenen gewartet und betriebsbereit bleiben.

Verstehen Sie Steuerflachen Verkehr

Um die Kontrollebene des Cisco IOS-Geräts richtig schützen zu können, müssen Sie wissen, für welche Arten von Datenverkehr Process-Switching durch die CPU erfolgt. Der Process-Switching-Datenverkehr besteht normalerweise aus zwei verschiedenen Arten von Datenverkehr. Die erste Art von Datenverkehr ist an das Cisco IOS-Gerät gerichtet und muss direkt von der CPU des Cisco IOS-Geräts verarbeitet werden. Dieser Verkehr besteht aus der Empfangungsumgebungs-Verkehrskategorie. Dieser Datenverkehr enthält einen Eintrag in der Cisco Express Forwarding (CEF)-Tabelle, wobei der nächste Router-Hop das Gerät selbst ist. Dieser Ausdruck wird in der CLI-Ausgabe durch den Begriff "Receive" (Empfangen) show ip cef gekennzeichnet. Dieses Anzeichen ist das Argument für jedes mögliches IP address, das das direkte Handhaben durch die Cisco IOS-Gerät CPU benötigt, die Schnittstelle IP address, Multicast-Adresse Adressbereich einschließt, und SendungsAdressbereich.

Die zweite Art von Datenverkehr, der von der CPU verarbeitet wird, ist Datenverkehr der Datenebene, d. h. Datenverkehr mit einem Ziel jenseits des Cisco IOS-Geräts selbst, der eine spezielle Verarbeitung durch die CPU erfordert. Bei folgende Arten von Datenverkehr findet Process-Switching statt, die den Betrieb der Kontrollebene beeinflussen können (wobei es über diese Liste hinaus auch andere Arten von Datenverkehr mit CPU-Auswirkungen gibt):

• ACL-Protokollierung: ACL-Protokolldatenverkehr umfasst alle Pakete, die aufgrund einer Übereinstimmung (Zulassen/Ablehnen) mit einem ACE generiert werden, in dem das Protokollschlüsselwort verwendet wird.
  
  
• Unicast RPF (Reverse Path Forwarding): Unicast RPF kann bei Verwendung mit einer ACL dazu führen, dass für bestimmte Pakete Process Switching erfolgt.
  
  
• IP-Optionen - Alle mögliche IP-Pakete mit den eingeschlossenen Optionen müssen durch die CPU verarbeitet werden.
  
  
• Fragmentierung: Alle IP-Pakete, die Fragmentierung erfordern, müssen zur Verarbeitung an die CPU übergeben werden.
  
  
• TTL-Ablauf (Time to Live): Bei Paketen mit einem TTL-Wert von kleiner oder gleich 1 müssen ICMP-Nachrichten zur Zeitüberschreitung (Internet Control Message Protocol – ICMP Typ 11, Code 0) versendet werden, die von der CPU verarbeitet werden.
  
  
• ICMP-Nichterreichbarkeitspakete: Pakete, die aus Routing-, MTU- oder Filtergründen in Nachrichten zur ICMP-Nichterreichbarkeit resultieren, werden von der CPU verarbeitet.
  
  
• Datenverkehr, der eine ARP-Anforderung erfordert - Ziele, für die kein ARP-Eintrag vorhanden ist, werden von der CPU verarbeitet.
  
  
• Verkehr Nicht-IP - Aller Verkehr NichtiP wird durch die CPU verarbeitet.

Die folgende Liste enthält verschiedene Methoden, mit denen Sie ermitteln können, welche Arten von Datenverkehr von der CPU des Cisco IOS-Geräts verarbeitet werden:

• Der show ip cef Befehl stellt die Next-Hop-Informationen für jedes in der CEF-Tabelle enthaltene IP-Präfix bereit. Wie vorher angezeigt, empfangen Einträge, die enthalten, während das „folgende Hopfen“ empfangen Umgebung betrachtet werden und zeigen an, dass Verkehr direkt zur CPU geschickt werden muss.
  
  
• Der show interface switching Befehl liefert Informationen zur Anzahl der Pakete, die von einem Gerät verarbeitet werden.
  
  
• Der show ip traffic Befehl liefert Informationen zur Anzahl der IP-Pakete:
  
  
  • mit einer lokalen Zieleinheit (empfangen Sie das heißt, Umgebungsverkehr)
  • mit Optionen
  • das benötigen Fragmentierung
  • das werden gesendet, um Adressbereich zu übertragen
  • das werden zum Multicast-Adressen-Adressbereich geschickt
    
    
• Empfangen Sie Umgebungsverkehr kann durch den Gebrauch von dem Show-IP-Cacheflussbefehl identifiziert werden. Alle an das Cisco IOS-Gerät gerichteten Datenströme haben die Zielschnittstelle (Destination Interface, DstIf) „local“.
  
  
• Mit Control Plane Policing können Sie die Art und Geschwindigkeit des Datenverkehrs identifizieren, der die Kontrollebene des Cisco IOS-Geräts erreicht. Die Richtlinienzuweisung auf Kontrollebene kann mithilfe detaillierter Klassifizierungs-ACLs, Protokolle und des show policy-map control-plane Befehls erfolgen.

Infrastruktur ACLs

Grenzmitteilung nach außen Infrastruktur ACLs (iACLs) zu den Geräten des Netzes. iACLs werden in diesem Dokument im Abschnitt Beschränken des Zugriffs auf das Netzwerk mit Infrastruktur-ACLs ausführlich behandelt.

Es wird empfohlen, iACLs zu implementieren, um die Kontrollebene aller Netzwerkgeräte zu schützen.

Empfangen Sie ACLs

Für verteilte Plattformen empfangen Sie ACLs (rACLs) kann eine Option für Cisco IOS-Software-Releases 12.0(21)S2 für die 12000 (GSR), 12.0(24)S für die 7500 und 12.0(31)S für die 10720 sein. Das rACL schützt das Gerät vor schädlichem Verkehr vor dem Verkehr auswirkt den Wegprozessor. rACLs dienen nur dazu, das Gerät zu schützen, auf dem sie konfiguriert sind. Der Transitdatenverkehr wird von einer rACL nicht beeinflusst. Daher bezieht sich die in den ACL-Beispieleinträgen unten verwendete Ziel-IP-Adresse „any“ nur auf die physischen oder virtuellen IP-Adressen des Routers. rACLs gelten auch als Best Practice für die Netzwerksicherheit und können als langfristige Ergänzung für ein sicheres Netzwerk angesehen werden.

Dieses ist der Empfangsweg ACL, der geschrieben wird, um Verkehr SSHs (TCP-Kanal 22) von verlässlichen Hauptrechnern im Netz 192.168.100.0/24 zu ermöglichen:

!
!--- 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
!

Weitere Informationen dazu, wie Sie legitimen Datenverkehr zu einem Gerät identifizieren und zulassen und alle unerwünschten Pakete ablehnen können, finden Sie unter Receive-Zugriffskontrolllisten.

CoPP

Auch mit der CoPP-Funktion können Sie die an das Infrastrukturgerät gerichteten IP-Pakete einschränken. In diesem Beispiel nur SSH-Verkehr von verlässlichen Hauptrechnern wird die Erlaubnis gehabt, um die Cisco IOS-Gerät CPU zu erreichen. 

Hinweis: Durch das Verwerfen von Datenverkehr von unbekannten oder nicht vertrauenswürdigen IP-Adressen können Hosts mit dynamisch zugewiesenen IP-Adressen unter Umständen keine Verbindung zum Cisco IOS-Gerät herstellen.

!

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
!

Im vorhergehenden CoPP-Beispiel lassen die ACL-Einträge, die abgleichen, die nicht autorisierten Pakete mit dem Erlaubnisaktionsergebnis in einem Ausschuss dieser Pakete durch die Politikkarte Funktion fallen, während Pakete, die die Leugnungsaktion abgleichen, nicht durch die Politikkartenrückgangsfunktion beeinflußt werden.

CoPP ist in Cisco IOS-Software-Release Serien 12.0S, 12.2SX, 12.2S, 12.3T, 12,4 und 12.4T verfügbar.

Steuern Sie flachen Schutz

Die mit Cisco IOS-Software 12.4(4)T eingeführte Funktion zum Schutz der Kontrollebene (Control Plane Protection, CPPr) kann verwendet werden, um den von der CPU eines Cisco IOS-Geräts ausgehenden Datenverkehr auf der Kontrollebene einzuschränken oder zu kontrollieren. Ähnlich wie mit CoPP lässt sich der Datenverkehr auch mit CPPr präziser einschränken. Bei CPPr wird die aggregierte Kontrollebene in drei getrennte Kontrollebenenkategorien aufgeteilt, die als Unterschnittstellen bezeichnet werden. Subinterfaces existieren für Hauptrechner-, Durchfahrt- und CEF-Ausnahmeverkehr Kategorien. Darüber hinaus enthält CPPr diese Steuerflache Schutzmerkmale:

• Funktion zur Portfilterung: Diese Funktion ermöglicht das Policing oder Verwerfen von Paketen, die an geschlossene oder nicht empfangsbereite TCP- und UDP-Ports gerichtet sind.
  
  
• Funktion für Richtlinien zum Warteschlangenschwellenwert: Diese Funktion schränkt die Anzahl der Pakete für ein bestimmtes Protokoll ein, die in der IP-Eingabewarteschlange der Kontrollebene zulässig sind.

Weitere Informationen zur Verwendung der CPPr-Funktion finden Sie unter Understanding Control Plane Protection (CPPr).

Hardware Rate Limiters

Die Cisco Catalyst Supervisor Engine 32 und Supervisor Engine 720 der Cisco Catalyst 6500-Serie unterstützen plattformspezifische hardwarebasierte Lösungen zur Ratenbegrenzung (Hardware-based Rate Limiters, HWRLs) für spezielle Netzwerkszenarien. Diese Hardware-Kinetikbegrenzer gekennzeichnet als Speziellfallkinetikbegrenzer, weil sie ein Besondere vorbestimmtes Set IPv4, IPv6, unicast und multicast DOS-Szenario umfassen. HWRLs können das Cisco IOS Gerät vor einer Vielzahl von Angriffen schützen, bei denen Pakete von der CPU verarbeitet werden müssen.

Mehrere HWRLs sind standardmäßig aktiviert. Weitere Informationen zu HWRLs finden Sie bei den Standardeinstellungen für Lösungen zur hardwarebasierten Ratenbegrenzung auf PFC3.

Sprechen Sie Rate Limiters Hardware gestützt auf dem PFC3 zu mehr Information über HWRLs an.

Sichern Sie BGP

Das Border Gateway Protocol (BGP) ist die Wegewahlgrundlage des Internets. Als solches verwendet jede mögliche Organisation mit mehr als bescheidenen Anschlussfähigkeitsanforderungen häufig BGP. BGP ist oft Ziel von Angriffen, weil es auf breiter Basis genutzt wird und kleinere Unternehmen die BGP-Konfiguration oft nur einmal festlegen und dann nicht mehr beachten. Jedoch gibt es viele BGP-spezifischen Sicherheitsmerkmale, die wirksam eingesetzt werden können, um die Sicherheit einer BGP-Konfiguration zu erhöhen.

Im Folgenden erhalten Sie einen Überblick über die wichtigsten Sicherheitsfunktionen von BGP sowie ggf. Empfehlungen zur Konfiguration.

TTL-basierte Sicherheits-Schutze

Jedes IP-Paket enthält ein Feld 1-byte, das als das Time to Live (TTL) bekannt ist. Jedes Gerät, dass ein IP-Paket Dekrement dieser Wert durch einen überquert. Der TTL-Anfangswert variiert je nach Betriebssystem und liegt normalerweise zwischen 64 und 255. Ein Paket wird fallen gelassen, wenn sein TTL-Wert null erreicht.

Der sowohl als GTSM (Generalized TTL-based Security Mechanism) und als BTSH (BGP TTL Security Hack) bekannte TTL-basierte Sicherheitsschutz stellt anhand des TTL-Werts von IP-Paketen sicher, dass die empfangenen BGP-Pakete von einem direkt verbundenen Peer stammen. Diese Funktion erfordert häufig die Koordination von Peer-Routern. Sobald sie aktiviert ist, kann sie jedoch viele TCP-basierte Angriffe auf BGP vollständig verhindern.

GTSM für BGP wird mit der ttl-security Option für den Konfigurationsbefehl des neighbor BGP-Routers aktiviert. Dieses Beispiel veranschaulicht die Konfiguration dieses Merkmals:

!

router bgp <asn>
 neighbor <ip-address> remote-as <remote-asn>
 neighbor <ip-address> ttl-security hops <hop-count>
!

Wenn BGP-Pakete empfangen werden, wird ihr TTL-Wert geprüft. Er muss größer oder gleich 255 abzüglich der angegebenen Hop-Anzahl sein.

BGP Peer Authentication mit MD5

Gleichauthentisierung mit MD5 stellt eine Auswahl MD5 jedes Pakets her, das als Teil einer BGP-Sitzung gesendet wird. Konkret werden Teile der IP- und TCP-Header, die TCP-Payload und ein geheimer Schlüssel verwendet, um den Digest zu generieren.

Die hergestellte Auswahl wird dann in TCP-Option Art 19 gespeichert, die speziell zu diesem Zweck durch RFC 2385 erstellt wurde. Der empfangende BGP-Router verwendet denselben Algorithmus und denselben geheimen Schlüssel, um den Nachrichten-Digest neu zu generieren. Wenn die empfangenen und Berechnungs- Auswahl nicht identisch sind, wird das Paket verworfen.

Die Peer-Authentifizierung mit MD5 wird mit der password Option des Konfigurationsbefehls des neighbor BGP-Routers konfiguriert. Im Folgenden wird Verwendung dieses Befehls veranschaulicht:

!

router bgp <asn>
 neighbor <ip-address> remote-as <remote-asn>
 neighbor <ip-address> password <secret>
!

Sprechen Sie Nachbarrouter-Authentisierung zu mehr Information über BGP-Gleichauthentisierung mit MD5 an.

Konfigurieren Sie maximale Vorzeichen

BGP-Vorzeichen werden durch einen Router im Speicher gespeichert. Je mehr Präfixe ein Router vorhalten muss, desto mehr Arbeitsspeicher nimmt BGP in Anspruch. Bei einigen Konfigurationen kann eine Teilmenge aller Internet-Präfixe gespeichert werden, beispielsweise in Konfigurationen, bei denen nur eine Standardroute oder Routen für die Benutzernetzwerke eines Anbieters genutzt werden.

Um einer Überlastung des Arbeitsspeichers vorzubeugen, konfigurieren Sie die Höchstanzahl der Präfixe, die pro Peer akzeptiert werden. Es wird empfohlen, dass eine Grenze für jeden BGP-Gleichen konfiguriert wird.

Wenn Sie diese Funktion mit dem neighbor maximum-prefix BGP-Router-Konfigurationsbefehl konfigurieren, ist ein Argument erforderlich: die maximale Anzahl von Präfixen, die akzeptiert werden, bevor ein Peer heruntergefahren wird. Beliebig kann eine Zahl von 1 bis 100 auch eingegeben werden. Diese Zahl stellt den Prozentsatz des Wertes für die Höchstanzahl der Präfixe, bei dem eine Protokollnachricht gesendet wird.

!

router bgp <asn>
 neighbor <ip-address> remote-as <remote-asn>
 neighbor <ip-address> maximum-prefix <shutdown-threshold> <log-percent>
!

Siehe das Konfigurieren des BGP-Maximum-Vorzeichen-Merkmals zu mehr Information über Progleichmaximumvorzeichen.

Filtern Sie BGP-Vorzeichen mit Vorzeichen-Listen

Mit Präfixlisten können Netzwerkadmins bestimmte Präfixe zulassen oder ablehnen, die über BGP gesendet oder empfangen werden. Verwenden Sie nach Möglichkeit Präfixlisten, um sicherzustellen, dass der Netzwerkverkehr über die vorgesehenen Pfade gesendet wird. Wenden Sie Präfixlisten auf jeden eBGP-Peer sowohl in der eingehenden als auch in der ausgehenden Richtung an.

Konfigurierte Präfixlisten begrenzen die Präfixe, die gesendet oder empfangen werden, auf die von der Routing-Richtlinie eines Netzwerks ausdrücklich zugelassenen Präfixe. Wenn dies aufgrund der großen Anzahl der empfangenen Präfixe nicht möglich ist, konfigurieren Sie eine Präfixliste so, dass bekanntermaßen ungültige Präfixe gezielt blockiert werden. Zu diesen bekanntermaßen fehlerhaften Präfixen zählen nicht zugeordnete IP-Adressbereiche und Netzwerke, die für interne oder Testzwecke von RFC 3330 reserviert sind.  Konfigurieren Sie Listen für ausgehende Präfixe so, dass sie nur die Präfixe zulassen, die eine Organisation anzukündigen beabsichtigt.

Dieses Konfigurationsbeispiel benutzt Vorzeichenlisten, um die Wege zu begrenzen, die gelehrt sind und machte bekannt. Speziell nur ein default route wird Inlands durch Vorzeichenliste BGP-PL-INBOUND erlaubt, und das Vorzeichen 192.168.2.0/24 ist der einzige Weg, der durch BGP-PL-OUTBOUND bekannt gemacht werden lassen wird.

!

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
!

Umfassende Informationen zur vollständigen Abdeckung der BGP-Präfixfilterung finden Sie bei den Hinweisen zum Herstellen einer Verbindung mit einem Service-Provider mithilfe von externem BGP.

Filtern Sie BGP-Vorzeichen mit Autonomouss- Systempfad-Zugriffs-Listen

Mit AS-Pfadzugriffslisten (Autonomous System, autonomes System) können BenutzerInnen empfangene und angekündigte Präfixe anhand des „AS-path“-Attributs eines Präfixes filtern. Dieses Verfahren kann mit Präfixlisten verwendet werden, um einen robusten Satz an Filtern zu erstellen.

In diesem Konfigurationsbeispiel werden AS-Pfadzugriffslisten verwendet, um die eingehenden Präfixe auf die vom Remote-AS stammenden Präfixe und die ausgehenden Präfixe auf die vom lokalen autonomen System stammenden Präfixe zu beschränken. Präfixe, die von allen anderen autonomen Systemen stammen, werden gefiltert und nicht in der Routing-Tabelle installiert.

!

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
!

Sichern Sie Innenkommunikationsrechner-Protokolle

Ob ein Netzwerk den Datenverkehr ordnungsgemäß weiterleiten und Änderungen oder Fehler in der Topologie überstehen kann, hängt von einer exakten Ansicht der Topologie ab. Oft kann diese Ansicht durch das Ausführen eines IGP (Interior Gateway Protocol) erzielt werden. Standardmäßig sind IGP dynamisch und entdecken zusätzliche Router, die das bestimmte gebräuchliche IGP sind. IGPs erkennen auch Routen, die beim Ausfall einer Netzwerkverbindung verwendet werden können.

Diese Unterabschnitte liefern einen Überblick über die wichtigsten IGP-Sicherheitsmerkmale. Empfehlungen und Beispiele, die Routing- Information Protocolversion 2 (RIPv2) umfassen, erhöhtes Innenkommunikationsrechner-Wegewahl-Protokoll (EIGRP) und offenes Shortest-Path zuerst (OSPF) werden zur Verfügung gestellt, wenn passend.

Verlegung von von Protokoll-Authentisierung und Überprüfung mit Meldungs-Auswahl 5

Störung, den Austausch der Leitinformation zu sichern erlaubt einem Angreifer, falsche Leitinformation in das Netz vorzustellen. Verwenden Sie Kennwortauthentifizierung mit Routing-Protokollen zwischen Routern, um die Sicherheit des Netzwerks zu stärken. Jedoch weil diese Authentisierung als Klartext gesendet wird, kann es einfach sein, damit ein Angreifer diese Sicherheitskontrolle umstürzt.

Durch das Hinzufügen von MD5-Hash-Funktionen zum Authentifizierungsprozess enthalten Routing-Updates keine Klartext-Kennwörter mehr, und der gesamte Inhalt des Routing-Updates ist widerstandsfähiger gegen Manipulationen. Allerdings ist die MD5-Authentifizierung immer noch anfällig für Brute-Force- und Wörterbuchangriffe, wenn schwache Kennwörter verwendet werden. Sie werden geraten, Passwörter mit genügender Zufallszuteilung zu verwenden. Da Authentisierung MD5, wenn sie mit Passwortauthentisierung verglichen wird, diese Beispiele, sind spezifisch zur Authentisierung MD5 viel sicherer ist. IPsec kann ebenfalls zum Validieren und Schützen von Routing-Protokollen eingesetzt werden, wird in den folgenden Beispielen jedoch nicht näher beschrieben.

Sowohl EIGRP als auch RIPv2 nutzen Schlüsselketten als Teil der Konfiguration. Siehe Taste zu mehr Information über die Konfiguration und den Gebrauch der Schlüsselanhänger.

Hier eine Beispielkonfiguration für die EIGRP-Router-Authentifizierung mit 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>
!

Dieses ist eine Router-Authentisierungskonfiguration des Beispiels MD5 für RIPv2. RIPv1 unterstützt nicht Authentisierung.

!

key chain <key-name>
 key <key-identifier>
 key-string <password> 
!

interface <interface>
 ip rip authentication mode md5
 ip rip authentication key-chain <key-name>
!

Hier eine Beispielkonfiguration für die OSPF-Router-Authentifizierung mit MD5. Bei OSPF werden keine Schlüsselketten verwendet.

!

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
!

Sprechen Sie konfigurierendes OSPF zu mehr Information an.

Passiv-Schnittstellen-Befehle

Informationslecks oder das Einschleusen falscher Informationen in ein IGP können durch die Verwendung des Befehls verhindert werden, der bei der passive-interface Steuerung der Meldung von Routing-Informationen hilft. Es wird empfohlen, Netzwerken außerhalb Ihrer administrativen Kontrolle keine Informationen anzukündigen.

Das folgende Beispiel veranschaulicht die Verwendung dieser Funktion:

!

router eigrp <as-number> 
 passive-interface default
 no passive-interface <interface>
!

Weg-Entstörung

Um die Möglichkeit zu reduzieren, dass falsche Routing-Informationen in das Netzwerk eingeschleust werden, müssen Sie die Routenfilterung verwenden. Im Gegensatz zum Konfigurationsbefehl für den passive-interface Router erfolgt das Routing an Schnittstellen, sobald die Routenfilterung aktiviert ist, die angezeigten oder verarbeiteten Informationen jedoch eingeschränkt sind.

Bei EIGRP und RIP beschränkt die Verwendung des distribute-list Befehls mit dem out Schlüsselwort die angezeigten Informationen, während die Verwendung des in Schlüsselworts die verarbeiteten Updates einschränkt. Der distribute-list Befehl steht für OSPF zur Verfügung, verhindert jedoch nicht, dass ein Router gefilterte Routen propagiert. Stattdessen kann der area filter-list Befehl verwendet werden.

In diesem EIGRP-Beispiel werden ausgehende Ankündigungen mit dem distribute-list Befehl und einer Präfixliste gefiltert:

!

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>
!

Dieses EIGRP-Beispiel filtert Inlandsaktualisierungen mit einer Vorzeichenliste:

!

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>
!

In diesem OSPF-Beispiel wird eine Präfixliste mit den OSPF-spezifischen area filter-list command:

!

ip prefix-list <list-name> seq 10 permit <prefix> 
!

router ospf <process-id>
 area <area-id> filter-list prefix <list-name> in 
!

Wegewahl-Prozess-Ressourcen-Verbrauch

Routing-Protokollpräfixe werden vom Router im Arbeitsspeicher abgelegt. Entsprechend ist der Ressourcenverbrauch umso höher, je mehr Präfixe ein Router vorhalten muss. Um einer Überlastung der Ressourcen vorzubeugen, konfigurieren Sie das Routing-Protokoll so, dass der Ressourcenverbrauch begrenzt wird. Dieses ist mit OSPF möglich, wenn Sie die Link-Zustands-Datenbank-Überlastschutzfunktion benutzen.

Dieses Beispiel zeigt Konfiguration des OSPF-Link-Zustands-Datenbank-Überlastschutzmerkmals:

!

router ospf <process-id>
 max-lsa <maximum-number> 
!

Sichern Sie erste Hopfenredundanz-Protokolle

Erste Hopfenredundanz-Protokolle (FHRPs) stellen Elastizität und Redundanz für Geräte zur Verfügung, die als Nichterfüllungskommunikationsrechner auftreten. Diese Situation und diese Protokolle sind in den Umgebungen alltäglich, in denen ein Paar Geräte der Schicht 3 Nichterfüllungskommunikationsrechnerfunktionalität für ein Netzsegment oder Set von VLANs zur Verfügung stellt, die Servers oder Arbeitsplätze enthalten.

Das Kommunikationsrechner-Eingabe-balancierende Protokoll (GLBP), das Hot-standbyrouter-Protokoll (HSRP) und das virtuelle Router-Redundanz-Protokoll (VRRP) sind alles FHRPs. Standardmäßig sind diese Protokolle unauthenticated Kommunikationen verbunden. Diese Art der Kommunikation kann es Angreifern ermöglichen, sich als FHRP-konformes Routergerät zu tarnen, um die Rolle des Standardgateways im Netzwerk zu übernehmen. Durch diese Übernahme können die Angreifer einen Man-in-the-Middle-Angriff durchführen und den gesamten Benutzerdatenverkehr abfangen, der das Netzwerk verlässt.

Um diese Art von Angriffen zu verhindern, enthalten alle von der Cisco IOS-Software unterstützten FHRPs eine Authentifizierungsfunktion mit entweder MD5 oder Textzeichenfolgen. Wegen der Drohung, die durch unauthenticated FHRPs aufgeworfen wird, wird es empfohlen, dass Fälle dieser Protokolle Authentisierung MD5 verwenden. Dieses Konfigurationsbeispiel zeigt den Gebrauch von GLBP-, HSRP- und VRRP-MD5 Authentisierung:

!

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
!

Daten-Fläche

Die Datenebene ist zwar für das Übertragen von Daten von der Quelle zum Ziel zuständig, spielt aber im Kontext der Sicherheit eine kleinere Rolle als die beiden anderen Ebenen. Aus diesem Grund sollten Sie sich zugunsten der Sicherheit eines Netzwerkgeräts zuerst dem Schutz der Managementebene und der Kontrollebene widmen.

Jedoch innerhalb der Datenfläche selbst, gibt es viele Merkmale und Konfigurationsoptionen, die sicherem Verkehr helfen können. In den folgenden Abschnitten werden die Funktionen und Optionen beschrieben, mit denen Sie Ihr Netzwerk einfacher schützen können.

Allgemeine Daten-flache Verhärtung

Der überwiegende Teil des Datenverkehrs der Datenebene läuft über das Netzwerk, wie durch die Routing-Konfiguration des Netzwerks festgelegt. Jedoch existiert IP-Netzfunktionalität, um den Pfad von Paketen über dem Netz zu ändern. Funktionen wie IP-Optionen, insbesondere die Source Routing-Option, stellen eine Sicherheitsherausforderung in den Netzwerken von heute dar.

Die Verwendung von Transit-ACLs ist auch für das Härten der Datenebene relevant.

Weitere Informationen finden Sie im Abschnitt Filter Transit Traffic with Transit ACLs (Transit-ACLs filtern).

IP-Options-selektiver Tropfen

Es gibt zwei Sicherheitsprobleme, die durch IP-Optionen dargestellt werden. Datenverkehr, der IP-Optionen enthält, muss von Cisco IOS-Geräten per Process Switching verarbeitet werden, was zu einer erhöhten CPU-Last führen kann. IP-Optionen bieten auch die Möglichkeit, den Pfad des Datenverkehrs im Netzwerk zu ändern. So können potenziell Sicherheitskontrollen umgangen werden.

Aus diesem Grund ip options {drop | ignore} wurde der globale Konfigurationsbefehl zu den Cisco IOS Software-Versionen 12.3(4)T, 12.0(22)S und 12.2(25)S hinzugefügt. In der ersten Form dieses Befehls werden ip options dropalle IP-Pakete verworfen, die vom Cisco IOS-Gerät empfangene IP-Optionen enthalten. Dieses verhindert die erhöhte CPU-Eingabe und mögliche Subversion von Sicherheitskontrollen, die IP-Optionen aktivieren können.

Die zweite Form dieses Befehls konfiguriert das Cisco IOS-Gerät ip options ignoreso, dass in empfangenen Paketen enthaltene IP-Optionen ignoriert werden. Dies reduziert zwar die Bedrohungen im Zusammenhang mit IP-Optionen für das lokale Gerät, jedoch könnten Downstream-Geräte durch das Vorhandensein von IP-Optionen beeinträchtigt werden. Aus diesem Grund wird die drop Form dieses Befehls dringend empfohlen. Im folgenden Konfigurationsbeispiel wird dies veranschaulicht:

!
ip options drop
!

Einige Protokolle wie etwa RSVP nutzen IP-Optionen in legitimem Rahmen. Die Funktionalität dieser Protokolle wird durch diesen Befehl ausgewirkt.

Sobald IP Options Selective Drop aktiviert wurde, kann mit dem show ip traffic EXEC Befehl die Anzahl der Pakete bestimmt werden, die aufgrund vorhandener IP-Optionen verworfen werden. Diese Informationen sind im vorverlegten Rückgangszähler anwesend.

Sperrung IP-Quellwegewahl

Für das IP Source Routing werden die Optionen „Loose Source Route“ und „Record Route“ zusammen oder die Option „Strict Source Route“ zusammen mit der Option „Record Route“ verwendet, um die Angabe des Netzwerkpfads für ein Paket durch die Quelle des IP-Datagramms zu ermöglichen. Mithilfe dieser Funktion können Angreifer versuchen, Datenverkehr um die Sicherheitskontrollen im Netzwerk herumzuleiten.

Wenn IP-Optionen nicht mithilfe der Funktion zum selektiven Verwerfen von IP-Optionen vollständig deaktiviert wurden, muss IP Source Routing unbedingt deaktiviert werden. Das IP-Quell-Routing, das in allen Cisco IOS-Softwareversionen standardmäßig aktiviert ist, wird durch den no ip source-route globalen Konfigurationsbefehl deaktiviert. Dieses Konfigurationsbeispiel veranschaulicht den Gebrauch von diesem Befehl:

!
no ip source-route
!

Sperrung ICMP adressiert um

Mithilfe von ICMP-Umleitungen wird ein Netzwerkgerät über einen besser geeigneten Pfad zu einem IP-Ziel informiert. Standardmäßig sendet die Cisco IOS-Software ein Umadressierung, wenn sie ein Paket empfängt, das durch die Schnittstelle verlegt werden muss, die, sie empfangen wurde.

In bestimmten Situationen können Angreifer möglicherweise das Senden vieler ICMP-Umleitungsnachrichten durch das Cisco IOS-Gerät verursachen, was zu einer erhöhten CPU-Load führt. Aus diesem Grund wird empfohlen, die Übertragung von ICMP-Umleitungen zu deaktivieren. ICMP-Umleitungen werden mit dem Schnittstellenkonfigurationsbefehl no ip redirects deaktiviert, wie in dieser Beispielkonfiguration gezeigt:

!

interface FastEthernet 0
 no ip redirects
!

Sperrungs-oder Grenz-IP verwiesene Sendungen

IP verwiesene Sendungen machen es möglich, ein IP-Sendungspaket zu einem Fern-IP-Teilnetze zu schicken. Sobald das Paket das Remote-Netzwerk erreicht, sendet das IP-Weiterleitungsgerät das Paket als Layer-2-Broadcast an alle Stationen im Subnetz. Diese Directed Broadcast-Funktion wurde bereits mehrfach bei Angriffen als Mittel zur Verstärkung und Verbreitung genutzt. Ein Beispiel sind sogenannte Smurf-Angriffe.

In aktuellen Versionen der Cisco IOS-Software ist diese Funktion standardmäßig deaktiviert. Sie kann jedoch über den ip directed-broadcast Schnittstellenkonfigurationsbefehl aktiviert werden. Bei Versionen vor Cisco IOS-Software 12.0 ist diese Funktion standardmäßig aktiviert.

Wenn ein Netzwerk unbedingt eine Directed Broadcast-Funktion erfordert, muss deren Verwendung gezielt kontrolliert werden. Dies ist möglich, wenn eine ACL als Option für den ip directed-broadcast Befehl verwendet wird. Im folgenden Konfigurationsbeispiel werden Directed Broadcasts auf UDP-Pakete aus dem vertrauenswürdigen Netzwerk 192.168.1.0/24 begrenzt:

!

access-list 100 permit udp 192.168.1.0 0.0.0.255 any
!

interface FastEthernet 0
 ip directed-broadcast 100
!

Filter-Durchgangsverkehr mit Durchfahrt ACLs

Es ist möglich, zu steuern, welcher Verkehr das Netz mit dem Gebrauch von Durchfahrt ACLs (tACLs) durchfährt. Dies steht im Gegensatz zu iACLs, mit denen der an das Netzwerk selbst gerichtete Datenverkehr gefiltert wird. Der von tACLs bereitgestellte Filter ist nützlich, wenn das Ziel darin besteht, den Datenverkehr zu filtern, der an eine bestimmte Gruppe von Geräten übermittelt wird oder der das Netzwerk durchläuft.

Traditionell wird diese Art von Filter von Firewalls verwendet. In einigen Fällen kann es jedoch von Vorteil sein, diesen Filter auf ein Cisco IOS-Gerät im Netzwerk anzuwenden. Ein Beispiel hierfür wäre, dass eine Filterung angewendet werden muss, aber keine Firewall vorhanden ist.

tACLs eignen sich auch zum Implementieren statischer Maßnahmen zum Schutz vor Spoofing.

Weitere Informationen finden Sie im Abschnitt Anti-Spoofing-Schutz.

Weitere Informationen zu tACLs finden Sie bei den Hinweisen zu Transit-Zugriffskontrolllisten: Filtern am Edge.

ICMP-Paket-Entstörung

Das Internet Control Message Protocol (ICMP) war als Steuerprotokoll für IP konzipiert. Dementsprechend können die über dieses Protokoll vermittelten Nachrichten erhebliche Auswirkungen auf die TCP- und IP-Protokolle im Allgemeinen haben. Das ICMP wird von den Tools ping und traceroutezur Fehlerbehebung im Netzwerk sowie von der MTU-Pfaderkennung verwendet. Externe ICMP-Verbindungen werden jedoch selten benötigt, um einen ordnungsgemäßen Netzwerkbetrieb zu gewährleisten.

Cisco IOS-Software liefert Funktionalität, um ICMP-Meldungen speziell namentlich zu filtern oder zu schreiben und zu codieren. Die folgende Beispiel-ACL ermöglicht ICMP aus vertrauenswürdigen Netzwerken, während alle ICMP-Pakete aus anderen Quellen blockiert werden:

!

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
!

Filter IP-Fragmente

Wie zuvor in diesem Dokument im Abschnitt Beschränken des Zugriffs auf das Netzwerk mit Infrastruktur-ACLs beschrieben, kann der Filter für fragmentierte IP-Pakete eine Herausforderung für Sicherheitsgeräte darstellen.

Aufgrund der nicht intuitiven Kontrolle von Fragmenten werden IP-Fragmente häufig versehentlich durch ACLs zugelassen. Fragmentierung ist auch in den Versuchen, Entdeckung durch EindringenErfassungssysteme auszuweichen häufig benutzt. Aus diesen Gründen werden IP-Fragmente häufig in Angriffen verwendet und können zusätzlich zu den konfigurierten iACLs explizit gefiltert werden. Diese Beispiel-ACL beinhaltet einen umfassenden Filter für IP-Fragmente. Die Funktionen aus diesem Beispiel müssen in Verbindung mit den Funktionen aus den vorherigen Beispielen verwendet werden:

!

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
!

Siehe Zugriffskontrolllisten und IP-Fragmente zu mehr Information über, wie ACL zersplitterte IP-Pakete handhabt.

ACL-Unterstützung für das Filtern von IP-Optionen

Ab Version 12.3(4)T unterstützt die Cisco IOS-Software die Verwendung von ACLs zum Filtern von IP-Paketen anhand der im Paket enthaltenen IP-Optionen. Das Vorhandensein von IP-Optionen in einem Paket kann auf den Versuch hindeuten, Sicherheitskontrollen im Netzwerk zu untergraben oder die Transit-Eigenschaften eines Pakets anderweitig zu ändern. Deshalb wird empfohlen, Pakete mit IP-Optionen am Netzwerk-Edge zu filtern.

Verwenden Sie dieses Beispiel zusammen mit den Inhalten der vorherigen Beispiele, um einen vollständigen Filter für IP-Paketen mit enthaltenen IP-Optionen einzubeziehen:

!

ip access-list extended ACL-TRANSIT-IN
!
!--- Deny IP packets containing IP options
!

 deny ip any any option any-options
!

Anti-Spoofing Schutze

Gebrauchsquellip address vieler Angriffe, das, um effektiv zu sein- spoofing ist oder die wahre Quelle eines Angriffs zu verbergen und genauen Traceback zu hindern. Die Cisco IOS-Software bietet Unicast RPF und IP Source Guard (IPSG) zur Abwehr von Angriffen, die auf Spoofing der Quell-IP-Adresse beruhen. Darüber hinaus wird ACLs und ungültige Wegewahl häufig als manuelle Durchschnitte von spoofing Verhinderung eingesetzt.

IPSG soll Spoofing für Netzwerke minimieren, die durch Verifizierung des Switch-Ports, der MAC-Adresse und der Quelladresse unter direkter administrativer Kontrolle stehen. Unicast RPF ermöglicht die Verifizierung des Quellnetzwerks und kann Spoofing-Angriffe von Netzwerken reduzieren, die nicht unter direkter administrativer Kontrolle stehen. Port-Sicherheit kann verwendet werden, um MAC-Adressen in der Zugriffsschicht zu validieren. Dynamische Inspektion des Address- Resolution Protocol(ARP) (DAI) schwächt Angriffsvektoren ab, die ARP-Vergiftung auf lokalen Segmenten verwenden.

Unicast RPF

Mithilfe von Unicast RPF kann ein Gerät überprüfen, ob die Quelladresse eines weitergeleiteten Pakets über die Schnittstelle erreichbar ist, von der das Paket empfangen wurde. Verlassen Sie sich nicht auf Unicast RPF als einzigen Schutz vor Spoofing. Spoofed Pakete konnten das Netz durch eine Unicast RPF-aktivierte Schnittstelle eintragen, wenn ein passender Rückholweg zum Quellip address existiert. Unicast RPF beruht auf Ihnen, um Eilbeförderung Ciscos auf jedem Gerät zu aktivieren und wird auf einer Proschnittstellenbasis konfiguriert.

Unicast RPF kann in einem von zwei Modi konfiguriert werden: „Loose“ (locker) oder „Strict“ (streng). In den Fällen wo es asymetrische Wegewahl gibt, wird loser Modus bevorzugt, weil strenger Modus bekannt, um Pakete in diesen Situationen fallenzulassen. Während der Konfiguration des ip verify Schnittstellenkonfigurationsbefehls wird der Loose-Modus mit dem Schlüsselwort any rx konfiguriert, während der strikte Modus konfiguriert wird.

Dieses Beispiel veranschaulicht Konfiguration dieses Merkmals:

!

ip cef
!

interface <interface>
  ip verify unicast source reachable-via <mode>
!

Siehe Verständnis des Rückpfad-Versendens Unicast zu mehr Information über die Konfiguration und den Gebrauch Unicast RPF.

IP-Quellschutz

IP-Quellschutz ist- effektive Durchschnitte von spoofing Verhinderung, die verwendet werden kann, wenn Sie Steuerung über Schnittstellen der Schicht 2 haben. IP Source Guard verwendet Informationen aus dem DHCP-Snooping, um an der Layer-2-Schnittstelle dynamisch eine Port-ACL (PACL) zu konfigurieren und jeglichen Datenverkehr von IP-Adressen zu verweigern, die in der IP-Quellbindungstabelle nicht zugeordnet sind.

IP Source Guard kann auf Layer-2-Schnittstellen angewendet werden, die zu DHCP-Snooping-fähigen VLANs gehören. Diese Befehle aktivieren DHCP-Herumschnüffeln:

!

ip dhcp snooping
ip dhcp snooping vlan <vlan-range>
!

Nachdem DHCP-Herumschnüffeln aktiviert ist, aktivieren diese Befehle IPSG:

!
interface <interface-id>
   ip verify source 
!

Die Port-Sicherheit kann mithilfe des Befehls für die Tip verify source port security Schnittstellenkonfiguration aktiviert werden. Dies erfordert den globalen Konfigurationsbefehl ip dhcp snooping information option; zusätzlich, der DHCP-Server muss die DHCP-Option 82 unterstützen.

Sprechen Sie konfigurierende DHCP-Merkmale und IP-Quellschutz zu mehr Information über dieses Merkmal an.

Kanal-Sicherheit

Port-Sicherheit wird verwendet, um MAC-Adress-Spoofing an der Zugangsschnittstelle zu minimieren. Kanal-Sicherheit kann dynamisch gelehrte (klebrige) MAC-Adressen verwenden, um in der Erstkonfiguration nachzulassen. Sobald Kanalsicherheit eine MAC-Verletzung bestimmt hat, kann sie einen von vier Verletzungsmodi verwenden. Diese Modi lauten „protect“ (schützen), „restrict“ (einschränken), „shutdown“ (abschalten) und „shutdown VLAN“ (VLAN abschalten). In den Fällen, in denen ein Port nur Zugriff für eine einzelne Workstation unter Verwendung von Standardprotokollen bietet, kann eine maximale Anzahl von 1 ausreichen. Protokolle wie HSRP, bei denen virtuelle MAC-Adressen genutzt werden, funktionieren nicht, wenn die maximale Anzahl auf 1 gesetzt ist.

!

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>
!

Sprechen Sie konfigurierende Kanal-Sicherheit zu mehr Information über das Kanal-Sicherheit confuration an.

Dynamische ARP-Inspektion

Mithilfe von DAI (Dynamic ARP Inspection) können Sie das Risiko von ARP-Poisoning-Angriffen auf lokale Segmente mindern. Ein arp-Vergiftungsangriff ist eine Methode, in der ein Angreifer gefälschte ARP-Informationen zu einem lokalen Segment schickt. Diese Informationen sollen den ARP-Cache anderer Geräte beschädigen. ARP-Poisoning wird oft für Man-in-the-Middle-Angriffe eingesetzt.

DAI fängt ab und validiert das IP-zu-MAC-Adress-Verhältnis aller ARP-Pakete auf untrusted Kanälen. In DHCP-Umgebungen verwendet DAI die Daten, die durch das herumschnüffelnde Merkmal DHCP festgelegt wird. ARP-Pakete, die an vertrauenswürdigen Schnittstellen empfangen werden, werden nicht validiert. Ungültige Pakete an nicht vertrauenswürdigen Schnittstellen werden verworfen. In den Umgebungen NichtdHCP wird der Gebrauch ARP ACLs benötigt.

Diese Befehle aktivieren DHCP-Herumschnüffeln:

!
ip dhcp snooping
ip dhcp snooping vlan <vlan-range>
!

Sobald DHCP-Herumschnüffeln aktiviert worden ist, aktivieren diese Befehle DAI:

!
ip arp inspection vlan <vlan-range> 
!

In Nicht-DHCP-Umgebungen sind ARP-ACLs erforderlich, um DAI zu aktivieren. Dieses Beispiel zeigt die Grundkonfiguration von DAI mit ARP ACLs:

!

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 kann pro die gleichgültig wo unterstützte worden Schnittstellenbasis auch an aktiviert werden.

ip arp inspection limit rate <rate_value> burst interval <interval_value>

Sprechen Sie konfigurierende dynamische ARP-Inspektion zu mehr Information über an, wie man DAI konfiguriert.

Anti-Spoofing ACLs

Manuell konfiguriertes ACLs kann statischen anti-spoofing Schutz gegen Angriffe bieten, die bekannten unbenutzten und untrusted Adressbereich benutzen. Geläufig werden diese, die ACLs anti-spoofing sind, am Eintrittverkehr an den Netzgrenzen als Komponente eines größeren ACL angewendet. ACLs zum Schutz vor Spoofing erfordern regelmäßige Monitoring-Intervalle, da sie sich häufig ändern können. Spoofing kann im Verkehr herabgesetzt werden, der vom lokalen Netzwerk (LAN) entsteht, wenn Sie Auslands-ACLs anwenden, das den Verkehr auf gültige lokale Adressen begrenzen.

Dieses Beispiel zeigt, wie Sie mithilfe von ACLs IP-Spoofing einschränken können. Dieser ACL ist auf der gewünschten Schnittstelle angewandtes Inlands. Die Asse, die diesen ACL bilden, sind nicht umfassend. Wenn Sie diese Arten von ACLs konfigurieren, bemühen Sie sich um eine aktuelle, vollständige Referenz.

!

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
!

Sprechen Sie konfigurierendes allgemein verwendetes IP ACLs zu mehr Information über an, wie man Zugriffskontrolllisten konfiguriert.

Die amtliche Börsennotierung von nicht zugewiesenen Internet-Adressen wird von Team Cymru beibehalten. Weitere Informationen dazu, wie Sie nicht verwendete Adressen filtern, finden Sie auf der Seite zur Bogon-Referenz.

Grenze-CPU-Auswirkung des Daten-Flächen-Verkehrs

Der Hauptzweck von Routern und von Schaltern ist, Pakete und Felder durch das Gerät zu den endgültigen Bestimmungsorts vorwärts nachzuschicken. Diese Pakete, die die Geräte durchfahren, setzten während des Netzes, können CPU-Operationen eines Gerätes auswirken ein. Schützen Sie die Datenebene, die aus Datenverkehr besteht, der das Netzwerkgerät durchläuft, um den Betrieb der Management- und Kontrollebene sicherzustellen. Wenn der Transitdatenverkehr dazu führen kann, dass ein Gerät Switch-Datenverkehr verarbeitet, kann die Kontrollebene eines Geräts beeinträchtigt werden, was zu einer Betriebsunterbrechung führt.

Merkmale und Verkehrs-Typen, die die CPU auswirken

Diese Liste ist zwar nicht vollständig, umfasst jedoch Datenverkehrstypen, die eine spezielle CPU-Verarbeitung erfordern und von der CPU per Process Switching verarbeitet werden:

• ACL-Protokollierung: ACL-Protokolldatenverkehr besteht aus allen Paketen, die aufgrund einer Übereinstimmung (Zulassen/Ablehnen) mit einem ACE generiert werden, in dem das Schlüsselwort log verwendet wird.
  
  
• Unicast RPF: Unicast RPF kann, wenn es mit einer ACL verwendet wird, dazu führen, dass für bestimmte Pakete Process Switching erfolgt.
  
  
• IP-Optionen - Alle mögliche IP-Pakete mit den eingeschlossenen Optionen müssen durch die CPU verarbeitet werden.
  
  
• Fragmentierung - Jedes mögliches IP-Paket, das Fragmentierung benötigt, muss zur CPU für die Verarbeitung geführt werden.
  
  
• Ende des Time- to Live(TTL) - Pakete, die einen TTL-Wert weniger als oder Gleichgestelltes bis 1 Internet- Control Message Protocolzeit fordern lassen, überstiegen (ICMP-Typ 11, Code 0) die gesendet zu werden Meldungen, das CPUverarbeitung ergibt.
  
  
• ICMP-Nichterreichbarkeitspakete: Pakete, die aus Routing-, MTU- oder Filtergründen in Nachrichten zur ICMP-Nichterreichbarkeit resultieren, werden von der CPU verarbeitet.
  
  
• Datenverkehr, der eine ARP-Anforderung erfordert - Ziele, für die kein ARP-Eintrag vorhanden ist, werden von der CPU verarbeitet.
  
  
• Verkehr Nicht-IP - Aller Verkehr NichtiP wird durch die CPU verarbeitet.

Weitere Informationen über die Datenebenensicherung finden Sie im Abschnitt Allgemeine Datenebenensicherung.

Filter auf TTL-Wert

Sie können die mit Cisco IOS Software 12.4(2)T eingeführte Funktion zur ACL-Unterstützung für die Filterung nach TTL-Wert in einer erweiterten IP-Zugriffsliste zum Filtern von Paketen anhand des TTL-Werts nutzen. Mit dieser Funktion können Sie Geräte schützen, die Transitdatenverkehr empfangen, bei dem der TTL-Wert 0 oder 1 beträgt. Das Filtern von Paketen anhand der TTL-Werte kann auch verwendet werden, um sicherzustellen, dass der TTL-Wert nicht kleiner ist als der Durchmesser des Netzwerks. So wird die Kontrollebene der Downstream-Infrastrukturgeräte vor TTL-Ablauf-Angriffen geschützt.

Einige Anwendungen und Tools, z. B., traceroute verwenden TTL-Ablaufpakete für Test- und Diagnosezwecke. Einige Protokolle, wie IGMP, verwenden legitim einen TTL-Wert von einem.

Dieses ACL-Beispiel erstellt eine Politik dieses Filter IP-Pakete, wo der TTL-Wert kleiner als 6. ist.

!
!--- 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 
!

Weitere Informationen dazu, wie Sie Pakete anhand des TTL-Werts filtern, finden Sie im Dokument zum Thema Erkennung und Verhinderung von TTL-Ablauf-Angriffen.

Siehe ACL-Support für die Entstörung auf TTL-Wert zu mehr Information über dieses Merkmal.

Im Cisco IOS-Software-Release 12.4(4)T und im neueren, flexiblen Paket erlaubt das Abgleichen (FPM) einem Verwalter, auf willkürlichen Bits eines Pakets abzugleichen. Durch diese FPM-Richtlinie werden Pakete mit einem TTL-Wert von weniger als 6 verworfen.

!

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
!

Filter auf dem Vorhandensein von IP-Optionen

In Cisco IOS-Software ab Version 12.3(4)T können Sie die ACL-Unterstützung für die Funktion zum Filtern von IP-Optionen in einer benannten erweiterten IP-Zugriffsliste verwenden, um IP-Pakete mit vorhandenen IP-Optionen zu filtern. Das Filtern von IP-Paketen nach Vorhandensein von IP-Optionen kann auch verwendet werden, damit die Kontrollebene von Infrastrukturgeräten diese Pakete nicht auf CPU-Ebene verarbeiten muss.

Die Funktion zur ACL-Unterstützung für die Filterung von IP-Optionen kann nur mit benannten erweiterten ACLs verwendet werden. RSVP, MPLS TE (Multiprotocol Label Switching Traffic Engineering), IGMP Version 2 und 3 sowie andere Protokolle, bei denen Pakete mit IP-Optionen verwendet werden, funktionieren nicht ordnungsgemäß, wenn Pakete für diese Protokolle verworfen werden. Wenn diese Protokolle im Netzwerk verwendet werden, kann die ACL-Unterstützung für die Filterung von IP-Optionen verwendet werden. Allerdings kann dieser Datenverkehr durch die Funktion zum selektiven Verwerfen von IP-Optionen mit ACLs verworfen werden, sodass diese Protokolle nicht ordnungsgemäß funktionieren. Wenn es keine gebräuchlichen Protokolle gibt, die IP-Optionen benötigen, ist ACL-IP-Options-selektiver Rückgang die bevorzugte Methode, zum dieser Pakete fallenzulassen.

Dieses ACL-Beispiel erstellt eine Politik dieses Filter IP-Pakete, die alle mögliche IP-Optionen enthalten:

!

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 
!

Dieses Beispiel ACL zeigt eine Politik dieses Filter IP-Pakete mit fünf spezifischen IP-Optionen. Pakete, die diese Optionen enthalten, werden verweigert:

• 0 Ende Options-Liste (eool)
  
  
• Rekordweg 7 (Satzweg)
  
  
• Stempel der Zeit-68 (Zeitstempel)
  
  
• 131 - Loser Quellweg (lsr)
  
  
• 137 - Strenger Quellweg (ssr)

!

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 
!

Weitere Informationen zum selektiven Verwerfen von IP-Optionen mit ACLs finden Sie in diesem Dokument im Abschnitt Allgemeines Härten der Datenebene.

Weitere Informationen dazu, wie Sie Transit- und Edge-Datenverkehr filtern, finden Sie bei den Hinweisen zu Transit-Zugriffskontrolllisten: Filtern am Edge.

Eine weitere Funktion in der Cisco IOS-Software, die zum Filtern von Paketen mit IP-Optionen verwendet werden kann, ist CoPP. Im Cisco IOS-Software-Release 12.3(4)T und später, erlaubt CoPP einem Verwalter, den Verkehrsprogrammablauf Flächenpakete zu filtern. Bei einem Gerät, das CoPP unterstützt und ACL-Unterstützung für die Filterung von IP-Optionen bietet (eingeführt mit Cisco IOS-Software 12.3(4)T), kann eine Zugriffslistenrichtlinie zum Filtern von Paketen mit enthaltenen IP-Optionen verwendet werden.

Diese CoPP-Politik lässt Durchfahrtpakete fallen, die durch ein Gerät empfangen werden, wenn alle mögliche IP-Optionen anwesend sind:

!

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
!

Diese CoPP-Politik lässt die Durchfahrtpakete fallen, die durch ein Gerät empfangen werden, wenn diese IP-Optionen anwesend sind:

• 0 Ende Options-Liste (eool)
  
  
• Rekordweg 7 (Satzweg)
  
  
• Stempel der Zeit-68 (Zeitstempel)
  
  
• Loser Weg des Quell131 (lsr)
  
  
• Strenger Weg des Quell137 (ssr)

!

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
!

Bei den zuvor beschriebenen CPPr-Richtlinien führen die ACL-Einträge (Access Control List Entries, ACEs), durch die Pakete mit der „permit“-Aktion abgeglichen werden, zum Verwerfen dieser Pakete durch die „policy-map“-Funktion „drop“. Pakete, die zur „deny“-Aktion passen (nicht gezeigt), sind dagegen nicht von der „policy-map“-Funktion „drop“ betroffen.

Steuern Sie flachen Schutz

In Cisco IOS-Software ab Version 12.4(4)T kann die Funktion zum Schutz der Kontrollebene (Control Plane Protection, CPPr) verwendet werden, um den von der CPU eines Cisco IOS-Geräts ausgehenden Datenverkehr auf der Kontrollebene einzuschränken oder zu kontrollieren. Ähnlich wie mit CoPP lässt sich der Datenverkehr auch mit CPPr präziser einschränken oder mittels Richtlinien steuern. Bei CPPr wird die aggregierte Kontrollebene in drei getrennte Kontrollebenenkategorien aufgeteilt, die als Unterschnittstellen bezeichnet werden: Host, Transit und CEF-Exception.

Diese CPPr-Politik lässt die Durchfahrtpakete fallen, die durch ein Gerät empfangen werden, in dem der TTL-Wert kleiner als 6 und die Durchfahrt- oder Nichtdurchfahrtpakete, die durch ein Gerät empfangen werden ist, in dem der TTL-Wert null oder eins ist. Die CPPr-Politik lässt auch Pakete mit ausgewählten IP-Optionen fallen, die durch das Gerät empfangen werden.

!

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
!

Bei der obigen CPPr-Richtlinie führten die ACL-Einträge, durch die Pakete mit der „permit“-Aktion abgeglichen wurden, zum Verwerfen dieser Pakete durch die „policy-map“-Funktion „drop“. Pakete, die zur „deny“-Aktion passten (nicht gezeigt), waren dagegen nicht von der „policy-map“-Funktion „drop“ betroffen.

Siehe Verständnis des Steuerflachen Schutzes und steuern Sie flachen Schutz zu mehr Information über das CPPr-Merkmal.

Handeln Sie Kennzeichen und Traceback

Manchmal können Sie und Tracebacknetzwerkverkehr, besonders während der Vorfallantwort oder der schlechten Netzwerk-Performance schnell identifizieren müssen. NetFlow und Klassifizierungs-ACLs sind die beiden Hauptmethoden, um dies mit der Cisco IOS-Software zu erreichen. NetFlow kann Sicht in allen Verkehr auf dem Netz zur Verfügung stellen. Zusätzlich kann NetFlow mit Kollektoren eingeführt werden, die das Neigen der Zeitdauer und automatisierte Analyse zur Verfügung stellen können. Klassifikation ACLs sind eine Komponente von ACLs und benötigen das Im Voraus planen, zum des spezifischen Verkehrs und der manuellen Intervention während der Analyse zu identifizieren. Diese Kapitel liefern einen kurzen Überblick über jedes Merkmal.

NetFlow

NetFlow erkennt anomale und sicherheitsrelevante Netzwerkaktivitäten durch die Verfolgung von Netzwerk-Flows. NetFlow-Daten können über die CLI angezeigt und analysiert werden. Alternativ können Sie die Daten zur Aggregation und Analyse in einen kommerziellen oder Freeware-NetFlow-Collector exportieren. NetFlow-Collectors können langfristige Trends ermitteln und so Analysen des Netzwerkverhaltens und der Netzwerknutzung bereitstellen. NetFlow führt Analysen zu bestimmten Attributen in IP-Paketen durch und erstellt Flows. Version 5 ist die am häufigsten verwendete Version von NetFlow, jedoch lässt sich Version 9 besser erweitern. NetFlow-Flüsse können mit geprüften Verkehrsdaten in den Großserienumgebungen erstellt werden.

CEF oder Distributed CEF ist eine Voraussetzung für die Aktivierung von NetFlow. NetFlow kann auf Routern und Schaltern konfiguriert werden.

Das folgende Beispiel zeigt die grundlegende Konfiguration von NetFlow. In früheren Versionen der Cisco IOS-Software wurde der Befehl zum Aktivieren von NetFlow auf einer Schnittstelle ip route-cache flow anstelle von ip flow {ingress | egress}.

!

ip flow-export destination <ip-address> <udp-port>
ip flow-export version <version>
!

interface <interface> 
 ip flow <ingess|egress> 
!

Dieses ist ein Beispiel von NetFlow ausgab vom CLI. Das SrcIf-Attribut kann im Traceback helfen.

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

Siehe Cisco IOS NetFlow zu mehr Information über NetFlow-Fähigkeiten.

Sprechen Sie eine Einleitung zu Cisco IOS NetFlow - ein technischer Überblick für einen technischen Überblick über NetFlow an.

Klassifikation ACLs

Klassifikation ACLs stellen Sicht in Verkehr zur Verfügung, der eine Schnittstelle überquert. Klassifikation ACLs ändern nicht die Sicherheitspolitik eines Netzes und werden gewöhnlich konstruiert, um einzelne Protokolle, Quelladressen oder Zieleinheiten zu klassifizieren. Zum Beispiel könnte ACE, der allen Verkehr ermöglicht, in spezifische Protokolle oder in Kanäle getrennt werden. Diese differenziertere Klassifizierung des Datenverkehrs in bestimmte ACEs kann Einblicke in den Netzwerkverkehr vermitteln, da jede Datenverkehrskategorie über einen eigenen Zugriffszähler verfügt. Admins können auch die implizite Ablehnung am Ende einer ACL in feiner abgestufte ACEs unterteilen, um die Art des abgelehnten Datenverkehrs zu identifizieren.

Administratoren können die Reaktion auf Vorfälle beschleunigen, indem sie Klassifizierungs-ACLs mit den Befehlen show access-list und clear ip access-list counters EXEC verwenden.

Das folgende Beispiel zeigt die Konfiguration einer Klassifizierungs-ACL zum Identifizieren von SMB-Datenverkehr vor einer standardmäßigen Ablehnung:

!

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 
!

Um den Datenverkehr zu identifizieren, der eine Klassifizierungs-ACL verwendet, verwenden Sie den show access-list EXEC Befehl. Die ACL-Zähler können mit dem clear ip access-list counters EXEC Befehl gelöscht werden.

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) 

Weitere Informationen dazu, wie Sie die Protokollfunktionen in ACLs aktivieren, finden Sie bei den Informationen zur ACL-Protokollierung.

Zugriffssteuerung mit VLAN-Karten und Kanal-Zugriffskontrolllisten

VLAN-Zugriffskontrolllisten (VACLs) oder VLAN-Karten und Kanal ACLs (PACLs), liefern die Fähigkeit, um Zugriffssteuerung auf nicht-verlegtem Verkehr zu erzwingen, der näher an Endpunktgeräten als Zugriffskontrolllisten ist, die an verlegten Schnittstellen angewendet werden.

Die folgenden Abschnitte vermitteln einen Überblick über die Funktionen, Vorteile und potenziellen Nutzungsszenarien von VACLs und PACLs.

Zugriffssteuerung mit VLAN-Karten

Mithilfe von VACLs oder VLAN-Zuordnungen, die für alle in das VLAN gelangenden Pakete gelten, kann die Zugriffskontrolle für den Datenverkehr innerhalb des VLAN durchgesetzt werden. Dieses ist nicht mit ACLs auf verlegten Schnittstellen möglich. So kann beispielsweise eine VLAN-Zuordnung verwendet werden, um die Kommunikation zwischen Hosts, die sich im selben VLAN befinden, zu verhindern. Dies verringert die Gelegenheiten für lokale Angreifer oder Würmer, einen Host im gleichen Netzwerksegment auszunutzen. Um zu verhindern, dass Pakete eine VLAN-Zuordnung nutzen, erstellen Sie eine Zugriffskontrollliste (Access Control List, ACL), die den Datenverkehr abgleicht, und legen Sie in der VLAN-Zuordnung „drop“ als Aktion fest. Sobald eine VLAN-Karte konfiguriert wird, werden alle Pakete, die den LAN eintragen, sequenziell gegen die konfigurierte VLAN-Karte ausgewertet. VLAN-Zugriffszuordnungen unterstützen IPv4- und MAC-Zugriffslisten. Sie unterstützen jedoch keine Protokolle oder IPv6-ACLs.

Dieses Beispiel benutzt eine ausgedehnte benannte Zugriffsliste, die die Konfiguration dieses Merkmals veranschaulicht:

!

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>
!

Das folgende Beispiel veranschaulicht die Verwendung einer VLAN-Zuordnung zum Ablehnen der TCP-Ports 139 und 445 und des vines-ip-Protokolls:

!

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 
!

Sprechen Sie konfigurierende Netzwerksicherheit mit ACLs zu mehr Information über die Konfiguration von VLAN-Karten an.

Zugriffssteuerung mit PACLs

PACLs kann an der Inlandsrichtung auf körperliche Schnittstellen der Schicht 2 eines Schalters nur angewendet werden. Ähnlich VLAN-Karten, stellen PACLs Zugriffssteuerung auf nicht-verlegt zur Verfügung oder überlagern Verkehr 2. Die Syntax für PACLs-Schaffung, die Vorrang vor VLAN-Karten und Router ACLs hat, ist die selbe wie Router ACLs. Wenn ein ACL an einer Schnittstelle der Schicht 2 angewendet wird, dann gekennzeichnet es als ein PACL. Konfiguration bezieht die Schaffung eines IPv4, des IPv6 oder des MAC ACL und der Anwendung von ihr zur Schnittstelle der Schicht 2 mit ein.

Im folgenden Beispiel wird eine erweiterte benannte Zugriffsliste verwendet, um die Konfiguration dieser Funktion zu veranschaulichen:

!

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 
!

Sprechen Sie das Kanal ACL-Kapitel des Konfigurierens von Netzwerksicherheit mit ACLs zu mehr Information über die Konfiguration von PACLs an.

Zugriffssteuerung mit MAC

MAC-Zugriffskontrolllisten oder erweiterte Listen können im IP-Netzwerk mit folgendem Befehl im Modus zur Schnittstellenkonfiguration angewendet werden:

Cat6K-IOS(config-if)#mac packet-classify

Hinweis: Mit MAC-Zugriffskontrolllisten werden Layer-3-Pakete als Layer-2-Pakete klassifiziert. Der Befehl wird in Cisco IOS-Software-Release 12.2(18)SXD (für Sup 720) und Cisco IOS Software-Releases 12.2(33)SRA oder später unterstützt.

Dieser Schnittstellenbefehl muss auf die Ingress-Schnittstelle angewendet werden und weist die Weiterleitungs-Engine an, den IP-Header nicht zu überprüfen. So können Sie eine MAC-Zugriffsliste in der IP-Umgebung verwenden.

Privater VLAN-Gebrauch

Private VLANs (PVLANs) sind eine Layer-2-Sicherheitsfunktion, die die Netzwerkverbindungen zwischen den Workstations oder Servern in einem VLAN begrenzt. Ohne PVLANs können alle Geräte auf einer Schicht 2 VLAN frei in Verbindung stehen. Es gibt Netzwerksituationen, in denen die Sicherheit durch die Begrenzung der Kommunikation zwischen Geräten innerhalb eines VLAN erhöht werden kann. PVLANs werden beispielsweise häufig verwendet, um die Kommunikation zwischen Servern in einem öffentlich zugänglichen Subnetz zu unterbinden. Wenn ein einzelner Server kompromittiert wird, kann eine weitere Verbreitung besser verhindert werden, wenn keine Netzwerkverbindungen zu anderen Servern bestehen.

Es gibt drei Arten von privaten VLANs: isolierte VLANs, Community-VLANs und primäre VLANs. Die Konfiguration von PVLANs nutzt Primär- und Sekundär-VLANs aus. Primär- VLAN enthält alle gemischten Kanäle, die später beschrieben werden, und enthält ein oder mehreres Sekundär-VLANs, das entweder lokalisiert werden kann oder Gemeinschaft VLANs.

Lokalisiertes VLANs

Die Konfiguration eines sekundären VLAN als isoliertes VLAN verhindert die Kommunikation zwischen Geräten im sekundären VLAN vollständig. Es kann nur ein isoliertes VLAN pro primärem VLAN geben, und nur Ports für alle Schnittstellen können mit Ports in einem isolierten VLAN kommunizieren. Isolierte VLANs können in nicht vertrauenswürdigen Netzwerken verwendet werden, beispielsweise in Netzwerken mit Unterstützung für Gastzugriff.

Dieses Konfigurationsbeispiel konfiguriert VLAN 11 als lokalisiertes VLAN und verbindet es zu Primär-VLAN, VLAN 20. Außerdem wird im folgenden Beispiel die Schnittstelle „FastEthernet 1/1“ als isolierter Port in VLAN 11 konfiguriert:

!

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
!

Gemeinschaft VLANs

Ein sekundäres VLAN, das als Community-VLAN konfiguriert ist, ermöglicht die Kommunikation zwischen Mitgliedern des VLANs sowie mit sämtlichen Ports für alle Schnittstellen im primären VLAN. Jedoch ist keine Kommunikation zwischen jeder möglicher zwei Gemeinschaft VLANs oder von einer Gemeinschaft VLAN zu lokalisierten VLAN möglich. Community-VLANs müssen verwendet werden, um Server zu gruppieren, für die eine Verbindung miteinander erforderlich ist, jedoch keine Verbindung zu allen anderen Geräten im VLAN. Dieses Szenario ist in einem öffentlich zugänglichen Netzwerk oder überall dort typisch, wo Server Inhalte für nicht vertrauenswürdige Clients bereitstellen.

Dieses Beispiel konfiguriert eine einzelne Gemeinschaft VLAN und konfiguriert Schalterkanal FastEthernet 1/2 als Bauteil von diesem VLAN. Die Gemeinschaft VLAN, VLAN 12, ist Sekundär-VLAN zu Primär-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
!

Gemischte Kanäle

Switch-Ports, die im primären VLAN platziert werden, werden als „Promiscuous-Ports“ (Ports für alle Schnittstellen) bezeichnet. Promiscuous-Ports können mit allen anderen Ports in den primären und sekundären VLANs kommunizieren. Router- oder Firewallschnittstellen sind die geläufigsten Geräte, die auf diesen VLANs gefunden werden.

Dieses Konfigurationsbeispiel kombiniert die vorhergehenden lokalisierten und Gemeinschafts-VLAN-Beispiele und fügt die Konfiguration der Schnittstelle FastEthernet 1/12 als gemischter Kanal hinzu:

!

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
!

Beim Implementieren von PVLANs müssen Sie sicherstellen, dass die Layer-3-Konfiguration die durch PVLANs auferlegten Einschränkungen unterstützt und es nicht möglich ist, die PVLAN-Konfiguration zu untergraben. Ein Layer-3-Filter mit einer Router-ACL oder Firewall kann die Umgehung der PVLAN-Konfiguration verhindern.

Sprechen Sie privates VLANs an (PVLANs) - Gemischt, lokalisiert, Gemeinschaft, lokalisiert auf dem LAN Security-homepage, zu mehr Information über den Gebrauch und die Konfiguration von privatem VLANs.

Schlussfolgerung

In diesem Dokument erhalten Sie einen umfassenden Überblick über Methoden, mit denen Sie ein Cisco IOS-Systemgerät schützen können. Wenn Sie die Geräte schützen, erhöht dies die Sicherheit der von Ihnen gemanagten Netzwerke insgesamt. In diesem Überblick werden Schutz des Managements, Steuerung, und Datenflächen wird behandelt, und Empfehlungen für Konfiguration geliefert. Wo möglich wird genügendes Detail für die Konfiguration jedes verbundenen Merkmals bereitgestellt. Jedoch in allen Fällen, werden umfassende Referenzen zur Verfügung gestellt, um Sie mit den Informationen zur Verfügung zu stellen, die für weitere Bewertung benötigt werden.

Quittungen

Einige Merkmalsbeschreibungen in diesem Dokument wurden von den Cisco-Informationsentwicklerteams geschrieben.

Anhang: Checkliste für die Cisco IOS-Gerätehärtung

Diese Checkliste ist eine Zusammenfassung aller in diesem Leitfaden vorgestellten Härtungsschritte. Verwalter können sie verwenden, während eine Anzeige der ganzer Verhärtung verwendet und für ein Cisco IOS-Gerät betrachtet kennzeichnet, selbst wenn ein Merkmal nicht eingeführt wurde, weil es nicht zutraf. Verwalter werden geraten, jede Option für sein potenzielles Risiko auszuwerten, bevor sie die Option einführen.

Management-Fläche

• Passwörter
  
  
  • Aktivieren Sie Hashing MD5 (geheime Option) für aktivieren und lokale Benutzerpasswörter
  • Konfigurieren Sie die Passwortwiederholungsaussperrung
  • Deaktivieren Sie Passwortwiederanlauf (betrachten Sie Risiko)
    
    
• Deaktivieren Sie unbenutzte Dienstleistungen
  
  
• Konfigurieren Sie TCP-Keepalives für Managementsitzungen
  
  
• Stellen Sie Speicher- und CPU-Schwellwertmitteilungen ein
  
  
• Konfigurieren
  
  
  • Speicher- und CPU-Schwellwertmitteilungen
  • Reservespeicher für Konsolenzugriff
  • Speicherleckdetektor
  • Buffersammelentdeckung
  • Erhöhte crashinfo Sammlung
    
    
• Benutzen Sie iACLs, um Managementzugriff einzuschränken
  
  
• Filtern Sie (betrachten Sie Risiko)
  
  
  • ICMP-Pakete
  • IP-Fragmente
  • IP-Optionen
  • TTL-Wert in den Paketen
    
    
• Steuern Sie flachen Schutz
  
  
  • Portfilterung konfigurieren
  • Konfigurieren Sie Warteschlangenschwellwerte
    
    
• Managementzugriff
  
  
  • Verwenden Sie Management-flachen Schutz, um Managementschnittstellen einzuschränken
  • Stellen Sie Leitprogrammunterbrechung ein
  • Verwenden Sie ein verschlüsseltes Ende-zu-Ende-Transportprotokoll (wie SSH) für CLI-Zugriff
  • Steuern Sie Transport für vty und tty zeichnet (Zugriffsklassenoption)
  • Anhand von Bannern warnen
    
    
• AAA
  
  
  • Benutzen Sie AAA für Authentisierung und Reserve
  • Benutzen Sie AAA (TACACS+) für Befehlsermächtigung
  • AAA für Kontozwecke verwenden
  • Benutzen Sie überflüssige AAA-Servers
    
    
• SNMP
  
  
  • Konfigurieren Sie Gemeinschaften SNMPv2 und wenden Sie ACLs an
  • Konfigurieren Sie SNMPv3
    
    
• Protokollieren
  
  
  • Zentrale Protokollierung konfigurieren
  • Protokollierungsstufen für alle relevanten Komponenten festlegen
  • Quellschnittstelle für Protokollierung festlegen
  • Granularität der Protokollzeitstempel konfigurieren
    
    
• Konfigurationsverwaltung
  
  
  • Ersetzen Sie und Preissenkung
  • Exklusiver Konfigurations-Änderungs-Zugriff
  • Software-Beweglichkeitskonfiguration
  • Konfigurationsänderungsmitteilungen

Steuern Sie Fläche

• Deaktivieren Sie (betrachten Sie Risiko)
  
  
  • ICMP adressiert um
  • ICMP Unreachables
  • Proxy ARP
    
    
• NTP-Authentifizierung konfigurieren, wenn NTP verwendet wird
  
  
• Control Plane Policing/Schutz der Kontrollebene konfigurieren (Portfilter, Schwellenwerte für Warteschlangen)
  
  
• Sichern Sie Wegewahlprotokolle
  
  
  • BGP (TTL, MD5, maximale Vorzeichen, Vorzeichenlisten, Systempfad ACLs)
  • IGP (MD5, passive Schnittstelle, Routenfilter, Ressourcenverbrauch)
    
    
• Konfigurieren Sie Hardware-Kinetikbegrenzer
  
  
• Sichern Sie erste Hopfenredundanz-Protokolle (GLBP, HSRP, VRRP)

Daten-Fläche

• Konfigurieren Sie IP-Options-selektiven Tropfen
  
  
• Deaktivieren Sie (betrachten Sie Risiko)
  
  
  • IP-Quellrouten
  • IP verwiesene Sendungen
  • ICMP adressiert um
    
    
• Grenz-IP verwiesene Sendungen
  
  
• Konfigurieren Sie tACLs (betrachten Sie Risiko)
  
  
  • Filtern Sie ICMP
  • Filter IP-Fragmente
  • Filtern Sie IP-Optionen
  • Filtern Sie TTL-Werte
    
    
• Configure benötigte anti-spoofing Schutze
  
  
  • ACLs
  • IP-Quellschutz
  • Dynamische ARP-Inspektion
  • Unicast RPF
  • Kanalsicherheit
    
    
• Steuern Sie flachen Schutz (Steuerungflächencefausnahme)
  
  
• Konfigurieren Sie NetFlow und Klassifikation ACLs für Verkehrskennzeichen
  
  
• Configure benötigte Zugriffssteuerung ACLs (VLAN-Karten, PACLs, MAC)
  
  
• Konfigurieren Sie privates VLANs