Tag Archives: security

DB 12.2: Neue Security Features

Oracle hat die Dokumentation für die Datenbank Version 12.2 veröffentlicht. Es sind eine Reihe neuer Security Features enthalten, insbesondere im Bereich TDE (Transparent Data Encryption). Wir bereits vermutet wurde, wird der Krypto-Algorithmus GOST unterstützt. Auch in der Kerberos-Implementierung soll sich einiges verbessert haben: Kerberos kann nun auch für Direct NFS genutzt werden und die Client-Konfiguration wird einfacher.

Eine kurze Übersicht über die neuen Security Features gibt der New Features Guide12c Release 2:

Encryption

  • TDE Tablespace Live Conversion
  • Fully Encrypted Database
  • Support for ARIA, SEED, and GOST Encryption Algorithms in TDE
  • TDE Tablespace Offline Conversion

Neuer Kerberos Stack: AD Authentifikation für Datenbank 12c

Wir haben in diesem Blog des öfteren die Empfehlung ausgesprochen, eine zentrale Benutzerverwaltung statt lokaler Benutzerkonten für den Zugang zu Oracle Datenbanken zu verwenden. Für Umgebungen mit bestehender Active Directory Infrastruktur bietet sich hierfür in erster Linie die AD-Anbindung über LDAP und Kerberos an.

Die Kerberos-Unterstützung ist bereits seit Version 7 der Oracle Datenbank vorhanden und gut dokumentiert. Für die Anbindung an Active Directory wird in der Regel ein Oracle LDAP-Server (OID oder OUD) verwendet, um die Oracle-spezifischen Einstellungen nicht im Active Directory Verzeichnis speichern zu müssen. Die Einrichtung dieser Komponenten mit der Datenbank 11gR2, dem Oracle Internet Directory als LDAP-Server und Microsoft Windows Server 2008 haben wir bereits in diesem Blog und in unserem Wiki beschrieben.

Oracle Wallets hacken

Oracle Wallets werden benutzt, um SSL Zertifikate, die dazugehörigen Schlüssel, aber auch Klartext-Passwörter (Secure Enterprise Password Store) abzulegen. Sie werden normalerweise durch ein Wallet-Passwort geschützt, das bei jedem Öffnen oder Auslesen eingegeben werden muß.

Um auch automatisiert mit Wallets arbeiten zu können, gibt es die Auto-Login-Funktion. Wird diese aktiviert, wird eine zusätzliche Datei im Wallet erzeugt, die sogenannte Single Sign On Datei (.sso). Diese ist ebenfalls verschlüsselt, aber nicht mit einem benutzerdefinierten Passwort, sondern mit einem Standard-Passwort. Auto-Login-Wallets werden in der Regel verwendet, um eine automatisierte Anmeldung an der Datenbank durchführen zu können, ohne dass ein Passwort im Klartext in Skripten, Konfigurationsdateien oder Umgebungsvariablen abgelegt werden muss.

Damit es nicht möglich ist, ein Wallet einfach zu kopieren und von einem anderen Rechner aus zu verwenden, gibt es die Auto-Login-Local-Funktion. Wird diese für ein Wallet eingestellt, so kann das Auto Login Wallet nur auf dem Rechner verwendet werden, auf dem es erzeugt wurde.

Enterprise Security mit LDAP und PKI – Varianten der zentralen Benutzerverwaltung für Oracle Datenbanken

Einleitung

Direkte Benutzerkonten und Passwörter in der Datenbank sind eine Sicherheits-Schwachstelle, da in der Regel keine eindeutige Zuordnung von natürlichen Personen zu Benutzerkonten möglich ist, keine unternehmenseinheitliche Sicherheitsregel durchgesetzt werden kann und ausgeschiedene Mitarbeiter nicht sicher und sofort aus sämtlichen Systemen ausgeschlossen werden können.

In diesem Artikel werden die verschiedenen Möglichkeiten aufgezeigt, Enterprise Single Sign On und Public Key Infrastructure (PKI) zu nutzen, um Datenbankbenutzer zu authentifizieren. Anhand von Projekterfahrungen aus der Praxis wird die Integration der Oracle Datenbank mit LDAP-Verzeichnissen (OID, OUD) und Microsoft ActiveDirectory mit und ohne Oracle Virtual Directory (OVD) erklärt sowie die Einführung von SmartCard-basierter PKI als Alternative vorgestellt.

Passwörter wiederherstellen in Oracle 11g

In der Datenbank Version 11gR1 hat Oracle bekanntlich case-sensitive Passwörter und einen neuen Passwort-Algorithmus eingeführt. In der Datenbank werden nicht die Klartext-Passwörter, sondern nur deren Hashes abgelegt, und der Algorithmus, mit dem diese Hashes berechnet werden, war bei 10g 3DES, und ist seit 11g SHA1. Im 10g-Hashverfahren fliesst der Username als Salt in den Hash mit ein, während ab 11g ein zufälliges Salt verwendet wird. Ab 11g können die Hashes also zwischen verschiedenen Benutzern geteilt werden.

DB Link Passwörter Metadaten in 11.2.0.4

Seit der Datenbank Version 11.2.0.4 funktioniert das Auslesen der Beschreibungen für Datenbank-Links über DBMS_METADATA.GET_DDL nicht mehr. Statt des Passwort Hashes wird nun eine Bind Variable angezeigt.

Die Passwörter von Datenbank-Links wurden früher in der PASSWORD-Spalte der Tabelle SYS.LINK$ im Klartext abgelegt und waren einfach lesbar. In Version 10gR1 wurde der Zugriff auf diese Tabelle aus der Rolle SELECT ANY DICTIONARY entfernt, mit 10gR2 wurde die Spalte PASSWORDX eingeführt, die nun nur noch den Hash speichert.  Mit der Sicherheit dieses Hashes steht es allerdings auch nicht zum Besten.

Blutendes Herz

Besser als “catastrophic” kann man die jüngste OpenSSL-Schwachstelle “Heartbleed” nicht beschreiben.

“At this point, the odds are close to one that every target has had its private keys extracted by multiple intelligence agencies. The real question is whether or not someone deliberately inserted this bug into OpenSSL and has had two years of unfettered access to everything.” (Bruce Schneier)

Auf Netzpolitik.ORG ist auch ein Artikel hierzu. Außerdem gibt es, wie so oft, ein sehr schönes XKCD.

Wie die IPSEC-Hintertür im Netzwerk-Stack von OpenBSD ist dies ein Beispiel für Schwachstellen in Open Source Code. Das der Code öffentlich sichtbar war, hat in diesen Fällen nicht geholfen, da niemand die Lücke als eine solche erkannt hat.