Online Suche im Handbuch

LITTLE-IDIOT NETWORKING

26.3 Helfen SQL Proxy´s ?

SQL Proxy's in Firewalls werden im allgemeinen nur dort eingesetzt, wo Datenbanken für Warenwirtschaftssysteme oder EDI Systeme an das Internet angebunden werden müssen. Leider muß man sagen, daß hier kaum jemand wirklich die Gefahren kennt. Viele Firewallhersteller begnügen sich einfach damit, den TELNET PROXY auf den Port z.B. 1521 des ORACLE Servers zu installieren, der dann als "dedicated server" konfiguriert sein muß. In diesem Falle wird nur der Port 1521 verwendet und Ports >1024 kommen nicht zur Anwendung. Dies kann dann interessant sein, wenn man z.B. einen SAP/R3 oder anderen Kommunikationsserver vor den eigentlichen Datenbankserver geschaltet hat. Ohne ein sogenanntes Port-Sharing mit dynamischen Ports bleibt dann natütlich die Zahl der simultanen Clients auf einen begrenzt. Mit aktiviertem Port-Sharing, also beim Einsatz von ORACLE als "multi threaded" Server, der vielen Clients gleichzeitig Rede und Antwort steht, müssen nämlich in der Firewall alle Ports > 1024 für den Zugriff auf den SQL Server geöffnet werden. Dies muß aus diesem Grund geschehen, da es ja nicht der SQL-Server ist, der die Verbindungen zum Client anfordert, sondern es die Clients sind, die die Ports > 1024 anfordern. Es bleibt also allein für Firewalls die Aufgabe, die IP - Nummern der Clients zu selektieren, also nur auf Cirquit-Level den Zugriff auf den Datenbank-Server einschränken. Für MySQL ab Version 3.20 gilt Port 3333, für die älteren Versionen der Port 3306.

Welches sind die Gefahren, die einer Datenbank drohen ? Hier kann man mehrere aufzählen:

1. Denial of Service durch zu zuviele Abfragen/Sekunde
2. Denial of Service durch zu komplexe Abfragen
3. Denial of Service durch fehlerhafte Statements
4. Denial of Service durch zu lange Ausgabe-Ergebnisse
5. Denial of Service durch Parameter mit Überlänge
6. Denial of Service durch "buffer overflow"
7. Einbruch in die Datenbank durch Ersniffen der Paßworte über das Netzwerk
8. Einbruch durch Fehler in der Konfiguration des Authntifizierungsmechanismus
9. Einbruch über den PDC/BDC im Falle von Microsoft Netzwerken
10. Einbruch über andere unsichere Dienste
11. Einbruch durch Erraten der Paßworte "dictionary attacks"
12. Einbruch durch unsichere Clients
13. Einbruch durch unklare Zugriffsrechte
14. Einbruch durch Replikations-Server von ACCESS
15. Einbruch durch trojanische Pferde (ODBC, ACCESS)
16. Einbruch in den ODBC Treiber (Microsoft Windows NT)
17. Einbruch über andere Sicherheitslücken
18. Ausspähen der Daten bei der Übertragung über das Netzwerk (ACCESS)
19. Zugriff mit gespoofter IP nach der Paßwort-Authentifizierung

Die Probleme sind hier unterschiedlicher Natur und von System zu System verschieden. Hier weitere Erläuterungen zu den obigen Punkten:

1. Denial of Service durch zu viele Abfragen pro Sekunde treten häufig bei Internet Datenbanken auf. Datenbanken sind recht schnell, wenn keine Schreibzugriffe stattfinden, das weit größere Problem sind aber die Interfaces, allen voran CGI-BIN´s oder ASP´s für die Ausgabe auf WWW-Browser. Eine besonderes Problem tritt z.B. bei dem IIS-Server unter Windows NT 4.0 auf, der bei der Eingabe von "https" anstelle von "http" durch die CPU - fressende Verschlüsselung bei vielen simultanen Abfragen schnell zum Erliegen kommt.
2. Denial of Service durch zu komplexe Abfragen tritt relativ häufig auf. Wer schon einmal in den großen Suchmaschinen nach Begriffen gesucht hat, die garantiert nicht enthalten sind, wird feststellen, daß die Suchanfrage viel Länger dauert, als wenn ein gängiger Begriff recherchiert werden soll. Wenn mehrere dieser Begriffe noch durch ODER verknüpft werden, dann kann es passieren, daß die Datenbank schon mit einer Anfrage Minuten beschäftigt ist.
3. Denial of Service durch fehlerhafte Statements ist weit komplexer, als man vielleicht ahnen kann. Hinter jeder Datenbank stecken recht viele Möglichkeiten, Befehle miteinander zu kombinieren. Bei SQL Datenbanken sind die Möglichkeiten so vielfältig, daß man durchaus duch geschickte INDIZIERUNG bestimmter Fehler das tausend oder millionenfache an 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 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 Parameterlängen für die Befehle müssen dann nochmals in der Länge beschränkt werden, was nur dann möglich ist, wenn man die Inhalte der Datenbank bzw. der Felder genau kennt. Da sich auch unter SQL mehrere Befehle kombinieren lassen, muß auch deren Kombinationsmöglichkeit stark eingeschränkt werden. Zum Schluß ist es wichtig, zu verhindern, daß Angreifer über andere Ports in die Maschine einbrechen und die komplette Datenbank mit Hilfe von anderen Protokollen über die Firewall kopieren. Es muß also zum Schutz der SQL Datenbanken die Firewall noch gegen sog. insider attacks gesichert werden. Dies bedeutet in der Praxis, daß auf der Firewall neben der SQL Datenbank keine anderen Funktionen aktiviert sein dürfen, und daß die Firewall sofort Alarm meldet, wenn jemand versucht, z.B. eine FTP Verbindung von innen heraus zu öffnen. Im Grunde muß also eine Firewall, die eine SQL Datenbank sichern soll, gegen Angreifer von außen und innen schützen. Ein PROXY, der Inhalte filtern kann, ist bei ORACLE erhältlich. PERL Skripte tun's im Prinzip aber auch. Man findet auf http://www.perl.org/CPAN/ einige Hinweise auf Filter.

Es gibt aber noch einige Probleme mit den neuen JDBC-Treibern von ORACLE 8i. Der JDBC Thin Driver ist ein Klasse 4 Treiber, und erfordert folgende Besonderheit, hier ein Zitat von ORACLE:

In Netscape 4.0 this involves signing your applet, then opening your
connection as follows. Please refer to your browser documentation for the
many details you have to take care of. 

netscape.security.PrivilegeManager.enablePrivilege
             ("UniversalConnect"); 
connection = DriverManager.getConnection
             ("jdbc:oracle:thin:scott/tiger@dlsun511:1721:orcl"); 

Firewall Considerations
The JDBC Thin driver cannot connect to a database from behind a firewall.
The firewall prevents the browser from opening a TCP/IP socket to the
database. 

This problem can be solved by using a Net8 compliant firewall and using
connect strings in the applet that are compliant with the firewall
configuration. This solution really only works for an intranet, because the
connect string is dependent on the firewall behind which the client browser
is running. 

"When the IP port number of the SQL*Net connection can be determined in advance, such as 1521, then connection can be permitted with some degree of security. Systems running multi-threaded servers, pre-spawned servers, or ones with architectures that do not support IP port sharing, require dynamic port allocation which tends to prevent connections. Firewall support where IP port redirection is employed requires an intelligent filter to monitor the port redirection information during the connect phase so that the filter can selectively open up the required port. Alternatively, a wide range of ports would have to be opened in advance, which would severely compromise security. In an application proxy solution the proxy itself handles IP port redirection issues."

1. Multi-Threaded Server (MTS) and pre-spawned servers always use dynamic port numbers.
2. "Dedicated Server" may either use 1. single port number say 1521 ; or 2.dynamic port numbers. Wherever possible, the first option is taken. It is the operating system and TCP/IP protocol implementation that determines which option is taken, not the version of Oracle or SQL*Net.
3. Oracle is producing (i.e. not available yet (March 1996)) a SQL*Net proxy which Oracle encourage FW vendors to integrate into their products. The proxy is based on the Oracle Multi-Protocol Interchange (MPI) and will support SQL*Net V2 only.

Therefore, my observation is that:

1. There is no satisfactory solution for allowing SQL*Net traffic through FW if Oracle is configured as MTS or pre-spawned servers. No application proxy at present handle this. Gary Flynn quoted the White Paper "In an application proxy solution the proxy itself handles IP port redirection issues." is only a requirement that FW vendors need to work on. This product doesn't exist at this moment.
2. There is no mention in the White Paper as to what OS and what TCP/IP implementation will cause a Dedicated Server to use dynamic port numbers. The limitation seems to be applicable to those that "do not support IP port sharing".
3. My preliminary (very preliminary) testing using Oracle 7 on HP-UX 9.x using SQL*Net v1 and Solaris 2.4 using both SQL*Net v1 and v2 revealed that a fixed port number on the server is used. The client port number is random but is constant for that specific session. In such a case, it is possible to apply simple filtering rules on screening routers or use such things as plug-gw. There is no need for setting up a server to server interchange. I can add that Oracle 7.1 on AIX 3.2.5 and Oracle 7.3 on Solaris 2.5 reveal the same behaviour, i.e. simple filtering rules on screening routers or such things as plug-gw from TIS's Firewall Toolkit may be used. However, Oracle 7.3 on Windows NT does not work this way.

Hiermit wäre im Prinzip alles gesagt, da sich an dem Prinzip von TCP/IP seit mehreren Jahren prinzipiell nichts mehr getan hat. Wer dennoch einen erhöhten Sicherheitsbedarf hat, der sollte mit PPTP oder mit dem guten, alten IPX mit RC4 - Verschlüsselung seine Daten transportieren. Schon seit vielen Jahren kann NOVELL jeden Datenverkehr verschlüsseln und auch über verschiedene Interfaces filtern.

Online Suche im Handbuch

LITTLE-IDIOT NETWORKING