Sicheres PRIMERGY Server Management Enterprise Security

Transkript

1 Sicheres PRIMERGY Server Management Enterprise Security Ausgabe Mai 2009 Seiten 30 PRIMERGY Server Management Sicherheit für hochverfügbare Plattformen Sicherheit ist wichtig für geschäftskritische IT Infrastrukturen Je mehr Unternehmen E-Business- und mobilitätsorientierte Lösungen einsetzen und dadurch ihre Informationssysteme über das Internet für Kunden und Partner öffnen, umso wichtiger wird die IT-Sicherheit, um Angriffspunkte zu vermeiden. Security Management ist ein fortlaufender Prozess. Dieses White Paper beschreibt das Modell für ein sicheres PRIMERGY Server Management: Es wird davon ausgegangen, dass Sie bereits über eine sichere Systemkonfiguration ohne Server Management Tools verfügen. Das vorliegende Dokument enthält viele Hinweise für die Installation eines sicheren PRIMERGY Server Management Systems.

2 White Paper Ausgabe: Mai 2009 Sicheres PRIMERGY Server Management Seite 2 / 30 Inhalt 1. Vorwort 3 2. "Security Management ist ein Prozess" Erarbeiten eines Sicherheitskonzepts Eine permanente Anpassung ist erforderlich 3 3. Allgemeine Fragen Kommunikationspfade Schutz durch Firewalls Offene Ports Separates Management LAN Konfiguration, Installation and Deployment von PRIMERGY Servern Entfernte Installation mit dem Installation Manager RAID Manager Deployment Manager SNMP-Agenten auf verwalteten Servern SNMP-Service ServerView-Agenten Absichern von SNMP Operationen mit IPsec Administration SNMP Service Installation der Web Server für den Operations Manager SSL für den Operations Manager Set-Operationen mit Benutzerauthentifizierung Event Manager und Antiviren-Programme Maintenance Download Manager Update Manager Boot-fähige Update CD PrimeUp PrimeCollect SNMP-Agenten für out-of-band Management auf RSB / RSB S2 / RSB S2 LP / irmc auf dem RSB als Konzentrator auf dem Remote Management Blade Out-of-band Management Remote Management/LAN Front-end mit BMC/IPMI Remote Management/Web Front-end mit BMC/IPMI Remote Management/Modem Front-end mit Remote Management/Diagnostic System (chipdisk/rtds) Paralleles Management mit speziellen Hardware-Komponenten, wie RSB, irmc oder Management Blade Sonderkonfiguration Erstellen von Web-Agenten Verwaltete Server in einer Demilitarisierten Zone Zusammenfassung Log Files Glossar Weitere Informationen über Enterprise Security 30

3 White Paper Ausgabe: Mai 2009 Sicheres PRIMERGY Server Management Seite 3 / Vorwort Security Management, ist wie das Qualitätsmanagement, ein fortwährender Prozess. Dieses White Paper ist daher kein Leitfaden für die Sicherheitsanalyse und für die Festlegung von Sicherheitsstrategien. Beides sind wichtige Schritte, die wesentlich allgemeiner und umfassender zu betrachten sind, als es im Rahmen dieses Dokumentes möglich ist. Wir gehen davon aus, dass Sie über eine sichere Systemkonfiguration verfügen und diese um PRIMERGY Server-Management-Komponenten ergänzen wollen. Das vorliegende Dokument enthält Hinweise wie Sie diese Sicherheit erhalten und wie die die Sicherheit von Managementoperationen erhöhen können. Mehr Sicherheit bedeutet auch mehr Aufwand, zum Beispiel für Planung oder Konfiguration. Welche dieser Regeln und Hinweise Sie umsetzen, liegt in Ihrem Ermessen und muss im Kontext Ihrer Gesamtstrategie für die Sicherheit entschieden werden. Es werden alle Phasen des Life Cycles in diesem Dokument betrachtet: Installation and Deployment (Kapitel 4) Überwachung und Administration (Kapitel 5 und Kapitel 6) Maintenance (Kapitel 7) Wiederherstellung und out-of-band Management (Kapitel 7.4 und 9) 2. "Security Management ist ein Prozess" Sicherheit kann nicht durch ein Produkt oder eine Lösung bereitgestellt werden. Nur durch einen ständigen Security Management-Prozess ist es möglich, Sicherheit zu erzielen. Dies ist vergleichbar mit dem ständigen Qualitätsmanagementprozess. Ein anderer Punkt ist, dass Sicherheit nicht durch bloße Prävention erreicht werden kann. Präventionssysteme sind nie perfekt. Eine Sicherheitsstrategie muss immer die Prävention, die Erkennung und die Reaktion umfassen Erarbeiten eines Sicherheitskonzepts Robuste und sensible IT-Systemsicherheit entsteht aus der korrekten Implementierung und Pflege einer klar definierten Sicherheitsstrategie. Eine solche Sicherheitsstrategie muss - neben den technischen Fragen - eine ganze Reihe verschiedener Aspekte, wie zum Beispiel organisatorische Fragen, menschliche Aspekte, Risikowahrscheinlichkeiten und Risikobewertung, in Betracht ziehen. Im Prinzip müssen die folgenden Schritte ausgeführt werden, um zu einer klar definierten Sicherheitsstrategie zu kommen: Analyse der zu schützenden Vermögenswerte Analyse der Bedrohungen Bewertung der Risiken - Primäre Auswirkungen, wie zum Beispiel Verlust, Zerstörung, finanzielle Auswirkungen - Sekundäre Auswirkungen, wie zum Beispiel Verzögerungen, Geschäftsausfälle - Drittrangige Auswirkungen, wie zum Beispiel Vertrauensverlust, Verlust von Kunden Entscheidung, sich gegen bestimmte Bedrohungen zu schützen Auswahl eines geeigneten Maßnahmenkatalogs Berechnung der Kosten Bewertung der verbleibenden Risiken Es ist sehr wahrscheinlich, dass einige dieser Schritte mehrfach durchgeführt werden müssen, es wird sich also eher um einen Schleifenverlauf als um eine reine Abfolge von Schritten handeln. Wenn beispielsweise die "Berechnung der Kosten" aufzeigt, dass die Kosten höher wären als der Schaden, muss der Schritt "Auswahl eines geeigneten Maßnahmenkatalogs" wiederholt werden. Weitere Informationen finden Sie unter: Eine permanente Anpassung ist erforderlich Wenn Sie alle diese Schritte durchlaufen haben, haben Sie eine Sicherheitsstrategie für die Situation erstellt, wie sie sich zum Zeitpunkt der Durchführung des ersten Schrittes "Analyse der zu schützenden Vermögenswerte" darstellte. In extremen Fällen kann die neue Sicherheitsstrategie jetzt schon wieder überholt sein. In der Regel ist dies zwar nicht der Fall, aber es zeigt, dass eine Sicherheitsstrategie periodisch sowie bei größeren Änderungen in Bezug auf die Vermögenswerte, neue potentielle Bedrohungen sowie die Verfügbarkeit neuer Maßnahmen usw. angepasst werden muss. Für die Überlegungen in diesem White Paper wird davon ausgegangen, dass bereits eine umfassende Sicherheitsstrategie -ein Rahmen an Regeln und deren Implementierung- für das IT-Geschäft entwickelt wurde, um die Sicherheitsziele zu erreichen. Immer wenn neue Komponenten hinzugefügt, Prozesse verändert, organisatorische Aspekte oder andere Faktoren modifiziert werden, muss auch die Sicherheitsstrategie angepasst werden. Eine solche Anpassung wird auch erforderlich, wenn ein bestimmtes Server Management Tool eingeführt wird.

4 White Paper Ausgabe: Mai 2009 Sicheres PRIMERGY Server Management Seite 4 / 30 Bild 1: Sicherheitsansatz Bild 1 illustriert diesen grundlegenden Ansatz, der aus den beiden Schritten "Get Secure" (Sicherheit herstellen) und "Stay Secure" (Sicherheit aufrechterhalten) besteht. In einer Microsoft-Umgebung kann zur Unterstützung des ersten Schritts Get Secure der Microsoft Baseline Security Analyzer (MBSA) verwendet werden. Dieses Werkzeug unterstützt kleinere und mittlere Unternehmen dabei, ihre Konfiguration im Hinblick auf Sicherheit und im Vergleich zu Microsofts Sicherheitsempfehlungen zu bewerten, und schlägt entsprechende Maßnahmen vor. Weitere Information zu diesem Thema finden Sie unter: Die Grundannahme für unsere Überlegungen ist, dass Sie den ersten Schritt bereits durchgeführt, d.h. eine sichere Systemkonfiguration erreicht haben und nun eine Komponente der PRIMERGY ServerView Suite hinzufügen bzw. Änderungen vornehmen. Dieses Dokument gibt Ihnen Hinweise und Regeln, die Sie beim Schritt "Stay Secure" (Sicherheit aufrechterhalten) unterstützen: Wie erhalte ich Sicherheit des Gesamtsystems aufrecht? So kann zum Beispiel die Installation eines Web Servers zu Sicherheitslücken führen, wenn Sie bestimmte Regeln nicht beachten. Wie kann ich die Sicherheit der Server-Management-Operationen verbessern? Zum Beispiel, damit nicht autorisierte Personen keine Management-Aktivitäten durchführen können. Die Sicherheitsaspekte und Auswirkungen der Nutzung eines bestimmten Server Management Tools müssen im Kontext der vorhandenen IT-Konfiguration, aber auch im Kontext der vorhandenen Sicherheitsstrategie bewertet werden. Beide sind individuell unterschiedlich. Aus diesem Grund kann dieses Dokument keine Sicherheitslösungen in Bezug auf das Server Management bieten, es stellt Ihnen jedoch Informationen und Unterstützung für die Anpassung Ihrer Sicherheitsstrategie bei der Verwendung der ServerView Suite für PRIMERGY Server bereit. Wie bereits oben erwähnt wurde, sind Präventionssysteme nie perfekt. Die Anzahl potentieller Lücken ist einfach zu groß, und die Angreifer sind opportunistisch: sie gehen den einfachsten und bequemsten Weg. Sie nutzen die bekanntesten Fehler mit den effektivsten und verbreitetesten Angriffs-Tools. Diese Sicherheitslücken sollten geschlossen werden. Sie sind detailliert unter: beschrieben. An verschiedenen Stellen in den folgenden Abschnitten wird ebenfalls darauf Bezug genommen.

5 White Paper Ausgabe: Mai 2009 Sicheres PRIMERGY Server Management Seite 5 / Allgemeine Fragen 3.1. Kommunikationspfade Dieses Kapitel beschreibt die Kommunikationspfade zwischen den unterschiedlichen Komponenten der PRIMERGY ServerView Suite. Wie im Handbuch ServerView Suite: Grundlegende Konzepte beschrieben, lassen sich diese Komponenten den folgenden vier Kategorien zuordnen: Management-Konsolen Management-Applikationen Helper Verwaltete Server Seit der letzten Version dieses White Papers wurden einige Komponenten umbenannt. Die nachfolgende Tabelle stellt diese neuen Namen den alten Namen gegenüber. Neuer Name Installation Manager (IM) Operations Manager (OM) Event Manager (EM) Update Manager(UM) Remote Management (REM) Deployment Manager (DM) Storage Manager (STM) RAID Manager (RM) Configuration Manager Bisheriger Name ServerStart ServerView S2 Alarm Service Global Flash RemoteView RemoteDeploy StorMan SV RAID Remote SCU (Server Configuration Utility) Bild 2 zeigt die Kategorisierung dieser Komponenten und wie sie miteinander kommunizieren. Die Komponenten können auf verschiedenen Rechnern installiert sein. Es ist jedoch auch möglich, mehrere Komponenten unterschiedlicher Kategorien auf demselben Rechner zu installieren. Browser Installation Manager Configuration Manager Deployment Java Front-end Operations Manager Event Manager PostgreSQL DB Update Manager Deployment Manager Image Repository Deployment Server - Remote Control - RemoteDeploy Service Storage Manager Installation Manager Management- Konsolen Management- Applikationen Win32-based ServerView Win32-based RemoteView Win32-based GlobalFlash Helper PXE Server DHCP Server FTP Server TFTP Server Verwaltete Server PRIMERGY server - SNMP Agent - Update Agent - RSB / RMC - RSB S2 / irmc + SNMP Agent + SNMP Traps + Consol Redirection + Console Redirection + Web Server + Web server + Power Management + Power Management + Mail + Mail - Cloning Agent (pre-os) + Remote Media - PXE Client (pre-os) - WinPE/DOS (pre-os) - RAID Manager (UI/CLI, dispatcher, Controller Plug-Ins) PRIMERGY Blade server - Management Blade + SNMP Agent + Consol Redirection + Web Server + Power Management + Mail - CPU Blade + SNMP Agent + Update Agent + Cloning Agent (pre-os) + WinPE/DOS (pre-os) + PXE Client (pre-os) - KVM Bild. 2: Kommunikationspfade der ServerView Suite für PRIMERGY Server

6 White Paper Ausgabe: Mai 2009 Sicheres PRIMERGY Server Management Seite 6 / 30 Die folgende Tabelle beschreibt, welche Kommunikationsprotokolle verwendet werden und welche Standard-Ports jeweils eingesetzt werden. Standardmäßig werden hauptsächlich bekannte Ports (im Bereich von 0 bis 1023) und IANA-registrierte Ports (1024 bis 49151) genutzt. Die Ports 3169 bis 3173, 3789, 9212 und 9213 und wurden bei IANA exklusiv für die PRIMERGY ServerView Suite registriert. Weitere Informationen finden Sie unter: Es können jedoch alle Ports individuell unter anderen Port-Nummern konfiguriert werden. : Kommunikationspfad in beide Richtungen : Kommunikation in eine Richtung Kommunikation Browser Operations Manager Browser Event Manager Browser Update Manager Browser Remote Management/Web Frontend Browser Deployment Manager RD-Java Front-end Deployment Manager Port: Protokoll Zweck Management-Konsolen Management-Applikationen 80: UDP/TCP Web HTTP (konfigurierbar), für: - IIS auf Windows - (vor August 2008: Apache Web Server on Linux) 443: UDP/TCP HTTP over TLS/SSL (konfigurierbar), für - IIS auf Windows - (vor August 2008: Apache Web Server on Linux) 3169 (IANA-registrierter Port): UDP/TCP HTTP (konfigurierbar) 3170 (IANA-registrierter Port): UDP/TCP HTTP over TLS/SSL(konfigurierbar) Administrator Event Manager 25: UDP/TCP SMTP Mail (konfigurierbar) Win32-based ServerView SNMP-Agent Win32-based ServerView SNMP-Agent (RSB/iRMC) Win32-based ServerView SNMP-Agent (Management Blade) Win32-based ServerView SNMP-Agent (CPU Blade) Win32-based ServerView SNMP-Agent (Management Blade) Management-Konsolen Verwaltete Server 161: UDP/TCP SNMP Win32-based ServerView SNMP-Agent Win32-based ServerView SNMP-Agent (RSB/iRMC/RSB S2) Win32-based ServerView SNMP-Agent (CPU Blade) Win32-based ServerView SNMP-Agent (Management Blade) Browser (Advanced Console Redirection) RSB/iRMC/RSB S2 Web-Server Browser RemoteView Management Blade: Web- Server Browser RSB S2 Remote Media (FD/CDROM/Image) Browser irmc Advanced Console Redirection 162: UDP/TCP SNMP Traps 80: UDP/TCP Web HTTP (konfigurierbar), für: - RSB-included Web server - RSB-ACR (Advanced Console Redirection) 443: UDP/TCP HTTP over TLS/SSL (konfigurierbar), für - RSB-included Web server - RSB-ACR (Advanced Console Redirection) 3260: UDP/TCP iscsi Server (konfigurierbar) 81: UDP/TCP Remote Media Configuration via HTTP protocol (konfigurierbar) 5900: UDP/TCP 5902: UDP/TCP 5903: UDP/TCP 5904: UDP/TCP

7 White Paper Ausgabe: Mai 2009 Sicheres PRIMERGY Server Management Seite 7 / 30 Kommunikation Browser irmc Remote Media Browser irmc Text Console Browser Digital KVM (BX 600 dkvm) Hinweis: Alle Default Ports können bei Bedarf manuell geändert werden. Browser / S3 Client SW External KVM KVM S / KVM S / KVM S Win32-based ServerView RomPilot Port: Protokoll Zweck 5901: UDP/TCP Transfer von FD/CDROM/Image 22: TCP (SSH, konfigurierbar) 3172: TCP (Telnet, konfigurierbar) : TCP Verschlüsselte Tastatur und Maus Daten 1078: TCP Video Port, Virtual Console (Viewer) 3169: TCP Virtual Media 80: Web Server HTTP 3211: UDP/TCP Proprietäres Protokoll 2068: TCP Verschlüsselte Tastatur und Maus Daten, digitalisierte Video Daten, Virtual Media 8192: TCP Digitalisierte Video Daten 389: UDP LDAP (non-secure) 636 UDP LDAP (secure) 4877: UDP/TCP vor Start des Betriebssystems Win32-based RemoteView RSB/iRMC/RSB S2 Text Console Redirection Win32-based RemoteView Management Blade Text Console Redirection 623: UDP: IPMI over LAN / RMCP 3172 (IANA-registrierter Port): UDP/TCP (SSL) Telnet: Console Redirection Remote Manager Interface (konfigurierbar) Administrator RSB/RSB S2/iRMC/Management-Blade: Mail Forwarding Browser RAID Manager Configuration Manager PRIMERGY Server Configuration Manager CPU Blade Installation Manager Installation Agent (WinPE) 25: UDP/TCP SMTP Mail (konfigurierbar) 3173 (IANA-registrierter Port): UDP/TCP HTTP over SSL 3172 (IANA-registrierter Port): UDP/TCP SV Connector Service (SCS) 9213 (IANA registrierter Port): UDP/TCP ServerStart Remote Control (configurable) Management-Applikationen Management-Applikationen Operations Manager PostgreSQL DB (nur Linux) Event Manager PostgreSQL DB (nur Linux) 9212 (IANA-registered port): UDP/TCP Event Manager Operations Manager Operations Manager Storage Manager Deployment Manager Remote Control (Deployment Server) Deployment Manager Deployment Service (Deployment Server) Dynamic: UDP SNMP: Benachrichtigung vom Event Manager für Operations Manager 4178 (IANA registrierter Port):: UDP/TCP StorMan 3789 (IANA-registrierter Port): TCP Aufträge für administrative Konfigurationen und Start von Deployment Jobs (via RD Job API) 4971/4972: UDP/TCP Private Ports (Fujitsu) nicht registriert

8 White Paper Ausgabe: Mai 2009 Sicheres PRIMERGY Server Management Seite 8 / 30 Kommunikation Deployment Manager Image Repository Deployment Service (Deployment Server) Image Repository Port: Protokoll Zweck 137 / 138 / 445: Microsoft SMB Microsoft: Remote Network Drive Operations Manager SNMP-Agent Event Manager SNMP-Agent Operations Manager SNMP-Agent (RSB/iRMC) Event Manager SNMP-Agent (RSB/iRMC) Operations Manager SNMP-Agent (CPU Blade) Event Manager SNMP-Agent (CPU Blade) Remote Control (DLL on Deployment Server) SNMP-Agent (CPU Blade) Operations Manager SNMP-Agent (Management Blade) Event Manager SNMP-Agent (Management Blade) Remote Control (DLL on Deployment Server) SNMP-Agent (Management Blade) Management-Applikationen Verwaltete Server 161: UDP/TCP SNMP 623: UDP IPMI over LAN / RMCP Operations Manager SNMP-Agent Event Manager SNMP-Agent Operations Manager SNMP-Agent (RSB/iRMC) Event Manager SNMP-Agent (RSB/iRMC) Operations Manager SNMP-Agent (CPU Blade) Event Manager SNMP-Agent (CPU Blade) Remote Control (DLL on Deployment Server) SNMP-Agent (CPU Blade) Operations Manager SNMP-Agent (Management Blade) Event Manager SNMP-Agent (Management Blade) Remote Control (DLL on Deployment Server) SNMP- Agent (Management Blade) Operations Manager SNMP Agent (Performance Management & Power Management & Online Diagnosis Results) Update Manager Update Agent Update Manager Update Agent (CPU Blade) Update Manager Management Blade Deployment Service (Deployment Server) Cloning Agent (CPU Blade) Installation Manager Installation Agent (WinPE) Remote Management/Web Frontend Management Blade Text Console Redirection Remote Management /Web Frontend irmc Text Console Redirection Operations Manager BMC/iRMC Operations Manager VMware Host 162: UDP/TCP SNMP Traps 3172 (IANA-registrierter Port): UDP/TCP SV Connector Service 3171 (IANA-registered port): TCP Firmware flash (konfigurierbar) 161: UDP/TCP SNMP 80: UDP/TCP Web HTTP : UDP/TCP Private ports (Fujitsu) not registered 9213 (IANA-registrierter Port): UDP/TCP ServerStart RemoteControl (konfigurierbar) 623: UDP: IPMI over LAN / RMCP 3172 (IANA- registrierter Port): UDP/TCP (SSL) Telnet: Console Redirection Remote Manager Interface (konfigurierbar) 623: UDP RMCP / IPMI over LAN 443: UDP/TCP HTTP over TLS/SSL (SOAP) Operations Manager Xen Host 9363: TCP XML-RPC Management-Applicationen Helpers

9 White Paper Ausgabe: Mai 2009 Sicheres PRIMERGY Server Management Seite 9 / 30 Kommunikation Update Manager PXE Server (Update Proxy) Update Manager TFTP Server (Update Proxy) Deployment Service PXE Server Port: Protokoll Zweck 3171 (IANA- registrierter Port): TCP Firmware flash (konfigurierbar) Local Update Agent PXE Server (Update Proxy) Verwaltete Server Helpers 3171 (IANA-registrierter Port): TCP Firmware flash (konfigurierbar) Cloning Agent DHCP Server Cloning Agent (CPU Blade) DHCP Server Update Agent PXE Server (PXE Boot) Cloning Agent PXE Server PXE Client PXE Server WinPE PXE Server Cloning Agent (CPU Blade) PXE Server PXE Client (CPU Blade) PXE Server WinPE (CPU Blade) PXE Server Update Agent PXE Server (PXE Boot) Cloning Agent TFTP Server PXE Client TFTP Server WinPE TFTP Server Cloning Agent (CPU Blade) TFTP Server PXE Client (CPU Blade) TFTP Server WinPE (CPU Blade) TFTP Server Update Agent PXE Server (PXE Boot) Management Blade TFTP Server RSB S2 LP TFTP Server Management Blade TFTP Server 67: UDP/TCP Bootstrap Protocol Server (bootps) 4011: UDP/TCP Alternate Service Boot 69: UDP/TCP Trivial File Transfer (TFTP) 161: UDP/TCP SNMP 80: UDP/TCP Web HTTP RSB/iRMC (Power Management) Server (Power Management) Remote RSB Configuration via CLI Verwaltete Server Verwaltete Server 3173 (IANA-registrierter Port): UDP/TCP XML: Power Management Switch server on/off via RSB Remote RSB configuration (konfigurierbar) 3.2. Schutz durch Firewalls Firewalls werden eingesetzt, um Angriffe aus dem öffentlichen Internet zu verhindern. Falls sich alle Komponenten hinter der Firewall befinden, sind auch alle Kommunikationspfade vor Angriffen aus dem öffentlichen Internet geschützt. Trotzdem kann der Administrator jederzeit und von jedem Ort aus mittels eines Browsers über das Internet auf das Management zugreifen. In dieser idealen Situation müssen nur die folgenden Kommunikationspfade die Firewall passieren: zwischen dem Browser mit Java-GUIs (Management-Konsole) und den Applikationen, wie z.b. Operations Manager oder Deployment Manager, und zwischen dem Browser mit Java-GUIs (Management-Konsole) und den Web-Servern auf dem RSB, irmc, RSB S2, und dem Management Blade. Diese Kommunikationspfade können über SSL gesichert werden, wie weiter unten beschrieben wird. Empfehlung 1 Lokalisieren Sie alle Komponenten/Tools der PRIMERGY Management Produkte gemeinsam mit den verwalteten Systemen hinter der Firewall. Auf die Web-basierten Tools kann mittels eines Browsers über das Internet zugegriffen werden. Diese Kommunikationspfade müssen durch SSL gesichert werden (siehe auch Empfehlung 19). Es kann aber auch Konfigurationen geben, wo SNMP Traps Firewalls passieren müssen, um über Ereignisse zu informieren, die innerhalb des durch den Firewall geschützten Bereichs auftreten. In diesem Fall müssen Sie dafür sorgen, dass die Firewall für UDP Port 162 geöffnet ist, andernfalls würden die SNMP Traps blockiert.

10 White Paper Ausgabe: Mai 2009 Sicheres PRIMERGY Server Management Seite 10 / Offene Ports Sowohl berechtigte Benutzer als auch Angreifer stellen die Verbindung zu den Systemen über offene Ports her. Je mehr Ports offen sind, desto mehr Möglichkeiten gibt es, dass jemand eine Verbindung zu Ihrem System herstellen kann. Aus diesem Grund ist es entscheidend, möglichst nur so wenige Ports für ein System offen zu lassen, wie dieses System für ein einwandfreies Funktionieren benötigt. Alle anderen Ports müssen geschlossen werden. Die Tabellen oben vermitteln Ihnen die erforderlichen Informationen, anhand derer Sie entscheiden können, welche Ports für das PRIMERGY Server Management offen sein müssen. Wie das Bild 2 zeigt, kann dies von System zu System variieren und ist abhängig von der Konfiguration und den im System angesiedelten Komponenten/Tools. Empfehlung 2 Minimieren Sie die Anzahl der offenen Ports für jedes System. Die Tabellen oben zeigen, welche offenen Ports von der PRIMERGY ServerView Suite benötigt werden Separates Management LAN Der Einsatz von Firewalls und das Schließen nicht benötigter Ports dienen dem Ziel, die Management-Komponenten vor nicht autorisiertem Zugriff zu schützen. Dies kann auch erreicht werden durch das Trennen des LANs in ein Management LAN und ein operationelles LAN, zum Beispiel durch Konfigurieren entsprechender VLANs, wodurch der Verkehr auf dem Management LAN auf logischer Ebene abgeschirmt wird vom Verkehr auf dem operationellen LAN. Auf der Grundlage von Bild 2 und den Tabellen, welche die Kommunikationspfade für PRIMERGY Management beschreiben, können Sie eine VLAN-Topologie planen, entweder für die komplette Management-Kommunikation oder für ausgewählte sicherheitsrelevante Pfade. Empfehlung 3 Die Trennung der Management-Kommunikation vom operationellen Verkehr auf dem LAN kann ein wesentlicher Beitrag zu verbesserter Sicherheit leisten. Dazu können Sie eine VLAN-Topologie für die Management-Kommunikation einrichten auf der Grundlage von Bild 2 und den Tabellen, welche die Kommunikationspfade für PRIMERGY Management beschreiben. Das Remote Management Service Board (RSB, RSB S2), der Remote Management Controller (irmc) sowie das RemoteView Management Blade haben ihren eigenen Netzwerkanschluss. Dadurch können Sie ein separates physikalisches Management- Netzwerk aufbauen zwischen diesen Komponenten und den entsprechenden Front-ends. Dies ist zwar mit zusätzlichem Aufwand verbunden, aber es führt auch zu einem sehr hohen Sicherheitsgrad beim PRIMERGY Management. Empfehlung 4 Das RSB, RSB S2, irmc, irmc S2 und das RemoteView Management Blade haben eigene Netzwerkanschlüsse, wodurch der Aufbau eines physikalisch getrennten Management LANs möglich ist. Dies stellt auf physikalischer Ebene sicher, dass alle sicherheitskritischen Operationen auf diesen Komponenten nur von entfernten Knoten angestoßen werden können, die mit diesem physikalischen Management LAN verbunden sind. 4. Konfiguration, Installation and Deployment von PRIMERGY Servern Für Konfiguration, Installation und Deployment von PRIMERGY Servern stehen Ihnen die folgenden Werkzeuge zur Verfügung: Installation Manager für die lokale oder entfernte Installation ServerView RAID Manager für die Administration unterschiedlicher RAID Controller mit einem einheitlichen Web User Interface Deployment Manager für entfernte Massen-Installationen oder Massen-Cloning, d.h. das effiziente Einrichten einer großen Anzahl identischer Server. Mit der Multi-Deployment Platform (MDP) steht eine Service Plattform zur Verfügung, die es erlaubt, lokale oder entfernte Deployment-Prozesse auf Zielrechnern anzustoßen und durchzuführen. Die Bootfähige Update CD können Sie verwenden, um die Firmware verschiedener Serverkomponenten oder das Server- BIOS zu aktualisieren, bevor ein Betriebssystem auf dem verwalteten Server installiert ist. Weitere Information dazu finden Sie im Kapitel 7.3 Boot-fähige Update CD 4.1. Entfernte Installation mit dem Installation Manager Mit dem Installation Manager können Sie neben lokalen Installationen auch entfernte (remote) Installationen durchführen, und zwar auf bis zu fünf Servern parallel. Eine entfernte Installation besteht aus zwei Phasen: einer lokalen Vorbereitungsphase, gefolgt von der entfernten Installation, die als Replikation durchgeführt wird. Voraussetzung für eine entfernte Installation mit dem Installation Manager ist, dass ein Deployment Server eingerichtet wird. Dabei wird der Dateibaum der Installation Manager CD auf die Festplatte des Deployment Servers kopiert und als Netzlaufwerk konfiguriert. Der Zugriff auf dieses Netzlaufwerk kann während der Installation des Installation Managers auf dem Deployment Server so konfiguriert werden, dass er durch Benutzername und Passwort geschützt ist. Bevor dann eine entfernte Installation eines Zielsystems angestoßen wird, muss der Administrator Benutzername und Passwort eingeben andernfalls kann der Installationsprozess auf dem Zielsystem nicht auf den Dateibaum zugreifen. Dadurch werden unberechtigte entfernte Installationen ausgeschlossen. Der Installation Manager verwendet für entfernte Installationen noch ein weiteres Netzlaufwerk mit dem Installation Manager- Betriebssystem (WinPE). Auf dieses Netzlaufwerk wird über TFTP aus Sicherheitsgründen ausschließlich im Lesemodus

11 White Paper Ausgabe: Mai 2009 Sicheres PRIMERGY Server Management Seite 11 / 30 zugegriffen. Falls dies trotzdem als zu risikoreich betrachtet wird, empfehlen wir den Installation Manager nur lokal zu verwenden. Empfehlung 5 Benutzen Sie eine Benutzerkennung, die Ihrer Sicherheitsstrategie entspricht, um damit den Zugriff auf das Netzlaufwerk mit dem Dateibaum des Installation Managers zu schützen. Dies schützt vor unberechtigten entfernten Installationen mit dem Installation Manager. Falls der TFTP-Zugriff auf das Installation Manager-Betriebssystem Netzlaufwerk, der ausschließlich im Lesemodus passiert, zu risikoreich eingestuft wird, empfehlen wir, den Installation Manager nur für lokale Installationen zu verwenden. Die entfernte Installation kann auch als Referenzinstallation im Zusammenhang mit dem Deployment Manager verwendet werden. Näheres dazu finden Sie im Kapitel Referenzinstallation mit. Die entfernte Massen-Installation mit dem Deployment Manager ist im Kapitel Entfernte Massen-Installation beschrieben RAID Manager Mit dem ServerView RAID Manager können Sie unterschiedliche RAID Controller über eine einheitliche Web-basierte Benutzeroberfläche konfigurieren und verwalten. Der ServerView RAID Manager kann lokal oder entfernt gestartet werden. Wenn der RAID Manager entfernt läuft, wird HTTPS als Kommunikationsprotokoll und der für ServerView IANA-registrierte Port 3173 verwendet, d.h. die Kommunikation wird durch SSL verschlüsselt. Zu diesem Zwecke erzeugt der ServerView RAID Manager für jedes System, auf dem er installiert ist, ein Zertifikat. Er verwendet also self-signed Zertifikate für die Absicherung der SSL-Kommunikation. Die Berechtigung des Administrators wird durch die Eingabe von Benutzernamen und Passwort überprüft. Es wird dringend empfohlen, die vorkonfigurierte SSL-gesicherte Verbindung nicht manuell in eine ungesicherte HTTP- Verbindung zu verändern, weil sonst Benutzerkennung und Passwort als Klartext übertragen würden. Hinweis: Wenn der RAID Manager installiert ist, läuft auf dem verwalteten Rechner ein Service (SPYser.exe), der auf Port 5554 horcht. Dieser Service wurde nicht von Fujitsu entwickelt, sondern stammt vom Hersteller des Controllers und wird vom RAID Manager genutzt. Wenn absichtlich wahllos Daten an diesen Service geschickt werden, kann es passieren, dass dieser abstürzt. Dies ist jedoch kein ernstes Sicherheitsproblem. In diesem Fall muss der Service neu gestartet werden. Im normalen Betrieb passiert dies jedoch nicht Deployment Manager Die Hauptfunktion des Installation Managers ist die lokale oder entfernte Installation von PRIMERGY Servern. Der Deployment Manager bietet die Funktion für eine große Anzahl von Servern parallel an und ist deshalb ein wichtiges Werkzeug, um die Administrationskosten in Rechenzentren zu reduzieren. Es unterstützt sowohl paralleles Cloning zahlreicher Server als auch die entfernte Masseninstallation für eine große Gruppe von Server, die aus der ServerView Datenbank ausgewählt werden können. Insbesondere wenn Sie Blade Server einsetzen, müssen unter Umständen Hunderte von Server Blades ohne Konsole einfach und schnell installiert werden. Grundsätzlich gibt es dabei vier Phasen, in denen Sicherheitsaspekte zu betrachten sind: die Installation der Komponenten des Deployment Managers die Referenzinstallation das Erzeugen des Images das Clonen Da das RemoteView Management Blade bei den Operationen des Deployment Managers eine wichtige Rolle spielt, beachten Sie bitte auch die Empfehlung Installation der Deployment Komponenten Wie im Handbuch des Deployment Managers beschrieben, besteht die Installation aus zwei Teilen: Installation des Web-basierten Deployment Front-ends einschließlich der Deployment Engine, die auf dem gleichen Rechner wie der Operations Manager installiert sein muss, wo sie sich integriert. Der Rechner, auf dem diese Komponenten installiert sind, wird Zentrale Management-Station (CMS = Central Management Station) genannt. Installation der Deployment Services bestehend aus PXE Service, TFTP Service und RemoteDeploy Service auf dem Deployment Server Deployment Engine Die Deployment Engine verwendet einen Web Server, der auf dem gleichen Rechner wie der Operations Manager installiert ist. Nach erfolgreicher Installation ist die Schaltfläche RemoteDeploy (Deployment Manager) im Win32-based ServerView sichtbar oder im Operations Manager wird ein neuer Menüeintrag zur Verfügung gestellt. Beim Drücken dieser Schaltfläche bzw. bei der Selektion des Menüeintrags wird ein Web Browser auf der gleichen Maschine gestartet, d.h. im Standardfall ist die Kommunikation zwischen Web Browser und Web Server lokal. In diesem Fall können Sie die Sicherheit noch erhöhen, wenn Sie den Web Server, der vom Deployment Manager benützt wird, derart konfigurieren, dass er nur lokale HTTP-Anfragen akzeptiert. Wenn sich der Deployment Manager in den Operations Manager integriert und dieser so konfiguriert ist, dass er SSL benützt (Siehe auch Empfehlung 19) dann wird der Web-basierte Zugriff automatisch auch für den Deployment Manager über SSL abgesichert.

12 White Paper Ausgabe: Mai 2009 Sicheres PRIMERGY Server Management Seite 12 / 30 Unabhängig davon, wie auf die Deployment Engine zugegriffen wird, beginnt jede Deployment Session mit einer Login- Prozedur. Die Identifizierung und Berechtigungsprüfung stützt sich dabei auf die Benutzerkennung (Administrator Account), der während der Installation des Deployment Service festgelegt wurde, weil dieser Service jetzt von der Deployment Engine benützt wird. Unberechtigter Zugriff wird dadurch verhindert. Empfehlung 6 Authentifizierung und Autorisierung wird von der Deployment Engine durchgeführt mit der Benutzerkennung, die während der Installation des Deployment Service angegeben wurde. Wenn es erforderlich ist, können Sie die Sicherheit noch erhöhen, indem Sie den Web Server, der vom Deployment Manager verwendet wird, so konfigurieren, dass er nur lokale HTTP-Anfragen akzeptiert Hinweis: Wenn der Deployment Manager vom Win-32 basierten Front-end gestartet wird, dann wird die lokale Loop Back Address verwendet. In diesem Fall muss die Adresse zur Liste der Adressen hinzugefügt werden, die Zugriff auf den Web Server haben. Deployment Service Während der Installation geben Sie die Benutzerkennung an, der später für die Authentifizierung und Autorisierung benützt wird, wenn Sie eine Deployment Session starten Arbeiten mit dem Deployment Manager Hinzufügen eines neuen Servers Wenn ein neuer Server in Betrieb genommen wird, müssen die BMC-Einstellungen (BMC = Baseboard Management Controller) einschließlich der Benutzerkennung, die den Zugriff auf den BMC schützt, eingestellt werden. Für BMC Firmware v2.x sind die Voreinstellungen für diese Kennung: Benutzer oem mit Passwort oem oder Benutzer admin mit Passwort admin Es wird dringend empfohlen, diese voreingestellten Benutzerkennungen schnellst möglich zu ändern (Siehe auch Empfehlung 30) Der Administrator kann für einen neuen Server auch festlegen, wie ein Shutdown erfolgen soll. Falls dafür die Methode Shutdown durch den ServerView-Agenten gewählt wird, muss ein Benutzername und Passwort festgelegt werden. Diese Benutzerkennung wird verwendet um SNMP-Set-Operationen auf verwalteten Rechnern auszuführen. Sie muss deshalb identisch sein mit der Benutzerkennung, die festgelegt wurde während der Installation der ServerView-Agenten auf den verwalteten Rechnern Siehe auch Empfehlung Referenzinstallation mit dem Installation Manager Cloning verwendet Images. Der erste Schritt zum Erzeugen eines Images ist die Referenzinstallation, zum Beispiel auf einem Server Blade. Das Server Blade, das dafür verwendet wird, wird im Folgenden auch Deployment Blade genannt. Es gibt zwei Möglichkeiten, diese Referenzinstallation durchzuführen, entweder lokal oder entfernt (remote). Voraussetzung für eine lokale Installation ist, dass ein CD-ROM und Floppy-Laufwerk über USB an dem Deployment Blade angeschlossen sind. Zusätzlich müssen über die BX300- bzw. BX600-Rückseite Monitor, Tastatur und Maus angeschlossen und mittels des KVM-Switches zum Deployment Blade durchgeschaltet sein. Diese vorbereitende Hardware-Konfiguration erfordert zwar zusätzlichen Aufwand, aber die lokale Installation bietet auch zwei wesentliche Vorteile im Vergleich zur remote Installation: Die lokale Installation ermöglicht den Guided Mode von ServerStart. Dabei wird die Hardwarekonfiguration des Zielsystems automatisch erkannt und analysiert, und diese Information wird dann automatisch während des gesamten Installationsprozesses berücksichtigt. Der Guided Mode ist deshalb die sicherste Art, eine fehlerfreie Installation des Deployment Blades durchzuführen. Da der komplette Installationsprozess lokal abläuft, gibt es keinerlei Sicherheitsprobleme. Für die entfernte Installation (Siehe auch Kapitel 4.1) müssen Sie keine spezielle Hardware-Konfiguration vornehmen, aber Sie müssen einen Deployment Server einrichten, von dem Sie die entfernte Installation durchführen können. Dieser Deployment Server kann ein PC oder Notebook sein und muss nicht der Deployment Server sein, der für den Deployment Service verwendet wird. Die entfernte Installation besteht aus zwei Schritten: Sie starten zuerst mit dem Installation Manager im Preparation Mode, um das Config File auf dem Deployment Server zu erzeugen. Im zweiten Schritt richten Sie dann den PXE und FTP Service auf dem Deployment Server ein, damit das Deployment Blade von dort den Installation Manager booten kann. Der Installation Manager läuft dann im Unattended Mode mit dem im ersten Schritt erzeugten Config File. Die entfernte Installation hat jedoch auch zwei Nachteile: Im Preparation Mode kann die Hardware-Konfiguration nicht automatisch erkannt werden, weil der Installation Manager dabei nicht auf der Ziel-Hardware läuft. Die entfernte Installation benötigt einen DHCP und PXE Service. Wenn es nur einen DHCP und PXE Service im LAN- Segment des Deployment Blades gibt, dann kann diese Konfiguration als sicher betrachtet werden, weil das Deployment Blade eindeutig genau diese Services finden wird. Falls es außer dem PXE Service, den Sie auf dem Deployment Blade installiert haben, noch weitere PXE Services gibt, sollten Sie folgendes prüfen: - Sind diese PXE Services passiv, d.h. reagieren sie ausschließlich auf Anfragen von konfigurierten MAC-Adressen? - Sind die PXE-Services vertrauenswürdig, d.h. die eingetragen MAC-Adressen überschneiden sich nicht mit MAC-Adressen des PXE Service auf dem Deployment Server?

13 White Paper Ausgabe: Mai 2009 Sicheres PRIMERGY Server Management Seite 13 / 30 Falls diese Bedingungen nicht erfüllt sind, besteht die Gefahr, dass das Deployment Blade mit dem falschen PXE Service Kontakt aufnimmt, d.h. es wird nicht die beabsichtigte, sondern eventuell gefährliche Software auf dem Deployment Blade installiert. Empfehlung 7 Die sicherste Referenzinstallation ist die lokale Installation, die zusätzlich auch die Vorteile des Guided Mode bietet, d.h. automatisches Erkennen und Konfigurieren der Hardware-Konfiguration. Wenn Sie remote installieren, sollten Sie folgendes überprüfen: - Gibt es neben dem PXE Service auf dem Deployment Server noch andere PXE Services im LAN-Segment? - Falls ja, sind diese PXE Services passiv, d.h. reagieren sie ausschließlich auf Anfragen von konfigurierten MAC-Adressen, und sind sie vertrauenswürdig, d.h. die eingetragen MAC-Adressen überschneiden sich nicht mit MAC-Adressen des PXE Service auf dem Deployment Server? - Wichtig: Falls es zwei PXE Services im LAN-Segment gibt, dann darf keiner von ihnen auf dem gleichen Rechner wie der DHCP Service installiert sein. In diesem Fall wäre nämlich ausschließlich dieser PXE Service für das Deployment Blade sichtbar Erzeugen des Images Wenn Sie ein Image erzeugen, müssen Sie einen Deployment Server und das gewünschte Referenzsystem auswählen. Dieser Deployment Server muss auf das Image Repository zugreifen können, das sie als shared Folder anlegen können, auf den entfernter Zugriff möglich ist. (Anmerkung: Wenn der Deployment Service und die Deployment Engine auf dem gleichen Rechner installiert sind und genügend Plattenspeicherplatz zur Verfügung steht, ist es auch möglich ein lokales Verzeichnis als Repository zu verwenden, das nicht shared sein muss.) Das Image Repository muss auch für die RemoteDeploy Engine erreichbar sein. Das heißt, sowohl der User Account, der während der Installation der Deployment Services angegeben wurde, wie auch der User Account, der während der Installation der Deployment Engine angegeben wurde, müssen alle Rechte für dieses shared Verzeichnis besitzen. Shared Permissions und Security Permissions sollten gesetzt sein. Aus Sicherheitsgründen sollten natürlich keine anderen Accounts Zugriff auf dieses shared Verzeichnis besitzen. (Es wird angenommen, dass ein NTFS Dateisystem verwendet wird.) Empfehlung 8 Stellen Sie sicher, dass das shared Verzeichnis, das als Image Repository für den Deployment Manager verwendet wird, so konfiguriert ist, dass neben den beiden Accounts, die während der Installation des Deployment Services und während der Installation der RemoteDeploy Engine angegeben wurden, keine weiteren Accounts volle Zugriffsrechte für das Verzeichnis besitzen (Shared Permissions und Security Permissions) Wie im Handbuch des Deployment Managers beschrieben, können sie Dateisystem-abhängige und Dateisystem-unabhängige Images erzeugen. In beiden Fällen werden die Images aus Sicherheitsgründen verschlüsselt. Dies verhindert dass Images von unberechtigter Seite eingeschleust werden können Cloning Intern bedeutet das Cloning eines Server Blades, dass das Server Blade für einen PXE Boot vorbereitet ist. Dies geschieht folgendermaßen: Der Deployment Service schickt einen SNMP-Request an den SNMP-Agenten auf dem RemoteView Management Blade, an den SNMP-Agenten auf dem verwalteten Server oder er kommuniziert über RMCP mit dem irmc. Für non-blade Server werden alternativ IPMI-Kommandos oder Wake-on-LAN (zusammen mit der manuellen Änderung der Boot Device Order) verwendet. Das Zielsystem reagiert auf diesen Set-Request, indem es die BIOS-Parameter so setzt, dass der nächste Boot-Vorgang über das PXE-Protokoll abläuft. Dieses Umschalten auf PXE-Boot ist nur für einen Boot-Vorgang wirksam, d.h. nach dem PXE-Boot werden die BIOS-Parameter automatisch wieder mit den Standard-Werten besetzt. Sicherheit von SNMPv1 basiert auf Community Strings, die sowohl auf der Agenten-Seite wie auch auf der Manager-Seite bekannt sein müssen. Beachten Sie diesbezüglich die beiden bereits früher erwähnten Empfehlungen: Empfehlung 28 beschreibt das Einrichten der Community Strings auf dem RemoteView Management Blade. Empfehlung 14 beschreibt das Einrichten der Community Strings auf dem Win32-basierten ServerView und dem Operations Manager, die dann auch von dem dort sich integrierenden Deployment Manager benützt werden Entfernte Massen-Installation Der Deployment Manager ermöglicht auch entfernte Massen-Installationen, d.h. Sie können durch die Festlegung von entsprechenden Tasks bequem eine große Anzahl von Servern installieren. Dabei können die Server entweder alle mit der gleichen Konfigurationsdatei (Config File der Referenzinstallation) oder jeder Server mit einer individuellen Konfigurationsdatei installiert werden. Intern, wird eine solche Task in mehrere entfernte Installationsprozesse zerlegt, die vom Installation Manager wie im Kapitel 4.1 beschrieben durchgeführt werden. Das heißt, dass der Zugriff auf die Dateien des Installation Managers durch Benutzername und Passwort geschützt ist. Wenn Sie eine Task für eine entfernte Masseninstallation festlegen, müssen Sie diese Benutzerkennung verwenden. Dies schützt vor unberechtigten entfernten Masseninstallationen mit dem Deployment Manager. 5. SNMP-Agenten auf verwalteten Servern Dieses Kapitel beschreibt Sicherheitsaspekte mit SNMP-Agenten, die unter einem Ziel-Betriebssystem auf einem PRIMERGY Server, einem PRIMERGY Server Blade oder auf einem virtuellen Server (Host und Gast) laufen. SNMP-Agenten, die auf einem RemoteView Service Board (RSB)/Remote Management Controller (irmc) oder einem RemoteView Management Board eines Blade Servers laufen, werden im Kapitel 8 SNMP-Agenten für out-of-band Management betrachtet.

14 White Paper Ausgabe: Mai 2009 Sicheres PRIMERGY Server Management Seite 14 / 30 Für die Verwaltung eines Systems mit ServerView ist es erforderlich, den SNMP-Service und die ServerView-Agenten auf diesem System zu installieren. Der ServerView-Agent erhält die Managementdaten vom System und übermittelt sie über SNMP an die Komponente, die diese Information angefordert hat, zum Beispiel an den Operations Manager oder den Event Manager. Der SNMP-Service muss auf beiden Seiten installiert sein: Auf dem verwalteten Server und auf dem Manager (zum Beispiel dem Operations Manager oder den Event Manager). In diesem Kapitel betrachten wir nur den verwalteten Server SNMP-Service SNMP ist ein verbreitetes und viel genutztes Management-Protokoll. SNMP v1 ist nicht sicher und bietet auch keine Verschlüsselung. Trotzdem kann ein Grundmaß an Sicherheit erreicht werden, wenn der SNMP-Service richtig konfiguriert wird. Die Verwendung der Standardeinstellungen muss vermieden werden. Hinweis: Wenn Sie die Standardeinstellungen auf dem verwalteten Server ändern, vergessen Sie nicht, auch die Einstellungen auf der Manager-Seite zu ändern. Empfehlung 9 Ändern Sie die Standardeinstellungen des SNMP-Service. Genauere Informationen finden Sie unten. Die SNMP-Serviceparameter können von Betriebssystemimplementierung zu Betriebssystemimplementierung variieren. Einzelheiten zur betriebssystemabhängigen Installation und Konfiguration sind in den Handbüchern ServerView Installation unter Windows und ServerView Installation unter Linux beschrieben. Falls verfügbar, sollten die folgenden Parameter entsprechend den folgenden Regeln gesetzt werden. Community Strings für die Annahme von SNMP-Anfragen: Der Community String ist Bestandteil eines jeden SNMP-Requests, der vom Manager zum Agenten gesandt wird. Dies ist der einzige Authentifizierungsmechanismus von SNMP, der allerdings unverschlüsselt ist. Die mangelnde Verschlüsselung kann ein Problem darstellen, aber von den meisten SNMP-Geräten wird der Default Community String "public" verwendet. Aus diesem Grund sollte dies in Übereinstimmung mit den Regeln geändert werden, die auch für Passwörter gelten. Wenn Sie die Default Community-Einstellungen auf der Agenten-Seite ändern, müssen Sie auch die Default-Einstellungen des Community String auf der Manager-Seite ändern. Im Prinzip können Sie für jeden Server oder jede Gruppe von Servern individuelle Communities verwenden. Community Strings können Zugriffsberechtigungen zugewiesen werden, zum Beispiel nur Lesen (read-only), Lesen und Schreiben (read-write) usw. Wenn Sie die umfassende ServerView-Funktionalität nutzen wollen, müssen Sie "read-write" verwenden, Sie können aber auch die Funktionalität von Agenten auf reine Leseoperationen ("read-only") beschränken. Hinweis: Der Operations Manager wie auch das Win32-basiete ServerView unterstützt nur eine Community für SNMP- Anfragen. Aus diesem Grund sollten Sie hier keine zwei unterschiedlichen Communities, wie zum Beispiel "public" für reine Leseoperationen und "secret" für Lesen und Schreiben, konfigurieren. Annehmen von SNMP-Paketen von ausgewählten Servern/jedem Server: Hier sollten Sie explizit die IP-Adressen der Management-Applikation(en) definieren, und auch des Deployment Servers, falls Sie diesen verwenden. Dies verhindert, dass ein Agent SNMP-Anfragen von anderen Servern annimmt als dem Server/den Servern, auf dem/denen der/die Management Applikation(en) installiert ist/sind. Hinweis: In diesem Fall darf die IP-Adresse für die Management-Applikation(en) nicht über DHCP kommen. Trap Destination: Hier sollten Sie die IP-Adressen der Systeme explizit angeben, auf denen sich Management-Applikationen befinden, die Traps empfangen müssen. Hinweis: Die IP-Adresse für diese Management-Applikation(en) darf nicht über DHCP kommen. Community String für das Senden von Traps: Hier geben Sie den Community String an, der als Bestandteil eines SNMP-Traps an die Management-Applikation gesandt wird. Hinweis: Der SNMP-Service auf der Seite der Management-Applikation muss so konfiguriert sein, dass Traps mit diesem Community String angenommen werden. Aktivieren/Deaktivieren von Set Requests: Einige SNMP-Service-Implementierungen aktivieren bzw. deaktivieren die Möglichkeit des Agenten, SNMP Set Requests durchzuführen. Wenn Sie die umfassende ServerView-Funktionalität nutzen wollen, so müssen Sie diese auch hier aktivieren. In diesem Fall sollten das Kapitel 6.4 Set-Operationen mit Benutzerauthentifizierung berücksichtigen. Wenn Sie jedoch aus Sicherheitsaspekten generell keine SNMP Set Requests zulassen wollen, können Sie den SNMP Service entsprechend konfigurieren Konfiguration des SNMP Service mit dem MS System Policy Editor Windows erlaubt es, Einstellungen für mehrere Benutzer mithilfe des System Policy Editor durch das Erzeugen einer Datei Ntconfig.pol vorzunehmen. Diese Dateien können auch an andere Server verteilt werden. Wie sie diese Lösungsmöglichkeit für die Konfiguration des MS SNMP Service anwenden können, finden Sie im Kapitel Using the System Policy Editor unter Empfehlung 10 Für die bequeme Konfiguration des MS SNMP Service auf vielen Servern können Sie den MS System Policy Editor verwenden.

15 White Paper Ausgabe: Mai 2009 Sicheres PRIMERGY Server Management Seite 15 / Kommunikation zwischen Agenten auf MMBs und CPU Blades Falls der verwaltete Server ein Blade Server ist, haben Sie die folgende Situation: Auf dem Management Blade (MMB) läuft ein SNMP Agent und SNMP Agenten laufen auf den Server Blades. ServerView Manager kommunizieren mit beiden Typen von Agenten, aber der MMB Agent kommuniziert auch mit den Agenten auf den Server Blades. Grundsätzlich könnte man unterschiedliche SNMP Communities für den MMB Agenten und die Agenten auf den Server Blades konfigurieren. Wenn die Manager entsprechend konfiguriert sind, funktioniert die Kommunikation zwischen den Managern und den Agenten problemlos. Für die SNMP-Kommunikation zwischen dem MMB-Agenten und den Agenten auf den Server Blades ergibt sich jedoch ein Problem, weil sie mit verschiedenen Communities konfiguriert sind. Das führt dann zu einer eingeschränkten ServerView- Funktionalität. Empfehlung 11 Falls der verwaltete Server ein Blade Server ist und Sie wollen die uneingeschränkte ServerView-Funktionalität sicherstellen, dann müssen der Agent auf dem MMB und die Agenten auf den Server Blades mit der gleichen Community konfiguriert sein. Wenn verschiedene Server Blades verschiedenen Kunden zugeordnet sind, sind Sie im Allgemeinen gezwungen, unterschiedliche Communities für die Server Blades der unterschiedlichen Kunden zu verwenden, um zu verhindern, dass ein Kunde Informationen über die Blades eines anderen Kunden erhält. In diesem Fall müssen Sie allerdings auch verhindern, dass ein Kunde über das MMB Informationen über Blades anderer Kunden bekommt. Der Umstand, dass in diesem Fall der MMB Agent nicht mit den Agenten auf den Server Blades kommunizieren kann, erfüllt diese Forderung ServerView-Agenten Der einzige Authentifizierungsmechanismus von SNMP ist der Community String. Er wird als Klartext übertragen, weil SNMPv1 keine Verschlüsselung unterstützt. Daher können Set-Operationen von SNMP als riskant betrachtet werden. Aber ServerView bietet ein ServerView Sicherheitskonzept für SNMP Set-Operationen zusätzlich zur Konfigurationsmöglichkeit des SNMP Service. Dieses Konzept umfasst drei Optionen für SNMP Set-Operationen: Verhindern von spezifischen Set-Operationen Verhindern von allen Set-Operationen Schützen von Set-Operationen durch Benutzerauthentifizierung Die Konfiguration dieser Optionen sind beschrieben in den Handbüchern ServerView Installation unter Windows und ServerView Installation unter Linux. Das Verhindern von Set-Operationen mit diesen Optionen ist nur wirksam für ServerView-Agenten. Set-Operationen anderer SNMP-Agenten sind davon nicht betroffen. Die Option Schützen von Set-Operationen durch Benutzerauthentifizierung funktioniert folgendermaßen: Wenn ein ServerView-Agent installiert wird, muss eine Benutzergruppe (lokal oder Domain) angegeben werden. Bevor der ServerView Manager eine SNMP Set-Operation an den verwalteten Server schickt, bittet er den Administrator, eine Kennung (Name und Passwort) einzurichten. Der ServerView Manager fragt den Agenten über SNMP nach dieser Kennung, die bei der Installation des Agenten angegeben wurde. Diese Informationen werden während des SNMP-Transports schwach verschlüsselt. Der Server Manager versendet den SNMP Set Request nur dann, wenn der vom Agenten gelieferte Account dem Account entspricht, der vom Administrator angegeben wurde. Empfehlung 12 Geben Sie bei der Installation des Agenten eine Benutzergruppe an, die dann vom Operations Manager oder dem Win32-basierten ServerView für die Authentifizierung verwendet wird, bevor SNMP Set Requests an den Agenten versandt werden. Diese Benutzerkennung (Name und Passwort) wird ebenfalls vom Deployment Manager verwendet, wenn die Methode Shutdown durch ServerView-Agenten ausgewählt wird. Wenn diese Methode ausgewählt wird, muss die identische Benutzerkennung dafür festgelegt werden Absichern von SNMP Operationen mit IPsec Wie bereits erwähnt, bietet SNMPv1 keine Verschlüsselung. Dieser Mangel an Sicherheit kann umgangen werden, indem auf allen Knoten mit SNMP-Agenten oder Managern entsprechende IPsec Policies konfiguriert werden. Dies verhindert, dass potentielle Angreifer SNMP-Operationen abfangen oder manipulieren können. Jedoch verschlüsselt IPsec nicht automatisch den SNMP-Verkehr. Sie müssen dazu Filterspezifikationen in den entsprechenden Filterlisten zwischen SNMP-Managern und SNMP-Agenten konfigurieren (Siehe auch Tabelle Kommunikationspfade ). Eine detaillierte Beschreibung, wie Sie dies Filterlisten für Microsoft Betriebssysteme erzeugen und konfigurieren, finden Sie unter: Empfehlung 13 Falls es nötig ist, die Sicherheitsmängel von SNMP v1 zu umgehen, sichern Sie die SNMP-Operationen über IPsec ab. In einer Microsoft-Umgebung folgen Sie bitte dazu den Microsoft-Empfehlungen unter

16 White Paper Ausgabe: Mai 2009 Sicheres PRIMERGY Server Management Seite 16 / Administration 6.1. SNMP Service Analog zur Konfiguration des SNMP Service auf den verwalteten Rechnern sind ebenfalls zwei Konfigurationen auf dem Zentralen Management-Server (CMS) nötig: Bevor Sie den Operations Manager, den Event Manager oder das Win32-basierte ServerView auf dem Zentralen Management-Server (CMS) installieren, müssen Sie den SNMP Service so installieren und konfigurieren, dass SNMP- Traps von den Agenten empfangen werden können. Diese Konfiguration muss der Konfiguration der SNMP-Services auf den verwalteten Servern entsprechen. (Siehe Empfehlung 9: "Trap-Empfänger" und "Community String für das Senden von Traps".) Nach der Installation des Zentralen Management-Servers müssen Sie für jeden verwalteten Server oder jede Gruppe verwalteter Server folgende Konfiguration vornehmen: Community String, der verwendet werden muss, wenn der Zentralen Management-Server einen SNMP-Request an den Agenten des verwalteten Servers versendet. Konfigurieren Sie diesen Community String gemäß der Empfehlung 9, "Community Strings für die Annahme von SNMP-Requests" konfigurieren. Empfehlung 14 Falls Sie den Deployment Manager für das Installieren/Clonen von Server Blades einsetzen, müssen Sie im Operations Manager oder Win-32-basierten ServerView die RemoteView Management Blades dieser Blade Server als verwaltetete Server eintragen. Der Grund dafür ist, dass der Deployment Manager SNMP-Requests an diese Management Blades schicken muss. Der Deployment Manager ist in den Operations Manager oder das Win-32- basierte ServerView integriert und benützt deshalb die Konfiguration der SNMP Community Strings dieser Komponenten. Die ServerView-Agenten und der Zentrale Management-Server kommunizieren über SNMP. Da SNMP weder eine Verschlüsselung, noch eine sichere Authentifizierung bietet, wird dringend empfohlen, sowohl den Zentralen Management- Server, als auch die ServerView-Agenten hinter einer Firewall zu installieren. SNMP darf die Firewall nicht überqueren. Empfehlung 15 Installieren Sie sowohl den Zentralen Management-Server als auch die ServerView-Agenten auf den verwalteten Servern hinter einer Firewall, die die SNMP-Kommunikation schützt Installation der Web Server für den Operations Manager Der große Vorteil des Operations Manager ist die Möglichkeit, dass er hinter der Firewall im Intranet ablaufen kann, Sie aber trotzdem über jeden Web-Browser im Internet auf dieses Management-Tool zugreifen können - zu jeder Zeit und an jedem Ort. Unter Sicherheitsaspekten kann jede Installation eines Web Servers zu Sicherheitslücken in einer vorhandenen Konfiguration führen. Dieses Risiko kann minimiert werden, wenn Sie einige Regeln befolgen. Die Ausbaufähigkeit der Web Server ist ein Grund, warum die Installation eines Web Servers zu einer Sicherheitslücke führen kann. Der Operations Manager ist für den Ablauf auf Microsoft IIS oder auf dem Apache Web Server implementiert. Aus diesem Grund werden keine Microsoft-spezifischen Schnittstellen für die Erweiterung des Web Servers verwendet. Die Erweiterbarkeit basiert auf dem Standard CGI Interface. Aus diesem Grund können nur Sicherheitslücken relevant werden, die sich aus der Verwendung von CGI ableiten. Die Handbücher "ServerView Installation unter Windows und ServerView Installation unter Linux enthalten einige Abschnitte über die Installation der Web Server. Die Web Server sind keine Fujitsu Produkte. Aus Sicherheitsgründen müssen Sie deshalb auch die Hinweise der Anbieter der Web Server berücksichtigen. Empfehlung 16 Entfernen Sie alle CGI-Beispielprogramme. Verwenden Sie die Patches für bekannte Schwachstellen. Stellen Sie sicher, dass Ihr CGI bin-verzeichnis keine Compiler oder Interpreter enthält. Verwenden Sie für Ihren Web Server keine Administrator- oder Root-Berechtigungen, wenn diese nicht erforderlich sind. (Für ServerView sind diese Berechtigungen nicht erforderlich.) Microsoft hat auch ein Strategic Technology Protection Program gestartet, das im Wesentlichen aus den beiden Schritten "Get Secure" (Sicherheit herstellen) und "Stay Secure" (Sicherheit aufrechterhalten) besteht ( ). Außerdem gibt es spezielle Sicherheitschecklisten für den Internet Information Server ( ). Empfehlung 17 Befolgen Sie die Sicherheits-Checkliste von Microsoft IIS Baseline Security Checklist, die unter der folgenden Adresse heruntergeladen werden kann: SSL für den Operations Manager Wenn Sie von einem Web-Browser außerhalb des durch die Firewall geschützten Intranets auf den Operations Manager zugreifen wollen, sollten Sie die Verbindung vom Web-Browser zum Zentralen Management-Server durch Secure Socket Layer

17 White Paper Ausgabe: Mai 2009 Sicheres PRIMERGY Server Management Seite 17 / 30 (SSL) sichern. SSL wird mit IIS 4.0 und späteren Versionen bereitgestellt. Wie Sie IIS oder Apache mit SSL installieren, ist in den Handbüchern "ServerView Installation unter Windows und ServerView Installation unter Linux beschrieben. Das Leistungsmerkmal SSL der Web Server bietet eine sichere, verschlüsselte Verbindung zwischen dem Web-Browser und dem Web Server. Es besteht auch die Möglichkeit den Web Server so zu konfigurieren, dass auch eine Authentifizierung durch eine Benutzerkennung (Name und Passwort) durchgeführt wird. (Übrigens kann diese Authentifizierung auch ohne die Verwendung von SSL durchgeführt werden.) Sie können entscheiden, welche Informationen (Verzeichnis) durch diese Authentifizierung geschützt werden sollen. So müssen beispielsweise Management-Daten geschützt werden, Hilfetexte dagegen benötigen keinen Schutz. Empfehlung 18 Falls die Verbindung zwischen dem Web-Browser und dem Operations Manager das Internet nutzt, sollten Sie diese Verbindung durch SSL einschließlich der Authentifizierung durch Benutzerkennungen sichern. Die Konfiguration von Microsoft IIS bzw. Apache für SSL ist in den Handbüchern "ServerView Installation unter Windows und ServerView Installation unter Linux beschrieben. Für SSL-Verschlüsselung ist ein Zertifikat Voraussetzung. Die ServerView Suite wird mit einem solchen Zertifikat ausgeliefert, das jedoch nur für Testzwecke und nicht für den normalen Betrieb gedacht ist. Es wird deshalb dringend empfohlen, dieses Zertifikat durch ein gültiges Zertifikat von einer externen oder internen Zertifizierungsstelle zu ersetzen. Im Detail ist dies in den Handbüchern "ServerView Installation unter Windows und ServerView Installation unter Linux beschrieben. Empfehlung 19 Wenn Sie SSL-Verschlüsselung für den ServerView Web Server verwenden, wird dringend empfohlen, das Default- Zertifikat durch ein gültiges Zertifikat von einer externen oder internen Zertifizierungsstelle zu ersetzen. Web-basierte Kommunikation innerhalb des Operations Managers ist automatisch immer durch SSL gesichert Set-Operationen mit Benutzerauthentifizierung Falls Sie während der Installation der SNMP-Agenten auf den verwalteten Servern Benutzerkennungen festgelegt haben um die SNMP-Set-Operationen mit Benutzerauthentifizierung abzusichern (Empfehlung 12), dann müssen Sie diese Benutzerkennungen auch während der Konfiguration des Operations Managers oder des Win-32-basierten ServerView verwenden. Grundsätzlich kann dies für jeden verwalteten Server individuell geschehen, aber Sie können auch mehrere Server auswählen und diesen mit einer einzigen Konfigurationsoperation ( Setting properties for server ) die gleiche Benutzerkennung zuweisen. Hinweis: Diese Benutzerauthentifizierung funktioniert nur mit den Komponenten der ServerView Suite, jedoch nicht mit anderen SNMP-Werkzeugen Event Manager und Antiviren-Programme Der Event Manager kann so konfiguriert werden, dass er Administratoren durch s über bestimmte Ereignisse informiert. Wenn auf der zentralen Managementstation, wo der Event Manager installiert ist, ein Antiviren-Programm läuft, kann es sein, dass dieses verhindert, dass der Event Manager s verschickt. Damit der Event Manager trotzdem den Administrator durch s informieren kann, muss das Antiviren-Programm so konfiguriert werden, dass es den folgenden Prozessen das Versenden von s erlaubt: Windows: blat.exe Linux, Solaris: smtpm 7. Maintenance Das Update-Management der PRIMERGY ServerView Suite bietet dem Administrator eine bequeme Möglichkeit, unterschiedliche Komponenten der verwalteten Server auf den neuesten Stand zu bringen. Dafür steht folgendes mit der ServerView Suite zur Verfügung: Download Manager (integriert in Operations Manager) Im ersten Schritt sucht der Download Manager automatisch nach den neuesten verfügbaren Updates und stellt sie auf dem zentralen Management-Server (CMS) zur Verfügung. Update Manager (integriert in Operations Manager) Der Update Manager ermöglicht die zuverlässige, netzwerkweite Aktualisierung von BIOS, Firmware, Treibern, ServerViewund Update-Agenten über eine grafische Benutzeroberfläche oder ein Web-basiertes GUI. Sie können automatisch mehrere Server gleichzeitig aktualisieren. Dieser Vorgang wird vom Management-Server gesteuert. Der Update Manager verwendet neben den eigentlichen Update-Dateien auch Informationsdateien. Diese Dateien müssen sich entweder - auf dem zentralen Management-Server in dem Verzeichnis, das der Download Manager verwendet, befinden, oder - auf der ServerSupport CD2, oder - im Internet (FSC-Support-GlobalFlash) Boot-fähige Update CD Mithilfe der Boot-fähigen Update CD können Sie sowohl die Firmware von Server-Komponenten wie auch das Server-BIOS lokal auf dem verwalteten Server aktualisieren, bevor das Betriebssystem installiert wird (Offline BIOS/Firmware Update).

18 White Paper Ausgabe: Mai 2009 Sicheres PRIMERGY Server Management Seite 18 / 30 PrimeUp PrimeUp ermöglicht die bedienerlose Aktualisierung von Treibern und ServerView-Agenten auf verwalteten Servern. Zusätzlich gibt es auch die Möglichkeit, mit PrimeCollect Systeminformationen in einem Archive abzuspeichern, dass dann zu Analysezwecken an den Service geschickt werden kann Download Manager Der Download Manager besteht aus dem Download Service und einer grafischen Benutzeroberfläche (GUI), die aus dem Win32-basierten ServerView, aus dem Operations Manager heraus oder über das Windows Start Menü geöffnet werden kann. Für einen Server oder eine Gruppe von Servern legen Sie fest, wann und wie oft der Download Manager die Download Tasks starten soll. Beim Ausführen einer Download Task überträgt der Download Manager folgendes vom FSC Web Server zum zentralen Management Server: die für die Aktualisierung benötigten Informationsdateien, die Update-Dateien für den Update Manager und die aktuelle Version Manager Datenbank. Das Ziel für die Downloads ist ein Verzeichnis auf dem zentralen Management Server. Die Quelle ist der FSC Web Server. Alle Downloads gehen über das Internet und die Dateien sind nicht signiert. Falls Sie in Ihrer Umgebung sehr hohe Sicherheitsanforderungen haben, kann es sein, dass Ihnen dieser bequeme Weg des Downloads zu risikoreich erscheint. Empfehlung 20 Falls Sie die Übertragung der nicht signierten Dateien vom FSC Web Server zum zentralen Management Server über das Internet als zu gefährlich einstufen, können Sie stattdessen die PRIMERGY ServerView Suite Update CD verwenden. Eine aktuelle Version dieser CD ist zwei-monatlich verfügbar Update Manager Mit dem Update Manager können Sie Firmware, BIOS und Treiber, sowie ServerView- und Update-Agenten auf den verwalteten Servern vom zentralen Management Server aus aktualisieren. Die dafür nötigen aktuellen Dateien können sich in einem Verzeichnis auf dem zentralen Management Server befinden (wo sie z.b. der Download Manager hin übertragen hat), oder Sie können die PRIMERGY ServerView Suite Update CD verwenden. Wie im Handbuch beschrieben, besteht Update Management aus den folgenden Komponenten: Update Manager, installiert auf dem zentralen Management Server Update Agent, installiert auf jedem verwalteten Server Update PXE Server Agent, installiert auf einem PXE Server (falls nötig). Update TFTP Server Agent Das Aktualisieren von Firmware, BIOS, Treibern und Agenten ist eine Aktion, die geschützt werden muss. Unberechtigtes Aktualisieren von Firmware, BIOS, Treibern oder Agenten kann zu ernsthaften Problemen auf Ihren Servern führen. Deshalb bietet der Update Manager Verfahren zur Authentifizierung von Berechtigten, die im Handbuch Update Manager beschrieben sind. Der Update Manager verwendet dafür ein ähnliches Verfahren, wie es für die Absicherung von SNMP Set-Operationen verwendet wird: Der Administrator muss sich erfolgreich beim Agenten einloggen, bevor er Aktualisierungen starten kann. Es wird deshalb dringend empfohlen, bei der Installation der Update-Agenten diese Option auszuwählen. Empfehlung 21 Richten Sie auf den verwalteten Servern eine Benutzergruppe mit Benutzer(n) ein, bevor Sie die Update-Agenten installieren. Wählen Sie während der Installation der Update-Agenten im Bildschirm Security Settings die Option Account Check aus und verwenden Sie die eingerichtete Benutzergruppe als Flash User Group. Damit stellen Sie sicher, dass ein Benutzer des Update Managers nur dann die Berechtigung für Aktualisierungen besitzt, wenn er sich erfolgreich mit dem korrekten Benutzernamen und Passwort eingeloggt hat. Empfehlung 22 Empfehlung 23 Falls Sie aus Sicherheitsgründen die lokale Aktualisierung von Treibern und ServerView-Agenten bevorzugen, können Sie auch die lokale Kommandoschnittstelle des Update-Agenten verwenden. Falls Sie aus Sicherheitsgründen für das Flashen von Firmware und für die Aktualisierung des Server-BIOS lokale Werkzeuge bevorzugen, dann steht Ihnen anstelle des Download Managers und Update Managers dafür auch die Boot-fähige Update CD zur Verfügung. Für die Aktualisierung von Treibern und ServerView-Agenten können Sie auch PrimeUp auf der PRIMERGY ServerView ServerStart DVD verwenden Boot-fähige Update CD Bisher haben wir gesehen, dass die PRIMERGY ServerView Suite Update CD alle Daten und Dateien enthält, die der Update Manager für Aktualisierungsvorgänge benötigt. Diese CD hat jedoch auch noch eine andere Funktion: Die Funktion Boot-fähige Update CD ist eine eigenständige Management-Komponente der PRIMERGY ServerView Suite. Mit ihr ist es möglich, die Firmware verschiedener Serverkomponenten und das Server-BIOS lokal auf den verwalteten Servern zu aktualisieren bevor das Betriebssystem installiert wird. Natürlich kann es auch für bereits installierte Server verwendet werden. Einzelheiten finden Sie im Handbuch Bootable Update CD.

19 White Paper Ausgabe: Mai 2009 Sicheres PRIMERGY Server Management Seite 19 / PrimeUp PrimeUp ermöglicht die lokale bedienerlose Aktualisierung von Treibern und ServerView-Agenten auf verwalteten Servern. Die dafür nötigen Daten sind verfügbar in speziellen PRIMERGY Support Packages auf dem Fujitsu Web Server oder auf der PRIMERGY ServerView ServerStart DVD, die Sie im Abonnement erhalten können. Die Installationsvorgänge mit PrimeUp steuern Sie über Kommandos (Command Line Interface) durch entsprechende Parameter und Optionen. Durch die Verwendung von Scripts können Sie auch effizient mehrere Systeme aktualisieren PrimeCollect Mit PrimeCollect (nur für Windows) können Sie Informationen sammeln über das System, das Betriebssystem, Sensorwerte (z.b. Temperaturwerte) und verschiedene Log-Einträge (z.b. System Event Log). Sämtliche Informationen werden in einem zip- Archive gesammelt, das Sie dann an den Service schicken können. Damit kann dann der Service sofort eine Problemanalyse durchführen, wodurch dann eine Lösung wesentlich schneller zur Verfügung steht. Aus Sicherheitsgründen möchten Sie eventuell genau wissen, welche Information im zip-archive an den Service geschickt wird. Im Handbuch PrimeCollect finden Sie eine Tabelle, die alle Dateien und deren Inhalt beschreibt. Wenn es Ihre Sicherheitsstrategie erfordert, können Sie vor der Übertragung an den Service einzelne Dateien aus dem Archive löschen, oder Sie können sich dafür entscheiden, das Archiv überhaupt nicht zu versenden. Empfehlung 24 Bevor Sie das mit PrimeCollect erzeugte Archiv versenden, können Sie den Inhalt überprüfen und falls es Ihre Sicherheitsstrategie erfordert einzelne Dateien vor dem Versenden löschen. Im Handbuch PrimeCollect finden Sie eine Tabelle, die alle Dateien und deren Inhalt beschreibt. 8. SNMP-Agenten für out-of-band Management Kapitel 5 SNMP-Agenten auf verwalteten Servern hat das Thema Sicherheit für SNMP-Agenten auf verwalteten Servern mit installiertem Betriebssystem behandelt, d.h. im Zusammenhang mit in-band Management. In-band Management bedeutet, dass die Hardware des verwalteten Servers und auch das darauf installierte Ziel-Betriebssystem Voraussetzung sind, um auf die Managementinformation zuzugreifen. Außerdem muss noch eine entsprechende Software, zum Beispiel ein SNMP-Agent auf dem Ziel-Betriebssystem installiert sein. Out-of-band Management setzt kein laufendes Ziel-Betriebssystem voraus, um auf die Managementinformation des verwalteten Servers zuzugreifen. Zwei Fälle sind zu unterscheiden: Auf dem verwalteten Server läuft ein spezielles Diagnose-Betriebssystem Eine vollständig unabhängige Hardware-Komponente wird benützt, um auf die Managementinformation des verwalteten Rechners zuzugreifen. Beispiele für solche Hardware sind: irmc oder ein RemoteView Management Board eines Blade Servers. Dieses Kapitel behandelt Sicherheitsthemen mit SNMP-Agenten, die auf solcher spezieller Management-Hardware laufen. Das SNMP-Protokoll muss auf beiden Seiten verfügbar sein, auf der speziellen Management-Hardware und auf dem Remote Management Front-End. Dieses Kapitel betrachtet nur die spezielle Management-Hardware auf RSB / RSB S2 / RSB S2 LP / irmc Das Remote Management Service Board (RSB) ist ein PCI Board mit eigenem Betriebssystem und eigener Stromversorgung und läuft damit vollständig unabhängig vom eigentlichen verwalteten Server. Ein RSB hat auch seinen eigenen Web Server, eigene SNMP-Agenten, eigene Benutzerverwaltung und einen eigenen Event Manager für das Weiterleiten von Alarmen. Der Remote Management Controller (irmc) ist eine entsprechende on-board Lösung. Auch hier können Sie SNMP Communities mit entsprechenden Rechten konfigurieren und auch Trap Destinations. SNMP Communities, die auf dem RSB/iRMC konfiguriert sind, müssen auch in der Server-Liste des Win32-basierten ServerView/Operations Manager konfiguriert sein, weil sonst der SNMP-Agent des RSB/iRMC die SNMP-Nachrichten dieser Front-Ends nicht akzeptiert. Sie sollten die SNMP-Agenten des RSB/iRMC nach denselben Regeln konfigurieren, die Sie beim Konfigurieren der auf dem Zielbetriebssystem laufenden SNMP-Agenten verwenden. Diese wurde im Kapitel 5 SNMP-Agenten auf verwalteten Servern beschrieben. SNMP Set-Operationen sollten wenn überhaupt nur hinter einer Firewall oder mit einem dedizierten Management-Netz erlaubt werden, außer wenn sie durch die Verwendung des Deployment Managers erforderlich sind. Aktives Management, das über SNMP angestoßen wird, kann ebenso über eine SSL-gesicherte Web-basierte Benutzeroberfläche oder über SSLgesichertes Telnet durchgeführt werden. Umfangreiche Sicherheitsfunktionen des RSB stellen dann sicher, dass diese Operationen ausschließlich von berechtigten Benutzern durchgeführt werden können. Die Authentifizierung erfolgt über Benutzernamen und Passwort (gesicherter Transfer), wobei die Benutzernamen mit unterschiedlichen Rechten versehen werden können. Mit dem SSL-Protokoll (Secure Sockets Layer) wird sowohl der Datentransfer über die Web-basierte Benutzeroberfläche als auch über die Konsole verschlüsselt. Die Kommunikation übers Modem kann dadurch gesichert werden, dass die Verbindung vom verwalteten Server in Richtung Administrator aufgebaut wird (Call back). Zusätzlich werden Aktivitäten in Log-Dateien aufgezeichnet.

20 White Paper Ausgabe: Mai 2009 Sicheres PRIMERGY Server Management Seite 20 / 30 Empfehlung 25 Aus Sicherheitsgründen sollten die SNMP Communities auf dem RSB/iRMC nur mit Leseberechtigung konfiguriert werden. Aktives Management über SNMP sollte vermieden werden, weil eine SSL-gesicherte Alternative für die Web- Oberfläche oder Telnet zur Verfügung steht. Das RSB/iRMC verfügt über ein eigenes Event-Management. Während SNMP-Agenten nur mittels SNMP Traps über Ereignisse informieren können, kann der Event Manager auf dem RSB/iRMC so konfiguriert werden, dass er den Administrator über Pager, Mail, SMS oder SNMP Trap benachrichtigt. SNMP Traps können verloren gelten und gelten deshalb als unzuverlässig. Die anderen Alternativen hingegen gelten als hinreichend zuverlässig. Empfehlung 26 Um dem Verlust von Ereignis-Benachrichtigungen vorzubeugen, wird empfohlen, den Event Manager auf dem RSB/iRMC bzw. auf dem Management Blade so zu konfigurieren, dass die Benachrichtigung nicht ausschließlich über SNMP Traps erfolgt auf dem RSB als Konzentrator Wenn ein RSB als Konzentrator eingesetzt wird, dann unterstützt es nicht nur entferntes Management für den PRIMERGY Server, in dem es eingebaut ist, sondern zusätzlich für bis zu 9 weitere PRIMERGY Server. In diesem Fall läuft ein SNMP- Agent mit einer ServerView-spezifischen MIB auf dem RSB. Dieser SNMP-Agent kommuniziert mit den BMCs jener Server, für die er als Konzentrator agiert. Bezüglich Sicherheit müssen in diesem Fall die folgenden zwei Kommunikationspfade betrachtet werden: SNMP-Kommunikation mit dem Agenten auf dem RSB Kommunkation zwischen dem RSB und den BMCs auf den anderen Servern Bezüglich der SNMP-Kommunikation sollten auch hier die Empfehlung 25 und die Empfehlung 26 des vorhergehenden Kapitels angewendet werden. Bezüglich der Kommunikation zwischen dem RSB und den BMCs ist festzustellen, dass die entsprechenden Parameter festgelegt werden, wenn der verwaltete Server einem RSB als Konzentrator zugeordnet wird. Dabei kann neben der IP-Adresse und dem Namen des Servers auch die Authentifizierungsmethode für die IPMI-basierte Kommunikation zwischen dem RSB und dem BMC festgelegt werden. Dafür stehen die folgenden Alternativen zur Verfügung: Keine Authentifizierung MD5, d.h. Benutzername und Passwort werden vor dem Zugriff auf den BMC abgefragt; das Passwort wird verschlüsselt übertragen. straight password, d.h. Benutzername und Passwort werden vor dem Zugriff auf den BMC abgefragt; das Passwort wird nicht verschlüsselt. Aus Sicherheitsgründen sollte immer die Alternative MD5 gewählt werden. Bitte achten Sie darauf, dass auch die BMCs auf den verwalteten Servern entsprechend konfiguriert sind, d.h. sie sollten nur Anfragen akzeptieren, deren Herkunft durch Benutzernamen und verschlüsseltes Passwort sichergestellt werden kann. Empfehlung 27 Wenn Sie ein RSB als Konzentrator verwenden, sollte die Kommunikation zwischen dem RSB und dem zugeordneten verwalteten Server so konfiguriert sein, dass MD5 für die Authentifizierung verwendet wird auf dem Remote Management Blade Das Management Blade wird auch vom Deployment Manager verwendet. Bei der Auslieferung ist das Management Blade nicht mit einer Default Community vorkonfiguriert. Wenn Sie den Deployment Manager einsetzen, müssen Sie deshalb eine entsprechende SNMP Community konfigurieren. Ältere Management Blades verwenden diesen Community String für Get und Set Operationen. Neuere Management Blades erlauben es, Community Strings mit unterschiedlichen Rechten zu versehen. Das Management Blade unterstützt auch das Filtern von SNMP-Adressen, d.h. Sie können IP-Adressen festlegen von denen SNMP-Anfragen akzeptiert werden. Anfragen, die von anderen Adressen kommen, werden abgelehnt. Es wird dringend empfohlen, solche Filter anhand der Tabellen im Kapitel 3.1 Kommunikationspfade anzulegen. Empfehlung 28 Wenn Sie den Deployment Manager einsetzen, dann müssen Sie für den SNMP Service auf dem RemoteView Management Board einen Community String konfigurieren. Es wird auch dringend empfohlen, SNMP Address Filter anhand der Tabellen im Kapitel 3.1 Kommunikationspfade anzulegen. 9. Out-of-band Management Wie bereits erwähnt, verwenden einige Komponenten der ServerView Suite, wie der Operations Manager oder der Deployment Manager, out-of-band SNMP Agenten für Managementzwecke. Die wichtigsten Komponenten innerhalb der ServerView Suite zur Unterstützung von out-of-band Management finden Sie im SV Remote Management, das die folgenden Komponenten umfasst: Remote Management Software Front-ends Remote Management Test und Diagnose Software (RTDS) Remote Management Service Board (RSB/RSB S2) oder integrated Remote Management Controller (irmc) Remote Management Blade