Správa sítí vyžaduje zajištění odpovídajícího dohledu, to znamená zjišťování aktuálních událostí (monotoring) a případně změny nastavení. Jak to je s ochranou SNMP z pohledu kryptografie?
Pro zjišťování informací o stavu zařízení a případně jeho nastavení slouží dlouhá léta protokol SNMP. V současnosti existuje ve třech verzích, které se výrazně liší možnostmi a hlavně zabezpečením protokolu. Bezpečnostní v tomto ohledu nemám na mysli zranitelnosti v kódu, ale ochranu důvěrnosti (Confidentiality), celistvosti (integrity), nedomítnutelnosti (non-repudiation) a autenticity.
Vlastní protokol je založen na využívá PDU (Program Data Unit), specifikovaných ve standardech ITU-T. Koncové zařízení musí pracovat jako agent, schopný přijímat povely a odesílat data. Správa sítě (NMS – Network Management Station) data přijímá a vyhodnocuje dle definic v MIB souborech (Management Information Base). Definice popisují vlastnosti systému, pro každou vlastnost je přiděleno samostatné OID stejně, jako v X.509 certifikátech. Každé z těchto vlastností může být přidělena jedna nebo více hodnot.
| Port | Popis | Verze |
| UDP/161 | Port, na kterém naslouchá agent | v1, v2, v3 |
| UDP/162 | Port, na kterém naslouchá manager (SNMP Trap) | v1, v2, v3 |
| TCP/161 | Port, na kterém naslouchá agent | v2, v3 (vzácné) |
| TCP/162 | Port, na kterém naslouchá manager (SNMP Trap) | v2, v3 (vzácné) |
| UDP/10161 | SNMP/DTLS port, na kterém naslouchá agent | v3 (raritní) |
| UDP/10162 | SNMP/DTLS port, na kterém naslouchá manager (SNMP Trap) | v3 (raritní) |
| TCP/10161 | SNMP/TLS port na kterém naslouchá agent | v3 (prakticky neexistuje) |
| TCP/10162 | SNMP/TLS port, na kterém naslouchá manager (SNMP Trap) | v3 (prakticky neexistuje) |
Tento protokol vznikl v roce 1988 a používal comunity (komunita, název oprávnění) pro čtení a zápis. Tyto comunity byly zasílány v textovém tvaru, bez jakékoliv ochrany. Uvedená data bylo možné číst bez jakýchkoliv omezení. Následné zaslání odpovídajících nastavení nekontrolovalo nic jiného, než odpovídající řetězec. V případě správnosti se nastavení aplikovalo.
Co je horší, existovaly standardní hodnoty pro comunity. Pro monitorování se používalo většinou public, u některých výrobců read nebo monitor, pro zápis pak private, občas i write.
Protože koncové strany nepodporují žádnou formu identifikace a autentizace, je jakékoliv použití TLS/DTLS pro ochranu nesmyslné. Tento protokol je extrémně zastaralý a přes jeho univerzálnost je vhodné se jeho nasazení vyhnout. Pokud je nutné ho využít, měl by pouze dovolit poskytovat informace o stavu na konkrétní body, agent by měl být chráněn paketovým filtrem pro omezení komunikace.
V roce 1993 přišel nový standard SNMPv2, který se po drobných peripetiích vyvinul v SNMPv2c. To je aktuální používaná verze. Přinesl výraznou optimalizaci, podporu TCP protokolu (alespoň papírově), přinesl přechod z 32-bit na 64-bit hodnoty, dále dovolil začít používat SNMPv2 agenta jako proxy službu pro SNMPv1 ... nepřinesl žádnou změnu v bezpečnosti. I zde je případné použití TLS/DTLS pro ochranu nesmyslem a proto platí stejná pravidla jako u SNMPv1.
Výraznou změnu přinesl v roce 1999 protokol SNMPv3. Zamítl původně používatné comunity stringy, začal využívat autentizaci, ochranu důvěrnosti a ochranu integrity. Vlastní kryptografické algoritmy pro řízení ochrany na úrovni protokolu jsou součástí USM (User Security Module), v případě použití TLS/DTLS se používá TSM (Transport Security Module). Uvedené moduly lze kombinovat, doporučuje se používat stejné algoritmy. TSM vyžaduje použití X.509 certifikátů, proto je potřeba před implementací ověřit odpovídající podporu na straně agentů a NMS serveru.
TSM je volitelný modul, který podporuje následující sady protokolů:
USM je povinný modul, který má tři základní stavy. Stav AuthNoPriv podporuje autenticitu a ochranu integrity, stav AuthPriv porpoduje autentizaci, ochranu důvěrnosti a ochranu integrity.
Z uvedených parametrů je zřejmé, že komunikace v módu NoAuthPriv je zcela nevhodná, nezabezpečuje žádnou ochranu a je na stejné úrovni jako SNMPv1 a SNMPv2. Komunikace v módu AuthNoPriv má význam jenom v omezené oblasti a to pouze pro monitoring. Pro jiné účely je nevhodná. Poslední je komunikace v módu AuthPriv, kterou je možné použít jak pro monitoring, tak pro nastavení parametrů bezpečným způsobem.
Přes možnost komunikace zabezpečeným kanálem je vhodné se zamyslet nad nastavením TSM modulu. Co je důležité a opomíjené, protože kód na daných prvcích může mít bezpečnostní vady, je vhodné zajistit pro správu těchto zařízení samostatnou a fyzicky oddělenou síť.
V případě komunikace v módech AuthNoPriv a AuthPriv je možné dle funkce využít následujících skupin algoritmů.
Algoritmy pro zajištění důvěrnosti (confidentiality):
| Algoritmus | Mód užití | Standard | MIB OID | KDF hesla | Poznámky |
| Žádná šifra | RFC 3414 | 1.3.6.1.6.3.10.1.2.1 (usmNoPrivProtocol) | Nebezpečné | ||
| DES | CBC | RFC 3414 | 1.3.6.1.6.3.10.1.2.2.1 (usmDESPrivProtocol) | Dle hash* | Široká podpora |
| 3DES | CBC | RFC 3826 | 1.3.6.1.4.1.9.12.6.1.3 (cusm3DES168PrivProtocol) | Dle hash* | Prakticky se nepoužívá |
| AES-128 | CFB | RFC 3826 | 1.3.6.1.6.3.20.1.1 (usmAesCfb128Protocol) | Dle hash* | Široká podpora |
| AES-192 | CFB | 1.3.6.1.4.1.9.12.6.1.1 (cusmAESCfb192PrivProtocol) | Dle hash* | Vzácné | |
| AES-256 | CFB | 1.3.6.1.4.1.9.12.6.1.2 (cusmAESCfb256PrivProtocol) | Dle hash* | Podpora u některých výrobců | |
| 3DES(EDE) | CFB | Dle hash* | Prakticky se nepoužívá | ||
| IDEA | CFB | N/A (Vendor specific) | N/A | Nestandardní (2002-2005) |
Algoritmy pro zajištění integrity:
| Algoritmus | MIB OID | Standard | Poznámky |
| Bez ověření | 1.3.6.1.6.3.10.1.1.1 | RFC 3414 | Použití u autentizace zároveň vypíná kontrolu integrity |
| HMAC-MD5-96 | 1.3.6.1.6.3.10.1.1.2.1 | RFC 3414 | Zlomené, výstup HMAC funkce je oříznut na 96b |
| HMAC-SHA-96 | 1.3.6.1.6.3.10.1.1.2.2 | RFC 3414 | Zlomené, výstup HMAC funkce je oříznut na 96b |
| SHA-1 (TSM variant) | 1.3.6.1.6.3.10.1.1.3 | RFC 6353 | Zlomené, odvozuje klíč pro TSM a zajištuje integritu |
| HMAC-SHA2-224 | 1.3.6.1.6.3.10.1.1.4 | RFC 7860 | Zastaralé, HMAC |
| HMAC-SHA2-256 | 1.3.6.1.6.3.10.1.1.5 | RFC 7860 | HMAC, aktuální implementace (do roku 2030) |
| HMAC-SHA2-384 | 1.3.6.1.6.3.10.1.1.6 | RFC 7860 | HMAC, vzácné |
| HMAC-SHA2-512 | 1.3.6.1.6.3.10.1.1.7 | RFC 7860 | HMAC, vzácné |
Algoritmy pro zajištění autentizace:
| Algoritmus | MIB OID | Standard | Poznámky |
| Bez ověření | 1.3.6.1.6.3.10.1.1.1 | RFC 3414 | usmNoAuthProtocol |
| MD5 (HMAC‑MD5) | 1.3.6.1.6.3.10.1.1.2 | RFC 3414 | usmHMACMD5AuthProtocol, zlomené |
| SHA1 (HMAC‑SHA‑1) | 1.3.6.1.6.3.10.1.1.3 | RFC 3628 | usmHMACSHAAuthProtocol, zlomené |
| SHA2-224 (HMAC‑SHA2-224) | 1.3.6.1.6.3.10.1.1.4 | RFC 7860 | usmHMAC128SHA224AuthProtocol, zastaralé |
| SHA2-256 (HMAC‑SHA2-256) | 1.3.6.1.6.3.10.1.1.5 | RFC 7860 | usmHMAC192SHA256AuthProtocol, aktuální (do roku 2030) |
| SHA2-384 (HMAC‑SHA2-384) | 1.3.6.1.6.3.10.1.1.6 | RFC 7860 | usmHMAC256SHA384AuthProtocol, vzácné |
| SHA2-512 (HMAC‑SHA2-512) | 1.3.6.1.6.3.10.1.1.7 | RFC 7860 | usmHMAC384SHA512AuthProtocol, vzácné |
Obrovskou nevýhodou SNMP je nemožnost definovat samostatně algoritmus pro zajištění integrity a samostatně algoritmus pro zajištění autenticity. V případě konfigurace se pro tyto účely používá vždy stejná funkce. Ta zároveň vytváří volí metodu derivace klíčovéh materiálu, z dnešního pohledu značně zastaralou. V rámci SNMP standardu jsou jasně dané podmínky. Heslo se opakuje, dokud nevytvoří 1MB dat (1 048 576 bajtů). Přebytek se ořízne. Výsledek se hashuje a vzniká pracovní hodnota:
Ku=HASH(buffer)
Ta se následně použije pro lokalizaci klíčového materiálu následujícím způsobem:
Kul = HASH( Ku || engineID || Ku )Sada standardů, popisující protokol SNMP ve všech jeho verzích:
| Standard | Popis | Verze |
| RFC 1157 | A Simple Network Management Protocol – definice SNMPv1 | SNMPv1 |
| RFC 1155 | Structure and Identification of Management Information for TCP/IP-based internets (SMIv1) | SNMPv1 |
| RFC 1212 | Concise MIB Definitions | SNMPv1 |
| RFC 1215 | Convention for Defining Traps | SNMPv1 |
| RFC 1901 | Introduction to Community-based SNMPv2 | SNMPv2 |
| RFC 1902 | Structure of Management Information for SNMPv2 (SMIv2) | SNMPv2 |
| RFC 1903 | Textual Conventions for SNMPv2 | SNMPv2 |
| RFC 1904 | Conformance Statements for SNMPv2 | SNMPv2 |
| RFC 1905 | Protocol Operations for SNMPv2 | SNMPv2 |
| RFC 1906 | Transport Mappings for SNMPv2 | SNMPv2 |
| RFC 1907 | Management Information Base for SNMPv2 | SNMPv2 |
| RFC 1908 | Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework | SNMPv2 |
| RFC 2089 | V2ToV1 Mapping SNMPv2 onto SNMPv1 (optional mapping) | SNMPv2 |
| RFC 3410 | Introduction and Applicability Statements for Internet-Standard Management Framework | SNMPv3 |
| RFC 3411 | An Architecture for Describing SNMP Management Frameworks | SNMPv3 |
| RFC 3412 | Message Processing and Dispatching for SNMP | SNMPv3 |
| RFC 3413 | SNMP Applications | SNMPv3 |
| RFC 3414 | User-based Security Model | SNMPv3 |
| RFC 3415 | View-based Access Control Model | SNMPv3 |
| RFC 3416 | Version 2 of SNMP Protocol Operations | SNMPv3 |
| RFC 3417 | Transport Mappings for SNMP | SNMPv3 |
| RFC 3584 | Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework | SNMPv3 |
| RFC 3826 | The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model | SNMPv3 |
| RFC 7860 | HMAC-SHA-2 Authentication Protocols in User-Based Security Model | SNMPv3 |
| RFC 5590 | Transport Subsystem for the Simple Network Management Protocol | SNMPv3 TSM |
| RFC 5591 | Transport Security Model for SNMP | SNMPv3 TSM |
| RFC 5953 | TLS Transport Model for SNMP | SNMPv3 TSM |
| RFC 2578 | Structure of Management Information Version 2 | SMIv2 |
| RFC 2579 | Textual Conventions for SMIv2 | SMIv2 |
| RFC 2580 | Conformance Statements for SMIv2 | SMIv2 |
SNMP je dobrý sluha, ale zlý pán. Zastaralé konfigurace, neumožňující řešit problémy s ochranou dat mohou být při správě sítě značně nebezpečné. Ani na lokální síti nelze důvěřovat všem účastníkům, proto by zajištění autenticity zprávy spolu s ochranou integrity a důvěrnosti mělo být základním požadavkem.
1. Úvodní ustanovení
1.1. Tyto všeobecné obchodní podmínky jsou, není-li ve smlouvě písemně dohodnuto jinak, nedílnou součástí všech smluv týkajících školení, pořádaných nebo poskytovaných školitelem, Jan Dušátko, IČ 434 797 66, DIČ 7208253041, se sídlem Pod Harfou 938/58, Praha 9, zapsané u Úřadu městské části Praha 9 (dále jen „školitel“).2. Vznik smlouvy přihlášením ke kurzu
2.1. Přihláškou se rozumí jednostranný úkon objednatele adresovaný školiteli prostřednictvím datové schránky s identifikací euxesuf, e-mailu na adresu register@cryptosession.cz nebo register@cryptosession.info, internetových stránek cryptosession.cz, cryptosession.info nebo kontaktním telefonem +420 602 427 840.3. Zánik smlouvy zrušením přihlášky
3.1. Přihláška může být objednatelem zrušena pomocí e-mailu, nebo pomocí datové schránky.4. Cena a platební podmínky
4.1. Odesláním přihlášky objednatel akceptuje smluvní cenu (dále jen účastnický poplatek) uvedenou u daného kurzu.5. Podmínky školení
5.1. Školitel je povinnen informovat objednatele 14 dní dopředu o místě a času školení, včetně termínu zahájení a ukončení denního programu.6. Reklamace
6.1. Pokud je účastník hrubě nespokojen s průběhem kurzu, je školitel o této informaci vyrozuměn.7. Autorská práva k poskytnutým materiálům
7.1. Školicí materiály poskytnuté školitelem v rámci konání školení splňují znaky autorského díla dle zákona č. 121/2000 Sb.8. Zodpovědnost
8.1. Školitel nepřebírá odpovědnost za nedostatky ve službách kterékoliv třetí strany, kterou využívá při školeních.9. Platnost podmínek
9.1 Tyto všeobecné obchodní podmínky jsou platné a účinné od 1. října 2024.Informace o sběru a zpravování osobních údajů
Zpracovatel Jan Dušátko (dále jen „Správce“), dle nařízení Evropského parlamentu a Rady (EU) č. 2016/679 o ochraně fyzických osob v souvislosti se zpracováním osobních údajů a o volném pohybu těchto údajů a o zrušení směrnice 95/46/ES (obecné nařízení o ochraně osobních údajů, dále jen „Nařízení“) zpracovává osobní údaje. Dále jsou rozepsané jednotlivé osobní údaje, které jsou součástí zpracování při konkrétních aktivitách u této webové prezentace a v rámci obchodního styku.Informace o záznamech přístupu na webovou prezentaci
Tento web nesbírá žádné cookies. Stránka nepoužívá ani žádné analytické scripty třetích stran (sociální sítě, cloud provideři). Z těchto důvodů je také nabízena volba pro zobrazení mapy formou odkazu, kde primárním zdrojem je OpenStreet a alternativy pak často používané Mapy společnosti Seznam, a.s., případně Google Maps společnosti Google LLC Inc. Využití jakéhokoliv z těchto zdrojů je zcela na libovůli uživatelů těchto stránek. Správce nenese odpovědnost za sběr dat realizovaný těmito společnostmi, neposkytuje jim data o uživatelích a na sběru dat nespolupracuje.Informace o kontaktování provozovatele stránek
Formulář pro kontaktování provozovatele stránek (správce) obsahuje následující osobní údaje: jméno, příjmení, e-mail. Tyto údaje jsou určeny jen a pouze pro tuto komunikaci, odpovídající oslovení uživatele a jsou udržovány po dobu nezbytnou k naplnění účelu, maximálně pak po dobu jednoho roku, pokud si uživatel neurčí jinak.Informace o objednávkovém formuláři
Pro případ zájmu o objednávku formulář obsahuje více údajů, tj. jméno, příjmení, e-mail a kontaktní údaje na organizaci. Tyto údaje jsou určeny jen a pouze pro tuto komunikaci, odpovídající oslovení uživatele a jsou udržovány po dobu jednoho roku, pokud si uživatel neurčí jinak. V případě, kdy na základě této objednávky dojde k uzavření obchodního vztahu, budou nadále správcem udržovány pouze informace vyžadované českými zákony na základě obchodních vztahů (název a adresa společnosti, číslo bankovního účtu, typ kurzu a jeho cena).Informace o dokumentu o absolovování kurzu
V rámci kurzu je vydán zpracovatelem dokument o absolovování kurzu. Tento dokument obsahuje následující údaje: jméno a příjmení studenta, název a datum absolovování kurzu a jméno zaměstnavatele. Uvedené informace se následně používají pro tvorbu lineárního stromu hashí (nemodifikovatelný záznam). Tato databáze obsahuje pouze informace o poskytnutých jménech a názvech společností, které mohou a a nemusí odpovídat realitě a je udržován zpracovatelem pro případné opětovné vystavení nebo ověření vydání dokumentu.Práva subjektu osobních údajů
Zákazník nebo návštěvník tohoto webu má možnost požádat o informace o zpracování osobních údajů, právo požadovat přístup k osobním údajům, případně právo požádat o opravu nebo výmaz veškerých dat, které by o něm byly vedeny. V případě výmazu tento požadavek není možné splnit pouze pokud se nejedná o data nezbytně nutná v rámci obchodního styku. Zákazník nebo návštěvník webu má dále právo na vysvětlení týkající se zpracování jeho osobních údajů, pokud tento zjistí nebo se domnívá, že zpracování je prováděno v rozporu s ochranou jeho soukromého a osobního života nebo v rozporu s platnými právními předpisy a právo požadovat odstranění takto vzniklého stavu a zajištění nápravy.