Unsicherheitsfaktor Netzwerk - Verschlüsseln ist Pflicht

von Ralf Durben, ORACLE Deutschland GmbH

IT-Systeme werden in der heutigen Zeit eigentlich immer in einem Netzwerk betrieben. Datenbankanwendungen greifen in aller Regel über dieses Netzwerk auf die Datenbank zu. Für potentielle Angreifer ist dieser Netzwerkverkehr ein interessanter Angriffspunkt. Neben einer Absicherung der Datenbank selbst muß also unbedingt auf die Absicherung des Netzwerkverkehrs geachtet werden. Es gibt wunderbar einfache und schöne Tools, mit denen man das Netzwerk abhören kann. So stellt sich die Frage, wie es um die Sicherheit der Daten steht, die über das Netzwerk übertragen werden.

Man muß auf diesem Gebiet die folgende Unterscheidung machen:

Übertragung von Daten zum Aufbau einer Benutzersitzung (Authentifizierung). Hierbei interessiert vor allem die Frage, inwieweit die übertragene Information von Benutzernamen und Paßwort für andere sichtbar ist.
Übertragung von Daten einer bestehenden Benutzersitzung (Datenabfrage, Dateneingabe, usw.)

Netzwerkübertragung von Authentifizierungsinformationen

Die Übertragung von Authentifizierungsinformationen wird seit SQL*Net2.1, also seit der Datenbankversion 7.1, grundsätzlich verschlüsselt durchgeführt, wobei der verwendete Schlüssel immer wieder neu erstellt wird.

Wer keine ältere Software als 7.1 mehr verwendet kann diesen Abschnitt überlesen und bei "Netzwerkübertragungen von Daten aus einer bestehenden Sitzung" fortsetzen.

Alle Datenbank- und Clientversionen vor 7.1 kennen die automatische Verschlüsselung des logins nicht. Wenn diese zum Einsatz kommen, findet die übertragung unverschlüsselt statt. Aus diesem Grund sollte man darauf achten, dass

kein Oracle 7.0 (oder älter) Datenbankserver im Netzwerk betrieben wird.
möglichst kein Oracle Client betrieben wird, der sich mit einer Oracle 7.0 Datenbank oder älter verbinden kann. Für diese Clients gibt es aber auch einen Parameter (db_encrypt_login), der eine unverschlüsselte übertragung der Authentifizierungsdaten verhindert.

Wenn die Datenbankversion größer oder gleich 7.1 ist bzw. wenn der Client sich nicht gegen eine Oracle 7.0 Datenbank anmelden kann, ist die übertragung der Authentifizierungsinformationen über das Netzwerk gesichert und damit unproblematisch. Dieses ist für alle derzeit supporteten Oracle Clients der Fall.

Netzwerkübertragungen von Daten aus einer bestehenden Sitzung

Man ist geneigt diesen Abschnitt mit einer überschrift wie zum Beispiel "Netzwerkübertragungen von Nutzdaten" zu versehen. Das wäre aber eine viel zu einschränkende Sicht auf das nun folgende Thema. Nachdem der Benutzer eine Benutzersitzung aufgebaut hat, findet bei den folgenden übertragungen keine Verschlüsselung mehr statt, es sei denn, man hat die Datenbankoption "Oracle Advanced Security" lizenziert, installiert und korrekt konfiguriert, oder man verschlüsselt das gesamte Netzwerk. Man hat hier die Wahl, aber eine Verschlüsselung sollte auf jeden Fall genutzt werden.

Um dieses zu verdeutlichen sei das folgende Beispiel aufgeführt. Der Benutzer SCOTT baut eine Benutzersitzung auf und fragt die Tabelle EMP ab. Sowohl die Abfrage als auch das Ergebnis sind über das Netzwerk klar sichtbar. Um dieses nachzuvollziehen, könnte man jetzt einen Netzwerksniffer einsetzen, also ein Tool welches den Netzwerkverkehr mitprotokollieren und mittels Filter gezielt nach Datenübertragungen suchen kann. Aber auch die Oracle Datenbanksoftware stellt Mittel zur Verfügung, um einen Einblick in den Netzwerkverkehr mit der Datenbank zu bekommen. Dazu muss nur in der Datei "sqlnet.ora" ein Tracing mit geeigneten Optionen eingestellt werden:

trace_level_client = 16

Listing 1:  Einschalten von Tracing in der Datei sqlnet.ora

Jede neue Datenbanksitzung wird ab sofort eine Tracedatei erzeugen. In dieser Tracedatei kann man dann zum Beispiel folgende Einträge finden:

nspsend: 00 CE 6A A0 01 73 65 6C  |..j..sel|
nspsend: 65 63 74 20 2A 20 66 72  |ect * fr|
nspsend: 6F 6D 20 65 6D 70 0A 01  |om emp..|

Listing 2:  übertragung eines SELECT-Statements

Man sieht genau, welches SELECT-Statement vom Client an den Datenbankserver geschickt wird. Das sieht auf den ersten Blick nicht wirklich gefährlich aus. Dennoch enthalten Datenbankabfragen oft interessante Informationen für nicht autorisierte Personen. Nachdem die Abfrage von der Datenbank bearbeitet wurde, wird das Ergebnis an den Client geschickt:

nsprecv: 00 00 04 4E 67 61 6F 00  |...Ngao.|
nsprecv: 00 00 00 07 4C 61 44 6F  |....LaDo|
nsprecv: 72 69 73 00 00 00 00 05  |ris.....|
nsprecv: 6C 6E 67 61 6F 00 00 00  |lngao...|

Listing 3:  übertragung abgefragter Daten

Ein Angreifer kann alle an den Client geschickten Daten abfangen und lesen. Dieses ist aber noch nicht alles: Wird ein Passwort eines Datenbankbenutzers geändert und die Anwendung benutzt dabei eine Netzwerkverbindung, so wird auch das neue Passwort unverschlüsselt übertragen:

nspsend: 00 CE 6A A0 01 61 6C 74  |..j..alt|
nspsend: 65 72 20 75 73 65 72 20  |er user |
nspsend: 73 63 6F 74 74 20 69 64  |scott id|
nspsend: 65 6E 74 69 66 69 65 64  |entified|
nspsend: 20 62 79 20 6C 69 6F 6E  | by lion|

Listing 4:  übertragung von DDL-Statements

Nicht nur das Mitlesen von Datenpaketen ist problematisch. Ein Angreifer kann diese Datenpakete auch verändern und so in Transaktionen eingreifen. Man kann anhand dieser einfachen Beispiele, die man in jeder Oracle Datenbankinstallation nachvollziehen kann, sehen, dass die Verschlüsselung des Netzwerkverkehrs ein elementarer Baustein einer Sicherheitsstrategie sein muss.

Dieses gilt umso mehr als viele Angriffe auf IT-Systeme innerhalb von Firewall geschützten Bereichen stattfinden. Eine Verschlüsselung des gesamten Netzwerkverkehrs wäre hierzu ausreichend, aber für die meisten Unternehmen ist dieses nicht notwendig und wäre auch zu teuer.

Oracle bietet die Verschlüsselung des Netzwerktransfers zwischen Oracle Datenbankservern und Oracle Clients als lizenzpflichtige Option zur Enterprise Edition der Datenbank an. Dabei ist der Begriff "Oracle Client" weit zu fassen: Aus der Sicht einer Datenbank ist ein Application Server oder eine andere Datenbank, die mittels Datenbank-Link zugreift, auch ein Oracle Client.

Verschlüsselung mit Oracle Advanced Security

Die lizenzpflichtige Option "Oracle Advanced Security" enthält verschiedene Sicherheitsfunktionalitäten. An dieser Stelle wird nur der Bereich Netzwerkverschlüsselung betrachtet. Sowohl für den Oracle Server als auch für den Oracle Client muß die Datenbankoption installiert sein. Das Einschalten der Verschlüsselung findet mittels weniger Parameter in der Datei "sqlnet.ora" statt.

Zwei Aspekte werden durch diese Parameter eingestellt:

Soll überhaupt verschlüsselt werden?
Welcher Algorithmus soll verwendet werden?

Ob verschlüsselt wird, wird mittels der Parameter "sqlnet.encryption_client" bzw. "sqlnet.encryption_server" festgelegt. Dabei hat man die Wahl zwischen vier Einstellungen:

Rejected
Verschlüsselung wird verweigert
Accepted (Default)
Verschlüsselung wird akzeptiert, wenn der andere es möchte
Requested
Verschlüsselung wird gewünscht, aber nicht verlangt
Required
Verschlüsselung wird verlangt

Entsprechend der Einstellungen auf beiden Seiten ergibt sich nun, ob verschlüsselt wird oder nicht, bzw. ob überhaupt eine Datenbankverbindung zustandekommt. Per Default gilt für beide Seiten der Wert "Accepted", was zur Folge hat, dass beide Seiten für eine Verschlüsselung zur Verfügung stehen, sie diese aber nicht wünschen - es findet also auch keine Verschlüsselung statt. Als nächstes muß noch der Verschlüsselungsalgorithmus gewählt werden. Je nach Version des Datenbankservers bzw. Oracle Clients stehen verschiedene Verfahren zur Verfügung. Im Handbuch "Advancced Security Administrators Guide" werden die Verschlüsselungsverfahren beschrieben. Man kann immer mehrere Verfahren angeben, damit ein auf beiden Seiten erlaubtes Verfahren ermittelt werden kann. Die Datei sqlnet.ora sieht auf der Serverseite dann zum Beispiel so aus:

sqlnet.encryption_server = required
sqlnet.encryption_types_server = AES256,RC4256
sqlnet.encryption_client = required
sqlnet.encryption_types_client = AES256,RC4256

Listing 5:  sqlnet.ora für Verschlüsselung auf Serverseite

Auch die "client"-Parameter wurden hier angegeben, da eine Datenbank auch als Client agieren, kann, z.B. bei der Verwendung von Database Links. Die gleiche Datei kann auch auf der Client-Seite verwendet werden, vorausgesetzt der Client unterstützt die angegebenen Algorithmen. Die Tatsache, dass auch serverseitige Parameter spezifiziert sind, stört dabei nicht.

Integritätsprüfungen

Die Verschlüsselung allein reicht nicht aus, um den Netzwerkverkehr abzusichern. Auch verschlüsselte Datenpakete können abgehört, umgeleitet und in veränderter Form wieder eingespielt werden. Um dieses abzusichern, sollten Checksummen in den Datenpaketen integriert werden. Dieses konfigurieren Sie mit zwei Parametern in der sqlnet.ora, mit denen Sie wieder den Algorithmus sowie den Einsatzmodus festlegen:

sqlnet.crypto_checksum_server = required
sqlnet.crypto_checksum _types_server = MD5,SHA1
sqlnet.crypto_checksum_client = required
sqlnet.crypto_checksum _types_client = MD5,SHA1

Listing 6:  sqlnet.ora für Integritätsprüfung auf Serverseite

Fazit

Der Netzwerkverkehr zwischen Datenbankclients und dem Datenbankserver sollte unbedingt verschlüsselt werden, da die übertragenen Daten nicht sicher vor unbefugtem Zugriff sind. Auch Integritätsprüfungen sind sehr wichtig. Dazu stehen für Oracle Datenbanken zwei Alternativen zur Verfügung: Die Verschlüsselung des gesamten Netzwerkes, was sehr aufwändig und auch teuer werden kann, oder die Verschlüsselung mittels der Oracle Advanced Security Option, die schnell installiert und konfiguriert ist.

Zurück zur Community-Seite