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

Geschwindigkeit herausholen kann (Siehe Skript MySQL - Tuning). Alle
Parser haben bestimmte Schwächen bei der Interpretation von Statements.
Wer sich ein wenig mit C++ beschäftigt hat, der wird bemerkt haben, daß
verschiedene Compiler bestimmte Statements unterschiedlich interpretieren.
Durch eine gründliche Analyse der Datenbank kommt man nach einiger Zeit
auf Varianten, die eventuell noch nicht im Filter implementiert wurden.
4. Denial of Service durch zu lange Ausgabe-Ergebnisse trifft immer dann
zu, wenn jemand z.B. nach dem Buchstaben "%a%" (SQL) suchen läßt. In
vielen Fällen ist die Eingabemaske in ihren Möglichkeiten schon
eingeschränkt (Siehe WWW-Interfaces). Wer sich die komplexe Struktur der
übergebenen Parameter anschaut, der kann oft bei Suchmaschinen
feststellen, daß die max. Zahl der Ausgaben in dem HTML Code steckt. Man
kopiert sich die HTML-Seite auf die Arbeitsstation, ändert die Ausgabe auf ein
paar Millionen und schon hat man die Suchmaschine überlastet.
5. Denial of Service durch Patermeter mit Überlänge ist ein ähnlicher
Versuch, die Datenbank zur Verzweiflung zu bringen. Im Falle des IIS 2.0 und
3.0 konnte man durch Angabe einer URL mit vielen tausend Buchstaben
Länge den Server zum Absturz bewegen. Microsofts Lösung war so einfach
wie unwirksam - sie begrenzten einfach die URL Länge im IE 4.0, unter
Netscape funktionierte der DoS Angriff noch viel länger. Große
Datenbankanbieter, die z.B. hinter Computermagazinen (Computerwoche)
steckten, hatten lange mit diesem Problem zu kämpfen.
6. Denial of Service durch "buffer overflow" ist ähnlich dem obigen Versuch,
jedoch versucht ein Angreifer hier, zuerst komplexe Abfragen zu konstruieren,
um dann den einen oder anderen Parameter mit Überlangen
Buchstaben/Zeichen zu überladen. Auch komplexe Filter haben
Schwierigkeiten hiermit. Das Resultat ist - Absturz des Datenbankservers.
7. Einbruch in die Datenbank durch Ersniffen der Paßworte über das
Netzwerk ist insbesondere bei ACCESS recht einfach. Im Internet gibt es
viele Beispiele, die zeigen, wie man die Paßwortabfrage einer ACCESS
Datenbank umgehen kann, bzw. wie man die Authentifizierungmechanismen
von ACCESS (.mdw) überwindet. Da häufig ACCESS am zentralen MS SQL
Server angebunden ist, erfolgen die häufigsten Einbrüche in SQL
Datenbanken über ACCESS. Die Übertragung von unverschlüsselten
Paßworten ist noch ein recht verbreitetes Problem bei Microsoft Netzwerken.
Auch der ODBC Treiber bei Microsoft NT Servern hat zahlreiche
Sicherheitslücken. Mit einem Makrovirus in irgendeiner
EXCEL/WINWORD/ACCESS Datei läßt sich der ODBC Treiber auf z.B.
einem NT Server knacken. Damit hat dieses Makro häufig vollen Zugriff auf
die Inhalte der SQL Datenbank, da sich kaum ein Systemadministrator
Gedanken über die internen Rechte am SQL Server macht.
8. Einbruch in die Datenbank über den PDC/BDC im Falle von Microsoft
Netzwerken Nachdem Microsoft etliche Service-Packs herausgebracht hat,
die angeblich verschlüsselte Paßworte einführen, muß man dann feststellen,
daß sich die PDC/BDC´s untereinander mit dem Paßwort "anonymous"
legitimieren. Dazu benutzen diese noch das RPC Protokoll, welches sich
kaum über Firewalls absichern läßt. Wer also Directory Services
implementiert hat, der muß sich darüber im klaren sein, daß ein Paßwort
gleich für verschiedenste Dienste im Microsoft-Netzwerk gültig ist (SQL
Datenbank - Fileserver - Email?) Wer weiß genau, welches Paßwort nach der
Installation welches Service Packs noch für andere Dienste gültig ist ? Ich
selber habe versucht, die Sicherheitsmechanismen von Windows NT zu
verstehen - und nach einigen offensichtlichen Lügen von Microsoft
aufgegeben....
9. Einbruch in die Datenbank über Erraten der Paßworte, Stichwort
"dictionary attacks" ist ein beliebtes Ziel, zumal in vielen Firmen die Paßworte
Erstellt von Doc Gonzo - http://kickme.to/plugins