SNMP v3: kryptering, autentisering och migration från v2c
Vad är SNMP v3 och varför är det viktigt?
SNMP v3 är den tredje och nyaste versionen av Simple Network Management Protocol, det protokoll som används för att övervaka och konfigurera nätverksenheter. Standarden definieras i RFC 3411 till RFC 3418 och publicerades 2002. SNMP v3 tillför två saker som tidigare versioner saknar helt: autentisering med kryptografisk integritetskontroll och kryptering av meddelandeinnehåll.
Den största förändringen jämfört med SNMP v1 och SNMP v2c är säkerhetsmodellen. I de äldre versionerna används så kallade community strings, oftast ”public” för läsning och ”private” för skrivning. Dessa skickas i klartext över nätverket och fungerar som ett delat lösenord. Vem som helst som kan avlyssna trafiken ser dem och kan därefter ställa frågor till eller manipulera enheterna.
De tre säkerhetsnivåerna i SNMP v3
SNMP v3 har tre olika säkerhetsnivåer som du väljer per användare. Valet styr vad som verifieras och vad som krypteras. Skillnaderna är följande:
| Nivå | Vad nivån ger |
|---|---|
| noAuthNoPriv | Varken autentisering eller kryptering. Användarnamn skickas men verifieras inte. Bör undvikas i produktion. |
| authNoPriv | Autentisering med HMAC-SHA, men meddelandena skickas okrypterade. Skyddar mot förfalskning men inte avlyssning. |
| authPriv | Både autentisering och kryptering med AES eller äldre DES. Den enda nivå som ska användas i en produktionsmiljö. |
Bara authPriv ger fullt skydd. Du autentiserar avsändaren med HMAC-SHA-1, HMAC-SHA-256 eller HMAC-SHA-512 och krypterar trafiken med AES-128, AES-192 eller AES-256. Den ursprungliga DES-krypteringen i RFC 3414 är idag betraktad som osäker och bör inte användas.
SNMP v1 mot v2c mot v3
Tre versioner av SNMP är fortfarande i bruk. Varje version har specifika styrkor och svagheter. Här är en jämförelse av det som faktiskt spelar roll i drift:
| Egenskap | Versionerna jämfört |
|---|---|
| Autentisering | v1: community string i klartext • v2c: community string i klartext • v3: användarnamn med HMAC-signatur |
| Kryptering | v1: ingen • v2c: ingen • v3: AES eller DES (DES är osäker) |
| Räknare för bandbredd | v1: 32 bitar • v2c: 64 bitar • v3: 64 bitar |
| Bulkhämtning (GETBULK) | v1: nej • v2c: ja • v3: ja |
| Användarbaserad åtkomstkontroll | v1: nej • v2c: nej • v3: ja, via VACM |
32-bitars räknarna i SNMP v1 räcker bara till 4,29 miljarder, vilket innebär att en räknare på ett 1 Gbit-gränssnitt rundar av på cirka 34 sekunder. För moderna nätverk är 64-bitars räknare, som finns från v2c och uppåt, ett krav.
Varför är klartextrisken så allvarlig?
Många nätverksadministratörer accepterar SNMP v2c med motiveringen att hanteringsnätet är skyddat eller internt. Klartextrisken är dock större än många tror. Anledningarna är flera:
- Interna hot: En anställd eller konsult med fysisk åtkomst kan ofta avlyssna hanteringstrafik och få community strings
- Sidoflyttning: En angripare som tagit sig in i nätet hittar SNMP-trafik snabbt och använder den för att kartlägga miljön
- Felaktig segmentering: Hanteringsnät glider ofta över i produktionsnät av misstag, vilket exponerar trafiken på fler vägar än man tror
- Konfigurationsändringar: Med skriv-community kan en angripare ändra konfigurationen på switchar, brandväggar och routrar direkt
Branscher med strikta krav på dataskydd, exempelvis sjukvård, bank och offentlig förvaltning, har SNMP v3 som krav i sina säkerhetsregelverk. PCI DSS kräver bland annat att klartextprotokoll byts ut mot krypterade motsvarigheter.
Så konfigurerar du SNMP v3 på en switch
Att gå från SNMP v2c till v3 kräver att du skapar en användare, väljer säkerhetsnivå och tilldelar åtkomstvyer. Stegen ser olika ut beroende på tillverkare, men den övergripande processen är likadan. På en Cisco-switch ser den ut så här:
- Skapa en SNMP-grupp som styr vad användare i gruppen får göra:
snmp-server group GROUP1 v3 priv read VIEW1 - Skapa en användare med autentisering och kryptering:
snmp-server user USER1 GROUP1 v3 auth sha PASSWORD1 priv aes 128 PASSWORD2 - Definiera en åtkomstvy som styr vilka MIB-grenar gruppen får läsa:
snmp-server view VIEW1 internet included - Verifiera konfigurationen med
show snmp userpå switchen - Konfigurera ditt övervakningssystem (NMS) med samma användarnamn, autentiseringsnyckel och privacynyckel
Prestandapåverkan
Kryptering och autentisering kostar processorkraft, både på enheten som svarar och på övervakningssystemet som frågar. På moderna enheter är skillnaden liten, men på äldre eller resurssvaga enheter kan SNMP v3 belasta processorn märkbart. För riktigt stora övervakningsmiljöer, med tiotusentals enheter och täta polls, kan flera SNMP-pollers krävas där en SNMP v2c-installation klarade sig med en.
Mät processorbelastningen på en handfull representativa enheter innan migrationen rullas ut i hela parken. Vid behov kan poll-intervallet glesas ut eller bulkhämtning användas mer aggressivt för att minska antalet anrop.
Övergång från v2c till v3
De flesta organisationer kör SNMP v2c och v3 parallellt under en övergångsperiod. Det är inget problem, eftersom enheterna kan ha båda versionerna aktiverade samtidigt. En typisk migrationsplan ser ut så här:
- Inventera vilka enheter som har stöd för SNMP v3 (gäller i princip allt från 2010 och senare)
- Aktivera v3 parallellt med v2c på en kontrollerad uppsättning enheter
- Flytta över övervakningssystemet att läsa via v3 från de aktiverade enheterna
- Stäng av v2c på enheter där v3 fungerar stabilt
- Mediera kvarvarande enheter utan v3-stöd via en separat segmenterad zon
Enheter som inte stödjer SNMP v3 är ofta så pass gamla att de bör bytas ut av andra skäl. För kritiska enheter som måste behållas finns mediationsprodukter som översätter v1/v2c-trafik internt och presenterar v3 utåt.
Vanliga misstag att undvika
Tre misstag är extra vanliga vid övergång till SNMP v3. Den som känner till dem i förväg sparar mycket felsökningstid:
- Använda DES istället för AES: DES är från 1970-talet och kan brute force-attackeras. Välj alltid AES-128 eller starkare
- Korta lösenord: SNMP v3 kräver minst åtta tecken, men 16 till 24 tecken är ett bättre val för att stå emot offline-attacker
- Glömma EngineID-konsistens: Klonas en enhet utan att EngineID nollställs uppstår problem med dubbletter
