Schlagwort-Archive: HPE

BitBastelei #337 – HP/Aruba/HPE ProCurve 2510G-24 Managed Switch

BitBastelei #337 - HP/Aruba/HPE ProCurve 2510G-24 Managed Switch

(686 MB) 00:34:49

2019-06-16 10:00 🛈

Wieder mal ein Auktionstreffer – auf der Suche nach einem kleinen Switch mit VLAN-Unterstützung ist mit ein professioneller 24-Port Gigabit-Switch. Zwar hat das Modell schon ein paar Jahre auf dem Buckel, dürfte jedoch bei Haltbarkeit und Funktionen aktuelle Consumer-Modelle noch immer übertreffen. Schauen wir mal auf den Funktionsumfang, das Management und natürlich was drin steckt.

HTTPS mit signierten Zertifikaten auf HP/HPE/Procurve/Aruba/Procurve-Switchen

HTTPS, vorzugsweise mit gültigen Zertifikaten, sollte heute eigentlich Standard sein – erst recht wenn man mehr oder weniger kritische Infrastrukturen darüber verwalten möchte. Auch wenn ich eher ein Verfechter von SSH bei der Konfiguration von Switchen bin, so wird doch oft auch ein Webinterface gefordert. Bei HP/HPE/Aruba/Procurve ist dies in der Standardkonfiguration unverschlüsselt per HTTP erreichbar. HTTPS lässt sich aktivieren, die Einrichtung von etwas anderem als self-signed ist jedoch leider nicht so intuitiv wie ich das gerne hätte. Also gehen wir die Schritte mal durch. Im CLI natürlich.

Erst muss ein “Trust Anchor” erstellt werden. Dies ist sozusagen die Zertifikatsdatenbank des Switches. Da mehrere vorhanden sein können wird er mit einem aussagekräftigem Namen (her “MEINNETZ“) versehen.

Anschließend wird das Zertifikat der Zertifizierungsstelle (CA) importiert. Leider ist dies bei vielen  Geräten nur per TFTP und nicht über USB-Stick, Terminal  o.Ä. möglich. Auch dieses bekommt zur besseren Auffindbarkeit einen Namen (hier “MYCA“). Die angegebene IP entspricht der des TFTP-Servers, unter Windows lässt sich hierzu z.B. TFTPD32 nutzen. Der Switch selbst muss hierfür natürlich bereits eine passende Netzwerkkonfiguration besitzen und den PC erreichen können, ohne passende Konfiguration sucht er sich eine Adresse per DHCP auf dem Standard-VLAN.

Im Anschluss kann die Zertifikatsunterschriftanfrage (CSR) generiert werden. Wichtig für ein gültiges Zertifikat ist hierbei im Feld “common-name” den späteren Hostname oder die IP-Adresse des Switches anzugeben, welche letztendlich für das Management verwendet werden soll..

Zu beachten ist, dass je nach Modellgeneration die Verfügbaren Cryptomethoden limitiert sein können. Das hier genutzte Modell unterstützt so leiglich RSA-Schlüssel mit bis zu 2048 Bit. Die verfügbaren Optionen lassen sich wie immer durch “?” abrufen. Das Erstellen kann je nach verbautem Managementprozessor einige Zeit in Anspruch nehmen, im Anschluss erscheint die Anfrage als Text.

Diese Anfrage kopiert man aus dem Terminal und reicht sie als .csr-Datei an die gewünschte Zertifizierungsstelle weiter bzw. signiert diesen selbst mit seiner lokalen CA. Als Ergebnis erhält man ein Zertifikat, üblicherweise im PEM-Format (meist .pem oder .crt), welches im Switch importiert werden muss. Erhält man stattdessen eine DER oder P7B-Datei kann diese an einem PC z.B. mit openssl konvertiert werden. Nach Eingabe des Importbefehls erwartet der Switch den Inhalt der PEM-Datei als Texteingabe. Unter Windows mit PuTTy kann mit einem Rechtsklick eingefügt werden.

Mit Erkennen der “END CERTIFICATE“-Zeile kehrt der Switch automatisch zur Konfigurationsoberfläche zurück.  Das Zertifikat sollte nun in der Liste der installierten Zertifikate zu sehen sein.

Zuletzt wird HTTPS ein- und HTTP ausgeschaltet. Das zuvor installierte und somit einzige Zertifikat sollte automatisch verwendet werden.

Somit ist der Switch nicht mehr unverschlüsselt verwaltbar und die zuständigen “Administratoren” teilen ihr Passwort nicht mehr zwangsläufig allen Lauschern im Netz servierfertig mit. Mit etwas Glück spart das Ganze am Ende mehr Arbeit als das turnusmäßige Auffrischen der Zertifikate verursacht. Wenn nicht schont der nicht mehr vorhandene HTTP-Login  immerhin meine Nerven.