SQL-Filter gesucht (erlaube nur SELECT, kein INSERT/DELETE/UPDATE)

[mbab72]

Hallo

Ich suche eine SQL-Filter-Anwendung (oder auch -Appliance), und zwar zum Einsatz in folgenden Szenario:

- Ein Server SRV1 steht im Internet (Zugriff auf Port 80), auf diesem Server läuft eine Anwendung ANW1, die mit Datenbanken reden soll.

- Diese Datenbanken (mehrere Datenbankserver mit jew. mehreren Datenbanken) stehen in einem anderen Netzwerksegment, Zugriff erfolgt auf Port 1521.

Nun gilt es, das abzusichern und zwar speziell Datenveränderung / -löschung zu vermeiden. Zuviel Lesen ist erstmal schadlos.

Datenveränderung / -löschung könnte ja durch Kapern des Webservers versucht werden.

Dazu sollen also die SQL-Statements geprüft werden, INSERT/DELETE/UPDATE soll kommentarlos entfernt werden.

Die Oracle Firewall kann reines Whitelisting, das ist aufwändig zu pflegen, einfach weil die Anwendung ANW1 so flexibel ist. (abgesehen von den Kosten der Oracle Firewall)

Die Datenbanken können nicht gespiegelt werden (Multi-TB), auch readonly-mounten geht kaum, weil die Daten dauernd aktualisiert werden.

Im Fall von Webtraffic könnte man mit Apache einen ReverseProxy (RewriteCond / RewriteRule) bauen, wie geht das mit SQL-Statements?

Ciao

[flashpixx]

Erlaube dem User , der connected, einfach keine Veränderung auf Feld- & Tabellenebene, alles andere ist Frickelwerk.

[mbab72]

Ja, die bisher konfigurierten Datenbank-verbindungen haben solche User hinterlegt, ein bösartiger Mensch der den Webserver kapert, _muss_ diese Nutzer aber nicht verwenden, oder?

Es geht um eine "zusätzliche" Ebene, die Cheffchen (und manchen SysAdmin) ruhiger schlafen lässt. Mehrere TB will niemand gern von Bändern einspielen, schon gar nicht mit irgendwelchen Cheffen im Nacken, die meist "nicht soviel Ahnung" von EDV haben.

[dr.dimitri]

Woher sollte der die Anmeldungen für entsprechend berechtigte User haben? Ihr habt die ja vermutlich nicht alle im Klartext auf dem server liegen oder?

[mbab72]

Der mögliche Angreifer könnte ja einen Netzwerksniffer installieren und so an Username und Passwort kommen, egal in welchen Format die auf dem Anwendungsserver hinterlegt sind.

Privilege Elevation gibts doch auch im Datenbank-Umfeld oder? Ich bin halt eher Systemer.

Eine _zentrale_ Stelle zum Filtern kann auch das Leben erleichtern, wenn nicht alle Datenbankserver top-aktuell gepatcht sind (z.B. weil die Fachseite das noch nicht abgenickt hat) und man eben "Privilege Elevation"-verdächtige Statements gar nicht erst durchreichen will.

[flashpixx]

Man kann nicht nur aufgrund von Logindaten beschränken, sondern auch von Hostdaten, d.h. Änderungen der Daten sind von bestimmten Hosts verboten.

Was bringt denn bitte ein solcher Schutz !? Du kannst z.B. ein Insert Statement innerhalb einer Stored Procedure so gar nicht abfangen, denn die SP wird innerhalb der Datenbank aufgerufen, d.h. Dein Filter würde da gar nicht greifen.

Weiterhin sollte die Kommunikation zwischen Anwendung und Datenbank verschlüsselt ablaufen, d.h. Dein Filter kann gar nicht die Statements filtern, da die Daten verschlüsselt übertragen werden, das was da nur hilft wäre eine Man-in-the-Middle Attacke, aber das möchtest Du sicherlich nicht.

Mach ein entsprechendes Host & Userkonzept, um zu entscheiden welche User von welchem Host entsprechende Zugriffe brauchen. Authentifiziere die User passend an der Anwendung, so dass die Anwendung mit dem spezifischen Useraccount auf der Datenbank arbeitet, vergib anständige Passwörter oder Zertifikate, sichere die Verbindung zwischen Anwendung und Datenbank per SSL ab, sichere die Anwendung gegen SQL Injections ab.

Das Filtern von SQL Statements muss entweder dort geschehen, wo sie generiert werden, d.h. in der Anwendung oder eben durch entsprechende Rechte verboten / erlaubt werden, was dann auf Datenbankebene geschieht. Das was Du da machen willst, ist absolut fahrlässig, denn wenn ich z.B. ein codiertes SQL Statement in die Verbindung einschleusen kann, wird dein Filter ebenfalls nicht greifen. Die Anwendung (wobei Anwendung hier auch eine mehrschichtige Architektur sein kann, Frontend, Applicationserver, Datenbankserver) & die Datenbank sind die zwei Punkte, an denen man absichern muss, alles andere zeugt eigentlich davon, dass man sowohl auf Anwendungs- wie auf Datenbankseite keine ordentliche Absicherung hat

Bearbeitet 23. November 2012 von flashpixx

[dr.dimitri]

Der mögliche Angreifer könnte ja einen Netzwerksniffer installieren und so an Username und Passwort kommen, egal in welchen Format die auf dem Anwendungsserver hinterlegt sind.

Also. Dein Angreifer hat Zugriff auf Dein Netzwerk und kann dort seelenruhig den Netzwerkverkehr untersuchen? Warum sollte er sich die Mühe machen diese ganzen Umwege zu gehen? Ich hol mir die Accounts von einem Sysadmin für einen der DB-Server und dann reicht ein sqlplus / as sysdba und das wars. Da geb ich mich doch nicht mit normalen Useraccounts ab.

Dim

[mbab72]

Ich hol mir die Accounts von einem Sysadmin für einen der DB-Server und dann reicht ein sqlplus / as sysdba und das wars. Da geb ich mich doch nicht mit normalen Useraccounts ab.

Genau DAS meinte ich in Beitrag #3 als ich schrieb "ein bösartiger Mensch der den Webserver kapert, _muss_ diese Nutzer aber nicht verwenden, oder?"

[dr.dimitri]

Genau DAS meinte ich in Beitrag #3 als ich schrieb "ein bösartiger Mensch der den Webserver kapert, _muss_ diese Nutzer aber nicht verwenden, oder?"

Richtig, aber da hilft dir auch keine Filterung vom webserver zur Datenbank, wenn ich mir einfach den sys Account für die DB selbst beschaffe. Da kannst Du DMLs filtern bis Du schwarz wirst

Im übrigend: Wieso besteht Panik vor dem Verändern der Daten? Mindestens genauso schlimm kann auch Datendiebstahl sein. Den läßt Du bei deinen bisherigen Szenarien aber ausser acht.

Flashpixx hat ja schon gute Ansätze genannt das zu verhindern.

Dim

[mbab72]

Richtig, aber da hilft dir auch keine Filterung vom webserver zur Datenbank, wenn ich mir einfach den sys Account für die DB selbst beschaffe. Da kannst Du DMLs filtern bis Du schwarz wirst

Das verstehe ich nicht. Wenn da ein "SQL reverse proxy" auf der einzigen Strecke zur Datenbank eben kein "drop table" (z.B.) durchreicht, wie soll dann Schaden entstehen?

Ein Apache-basierter reverse proxy (für einen Webserver) kann ja einfach sagen dass Anfragen nach "/Nacktbilder_vom_Vorstand.jpg" einfach nach 404.html umgeleitet werden.

Im übrigend: Wieso besteht Panik vor dem Verändern der Daten? Mindestens genauso schlimm kann auch Datendiebstahl sein. Den läßt Du bei deinen bisherigen Szenarien aber ausser acht.

In Beitrag #1 schrieb ich "Zuviel Lesen ist erstmal schadlos.", die Daten _sind_ für Veröffentlichung freigegeben. Das ist die Entscheidung der Fachseite. Wer bin ich, dass ich daran rüttle?

Bearbeitet 23. November 2012 von mbab72

[dr.dimitri]

Das verstehe ich nicht. Wenn da ein "SQL reverse proxy" auf der einzigen Strecke zur Datenbank eben kein "drop table" (z.B.) durchreicht, wie soll dann Schaden entstehen?

Ein Apache-basierter reverse proxy (für einen Webserver) kann ja einfach sagen dass Anfragen nach "/Nacktbilder_vom_Vorstand.jpg" einfach nach 404.html umgeleitet werden.

Ich bin aber schon längst nicht mehr auf dem Webserver. Der Apache interessiert mich nicht. Ich bin lokal auf dem Datenbankserver, Mitglied der ORADBA Gruppe und kann mich damit ohne Passwort als SYS an die Datenbank anmelden.

Wenn Du also befürchtest, dass jemand den unverschlüsselten Netzwerkverkehr innerhalb eures Netzes ausließt, dann schafft er es auch früher oder später sich das Passwort für einen root oder root ähnlichen Account für den Server seiner Wahl zu besorgen.

Aus diesem Grund muss das eben verhindert werden.

Dim

[flashpixx]

Wenn Du also befürchtest, dass jemand den unverschlüsselten Netzwerkverkehr innerhalb eures Netzes ausließt, dann schafft er es auch früher oder später sich das Passwort für einen root oder root ähnlichen Account für den Server seiner Wahl zu besorgen.

Aus diesem Grund muss das eben verhindert werden.

Ergänzend dazu: Deshalb verschlüsselt man Verbindungen, zusätzlich sollte nicht jeder wildfremde Client eine Verbindung zur Datenbank aufbauen und zusätzlich kann man durch entsprechende ACLs auf den Routern Zugriffe von unbekannten Quellen absichern. Im Normalfall kommt a) nur eine explizit freigegebener Client (Subnetz / statische IP) eine Verbindung auf den Datenbankserver, die Datenbank authentifiziert den User anhand Zertifikat oder Username & Passwort und anhand der Client IP / Subnetz und c) jede Verbindung zum Datenbank geschieht über eine verschlüsselte Verbindung.

D.h. der Datenbankdienst kann anhand der IP des Client und der Userinformationen entsprechende Statements unterbinden.

Wenn die Authentifizierung am Datenbankserver unverschlüsselt statt findet und/oder jeder connecten darf, dann würde ich vielleicht erst einmal Gedanken in eine sichere Netzstruktur investieren, anstatt irgendwelche Filter zu implementieren. Zusätzlich sollte es nicht jedem User möglich sein, auf das OS des Datenbankservers zu kommen, also ein Datenbankserver auf dem noch zig andere Dienste laufen und jeder User remote connecten darf, ist natürlich ein potentielles Sicherheitsrisiko.

Ein Datenbankserver stellt nur den Datenbankdienst zur Verfügung und nur ein entsprechender Administrator aus einem entsprechenden Netz darf sich auch nur mit einer verschlüsselten Remoteshell verbinden

Bearbeitet 23. November 2012 von flashpixx