OpenVZ nur internen Zugriff erlauben

T

tomic

New Member
Wie ist es geschickt umzusetzen wenn ich folgendes erreichen möchte:

Eine VM soll einen Webserver darstellen. Auf diesem brauche ich von extern erreichbar nur port 80. Es laufen jedoch auch andere Dienste die nur vom internen Netzwerk erreichbar sein sollen.

Ich denke IPTables ist die Lösung, aber wie müsste es konkret für Debian Lenny umgesetzt werden?
 
Wie sieht denn deine Netz-Konfiguration (Hostsystem und Gast) im Moment überhaupt aus? Eventuell brauchts ja gar keine IPTables. :rolleyes:
 
Hostsystem: 10.11.0.24
VM mit Apache: 10.11.0.103

Die Ip's werden natürlich noch durch öffentliche IP's ersetzt sobald das System im RZ steht.

Die 103 soll dann von außen erreichbar sein. Von anderen VM's wie z.B. 104 sollen dann jedoch weitere Dienste auf der 103 erreichbar sein.
Auf dem Hostsystem wird nachher nur SSH freigegeben sein.
 
Last edited by a moderator:
Das könnte man mit einfachen Accept/Drop/Reject Regeln lösen. Aber was spricht dagegen, den VEs eine zweite (interne/private) IP zuzuweisen und die anderen Dienste an die IP zu binden? ;)
 
Der Server selbst hat eine einzige Netzwerkkarte. Habe über Idee auch schon nachgedacht aber keine Möglichkeit gefunden in OpenVZ eine weitere Virtuelle Katre anzulegen bzw. zu belegen.
 
das ist schonmal ein Anfang. Danke dafür. Wenn ich nun jedoch ein anderes Netz nehme.

z. B. 192.168.1.x dann erreiche ich diese IP im Netz (von anderen Rechnern im 10er Netz) nicht. Muss ich hierfür noch Routen festlegen?

Wie sollte die Firewall aussehen und womit mache ich das am besten? ferm?
 
Last edited by a moderator:
Vielleicht zeichnest du einfach mal auf, wie das Netz nun wirklich aussehen soll und wer von wo nach wo zugreifen soll/darf. Inklusive aller öffentlichen und privaten Netze, sowie VPN und sonstigen Tunneln.
 
Eine Skizze des Netztes werde ich morgen früh hier reinstellen. Muss bissel zeichnen :-)

Vielen Dank für die bisherige Hilfe.
 
Hoffe dieser Entwurf ist aussagefähig genug (siehe Bild):

Hostsystem
Port 22 nach außen frei (für VM Verwaltung)

CTID 103 (Webserver)
Port 21 nach außen frei
Port 80 nach außen frei
intern alles frei

CTID 104 (Webserver)
Port 21 nach außen frei
Port 80 nach außen frei
intern alles frei

CTID 131 (Mailserver)
extern folgende Ports offen 25, 110, 143
intern alles frei

CTID 111 (MySQL)
intern alles frei

CTID 112 (MySQL)
intern alles frei

CTID 113 (MySQL)
intern alles frei

CTID 121 (DNS)
intern alles frei
extern offen Port 53

CTID 122 (DNS)
intern alles frei
extern offen Port 53
-------------------------------------------------------

Generell ist es so gedacht dass die Server eben untereinander alles miteinander tun dürfen und extern nur das notwendige (Apache, Courier, powerdns, proftpd, SSH nur auf dem Host) frei ist. Aktuell habe ich für meine Tests die IP's meines Homenetzwerks genommen. Ich bekomme aber beim Einzug ins Rechenzentrum öffentliche IP's die ich dann entsprechend den VM's geben muss. Wäre es sinnvoll dennoch das interne Netz bestehen zu lassen und nur den VM's die von außen erreichbar sein sollen eine der öffentlichen IP's zu geben oder was rätst du mir dabei?

PS: lighttpd nehme ich für die Erstellung der FTP-User, Vhosts usw.. Dieser Dienst läuft als root - unsicher und deshalb nur intern erreichbar auf 51337.

Nochmals ganz herzlichen Dank für Hilfe.
 

Attachments

  • Bild 1.jpg
    Bild 1.jpg
    52 KB · Views: 107
Deine Skizze zeigt pro VE nur eine IP, für das Vorhaben, sollten es aber schon 2 sein. ;)
Ich verstehe auch noch nicht was du nun damit ausdrücken wolltest:
tomic said:
z. B. 192.168.1.x dann erreiche ich diese IP im Netz (von anderen Rechnern im 10er Netz) nicht. Muss ich hierfür noch Routen festlegen?
Click to expand...

Die VEs auf dem Hostsystem erreichen sich automatisch untereinander, weil das Hostsystem der Router ist und VZ automatisch die entsprechenden Routen für die einzelnen IPs in den VEs auf dem Hostsystem setzt.
Von "anderen Rechnern" ist in deiner Skizze nichts zu sehen. ;)
 
Ich hatte von meinem eigenen PC (10.11.0.12) versucht die neue IP 192.168.1.3 anzupingen was natürlich nicht geht. Aber es ist ausreichend dass es innerhalb der VM's funktioniert. Das dies automatisch von OpenVZ geroutet wird finde ich ziemlich gut :-)

Wo ergibt eine zusätzliche IP Sinn?
Wie sollte die Netzstruktur generell aussehen um auch die FW entsprechend einfach konfigurieren zu können?
 
tomic said:
Ich hatte von meinem eigenen PC (10.11.0.12) versucht die neue IP 192.168.1.3 anzupingen was natürlich nicht geht.
Click to expand...
Für die Testumgebung zu Hause hast du dafür 2 Möglichkeiten:
  • Du gibst deinem Rechner ebenfalls eine IP in dem 192.168er Netz
  • oder du sagst deinem Router, welchen du ja in der Regel als dein Default Gateway nutzt, dass er das 192.168er Netz über die IP des Hostsystems erreicht.

tomic said:
Wo ergibt eine zusätzliche IP Sinn?
Click to expand...
Die macht in sofern Sinn, dass du dir die Firewall sparen kannst, weil du die Dienste an die "interne" private IP binden kannst.

tomic said:
Wie sollte die Netzstruktur generell aussehen um auch die FW entsprechend einfach konfigurieren zu können?
Click to expand...
Was willst du mit der Firewall den bezwecken? Bei OpenVZ kannst du die IPTables Regeln auf dem Hostsystem sowie auch direkt in den VEs pflegen. Jenachdem was dir besser gefällt. Ein großes IPTables Script oder mehrere kleine zu haben. :)
 
Danke für die schnelle Antwort und die Mühen :)

Generell will ich die FW einsetzen um noch ein Stückchen mehr Sicherheit zu schaffen.

Mir wäre eine FW je VM lieber. Bei VM's die keine öffentlichen Dienste bereit stellen bräuchte ich doch dann auch keine öffentliche IP. Die IP einer solchen VM könnte doch dann eine interne IP sein?!

Interessanter wird es bei den VM's die öffentliche Dienste bereit stellen. Hier möchte ich wie schon erwähnt die FW als zusätzliches Sicherheitsmerkmal zum Einsatz bringen. Wenn ich die internen Dienste an die interne IP und die externen Dienste an die öffentliche IP binden und dann die FW so konfigurieren das die Schnittstelle mit der öffentlichen IP eben alles außer die entsprechend erforderlichen Ports blockt?!

Wie genau stellst du dir das Szenario vor? Meine Vorstellung kennt du ja nun :-)

Vielen Dank im Voraus.
 
tomic said:
Danke für die schnelle Antwort und die Mühen :)
Click to expand...
Kein Problem, dafür sind wir hier. :)

tomic said:
Bei VM's die keine öffentlichen Dienste bereit stellen bräuchte ich doch dann auch keine öffentliche IP. Die IP einer solchen VM könnte doch dann eine interne IP sein?!
Click to expand...
Korrekt.

tomic said:
Wenn ich die internen Dienste an die interne IP und die externen Dienste an die öffentliche IP binden und dann die FW so konfigurieren das die Schnittstelle mit der öffentlichen IP eben alles außer die entsprechend erforderlichen Ports blockt?!
Click to expand...
Technisch kein Problem, kann man machen. Aber wenn die Firewall sowieso nur Portfilter spielt und die Dienste sowieso nur auf der IP lauschen, auf der du sie letztendlich auch freigeben würdest, kommt wieder die große Frage der Sinnhaftigkeit einer "Firewall" bzw. eines Portfilters auf. Hier gibt es unterschiedliche Ansichten und wohl nie eine allgemeingültige Aussage.

Ganz persönliche Meinung dazu:
Bei einem System, dass eine klar definierte Aufgabe hat (bspw. Webserver) und nie etwas anderes machen wird halte ich einen Portfilter für überflüssig.
Bei einem System, dass alles mögliche beherbergt (Web-, Mail-, Fileserver, rsyncd, was weiß ich) und eventuell auch zum Testen weiterer Dienste genutzt wird (wohl bemerkt, testen auf hohem Niveau und nicht das was einige Kiddies hier als "lernen" einstufen), kann es meiner Meinung nach sinnvoll sein.

In deinem Fall würde ich für "Tests auf hohem Niveau" aber eher eine weitere VE mit interner IP anlegen. Dann sparst du dir diesen Teil ebenfalls. :)
 
bei den VM's die nur interne Dienste bereitstellen bin ich deiner Meinung. Eine Firewall ist hier wohl überflüssig.

Wie fange ich denn bei den VM's mit offentlichen Diensten an, die FW aufzusetzen? tue mich etwas schwer mit den regeln, chains usw.
 
Last edited by a moderator:
Naja, was soll man da nun groß zu schreiben. ;)
Wenn es ein reiner Portfilter werden soll, Freigaben für die einzelnen Ports in die INPUT Chain stopfen und danach Default-Policy auf DROP oder REJECT setzen.
 
Kannst du das bitte mal konkreter formulieren? wie sieht eine solche Datei genau aus und wie binde ich diese in mein Debian Lenny ein?
 
Ein sehr einfaches Beispiel für einen Portfilter:
Code: 
#!/bin/bash
### BEGIN INIT INFO
# Provides:          firewall
# Required-Start:    $network
# Required-Stop:     $network
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: firewall
# Description:       firewall
### END INIT INFO

start() {
	# open all
	iptables -P INPUT ACCEPT
	iptables -P OUTPUT ACCEPT
	iptables -P FORWARD ACCEPT

	# flush
	iptables --flush
	iptables -t nat --flush

	# rules ...
	iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
	iptables -A INPUT -i venet0 -p tcp -m state --state NEW --dport 22 -j ACCEPT
	iptables -A INPUT -i venet0 -p icmp -m state --state NEW -j ACCEPT

	# close
	iptables -P INPUT DROP
}

stop() {
	iptables -P INPUT ACCEPT
	iptables -P OUTPUT ACCEPT
	iptables -P FORWARD ACCEPT
	iptables -F
	iptables -X
}

case "$1" in
	start)
		start
	;;
	stop)
		stop
	;;
	restart)
		stop
		start
	;;
	*)
	echo "Usage: /etc/init.d/firewall {start|stop|restart}" >&2
	exit 2
	;;
esac
 
You must log in or register to reply here.
Back
Top