Dienste Verteilung in Jails

daiv

AgainstAllAuthority
Hallo Forum,

ich habe erfolgreich einen Hetzner EQ4 Server mit FreeBSD und Jails am Laufen. Jetzt würde ich gerne folgende Dienste in Jails sperren:
- opentaps (CRM/ERP/WAWI: www.opentaps.com)
- PostgreSQL
- MySQL
- Apache 2
- Mailserver (Postfix / Qmail)
(- Jabber)

Ich habe 4 IPs zur Verfügung. Eine hat ja bereits das Host-System. Jetzt habe ich an 3 Jails gedacht:

Jail 1 (wawi): opentaps (ohne Datenbank)
Jail 2 (db): PostgreSQL und MySQL
Jail 3 (web): Apache 2 und Mail

Bin mir etwas unsicher. Vielleicht sollte ich die DBs und die wawi zusammen in eine Jail sperren?
Da Jails bei mir hauptsächlich wegen der einfachen Sicherung und natürlich der Sicherheit wegen eingesetzt werden, macht es doch Sinn die db die Daten von Jail 1 und 3 beinhalten soll extra zu behandeln. Die Frage ist auch ob es Sinn macht wawi und web zu trennen. Opentaps verfügt über eine Art Shop-Lösung die ich auch gerne nutzen würde.

Danke schonmal für eure Ideen und Anregungen

David
 
Hi.

Es spricht (eigentlich) nichts dagegen alle Dienste in separaten Jails zu betreiben. Um die IP-Knappheit zu umgehen kann man wunderbar Jails mit "host-only" IPs versehen und diese dann per Port-Forwarding erreichbar machen.
Siehe: http://wiki.bsdforen.de/howto/ezjail#nur_interne_ips
Es ist immer sinnvoll seine IPs nicht komplett zu belegen, manchmal braucht man einfach eine neue und dann ists blöd wenn alle schon belegt sind.


Prinzipiell würde ich nicht davon zurück schrecken die beiden Datenbanken in ein Jail zu stecken. Angenommen die müssen auch von außen erreichbar sein. Ansonsten ist gerade hier die Host-Only Lösung wirklich zu empfehlen!
Hierzu ist auch Siehe: http://wiki.bsdforen.de/howto/jails#sysctl-knoepfe_fuer_jails interessant.

Dann könnte man die ganze Webgeschichte (Apache) in ein Jail stecken

und die Mailsachen sollten vielleicht doch ne eigene externe IP bekommen damit man die notfalls einfach wechseln kann.

Und was auch immer dieses Opentaps ist... kann ja auch noch ein eigenes Jail bekommen ;-)


Grüße!
 
Hallo MrMarv,

danke für die schnelle Antwort. Du hast Recht, ich sollte lieber sparsam mit den IPs umgehen. Mit den Datenbanken hast du auch Recht, genau da sollte ich keine öffentliche IP "verschenken". Im Grunde muss keiner von "außen" dran.
Also macht es Sinn die Datenbanken zwecks Sicherheit von den anderen Anwendungen zu trennen?

Bin jetzt nur am überlegen ob die wawi (opentaps) nicht doch mit dem Webzeug zusammen eine "Zelle" bekommt. Wollte das nur nicht weil opentaps JDK benötigt und ich das noch nie auf FreeBSD installiert habe. Ich werde das anhand diesem Eintrag http://wiki.bsdforen.de/howto/java_installation machen. Eigentlich ist Java der einzige Grund (und vielleicht noch die Sicherheit) warum ich das trennen würde.
 
Hallo daiv,

trennen kostet ja nicht viel, wenn Du den statischen Teil read-only zwischen den Jails teilst... Java (diablo-jdk1.6 oder diablo-jre1.6) sind mittlerweile recht problemlos in der Installation, man muss nur die distfiles manuell runterladen.

PostgreSQL würde ich nicht in ein Jail stecken - dafür musst Du SYSVSHM erlauben, und das geht nur global für alle Jails. Wurde hier mal ausführlicher diskutiert... (bei MySQL besteht dieses Problem übrigens nicht, das kann wunderbar hinter Gittern vor sich hinvegetieren)
 
Danke Ogion für den Hinweis, dann muss ich wohl oder übel PostgreSQL auf dem Host laufen lassen. Ich kann zwar für opentaps so ziemlich jede Datenbank verwenden, aber möchte lieber PostgreSQL.
 
Könnte ich eigentlich PostgreSQL mit jail.sysvipc_allowed=1 trotzdem in eine Jail installieren? Ich hätte dann "nur" soweit ich das verstanden habe ein mögliches Sicherheitsrisiko, weil PG nicht vollständig vom Host isoliert ist. Das würde ich vorziehen als PG nicht in eine Jail zu packen.

Was meint ihr dazu?
 
Könnte ich eigentlich PostgreSQL mit jail.sysvipc_allowed=1 trotzdem in eine Jail installieren? Ich hätte dann "nur" soweit ich das verstanden habe ein mögliches Sicherheitsrisiko, weil PG nicht vollständig vom Host isoliert ist. Das würde ich vorziehen als PG nicht in eine Jail zu packen.
jail.sysvipc_allowed=1 gilt global für alle Jails. Dadurch können Prozesse in allen Jails auf die Shared Memory Segmente aller anderen Jails und des Hosts zugreifen (auch schreibend). Ich glaube nicht, dass Du das möchtest...
 
Hat sich eventl. etwas geändert mit der neuen Version 8.4?

Nein, das ist bei PostgreSQL "by design" so, da die verschiedenen Aufgaben auf separate Prozesse aufgeteilt sind. Man müsste die Interprozess-Kommunikation von SHM auf Unix Sockets umstellen, was aber a) einen Haufen Arbeit bedeutet und b) ggf. einen Performance-Bottleneck schaffen dürfte.
 
Danke für die Antwort Ogion.

jail.sysvipc_allowed=1 gilt global für alle Jails. Dadurch können Prozesse in allen Jails auf die Shared Memory Segmente aller anderen Jails und des Hosts zugreifen (auch schreibend). Ich glaube nicht, dass Du das möchtest...
Ich habe folgenden Beitrag auf http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2003-09/0168.html gefunden
> Reading this it sounds like setting jail.sysvipc_allowed=1 is a bad idea?
> So I guess my question is, whether it is a big security risk to run
> postgresql in a jail?

No, I wouldn't say that. It is still _much_ better than
not running PostgreSQL in a jail at all.
Verstehe ich da etwas falsch? Dort wird ja behauptet es ist besser trotzdem PostgreSQL in einer Jail laufen zu lassen.
 
Ja, es wird dort gesagt - ohne Begründung.
Die Frage lässt sich nicht pauschal beantworten. Es kommt darauf an, wie vertrauenswürdig die anderen Jails und das Hostsystem sind. Wenn du allen hundertprozentig vertrauen kannst, dann spricht nichts dagegen. ;-)
Meine Meinung dazu: Wieviele Sicherheitslücken gabs in der letzten Zeit in PG? Was spricht dagegen es auf dem Hostsystem laufen zu lassen?

Edit: Es ist u.A. eine Prioritätenfrage. Ich selbst gehe davon aus, dass die Daten in einer DB die höchste Priorität haben. Bei meiner Sichtweise ist also ein möglicher Angriff auf PG der wc. Du musst halt für dich die Prioritäten setzen.
 
Zuletzt bearbeitet:
Zurück
Oben