Der privilegierteste Port im Rack ist der, den niemand beachtet

Jeder moderne Server trägt einen zweiten, kleineren Computer in sich: den Management-Controller. Auf HPE-Servern ist das iLO, auf Dell-Servern iDRAC, und in Blade-Enclosures sitzt ein Onboard Administrator über den Blades. Er wird oft als Bequemlichkeit für Neustarts aus der Ferne behandelt. Tatsächlich ist er die privilegierteste Komponente im Rack, und er verdient es, dass man um ihn herum plant.

Was ein Management-Controller kann

Alle Härtung (Hardening), die Sie innerhalb des Betriebssystems vornehmen, geht am Thema vorbei, wenn der Controller für die falschen Leute erreichbar ist.

Regel eins: eigener Port, eigenes Netzwerk

Die meisten Server können den Controller entweder über einen dedizierten Managementport betreiben oder gemeinsam mit einem der Hauptnetzwerkports. Die gemeinsame Nutzung ist bequem, weil sie ein Kabel und einen Switchport spart. Sie setzt den Controller aber in dasselbe Netzwerk wie den normalen Datenverkehr des Servers, und genau dort sollte er nicht sein.

Wir geben jedem Controller seinen eigenen physischen Port, sein eigenes Kabel und sein eigenes Switching, in einem privaten Adressraum, der nie in ein Kundennetz oder aus einem Kundennetz geroutet und nie ins Internet announct wird. Das meinen wir mit einem physisch getrennten (air-gapped) Managementnetz. Eine Kundenmaschine, selbst eine kompromittierte, hat keinen Pfad zu irgendeinem Controller. Ingenieure erreichen das Managementnetz nur über unsere eigenen VPN-Gateways und Jump-Hosts.

Die aktuelle Einstellung können Sie am Controller selbst prüfen. Auf iDRAC:

racadm get iDRAC.NIC.Selection      # Dedicated, or one of the LOM ports
racadm get iDRAC.IPv4               # address, gateway, DHCP state

Auf jedem Server mit installierten IPMI-Werkzeugen, aus dem Betriebssystem heraus:

ipmitool lan print 1

Das zeigt die Adresse des Controllers, das VLAN und die Cipher Suites, die er über das Netzwerk akzeptiert.

Regel zwei: abschalten, was Sie nicht nutzen

Controller werden mit mehreren Zugangswegen ausgeliefert, und jeder davon ist Angriffsfläche. Prüfen Sie sie auf jeder Maschine:

• IPMI over LAN. Älter und weniger sicher als die Web- und SSH-Schnittstellen des Controllers. Wenn nichts in Ihren Werkzeugen es braucht, deaktivieren Sie es (racadm get iDRAC.IPMILan.Enable zeigt den Zustand auf iDRAC). Wenn etwas es doch braucht, stellen Sie sicher, dass nur starke Cipher Suites akzeptiert werden.
• Zeit und Protokollierung. Richten Sie den Controller auf Ihre eigenen Zeitquellen aus, und senden Sie seine Logs und SNMP-Traps an Ihre Management-Collectors.

Regel drei: richtig lizenzieren

Nacktes IPMI gibt Ihnen Stromsteuerung und nicht viel mehr. Die lizenzierten Stufen sind es, die einen Controller für den echten Betrieb nützlich machen: eine Remote-Konsole, die zuverlässig funktioniert, Virtual Media für Installationen aus der Ferne, vollständige Hardware-Telemetrie und Firmware-Verwaltung. Wir betreiben iDRAC Enterprise mit Datacenter-Lizenz auf Dell-Servern, iLO Advanced auf HPE-Servern und redundante Onboard Administrators in jedem Blade-Enclosure. Ein Server, der über seinen Controller nicht vollständig erreichbar ist, ist ein Server, der einen Menschen vor sich braucht, und das ist die teure Art, ein Rechenzentrum zu betreiben.

Das ganze Enclosure auf einmal konfigurieren

Bei HPE-Blade-Enclosures gibt es einen besseren Weg. Der Onboard Administrator kann ein Konfigurationsskript über die Backplane des Enclosures in einem einzigen Vorgang an das iLO jedes Blades weitergeben, im RIBCL-Skriptformat von HPE über den Befehl HPONCFG. Das Enclosure authentifiziert sich selbst gegenüber jedem iLO, es sind also keine Zugangsdaten pro Blade nötig. Das heißt, ein Blade, das am Vormittag ins Rack kam und noch kein eigenes Passwort hat, kann am Nachmittag vollständig konfiguriert sein.

Ein typischer Durchlauf über das ganze Enclosure setzt die Lizenz, legt ein Managementkonto an, setzt das Session-Timeout, richtet Zeit und SNMP auf die Management-Collectors aus und wird von einem zweiten Durchlauf gefolgt, der jede Einstellung zur Verifikation zurückliest. Dell hat das Gegenstück im racadm-Scripting und in Server Configuration Profiles. Welchen Hersteller Sie auch verwenden, das Prinzip ist dasselbe: eine schriftliche Konfiguration, identisch angewendet, durch Zurücklesen verifiziert.

Kunden Zugang geben, ohne das Modell zu brechen

Kunden mit Dedicated servers brauchen manchmal eigenen Konsolenzugang. Standardmäßig nutzen unsere Ingenieure die Remote-Konsole im Auftrag des Kunden, rund um die Uhr. Wo ein Kunde direkten iLO- oder iDRAC-Zugang braucht, stellen wir ihn über ein dediziertes VPN bereit, so dass der Controller selbst im isolierten Managementnetz bleibt und nur der Controller dieses Kunden darüber erreichbar ist.

Prüfen Sie Ihre eigenen Controller

• Hängt jeder Controller an einem dedizierten Port, oder teilen sich einige einen Datenport?
• Ist irgendein Controller aus einem Kundennetz oder aus dem Internet erreichbar?
• Ist IPMI over LAN irgendwo aktiv, wo es nicht gebraucht wird?
• Sind noch Werkskonten aktiv?
• Erreichen die Logs und Traps der Controller Ihr Monitoring?
• Gibt es eine schriftliche Konfiguration, gegen die jeder Controller geprüft wird?

Wenn Sie Ihre Hardware von jemandem betreiben lassen möchten, bei dem die Controller dort weggeschlossen sind, wo sie hingehören, sprechen wir gern darüber. Mit einem Ingenieur sprechen

Verwandt: Rack-Aufbau, Blade-Onboarding, Management-Controller · Die Hardening-Baseline auf jedem Host · DCIM: jedes Objekt, jeder Port, jedes Kabel und jede Adresse erfasst