Benutzer-Werkzeuge

Webseiten-Werkzeuge


dba:passwort_schuetzen

Datenbank User Passwörter in Shell und SQL Skripten

Ein hohes Sicherheitsrisiko geht von Hardkodierten Passwörtern in Shell und SQL Scripten aus.
In Linux kann zudem auch recht einfach ein, über die Kommando Zeile als Aufrufparameter gesetztes Passwort, von jederman über die Prozessliste mit „ps -Af“ mitgelesen werden.

Welche Möglichkeiten gibt es Passwörter zu verschleiern bzw. gar nicht zu verwenden:

  • Connect / as sysdba auf lokaler Maschine für User in der DBA Gruppe
  • Den Datenbank User extern autentifizieren als ops$ User
  • Scripte verschlüsseln
  • Secure External Passwort Store
  • usw.

Siehe auch meinen Vortrag bei der SIG Securtiy von 10.2012 Secure Scripting SIG Security München oder in Slideshare:

Connect / as sysdba

Ist der am Betriebsystem angemeldete Anwender in der Betriebsystemgruppe dba (Linux) oder ora_dba (Windows) kann sich der Anwender mit „sqlplus / as sysdba“ an der lokalen Datenbank anmelden.
(Vorraussetzung Umgebung ist gesetzt →Arbeitsumgebung setzen und einrichten)

SQLNET.AUTHENTICATION_SERVICES= (NTS)

Damit kann in Scripten, die auf eine lokale DB zugreifen auf das Passwort verzeichtet werden.

Tipp in 9i:
Leerzeichen vor der Shell schützen, sqlplus „/ as sysdba“

Secure External Passwort Store

ab 10g R2:

Mit dem Secure External Passwort Store Feature wird der User und das Passwort in einer Oracle Wallet mit hoher Verschlüsselung (3DES) hinterlegt.
Das Feature ist kein Teil der „Oracle Advanced Security Option“ und kann damit auch allen Editionen genutzt werden.
Der Connect findet über einen speziellen TNSAlias pro User statt.
Der TNSAlias ist qusi der primary Key, der die Tupel aus Username und Password beschreibet daher muss pro User ein TNSAlias angelegt weden

Konfiguration:

  1. Wallet anlegen
  2. Zugriff auf Wallet in sqlnet.ora konfigurieren
  3. TNSAlias in der tnsnames.ora setzen
  4. Testen

Wallet anlegen

Mit dem Programm mkstore kann eine Wallet angelegt werden.

C:\>mkdir c:\wallet
C:\>cd wallet
C:\wallet>mkstore -wrl . -create
Enter password:
Enter password again:
C:\wallet>dir
 Verzeichnis von C:\wallet
..
13/05/2010  17:16             7,940 cwallet.sso
13/05/2010  17:16             7,912 ewallet.p12

Kann aber ein Angreifer die Wallet auf einen anderen Server kopieren, kann diese dort auch verwendet werden!

Alternativ kann ab Oracle 11.2 mit dem Programm ORAPKI die Wallet so angelegt werden, das die Wallet nur auf dem aktuellen Server UND dem aktuellen Anwender verwendbar ist.
Wallet anlegen mit orapki:

orapki wallet create -wallet "." -auto_login_local


Mit der Option AUTO_LOGIN_LOCAL kann dieses Wallet nur noch auf dem Server vom aktuellen Anwender benutzt werden.

Unberechtigte Benutzer oder Server erhalten bei der Benutzung dieses Wallets eine Fehlermeldung:

ERROR:
ORA-12578: TNS: Wallet konnte nicht ge÷ffnet werden


Password und User in der Wallet hinterlegen

Mit „mkstore -wrl <wallet_location> -createCredential <db_connect_string> <user_name> <password>“ wird der User angelegt

C:\wallet>mkstore  -wrl .  -createCredential oraidc idcuser idcpassword
Enter password:
Create credential oracle.security.client.connect_string1

sqlnet.ora konfigurieren

Zuerst mit einen tnsping xxx testen, welche sqlnet.ora überhaupt in der akutellen Session verwandt wird.
Datei (in %ORACLE_HOME%/network/admin/sqlnet.ora) öffnen und um folgenden Eintrag ergänzen:

WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=C:\wallet)))
SQLNET.WALLET_OVERRIDE=TRUE
SSL_CLIENT_AUTHENTICATION=FALSE

Diese Einstellung bewirken, das bei „sqlplus /@alias“ automatisch die Wallet verwendet wird.

tnsnames.ora konfigurieren

Neuen TNSAlias anlegen (in %ORACLE_HOME%/network/admin/tnsnames.ora):

ORAIDC =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.178.23)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = PRIM01)
    )
 )

mit tnsping testen, „tnsping oraidc“ muss positive Ergebnis zurückgeben!

Testen

C:\wallet>sqlplus /@oraidc

Sicherheitsüberlegungen

Über einen SQL*Net Trace kann nun das Verhalten geprüft werden: (Parameter in SQLNet.ora setzen siehe ⇒ SQL Net Trace anlegen und Logfile auswerten):

..
[13-MAI-2010 17:55:02:218] nzucpget_parameter: value retrieved for parameter "WALLET_LOCATION": "(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=C:\wallet)))".
..
[13-MAI-2010 17:55:02:218] nzdcpgp_get_parameter: Resulting value:
	Parameter "WALLET_LOCATION"
	Method: "FILE"
	Filename: "C:\wallet\cwallet.sso"
...
[13-MAI-2010 17:55:02:218] nzhewencPkcs12wlttoWallet: entry
...
13-MAI-2010 17:55:02:234] nzdcfcx_free_cert_ctx: entry
[13-MAI-2010 17:55:02:234] nzdkfvc_free_private_ctx: entry
[13-MAI-2010 17:55:02:234] nzdkfvc_free_private_ctx: exit
[13-MAI-2010 17:55:02:234] nzdcfcx_free_cert_ctx: exit
[13-MAI-2010 17:55:02:234] nzxMKEOU_MapKeyExtToOrclUsg: entry
[13-MAI-2010 17:55:02:234] nzxMKEOU_MapKeyExtToOrclUsg: exit
...
[13-MAI-2010 18:53:56:781] nspsend: 00 07 69 64 63 75 73 65  |..idcuse|
[13-MAI-2010 18:53:56:781] nspsend: 72 27 00 00 00 0D 41 55  |r'....AU|
...

Auf den ersten Blick kann dort zwar die Verwendung der Wallet nachvollzogen werden, der User wird angezeigt, weitere Informationen so nicht sichtbar.
Wird die Wallet im Oracle Wallet Manager geöffnet, sind auch keine weiteren Daten sichtbar.

Aber:
Wie ließt SQL*Plus nun die Daten dort aus? Es wird kein Passwort oder ein andere Key ausgeben, d.h. es muss eine universelle OCI Methode zum lesen der Daten existieren?


Nun benötigen wir in Scripten kein Passwort mehr, geht ein Script verloren ist hier das Sicherheitsrisiko minimiert.

Auch kann eine zentral abgelegt Wallet Entwickler Zugriff auf Datenbanken erlauben, ohne das diese das Passwort kennen müssen.

Quellen

Cookies helfen bei der Bereitstellung von Inhalten. Durch die Nutzung dieser Seiten erklären Sie sich damit einverstanden, dass Cookies auf Ihrem Rechner gespeichert werden. Weitere Information
"Autor: Gunther Pipperr"
dba/passwort_schuetzen.txt · Zuletzt geändert: 2016/01/08 16:42 von Gunther Pippèrr