Mehr Sicherheit für Netzwerkverbindungen
von Heinz-Wilhelm Fabry, ORACLE Deutschland B.V. & Co. KG
Der Zugriff auf Datenbanken über das Netzwerk stellt aus Security Sicht einen ausgesprochen kritischen Vorgang
dar, der unbedingt vor Missbrauch geschützt werden muss. Deshalb ist es auch nicht weiter verwunderlich, dass
im Security Ecosystem etliche Produkte angeboten werden, die diesen Zugriff sichern helfen: Das beginnt bei
Firewalls mit SQL Net Proxy, geht über Produkte wie die
Oracle Database Firewall, die
einen Schutz vor SQL Injection Angriffen über das Netzwerk leisten, und endet etwa bei den Angeboten zur
Netzwerkverschlüsselung, wie sie im Oracle Datenbankumfeld vor allem
die Advanced Security Option anbietet.
Aber vor jedem Einsatz schwieriger oder kostspieliger Mittel zur Steigerung der Sicherheit einer Datenbank steht der Einsatz solcher Mittel, die ohne zusätzliche Kosten oder relativ einfach zu implementieren sind. Dazu gehören das bereits in einem Community Artikel andiskutierte Härten der Datenbank oder das in einem weiteren Artikel angesprochene Umsetzen des Prinzips des least privilege. Im vorliegenden Artikel soll darauf eingegangen werden, wie die Verbindungsaufnahme zur Datenbank über einen Listener Prozess sowie die Netzwerkverbindung zwischen Client und Datenbank über SQL Net eigene Mittel so konfiguriert werden können, dass dies die Sicherheit einer Datenbank ohne Zusatzkosten erhöht. Listener
Der Listener ist die erste Anlaufstelle für jeden Versuch, über ein Netzwerk den Kontakt mit einer Oracle Datenbank
aufzunehmen, sprich sich einzuloggen. Schaltet ein Angreifer den Listener aus, kann sich niemand mehr über das
Netzwerk bei der Datenbank anmelden. Ein solches Ausschalten wäre also ein erfolgreicher Denial of Service
(DoS) Angriff. Einige einfache Konfigurationseinstellungen, die in der Datei listener.ora abgelegt sind,
reduzieren dieses Risiko deutlich.
Vorhandene Einstellungen der Standard listener.ora Datei modifizieren
Betrachtet man die Datei listener.ora, wie sie bei einer Default Installation einer Datenbank auf
Oracle Enterprise Linux (OEL) durch die Installationsroutine im Verzeichnis $ORACLE_HOME/network/admin
angelegt wird, sieht man etwa Folgendes:
# listener.ora Network Configuration File: /oracle/product/11.2.0/dbhome_1/network/admin/listener.ora # Generated by Oracle configuration tools. LISTENER = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = hwf.de.oracle.com)(PORT = 1521)) ) ) ADR_BASE_LISTENER = /oracleWeil die Eigenschaften des Listener verändert werden sollen, sollte ein laufender Listener zunächst gestoppt werden. Der über diese Datei konfigurierte Listener heisst LISTENER. Damit kann ein Angreifer, der Zugriff auf die Prozessliste des Systems hat, diesen für die Datenbank wichtigen Prozess auf den ersten Blick identifizieren und eventuell zum Ziel seiner Angriffe machen. Stattdessen sollte man den Listener anders nennen, indem man die entsprechende Zeile modifiziert. Hier soll der Listener sam heissen. Als nächstes sind die Services beschrieben, die dieser Listener bereitstellt. Da ist zunächst festgelegt, dass der Listener auch den Aufruf von externen Prozeduren ermöglicht. Weitere Services, zum Beispiel das Aufrufen von XML Datenbank Routinen könnten an dieser Stelle ebenfalls beschrieben werden. Allerdings sollte man nur solche Services erlauben, die auch tatsächlich verwendet werden. Damit reduziert man die Angriffsfläche, die sich einem böswilligen Angreifer bietet. Da in der Beispieldatenbank für diesen Beitrag keine externen Prozeduren benötigt werden, kann die gesamte Zeile gelöscht werden. In der nächsten Zeile der Adressliste erfolgt die Beschreibung des Datenbank Service. Über den angegebenen Port 1521 kann eine Verbindung zu diesem Service aufgenommen werden. Es handelt sich um den Standard Port, der allegemein bekannt ist. Obwohl ein Port Scanner sehr schnell auch einen anderen Port identifizieren könnte, sollte der Standardport dennoch geändert werden: Nicht jede Angriffsroutine bindet einen Port Scan ein. Bei der Vergabe der Portnummer ist zu beachten, dass Nummern, die kleiner sind als 1024, auf vielen Systemen von besonders privilegierten Prozessen genutzt werden, und dass der Wertebereich nach oben begrenzt ist mit der Portnummer 65535. Für diesen Beitrag wird der Port auf 1999 gesetzt. Damit das Logging des neuen Listeners an den Standard Speicherort erfolgt, wird der Parameter ADR_BASE_LISTENER auf ADR_BASE_sam geändert. Der veränderte Teil der listener.ora Datei sieht nun folgendermassen aus: ... sam = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = hwf.de.oracle.com)(PORT = 1999)) ...Um mit den Veränderungen arbeiten zu können, sind zwei weitere Anpassungen nötig. Sie betreffen das Arbeiten mit dem Hilfsprogramm lsnrctl und die Verbindung zwischen Listener und Datenbank. Die Befehle von lsnrctl setzen voraus, dass der Listener den Standardnamen LISTENER trägt. Um einen Listener mit einem anderen Namen - hier sam - zu steuern, müssen deshalb alle lsnrctl Befehle um diesen Namen ergänzt werden. Fehlt der neue Name, würde zum Beispiel beim Starten des Listeners ein Listener mit dem Standardnamen LISTENER und den Standardeinstellungen gestartet. Für diesen Beitrag wird der Listener also ab jetzt gestartet mit lsnrctl start sam ![]() Die Systemmeldung dazu beginnt etwa wie links abgebildet. Die Verbindung zwischen Listener und Datenbank erfolgt automatisch, sofern der Listener den Standardport 1521 verwendet. Soll, wie hier, ein anderer Port verwendet werden, muss das mit folgendem Befehl deklariert werden. ALTER SYSTEM SET local_listener = '(address=(protocol=tcp)(host=hwf.de.oracle.com)(port=1999))' SCOPE=both ![]() Wer lieber mit einer graphischen Oberfläche arbeitet, kann die Namens- und Portänderungen auch mit dem Hilfsprogramm ORACLE NET MANAGER durchführen. Es wird auf LINUX Betriebssystemen über die Eingabe von netmgr auf der Kommandozeile aufgerufen. Ein Vorteil der graphischen Oberfläche liegt vielleicht darin, dass auch eine eventuell vorhandene Datei tnsnames.ora gleich mitbearbeitet wird. Die Abbildung links zeigt den Bildschirm für die Portänderung. Die Verwendung der graphischen Oberfläche entbindet übrigens nicht davon, den gerade vorgestellten Befehl ALTER SYSTEM SET local_listener auszuführen. listener.ora Datei ergänzen
Nachdem die vorhandenen Einträge bearbeitet sind, sollen nun weitere Parameter eingefügt werden.
Das Setzen des Parameters ADMIN_RESTRICTIONS_listener_name auf ON bewirkt, dass SET Befehle zur
Konfiguration des Listeners nicht mehr funktionieren. Eine Änderung von Parametern ist dann nur noch
über das Editieren der Datei listener.ora möglich - und einem Neuladen der
veränderten Einstellungen. Damit werden die Sicherheitsmechanismen des Betriebssystems in die Administration
des Listeners eingebunden, denn man muss ja nun auf der Betriebssystemebene über die Berechtigung verfügen, die
Konfigurationsdatei zu bearbeiten.
Das Betriebssystem wird auch für den nächsten Parameter, LOCAL_OS_AUTHENTICATION_listener_name, genutzt, um die Sicherheit des Listeners zu erhöhen. Der Parameter sollte auf dem Default Wert ON stehen. Damit wird erreicht, dass der Listener nicht mehr über das Netzwerk zu starten und zu stoppen ist, sondern nur dann, wenn man direkt auf dem Server eingeloggt ist, auf dem der Listener läuft. Ausserdem ist der Listener nur noch von der Person zu stoppen, die ihn auch gestartet hat. An dieser Stelle darf ein Hinweis auf den Parameter PASSWORDS_listener_name nicht fehlen. Es wird inzwischen davon abgeraten, den Listener über ein Passwort abzusichern. Der Parameter ist inzwischen von Oracle sogar auf den Status deprecated gesetzt, das heisst seine Verwendung führt maximal zu einer Fehlermeldung, die das Funktionieren aber nicht behindert. Mit dem nächsten Hauptrelease der Datenbank ist die Verwendung des Parameters dann aber überhaupt nicht mehr möglich (vgl. MOS Note 1328725.1). Die Erklärung für diese Vorgehensweise ist recht einfach: Der Listener verfügt über keinen Schutz vor Eingabe falscher Passwörter. Damit ist er quasi hilflos gegen sogenannte dictionary attacks - also gegen die Eingabe immer neuer Passwörter, bis vielleicht irgendwann das richtige Passwort gefunden ist und dann der Listener durch den Angreifer manipulierbar wird. Der Parameter INBOUND_CONNECT_TIMEOUT_listener_name bietet einen Schutz gegen einen DoS Angriff. Hier kann in Sekunden angegeben werden, wie lange der Listener maximal versucht, für einen Client eine Verbindung zur Datenbank aufzubauen. Damit wird verhindert, dass durch eine Flut von Verbindungsversuchen mit falschen Benutzernamen und / oder Passwörtern der Listener derartig überlastet wird, dass er entweder nur noch erfolglos versucht, Verbindungen aufzubauen, oder sogar 'zusammenbricht'. Welchen Wert man hier angibt, hängt ab von den Zeiten, die üblicherweise für den Aufbau einer Verbindung benötigt werden: Benötigt der Verbindungsaufbau im Normalfall etwa 1 Sekunde - das ist schon relativ lang - wäre vielleicht ein Wert von 5 Sekunden hier angebracht. ![]() Auch das Begrenzen der Anzahl Verbindungen, die maximal pro Sekunde aufgebaut werden sollen, unterstützt bei der Abwehr von DoS Angriffen. Diese Begrenzung wird über zwei Einstellungen in der Datei listener.ora erreicht: Einerseits über den Parameter CONNECTION_RATE_listener_name und dann über die Angabe RATE_LIMIT in der Addressliste. Die Abbildung links zeigt, welche Auswirkung diese Einstellung hat: Auf der linken Seite werden die Auswirkungen beschrieben, wenn keine Verbindungsrate (CONNECTION_RATE) eingestellt ist und eine große Anzahl von Sessions (roter Graph) nahezu gleichzeitig versucht, eine Verbindung mit der Datenbank herzustellen. Im dazugehörigen unteren Bereich der Graphik (blauer Graph) wird im unteren Bereich deutlich, dass die CPU Belastung mit steigender Anzahl der Sessions das System fast zum Stillstand bringt. Dagegen führt die Begrenzung auf 3 Verbindungen pro Sekunde, die Grundlage der Messung der rechten Graphik ist, zwar zu einer steigenden Belastung, aber nicht bis in einen kritischen Bereich. Unsere Beispiels listener.ora Datei sieht inzwischen folgendermassen aus: ... sam = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = hwf.de.oracle.com)(PORT = 1999) (RATE_LIMIT=yes)) ) ) CONNECTION_RATE_sam = 5 LOCAL_OS_AUTHENTICATION_sam = ON ADMIN_RESTRICTIONS_sam = ON ... Listener Logging
Man sollte das Logging des Listeners mit Hilfe des Parameters LOGGING_listener_name aktivieren und
regelmäßig die Einträge dort kontrollieren. Angriffe deuten sich zum Beispiel in Meldungen an wie
Die Listener Logs werden im ab Oracle Database 11g im ADR Verzeichnis abgelegt. Dessen Basisverzeichnis ist mit dem Parameter ADR_BASE_listener_name angegeben. Man kann allerdings auch selbst festlegen, in welches Verzeichnis und mit welchem Dateinamen die Log Dateien geschrieben werden. Die Einträge für diesen Beitrag könnten dann etwa so aussehen: LOGGING_sam = ON LOG_DIRECTORY_sam = /logs/listener LOG_FILE_sam = lsnr_sam.log SQL Net Einstellungen
Über die Datei sqlnet.ora gibt es weitere Möglichkeiten, sich gegen Angriffe über das Netzwerk
zu schützen. Zum einen
gibt es hier den Parameter SQLNET.INBOUND_CONNECT_TIMEOUT - ebenfalls auf Sekunden einzustellen - der
dem selben Ziel dient wie der vergleichbare Parameter der Listener-Konfiguration und gemeinsam mit ihm
verwendet werden sollte. Der Parameter sollte auf einen etwas größeren Wert gestellt werden, als der der
Listener Konfiguration.
Man sollte auch die Möglichkeit nutzen, den Zugriff auf die Datenbank nur über bestimmte IP Adressen zuzulassen. Wird beispielsweise immer nur von einer Reihe Administrationsrechnern und von einem Application Server aus zugegriffen, sollte man deren IP Adressen angeben. Damit wäre ein Zugriff dann ausschließlich von diesen Rechnern aus möglich. Erreicht wird das mit dem Parameter TCP.VALIDNODE_CHECKING, der auf YES gesetzt sein muss, sowie mindestens einem der beiden Parameter TCP.EXCLUDED_NODES und TCP.INVITED_NODES. Seit Oracle Database 11g Release 2 sind hier sowohl Wildcards als auch die CIDR Notation erlaubt. Unsere Datei sqlnet.ora könnte also um folgende Einträge ergänzt werden: SQLNET.INBOUND_CONNECT_TIMEOUT = 8 TCP.VALIDNODE_CHECKING = YES TCP.INVITED_NODES = anwendung.de.firma.com, 192.168.111.* Weitere Informationen
Weitere Informationen zur Konfiguration der Oracle SQL Net Services findet man im
Net Services Administrator's Guide
sowie der dazugehörigen
Referenz. Neben der o.g. Support
Note gibt es ausserdem eine ganze Reihe von hilfreichen Dokumenten zur Konfiguration des Oracle Netzwerks
auf MOS, z.B. 364388.1 "How To Network Secure Your Oracle Database Listener in Intranet / Internet" mit einer
Reihe weiterführender Hinweise.
|