Inhaltsverzeichnis
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:
[slideshare id=51535853&doc=deroracledbaundseinepasswoerter-150812090538-lva1-app6892]
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:
- Wallet anlegen
- Zugriff auf Wallet in sqlnet.ora konfigurieren
- TNSAlias in der tnsnames.ora setzen
- 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.