Sicherheitsproblem SNMP mit Umstellung auf 9.20/9.24?

[Jirka]

Hallo,

ich bin der Meinung, dass sich mit den SNMP-Änderungen der 9.20 ein Sicherheitsproblem eingeschlichen hat. Und zwar deshalb, weil sich anscheinend das Verhalten des Gerätes geändert hat. Das Problem tritt nur auf, wenn die Konfig von einer 9.10 oder älter konvertiert wurde und vorher der SNMP-Zugriff von WAN-Seite erlaubt war (mit Passwort oder angegebener Community) und der Zugriff mit der SNMP-Community public erlaubt war (von LAN-Seite).

Mit der 9.10 war es so, dass es eine SNMP Read-Only Community gab, die man angeben konnte, oder eben nicht. Zusätzlich dazu gab es einen Schalter, der in LANconfig mit "SNMP Read-Only Community 'public' deaktiviert" bezeichnet war (Konsole: Password-Required-for-SNMP-Read-Access). War dort der Haken drin (bzw. auf yes in der Konsole), dann war der Zugang zum SNMP mit der Standard-Community 'public' verwehrt. War der Haken dort nicht drin, konnte man mit der Standard-Community 'public' die Gerätedaten abfragen. Allerdings NUR von lokal, von WAN-Seite aus war 'public' grundsätzlich nicht zulässig.
Nun mit der 9.20 bzw. 9.24, ist es so, dass die Konfig konvertiert wurde und sich die SNMP-Community an anderer Stelle wiederfindet. War vorher der Haken bei "SNMP Read-Only Community 'public' deaktiviert" nicht drin, ist die Community 'public' nun auch aktiv. Soweit korrekt. Aber plötzlich, was vorher ja nicht der Fall war, gilt diese nun auch über WAN, womit sich das Verhalten zu vorher geändert hat und damit ein Sicherheitsloch entstanden ist.

Der aufmerksame cpuprofi aus dem Forum hatte das sogar schon bemerkt: http://www.lancom-forum.de/sicherheitsw ... 15369.html Allerdings hat damals niemand nachvollzogen, wie das Problem zustande kam.

Vielen Dank und viele Grüße,
Jirka

[COMCARGRU]

Hallo Jirka,

danke für den Hinweis - bin gespannt was die Lancom-Vertreter im Forum hier dazu schreiben werden?

Nur um es zu verfeinern - ich kann es gerade nicht selbst testen - letztlich entscheidend sollte doch sein, was unter Zugriffs-Rechte WAN-Schnittstelle steht. Solange dort "nicht erlaubt" oder "nur über VPN" eingetragen ist, sollte das nicht möglich sein egal ob "public" aktiv oder deaktiviert ist. Sehe ich das falsch?


Gruß
CG

[Jirka]

Hallo COMCARGRU,

nein, das siehst Du natürlich genau richtig. Habe das bei meinem Beitrag oben gerade noch zusätzlich mit angegeben bei den Voraussetzungen für das Problem. Wenn SNMP für WAN nicht freigeschaltet ist, dann ist es natürlich auch nicht erreichbar. Allerdings wird SNMP sehr oft WAN-seitig erlaubt, ich gebe zu, dass ich das auch gerne mal zulasse (dann aber natürlich mit entsprechenden Zugangsdaten).

Viele Grüße,
Jirka

[Jirka]

Hallo,

mit der 9.24.0114 geht SNMP - unter folgenden Konditionen - nun leider gar nicht mehr:

PRTG/LANmonitor mit SNMPv2 von WAN-Seite über VPN, SNMP-Community aus Benutzername und Passwort

Konfiguration:
Zugriffsrechte SNMP: Nur über VPN, Zugriffs-Stationen: keine Einschränkung, SNMP-Port: 161
SNMP-Community public nicht aktiv
Weiterer Adminitrator konfiguriert mit nur Lese-Rechten und ohne Funktions-Rechte, mit Benutzername und Passwort.
Noch ein weiterer Administrator mit eingeschränkten Rechten (z. B. für Leitungstrennungen mit LANmonitor).

Ich habe nicht geprüft, ob es funktioniert hätte, wenn ich explizit eine SNMP-Community angegeben hätte.

Vielen Dank und viele Grüße,
Jirka

[LoUiS]

Es ist eine neue Einstellung im Konfigurationswuerfel fuer SNMPv2 hinzugekommen, die SNMPv2 im Default vom WAN verbietet.
Wenn SNMPv2 vom WAN aus gewuenscht ist, muss dies nun erst explizit erlaubt werden:
"/Setup/Config/Access-Table"

[Jirka]

Vielen Dank erst mal für die Info.

[cpuprofi]

Hallo LoUiS,

ich bin ja nun nicht der super SNMP-Experte aber:

...Wenn SNMPv2 vom WAN aus gewuenscht ist, muss dies nun erst explizit erlaubt werden...

Wie sieht das dann bei SNMPv1 (ist wohl mit nur "SNMP" unter Webconfig gemeint) und bei SNMPv3 aus... ?

Grüße
Cpuprofi

[LoUiS]

SNMPv1/v2 ist ein Schalter mit der Bezeichnung "SNMP", "SNMPv3" ist ein weiterer, separat zu konfigurierender Schalter.

Aktuell sieht die Access-Table (in der 9.24 Build 0115 und 9.20 Build 0712) so aus:

Code: Alles auswählen

root@1781VA:/Setup/Config/Access-Table
> l

Ifc.    Telnet  TFTP    HTTP    SNMP    HTTPS   Telnet-SSL  SSH     SNMPv3
========------------------------------------------------------------------
LAN     Yes     Yes     Yes     Yes     Yes     Yes         Yes     Yes
WAN     VPN     VPN     VPN     No      VPN     VPN         VPN     VPN
WLAN    Yes     Yes     Yes     Yes     Yes     Yes         Yes     Yes

Die aktuelle Version von LANconfig unterstuetzt den Schalter "SNMPv3" ncoh nicht, dies wird aber auch noch nachgezogen.


Ciao
LoUiS

[cpuprofi]

Hallo LoUiS,

SNMPv1/v2 ist ein Schalter mit der Bezeichnung "SNMP", "SNMPv3" ist ein weiterer, separat zu konfigurierender Schalter... Access-Table (in der 9.24 Build 0115 und 9.20 Build 0712)

in der 9.24 Build 0114 ist dieses aber (noch) anders, da gibt es einen Schalter mit der Bezeichnung "SNMP", "SNMPv2".

Code: Alles auswählen

root@Lancom1781VA:/Setup/Config/Access-Table
>

Ifc.    Telnet  TFTP    HTTP    SNMP    HTTPS   Telnet-SSL  SSH     SNMPv2
========------------------------------------------------------------------
LAN     Yes     Yes     Yes     Yes     Yes     Yes         Yes     Yes
WAN     VPN     VPN     VPN     VPN     Yes     Yes         Yes     VPN

Erst mit dem "aktivieren" des "SNMPv2" Schalters, waren SNMP-Abfragen wieder möglich.

Grüße
Cpuprofi

[LoUiS]

Richtig, also das Verhalten der Build 0114 gleich der Build 0115. Es hat sich nur die Bezeichnung geaendert, um es deutlicher zu machen.

Nach wie vor ist es so, dass man SNMPv1/v2 fuer das WAN erst aktivieren muss, weil dies per Default verboten ist.
Der Bezeichner fuer v1/v2 wurde von vorher SNMPv2 auf neu SNMP geaendert. Der alte Bezeichner fuer v3 ist von alt SNMP jetzt zu neu SNMPv3 geworden.


Ciao
LoUiS

[cpuprofi]

Ok, jetzt kann ich es auch nachvollziehen.

Grüße
Cpuprofi

[Jirka]

Hallo LoUiS, hallo zusammen,

ich habe mir jetzt die Firmware 9.24.0115 angeschaut und muss sagen, dass sie ein stimmiges Bild ergibt:
Auch wenn SNMP von WAN-Seite erlaubt ist und die SNMP-Community public aktiv ist, so ist ein Zugriff von WAN mit public nicht möglich - das entspricht wieder dem bisherigen, bekannten Verhalten. Zusätzlich ist es mit dem neuen Parameter SNMPv3 in den Zugriffs-Rechten nun möglich, SNMPv3 von WAN-Seite zu erlauben, während SNMPv1/v2 (über den Parameter SNMP) verboten sein kann - gleichzeitig über VPN oder LAN jedoch erlaubt. Klar ausgedrückt heißt das, dass man PRTG über VPN wie bisher laufen lassen kann, externe LANmonitor-Benutzer aber zum Umstieg auf SNMPv3 zwingen kann. Bleibt einzig meiner Ansicht nach der Wermutstropfen, dass der Parameter SNMP in den Zugriffs-Rechten mit dem Update auf die 9.24.0115 bei WAN immer auf No gesetzt wird, auch wenn es vorher auf erlaubt oder nur über VPN erlaubt war - nur über VPN hätte in den beiden Fällen dann auch gereicht um die Sicherheit zu erhöhen, gleichzeitig wäre es kompatibler zu bestehenden Installationen/Überwachungsszenarien gewesen. Aber macht nichts, kann man ja alles einstellen:

Script, was man nach einem Firmware-Update in betroffene Geräte einspielt:

Code: Alles auswählen

set /2/11/15/WAN {5} 16
exit
 

(Das Script setzt die Zugriffs-Rechte für SNMP über WAN auf "nur über VPN".)

Oder ein Script, was man vor einem Firmware-Update in betroffene Geräte einspielt (damit man z. B. automatisiert updaten und trotzdem beruhigt ausschlafen kann):

Code: Alles auswählen

set /2/11/20/1111 0 1 0 "1" "0" "0" "" "" "exec:flash no ; set /2/11/15/WAN {5} 16 ; del /2/11/20/1111 ; flash yes" "root" "Zugriffsrechte fuer SNMP einmalig nach Neustart setzen"
exit
 

(Das Script macht das gleiche wie oben, nur nicht sofort, sondern eine Minute nach Neustart/Firmware-Update.)

Viele Grüße,
Jirka