Asp.net in DMZ
Hallo,
wir haben einen IIS-Webserver in der DMZ. Dieser kommuniziert über einen freigeschalteten Port mit einem Datenbankserver in unserem internen Netz.
Ist dieses Setup sicher oder sollte die Datenbank auch in die DMZ?
Die Kommunikation erfolgt über Ado.net. Wie kann ich diese absichern? Muss ich ggf. Verschlüsselung einsetzen?
Danke für eure Hilfe!
Gruß
LuckyStrike
huhu,
Wenn jemand deinen Webserver kompromitiert, dann kommt er immer auch an einen nachgelagerten DB-Server.
Wenn der DB-Server nicht entsprechend gesichert ist, kann auch über eine simple SQL-Injection großer Schaden entstehen. Eine Verschlüsselung der Verbindung zwischen den Server bringt hier garnichts.
Es kommt ein wenig darauf an, welche Daten der DB-Server bereit hält, und inwiefern diese im internen LAN benötigt werden. Eventuell bietet sich auch eine Replikation zu einem (neuen) DB-Server in der DMZ und dem internen Lan an.
😃
Xynratron
Herr, schmeiss Hirn vom Himmel - Autsch!
Die Erfahrung zeigt immer wieder, dass viele Probleme sich in Luft auslösen, wenn man sich den nötigen Abstand bzw. Schlaf gönnt.
Sicherheitstechnisch finde ich es auch nicht gerade optimal. Ich habe es folgender Maße gelöst. IIS ist in der DMZ und meine DB im LAN (auch IIS installiert). Auf dem DB Server habe ich WebServices erstellt. Nun kommunziert die DMZ mit dem LAN nur über WebServices (HTTP Port, alles weitere ist gesperrt).
Wenn der DB-Server nicht entsprechend gesichert ist, kann auch über eine simple SQL-Injection großer Schaden entstehen.
Du kannst den DB-Server sichern wie du willst. wenn die Anwendungen SQL-Injection zulassen, dann nützt dir das alles meistens nichts.
Generell gilt, das Jede Anwendung obwohl die in der DMZ steht, dennoch sicher sein muss. Wenn man davon ausgeht, das die Anwendungen nicht Sicher sind, dann nützt die DMZ auch nichts.
IIS ist in der DMZ und meine DB im LAN (auch IIS installiert). Auf dem DB Server habe ich WebServices erstellt. Nun kommunziert die DMZ mit dem LAN nur über WebServices
Generell gutes vorgehen. Gegen fehlerhafte Programmierung aber auch hier nicht sicher. Wenn SQL-Injection prinzipiell möglich ist, dann nützt das auch nicht.
Also: Sichere Programme verwenden.
huhu,
Wenn der DB-Server nicht entsprechend gesichert ist, kann auch über eine simple SQL-Injection großer Schaden entstehen.
Du kannst den DB-Server sichern wie du willst. wenn die Anwendungen SQL-Injection zulassen, dann nützt dir das alles meistens nichts.
Ja, meistens 😃 Ich dachte da eher an ein "1=1'; drop table users; --" wenn aber die Zugriffe z.B. über SPs gehen und/oder der verwendete DB-User die Berechtigung dafür nicht hat, dann geht das z.B. nicht mehr. Aber egal - letzendlich muss man nicht nur die Anwendung sicher machen - eine Kompromitierung des Web-Servers kann ja auch über andere Möglichkeiten geschenen - sondern auch seine DB im Hintergrund entsprechend schützen. Eine Einschränkung der Benutzerrechte wäre schonmal ein erster Schritt.
Schön aber, dass mal jemand nachfrägt, meiner Meinung nach wird das Thema "Sicherheit" immernoch extrem vernachlässigt.
😃
Xynratron
Herr, schmeiss Hirn vom Himmel - Autsch!
Die Erfahrung zeigt immer wieder, dass viele Probleme sich in Luft auslösen, wenn man sich den nötigen Abstand bzw. Schlaf gönnt.
Ich dachte da eher an ein "1=1'; drop table users; --" wenn aber die Zugriffe z.B. über SPs gehen und/oder der verwendete DB-User die Berechtigung dafür nicht hat, dann geht das z.B. nicht mehr.
Die korrekte Verwendung von Parametern reicht eigentlich auch schon. SP´s dafür zu verwenden finde ich persönlich für umständlich. Zumal SP´s im einfachsten Falle kaum echte Vorteile bringen.
jap, viele Wege, ein Ziel 😃
Herr, schmeiss Hirn vom Himmel - Autsch!
Die Erfahrung zeigt immer wieder, dass viele Probleme sich in Luft auslösen, wenn man sich den nötigen Abstand bzw. Schlaf gönnt.
Hallo,
vielen dank für eure Antworten. Also die Verbindung zwischen Client und Webserver ist über SSL abgesichert.
In der Webanwendung ist der DataAccessLayer als library eingebunden. Die SQL-Abfragen von Webserver zu DB laufen über parametrisierte Queries unter einem DB-Nutzer mit eingeschränkten Rechten.
Da das ganze über SQL-Authentication läuft, enthält die Library aber im Moment den Connection-String als Klartext. Wenn nun der Webserver kompromitiert wird, könnte jemand mittels Disassembler das DB-Passwort rauskriegen und direkt auf den DB-Server zugreifen.
Daher nun meine Frage wie ich den DAL absichere. Reicht eine Verschlüsselung des Connection-Strings aus? Wenn ich die Connection im DAL öffne, werden dann Anmeldenamen und Passwort im Klartext an die DB übertragen? Kann bzw. sollte ich den Datenverkehr zwischen Webserver und DB verschlüsseln oder ist das mit Kanonen auf Spatzen geschossen?
Ein Appliaktionsserver im internen Netz, der den DAL als Webservice bereit stellt würde das Problem m.M. nach nur veschieben, oder?
Die Anwendung wird übrigens in einer Webfarm gehosted.
Wenn nun der Webserver kompromitiert wird, könnte jemand mittels Disassembler das DB-Passwort rauskriegen und direkt auf den DB-Server zugreifen.
Kompromittieren != Kompromittieren 😃
Das ist ein wenig komisch ausgedrückt aber wenn jemand auf dein System irgendwie Draufkommt, dann heißt es ja nicht, das er auch auf deine Quellen kommt. Und selbst wenn er das Schafft (was schon recht schwer ist), dann kann er vielleicht das PW auslesen (was ja nicht sichergestellt ist, weil der Disassembler nur einen Statisch hinterlegtes Passwort anzeigen könnte... nicht aber eine Passwort aus eine Config Datei) aber nur das PW und der User bringt ihn auch nicht viel weiter. Die DB ist ja nur aus der DMZ erreichbar. Daher müsste er es schaffen, ein eigenes Programm in die DMZ zu schleusen und auszuführen (mit dem richtigen Benutzer + Rechte) und das ist ... sagen wir mal der Katastrophenfall, da der komplette Server hier unter Kontrolle des Angreifers steht (was äußerst selten zu schaffen ist) und selbst dann hat er nur einen DB-User mit eingeschränkten Rechten....
Je mehr ich mich mit dem Thema beschäftige, desto paranoider werde ich ... 😃
Aber angenommen jemand schafft es ein Programm auf unseren Webserver einzuschleusen, dann hat er trotzdem mehr Rechte als die Applikation selbst, denn die ganzen Benutzerrechte (Zugriffe, Rollen) werden ja in der Applikation geregelt.
Also ich würde jetzt erstmal den Connection-String aus der Library rausziehen und in die web.config packen. Wie kann ich die denn am effektivsten sichern? Hab ja keinen Root-Zugang zum Server und kann kein aspnet_regiis rausführen.
Aber angenommen jemand schafft es ein Programm auf unseren Webserver einzuschleusen,
Das passiert so gut wie nie. Meistens schafft man es wenn überhaupt, code mit den rechten des Kompromitierten Programmes auszuführen.
Aber gut, gehen wir den Katastrophenfall durch. Dann müsste derjenige deine Config auslesen und das Passwort erspähen. Wobei du hier die Möglichkeit hast das Passwort verschlüsselt in der Config abzulegen und immer Dynamisch auszulesen. Also könnte derjenige nur mit einem Debugger das Passwort auslesen oder aber den Gesamten Speicher nach Strings durchsuchen (für beides sind Adminrechte notwendig) um an das Passwort zu kommen.
Angenommen er hat Adminrechte und schafft das... (und dann ist er schon verdammt gut und hat sicherlich einige Tage Aufwand investiert....) Dann hat er auch nicht mehr als einen DB-User, welcher eingeschränkte Rechte hat und er ist Admin in der DMZ ... na WOW... 😉
So habe in der Global.asax beim Application_Start Event die Verschlüsselung der ConnectStrings eingebaut.
Jetzt kann ich ruhig schlafen ... 😃
Danke für eure schnelle Hilfe!