Syslog

Under arbete . . . . . . .

Introduktion till Syslog
Att implementera en loggningsfunktion är en viktig del av alla nätverkssäkerhetspolicyer. När vissa händelser inträffar i ett nätverk har nätverksenheter pålitliga mekanismer för att meddela administratören med detaljerade systemmeddelanden. Dessa meddelanden kan vara icke-kritiska eller betydande, och det finns flera tillgängliga alternativ för att lagra, tolka och visa dem. Administratörer kan varnas för alla meddelanden eller bara de meddelanden som kan ha störst inverkan på nätverksinfrastrukturen.
Den vanligaste metoden för att komma åt systemmeddelanden från nätverksenheter är att använda ett protokoll som kallas syslog, vilket beskrivs i RFC 5424. Syslog använder User Datagram Protocol (UDP) port 514 för att skicka händelseaviseringsmeddelanden över IP-nätverk till händelsemeddelandeinsamlare, som visas i figuren.
Många nätverksenheter stöder syslog inklusive routrar, switchar, applikationsservrar, brandväggar och andra nätverksanslutna enheter. Syslog-loggningstjänsten tillhandahåller tre primära funktioner:
• Möjligheten att samla in loggningsinformation för övervakning och felsökning
• Möjligheten att välja vilken typ av logginformation som ska fångas
• Möjligheten att ange destinationer för infångade syslog-meddelanden
Syslog Operation
På Cisco-nätverksenheter börjar syslog-protokollet med att skicka systemmeddelanden och felsöka utdata till en lokal loggningsprocess som är intern i enheten. Hur loggningsprocessen hanterar och matar ut dessa meddelanden baseras på enhetskonfigurationer. Till exempel kan syslog-meddelanden skickas över nätverket till en extern syslog-server. Dessa meddelanden kan hämtas och sedan dras in i olika rapporter för enklare läsning.
Cisco-routrar kan logga information om konfigurationsändringar, ACL-överträdelser, gränssnittsstatus, CPU-användning och många andra typer av händelser. Använd till exempel de minnesfria tröskelvärdena io och minnesfria processorkommandon för lågvattenmärke för att ställa in minneströsklar. Routern kommer att skicka meddelanden, specificerade i kilobyte till syslog-servern när tillgängligt ledigt minne faller under tröskeln. Routern kommer att skicka aviseringar igen när det tillgängliga lediga minnet stiger till fem procent över tröskeln.
Cisco-routrar kan logga information om konfigurationsändringar, ACL-överträdelser, gränssnittsstatus och många andra typer av händelser. Cisco-routrar kan konfigureras för att skicka syslog-meddelanden till flera olika faciliteter, som visas i bilden:
• Loggningsbuffert – Meddelanden lagras i routerns minne under en viss tid. Händelser rensas dock när routern startas om.
• Konsol – Konsolloggning är aktiverat som standard. Syslog-meddelanden skickas till konsollinjen när administratören aktiverar gränssnittet.
• Terminallinjer – Aktiverade EXEC-sessioner kan konfigureras för att ta emot loggmeddelanden på alla terminallinjer.
• Syslog-server – Cisco-routrar kan konfigureras för att vidarebefordra loggmeddelanden till en extern syslog-tjänst.
Syslog meddelande
Cisco-enheter producerar syslog-meddelanden som ett resultat av nätverkshändelser. Varje syslog-meddelande innehåller en svårighetsgrad och en funktion.
De mindre numeriska nivåerna är de mer kritiska sysloglarmen. Meddelandenas svårighetsgrad kan ställas in för att styra var varje typ av meddelande visas (dvs på konsolen eller de andra destinationerna). Den fullständiga listan över syslog-nivåer visas i figur 1. Varje syslog-nivå har sin egen betydelse, som visas i figur 2.
Syslog-nivåerna noll till fyra är meddelanden om mjukvara eller hårdvarufunktionalitet. Problemets svårighetsgrad avgör den faktiska syslognivån som tillämpas. Syslog nivåer fem och sex är för aviseringar och informationsmeddelanden. Syslog nivå sju indikerar att meddelandena genereras genom att olika felsökningskommandon utfärdas.
Förutom att specificera svårighetsgraden innehåller syslog-meddelanden information om anläggningen. Syslog-faciliteter är tjänsteidentifierare som identifierar och kategoriserar systemtillståndsdata för fel- och händelsemeddelanderapportering. De loggningsmöjligheter som är tillgängliga är specifika för nätverksenheten.
Formatet för Cisco IOS syslog-meddelanden visas i figur 3.
Allvarlighetsnivåer
Syslog-system
Syslog-implementationer innehåller alltid två typer av system:
• Syslog-servrar – Även känd som loggvärdar, dessa system accepterar och bearbetar loggmeddelanden från syslog-klienter.
• Syslog-klienter – routrar eller annan typ av utrustning som genererar och vidarebefordrar loggmeddelanden till syslog-servrar.
Topologin i figuren identifierar syslog-servern vid IP-adress 10.2.2.6. Resten av servrarna och enheterna i topologin kan konfigureras som syslog-klienter, som skickar syslog-meddelanden till syslog-servern.
Konfigurera systemloggning
Konfigurera systemloggning:
Steg 1. Ställ in destinationsloggningsvärden med hjälp av loggningsvärdkommandot, som visas i figur 1.
Steg 2. (Valfritt) Ställ in loggens allvarlighetsgrad (fällan) med kommandot loggningsfälla, som visas i figur 2.
Steg 3. Ställ in källgränssnittet med kommandot loggning källgränssnitt, som visas i figur 3. Detta kommando anger att syslog-paket innehåller IPv4- eller IPv6-adressen för ett specifikt gränssnitt, oavsett vilket gränssnitt paketet använder för att lämna routern.
Steg 4. Aktivera inloggning till alla aktiverade destinationer med kommandot inloggning, som visas i figur 4.
Figur 5 visar syslog-referenstopologin. Figur 6 visar ett exempel på en syslog-konfiguration för R1. Använd kommandot show logging för att visa loggningskonfiguration och buffrade syslog-meddelanden.
Introduktion till SNMP
Ett annat vanligt övervakningsverktyg är SNMP (Simple Network Management Protocol). SNMP utvecklades för att administratörer ska kunna hantera enheter i ett IP-nätverk. Det gör det möjligt för nätverksadministratörer att övervaka nätverksprestanda, hantera nätverksenheter, felsöka nätverksproblem och planera för nätverkstillväxt.
SNMP består av tre element som är relevanta för Network Management System (NMS):
• SNMP-hanterare
• SNMP-agenter (hanterad nod)
• Management Information Base (MIB)
SNMP-hanterare och -agenter använder UDP för att utbyta information. Specifikt lyssnar SNMP-agenter på UDP-port 161 medan SNMP-hanterare lyssnar på UDP-port 162. SNMP-hanteraren kör SNMP-hanteringsprogramvara. Som visas i figuren kan SNMP-hanteraren samla in information från en SNMP-agent med hjälp av get-förfrågningar och kan ändra konfigurationer på en agent med hjälp av set requests-åtgärden. SNMP-agenten måste konfigureras för att ge åtkomst till den lokala MIB. Dessutom kan SNMP-agenter konfigureras för att vidarebefordra meddelanden (fällor) direkt till en SNMP-hanterare.
Management Information Base (MIB)
SNMP set, get och trap meddelanden har alla tillgång till att skapa och ändra informationen i MIB. Denna information är organiserad hierarkiskt så att SNMP snabbt kan komma åt den. Varje del av information inom MIB ges ett objekt-ID (OID). MIB organiserar OID baserat på RFC-standarder i en hierarki av OID, som visas i figur 1. Innebörden av var och en av nivåerna nere i trädet ligger utanför denna kurs. Observera dock att SNMP-meddelanden för Cisco-enheter lagras i MIB på följande platser: 1.3.6.1.4.1.9. Detta är bara ett exempel. MIB-trädet för en given enhet inkluderar grenar med variabler som är gemensamma för många nätverksenheter och grenar med variabler som är specifika för den enheten eller leverantören.
Cisco SNMP Object Navigator tillåter en nätverksadministratör att undersöka detaljer om ett visst OID. Figur 2 visar ett exempel på att fastställa att OID 1.3.6.1.2.1.4.21 är reserverad för en enhets routingtabell. Klicka här för att öppna Cisco SNMP Object Navigator.
Cisco MIB-hierarki
SNMP-versioner
Det finns flera versioner av SNMP:
• SNMPv1 – Definierat i RFC 1157; förutsatt att ingen autentisering eller krypteringsmekanism
• SNMPv2c – Definierat i RFC:er 1901 till 1908; förbättrats med SNMPv1 men tillhandahöll ingen autentiserings- eller krypteringsmekanism
• SNMPv3 – Definierat i RFC:er 2273 till 2275; ger säker åtkomst till enheter genom att autentisera och kryptera paket över nätverket
Säkerhetsmodelldetaljerna för varje version visas i figuren.
SNMP-sårbarheter
I vilken nätverkstopologi som helst bör minst en förvaltarnod köra SNMP-hanteringsprogramvara. Nätverksenheter som kan hanteras, såsom switchar, routrar, servrar och arbetsstationer, är utrustade med SNMP-agentprogramvarumodulen. Dessa agenter är ansvariga för att ge SNMP-hanteraren åtkomst till en lokal MIB, som lagrar data om enhetens funktion.
SNMP är sårbart för attacker just därför att SNMP-agenter kan pollas med get-förfrågningar och acceptera konfigurationsändringar med set-förfrågningar, som visas i figuren. Till exempel kan en uppsättningsbegäran få en router att starta om, skicka en konfigurationsfil eller ta emot en konfigurationsfil. En SNMP-agent kan också konfigureras för att skicka ut fällor eller meddelanden. I SNMPv1 och SNMPv2c är dessa förfrågningar och meddelanden inte autentiserade eller krypterade.
SNMPv3
SNMPv3 autentiserar och krypterar paket över nätverket för att ge säker åtkomst till enheter. Detta åtgärdade sårbarheterna i tidigare versioner av SNMP.
SNMPv3 har tre säkerhetsfunktioner:
• Meddelandeintegritet och autentisering – Säkerställer att ett paket inte har manipulerats under överföringen och kommer från en giltig källa, som visas i figur 1.
• Kryptering – Kryptar innehållet i ett paket för att förhindra att det ses av en obehörig källa, som visas i figur 2.
• Åtkomstkontroll – Begränsar varje huvudman till vissa åtgärder på specifika delar av data, som visas i figur 3.
SNMPv3-meddelandeintegritet och autentisering
Överföringar från chef till agent kan autentiseras för att garantera avsändarens identitet och integriteten och tidslinjerna för ett meddelande.
SNMPv3-kryptering
SNMPv3-meddelanden kan krypteras för att säkerställa integritet
SNMPv3 åtkomstkontroll
Agent kan genomdriva åtkomstkontroll för att begränsa varje huvudman till vissa åtgärder på specifika delar av data
Konfigurera SNMPv3-säkerhet
SNMPv3 kan säkras med endast ett fåtal kommandon, som visas i figuren.
Steg 1. Konfigurera en ACL som tillåter åtkomst till auktoriserade SNMP-hanterare.
Steg 2. Konfigurera en SNMP-vy med kommandot snmp-server view för att identifiera MIB OID:erna som SNMP-hanteraren kommer att kunna läsa. Konfigurering av en vy krävs för att begränsa SNMP-meddelanden till skrivskyddad åtkomst.
Steg 3. Konfigurera SNMP-gruppfunktioner med kommandot snmp-server group:
• Konfigurera ett namn för gruppen.
• Ställ in SNMP-versionen till 3 med nyckelordet v3.
• Kräv autentisering och kryptering med nyckelordet priv.
• Koppla en vy till gruppen och ge den skrivskyddad åtkomst med läskommandot.
• Ange ACL som konfigurerats i steg 1.
Steg 4. Konfigurera SNMP-gruppanvändarfunktioner med användarkommandot snmp-server:
• Konfigurera ett användarnamn och associera användaren med gruppnamnet som konfigurerades i steg 3.
• Ställ in SNMP-versionen till 3 med nyckelordet v3.
• Ställ in autentiseringstypen till antingen md5 eller sha och konfigurera ett autentiseringslösenord. SHA är att föredra och bör stödjas av SNMP-hanteringsprogramvaran.
• Kräv kryptering med nyckelordet priv och konfigurera ett krypteringslösenord.
En fullständig diskussion om konfigurationsalternativen för SNMPv3 ligger utanför denna kurs.
Säker SNMPv3-konfigurationsexempel
Figur 1 visar ett exempel på en konfiguration för att säkra SNMPv3.
Steg 1. En standard ACL heter PERMIT-ADMIN och är konfigurerad för att endast tillåta 192.168.1.0/24-nätverket. Alla värdar som är anslutna till detta nätverk kommer att få åtkomst till SNMP-agenten som körs på R1.
Steg 2. En SNMP-vy heter SNMP-RO och är konfigurerad att inkludera hela isoträdet från MIB. På ett produktionsnätverk skulle nätverksadministratören förmodligen konfigurera den här vyn så att den endast inkluderar MIB OID:er som var nödvändiga för att övervaka och hantera nätverket.
Steg 3. En SNMP-grupp konfigureras med namnet ADMIN. SNMP är inställd på version 3 med autentisering och kryptering krävs. Gruppen tillåts skrivskyddad åtkomst till vyn (SNMP-RO). Åtkomsten för gruppen begränsas av PERMIT-ADMIN ACL.
Steg 4. En SNMP-användare, BOB, konfigureras som medlem i gruppen ADMIN. SNMP är inställd på version 3. Autentisering är inställd på att använda SHA och ett autentiseringslösenord är konfigurerat. Även om R1 stöder upp till AES 256-kryptering, stöder SNMP-hanteringsprogramvaran endast AES 128. Så krypteringen är inställd på AES 128 och ett krypteringslösenord konfigureras.
Använd Syntax Checker i figur 2 för att konfigurera R1 med SNMPv3-autentisering med en ACL.
Säker SNMPv3-konfigurationsexempel
Figur 1 visar ett exempel på en konfiguration för att säkra SNMPv3.
Steg 1. En standard ACL heter PERMIT-ADMIN och är konfigurerad för att endast tillåta 192.168.1.0/24-nätverket. Alla värdar som är anslutna till detta nätverk kommer att få åtkomst till SNMP-agenten som körs på R1.
Steg 2. En SNMP-vy heter SNMP-RO och är konfigurerad att inkludera hela isoträdet från MIB. På ett produktionsnätverk skulle nätverksadministratören förmodligen konfigurera den här vyn så att den endast inkluderar MIB OID:er som var nödvändiga för att övervaka och hantera nätverket.
Steg 3. En SNMP-grupp konfigureras med namnet ADMIN. SNMP är inställd på version 3 med autentisering och kryptering krävs. Gruppen tillåts skrivskyddad åtkomst till vyn (SNMP-RO). Åtkomsten för gruppen begränsas av PERMIT-ADMIN ACL.
Steg 4. En SNMP-användare, BOB, konfigureras som medlem i gruppen ADMIN. SNMP är inställd på version 3. Autentisering är inställd på att använda SHA och ett autentiseringslösenord är konfigurerat. Även om R1 stöder upp till AES 256-kryptering, stöder SNMP-hanteringsprogramvaran endast AES 128. Så krypteringen är inställd på AES 128 och ett krypteringslösenord konfigureras.
Använd Syntax Checker i figur 2 för att konfigurera R1 med SNMPv3-autentisering med en ACL.
Konfigurera SNMPv3-autentisering med en ACL
Konfigurera en standardåtkomstlista med namnet PERMIT-ADMIN på R1 för att endast tillåta nätverket 192.168.1.0/24.
Avsluta ACL-konfigurationen för att fortsätta.
R1(config)# ip access-list standard PERMIT-ADMIN
R1(config-std-nacl)# permit 192.168.1.0 0.0.0.255
R1(config-std-nacl)# avsluta
R1(config)#
Använd kommandot snmp-server view, konfigurera en SNMP-vy med namnet SNMP-RO och begränsa åtkomsten med PERMIT-ADMIN ACL.
R1(config)# snmp-servervy SNMP-RO iso ingår
R1(config)#
Använd kommandot snmp-server group och konfigurera en SNMP-grupp med namnet ADMIN. Ställ in SNMP till version 3 med autentisering och kryptering krävs. Tillåt skrivskyddad åtkomst till vyn SNMP-RO och begränsa åtkomsten med PERMIT-ADMIN ACL
R1(config)# snmp-servergrupp ADMIN v3 priv läs SNMP-RO-åtkomst PERMIT-ADMIN
R1(config)#
Använd användarkommandot snmp-server, lägg till en snmp-användare med namnet BOB som medlem i ADMIN-gruppen. Ställ in SNMP till version 3 och ställ in autentisering för att använda SHA med lösenordet cisco12345. Ställ in krypteringen till AES 128 med lösenordet cisco54321. När konfigurationen är klar, använd slutkommandot för att avsluta konfigurationsläget.
R1(config)# snmp-serveranvändare BOB ADMIN v3 auth sha cisco12345 priv aes 128 cisco54321
R1(config)# slut
R1#
Verifierar SNMPv3-konfigurationen
Verifiera det mesta av SNMPv3-säkerhetskonfigurationen genom att visa den körande konfigurationen, som visas i figur 1. Observera att snmp-serverns användarkonfiguration är dold. Använd kommandot show snmp user för att se användarinformationen.
Verifiera att SNMP-hanteraren kan skicka get-förfrågningar till R1 genom att använda ett SNMP-hanteringsverktyg, såsom ManageEngines kostnadsfria SNMP MIB Browser. Konfigurera verktyget med användarinformationen, som visas i figur 2. När en användare är konfigurerad, använd SNMP-hanteringsverktygets funktioner för att testa att den konfigurerade användaren kan komma åt SNMP-agenten. I figur 3 angav nätverksadministratören OID för IP-adresseringstabellen. Get-begäran returnerade all adresseringsinformation för R1. Nätverksadministratören har autentiserats med lämpliga referenser. Verifiera att datan var krypterad genom att köra en protokollanalysator, såsom Wireshark, och fånga SNMP-paketen (se figur 4).
Klicka här för att se Keith Barkers demonstration av att konfigurera och verifiera SNMPv3.
Verifiera den säkra SNMPv3-konfigurationen.