Hallo Leute,
ich hoffe hier kann mir einer von euch weiter Helfen.
Ich versuche seit einiger Zeit SNMP v3 zuverstehen und hab da so meine
schwierigkeiten:
The RFC 3411 architecture recognizes three levels of security:
o without authentication and without privacy (noAuthNoPriv)
- hier sollten kaum Änderungen (bis auf das Telegram selbst) keine
neuerungen auftauchen
- also schnell auf meinem MC umsetzbar sein
o with authentication but without privacy (authNoPriv)
- hier fangen die Probleme an:
- wie wird der User übertragen? hier kommt doch bestimmt die
"authentication" zum tragen, und der 'Name-Text' wird halt
unkenntlichgemacht bzw der Hashwert (MD5) wird dann übertragen?!?
- nur was bringt mir das? Da der Hashwert immer gleich bleibt brauch man
doch das Telegramm auch nur zu klonen und man hat Zugang, oder?
o with authentication and with privacy (authPriv)
- hier wird dann auch wieder der 'Name' (Hashwert, MD5) übertragen und
zusätzlich nur die SNMP-Nutzdaten (PDU) werden verschlüsselt?!? (DES)
So nun was bringt mir das ganze Punkt 1 + 2 sind doch zum alten System
v2c identisch!?! Nur Punkt 3 bringt mehr Sicherheit mit sich.
Warum wird bei Punkt 2 nicht auch Stationen bezogene Daten (bzw
veränderte Daten) mit in den Hashwerten eingestreut, um das kopieren
eines Telegrams
zu erschweren?
für mich als Mensch ist es schon etwas schwere den User
'HansDieterJosef' mit dem Hashwert 'cf68ac6b8d99607663e92985287eb5dc' zu
verbinden aber ein Computer macht doch sowas tagtäglich, also warum das
ganze?
dann noch eine Frage:
Wenn der User bei mir im MC angelegt wird, dann reicht es doch, wenn ich
den Hashwert einmal berechne, ihn dann ins EEProm brenne und im
Telegramm immer nur noch die Hashwerte vergleichen muss.
So würde ich mir doch das 'berechnen' des Users sparen und mein Code
läuft schneller.
Kennt jemand noch gute Literatur zum Thema bzw. Webseiten?
Danke
Stephan
hi
also ich muss ein bestehendes SNMP v2c auf v3 Upgraden, weil die Kunden
es verlangen!
Auf der PC Seite ist das kein Problem Net-SNMP kann das, aber bei
unserem Mikrocontroller sieht es da schon anders aus. Da muss ich dran!
Aber wie oben schon beschrieben verstehen ich die zusammenhänge von dem
DES und MD5 nicht so richtig und bevor ich mit dem proggen los lege
wollte ich es erst verstehen.
Ich glaube eine Version mit 'noAuthNoPriv' müsste ich schon so hin
bekommen, aber das ist nicht das was die Kunden wollen. Die sind leider
immer so anspruchsvoll. ;-)
Stephan
Hi Stephan,
ich finde deine Fragen sehr interessant, sind sie mir zum Teil denn auch
schon begegnet.
authNoPriv
"wie wird der User übertragen? hier kommt doch bestimmt die
"authentication" zum tragen, und der 'Name-Text' wird halt
unkenntlichgemacht bzw der Hashwert (MD5) wird dann übertragen?!?"
Denke ich auch,könnte aber auch ein SHA Wert sein. Ich werde es
heute/morgen mal über einen Wiresharkmitschnitt testen. Da muss der Hash
ja irgendwo auftauchen.
Ich werde mir dafür aber erst mal NET-SNMP einrichten.
(http://www.net-snmp.org/)
Bist du noch an dem Thema dran ?
Grüße
Micha
HuHu,
also ganz so einfach ist es dann noch nicht.
Wer sich mal Table 20 der Cisco IOS Configuration Fundamentals
(http://www.cisco.com/en/US/docs/ios/12_2/configfun/configuration/guide/fcf014.html)
anschaut wird feststellen, dass bei authNoPriv hier bereits eine
Kombination von zwei Hash-Algos greifen.
Dem HMAC in Verbindung mit MD5 oder der HMAC in Verbindung mit SHA1
Darauf könnte auch die sehr seltsame Hashlänge der folgenden
abgefangenen Parameter eines SNMPv3 Paketes hindeuten:
snmp.msgAuthenticationParameters: 19:39:5e:67:89:4f:da:18:24:14:84:9f
msgPrivacyParameters: 0000000103d5321a
Da die beiden Werte ungleich 0 sind, wird also das authPriv Level
verwendet.
Es ist wahrscheinlich noch irgend ein geheimer Schlüssel notwendig, der
auf den Hash des Nutzers angewandt wird ?
Hier nochmal der zutreffende RFC 3414 der das Ganze belegen sollte:
User-based Security Model (USM) for version 3 of the Simple Network
Management Protocol (SNMPv3)
Hoffe ich mach hier nicht weiter Alleinunterhalter ;-)
Grüße,
Micha
Es ist zwar ein paar Jahre her, daß ich mit SNMP zu tun hatte, und um v3
bin ich damals herumgekommen, aber ein paar Anmerkungen kann ich
beisteuern:
"authentication" wird sich, genaus wie "privacy" auf den Inhalt der
Nachricht beziehen, d.h. der Empfänger will sich sicher sein, daß er es
mit einem unverfälschten SNMP-Paket von einem legitimen Absender zu tun
hat. Dazu muß das ganze Paket (naja, zumindest die eigentliche SNMP
Nachricht darin) gehasht werden (damit jegliche Manipulation auffliegt),
und irgendwie muß noch ein Geheimnis beteiligt sein, sonst rechnet der
Angreifer einfach den passenden Hash zu seinen manipulierten Paketen und
kommt damit durch.
"Hash mit Geheimnis" heißt in der Fachsprache "keyed hash", d.h. ein
Hash, der nur mit Kenntnis eines geheimen Schlüssels nachvollziehbar
ist. Das hat zwei Auswirkungen:
- nur wer das Geheimnis kennt, kann das Paket auf Echtheit prüfen
(brauchen wir hier nicht)
- nur wer das Geheimnis kennt, kann ein echtes Paket herstellen (das
ist wichtig)
HMAC ist kein Hash-Algorithmus, sondern ein Verfahren, um aus einem
beliebigen normalen Hash-Algorithmus einen keyed hash zu bauen. HMAC
alleine ist also gar nichts, aber HMAC+MD5 ist ein keyed hash, genauso
wie HMAC+SHA1.
Hallo Micha,
nur mal so eine Frage am Rande: net-snmp ist ja open source und die v3
z.B. wird im snmpv3.h, snmpv3_api.h bzw. snmpv3-security-includes.h
referenziert.
Hast Du die zugehörigen Funktionen (z.B. snmpv3.c) schon mal angeschaut?
MfG,
Andreas
Huhu,
danke Nosnibor für die Aufklärung zu HMAC.
Das Verfahren hmac_md5 wird ja sogar im Informational-Teil auf Page 7 im
RFC 2104 mit Quellcode verdeutlicht.
Hi Andreas,
ne den Quellcode in NetSNMP habe ich bisher nicht studiert, obwohl er
(wenn ich jetzt so drüber nachdenke) sicher aufschlussreich wäre. Das
war wohl sicher ein indirekter Wink von dir ? ;-)
Güße
Micha
