SNMP-Sperre bei SNMP-Anfrage mit public seit 9.20/9.24

[Jirka]

Hallo zusammen,

unter Zugriffs-Rechte sind SNMPv1/v2 und SNMPv3 im lokalen LAN des LANCOMs erlaubt (ist so erforderlich).
Die SNMP-Community public ist jedoch aus Sicherheitsgründen nicht erlaubt (ebenfalls so erforderlich).

Macht jetzt ein Client im lokalen LAN eine SNMP-Anfrage (GET-Request) mit der SNMP-Community public an den LANCOM (direkt oder z. B. indirekt als Broadcast), so wertet der LANCOM-Router dies als Hack-Versuch und sperrt den SNMP-Zugriff (entsprechend der Einstellungen unter Konfigurations-Login-Sperre), übrigens auch wenn man von WAN-Seite per VPN kommt. In der Folge kann der LANCOM nicht mehr mit PRTG gemonitort werden und Fehler-E-Mails sind die Folge. Public zu verbieten ist also mit der Firmware 9.20/9.24 zum Problem geworden. Vorher hat der LANCOM einfach nicht geantwortet, fertig. Alles gut.

Hintergrund: Das Problem trat bei mir seit längerem sporadisch an verschiedenen Stellen auf. Ein Trace zeigte mir ziemlich schnell:

Code: Alles auswählen

[SNMP-Engine-Error] 2016/11/14 13:40:44,042  Devicetime: 2016/11/14 13:40:45,636 Wrong security information
 Version: Integer32: 0
 Community: public; OctetString: 0x70 0x75 0x62 0x6c 0x69 0x63
 ConnectionInfo: 
 Port: 2, LAN-1
 tag: 0

[SNMP-Engine-Error] 2016/11/14 13:42:03,517  Devicetime: 2016/11/14 13:42:05,109 Wrong security information
 Version: Integer32: 0
 Community: public; OctetString: 0x70 0x75 0x62 0x6c 0x69 0x63
 ConnectionInfo: 
 Port: 2, LAN-1
 tag: 0

[SNMP-Engine-Error] 2016/11/14 13:42:04,231  Devicetime: 2016/11/14 13:42:05,824 Wrong security information
 Version: Integer32: 0
 Community: public; OctetString: 0x70 0x75 0x62 0x6c 0x69 0x63
 ConnectionInfo: 
 Port: 2, LAN-1
 tag: 0

[SNMP-Engine-Error] 2016/11/14 13:42:05,438  Devicetime: 2016/11/14 13:42:07,033 SNMP access not granted: login blocked

[SNMP-Engine-Error] 2016/11/14 13:42:07,233  Devicetime: 2016/11/14 13:42:08,829 SNMP access not granted: login blocked

Warum hier und da Clients jedoch einfach versuchen, mit der SNMP-Community public den LANCOM zu befragen, war mir lange nicht klar. Inzwischen habe ich das hier nachgestellt. Man nehme ein Android-Smartphone oder -Tablet und drucke etwas aus. Wenn ich bei mir hier (Android 6.0.1) unter Einstellungen -> Weitere Verbindungseinstellungen -> Drucken -> das Druckdienste-Plug-In von Samsung aktiviere oder ein eben nachinstalliertes von HP Inc. (Bezeichnung bei Google Play: HP Druckdienst-Plug-In), dann gibt es vor jedem Druckbefehl ein SNMP-Broadcast, der nicht abschaltbar ist und den ich durchaus auch für zulässig halte (Druckersuche). Dass der LANCOM-Router dabei jedoch so reagiert, halte ich für einen Bug, das entspricht ja auch nicht dem bisherigen Verhalten. Das bisherige Verhalten war so, dass bei Anfragen mit public einfach nicht reagiert wurde, wie oben schon geschrieben. Nur wenn anderweitige Communities probiert wurden, griff die Sperre. Nachfolgend zur Info die SNMP-Anfragen meines Handys:

Druckdienste-Plug-In von Samsung:

Code: Alles auswählen

[Ethernet] 2016/11/14 20:51:12,576
Received 83 byte Ethernet packet via LAN-1:
HW Switch Port      : ETH-4
IPv4 Hdr Checksum   : OK
IP Proto Checksum   : OK
-->IEEE 802.3 Header
Dest                : ff:ff:ff:ff:ff:ff (Broadcast)
Source              : 34:14:5f:0d:4e:c5 (Samsung 0d:4e:c5)
Type                : IPv4
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0x00) (Precedence 0) / (DSCP CS0/BE)
Total length        : 69
ID                  : 59900
Fragment            : Offset 0 DontFrag
TTL                 : 64
Protocol            : UDP
Checksum            : 15510 (OK)
Src Address         : 10.10.10.12
Dest Address        : 255.255.255.255
-->UDP Header
Src Port            : 48195
Dest Port           : SNMP
Length              : 49
Checksum            : 46595 (OK)
ASN.1 Data          : SEQUENCE (len = 39)
                        INTEGER (len = 1): 1
                        OCTET-STRING (len = 6):
                          70 75 62 6c 69 63        public
                        GET-NEXT-REQUEST (len = 26)
                          INTEGER (len = 4): 1548192577
                          INTEGER (len = 1): 0
                          INTEGER (len = 1): 0
                          SEQUENCE (len = 12)
                            SEQUENCE (len = 10)
                              OBJECT-ID (len = 6): mib-2.43
                              NULL

Druckdienste-Plug-In von HP Inc.:

Code: Alles auswählen

[Ethernet] 2016/11/14 20:54:58,014
Received 101 byte Ethernet packet via LAN-1:
HW Switch Port      : ETH-4
IPv4 Hdr Checksum   : OK
IP Proto Checksum   : OK
-->IEEE 802.3 Header
Dest                : ff:ff:ff:ff:ff:ff (Broadcast)
Source              : 34:14:5f:0d:4e:c5 (Samsung 0d:4e:c5)
Type                : IPv4
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0x00) (Precedence 0) / (DSCP CS0/BE)
Total length        : 87
ID                  : 50995
Fragment            : Offset 0 DontFrag
TTL                 : 64
Protocol            : UDP
Checksum            : 19012 (OK)
Src Address         : 10.10.10.12
Dest Address        : 10.10.10.255
-->UDP Header
Src Port            : 45433
Dest Port           : SNMP
Length              : 67
Checksum            : 27020 (OK)
ASN.1 Data          : SEQUENCE (len = 57)
                        INTEGER (len = 1): 0
                        OCTET-STRING (len = 6):
                          70 75 62 6c 69 63        public
                        GET-REQUEST (len = 44)
                          INTEGER (len = 1): 1
                          INTEGER (len = 1): 0
                          INTEGER (len = 1): 0
                          SEQUENCE (len = 33)
                            SEQUENCE (len = 12)
                              OBJECT-ID (len = 8): system.5.0
                              NULL
                            SEQUENCE (len = 17)
                              OBJECT-ID (len = 13): enterprises.11.2.3.9.1.1.7.0
                              NULL

Firmware ist aktuell die 9.24.0139.

Vielen Dank und viele Grüße,
Jirka

[LoUiS]

Danke fuer Dein Feedback, ich hab es mal als Bug eingetragen.


Ciao
LoUiS

[LoUiS]

Hi,

hier schon mal ein Feeedback zu Deinen Anmerkungen.

Wenn der Brute-Force-Schutz an dieser Stelle wieder deaktiviert wird, waere ein Angriff ueber das Broadcast Protokoll auf das Root/Admin-Passwort moeglich. Daher ist das Verhalten so wie es jetzt ist korrekt.

Es gibt aber einen Workaround:
Die Communities Table hat einen Vorrang vor den im LCOS konfigurierten Admins. Das heisst diese Tabelle wird zuerst abgefragt. Wenn in dieser Tabelle die Community mit den Namen "public" vorhanden ist und dieser aktiviert wurde, wird der Brute-Force-Schutz nicht aktiviert. Der Zugriff ist erstmal mit korrekten Werten moeglich. Wenn jetzt aber der Security-Name ins "leere" zeigt oder in der Groups Tabelle deaktiviert oder nicht zugewiesen wurde, wird der Brute-Force-Schutz nicht aktiviert, der Zugriff aber dennoch nicht gestattet.

Alternativer Workaround: Admin Access deaktivieren, wenn dieser nicht benötigt wird.


Ciao
LoUiS

[Jirka]

Hallo LoUiS,

erstmal danke für die schnelle Rückmeldung und sorry, dass ich jetzt erst antworte. Ich habe einiges allerdings nicht ganz verstanden und würde darüber, im Sinne einer optimalen Lösung für das Problem, durchaus diskutieren wollen. Ich hoffe, dass das ok ist.

Wenn der Brute-Force-Schutz an dieser Stelle wieder deaktiviert wird

Nun ja, ich habe ja nicht gefordert, den Brute-Force-Schutz an der Stelle zu deaktivieren. Nur wenn ein SNMP-Get mit der Standard-Community public eingeht, dann soll das einfach nicht den Brute-Force-Schutz aktivieren, weil public ein spezielles Passwort ist, so speziell, dass es eigentlich gar keines ist. Es muss somit eine Ausnahmeregel geben, wie es sie von WAN-Seite ja nun inzwischen auch gibt, denn da ist public - auch wenn es als erlaubte SNMP-Community im LANCOM hinterlegt ist - eben nicht erlaubt. Und so darf public im lokalen LAN im Gegenzug auch nicht als Versuch gewertet werden, das Passwort zu knacken, denn es ist per Definition ja keines.

waere ein Angriff ueber das Broadcast Protokoll auf das Root/Admin-Passwort moeglich.

Ein Broadcast Protokoll kenne ich nicht. Ich gehe jetzt davon aus, dass hier Pakete in der Art wie die oben von mir angegebenen Pakete vom Android-Smartphone beim Drucken gemeint sind, also SNMP-Get-Requests, die als Broadcasts verschickt werden, wobei ob nun als Broadcast oder Unicast ist für dieses Problem hier eigentlich nicht relevant.
Wieso wäre ein Angriff auf das Root-Passwort möglich? Bei eingehenden SNMP-Get-Requests soll schon noch mit der SNMP-Communities-Tabelle abgeglichen werden. Passt da was, alles ok. Passt da nichts, Abgleich mit Root/Admin-Passwort. Passt es da, alles ok. Passt es nicht und das Admin-Passwort wurde auf public geprüft, dann Zugriff nur verweigern. Passt es nicht und das Admin-Passwort wurde auf andere Zeichenfolgen als public geprüft, dann nicht nur den Zugriff verweigern, sondern Vermerk im Brute-Force-Schutz. Wieso kann man das nicht so machen? So war es doch bisher auch.

Daher ist das Verhalten so wie es jetzt ist korrekt.

Das bedeutet dann im Umkehrschluss, dass das Verhalten vor der SNMP-Umstellung, also mit 9.10 oder kleiner, nicht korrekt ist? Kann ich nicht nachvollziehen. Wenn ich LANmonitor mit public auf ein Gerät mit der 9.10 ansetze, wo public nicht erlaubt ist, dann passiert gar nichts. Wenn ich gleich danach LANmonitor mit einer zulässigen Community oder dem Root/Admin-Passwort ansetze ist alles ok. Mache ich das gleiche Spiel mit test123 statt public, dann komme ich danach auch mit einer zulässigen Community oder dem Root/Admin-Passwort in LANmonitor zu keinen Ergebnissen, weil das Gerät noch in der Brute-Force-Sperre hängt. Wieso wurde also dieses, meiner Ansicht nach korrekte Verhalten, nicht übernommen?

Es gibt aber einen Workaround:
Die Communities Table hat einen Vorrang vor den im LCOS konfigurierten Admins. Das heisst diese Tabelle wird zuerst abgefragt. Wenn in dieser Tabelle die Community mit den Namen "public" vorhanden ist und dieser aktiviert wurde, wird der Brute-Force-Schutz nicht aktiviert. Der Zugriff ist erstmal mit korrekten Werten moeglich. Wenn jetzt aber der Security-Name ins "leere" zeigt oder in der Groups Tabelle deaktiviert oder nicht zugewiesen wurde, wird der Brute-Force-Schutz nicht aktiviert, der Zugriff aber dennoch nicht gestattet.

Das hört sich gut an. Bleibt nur als Einwand, dass wohl kaum jemand auf die Idee kommt, das so zu konfigurieren (es müsste also dokumentiert werden) und dass wenn da mal jemand eine Abnahme macht und die Konfig kontrolliert, dass man dann einen Minuspunkt bekommt, weil public auf ja steht, obwohl vereinbart war, dass das nicht der Fall sein soll.

Alternativer Workaround:

Auch noch ein zweiter Workaround...

Admin Access deaktivieren, wenn dieser nicht benötigt wird.

D. h. das Problem scheint wirklich in der Prüfung auf das Root/Admin-Passwort zu liegen. Verstehe ich nicht.
Aber der Zugriff auf SNMP wird ja z. B. benötigt, insofern ist es also kein echter Workaround.

Vielen Dank und viele Grüße,
Jirka

[LoUiS]

Hi Jirka,

bitte mal mit den aktuellen Builds von Heute 23.11 (LCOS 9.24 und LCOS 10.00) ausprobieren, da wurde das Verhalten der Community "public" angepasst.


Ciao
LoUiS

[Jirka]

Hallo LoUiS,

ja, was soll ich sagen?! Eben getestet - perfekt! Da hat sich der Einwand doch gelohnt. Besten Dank.

Vielen Dank und viele Grüße,
Jirka