Netzwerkstruktur WebServer

[tomic]

Hallo zusammen,

ich bin aktuell dabei mir einen Server auf Debian mit OpenVZ einzurichten und habe zu den Grundstrukturen in bezug auf das Netzwerk Wissenlücken...

Ich habe bisher folgende Struktur: (siehe Bild unten)
Subnetzmaske is 255.255.255.0

Dazu habe ich folgende Fragen:
1. Da ich vom Rechenzentrum dann wohl einen IP-Adressenbereich erhalte brauche ich 2 Netze oder?
Meine Vermutung:
Ein internes und ein externes Netz, wie sieht das dann im Detail aus?

2. Wie verbinde ich die beiden Netze dann so miteinander, dass ein Rechner aus Netz 1 mit dem Rechner aus Netz 2 "sprechen" kann?

Vielen Dank im Voraus

tomiC

 

[weesly]

Ein Datenbanksystem würde ich nie virtualisieren. Maximal mit auf eben des Hostsystems installieren.

Bzgl. deiner Fragen:

Zu 1) Kommt drauf an, wie du bestellst. Geht auch nur ein Netz

Zu 2) Das geht über Routing auf der Hostmaschine.

 

[mr_brain]

1a) Bei den meisten Domain-Registries kannst du keine IP´s auf dem gleichen Subnetz benutzen. D.h., vom RZ wirst du zwei Netze bekommen.

1b) Wozu interne IP´s?

2a) Mit zwei normalen Netzen ist dies kein Problem. Wichtig ist nur, dass bei Netze auf dem gleichen Router aufschlagen. Auf dem openVZ-Host brauchst du nur ein Gateway und eine Subnetmask. Die openVZ-vServer bekommen eh keine Gateway- und Subnetmask-Angabe.

1b) Interne IP´s wirst du nur per NAT erreichen können.

 

[tomic]

Wie werden denn dann 2 Netzte in meiner Konstellation verwirklicht? Bekommt dann jede VM eine 2te virtuelle Netzwerkkarte?

Laut Informationen vom Rechenzentrum muss sich der primary DNS-Server in einem anderen Netz befinden als der secondary DNS-Server.

Die Virtualisierung der Datenank wird aus folgenden Gründen durchgeführt:
Es ist für einen Angreifer schwerer aus einer VM "auszubrechen". Sollte die Datenbank auf einem der andren VM'S liegen hätte es ein Angreifen leichter die darauf befindlichen weiteren Diensten ebenfalls zu kompromittieren.
Die Verwaltung der einzelnen VM'S läuft komplett über ein selbst erstelltes Webinterface mit einem lighttpd Server welcher dann Befehle direkt in der Shell als Root ausführen kann. (restart, exec, anlegen von Vhosts usw.)
Diese Befehle sollen nur gültigkeit für die entsprechende VM haben.

 

[Joe User]

Die Verwaltung der einzelnen VM'S läuft komplett über ein selbst erstelltes Webinterface mit einem lighttpd Server welcher dann Befehle direkt in der Shell als Root ausführen kann. (restart, exec, anlegen von Vhosts usw.)

Aber das DBMS virtualisieren wollen...
Dein Vorhaben ist "broken-by-design", oder wie gewährleistest Du die Sicherheit Deines Remote-root-Interface?

 

[tomic]

Dein Vorhaben ist "broken-by-design", oder wie gewährleistest Du die Sicherheit Deines Remote-root-Interface?

Kannst du das bitte etwas näher erläutern?

Falls mit Remote Root Interface das Hostsystem gemeint ist kann ich dazu sagen, dass auf diesem letztlich nur SSH nach außen frei ist. Portknocking Daemon für OpenSSH sollte diesen in Verbindung mit den entsprechenden FW-Regeln die Sicherheit gewährleisten können. Oder?

 

[Joe User]

lighttpd Server welcher dann Befehle direkt in der Shell als Root ausführen kann.

Das meine ich. Das ist Harakeri auf Raten, kurz broken-by-design.
Was glaubst du wie leicht damit jedes Scriptkiddie Deine Kiste inklusive VMs übernimmt? Schneller als jedes DBMS in Grundkonfiguration.

 

[tomic]

Ich habe mich offensichtlich nicht detailliert genug ausgedrückt. Sorry

Hier mal etwas ausführlicher:
Die auf dem Bild zu sehenden VM'S haben bis auf die DNS-Server alle einen lighttpd Server der dann "nur" die VM's auf welchen der "little webserver" installiert ist steuern kann. Zum Thema Sicherheit wurde folgendes getan um einen Angriff so unwahrscheinlich als mir möglich zu machen:
1. Per IP-Tables wurde festgelegt, dass lighttpd nur von einer internen Addresse erreicht werden kann. OpenVPN wurde eingerichtet.
2. Auch der lighttpd-Port ist nur dann erreichbar, wenn zuvor an unterschiedlichen Ports in Folge "angeklopft" (portknocking)wurde. Erst dann öffnet sich der Port auf dem der lighttpd für wenige Sekunden die Befehle annimmt.
3. Das Webinterface über welches lighttpd dann erreicht werden kann ist dann zum Abschluss über SSL gesichert.

Um alle der gelisteten Sicherheitsmerkmale zu umgehen würde man, wenn überhaupt möglich, mehrere Tage oder gar Wochen brauchen. Da die Logs täglich ausgewertet werden würde es auffallen.

Generell stimme ich dem zu, dass eigtl. nichts als root gemacht werden sollte. -wer den root hat hat die macht-
Danke für die Info. Bin für jede Anregung dankbar.

Wie werden denn dann 2 Netzte in meiner Konstellation verwirklicht? Bekommt dann jede VM eine 2te virtuelle Netzwerkkarte?

Laut Informationen vom Rechenzentrum muss sich der primary DNS-Server in einem anderen Netz befinden als der secondary DNS-Server.

Gibt es zu den beiden offenen Fragen noch Anregungen/Hilfestellung?

Vielen Dank im Voraus

 

[Joe User]

OK, zwar nicht sehr elegant gelöst, aber brauchbar.
IPTables kannst Du Dir sparen, server.bind=localhost reicht völlig.

 

[Joe User]

Nachtrag: Statt Linux+VMs solltest Du über FreeBSD+Jails nachdenken, dann leidet auch das DBMS nicht unter den Nachteilen der VM.

 

[tomasini]

Darf ich mal fragen, ob das ein echtes Produktivsystem werden soll oder nur eine rein private Geschichte?

 

[Roger Wilco]

Laut Informationen vom Rechenzentrum muss sich der primary DNS-Server in einem anderen Netz befinden als der secondary DNS-Server.

Ja, und zwar aus Redundanzgründen. Was bringt es dir, zwei VMs mit jeweils einem Nameserver zu betreiben? Nichts, zumal die Geschichte mit den zwei Nameservern eine rein administrative Anforderung ist, keine technische. Such dir lieber einen richtigen Slave-Server für deinen Nameserver.

Nachtrag: Statt Linux+VMs solltest Du über FreeBSD+Jails nachdenken, dann leidet auch das DBMS nicht unter den Nachteilen der VM.

Inwiefern? FreeBSD Jails sind im wesentlichen doch auch nur aufgebohrte OS-Container, genau wie die VEs bei OpenVZ oder Linux-Vserver.

 

[tomic]

Such dir lieber einen richtigen Slave-Server für deinen Nameserver.

Was ist hier mit richtigen Slave-Server gemeint?

die beiden DNS-Server holen sich bisher die Nutzdaten jeweils aus redundant angelegten Datenbanken.

Es soll übrigens durchaus ein produktives System werden. Die Lösung mit lighttpd ist definitiv nicht elegant und insgeheim eine kleine Insellösung, jedoch steht die komplette Konfiguration und Implementierung der einzelnen PHP-Skripte schon, was einige Wochen in Anspruch genommen hat. Der Aufwand war doch relativ hoch ein komplettes Administrationspanel zu schreiben über welches nahezu alle verfügbaren Shell Befehle "relativ sicher" abgesetzt werden können.

 

[Roger Wilco]

Was ist hier mit richtigen Slave-Server gemeint?

Einen Nameserver, der die Zonendaten deines primären Nameservers besitzt und ausliefern kann.

die beiden DNS-Server holen sich bisher die Nutzdaten jeweils aus redundant angelegten Datenbanken.

Schön, und was machst du, wenn dein Wirtssystem ausfällt? Oder einfach nur eine VM geDDoSt wird? Dann ist das Netzwerkinterface deines Servers erstmal dicht.

Du baust dir also einen wunderschönen SPOF.

 

[tomic]

Einen Nameserver, der die Zonendaten deines primären Nameservers besitzt und ausliefern kann.

Verstehe ich es also richtig wenn ich z. B. als secondären DNS einen komplett anderen DNS Server angebe der nicht auf dem Server läuft? Wenn Ja, woher bekomme ich solch einen und woher kennt dieser DNS die Zonendaten meines DNS-Servers?

 

[Roger Wilco]

Verstehe ich es also richtig wenn ich z. B. als secondären DNS einen komplett anderen DNS Server angebe der nicht auf dem Server läuft?

Ja.

Wenn Ja, woher bekomme ich solch einen und woher kennt dieser DNS die Zonendaten meines DNS-Servers?

Viele Provider bieten eine entsprechende Dienstleistung an, viele sogar kostenlos, wenn die Domains bei ihnen registriert wurden.

Die Übertragung der Zonendaten bleibt dir überlassen, üblich wäre ein Zonetransfer via AXFR oder IXFR.