Firewall Handbuch für LINUX 2.0 und 2.2 - zurück

aus Sicherheitsgründen ablaufen. Es dürfte wohl jedem klar sein, daß wenn
die User häufiger aufgefordert werden, das Paßwort zu ändern, nach relativ
kurzer Zeit die Paßworte recht einfach zu erraten sein werden.
10. Einbruch in die Datenbank durch unsichere Clients ist ein komplexeres
Thema welches ich durch ein einfaches Beispiel erhellen möchte. In meinem
Handbuch zu MySQL ist diese Problematik näher erklärt. Es gibt unter
MySQL die Befehle LOAD DATA INFILE und LOAD DATA INTO OUTFILE.
Diese Laden eine ASCII Tabelle von der Festplatte des Servers in den
Datenbankserver und wieder herunter. Solange die Daten also nur auf der
Festplatte des (angenommen) gesicherten Servers lagern, gibt es keine
Probleme. Der Zusatz LOCAL also LOAD DATA LOCAL INFILE hat eine
geringfügig andere Bedeutung. Die Daten werden zwischen der Festplatte der
Arbeitsstation und dem Datenbankserver über das Netzwerk im Klartext
übertragen. Im günstigsten Falle sorgt der Befehl COMPRESS dafür, daß die
Daten komprimiert übertragen werden. Dies ist ein Feature, welches von
jedem ODBC - Treiber unterstützt wird, allerdings haben nur wenige eine
Verschlüsselung der Daten vorgesehen. Schlußfolgerung ist, daß man Clients
an Datenbanken nur über IPSec (PPTP, ENSkip, OPIE....) an den
Datenbankserver anschließen sollte.
11. Einbruch in die Datenbank durch unklare Zugriffsrechte ist ebenfalls ein
recht häufiges Problem. Mit Hilfe unklarer GRANT Tabellen kann es
passieren, daß vergessen wurde, die Zugriffsbeschränkungen korrekt zu
setzen. Ein ganz wichtiger Punkt bei der Erstellung der Security Policy.
12. Einbruch in die Datenbank durch Replikations-Server ist recht selten. Es
ist aber von Interesse, wie Transaktionen und die Replikationsmechanismen
genau ablaufen.
13. Einbruch in die Datenbank durch trojanische Pferde (ODBC, ACCESS).
Unsichere Clients (siehe oben) sind der Hauptgrund für erfolgreiche
Einbrüche in Datenbanken. Wer sich einmal die Makroviren MELISSA & Co
genau anschaut, der wird feststellen, daß hiermit auch Makro´s für ACCESS
gestartet werden können. Ein Makro in einer E-Mail kann somit die
Datenbank mit LOAD DATA LOCAL INTO OUTFILE (Siehe Handbuch
MySQL) ins Internet versenden. Microsoft nennt es Feature, andere nennen
es eine Katastrophe.
14. Einbruch in den Datenbankserver über andere Sicherheitslücken. Für
Datenbanken muß im Prinzip das selbe gelten, wie für Firewalls. Keine
anderen Dienste auf dem Server !
15. Ausspähen der Daten bei der Übertragung über das Netzwerk
(ACCESS). Wer das typische Man In The Middle (MITM) Problem kennt, der
kann sich vorstellen, daß man mit einem Sniffer am Netzwerkstrang im Laufe
der Zeit fast alle Einträge in der Datenbank passieren sehen kann.........
16. Zugriff mit gespoofter IP nach der Paßwort-Authentifizierung ist ein recht
häufiges Problem. Es wird "session stealing/hijacking" genannt. Ein User
authentifiziert sich an der Datenbank, tätigt Abfragen. Ein benachbarter Host
kontaktiert sich mit gespoofter IP - Nummer an diesen Host und tätigt seine
eigenen Abfragen, ohne jedoch nocheinmal authentifizieren zu müssen.
Einfacher geht´s kaum noch. Wer sich die einfachen Beispiele in "C" vom
PHRACK Magazin einmal genau anschaut, der wird feststellen, daß diese
auch für andere Dinge geeignet sind. Starke Authentifizierung an dem
Datenbankserver und eine verschlüsselte Übertragung mit z.B. PPTP (die
Experten werden mich hoffentlich nicht schlagen!), welches zumindest
sicherer geworden ist, sollte obligatorisch sein.
Um mit einem SQL Proxy eine Datenbank sicher an das Internet anzubinden, sind
spezielle Filter unumgänglich. In diesen werden anhand einer Positivliste nur diejenigen
Befehle zugelassen, die für den Betrieb minimal notwendig sind. Die übergebenen
Erstellt von Doc Gonzo - http://kickme.to/plugins