Angreifbarkeit von Datenbank-Servern

Hallo Experten,

ich wollte mal hören, wie Ihr das Risiko bei einem bestimmten Szenario einschätzt:

Für einen Kunden muss(!) ein Web-Server auf Basis von M$ IIS aufgesetzt werden. (Nein, es geht wirklich nicht anders… :frowning: )
Dieser Server greift (lesend und schreibend) auf eine Oracle-Datenbank zu und wird in einer eigenen DMZ plaziert sein.

Jetzt geht es darum: das der IIS mal geknackt wird dürfte nur eine Frage der Zeit sein. Nehmen wir also mal den worst case an, dass der böse Hacker es glücklich mit admin-Rechten in die shell geschafft hat - ähhh, ich meine auf BS-Ebene, also Win2000.

Wie wahrscheinlich ist es, dass er es von hier aus auf den Datenbankserver (AIX) schafft? Zwischen IIS und DB-Server sollen nur die Oracle-Ports freigegeben werden. Und zwar auch wieder auf die Shell - dass er die DB zerbomben könnte ist klar.

Es dreht sich nämlich darum, ob wir die Datenbank u.U. auf einem zentralen DB-Server mit anderen Datenbanken laufen lassen können, der allerdings nicht in dieser DMZ steht. Es wäre kein großes Problem, wenn Harry Hacker diese spezielle DB kaputt macht, es wäre nur fatal, wenn er auch an die anderen DB’s ramkäme bzw. auf den Rechner selber. Wenn das Risiko zu hoch ist, müsste ein dedizierter DB-Server beschafft werden -> teuer.

Ich bitte um Eure Meinungen.

Gruß
Stefan

Wenn das Risiko zu
hoch ist, müsste ein dedizierter DB-Server beschafft werden
-> teuer.

Ich bitte um Eure Meinungen.

Die Frage ist, was ist teurer: Der Verlust der Daten oder der Kauf einer neuen Maschine? Wie lange dauert es, einen beschädigten Datenbank-Server wieder aufzubauen (Restore-Strategie)? Ist ein Ausfall von beispielsweise sechs Stunden vertretbar oder ziehen euch eure Kunden dann finanziell das Fell über die Ohren?

Und vor allen Dingen: wie oft wird ein solcher Ausfall angenommen? Täglich (au weia)? Einmal in drei Jahren?

Ich persönlich halte den IIS in einer geschützten und gepflegten Umgebung für nicht anfälliger als jede andere Maschine. Man muss sich halt darum genauso kümmern wie um jeden Apache. Wenn du auch sonst keine bedenken hast, die zentrale Datenbank zu nutzen (beispielsweise über einen Apache), dann kannst du den IIS genauso einsetzen.

Stefan

Jetzt geht es darum: das der IIS mal geknackt wird dürfte nur
eine Frage der Zeit sein.

Wieso? Er ist doch von aussen ausschliesslich über Port 443 erreichbar. Da würde ich einen über ein Defacement oder DOS hinausgehenden Angriff schon für sehr unwahrscheinlich halten. Wenn deine der Datenkommunikation dienenden Scripte sauber sind und die Firewall dicht ist, solltest du auch mit einem IIS nicht angreifbarer sein, als z. B. mit einem Apache.

Wenn der Kunde Fernverwaltung realisieren will, die über Scripts hinausgeht, wenn er also z. B. direkt auf einen MS-SQL-Port zugreifen will, realisierst du das über die Firewall per VPN. Dann ist schon eine man in the middle attack erforderlich, um ins System eindringen zu können.

Nehmen wir also mal den worst case
an, dass der böse Hacker es glücklich mit admin-Rechten in die
shell geschafft hat - ähhh, ich meine auf BS-Ebene, also
Win2000.

Wie wahrscheinlich ist es, dass er es von hier aus auf den
Datenbankserver (AIX) schafft? Zwischen IIS und DB-Server
sollen nur die Oracle-Ports freigegeben werden. Und zwar auch
wieder auf die Shell - dass er die DB zerbomben könnte ist
klar.

Es dreht sich nämlich darum, ob wir die Datenbank u.U. auf
einem zentralen DB-Server mit anderen Datenbanken laufen
lassen können, der allerdings nicht in dieser DMZ steht. Es
wäre kein großes Problem, wenn Harry Hacker diese spezielle DB
kaputt macht, es wäre nur fatal, wenn er auch an die anderen
DB’s ramkäme bzw. auf den Rechner selber. Wenn das Risiko zu
hoch ist, müsste ein dedizierter DB-Server beschafft werden
-> teuer.

Wenn die DB in einer eigenen Oracle-Instanz mit nur für diese DB zugeordneten Ports läuft sollten andere Instanzen sicher sein. Ein erfolgreicher DOS auf die eine Instanz würde aber selbstverständliche alle anderen Instanzen in Mitleidenschaft ziehen.

Selbst wenn Oracle z. B. über einen Pufferüberlauf angreifbar wäre, wären die anderen DB sicher, da ja zwischen IIS und DB-Server wieder eine Firewall steht, die ausschliesslich den (die) dedizierten Oracle-Ports auf die in eigenem Kontext laufende Instanz öffnet.

Wenn auf den anderen DB kritische Daten liegen, solltest du aber noch ein IDS zur Überwachung der DMZ installieren.

Gruss,
Schorsch

Hallo,

Jetzt geht es darum: das der IIS mal geknackt wird dürfte nur
eine Frage der Zeit sein.

Nö. Wenn der richtig administriert wird nicht. Abgesehen davon: Der IIS an sich (!) soll ja auch garnicht sicher sein. DAFÜR gibt es andere Sicherheitsmechanismen.

Wie wahrscheinlich ist es, dass er es von hier aus auf den
Datenbankserver (AIX) schafft? Zwischen IIS und DB-Server
sollen nur die Oracle-Ports freigegeben werden. Und zwar auch
wieder auf die Shell - dass er die DB zerbomben könnte ist
klar.

Selbst wenn. Was soll er mit dem Datenstrom machen? Soweit ich mich erinner kann, kann man nicht so ohne weiteres die DB z.B. „kopieren“ und dann drauf zugreifen.

Es dreht sich nämlich darum, ob wir die Datenbank u.U. auf
einem zentralen DB-Server mit anderen Datenbanken laufen
lassen können, der allerdings nicht in dieser DMZ steht. Es
wäre kein großes Problem, wenn Harry Hacker diese spezielle DB
kaputt macht, es wäre nur fatal, wenn er auch an die anderen
DB’s ramkäme bzw. auf den Rechner selber. Wenn das Risiko zu
hoch ist, müsste ein dedizierter DB-Server beschafft werden
-> teuer.

Du gibst doch selbst schon die Antwort *kicher*
„Sicherer“ wäre wohl ein Szenario mit einem DB Server IN und einen ausserhalb der DMZ. Diese dann spiegeln.
Die „kleine“ Lösung würde für mich so aussehen: DB Server, IIS und Firewall/Router.

Gruß
h.