Enterprise Network Function Virtualization Infrastructure Software
Produktinformation
Specifikationer
- NFVIS mjukvaruversion: 3.7.1 och senare
- RPM-signering och signaturverifiering stöds
- Säker start tillgänglig (inaktiverad som standard)
- Secure Unique Device Identification (SUDI)-mekanism används
Säkerhetsöverväganden
NFVIS-mjukvaran säkerställer säkerhet genom olika
mekanismer:
- Bild Tamper Skydd: RPM-signering och signaturverifiering
för alla RPM-paket i ISO och uppgraderingsbilder. - RPM-signering: Alla RPM-paket i Cisco Enterprise NFVIS ISO
och uppgraderingsbilder är signerade för att säkerställa kryptografisk integritet och
äkthet. - RPM-signaturverifiering: Signatur för alla RPM-paket är
verifieras före installation eller uppgradering. - Verifiering av bildintegritet: Hash för Cisco NFVIS ISO-bilden
och uppgraderingsbild publiceras för att säkerställa integriteten för ytterligare
icke-rpm files. - ENCS Secure Boot: En del av UEFI-standarden, säkerställer att
enheten startar endast med pålitlig programvara. - Secure Unique Device Identification (SUDI): Tillhandahåller enheten
med en oföränderlig identitet för att verifiera dess äkthet.
Installation
För att installera NFVIS-programvaran, följ dessa steg:
- Se till att mjukvarubilden inte har blivit tampered med av
verifiera dess signatur och integritet. - Om du använder Cisco Enterprise NFVIS 3.7.1 och senare, se till att
signaturverifieringen godkänns under installationen. Om det misslyckas,
installationen kommer att avbrytas. - Om du uppgraderar från Cisco Enterprise NFVIS 3.6.x till Release
3.7.1, RPM-signaturerna verifieras under uppgraderingen. Om
signaturverifiering misslyckas, ett fel loggas men uppgraderingen är det
avslutad. - Om du uppgraderar från version 3.7.1 till senare versioner, RPM
signaturer verifieras när uppgraderingsbilden registreras. Om
signaturverifieringen misslyckas, uppgraderingen avbryts. - Verifiera hashen för Cisco NFVIS ISO-bilden eller uppgraderingsbilden
med hjälp av kommandot:/usr/bin/sha512sum. Jämför hashen med den publicerade
<image_filepath>
hash för att säkerställa integritet.
Säker start
Säker start är en funktion tillgänglig på ENCS (inaktiverad som standard)
som säkerställer att enheten bara startar med pålitlig programvara. Till
aktivera säker start:
- Se dokumentationen om Secure Boot of Host för mer
information. - Följ de medföljande instruktionerna för att aktivera säker start på din
anordning.
Secure Unique Device Identification (SUDI)
SUDI förser NFVIS med en oföränderlig identitet, vilket verifierar det
det är en äkta Cisco-produkt och säkerställer dess erkännande i
kundens lagersystem.
FAQ
F: Vad är NFVIS?
S: NFVIS står för Network Function Virtualization
Infrastruktur programvara. Det är en mjukvaruplattform som används för att distribuera
och hantera virtuella nätverksfunktioner.
F: Hur kan jag verifiera integriteten för NFVIS ISO-bilden eller
uppgradera bilden?
S: För att verifiera integriteten, använd kommandot
/usr/bin/sha512sum <image_filepath> och jämför
hashen med den publicerade hashen som tillhandahålls av Cisco.
F: Är säker start aktiverad som standard på ENCS?
S: Nej, säker start är inaktiverat som standard på ENCS. Det är
rekommenderas för att aktivera säker start för ökad säkerhet.
F: Vad är syftet med SUDI i NFVIS?
S: SUDI förser NFVIS med en unik och oföränderlig identitet,
säkerställa dess äkthet som en Cisco-produkt och underlätta dess
igenkänning i kundens lagersystem.
Säkerhetsöverväganden
Det här kapitlet beskriver säkerhetsfunktionerna och övervägandena i NFVIS. Det ger en hög nivå överview av säkerhetsrelaterade komponenter i NFVIS för att planera en säkerhetsstrategi för implementeringar som är specifika för dig. Den har också rekommendationer om bästa säkerhetspraxis för att upprätthålla de centrala delarna av nätverkssäkerhet. NFVIS-programvaran har inbäddad säkerhet direkt från installationen genom alla mjukvarulager. De efterföljande kapitlen fokuserar på dessa direkta säkerhetsaspekter som hantering av autentiseringsuppgifter, integritet och t.amper-skydd, sessionshantering, säker enhetsåtkomst och mer.
· Installation, på sidan 2 · Säker unik enhetsidentifiering, på sidan 3 · Enhetsåtkomst, på sidan 4
Säkerhetsaspekter 1
Installation
Säkerhetsöverväganden
· Infrastructure Management Network, på sidan 22 · Lokalt lagrad informationsskydd, på sidan 23 · File Överföring, på sidan 24 · Loggning, på sidan 24 · Virtual Machine-säkerhet, på sidan 25 · VM-isolering och resursförsörjning, på sidan 26 · Säker utvecklingslivscykel, på sidan 29
Installation
För att säkerställa att NFVIS-programvaran inte har tampmed , verifieras mjukvarubilden före installation med hjälp av följande mekanismer:
Bild Tamper Skydd
NFVIS stöder RPM-signering och signaturverifiering för alla RPM-paket i ISO och uppgraderingsbilder.
RPM-signering
Alla RPM-paket i Cisco Enterprise NFVIS ISO och uppgraderingsbilder är signerade för att säkerställa kryptografisk integritet och autenticitet. Detta garanterar att RPM-paketen inte har blivit tampered med och RPM-paketen är från NFVIS. Den privata nyckeln som används för att signera RPM-paketen skapas och underhålls säkert av Cisco.
RPM-signaturverifiering
NFVIS-programvaran verifierar signaturen för alla RPM-paket innan en installation eller uppgradering. Följande tabell beskriver Cisco Enterprise NFVIS-beteendet när signaturverifieringen misslyckas under en installation eller uppgradering.
Scenario
Beskrivning
Cisco Enterprise NFVIS 3.7.1 och senare installationer Om signaturverifieringen misslyckas när Cisco Enterprise NFVIS installeras, avbryts installationen.
Cisco Enterprise NFVIS-uppgradering från 3.6.x till version 3.7.1
RPM-signaturerna verifieras när uppgraderingen utförs. Om signaturverifieringen misslyckas loggas ett fel men uppgraderingen är klar.
Cisco Enterprise NFVIS-uppgradering från version 3.7.1 RPM-signaturerna verifieras vid uppgraderingen
till senare utgåvor
bilden är registrerad. Om signaturverifieringen misslyckas,
uppgraderingen avbryts.
Verifiering av bildintegritet
RPM-signering och signaturverifiering kan endast göras för de RPM-paket som finns tillgängliga i Cisco NFVIS ISO och uppgraderingsbilder. För att säkerställa integriteten för alla ytterligare icke-RPM files tillgängligt i Cisco NFVIS ISO-bilden publiceras en hash av Cisco NFVIS ISO-bilden tillsammans med bilden. På samma sätt publiceras en hash av Cisco NFVIS-uppgraderingsbilden tillsammans med bilden. För att verifiera att Ciscos hash
Säkerhetsaspekter 2
Säkerhetsöverväganden
ENCS säker start
NFVIS ISO-bild eller uppgraderingsbild matchar hashen som publicerats av Cisco, kör följande kommando och jämför hashen med den publicerade hashen:
% /usr/bin/sha512sumFile> c2122783efc18b039246ae1bcd4eec4e5e027526967b5b809da5632d462dfa6724a9b20ec318c74548c6bd7e9b8217ce96b5ece93dcdd74fda5e01bb382ad607
<ImageFile>
ENCS säker start
Säker start är en del av UEFI-standarden (Unified Extensible Firmware Interface) som säkerställer att en enhet endast startar med en programvara som är betrodd av Original Equipment Manufacturer (OEM). När NFVIS startar kontrollerar den fasta programvaran signaturen för startprogramvaran och operativsystemet. Om signaturerna är giltiga startar enheten och den fasta programvaran ger kontrollen till operativsystemet.
Säker start är tillgänglig på ENCS men är inaktiverad som standard. Cisco rekommenderar att du aktiverar säker start. För mer information, se Säker uppstart av värd.
Säker unik enhetsidentifiering
NFVIS använder en mekanism som kallas Secure Unique Device Identification (SUDI), som ger den en oföränderlig identitet. Denna identitet används för att verifiera att enheten är en äkta Cisco-produkt och för att säkerställa att enheten är välkänd för kundens lagersystem.
SUDI är ett X.509v3-certifikat och ett tillhörande nyckelpar som är skyddade i hårdvara. SUDI-certifikatet innehåller produktidentifieraren och serienumret och är rotat i Cisco Public Key Infrastructure. Nyckelparet och SUDI-certifikatet infogas i hårdvarumodulen under tillverkningen och den privata nyckeln kan aldrig exporteras.
Den SUDI-baserade identiteten kan användas för att utföra autentiserad och automatiserad konfiguration med Zero Touch Provisioning (ZTP). Detta möjliggör säker, fjärrinloggning av enheter och säkerställer att orkestreringsservern pratar med en äkta NFVIS-enhet. Ett backend-system kan utfärda en utmaning till NFVIS-enheten för att validera dess identitet och enheten kommer att svara på utmaningen med sin SUDI-baserade identitet. Detta gör att backend-systemet inte bara kan verifiera mot sitt lager att rätt enhet är på rätt plats utan också tillhandahålla krypterad konfiguration som bara kan öppnas av den specifika enheten, vilket säkerställer konfidentialitet vid överföring.
Följande arbetsflödesdiagram illustrerar hur NFVIS använder SUDI:
Säkerhetsaspekter 3
Enhetsåtkomst Figur 1: Plug and Play (PnP) serverautentisering
Säkerhetsöverväganden
Figur 2: Plug and Play-enhetsautentisering och auktorisering
Enhetsåtkomst
NFVIS tillhandahåller olika åtkomstmekanismer inklusive konsol samt fjärråtkomst baserat på protokoll som HTTPS och SSH. Varje åtkomstmekanism bör noggrant tas omviewed och konfigurerad. Se till att endast de nödvändiga åtkomstmekanismerna är aktiverade och att de är ordentligt säkrade. De viktigaste stegen för att säkra både interaktiv och hanteringsåtkomst till NFVIS är att begränsa enhetens tillgänglighet, begränsa de tillåtna användarnas möjligheter till vad som krävs och begränsa de tillåtna åtkomstmetoderna. NFVIS säkerställer att åtkomsten endast ges till autentiserade användare och att de bara kan utföra de auktoriserade åtgärderna. Enhetsåtkomst loggas för granskning och NFVIS säkerställer sekretessen för lokalt lagrad känslig data. Det är viktigt att upprätta lämpliga kontroller för att förhindra obehörig åtkomst till NFVIS. Följande avsnitt beskriver bästa praxis och konfigurationer för att uppnå detta:
Säkerhetsaspekter 4
Säkerhetsöverväganden
Påtvingad lösenordsändring vid första inloggning
Påtvingad lösenordsändring vid första inloggning
Standardreferenser är en frekvent källa till produktsäkerhetsincidenter. Kunder glömmer ofta att ändra standardinloggningsuppgifterna och lämnar deras system öppna för attack. För att förhindra detta tvingas NFVIS-användaren att ändra lösenordet efter den första inloggningen med standarduppgifterna (användarnamn: admin och lösenord Admin123#). För mer information, se Åtkomst till NFVIS.
Begränsa inloggningssårbarheter
Du kan förhindra sårbarheten för ordbok och DoS-attacker (Denial of Service) genom att använda följande funktioner.
Upprätthållande av starkt lösenord
En autentiseringsmekanism är bara lika stark som dess autentiseringsuppgifter. Av denna anledning är det viktigt att se till att användarna har starka lösenord. NFVIS kontrollerar att ett starkt lösenord är konfigurerat enligt följande regler: Lösenordet måste innehålla:
· Minst ett stort tecken · Minst ett gement tecken · Minst ett nummer · Minst ett av dessa specialtecken: hash (#), understreck (_), bindestreck (-), asterisk (*) eller fråga
markera (?) · Sju tecken eller mer · Lösenordslängden ska vara mellan 7 och 128 tecken.
Konfigurera minsta längd för lösenord
Brist på lösenordskomplexitet, särskilt lösenordslängden, minskar sökutrymmet avsevärt när angripare försöker gissa användarlösenord, vilket gör brute-force-attacker mycket enklare. Administratörsanvändaren kan konfigurera den minsta längden som krävs för alla användares lösenord. Minsta längd måste vara mellan 7 och 128 tecken. Som standard är den minsta längden som krävs för lösenord inställd på 7 tecken. CLI:
nfvis(config)# rbac-autentisering min-pwd-length 9
API:
/api/config/rbac/autentication/min-pwd-length
Konfigurera lösenordets livslängd
Lösenordets livslängd avgör hur länge ett lösenord kan användas innan användaren måste ändra det.
Säkerhetsaspekter 5
Begränsa tidigare återanvändning av lösenord
Säkerhetsöverväganden
Administratörsanvändaren kan konfigurera lägsta och maximala livstidsvärden för lösenord för alla användare och tillämpa en regel för att kontrollera dessa värden. Standardvärdet för minsta livslängd är inställt på 1 dag och standardvärdet för maximal livslängd är inställt på 60 dagar. När ett lägsta livstidsvärde är konfigurerat kan användaren inte ändra lösenordet förrän det angivna antalet dagar har gått. På samma sätt, när ett maximalt livstidsvärde är konfigurerat, måste en användare ändra lösenordet innan det angivna antalet dagar går. Om en användare inte ändrar lösenordet och det angivna antalet dagar har gått skickas ett meddelande till användaren.
Obs Minsta och maximala livstidsvärden och regeln för att kontrollera dessa värden tillämpas inte på administratörsanvändaren.
CLI:
konfigurera terminal rbac-autentisering lösenord-livstid verkställa sanna min-dagar 2 max-dagar 30 commit
API:
/api/config/rbac/autentication/password-lifetime/
Begränsa tidigare återanvändning av lösenord
Utan att förhindra användningen av tidigare lösenfraser är lösenordsutgången i stort sett värdelös eftersom användare helt enkelt kan ändra lösenfrasen och sedan ändra den tillbaka till originalet. NFVIS kontrollerar att det nya lösenordet inte är detsamma som ett av de 5 tidigare använda lösenorden. Ett undantag från denna regel är att administratörsanvändaren kan ändra lösenordet till standardlösenordet även om det var ett av de 5 tidigare använda lösenorden.
Begränsa frekvensen av inloggningsförsök
Om en fjärransluten peer tillåts logga in ett obegränsat antal gånger, kan den så småningom kunna gissa inloggningsuppgifterna med brute force. Eftersom lösenordsfraser ofta är lätta att gissa är detta en vanlig attack. Genom att begränsa hastigheten med vilken peer kan försöka logga in förhindrar vi denna attack. Vi undviker också att spendera systemresurserna på att onödigt autentisera dessa brute-force inloggningsförsök som kan skapa en Denial of Service-attack. NFVIS upprätthåller en 5 minuters användarlåsning efter 10 misslyckade inloggningsförsök.
Inaktivera inaktiva användarkonton
Att övervaka användaraktivitet och inaktivera oanvända eller inaktuella användarkonton hjälper till att säkra systemet från insiderattacker. De oanvända kontona bör så småningom tas bort. Administratörsanvändaren kan tillämpa en regel för att markera oanvända användarkonton som inaktiva och konfigurera antalet dagar efter vilka ett oanvänt användarkonto markeras som inaktivt. När den väl har markerats som inaktiv kan den användaren inte logga in på systemet. För att tillåta användaren att logga in på systemet kan adminanvändaren aktivera användarkontot.
Obs! Inaktivitetsperioden och regeln för att kontrollera inaktivitetsperioden tillämpas inte på adminanvändaren.
Säkerhetsaspekter 6
Säkerhetsöverväganden
Aktivera ett inaktivt användarkonto
Följande CLI och API kan användas för att konfigurera upprätthållandet av kontoinaktivitet. CLI:
konfigurera terminal rbac-autentisering konto-inaktivitet genomdriva sann inaktivitet-dagar 30 commit
API:
/api/config/rbac/autentication/account-inactivity/
Standardvärdet för inaktivitetsdagar är 35.
Aktivera ett inaktivt användarkonto Administratörsanvändaren kan aktivera kontot för en inaktiv användare med hjälp av följande CLI och API: CLI:
konfigurera terminal rbac autentisering användare användare guest_user aktivera commit
API:
/api/operations/rbac/autentication/users/user/username/activate
Framtvinga inställning av BIOS- och CIMC-lösenord
Tabell 1: Funktionshistoriktabell
Funktionens namn
Releaseinformation
Framtvinga inställning av BIOS och CIMC NFVIS 4.7.1 lösenord
Beskrivning
Denna funktion tvingar användaren att ändra standardlösenordet för CIMC och BIOS.
Restriktioner för upprätthållande av inställning av BIOS- och CIMC-lösenord
· Den här funktionen stöds endast på Cisco Catalyst 8200 UCPE och Cisco ENCS 5400-plattformar.
· Den här funktionen stöds endast på en nyinstallation av NFVIS 4.7.1 och senare versioner. Om du uppgraderar från NFVIS 4.6.1 till NFVIS 4.7.1 stöds inte den här funktionen och du uppmanas inte att återställa BIOS- och CIMS-lösenorden, även om BIOS- och CIMC-lösenorden inte är konfigurerade.
Information om upprätthållande av inställning av BIOS- och CIMC-lösenord
Den här funktionen åtgärdar en säkerhetslucka genom att tvinga fram återställningen av BIOS- och CIMC-lösenord efter en nyinstallation av NFVIS 4.7.1. Standard CIMC-lösenordet är lösenord och standard BIOS-lösenordet är inget lösenord.
För att åtgärda säkerhetsluckan tvingas du konfigurera BIOS- och CIMC-lösenorden i ENCS 5400. Under en nyinstallation av NFVIS 4.7.1, om BIOS- och CIMC-lösenorden inte har ändrats och fortfarande har
Säkerhetsaspekter 7
Konfiguration Examples för tvingad återställning av BIOS- och CIMC-lösenord
Säkerhetsöverväganden
standardlösenorden, då uppmanas du att ändra både BIOS- och CIMC-lösenorden. Om bara en av dem kräver återställning, uppmanas du att återställa lösenordet för endast den komponenten. Cisco Catalyst 8200 UCPE kräver bara BIOS-lösenordet och därför uppmanas endast BIOS-lösenordsåterställningen, om den inte redan har ställts in.
Obs! Om du uppgraderar från någon tidigare version till NFVIS 4.7.1 eller senare utgåvor kan du ändra BIOS- och CIMC-lösenorden med kommandona hostaction change-bios-password newpassword eller hostaction change-cimc-password newpassword.
För mer information om BIOS- och CIMC-lösenord, se BIOS och CIMC-lösenord.
Konfiguration Examples för tvingad återställning av BIOS- och CIMC-lösenord
1. När du installerar NFVIS 4.7.1 måste du först återställa standardadministratörslösenordet.
Cisco Network Function Virtualization Infrastructure Software (NFVIS)
NFVIS-version: 99.99.0-1009
Copyright (c) 2015-2021 av Cisco Systems, Inc. Cisco, Cisco Systems och Cisco Systems logotyp är registrerade varumärken som tillhör Cisco Systems, Inc. och/eller dess dotterbolag i USA och vissa andra länder.
Upphovsrätten till vissa verk som ingår i denna programvara ägs av andra tredje parter och används och distribueras under tredje parts licensavtal. Vissa komponenter i denna programvara är licensierade under GNU GPL 2.0, GPL 3.0, LGPL 2.1, LGPL 3.0 och AGPL 3.0.
admin ansluten från 10.24.109.102 med ssh på nfvis admin inloggad med standarduppgifter Vänligen ange ett lösenord som uppfyller följande kriterier:
1.Minst ett gement tecken 2.Minst ett stort tecken 3.Minst ett nummer 4.Minst ett specialtecken från # _ – * ? 5.Längden bör vara mellan 7 och 128 tecken. Återställ lösenordet: Vänligen ange lösenordet igen:
Återställer administratörslösenord
2. På Cisco Catalyst 8200 UCPE och Cisco ENCS 5400-plattformar när du gör en nyinstallation av NFVIS 4.7.1 eller senare versioner, måste du ändra standard BIOS- och CIMC-lösenord. Om BIOS- och CIMC-lösenorden inte har konfigurerats tidigare, uppmanar systemet dig att återställa BIOS- och CIMC-lösenorden för Cisco ENCS 5400 och endast BIOS-lösenordet för Cisco Catalyst 8200 UCPE.
Nytt administratörslösenord är inställt
Ange BIOS-lösenordet som uppfyller följande kriterier: 1. Minst ett gement tecken 2. Minst ett stort tecken 3. Minst ett nummer 4. Minst ett specialtecken från #, @ eller _ 5. Längden ska vara mellan 8 och 20 tecken 6. Bör inte innehålla någon av följande strängar (skiftlägeskänsliga): bios 7. Första tecknet får inte vara ett #
Säkerhetsaspekter 8
Säkerhetsöverväganden
Verifiera BIOS- och CIMC-lösenord
Vänligen återställ BIOS-lösenordet: Vänligen ange BIOS-lösenordet igen: Ange CIMC-lösenordet som uppfyller följande kriterier:
1. Minst ett gement tecken 2. Minst ett stort tecken 3. Minst ett nummer 4. Minst ett specialtecken från #, @ eller _ 5. Längden ska vara mellan 8 och 20 tecken 6. Bör inte innehålla något av följande strängar (skiftlägeskänsliga): admin Vänligen återställ CIMC-lösenordet: Vänligen ange CIMC-lösenordet igen:
Verifiera BIOS- och CIMC-lösenord
Använd showloggen nfvis_config.log | inkludera BIOS eller visa logg nfvis_config.log | inkludera CIMC-kommandon:
nfvis# visa logg nfvis_config.log | inkluderar BIOS
2021-11-16 15:24:40,102 INFO
[hostaction:/system/settings] [] BIOS-lösenordsändringär framgångsrik
Du kan också ladda ner nfvis_config.log file och kontrollera om lösenorden har återställts.
Integration med externa AAA-servrar
Användare loggar in på NFVIS via ssh eller Web UI. I båda fallen måste användare autentiseras. Det vill säga, en användare måste presentera lösenordsuppgifter för att få åtkomst.
När en användare har autentiserats måste alla åtgärder som utförs av den användaren auktoriseras. Det vill säga att vissa användare kan tillåtas utföra vissa uppgifter, medan andra inte gör det. Detta kallas auktorisation.
Det rekommenderas att en centraliserad AAA-server distribueras för att upprätthålla AAA-baserad inloggningsautentisering per användare för NFVIS-åtkomst. NFVIS stöder RADIUS- och TACACS-protokoll för att förmedla nätverksåtkomst. På AAA-servern bör endast minsta åtkomstbehörighet ges till autentiserade användare i enlighet med deras specifika åtkomstkrav. Detta minskar exponeringen för både skadliga och oavsiktliga säkerhetsincidenter.
För mer information om extern autentisering, se Konfigurera RADIUS och Konfigurera en TACACS+-server.
Autentiseringscache för extern autentiseringsserver
Funktionens namn
Releaseinformation
Autentiseringscache för extern NFVIS 4.5.1 Autentiseringsserver
Beskrivning
Den här funktionen stöder TACACS-autentisering via OTP på NFVIS-portalen.
NFVIS-portalen använder samma One-Time Password (OTP) för alla API-anrop efter den första autentiseringen. API-anropen misslyckas så fort OTP löper ut. Den här funktionen stöder TACACS OTP-autentisering med NFVIS-portalen.
Efter att du har autentiserats genom TACACS-servern med en OTP, skapar NFVIS en hash-post med användarnamnet och OTP:n och lagrar detta hashvärde lokalt. Detta lokalt lagrade hashvärde har
Säkerhetsaspekter 9
Rollbaserad åtkomstkontroll
Säkerhetsöverväganden
en utgångstid stamp förknippas med det. Tiden stamp har samma värde som SSH-sessionens inaktiva timeout-värde som är 15 minuter. Alla efterföljande autentiseringsbegäranden med samma användarnamn autentiseras mot detta lokala hashvärde först. Om autentiseringen misslyckas med den lokala hashen, autentiserar NFVIS denna begäran med TACACS-servern och skapar en ny hash-post när autentiseringen lyckas. Om en hash-post redan finns, är det dags för stamp återställs till 15 minuter.
Om du tas bort från TACACS-servern efter att du lyckats logga in på portalen kan du fortsätta att använda portalen tills hash-posten i NFVIS går ut.
När du explicit loggar ut från NFVIS-portalen eller är utloggad på grund av vilotid, anropar portalen ett nytt API för att meddela NFVIS-backend att hash-posten rensas. Autentiseringscachen och alla dess poster rensas ut efter NFVIS omstart, fabriksåterställning eller uppgradering.
Rollbaserad åtkomstkontroll
Att begränsa nätverksåtkomst är viktigt för organisationer som har många anställda, anställer entreprenörer eller tillåter åtkomst till tredje part, såsom kunder och leverantörer. I ett sådant scenario är det svårt att övervaka nätverksåtkomst effektivt. Istället är det bättre att kontrollera vad som är tillgängligt, för att säkra den känsliga datan och kritiska applikationer.
Rollbaserad åtkomstkontroll (RBAC) är en metod för att begränsa nätverksåtkomst baserat på rollerna för enskilda användare inom ett företag. RBAC låter användare komma åt precis den information de behöver och hindrar dem från att komma åt information som inte hör till dem.
En anställds roll i företaget bör användas för att fastställa vilka behörigheter som beviljas, för att säkerställa att anställda med lägre privilegier inte kan komma åt känslig information eller utföra viktiga uppgifter.
Följande användarroller och privilegier definieras i NFVIS
Användarroll
Privilegium
Administratörer
Kan konfigurera alla tillgängliga funktioner och utföra alla uppgifter inklusive byte av användarroller. Administratören kan inte ta bort grundläggande infrastruktur som är grundläggande för NFVIS. Admin-användarens roll kan inte ändras; det är alltid "administratörer".
Operatörer
Kan starta och stoppa en virtuell dator, och view all information.
Revisorer
De är de minst privilegierade användarna. De har skrivskyddad behörighet och kan därför inte ändra någon konfiguration.
Fördelar med RBAC
Det finns ett antal fördelar med att använda RBAC för att begränsa onödig nätverksåtkomst baserat på människors roller inom en organisation, inklusive:
· Förbättring av operativ effektivitet.
Att ha fördefinierade roller i RBAC gör det enkelt att inkludera nya användare med rätt privilegier eller byta roller för befintliga användare. Det minskar också risken för fel när användarbehörigheter tilldelas.
· Förbättra efterlevnaden.
Säkerhetsaspekter 10
Säkerhetsöverväganden
Rollbaserad åtkomstkontroll
Varje organisation måste följa lokala, statliga och federala bestämmelser. Företag föredrar i allmänhet att implementera RBAC-system för att möta de lagstadgade kraven för konfidentialitet och integritet eftersom chefer och IT-avdelningar mer effektivt kan hantera hur data nås och används. Detta är särskilt viktigt för finansiella institutioner och hälsovårdsföretag som hanterar känslig information.
· Minska kostnader. Genom att inte tillåta användaråtkomst till vissa processer och applikationer kan företag spara eller använda resurser som nätverksbandbredd, minne och lagring på ett kostnadseffektivt sätt.
· Minskad risk för intrång och dataläckage. Att implementera RBAC innebär att begränsa åtkomsten till känslig information, vilket minskar risken för dataintrång eller dataläckage.
Bästa tillvägagångssätt för rollbaserade åtkomstkontrollimplementeringar · Som administratör, bestäm listan över användare och tilldela användarna de fördefinierade rollerna. Till exempelample, kan användaren "nätverksadmin" skapas och läggas till i användargruppen "administratörer".
konfigurera terminal rbac autentisering användare skapa användarnamn nätverksadministratör lösenord Test1_pass roll administratörer commit
Obs! Användargrupperna eller rollerna skapas av systemet. Du kan inte skapa eller ändra en användargrupp. För att ändra lösenordet, använd kommandot rbac-autentisering användare user change-password i globalt konfigurationsläge. För att ändra användarrollen, använd kommandot rbac-autentisering användare användar ändra-roll i globalt konfigurationsläge.
· Avsluta konton för användare som inte längre behöver åtkomst.
konfigurera terminal rbac-autentiseringsanvändare radera-användarnamn test1
· Genomför regelbundet revisioner för att utvärdera rollerna, de anställda som är tilldelade dem och den åtkomst som är tillåten för varje roll. Om en användare upptäcks ha onödig åtkomst till ett visst system, ändra användarens roll.
För mer information se Användare, roller och autentisering
Granulär rollbaserad åtkomstkontroll Från och med NFVIS 4.7.1 introduceras funktionen Granulär rollbaserad åtkomstkontroll. Den här funktionen lägger till en ny resursgrupppolicy som hanterar VM och VNF och låter dig tilldela användare till en grupp för att kontrollera VNF-åtkomst under VNF-distribution. Mer information finns i Granulär rollbaserad åtkomstkontroll.
Säkerhetsaspekter 11
Begränsa enhetens tillgänglighet
Säkerhetsöverväganden
Begränsa enhetens tillgänglighet
Användare har upprepade gånger fångats ovetande av attacker mot funktioner som de inte hade skyddat eftersom de inte visste att dessa funktioner var aktiverade. Oanvända tjänster tenderar att lämnas med standardkonfigurationer som inte alltid är säkra. Dessa tjänster kan också använda standardlösenord. Vissa tjänster kan ge en angripare enkel tillgång till information om vad servern kör eller hur nätverket är konfigurerat. Följande avsnitt beskriver hur NFVIS undviker sådana säkerhetsrisker:
Attackvektorreduktion
Vilken mjukvara som helst kan innehålla säkerhetsbrister. Mer programvara innebär fler angreppsmöjligheter. Även om det inte finns några allmänt kända sårbarheter vid tidpunkten för införandet, kommer sårbarheter troligen att upptäckas eller avslöjas i framtiden. För att undvika sådana scenarier installeras endast de programvarupaket som är nödvändiga för NFVIS-funktionaliteten. Detta hjälper till att begränsa sårbarheter i programvaran, minska resursförbrukningen och minska extra arbete när problem upptäcks med dessa paket. All programvara från tredje part som ingår i NFVIS registreras i en central databas i Cisco så att Cisco kan utföra ett organiserat svar på företagsnivå (juridiskt, säkerhet, etc). Programvarupaket korrigeras med jämna mellanrum i varje utgåva för kända gemensamma sårbarheter och exponeringar (CVE).
Aktiverar endast viktiga portar som standard
Endast de tjänster som är absolut nödvändiga för att ställa in och hantera NFVIS är tillgängliga som standard. Detta tar bort användaransträngningen som krävs för att konfigurera brandväggar och neka åtkomst till onödiga tjänster. De enda tjänsterna som är aktiverade som standard listas nedan tillsammans med portarna de öppnar.
Öppna porten
Service
Beskrivning
22 / TCP
SSH
Secure Socket Shell för fjärråtkomst med kommandorad till NFVIS
80 / TCP
HTTP
Hypertext Transfer Protocol för åtkomst till NFVIS-portalen. All HTTP-trafik som tas emot av NFVIS omdirigeras till port 443 för HTTPS
443 / TCP
HTTPS
Hypertext Transfer Protocol Secure för säker NFVIS-portalåtkomst
830 / TCP
NETCONF-ssh
Port öppnad för Network Configuration Protocol (NETCONF) över SSH. NETCONF är ett protokoll som används för automatiserad konfiguration av NFVIS och för att ta emot asynkrona händelsemeddelanden från NFVIS.
161/UDP
SNMP
Simple Network Management Protocol (SNMP). Används av NFVIS för att kommunicera med fjärrnätverksövervakningsapplikationer. För mer information se, Introduktion om SNMP
Säkerhetsaspekter 12
Säkerhetsöverväganden
Begränsa åtkomst till auktoriserade nätverk för auktoriserade tjänster
Begränsa åtkomst till auktoriserade nätverk för auktoriserade tjänster
Endast auktoriserade upphovsmän bör tillåtas att till och med försöka åtkomst till enhetshantering, och åtkomst bör endast vara till de tjänster de är auktoriserade att använda. NFVIS kan konfigureras så att åtkomsten begränsas till kända, pålitliga källor och förväntad trafikproffsfiles. Detta minskar risken för obehörig åtkomst och exponeringen för andra attacker, såsom brute force, ordbok eller DoS-attacker.
För att skydda NFVIS-hanteringsgränssnitten från onödig och potentiellt skadlig trafik, kan en administratörsanvändare skapa åtkomstkontrollistor (ACL) för den nätverkstrafik som tas emot. Dessa ACL:er anger källans IP-adresser/nätverk som trafiken kommer från och vilken typ av trafik som är tillåten eller avvisad från dessa källor. Dessa IP-trafikfilter tillämpas på varje hanteringsgränssnitt på NFVIS. Följande parametrar är konfigurerade i en åtkomstkontrolllista för IP-mottagning (ip-receive-acl)
Parameter
Värde
Beskrivning
Källnätverk/nätmask
Nätverk/nätmask. Till exempelample: 0.0.0.0/0
172.39.162.0/24
Detta fält anger IP-adressen/nätverket från vilket trafiken kommer
Serviceåtgärd
https icmp netconf scpd snmp ssh acceptera släpp avvisa
Typ av trafik från den angivna källan.
Åtgärder som ska vidtas på trafiken från källnätverket. Med accept kommer nya anslutningsförsök att beviljas. Med avvisande kommer anslutningsförsök inte att accepteras. Om regeln är för en TCP-baserad tjänst som HTTPS, NETCONF, SCP, SSH kommer källan att få ett TCP-återställningspaket (RST). För icke-TCP-regler som SNMP och ICMP kommer paketet att tas bort. Med drop kommer alla paket att släppas omedelbart, det skickas ingen information till källan.
Säkerhetsaspekter 13
Privilegerad felsökningsåtkomst
Säkerhetsöverväganden
Parameterprioritet
Värde Ett numeriskt värde
Beskrivning
Prioriteten används för att verkställa en order om reglerna. Regler med högre numeriskt värde för prioritet kommer att läggas till längre ner i kedjan. Om du vill vara säker på att en regel kommer att läggas till efter en annan, använd ett lågprioritetsnummer för den första och ett högre prioritetsnummer för följande.
Följande sample-konfigurationer illustrerar några scenarier som kan anpassas för specifika användningsfall.
Konfigurera ACL för IP-mottagning
Ju mer restriktiv en ACL är, desto mer begränsad är exponeringen för obehöriga åtkomstförsök. En mer restriktiv ACL kan dock skapa en hanteringsoverhead och kan påverka tillgängligheten för att utföra felsökning. Följaktligen finns det en balans att beakta. En kompromiss är att begränsa åtkomsten till endast företagets interna IP-adresser. Varje kund måste utvärdera implementeringen av ACL:er i förhållande till sin egen säkerhetspolicy, risker, exponering och acceptans därav.
Avvisa ssh-trafik från ett undernät:
nfvis(config)# systeminställningar ip-receive-acl 171.70.63.0/24 service ssh action avvisa prioritet 1
Ta bort ACL:er:
När en post raderas från ip-receive-acl raderas alla konfigurationer till den källan eftersom källans IP-adress är nyckeln. Om du bara vill ta bort en tjänst konfigurerar du andra tjänster igen.
nfvis(config)# inga systeminställningar ip-receive-acl 171.70.63.0/24
För mer information se, Konfigurera IP-mottagnings-ACL
Privilegerad felsökningsåtkomst
Superanvändarkontot på NFVIS är inaktiverat som standard för att förhindra alla obegränsade, potentiellt negativa, systemomfattande förändringar och NFVIS exponerar inte systemskalet för användaren.
För vissa svårfelsökta problem på NFVIS-systemet kan dock Ciscos tekniska hjälpcenterteam (TAC) eller utvecklingsteam kräva skalåtkomst till kundens NFVIS. NFVIS har en säker upplåsningsinfrastruktur för att säkerställa att privilegierad felsökningsåtkomst till en enhet i fält är begränsad till auktoriserade Cisco-anställda. För att säkert få åtkomst till Linux-skalet för den här typen av interaktiv felsökning, används en autentiseringsmekanism för utmaningssvar mellan NFVIS och den interaktiva felsökningsservern som underhålls av Cisco. Administratörsanvändarens lösenord krävs också utöver utmaning-svar-posten för att säkerställa att enheten nås med kundens samtycke.
Steg för att komma åt skalet för interaktiv felsökning:
1. En administratörsanvändare initierar denna procedur med detta dolda kommando.
nfvis# systemskal-åtkomst
Säkerhetsaspekter 14
Säkerhetsöverväganden
Säkra gränssnitt
2. Skärmen visar en utmaningssträng, till exempelampde:
Utmaningssträng (Kopiera endast allt mellan asteriskraderna):
******************************************************************************** SPH//wkAAABORlZJU0VOQ1M1NDA4L0s5AQAAABt+dcx+hB0V06r9RkdMMjEzNTgw RlHq7BxeAAA= DONE. ********************************************************************************
3. Cisco-medlemmen anger utmaningssträngen på en interaktiv felsökningsserver som underhålls av Cisco. Den här servern verifierar att Cisco-användaren är auktoriserad att felsöka NFVIS med hjälp av skalet och returnerar sedan en svarssträng.
4. Ange svarssträngen på skärmen under denna prompt: Ange ditt svar när du är klar:
5. När kunden uppmanas att ange administratörslösenordet. 6. Du får shell-access om lösenordet är giltigt. 7. Utvecklings- eller TAC-teamet använder skalet för att fortsätta med felsökningen. 8. För att avsluta skal-åtkomst, skriv Exit.
Säkra gränssnitt
NFVIS-hanteringsåtkomst tillåts med de gränssnitt som visas i diagrammet. Följande avsnitt beskriver bästa praxis för säkerhet för dessa gränssnitt till NFVIS.
Konsol SSH
Konsolporten är en asynkron seriell port som låter dig ansluta till NFVIS CLI för initial konfiguration. En användare kan komma åt konsolen med antingen fysisk åtkomst till NFVIS eller fjärråtkomst genom användning av en terminalserver. Om konsolportåtkomst krävs via en terminalserver, konfigurera åtkomstlistor på terminalservern för att endast tillåta åtkomst från de källadresser som krävs.
Användare kan komma åt NFVIS CLI genom att använda SSH som ett säkert sätt för fjärrinloggning. Integriteten och konfidentialiteten för NFVIS-hanteringstrafiken är väsentlig för säkerheten för det administrerade nätverket eftersom administrationsprotokoll ofta innehåller information som kan användas för att penetrera eller störa nätverket.
Säkerhetsaspekter 15
Timeout för CLI-session
Säkerhetsöverväganden
NFVIS använder SSH version 2, som är Ciscos och Internets de facto standardprotokoll för interaktiva inloggningar och stöder stark kryptering, hash och nyckelutbytesalgoritmer som rekommenderas av Security and Trust Organization inom Cisco.
Timeout för CLI-session
Genom att logga in via SSH upprättar en användare en session med NFVIS. Medan användaren är inloggad, om användaren lämnar den inloggade sessionen obevakad, kan detta utsätta nätverket för en säkerhetsrisk. Sessionssäkerhet begränsar risken för interna attacker, till exempel att en användare försöker använda en annan användares session.
För att minska denna risk, NFVIS timeout CLI-sessioner efter 15 minuters inaktivitet. När sessionens timeout nås loggas användaren automatiskt ut.
NETCONF
Network Configuration Protocol (NETCONF) är ett nätverkshanteringsprotokoll utvecklat och standardiserat av IETF för automatisk konfiguration av nätverksenheter.
NETCONF-protokollet använder en XML-baserad datakodning (Extensible Markup Language) för både konfigurationsdata och protokollmeddelanden. Protokollmeddelandena utbyts ovanpå ett säkert transportprotokoll.
NETCONF tillåter NFVIS att exponera ett XML-baserat API som nätverksoperatören kan använda för att ställa in och få konfigurationsdata och händelsemeddelanden säkert över SSH.
För mer information se NETCONF Event Notifications.
REST API
NFVIS kan konfigureras med RESTful API över HTTPS. REST API tillåter de begärande systemen att komma åt och manipulera NFVIS-konfigurationen genom att använda en enhetlig och fördefinierad uppsättning tillståndslösa operationer. Detaljer om alla REST API:er finns i NFVIS API Referensguide.
När användaren utfärdar ett REST API upprättas en session med NFVIS. För att begränsa risker relaterade till överbelastningsattacker, begränsar NFVIS det totala antalet samtidiga REST-sessioner till 100.
NFVIS Web Portal
NFVIS-portalen är en web-baserat grafiskt användargränssnitt som visar information om NFVIS. Portalen ger användaren ett enkelt sätt att konfigurera och övervaka NFVIS över HTTPS utan att behöva känna till NFVIS CLI och API.
Sessionshantering
Den tillståndslösa naturen hos HTTP och HTTPS kräver en metod för unik spårning av användare genom användning av unika sessions-ID:n och cookies.
NFVIS krypterar användarens session. AES-256-CBC-chifferet används för att kryptera sessionsinnehållet med en HMAC-SHA-256-autentisering tag. En slumpmässig 128-bitars initialiseringsvektor genereras för varje krypteringsoperation.
En revisionspost startas när en portalsession skapas. Sessionsinformation raderas när användaren loggar ut eller när sessionen tar slut.
Standardtidsgränsen för vilotid för portalsessioner är 15 minuter. Detta kan dock konfigureras för den aktuella sessionen till ett värde mellan 5 och 60 minuter på sidan Inställningar. Automatisk utloggning kommer att initieras efter detta
Säkerhetsaspekter 16
Säkerhetsöverväganden
HTTPS
HTTPS
period. Flera sessioner är inte tillåtna i en enda webbläsare. Det maximala antalet samtidiga sessioner är satt till 30. NFVIS-portalen använder cookies för att associera data med användaren. Den använder följande cookie-egenskaper för ökad säkerhet:
· tillfälligt för att säkerställa att cookien förfaller när webbläsaren stängs · httpEndast för att göra cookien otillgänglig från JavaScript · secureProxy för att säkerställa att cookien endast kan skickas över SSL.
Även efter autentisering är attacker som Cross-Site Request Forgery (CSRF) möjliga. I det här scenariot kan en slutanvändare oavsiktligt utföra oönskade åtgärder på en web applikation där de för närvarande är autentiserade. För att förhindra detta använder NFVIS CSRF-tokens för att validera varje REST API som anropas under varje session.
URL Omdirigering i typiskt web servrar, när en sida inte hittas på web servern får användaren ett 404-meddelande; för sidor som finns får de en inloggningssida. Säkerhetseffekten av detta är att en angripare kan utföra en brute force scan och enkelt upptäcka vilka sidor och mappar som finns. För att förhindra detta på NFVIS, allt obefintligt URLs med prefixet enhetens IP omdirigeras till portalens inloggningssida med en 301-statussvarskod. Detta innebär att oavsett URL begärt av en angripare kommer de alltid att få inloggningssidan för att autentisera sig. Alla HTTP-serverförfrågningar omdirigeras till HTTPS och har följande rubriker konfigurerade:
· X-Content-Type-Options · X-XSS-Protection · Content-Security-Policy · X-Frame-Options · Strikt-Transport-Security · Cache-Control
Inaktivera portalen NFVIS-portalåtkomsten är aktiverad som standard. Om du inte planerar att använda portalen, rekommenderas det att inaktivera portalåtkomst med detta kommando:
Konfigurera terminal Systemportalåtkomst inaktiverad commit
All HTTPS-data till och från NFVIS använder Transport Layer Security (TLS) för att kommunicera över nätverket. TLS är efterföljaren till Secure Socket Layer (SSL).
Säkerhetsaspekter 17
HTTPS
Säkerhetsöverväganden
TLS-handskakningen involverar autentisering under vilken klienten verifierar serverns SSL-certifikat med den certifikatutfärdare som utfärdade det. Detta bekräftar att servern är den den säger att den är och att klienten interagerar med ägaren av domänen. Som standard använder NFVIS ett självsignerat certifikat för att bevisa sin identitet för sina kunder. Detta certifikat har en 2048-bitars offentlig nyckel för att öka säkerheten för TLS-krypteringen, eftersom krypteringsstyrkan är direkt relaterad till nyckelstorleken.
Certifikathantering NFVIS genererar ett självsignerat SSL-certifikat när det först installeras. Det är en säkerhetspraxis att ersätta detta certifikat med ett giltigt certifikat undertecknat av en kompatibel certifikatutfärdare (CA). Använd följande steg för att ersätta det självsignerade standardcertifikatet: 1. Skapa en begäran om certifikatsignering (CSR) på NFVIS.
En begäran om certifikatsignering (CSR) är en file med ett block med kodad text som ges till en certifikatutfärdare när man ansöker om ett SSL-certifikat. Detta file innehåller information som bör inkluderas i certifikatet såsom organisationens namn, vanligt namn (domännamn), ort och land. De file innehåller också den publika nyckeln som ska inkluderas i certifikatet. NFVIS använder en 2048-bitars offentlig nyckel eftersom krypteringsstyrkan är högre med en högre nyckelstorlek. För att generera en CSR på NFVIS, kör följande kommando:
nfvis# systemcertifikat signering-begäran [vanligt namn landskod ort organisation organisation-enhet-namn stat] CSR file sparas som /data/intdatastore/download/nfvis.csr. . 2. Skaffa ett SSL-certifikat från en CA med hjälp av CSR. Från en extern värd använder du kommandot scp för att ladda ned begäran om certifikatsignering.
[myhost:/tmp] > scp -P 22222 admin@ :/data/intdatastore/download/nfvis.csrfile-namn>
Kontakta en certifikatutfärdare för att utfärda ett nytt SSL-servercertifikat med denna CSR. 3. Installera CA Signed Certificate.
Från en extern server använder du kommandot scp för att ladda upp certifikatet file till NFVIS till data/intdatastore/uploads/ katalog.
[myhost:/tmp] > scp -P 22222 file> admin@ :/data/intdatastore/uppladdningar
Installera certifikatet i NFVIS med följande kommando.
nfvis# systemcertifikat installation-cert sökväg file:///data/intdatastore/uploads/<certificate file>
4. Byt till att använda CA Signed Certificate. Använd följande kommando för att börja använda det CA-signerade certifikatet istället för det självsignerade standardcertifikatet.
Säkerhetsaspekter 18
Säkerhetsöverväganden
SNMP-åtkomst
nfvis(config)# systemcertifikat use-cert cert-type ca-signerad
SNMP-åtkomst
Simple Network Management Protocol (SNMP) är ett Internet Standard-protokoll för att samla in och organisera information om hanterade enheter på IP-nätverk och för att modifiera den informationen för att ändra enhetens beteende.
Tre betydande versioner av SNMP har utvecklats. NFVIS stöder SNMP version 1, version 2c och version 3. SNMP version 1 och 2 använder community-strängar för autentisering, och dessa skickas i vanlig text. Så det är en säkerhetspraxis att använda SNMP v3 istället.
SNMPv3 ger säker åtkomst till enheter genom att använda tre aspekter: – användare, autentisering och kryptering. SNMPv3 använder USM (användarbaserad säkerhetsmodul) för att kontrollera åtkomst till information tillgänglig via SNMP. SNMP v3-användaren är konfigurerad med en autentiseringstyp, en sekretesstyp samt en lösenordsfras. Alla användare som delar en grupp använder samma SNMP-version, men de specifika säkerhetsnivåinställningarna (lösenord, krypteringstyp, etc.) anges per användare.
Följande tabell sammanfattar säkerhetsalternativen inom SNMP
Modell
Nivå
Autentisering
Encyption
Resultat
v1
noAuthNoPriv
Community String No
Använder en gemenskap
strängmatch för
autentisering.
v2c
noAuthNoPriv
Community String No
Använder en gemenskapssträngmatchning för autentisering.
v3
noAuthNoPriv
Användarnamn
Inga
Använder ett användarnamn
matcha för
autentisering.
v3
authNoPriv
Message Digest 5 nr
Ger
(MD5)
autentiseringsbaserad
or
på HMAC-MD5-96 eller
Säker Hash
HMAC-SHA-96
Algoritm (SHA)
algoritmer.
Säkerhetsaspekter 19
Banners för juridiska meddelanden
Säkerhetsöverväganden
Modell v3
Nivå authPriv
Autentisering MD5 eller SHA
Encyption
Resultat
Datakryptering ger
Standard (DES) eller autentiseringsbaserad
Avancerad
på
Krypteringsstandard HMAC-MD5-96 eller
(AES)
HMAC-SHA-96
algoritmer.
Tillhandahåller DES Cipher-algoritm i Cipher Block Chaining Mode (CBC-DES)
or
AES-krypteringsalgoritm som används i Cipher FeedBack Mode (CFB), med en 128-bitars nyckelstorlek (CFB128-AES-128)
Sedan det antogs av NIST har AES blivit den dominerande krypteringsalgoritmen i hela branschen. För att följa branschens migrering bort från MD5 och mot SHA är det en säkerhetspraxis att konfigurera SNMP v3-autentiseringsprotokollet som SHA och integritetsprotokollet som AES.
För mer information om SNMP, se Introduktion om SNMP
Banners för juridiska meddelanden
Det rekommenderas att en juridisk meddelandebanner finns på alla interaktiva sessioner för att säkerställa att användarna underrättas om säkerhetspolicyn som tillämpas och som de är föremål för. I vissa jurisdiktioner är civilrättsliga och/eller straffrättsliga lagföring av en angripare som bryter sig in i ett system enklare, eller till och med nödvändigt, om en laglig meddelandebanner presenteras som informerar obehöriga användare om att deras användning faktiskt är obehörig. I vissa jurisdiktioner kan det också vara förbjudet att övervaka en obehörig användares aktivitet om de inte har underrättats om avsikten att göra det.
Juridiska underrättelsekrav är komplexa och varierar i varje jurisdiktion och situation. Även inom jurisdiktioner varierar juridiska åsikter. Diskutera det här problemet med din egen juridiska ombud för att säkerställa att meddelandebannern uppfyller företagets, lokala och internationella juridiska krav. Detta är ofta avgörande för att säkerställa lämpliga åtgärder i händelse av ett säkerhetsintrång. I samarbete med företagets juridiska rådgivare inkluderar uttalanden som kan inkluderas i en banner för juridiska meddelanden:
· Meddelande om att systemets åtkomst och användning endast tillåts av särskilt auktoriserad personal, och kanske information om vem som kan godkänna användning.
· Meddelande om att obehörig åtkomst och användning av systemet är olagligt och kan bli föremål för civilrättsliga och/eller straffrättsliga påföljder.
· Meddelande om att åtkomst och användning av systemet kan loggas eller övervakas utan ytterligare meddelande, och de resulterande loggarna kan användas som bevis i domstol.
· Ytterligare specifika meddelanden som krävs enligt lokala lagar.
Säkerhetsaspekter 20
Säkerhetsöverväganden
Fabriksåterställning
Ur en säkerhet snarare än en juridisk synpunkt view, bör en banner med juridiska meddelanden inte innehålla någon specifik information om enheten, såsom dess namn, modell, programvara, plats, operatör eller ägare eftersom denna typ av information kan vara användbar för en angripare.
Följande är somampen banner för juridiska meddelanden som kan visas före inloggning:
OBEHÖRIG ÅTKOMST TILL DENNA ENHET ÄR FÖRBJUDEN Du måste ha uttrycklig, auktoriserad tillstånd för att komma åt eller konfigurera den här enheten. Obehöriga försök och åtgärder för att komma åt eller använda
detta system kan leda till civilrättsliga och/eller straffrättsliga påföljder. Alla aktiviteter som utförs på den här enheten loggas och övervakas
Notera Presentera en banner för juridiska meddelanden som godkänts av företagets juridiska rådgivare.
NFVIS tillåter konfigurering av en banner och meddelande för dagen (MOTD). Bannern visas innan användaren loggar in. När användaren loggar in på NFVIS ger en systemdefinierad banner upphovsrättsinformation om NFVIS, och meddelande-of-the-day (MOTD), om det är konfigurerat, kommer att visas, följt av kommandoraden eller portalen view, beroende på inloggningsmetoden.
Det rekommenderas att en inloggningsbanner implementeras för att säkerställa att en juridisk meddelandebanner visas på alla åtkomstsessioner för enhetshantering innan en inloggningsuppmaning presenteras. Använd detta kommando för att konfigurera bannern och MOTD.
nfvis(config)# banner-motd banner motd
För mer information om bannerkommandot, se Konfigurera banner, Dagens meddelande och Systemtid.
Fabriksåterställning
Fabriksåterställning tar bort all kundspecifik data som har lagts till enheten sedan leveransen. De raderade uppgifterna inkluderar konfigurationer, logg files, VM-bilder, anslutningsinformation och användarinloggningsuppgifter.
Det ger ett kommando för att återställa enheten till fabriksinställningarna och är användbart i följande scenarier:
· Return Material Authorization (RMA) för en enhet – Om du måste returnera en enhet till Cisco för RMA, använd fabriksåterställning för att ta bort alla kundspecifika data.
· Återställa en komprometterad enhet – Om nyckelmaterialet eller användaruppgifterna som lagrats på en enhet äventyras, återställ enheten till fabriksinställningarna och konfigurera sedan om enheten.
· Om samma enhet behöver återanvändas på en annan plats med en ny konfiguration, utför en fabriksåterställning för att ta bort den befintliga konfigurationen och föra den till ett rent tillstånd.
NFVIS tillhandahåller följande alternativ inom fabriksåterställning:
Fabriksåterställningsalternativ
Data raderade
Data bevaras
alla
All konfiguration, uppladdad bild Administratörskontot behålls och
files, virtuella datorer och loggar.
lösenordet kommer att ändras till
Anslutning till enheten kommer att vara fabriksstandardlösenord.
förlorad.
Säkerhetsaspekter 21
Infrastructure Management Network
Säkerhetsöverväganden
Fabriksåterställningsalternativ alla-utom-bilder
allt-utom-bilder-anslutning
tillverkning
Data raderade
Data bevaras
All konfiguration utom bild Bildkonfiguration, registrerad
konfiguration, virtuella datorer och uppladdade bilder och loggar
bild files.
Administratörskontot behålls och
Anslutning till enheten kommer att lösenordet kommer att ändras till
förlorad.
fabriksstandardlösenord.
All konfiguration utom bild, bilder, nätverk och anslutning
nätverk och anslutning
relaterad konfiguration, registrerad
konfiguration, virtuella datorer och uppladdade bilder och loggar.
bild files.
Administratörskontot behålls och
Anslutning till enheten är
den tidigare konfigurerade admin
tillgänglig.
lösenordet kommer att bevaras.
All konfiguration utom bildkonfiguration, virtuella datorer, uppladdad bild files och loggar.
Anslutningen till enheten kommer att försvinna.
Bildrelaterad konfiguration och registrerade bilder
Administratörskontot behålls och lösenordet kommer att ändras till fabriksstandardlösenordet.
Användaren måste välja lämpligt alternativ noggrant baserat på syftet med fabriksåterställningen. För mer information, se Återställa till fabriksinställningar.
Infrastructure Management Network
Ett infrastrukturhanteringsnätverk avser nätverket som bär kontroll- och hanteringsplantrafiken (såsom NTP, SSH, SNMP, syslog, etc.) för infrastrukturenheterna. Enhetsåtkomst kan ske via konsolen, såväl som via Ethernet-gränssnitten. Denna kontroll- och hanteringsplanstrafik är avgörande för nätverksdriften och ger insyn i och kontroll över nätverket. Följaktligen är ett väldesignat och säkert nätverk för infrastrukturhantering avgörande för den övergripande säkerheten och driften av ett nätverk. En av de viktigaste rekommendationerna för ett säkert nätverk för infrastrukturhantering är att separera hantering och datatrafik för att säkerställa fjärrhantering även under hög belastning och hög trafik. Detta kan uppnås med hjälp av ett dedikerat hanteringsgränssnitt.
Följande är metoderna för implementering av nätverk för infrastrukturhantering:
Out-of-band Management
Ett Out-of-band Management-nätverk (OOB) består av ett nätverk som är helt oberoende och fysiskt skilt från det datanätverk som det hjälper till att hantera. Detta kallas ibland också för ett datakommunikationsnätverk (DCN). Nätverksenheter kan ansluta till OOB-nätverket på olika sätt: NFVIS stöder ett inbyggt hanteringsgränssnitt som kan användas för att ansluta till OOB-nätverket. NFVIS tillåter konfiguration av ett fördefinierat fysiskt gränssnitt, MGMT-porten på ENCS, som ett dedikerat hanteringsgränssnitt. Att begränsa hanteringspaket till angivna gränssnitt ger större kontroll över hanteringen av en enhet, vilket ger mer säkerhet för den enheten. Andra fördelar inkluderar förbättrad prestanda för datapaket på icke-hanteringsgränssnitt, stöd för nätverksskalbarhet,
Säkerhetsaspekter 22
Säkerhetsöverväganden
Pseudo out-of-band Management
behov av färre åtkomstkontrollistor (ACL) för att begränsa åtkomsten till en enhet och förhindra att hanteringspaketöversvämningar når CPU:n. Nätverksenheter kan också ansluta till OOB-nätverket via dedikerade datagränssnitt. I det här fallet bör ACL:er distribueras för att säkerställa att hanteringstrafik endast hanteras av de dedikerade gränssnitten. För ytterligare information, se Konfigurera IP-mottagnings-ACL och port 22222 och Management Interface ACL.
Pseudo out-of-band Management
Ett pseudo-out-of-band-hanteringsnätverk använder samma fysiska infrastruktur som datanätverket men ger logisk separation genom virtuell separering av trafik, genom att använda VLAN. NFVIS stöder att skapa VLAN och virtuella bryggor för att hjälpa till att identifiera olika trafikkällor och separera trafik mellan virtuella datorer. Att ha separata bryggor och VLAN isolerar det virtuella maskinnätverkets datatrafik och hanteringsnätverket, vilket ger trafiksegmentering mellan virtuella datorer och värden. För ytterligare information se Konfigurera VLAN för NFVIS Management Traffic.
In-band Management
Ett hanteringsnätverk inom bandet använder samma fysiska och logiska vägar som datatrafiken. I slutändan kräver denna nätverksdesign en analys per kund av risk kontra fördelar och kostnader. Några allmänna överväganden inkluderar:
· Ett isolerat OOB-hanteringsnätverk maximerar synlighet och kontroll över nätverket även under störande händelser.
· Att sända nätverkstelemetri över ett OOB-nätverk minimerar risken för störningar av just den information som ger kritisk nätverkssynlighet.
· In-band management-åtkomst till nätverksinfrastruktur, värdar, etc. är sårbar för fullständig förlust i händelse av en nätverksincident, vilket tar bort all nätverkssynlighet och kontroll. Lämpliga QoS-kontroller bör införas för att mildra denna händelse.
· NFVIS har gränssnitt som är dedikerade till enhetshantering, inklusive seriella konsolportar och Ethernet-hanteringsgränssnitt.
· Ett OOB-hanteringsnätverk kan vanligtvis distribueras till en rimlig kostnad, eftersom hanteringsnätverkstrafik vanligtvis inte kräver hög bandbredd eller högpresterande enheter och bara kräver tillräcklig porttäthet för att stödja anslutningen till varje infrastrukturenhet.
Lokalt lagrad informationsskydd
Skydda känslig information
NFVIS lagrar viss känslig information lokalt, inklusive lösenord och hemligheter. Lösenord bör i allmänhet underhållas och kontrolleras av en centraliserad AAA-server. Men även om en centraliserad AAA-server är utplacerad, krävs vissa lokalt lagrade lösenord i vissa fall, såsom lokal reserv om AAA-servrar inte är tillgängliga, användarnamn för speciell användning, etc. Dessa lokala lösenord och andra känsliga
Säkerhetsaspekter 23
File Överföra
Säkerhetsöverväganden
information lagras på NFVIS som hash så att det inte är möjligt att återställa de ursprungliga referenserna från systemet. Hashing är en allmänt accepterad branschnorm.
File Överföra
Files som kan behöva överföras till NFVIS-enheter inkluderar VM-avbildning och NFVIS-uppgradering files. Den säkra överföringen av files är avgörande för säkerheten i nätverksinfrastrukturen. NFVIS stöder Secure Copy (SCP) för att säkerställa säkerheten för file överföra. SCP förlitar sig på SSH för säker autentisering och transport, vilket möjliggör säker och autentiserad kopiering av files.
En säker kopia från NFVIS initieras genom kommandot scp. Kommandot säker kopia (scp) tillåter endast adminanvändaren att kopiera säkert files från NFVIS till ett externt system, eller från ett externt system till NFVIS.
Syntaxen för scp-kommandot är:
scp
Vi använder port 22222 för NFVIS SCP-servern. Som standard är denna port stängd och användare kan inte skydda kopieringen files in i NFVIS från en extern klient. Om det finns ett behov av att SCP a file från en extern klient kan användaren öppna porten med:
systeminställningar ip-receive-acl (adress)/(masklängd) tjänst scpd prioritet (nummer) åtgärd acceptera
begå
För att förhindra användare från att komma åt systemkataloger kan säker kopiering endast utföras till eller från intdatastore:, extdatastore1:, extdatastore2:, usb: och nfs:, om tillgängligt. Säker kopiering kan också utföras från loggar: och teknisk support:
Skogsavverkning
NFVIS-åtkomst- och konfigurationsändringar loggas som granskningsloggar för att registrera följande information: · Vem fick åtkomst till enheten · När loggade en användare in · Vad gjorde en användare när det gäller värdkonfigurationen och VM-livscykeln · När loggade en användare av · Misslyckade åtkomstförsök · Misslyckade autentiseringsbegäranden · Misslyckade auktoriseringsbegäranden
Denna information är ovärderlig för kriminalteknisk analys i händelse av obehöriga försök eller åtkomst, såväl som för konfigurationsändringsproblem och för att hjälpa till att planera gruppadministrationsändringar. Den kan också användas i realtid för att identifiera onormala aktiviteter som kan indikera att en attack äger rum. Denna analys kan korreleras med information från ytterligare externa källor, såsom IDS och brandväggsloggar.
Säkerhetsaspekter 24
Säkerhetsöverväganden
Säkerhet för virtuell maskin
Alla nyckelhändelser på NFVIS skickas som händelsemeddelanden till NETCONF-abonnenter och som sysloggar till de konfigurerade centrala loggningsservrarna. För mer information om syslog-meddelanden och händelseaviseringar, se Bilaga.
Säkerhet för virtuell maskin
Det här avsnittet beskriver säkerhetsfunktioner relaterade till registrering, distribution och drift av virtuella maskiner på NFVIS.
VNF säker start
NFVIS stöder Open Virtual Machine Firmware (OVMF) för att aktivera UEFI säker start för virtuella maskiner som stöder säker uppstart. VNF Secure boot verifierar att varje lager i VM-startprogramvaran är signerad, inklusive starthanteraren, operativsystemets kärna och operativsystemsdrivrutiner.
För mer information se Secure Boot of VNFs.
VNC Console Access Protection
NFVIS tillåter användaren att skapa en Virtual Network Computing-session (VNC) för att komma åt en utplacerad virtuell dators fjärrskrivbord. För att möjliggöra detta öppnar NFVIS dynamiskt en port som användaren kan ansluta med sin web webbläsare. Den här porten lämnas endast öppen i 60 sekunder för en extern server att starta en session till den virtuella datorn. Om ingen aktivitet ses inom denna tid är hamnen stängd. Portnumret tilldelas dynamiskt och tillåter därigenom endast en engångsåtkomst till VNC-konsolen.
nfvis# vncconsole start deployment-name 1510614035 vm-name ROUTER vncconsole-url :6005/vnc_auto.html
Pekar din webbläsare till https:// :6005/vnc_auto.html kommer att ansluta till ROUTER VM:s VNC-konsol.
Säkerhetsaspekter 25
Krypterade VM-konfigurationsdatavariabler
Säkerhetsöverväganden
Krypterade VM-konfigurationsdatavariabler
Under VM-distribution tillhandahåller användaren en dag-0-konfiguration file för VM. Detta file kan innehålla känslig information som lösenord och nycklar. Om denna information skickas som klartext visas den i loggen files och interna databasposter i klartext. Denna funktion tillåter användaren att flagga en konfigurationsdatavariabel som känslig så att dess värde krypteras med AES-CFB-128-kryptering innan den lagras eller skickas till interna delsystem.
Mer information finns i VM-distributionsparametrar.
Kontrollsummeverifiering för fjärrbildregistrering
För att registrera en fjärrbelägen VNF-bild anger användaren dess plats. Bilden måste laddas ner från en extern källa, till exempel en NFS-server eller en fjärransluten HTTPS-server.
För att veta om en nedladdad file är säker att installera, är det viktigt att jämföra files kontrollsumma innan du använder den. Att verifiera kontrollsumman hjälper till att säkerställa att file skadades inte under nätverksöverföring eller modifierades av en skadlig tredje part innan du laddade ner den.
NFVIS stöder kontrollsumman och checksum_algorithm-alternativen för att användaren ska kunna tillhandahålla den förväntade kontrollsumman och checksummaalgoritmen (SHA256 eller SHA512) som ska användas för att verifiera kontrollsumman för den nedladdade bilden. Bildskapandet misslyckas om kontrollsumman inte matchar.
Certifieringsvalidering för fjärrbildregistrering
För att registrera en VNF-bild som finns på en HTTPS-server måste bilden laddas ner från den fjärranslutna HTTPS-servern. För att säkert ladda ner denna bild verifierar NFVIS serverns SSL-certifikat. Användaren måste ange antingen sökvägen till certifikatet file eller PEM-formatets certifikatinnehåll för att möjliggöra denna säkra nedladdning.
Mer information finns i avsnittet om certifikatvalidering för bildregistrering
VM-isolering och resursprovisionering
Arkitekturen Network Function Virtualization (NFV) består av:
· Virtualiserade nätverksfunktioner (VNF), som är virtuella maskiner som kör mjukvaruapplikationer som levererar nätverksfunktionalitet som en router, brandvägg, lastbalanserare och så vidare.
· Nätverksfunktioner virtualiseringsinfrastruktur, som består av infrastrukturkomponenterna – dator, minne, lagring och nätverk, på en plattform som stöder den nödvändiga programvaran och hypervisorn.
Med NFV virtualiseras nätverksfunktioner så att flera funktioner kan köras på en enda server. Som ett resultat behövs mindre fysisk hårdvara, vilket möjliggör resurskonsolidering. I den här miljön är det viktigt att simulera dedikerade resurser för flera VNF från ett enda fysiskt hårdvarusystem. Med hjälp av NFVIS kan virtuella datorer distribueras på ett kontrollerat sätt så att varje virtuell dator får de resurser den behöver. Resurser delas upp efter behov från den fysiska miljön till de många virtuella miljöerna. De individuella VM-domänerna är isolerade så att de är separata, distinkta och säkra miljöer som inte tävlar med varandra om delade resurser.
Virtuella datorer kan inte använda fler resurser än vad som tillhandahålls. Detta undviker ett Denial of Service-villkor från en virtuell dator som förbrukar resurserna. Som ett resultat är CPU, minne, nätverk och lagring skyddade.
Säkerhetsaspekter 26
Säkerhetsöverväganden
CPU-isolering
CPU-isolering
NFVIS-systemet reserverar kärnor för infrastrukturprogramvaran som körs på värden. Resten av kärnorna är tillgängliga för VM-distribution. Detta garanterar att den virtuella datorns prestanda inte påverkar NFVIS-värdens prestanda. VM:ar med låg latens NFVIS tilldelar uttryckligen dedikerade kärnor till virtuella datorer med låg latens som är utplacerade på den. Om den virtuella datorn kräver 2 vCPU:er tilldelas den 2 dedikerade kärnor. Detta förhindrar delning och överteckning av kärnor och garanterar prestandan hos virtuella datorer med låg latens. Om antalet tillgängliga kärnor är mindre än antalet vCPU:er som begärts av en annan virtuell dator med låg latens, förhindras distributionen eftersom vi inte har tillräckliga resurser. VM:er med icke låg latens NFVIS tilldelar delbara processorer till virtuella datorer med icke-låg latens. Om den virtuella datorn kräver 2 vCPU:er tilldelas den 2 processorer. Dessa 2 processorer kan delas med andra virtuella datorer utan låg latens. Om antalet tillgängliga processorer är mindre än antalet vCPU:er som begärts av en annan virtuell dator utan låg latens, är distributionen fortfarande tillåten eftersom denna virtuella dator kommer att dela processorn med befintliga virtuella datorer utan låg latens.
Minnesallokering
NFVIS-infrastrukturen kräver en viss mängd minne. När en virtuell dator distribueras görs en kontroll för att säkerställa att det tillgängliga minnet efter att det minne som krävs för infrastrukturen och tidigare distribuerade virtuella datorer har reserverats är tillräckligt för den nya virtuella datorn. Vi tillåter inte minnesöverteckning för virtuella datorer.
Säkerhetsaspekter 27
Förvaringsisolering
VM:er tillåts inte direkt åtkomst till värden file system och lagring.
Förvaringsisolering
Säkerhetsöverväganden
ENCS-plattformen stöder ett internt datalager (M2 SSD) och externa diskar. NFVIS är installerat på den interna datalagringen. VNF:er kan också distribueras på denna interna datalagring. Det är en säkerhetspraxis att lagra kunddata och distribuera virtuella maskiner för kundapplikationer på de externa diskarna. Att ha fysiskt separata diskar för systemet files vs applikationen files hjälper till att skydda systemdata från korruption och säkerhetsproblem.
·
Gränssnittsisolering
Single Root I/O Virtualization eller SR-IOV är en specifikation som tillåter isolering av PCI Express (PCIe) resurser såsom en Ethernet-port. Med SR-IOV kan en enda Ethernet-port framstå som flera, separata, fysiska enheter som kallas virtuella funktioner. Alla VF-enheter på den adaptern delar samma fysiska nätverksport. En gäst kan använda en eller flera av dessa virtuella funktioner. En virtuell funktion visas för gästen som ett nätverkskort, på samma sätt som ett vanligt nätverkskort skulle framstå för ett operativsystem. Virtuella funktioner har nästan inbyggd prestanda och ger bättre prestanda än para-virtualiserade drivrutiner och emulerad åtkomst. Virtuella funktioner ger dataskydd mellan gäster på samma fysiska server eftersom data hanteras och kontrolleras av hårdvaran. NFVIS VNF:er kan använda SR-IOV-nätverk för att ansluta till WAN- och LAN-bakplansportar.
Säkerhetsaspekter 28
Säkerhetsöverväganden
Säker utvecklingslivscykel
Varje sådan virtuell dator äger ett virtuellt gränssnitt och dess relaterade resurser för att uppnå dataskydd bland virtuella datorer.
Säker utvecklingslivscykel
NFVIS följer en Secure Development Lifecycle (SDL) för mjukvara. Detta är en repeterbar, mätbar process designad för att minska sårbarheter och förbättra säkerheten och motståndskraften hos Cisco-lösningar. Cisco SDL tillämpar branschledande metoder och teknik för att bygga pålitliga lösningar som har färre upptäckta produktsäkerhetsincidenter. Varje NFVIS-release går igenom följande processer.
· Följer Ciscos interna och marknadsbaserade produktsäkerhetskrav · Registrering av programvara från tredje part med ett centralt arkiv hos Cisco för spårning av sårbarheter · Regelbundet patchar mjukvara med kända korrigeringar för CVE. · Utforma mjukvara med säkerhet i åtanke · Följa säker kodningsmetoder som att använda kontrollerade vanliga säkerhetsmoduler som CiscoSSL, köra
Statisk analys och implementering av indatavalidering för att förhindra kommandoinjektion, etc. · Använda Application Security-verktyg som IBM AppScan, Nessus och andra Ciscos interna verktyg.
Säkerhetsaspekter 29
Säker utvecklingslivscykel
Säkerhetsöverväganden
Säkerhetsaspekter 30
Dokument/resurser
 |
CISCO Enterprise Network Function Virtualization Infrastructure Software [pdf] Användarhandbok Enterprise Network Function Virtualization Infrastructure Software, Enterprise, Network Function Virtualization Infrastructure Software, Virtualization Infrastructure Software, Infrastructure Software |
