Oracle Security Seminarunterlage - IF DV GmbH
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
IF DV GmbH Oracle Security Seminarunterlage
ORACLE SECURITY
2
Impressum
Version: 1.01
DID: ORA_SEC
Autoren: Jörg Fritze
Gabriel Sommer
Herausgeber: IF DV GmbH
Alte Straße 65
D-44143 Dortmund
G m b H
Telefon: +49-231-416377
D V
Telefax: +49-231-410944
I F
E-Mail: info@if-dv.de
Internet: http://www.if-dv.de
Wichtiger Hinweis
Diese Seminarunterlage wurde mit größter Sorgfalt erstellt. Trotzdem können wir Fehler
nicht völlig ausschließen und können deshalb für fehlerhafte Angaben und deren Folgen keine
Haftung übernehmen. Bitte geben Sie uns Hinweise zu Fehlern unter der oben angegebenen
Telefonnummer oder E-Mail-Adresse.
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere
Copyright 2010 by ID DV GmbH
die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Ta-
bellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen
und der Speicherung auf Datenverarbeitungsanlagen bleiben auch bei nur auszugsweiser
Verwendung vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes
ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen der Bundesrepublik
Deutschland mit Genehmigung des Urhebers zulässig. Sie ist grundsätzlich vergütungspflich-
tig.
Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtgesetzes.
Jörg Fritze, Dortmund 2010
ORACLE SECURITY
Identifizierung und Authentisierung–Zutrittskontrolle 2-17
Betriebssystem-authentifizierte Benutzer
Alte Oracle-Hasen oder ehemalige VMS-Nutzer kennen diese Technik
evtl. noch unter dem Begriff "OPS$-User", weil Oracle aus historischen
Gründen einen Präfix namens "OPS$" für Betriebssystembenutzer fest-
legt. Dies hat zwar einen nostalgischen Reiz, ist jedoch sicherheitstech-
nisch unelegant.
Durch folgenden Befehl kann dann nämlich sehr einfach erkannt wer-
den, welche Benutzer nicht in Oracle sondern nur über das Betriebssys-
tem überprüft werden:
SELECT username, account_status
FROM dba_users
G m b H
WHERE username LIKE 'OPS$%'
;
D V
Aber zunächst zur Syntax; man legt einen entsprechenden Benutzer
I F
wie folgt an:
CREATE USER name IDENTIFIED EXTERNALLY;
Existiert ein BS-Benutzer name, so kann dieser sich ohne Angabe von
Benutzer oder Passwort an Oracle anmelden.
Voreingestellt ist hier (zum Glück) nur eine lokale Login-Erlaubnis. Sol-
len auch entfernte Zugriffe erlaubt werden, muss der Oracle-System-
parameter REMOTE_OS_AUTHENT auf TRUE gesetzt werden.
Copyright 2010 by IF DV GmbHORACLE SECURITY
2-18 Identifizierung und Authentisierung–Zutrittskontrolle
Vorteile BS-Benutzer Authentisierung:
Benutzer haben einen bequemeren Zugang zur DB und brauchen
sich keine weiteren Passworte zu merken
lokale Batch-Programme benötigen keine Login-Anweisungen mit
fest kodierten Passwörtern
Nachteile:
Die DB-Schutzschicht geht verloren, insbesondere bei Fernzugrif-
fen (Remote Login's) ist dies sehr gefährlich!
G m b H
Jeder BS-Benutzer kann immer nur mit genau einem DB-
Benutzer verbunden werden.
D V
I F
Copyright 2010 by ID DV GmbHORACLE SECURITY
Identifizierung und Authentisierung–Zutrittskontrolle 2-21
Jetzt kann ein Wallet im obigen Verzeichnis angelegt werden:
C:/>mkstore -wrl "C:/oracle/product/10.2.0/db_1/NETWORK/ADMIN" -create
Wallet-Kennwort eingeben
Wallet-Kewnnwort erneut eingeben
Nun legen wir einen Eintrag im Wallet an:
C:/>mkstore -wrl "C:/oracle/product/10.2.0/db_1/NETWORK/ADMIN"
-createCredential jf10 pwstore tresor
Wallet-Kennwort eingeben
G m b H
Create credential oracle.security.client.connect_string1
D V
Den Eintrag prüfen:
I F
C:/>mkstore -wrl "C:/oracle/product/10.2.0/db_1/NETWORK/ADMIN" -listCredential
Wallet-Kennwort eingeben
List credential (index: connect_string username)
1: jf10 pwstore
Jetzt ist ein Login ohne Eingabe von Benutzernamen/Passwort möglich:
Copyright 2010 by IF DV GmbH
C:/>sqlplus /@jf10
SQL*Plus: Release 10.2.0.4.0 - Production on Fr Jan 23 14:07:35 2009
Copyright (c) 1982, 2007, Oracle. All Rights Reserved.ORACLE SECURITY
2-22 Identifizierung und Authentisierung–Zutrittskontrolle
Verbunden mit:
Oracle Database 10g … 10.2.0.4.0 - Production
SQL> select user from dual;
USER
------------------------------
PWSTORE
Um das PW eines Benutzereintrags zu wechseln, schreibt man:
G m b H
mkstore -wrl -modifyCredential
D V
I F
So wird ein Eintrag gelöscht:
mkstore -wrl -deleteCredential
Auf DB-Ebene kann man (leider?) nicht erkennen, ob ein Login per
"Client-Wallet" = "externem PW-Speicher" erfolgt ist:
SQL> SELECT sys_context('userenv', 'authentication_method')
2 "Login-Methode" FROM dual;
Copyright 2010 by ID DV GmbH
Login-Methode
----------------------------------------------------------------
PASSWORDORACLE SECURITY
Identifizierung und Authentisierung–Zutrittskontrolle 2-23
Nicht jedes Werkzeug unterstützt diese "Login-Automatik", problemlos
geht es z.B. bei:
SQL*PLUS
RMAN
TOAD
PL/SQL Developer
Ein Passwort-Wallet ist selbstverständlich nicht mit der für DBA-
Sonderfunktionen notwendigen Passwort-Datei zu verwechseln.
Diese wird mittels "orapwd" erstellt und z.B. mit Hilfe des SQL-Befehls
G m b H
GRANT SYSDBA TO benutzer;
D V
mit entsprechend privilegierten Benutzern gefüllt. Eine Liste dieser Be-
nutzer (also quasi den Inhalt der Passwort-Datei) erhält man mit
I F
SELECT * FROM v$pwfile_users;
Copyright 2010 by IF DV GmbHORACLE SECURITY
2-24 Identifizierung und Authentisierung–Zutrittskontrolle
Web User authentifizieren (Proxy)
Die Kommunikation eines Clients mit einer Datenbank gestaltet sich in
den ja heute üblichen Mehrschichtarchitekturen durchaus etwas kom-
plizierter als bei einer reinen Client-/(DB)-Server Lösung.
Grundsätzlich lässt sich der Begriff "Proxy" in diesem Zusammenhang
mit "Stellvertreter" übersetzen. Zwischen Mittelschicht/Applikations-
server und Datenbankserver wird eine Verbindung aufgebaut, auf die
der eigentliche Client dann zugreifen kann.
Bei der für die Verbindungsnutzung können zwei Varianten unterschie-
den werden:
a) ohne Client-Kontext/Authentifizierung
G m b H
b) mit Client-Kontext/Authentifizierung
D V
Im Fall A wird vom Client nur ein Benutzername verlangt; da der Pro-
I F
xy-Benutzer ja bereits mit der Datenbank verbunden ist, kann der
applikatorische Client diese Variante nutzen ohne ein Passwort ange-
ben oder sich auf andere Art authentisieren zu müssen.
Dies Variante hat sicher diverse Nachteile; z.B. stehen jedem Benutzer
ja prinzipiell alle Privilegien des zentralen DB-Benutzers zur Verfü-
gung. Etwaige Einschränkungen müssen im Applikationscode verwaltet
werden.
Im Fall B wird der Client von der Mittelschicht über eine beliebige Me-
thode authentifiziert. Die Mittelschicht authentifiziert sich nun gegen-
über der Datenbank (mit fest verdrahtetem Passwort oder kennwortlo-
Copyright 2010 by ID DV GmbH
sem Verfahren) über den Proxy-Benutzer, liefert aber (jetzt kommt der
entscheidende Unterschied!) den Client-Kontext mit in die Datenbank.
Dieser Kontext (Client Identifier) kann nun dazu dienen unterschiedli-
che Zugriffsrechte mit Hilfe entsprechender "Applikations-Rollen" (s.
Kap. 3 – Benutzer und Rollen) zu setzen.
Diese Methode besitzt also gegenüber dem obigen Fall A zwei grund-
sätzliche Vorteile:ORACLE SECURITY
Identifizierung und Authentisierung–Zutrittskontrolle 2-27
Kurzdefinition PKI
Mit Public-Key-Infrastruktur (PKI, engl. public key infrastructure) bezeichnet man in der
Kryptologie ein System, welches es ermöglicht, digitale Zertifikate auszustellen, zu verteilen und
zu prüfen. Die innerhalb einer PKI ausgestellten Zertifikate werden zur Absicherung rechnerge-
stützter Kommunikation verwendet.
Mit Hilfe eines asymmetrischen Kryptosystems können Nachrichten in einem Netzwerk digital
signiert und verschlüsselt werden. Sichere Kryptosysteme können bei geeigneter Wahl der Para-
meter (z. B. der Schlüssellänge) auch bei Kenntnis des Verfahrens nicht in überschaubarer Zeit
gebrochen werden.
Für jede verschlüsselte Übermittlung benötigt der Sender allerdings den öffentlichen Schlüssel
(Public-Key) des Empfängers. Dieser könnte z. B. per E-Mail versendet oder von einer Web-
Seite heruntergeladen werden. Es muss jedoch sichergestellt werden, dass es sich tatsächlich um
den Schlüssel des Empfängers handelt und nicht um die Fälschung eines Betrügers.
G m b H
Hierzu dienen nun digitale Zertifikate, welche die Authentizität eines öffentlichen Schlüssels und
seinen zulässigen Anwendungs- und Geltungsbereich bestätigen. Das digitale Zertifikat ist selbst
durch eine digitale Signatur geschützt, deren Echtheit mit dem öffentlichen Schlüssel des Aus-
stellers des Zertifikates geprüft werden kann.
D V
I F
Um die Authentizität des Ausstellerschlüssels zu prüfen, wird wiederum ein digitales Zertifikat
benötigt. Auf diese Weise lässt sich eine Kette von digitalen Zertifikaten aufbauen, die jeweils
die Authentizität des öffentlichen Schlüssels bestätigen, mit dem das vorhergehende Zertifikat
geprüft werden kann. Eine solche Kette von Zertifikaten wird Validierungspfad oder Zertifizie-
rungspfad genannt. Auf die Echtheit des letzten Zertifikates (und des durch diesen zertifizierten
Schlüssels) müssen sich die Kommunikationspartner aber ohne ein weiteres Zertifikat verlassen
können.
Quelle: Wikipedia 27.03.2009
Kurzdefinition LDAP (Lightweight Directory Access Protocol)
Ein LDAP-Server stellt Informationen über Benutzer und deren Gruppenzugehörigkeit bereit.
Copyright 2010 by IF DV GmbH
Aber auch andere Objekte wie zum Beispiel die Zertifikate eines Computers können in einem
solchen Verzeichnis gespeichert werden. Beispiele für LDAP-Server sind:
IBM Lotus Notes
Microsoft Active Directory
Oracle Internet DirectoryORACLE SECURITY
2-28 Identifizierung und Authentisierung–Zutrittskontrolle
DB-Links
Datenbank-Links sind aus Datenschutzsicht ebenfalls erwähnenswert.
Man unterscheidet ja private und öffentlich zugängige ('public') Daten-
bank-Links. Die Eigenschaft "privat" erlaubt nur dem Link-Ersteller
den Zugriff, ein öffentlicher DB-Link (per "create public database link
…" erstellt) darf von jedem DB-Nutzer verwendet werden.
DB-Links können neben dem Verweis auf die anzusprechende Daten-
bank auch Benutzernamen und Passwort und damit explizite
Authentikationseigenschaften enthalten. Fehlen diese, so gilt ein impli-
ziter Login-Wunsch mit dem aktuellen Benutzernamen und –passwort.
G m b H
Die folgende Tabelle zeigt den Benutzerzugriff per Datenbank-Link:
Link-Typ Expl. authentisiert Zugriff
D V
private nein Benutzername und –passwort der aktuellen Sitzung
=> die beiden zu verbindenden Datenbanken benötigen
I F
synchronisierte Benutzer und Passwörter
private ja Benutzername und –passwort für den Zugriff auf die
Ziel-DB werden der Link-Definition entnommen und
ist daher fix.
public nein Wie beim privaten Link, jedoch kann dieser Link von
jedem DB-Benutzer eingesetzt werden – die Verbin-
dung ist benutzerspezifisch
public ja Wie beim privaten Link, jedoch kann dieser Link von
jedem DB-Benutzer eingesetzt werden – die Verbin-
dung ist statisch
Link-Informationen (insbesondere Benutzernamen und –passwörter
werden in der Datenbank abgelegt; achten Sie also bitte darauf, dass
folgende Tabellen nicht allgemein zugreifbar sind:
Copyright 2010 by ID DV GmbH
DBA_DB_LINKS
V$DB_LINK
SYS.LINK$ (! enthält Passworte - bis 10.1 unverschlüsselt)ORACLE SECURITY
Autorisierung – Datenzugriffskontrolle 3-17
-- ad 3.
(evtl. Fehler in UDUMP)
conn anwender/geheim89@testdb
-- Arbeitszeit
SQL> select to_char(sysdate, 'HH24:MI') zeit from dual;
ZEIT
-----
16:08
SQL> select * from dummy;
I
----------
G m b H
10
42
D V
I F
-- und nach Feierabend ...
=>
SQL> select to_char(sysdate, 'HH24:MI') zeit from dual;
ZEIT
-----
19:08
SQL> select * from dummy;
Es wurden keine Zeilen ausgewählt
Copyright 2010 by IF DV GmbH
-- aber als SYS !!!
conn sys/hochgeheim_a644@testdb as sysdba
SQL> select to_char(sysdate, 'HH24:MI') zeit from dual;
ZEIT
-----
19:09
SQL> select * from dummy;ORACLE SECURITY
3-18 Autorisierung – Datenzugriffskontrolle
I
----------
10
42
EINSATZBEREICHE
Bei Anwendungen mit besonders hohen Geheimhaltungs- oder Daten-
schutzanforderungen, wie etwa im medizinischen Bereich
G m b H
Für Hosting-Anwendungen, wo eine strikte Trennung der Daten ver-
schiedener Kunden gewährleistet sein muss, also zur transparenten
D V
Bildung einer Mandantenfähigkeit
I F
Ein Hacker kann mit folgendem Befehl die komplette VPD-
Sicherheits-schicht umgehen (selbst in Oracle 11.2):
grant exempt access policy to public;
ZUGRIFFSPROBLEME BEI VPD
Falls eine Policy-Funktion fehlschlägt, kann ein Benutzer nicht auf die
Copyright 2010 by ID DV GmbH
geschützten Objekte zugreifen (ungewollter Datenschutz ;-) …).
Die Auftrittswahrscheinlichkeit dieser Problematik steigt mit der Kom-
plexität der Funktion.
Es gibt zwei Hauptgründe für einen Policy-Fehler:
Die Policy-Funktion ist ungültig (Status: INVALID) und wird nicht
rekompiliert/ausgeführt. Das kann z.B. passieren, falls eine ZieltabelleORACLE SECURITY
Zugriffsüberwachung 4-9
Hierzu zählen Aktionen, die unter Nutzung der folgenden Privilegien
durchgeführt werden:
ALTER ANY PROCEDURE CREATE ANY JOB
DROP ANY TABLE ALTER ANY TABLE
CREATE ANY LIBRARY DROP PROFILEE
ALTER DATABASE CREATE ANY PROCEDURE
DROP USER ALTER PROFILE
CREATE ANY TABLE EXEMPT ACCESS POLICY
AUDIT ROLE BY ACCESS CREATE EXTERNAL JOB
GRANT ANY OBJECT PRIVILEGE ALTER SYSTEM
CREATE PUBLIC DATABASE LINK GRANT ANY PRIVILEGE
ALTER USER CREATE SESSION
GRANT ANY ROLE ALTER SYSTEM
CREATE USER
AUDIT SYSTEM BY ACCESS DROP ANY PROCEDURE
Was aus Gründen der Sicherheit eine gute Maßnahme darstellt, kann sich
allerdings schnell zum Problem entwickeln, da es keinen Automatismus
G m b H
für das Löschen der Audit-Daten in der Audit-Tabelle (AUD$) gibt.
Die Tabelle wird schnell zunehmend größer, was je nach Konfiguration bis
zum Stillstand der Instanz führen kann. Die Tabelle sollte also in einen
D V
dedizierten Tablespace gelegt und die entstandenen Audit-Daten regelmä-
I F
ßig verarbeitet werden.
In älteren Oracle-Versionen gab es keinen Standardweg, um AUDIT-
Ergebnisse (AUD$, FGA_LOG$) in einem anderen Tablespace als SYS-
TEM (evtl. sogar in getrennten Zielen) abzulegen.
Oracle 11.1.0.7 kennt ein Paket namens DBMS_AUDIT_MGMT, welches
die AUDIT-Verwaltung vereinfacht. Nun können Audit-Tabellen in ande-
re Tablespaces verschoben werden. Ab Oracle 11.2 erlaubt das Paket zu-
sätzlich die automatisierte Löschung alter AUDIT-Einträge durch die
Prozedur CLEAN_AUDIT_TRAIL.
Fragen Sie Ihren Referenten bei Bedarf nach weiteren Details oder Bei-
Copyright 2010 by IF DV GmbH
spielen (audit_verwaltung.txt)
Es empfiehlt sich außerdem, die obigen Audit-Einstellungen zu überprüfen
und ggf. an die eigenen Bedürfnisse anzupassen; einige sind gewiss zu viel
des Guten (z. B. CREATE SESSION...WHENEVER SUCCESSFUL), ande-
re könnten sicherlich noch hinzugefügt werden.ORACLE SECURITY
4-10 Zugriffsüberwachung
Trigger basiertes Auditing
Neben dem AUDIT-Kommando gibt es noch weitere Möglichkeiten, Zu-
griffe auf Objekte oder auch bereits Login-Vorgänge zu protokollieren.
Je nach Audit-Wunsch können verschiedene Triggerarten eingesetzt
werden:
INSERT, UPDATE, DELETE (DML-Objekttrigger)
SELECT (FINE GRAINED AUDITING, s. nä. Kapitel)
DDL-Kommandos (Schema-Trigger)
Sitzung starten (ebenfalls Schema-Trigger)
G m b H
DB-Start /-Stop (System-Trigger)
ORA-Fehlermeldung (ebenfalls System-Trigger)
D V
I F
Einige Beispiele:
-- DML-Objektzugriff
CREATE TRIGGER Auftrag_aud_tr
AFTER INSERT OR UPDATE OR DELETE ON auftrag
FOR EACH ROW
DECLARE
operation VARCHAR2(20);
BEGIN
IF INSERTING THEN
operation := ‘Eingefügt’;
ELSIF UPDATING THEN
operation := ‘Geändert’;
Copyright 2010 by ID DV GmbH
ELSE
operation := ‘Gelöscht’;
END IF;
INSERT INTO protokoll( aktion, benutzer, zeitpunkt,nummer_alt, nummer_neu ) VALUES
(operation, USER, SYSDATE, :OLD.auftrnr, :NEW.auftrnr );
END;
/ORACLE SECURITY
Zugriffsüberwachung 4-11
-- Systemtrigger zur Fehlerprotokollierung
CREATE OR REPLACE TRIGGER se_irf_tr
AFTER SERVERERROR ON DATABASE
BEGIN
IF Ora_Server_Error(1) IN (1536,1562,1631) OR Ora_Server_Error(1) BETWEEN
1650 AND 1659 THEN
irf_mail.SendMail( ‘f.roeing@irf-dv.de’, NULL, ‘Server-Fehler
aufgetreten!’,‘Achtung: Der Fehler ‘ ||ora_server_error(1) || ‘ ist bei
der Datenbank ‘ ||ora_database_name ||‘ für den Benutzer ‘ ||
ora_login_user ||‘ entdeckt worden! ‘ ||‘Offensichtlich liegt ein ‘ ||
‘Plattenplatzproblem vor.’ );
END IF;
END;
/
G m b H
D V
I F
Copyright 2010 by IF DV GmbHORACLE SECURITY
4-12 Zugriffsüberwachung
Fine Grained Auditing
Bisher beschränkte sich der Audit-Zugriff auf minimal ein Objekt (z.B.
eine Tabelle). Evtl. sollen aber nur bei bestimmten Selektionen oder
Projektionen Audit-Sätze angelegt werden. Hier hilft "feines Auditieren"
(FGA) weiter.
Ergebnisse werden in DBA_FGA_AUDIT_TRAIL (oder ab V10 auch in
DBA_COMMON_AUDIT_TRAIL) geschrieben.
Neben dem Namen des zu beobachtenden Objekts können eine Prüf-
funktion, eine Selektionsbedingung, eine Projektionsbedingung und (ab
V10) auch DML-Typen angegeben werden .
…
G m b H
-- Zugriffe auf DUMMY-Tabelle außerhalb der Arbeitszeit werden protokolliert
-- 0. Aufräumen
D V
-- 1. benötigte Rechte
-- 2. Funktion anlegen
I F
-- 3. Policy anlegen ("nur" Prüffunktion übergeben)
-- 4. Zugriffstest
-- ad 0.
drop table fritze.dummy;
exec DBMS_fga.drop_policy(object_schema => 'FRITZE', object_name => 'DUMMY',
policy_name => 'BSP_POL')
create table fritze.dummy(i number);
insert into fritze.dummy values(10);
insert into fritze.dummy values(42);
commit;
-- ad 1.
GRANT EXECUTE ON DBMS_fga TO fritze;
Copyright 2010 by ID DV GmbH
-- ad 2.
create or replace function tagsueber
return NUMBER
is
begin
if to_number(to_char(sysdate, 'HH24')) between 8 and 17 then
return 1;
else
return 0;
end if;ORACLE SECURITY
Datenübertragung – Netzwerksicherheit 5-1
5
G m b H
Datenübertragung – Netzwerksi-
cherheit
D V
I F
Copyright 2010 by IF DV GmbHORACLE SECURITY
5-2 Datenübertragung – Netzwerksicherheit
Listener
Der Listener ist das Ohr der Datenbank zur Außenwelt. Wenn ein
Client eine Anfrage an die Datenbank stellen möchte, nimmt er Kontakt
mit dem Listener auf, der nun seinerseits einen Serverprozess startet
und dessen Adresse (bzw. die Dispatcher-Adresse bei MTS-
Konfiguration) an den Client zurück gibt. Hierüber läuft dann die
Kommunikation.
Naturgemäß sind Listener beliebte Angriffsziele. Um den Angriff deut-
lich zu erschweren, gilt es zunächst einmal einige Basisschutzmaßnah-
men zu treffen:
Alle Verzeichnisse mit Listener-Konfigurationsdateien (auf Server-
und auf Clientseite) sind gegen unberechtigten Zugriff zu schützen.
G m b H
Setzen bzw. entziehen Sie also entsprechende Dateizugriffsrechte auf
BS-Ebene. Entsprechendes gilt für den Zugriff auf die Lister-
D V
spezifischen Programme TNSLSNR und LSNRCTL im Oracle/Bin
Verzeichnis!
I F
Änderung der allseits bekannten Standardportadressen 1521/1526 etc.
Eine komplette Liste dieser Ports sowie die notwendigen Änderungs-
maßnahmen finden Sie hier
www.red-database-security.com/whitepaper/oracle_default_ports.html
Anmerkung: Zur Änderung von Default Ports s. auch Metalink Note ID 359277.1
Spielen Sie aktuelle Listener-Security Patches ein!
Begrenzen Sie SQL*NET Zugriffe von "jenseits der Firewall" auf das
unbedingt nötige Maß, d.h. auf bekannte Absender (z.B. Web-Server),
Applikationen an spezifizierte DB-Server als Adressaten.
Copyright 2010 by ID DV GmbH
Listener-Konfigurationsänderungen dürfen nicht unberechtigt durch-
geführt werden, da sonst z.B. ein Trace aktiviert werden oder der
Listener einfach heruntergefahren werden kann (DoS-Attacke).
Vergeben Sie hierzu ein Passwort mittels LSNRCTL (Kommando
change_password) oder behalten Sie die Voreinstellung (ab Oracle
10.1) "lokale Listener-Administration"
(LOAL_OS_AUTHENTICATION_ = ON in
LISTENER.ORA) . Vor Oracle 10 wird z.B. nicht geprüft, ob derORACLE SECURITY
Datenübertragung – Netzwerksicherheit 5-3
LSNRCTL-Aufrufer zur lokalen DBA-Gruppe gehört.
Falls organisatorisch annehmbar sollten Sie – falls Sie Remote-
Administration benötigen – diese im laufenden Betrieb verbieten.
Der Eintrag in listener.ora:
ADMIN_RESTRICTIONS_LISTENER=ON erledigt dies.
Falls fachlich möglich, sollten Sie die Möglichkeit nutzen, SQL*NET
Zugriffe (per TCP/IP) auf spezielle Clients zu beschränken. Sie kön-
nen wahlweise angeben, welche Maschinen Sie zulassen oder aus-
schließen wollen. Tragen Sie in SQLNET.ORA folgendes ein:
TCP.VALIDNODE_CHECKINH=YES
TCP.INCLUDED_NOTES=(…)
bzw.
TCP.EXCLUDED_NOTES=(…)
G m b H
Um überwachen zu können, ob evtl. jemand versucht das Listener
Passwort zu erraten (z.B. per Brute Force Attacke) sollte "Listener
D V
Logging" aktiviert werden (mit LSNRCTL: Kommandos set
log_directory, set log_file, set log_status).
I F
Nun können Sie Rateversuche durch die Meldung TNS-01169 entde-
cken.
KONTROLLE DER NETZWERKZUGRIFFE AUS DER DATENBANK MIT ACL'S
In der Oracle Datenbank existieren bereits seit längerer Zeit eine Reihe
von PL/SQL Paketen, mit deren Hilfe Informationen aus der Datenbank
heraus an beliebige, im Netzwerk erreichbare Server geschickt werden
können. Zu diesen „Netzwerk“-Paketen zählen:
Copyright 2010 by IF DV GmbH
UTL_TCP
UTL_SMTP
UTL_MAIL
UTL_HTTP
UTL_INADDR
Diese Pakete sind bis Oracle 10g durch das EXECUTE-Privileg, das
standardmäßig an PUBLIC(!) vergeben ist, zur Ausführung freigegeben.
Diese uneingeschränkte und allgemeingültige Zugriffsmöglichkeit aufORACLE SECURITY
5-4 Datenübertragung – Netzwerksicherheit
das gesamte Netzwerk mag praktisch erscheinen, stellt aber ein erheb-
liches Sicherheitsrisiko dar.
Hier liefert Oracle ab Version 11.1 ein neues Sicherheitskonzept: Netz-
werkzugriffe, die durch PL/SQL-Pakete erfolgen, müssen vom DBA so-
wohl für die einzelnen Ziele als auch für die einzelnen Benutzer bzw.
Rollen separat freigegeben werden.
Diese Freigabe erfolgt über so genannte Access Control Listen (ACL's).
Programmtechnisch werden die ACLs als XML-Dokumente mit dem
neuen Paket DBMS_NETWORK_ACL_ADMIN erzeugt und verwaltet.
ACL-Bsp.
G m b H
-- ACL anlegen
BEGIN
DBMS_NETWORK_ACL_ADMIN.CREATE_ACL (
D V
acl => 'test_acl.xml',
description => 'Netzwerkzugriff für UTL-Pakete bzgl. Benutzer TEST_ACL',
I F
principal => 'TEST_ACL' -- 'PUBLIC' für alle Benutzer
is_grant => TRUE,
privilege => 'resolve'); -- 'connect' oder 'resolve' möglich
END;
/
-- ACL zuweisen
BEGIN
DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL (
acl => 'test_acl.xml',
host => 'AS2.if-dv.de'); -- '*' für alle Hosts
END;
/
commit;
Folgende Systemtabellen liefern einen Überblick über ACL's und die
Copyright 2010 by ID DV GmbH
dazugehörende Rechte:
DBA_NETWORK_ACLS
DBA_NETWORK_ACL_PRIVILEGES
Anmerkung zu ACL's: XDB muss in der Datenbank installiert sein!ORACLE SECURITY
Datenübertragung – Netzwerksicherheit 5-7
"alter user tcra identified by tcra;" sieht jetzt z.B. so aus:
…
[06-APR-2009 18:22:20:187] nspsend: 6E 3C E8 AC A9 47 8F C0 |nORACLE SECURITY
5-8 Datenübertragung – Netzwerksicherheit
Client
(SERVER) REJECTED ACCEPTED REQUESTED REQUESTED
REJECTED Klartext Klartext Klartext Keine Verbindung
ACCEPTED Klartext Klartext (*) verschlüsselt verschlüsselt
REQUESTED Klartext verschlüsselt verschlüsselt verschlüsselt
REQUESTED Keine Verbindung verschlüsselt verschlüsselt verschlüsselt
* Dies ist die Voreinstellung!
G m b H
Verschlüsselungsparameter setzen
D V
Wie vorhin im Beispiel gesehen, sind Algorithmus und Typ (sowie eine
I F
Zufallszeichenkette als Start) explizit in der Datei SQLNET.ORA einzu-
tragen (es ginge auch grafisch mit dem Oracle Net Manager).
sqlnet.crypto_seed="zufallszeichenfolge_mit_10_bis_70_zeichen"
sqlnet.ENCRYPTION_TYPES_SERVER=(algor., algor., …)
sqlnet.ENCRYPTION_SERVER=verschlüsselungstyp
sqlnet.ENCRYPTION_TYPES_CLIENT=(algor., algor., …)
sqlnet.ENCRYPTION_CLIENT=verschlüsselungstyp
Copyright 2010 by ID DV GmbH
Nach diesen Einstellungen ist der Datenverkehr auch über folgende
Protokolle/Schnittstellen verschlüsselt
ODBC
JDBCI (OCI="thick" Treiber)ORACLE SECURITY
Datenübertragung – Netzwerksicherheit 5-9
Leider gilt dies nicht für den JDBC "thin" Treiber; da er als reiner Java-
Treiber SQL*NET nur emuliert, müssen Client-Verschlüsselungs-
einstellungen direkt im Programmcode (classes12.jar) angegeben werden.
Der sicherste Algorithmus ist vor Oracle 11g: 3DES168, ab Oracle 11g:
AES256
Parametername Typ und Klasse Erlaubte Werte
oracle.net.encryption_client string static REJECTED ACCEPTED
REQUESTED REQUIRED
oracle.net.encryption_types_client string static RC4_40 RC4_56 DES40C
DES56C 3DES112
3DES168
Ab V11 zusätzlich:
AES128, AES192,
G m b H
AES256
oracle.net.crypto_checksum_client string static REJECTED ACCEPTED
REQUESTED REQUIRED
D V
oracle.net.crypto_checksum_types_client string static MD5
Anmerkung: Zitiert aus Oracle Database JDBC Developer's Guide and Reference sowie
I F
Oracle Database Advanced Security Administrator's Guide 11g
Ein Programmabschnitt kann also so aussehen (CHECKSUM-Erklä-
rung s.u.):
Properties props = new Properties();
try {
props.put("oracle.net.encryption_client", "REQUIRED");
props.put("oracle.net.encryption_types_client", "AES256");
props.put("oracle.net.crypto_checksum_client","REQUESTED");
props.put("oracle.net.crypto_checksum_types_client", " MD5 ");
Copyright 2010 by IF DV GmbH
props.put("user", "gast");
props.put("password","tiger43");
} catch (Exception e) { e.printStackTrace(); }
Connection conn = DriverManager.getConnection
("jdbc:oracle:thin:@testserver:1521:testdb",props);ORACLE SECURITY
5-10 Datenübertragung – Netzwerksicherheit
Integritätsprüfung
Erinnern Sie sich an das "Liebesbrief-Bild" im Kapitel 1? Die Angreife-
rin (vermutlich eine verschmähte Kollegin) hat hier die versandte Nach-
richt abgefangen, verändert und dadurch den Sinn entstellt. Diese Situ-
ation kann zu Herzschmerz führen, eine verfälschte Bankanweisung
(mit z.B. neuem Zielkonto) zu herben finanziellen Verlusten!
Um sich davor schützen zu können, baut man Integritätsprüfungen ein,
die garantieren, dass genau der Inhalt einer Nachricht beim Empfänger
ankommt, der auch vom Absender losgeschickt wurde. Selbstverständ-
lich könnte diese Änderung auch technische Hintergründe haben (z.B.
Übertragungsfehler aufgrund defekter Hardware).
Integritätsprüfungen unterstützen also sowohl den Schutz vor Verlust
G m b H
(Datensicherheit) als auch den Schutz vor vorsätzlicher Veränderung
(Fälschungssicherheit).
D V
Die ASO erlaubt die Bildung kryptographischer Prüfsummen vor und
I F
nach der Datenübertragung. Werden beim Prüfsummenvergleich keine
Unterschiede festgestellt, handelt es sich höchstwahrscheinlich um den
Originaldateninhalt.
Eingestellt wird diese Prüfsummentechnik durch die Eigenschaften Al-
gorithmus (s.u.) und Typ (s.o. "Netz-Verschlüsselung") explizit in der
Datei SQLNET.ORA (oder grafisch mit dem Oracle Net Manager).
sqlnet. CRYPTO_CHECKSUM _TYPES_SERVER=(algor., algor., …)
sqlnet. CRYPTO_CHECKSUM _SERVER=verschlüsselungstyp
Copyright 2010 by ID DV GmbH
sqlnet. CRYPTO_CHECKSUM _TYPES_CLIENT=(algor., algor., …)
sqlnet. CRYPTO_CHECKSUM _CLIENT=verschlüsselungstyp
Erlaubte Algorithmen sind hier: MD5 und SHA1; beide bereits ab Orac-
le 8i.ORACLE SECURITY
Datenspeicherung und –sicherung 6-1
6
G m b H
Datenspeicherung und –
sicherung
D V
I F
Copyright 2010 by IF DV GmbHORACLE SECURITY
6-2 Datenspeicherung und –sicherung
Sicherheit der Data-, Control- und Logfiles
Datendateien sind das Herzstück Ihrer Datenbank. Jeder DBA hütet sie
wie seinen Augapfel, denn er weiß, dass bei z.B. zu großzügig vergebe-
nen Zugriffsrechten (auf BS- oder DB-Ebene) sensible Informationen
leicht zugänglich sind.
Diese Dateien können gelesen, verändert oder gelöscht werden!
Der Zugriff kann auf BS-Ebene durch Editoren oder innerhalb der Da-
tenbank z.B. per PL/SQL (utl_file-Package) erfolgen.
Folgendes Beispiel zeigt, wie leicht Informationen in Tablespacedateien
lesbar sind:
G m b H
-- Benutzer TCRA legt Daten ab
create table test_tab(i number, t varchar2(50));
insert into test_tab values(42, 'zweiundvierzig');
insert into test_tab values(17, 'siebzehn');
D V
commit;
I F
SQL> SELECT * from TEST_TAB;
I T
---------- --------------------------------------
42 zweiundvierzig
17 siebzehn
-- jetzt suchen wir den Speicherort der Tabelle TEST_TAB
-- (als privilegierter Benutzer z.B. Administrator, Tuning-Experte …)
select file_id, block_id, d.blocks, value, substr(f.name,1,45) file_name
from dba_extents d, v$datafile f, sys.ts$ t, v$parameter p
where owner = 'TCRA' and segment_name = 'TEST_TAB' and
Copyright 2010 by ID DV GmbH
segment_type = 'TABLE' and d.file_id = f.file# and d.tablespace_name =
t.name and p.name = db_block_size'
order by file_id, block_id;
FILE_ID BLOCK_ID BLOCKS VALUE FILE_NAME
--------------------------------------------------------------------------
15 36817 16 4096 D:/oracle/oradata/JF10/USERS02.DBFORACLE SECURITY
Datenspeicherung und –sicherung 6-5
SQL> select count(*) from v$logmnr_contents where operation = 'DDL';
COUNT(*)
---------
3
SQL> select username, operation, sql_redo from v$logmnr_contents
2 where operation = 'DDL';
USERNAME OPERATION SQL_REDO
------------------------------------------------------------------------------
ABC DDL drop table autos;
ABC DDL create sequence au;
APPL_X DDL create table mit(pnr number,name
varchar2(30), gehalt number(6,2));
G m b H
-- und jetzt schauen wir mal, wer wieviel verdient …
SQL> SELECT SQL_REDO FROM V$LOGMNR_CONTENTS WHERE username = 'APPL_X'
2 where operation in ('INSERT', 'UPDATE', 'DELETE');
D V
SQL_REDO
I F
------------------------------------------------------------------------------
insert into "APPL_X"."MIT("PNR","NAME","GEHALT") values
(4711, 'Max Muster', 6890.00);
Wer ein "ALTER SYSTEM"-Recht besitzt, kann auch einen Dump ver-
anlassen; dieser liefert ebenfalls Nutzdateninhalte.
Ein Beispiel hierzu findet sich in REDOLOG_DUMP.PDF
Copyright 2010 by IF DV GmbH
Bis Oracle 9 wurden selbst Kommandos wie ALTER USER A
IDENTIFIED BY XYZ; komplett im Klartext in Redo-Logfiles
abgelegt.
Heute muss der interessierte Hacker dafür etwas tiefer in die Trickkiste
greifen, z.B. durch direkte – nicht/schlecht nachweisbare - Hauptspei-
cherzugriffe wie in Kapitel 4 Stichwort "Auditing".ORACLE SECURITY
6-6 Datenspeicherung und –sicherung
Transparente Datenverschlüsselung
Transparent Data Encryption (TDE) ist ab Oracle 10.2 EE mit ASO ver-
fügbar und nutzt standardmäßig den Algorithmus AES192 für Spalten-
verschlüsselung bzw. AES128 für Tablespace-Verschlüsselung .
Es wird mittels Passwort aktiviert, welches in einer externen Datei
(Wallet – bekannt aus Kapitel 2) gespeichert wird.
Der voreingestellte Standort dieser Datei ist hier zu finden: $ORAC-
LE_BASE/admin/$ORACLE_SID/wallet
Änderung möglich mittels SQLNET.ORA Parameter :
ENCRYPTION_WALLET_LOCATION (extra für TDE)
oder
G m b H
WALLET_LOCATION (allg. für Wallets)
ENCRYPTION_WALLET_LOCATION=
D V
(SOURCE=(METHOD=FILE)(METHOD_DATA=
(DIRECTORY=/u01/app/oracle/admin/jf11/encryption_wallet/)))
I F
TDE erstmalig aktivieren durch Anlage des Schlüssels:
ALTER SYSTEM SET ENCRYPTION KEY AUTHENTICATED BY "passwort";
-- legt eine Datei namens ewallet.p12 im Wallet-Verzeichnis an
TDE nach jedem DB-Neustart aktivieren, jeweils mit:
ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "passwort";
Anmerkung: Mit Hilfe des Wallet-Managers kann ein automatisches Wallet-Öffnen durch Erstellung einer Datei namens
Copyright 2010 by ID DV GmbH
cwallet.sso erreicht werden.ORACLE SECURITY
Datenspeicherung und –sicherung 6-7
Jetzt können Felder einzelner Tabellen oder (ab Oracle 11g) sogar die
Inhalte ganzer Tablespaces transparent verschlüsselt werden.
G m b H
Folgende Datentypen werden unterstützt:
D V
Bis V10.2: varchar2, nvarchar, char, nchar, number, date, raw
I F
Ab V11 zusätzlich: binary_float, binary_double, timestamp,
SecureFile LOBs
Syntaxbeispiele:
-- Feld einer Tabelle
alter table test_tab modify (t encrypt no salt);
Copyright 2010 by IF DV GmbH
-- kompletter Tablespace
CREATE TABLESPACE geheim
DATAFILE '/u01/app/oracle/oradata/jf11/geheim01.dbf' SIZE 512M
ENCRYPTION USING 'AES256' DEFAULT STORAGE(ENCRYPT);ORACLE SECURITY
6-8 Datenspeicherung und –sicherung
Welche Informationen sind verschlüsselt?
SQL> SELECT owner, table_name, column_name, encryption_alg, salt
2 FROM dba_encrypted_columns
3 ORDER BY owner, table_name, column_name;
OWNER TABLE_NAME COLUMN_NAME ENCRYPTION_ALG SAL
---------------------------------------------------------------------------
TCRA TEST_TAB T AES 192 bits key NO
SELECT tablespace_name, encrypted FROM dba_tablespaces;
TABLESPACE_NAME ENCRYPTED
-------------------------
SYSTEM NO
SYSAUX NO
G m b H
UNDOTBS1 NO
TEMP NO
DATA_2008 NO
D V
DATA_2009 NO
I F
GEHEIM YES
Ein komplettes Beispiel:
-- 1. Zugriff auf Dateninhalte ohne SQL, d.h. außerhalb der DB ...
-- siehe auch Unterkapitel "Datafiles"
-- Login als Benutzer TCRA
create table test_tab(i number, t varchar2(50));
insert into test_tab values(42, 'zweiundvierzig');
insert into test_tab values(17, 'siebzehn');
commit;
Copyright 2010 by ID DV GmbH
SQL> SELECT * from TEST_TAB;
I T
---------- --------------------------------------
42 zweiundvierzig
17 siebzehn
-- Speicherort der Tabelle TEST_TAB suchen (als privilegierter Benutzer)
select file_id, block_id, d.blocks, value, substr(f.name,1,45) file_name
from dba_extents d, v$datafile f, sys.ts$ t, v$parameter p
where owner = 'TCRA' and segment_name = 'TEST_TAB' and segment_type = 'TABLE'
and d.file_id = f.file# and d.tablespace_name = t.name and p.name =ORACLE SECURITY
Datenspeicherung und –sicherung 6-9
db_block_size'
order by file_id, block_id;
FILE_ID BLOCK_ID BLOCKS VALUE FILE_NAME
---------------------------------------------------------------
15 36817 16 4096 D:/oracle/oradata/JF10/USERS02.DBF
-- beliebiger Hex-Editor auf BS-Ebene liefert dann sowas ...
G m b H
D V
I F
-- 2. Jetzt aber hurtig verschlüsseln (transparent für jede Applikation)
-- a. Voraussetzungen:
-- Oracle V10.2 EE (Parameter COMPATIBLE >= 10.2.0), ASO Option
-- b. Eintrag in SQLNET.ORA, um einen Speicherort für externe Schlüssel fest
-- zulegen & Listener durchstarten
ENCRYPTION_WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
Copyright 2010 by IF DV GmbH
(DIRECTORY = c:/oracle/product/10.2.0/admin/JF10/wallet)
)
)
-- c. jetzt in SQL*PLUS den Master Key setzen (als SYS)
-- dadurch wird eine Datei namens ewallet.p12 im Wallet-Verzeichnis erzeugt
alter system set encryption key identified by "TDS_IRF_4711";
-- d. nun kann die Tabellendefinition auf transp. Verschlüsselung gesetzt
-- werden (Zusatz no salt ist nötig, damit
-- verschlüsselte Spalten indiziert werden können) …ORACLE SECURITY
6-10 Datenspeicherung und –sicherung
alter table test_tab modify (t encrypt no salt);
-- e. Zugriff nur noch mit geöffneter 'Geheimbörse'
-- (die DBF-Datei enthält übrigens auch keine unverschl. Spalte T mehr):
SQL> select * from test_tab;
I T
---------------------------------
12345678 zweiundvierzig
12345678 siebzehn
-- nach Schließen derselben ist kein Zugriff auf die TDS-Spalte möglich …
SQL> ALTER SYSTEM SET ENCRYPTION WALLET CLOSE;
System wurde geändert.
G m b H
SQL> select * from test_tab;
select * from test_tab
D V
*
I F
FEHLER in Zeile 1:
ORA-28365: Wallet ist nicht geöffnet
SQL> select i from test_tab;
I
----------
12345678
12345678
SQL> ALTER SYSTEM SET ENCRYPTION WALLET open identified by "TDS_IRF_4711";
System wurde geändert.
SQL> select * from test_tab;
I T
Copyright 2010 by ID DV GmbH
------------------------------------------------------------
12345678 zweiundvierzig
12345678 siebzehn
-- Verschlüsselungsalgorithmus verschärfen
alter table test_tab rekey using 'AES256';
-- schaltet man die Verschlüsselung ab, geht's natürlich auch ohne Börse …
SQL> alter table test_tab modify (t decrypt);
Tabelle wurde geändert.ORACLE SECURITY
Sichere Oracle-Instanz 7-1
7
G m b H
Sichere Oracle-Instanz
D V
I F
Copyright 2010 by IF DV GmbHORACLE SECURITY
7-2 Sichere Oracle-Instanz
Konfiguration (s)pfile
Im Rahmen dieser Unterlage traten bereits eine ganze Reihe von Sys-
temparametern in Erscheinung, die direkt mit dem Datenschutz in Zu-
sammenhang stehen. Prüfen Sie Ihre Datenbanken diesbezüglich durch
Lesen der init.ora oder direkt über die Tabelle V$PARAMETER bzw.
V$SPPARAMETER:
o7_dictionary_accessibility (FALSE, um unerwünschte Zugriffe auf
Systemtabellen zu verhindern)
remote_login_passwordfile (aktiviert/deaktiviert Fernsteuerung
sensibler DB-Zugriffe wie Hoch- und Runterfahren)
remote_os_authent (s. Kapitel 4: BS-authentifizierte Benutzer)
G m b H
remote_os_roles (s. Kapitel 4: BS-authentifizierte Benutzer)
audit_trail (s. Kapitel 4)
D V
I F
audit_file_dest (s. Kapitel 4)
audit_sys_operations (s. Kapitel 4)
Anmerkung: Bitte vergessen Sie nicht, welche weiteren hochsensiblen Parameter/Informationen in Dateien wie
SQLNET.ORA, LISTENER.ORA und TNSNAMES.ORA stecken!
Copyright 2010 by ID DV GmbHORACLE SECURITY
Sichere Oracle-Instanz 7-5
Das Skript hr_drop.sql in $ORACLE_HOME/demo/schema/human_
resources löscht z.B. den Benutzer HR und seine Objekte.
Fragen zu den von Oracle installierten Benutzern und deren Pass-
wörtern etc., haben wir ja bereits im Kapitel 2: "Standardbenutzer" be-
handelt.
G m b H
D V
I F
Copyright 2010 by IF DV GmbHORACLE SECURITY
7-6 Sichere Oracle-Instanz
Oracle Binaries
Oracle wird mit einer Reihe binärer Dateien ausgeliefert. Sie liegen
(fast alle) im Verzeichnis bin, unterhalb des Oracle-Home-
Verzeichnisses. Am bekanntesten dürfte oracle (bzw. Oracle.exe unter
Windows) sein, aber natürlich sind so berühmte Vertreter wie dbv,
imp/impdp, exp/expdp, lsnrctl, sqlldr, tkprof oder wrap auch dabei.
Das Prüfen der Dateizugriffsrechte gehört zum DBA-Arbeitsplan "Pro-
ject_Lockdown" Phase 1-2 (siehe Kapitel 10: "Checklisten" dieser Unter-
lage)
G m b H
Im bin-Verzeichnis finden Sie ggfs. eine weitere Gruppe von Dateien mit
der Endung oracleO bzw. Ouiback (Windows); diese sind Sicherungen
D V
der Binärdateien als Überbleibsel eines Updates.
I F
Alle diese Dateien werden häufig ausgeführt; die Berechtigung hierfür
ist klar geregelt:
Besitzverhältnisse der Datei
Dateizugriffsrechte (für den Besitzer bzw. der Gruppe unter Besitzer-
rechten)
Durch Veränderung dieser Dateien kann der geneigte Hacker jede Soft-
Copyright 2010 by ID DV GmbH
warereaktion erzielen die er gern möchte. Übrigens ist der Binärcode
gar nicht so unübersichtlich, wie man meint; wesentliche Teile des Auf-
baus sind in "Fachkreisen" bekannt und wer diesbezüglich zu den An-
fängern gehört, kann mit Freeware-Tools (z.B. LookingGlass von Errata
Security) recht schnell einige typische Schwachstellen herausfinden und
ausnutzen.
Anmerkung: LookingGlass findet im OracleHome einer V11.1.0.6 sagenhafte 518 Dateien mit sicherheitsgefährdenden
Funktionen!ORACLE SECURITY
IT-Schwachstelle Mensch (Social Engineering – ein Einblick)9-9
Typische falsche Identitäten
Der Angreifer gibt sich gern aus …
als Kollege der sich ganz schnell eine Datei, ein E-Mail oder ein Fax zu-
senden lassen muss
als Vorgesetzter (auch z.B. einer anderen Niederlassung), der jetzt am
Hauptfirmensitz ist, aber Hilfe braucht, um auf sein E-Mail zugreifen zu
können
als Mitarbeiter eines Kunden des Unternehmens (der z.B. sein Passwort
vergessen hat oder der in Vertretung eines anderen Kollegen ganz
schnell noch die Verkaufszahlen des letzten Jahres oder die aktuellen
Preise braucht)
als Mitarbeiter eines Service-Unternehmens
G m b H
als Journalist/Autor
oder als Mitarbeiter eines Umfrage-Instituts.
D V
I F
Wie machen sich Angreifer menschliche Verhaltensweisen zu-
nutze?
Autorität (Helpdesk braucht dringend ..., Sekretärin des Oberhäupt-
ling benötigt unbedingt , wichtiger&wütender Geschäftspartner will
sofort ..)
Copyright 2010 by IF DV GmbH
Zuneigung/Hilfsbereitschaft (neuer hilfloser Kollege aus Abt. X bittet
um ..)
Revanche (vermeintlicher Kollege hat einen Gefallen getan, da kann
man/frau doch jetzt nicht unhöflich sein ..)
Konsequenz/Leichtgläubigkeit/Neugier (Öffnen von E-Mails zweifel-
haften Inhalts/Absenders, Ausplaudern von Firmendetails an Perso-
nen unklarer Herkunft)ORACLE SECURITY
9-10IT-Schwachstelle Mensch (Social Engineering – ein Einblick)
Unsicherheit/soziale Bestätigung/Eitelkeit (Journalist schreibt Bericht
über kreative Mitarbeiter/Unternehmer)
Gier/Mangel (vermeintlich reiche Person sucht Geldanlage)
Bequemlichkeit (PW nicht regelmäßig neu setzen, Login während ei-
ner Abwesenheit nicht sperren …)
Erpressung/Bestechung (welche "Leiche" liegt bei Ihnen im Keller ;-)
...)
FUNDAMENTALE SCHUTZMASSNAHMEN
G m b H
Es gibt grundlegende Praktiken, die vor Social Engineering schützen
können:
D V
I F
Schulung aller betroffenen Mitarbeiter in regelmäßigen Abständen mit
Hinweisen zur Sicherheitssensibilisierung
Poster, Aufkleber, Warnhinweise
Authorisierungen möglichst gering halten und die Leute mit
Authorisierung besonders intensiv schulen
Alte Dateien, Papiere, Festplatten und sensible Dokumente schreddern
Keine Standardisierung von UserAccounts bspw. Logins, Passwörter
und Anmeldungen mittels Perlscripten etc.
Versuchen keine sensiblen Daten an die Öffentlichkeit dringen zu
lassen, zum Beispiel durch Einträge in Telefonbücher, Broschüren..
…
Copyright 2010 by ID DV GmbHSie können auch lesen
