Netzwerkgrundinstallation

UCS - Univention Corporate Server
#1

Hallo,
auf neuer Hardware mit jetzt 2 Netzwerkkarten will ich folgende Konstellation ( UCS Master für Mail und Dateiserver ) einrichten:

eth0 192.168.178.200 255.255.255.0 soll mit dem Router ( Fritzbox ) nur für die Verbindung ins Internet sorgen. Alle Anfragen im internen Netz an eth1 192.168.12.1 255.255.0.0 sollen nur über squid ins Internet gehen dürfen. Wie und was muss ich einrichten damit das so funktioniert. Und vor Allem was muss geblockt werden !!

Ich nehme an: firewall , squid.

Was könnte noch nötig sein.

Bitte um kurze Infos damit ich mich dann einlesen kann.

Vielen Dank
Marc

#2

Hallo,

verbieten muß man gar nichts. IP Forwarding ist in der Grundinstallation ausgeschaltet. Man muß nur öffnen, was benötigt wird. Zum einen muß man für Namensauflösung sorgen: der Server bekommt einen DNS Forwarder, der nach “draußen” fragen darf, und die Clients bekommen den Server als einzigen Ansprechpartner (Netzwerk Definition, DHCP Service, DNS).

Squid sollte man nicht direkt installieren, sondern besser das Integrationspaket univention-squid. Man bekommt dann zum einen gleich die Nagios-Integration (Überwachung) geschenkt und kann zum anderen den Squid bequem über die UCR-Variablen konfigurieren.

viele Grüße
Frank Greif.

#3

Hallo Greif,

das mit univention squid ist soweit ok. jetzt habe ich aber noch das Problem dass ich die Firewall für das eth0, also das zum Internet, auf allen ports außer 443 dicht machen will. Bei den ip-Filterregeln in der univention registry wird doch aber nicht nach der Schnittstelle gesondert gefiltert? ( habe ich es übersehen?). Wo stelle ich das ein?

Gruß
Marc

#4

Ich komme nicht weiter… vielleicht kann mir von euch jemand helfen,der sich mit sowas auskennt. Schön wäre es auch Alles mit univention regeln hinzubekommen.

ich will am Ende folgendes Szenario hinbekommen:

eth1 ( 192.168.178.100 ) ist über den Router( 192.168.178.1 ) nach draußen verkabelt. Eingehend soll nur Port 22 und 443 aktiviert sein.
eth0 ( 192.168.12.1 )hängt am internen Netz. ( 192.168.12.0/24). Dort sollen alle für UCS nötigen Ports geöffnet sein.

Nach draußen ins Internet soll 443 und 80 über squid laufen. Leider müssen auch vom Rechner 192.168.12.12 aus dem internen Netz einige Ports direkt zum Router geforwarded werden.

Ich habe fast das ganze Szenario durch Anlegen von iptables und abschalten der univention firewall hinbekommen, scheitere aber komischerweise bei der Namensauflösung ( forwarder ) vom Server zum Router…

Verzweiflung durch Unverständnis und Halbwissen wächst …

Vielen Dank vorab,
Marc Schumann

#5

Hallo,

Da gehen wir doch mal die einzelnen Forderungen durch, inwieweit die erfüllbar sind…

Das erfüllt sich dadurch, daß man auf dem Router nur diese beiden Ports mit einem Portforwarding durchschaltet. Alle anderen Dienste dürfen doch ruhig auf diesem Interface hören, da ja trotzdem kein Paket dahin kommen wird. SSH und HTTPS Dienste hören standardmäßig auf allen Interfaces.

Das erfüllt sich von allein, indem man nur die Dienste installiert, die man braucht. Die dabei automatisch entstehenden Firewall-Regeln öffnen kein Forwarding oder Routing, sondern ausschließlich die Ports, auf denen etwas hören muß. Wenn Sie die Ports wissen wollen: der SDB-Artikel http://sdb.univention.de/content/2/18/de/auf-welche-tcp_udp_ports-des-ucs-masters-muessen-andere-ucs_system-zugreifen-koennen.html?highlight=ports nennt alle Ports, die nötig sind.

Das kriege ich nicht entwirrt. Auf Port 443 und/oder 80 hört das Webinterface der Management Console, und das sollte auch so bleiben, damit man seinen Host auch noch managen kann. Deshalb eine schlechte Idee, diese Ports “über Squid laufen” zu lassen (ich denke es ist “transparent Proxy” gemeint). Besser man nimmt Squid in der Standardkonfiguration, da hört er auf 3128 und man muß das eben den Clients mitteilen. Ansonsten muß man die Ports 443 und 80 nicht “für nach draußen” sperren, denn IP Forwarding ist doch ohnehin aus.

Dafür hat UCS meines Wissens nach keine direkte Einstellung. Aber man muß dafür nicht gleich den gesamten Firewall abschießen. Wenn man Firewall-Regeln von Hand hinzufügen will, schreibt man sie in die Datei /etc/security/packetfilter.d/50_local.sh hinein. Diese Datei wird durch UCS nicht gepflegt, sondern einfach Wort für Wort in die Konfiguration übernommen. Die anderen beiden Dateien (10_univention-firewall_start.sh und 80_univention-firewall_policy.sh) werden davor bzw. danach ausgeführt. Durch das System der Nummerierung kann man durch weitere Dateien auch Einstellungen vor allen anderen (00-09) oder nach allen anderen (81-99) ausführen lassen.

Das sollte eigentlich auch problemlos gehen. Auch dafür muß nichts geroutet oder am Firewall konfiguriert werden. Wenn man auf dem Server mit Hilfe der drei UCR-Variablen “dns/forwarder1…3” die Hosts einträgt, die uns der Provider als DNS-Hosts gegeben hat, wird der Server von selbst einen DNS Proxy aufsetzen (univention-bind-proxy), an den alles weitergegeben wird, das sich in der Domain nicht auflösen läßt, und der die Anfragen nach außen schickt, wenn er die Ergebnisse nicht schon im Cache hat. Alle Hosts im inneren Netz müssen per DHCP nur unseren Server als einzigen DNS-Ansprechpartner bekommen, das stellt man am DHCP Service ein.

Ich hoffe ich hab die Gesamtaufgabe einigermaßen erfaßt? Und keine Unklarheiten dazugetan?

Viele Grüße,
Frank Greif.

#6

Hallo Greif,

…danke für die Hinweise. Ich habe jetzt folgendes realisiert mit der Standart univention firewall und zusätlichen einstellungen in der 50_local.sh in Form von
expliziten Freigaben nur auf eth1, als der Schnittstelle für das interne Netz. z.B. in Form von
/sbin/iptables -D INPUT -p “tcp” --dport 80 -j ACCEPT
/sbin/ip6tables -D INPUT -p “tcp” --dport 80 -j ACCEPT
/sbin/iptables -A INPUT -i eth1 -p “tcp” --dport 80 -j ACCEPT
/sbin/ip6tables -A INPUT -i eth1 -p “tcp” --dport 80 -j ACCEPT
, also erst die in 10_univention-firewall_start.sh automatisch erstellten Regeln löschen und wieder nur für eth0 freigeben…

Das Problem ist, dass am Router noch weitere Subnetze hängen die aussen vor bleiben sollen. Auch soll die Management und ssh Konsole nur von innen erreicht werden. Alles soweit OK.

Allerdings scheitere ich wegen mangelnder Kenntnisse an einer passenden Firewall Regel für das Routing für Ports eines bestimmten Rechners ( 192.168.12.12 ) an eth1 nach draussen also über eth0. IP Routing habe ich eingeschaltet lt:

bearbeiten der Datei /etc/sysctl.conf

  • Kommentarzeichen # der Zeile net.ipv4.ip_forward=1 entfernen
  • da dies erst nach einem Neustart greift entweder neu starten oder in
    der Kommandozeile “echo 1 > /proc/sys/net/ipv4/ip_forward” ausführen.

mit einer Firewallregel wie dieser: ( Testweise noch ohne spezielle Portangabe )
/sbin/iptables -A FORWARD -s 192.168.12.12 -i eth1 -o eth0 -j ACCEPT

Geht aber nicht !!

Noch eine Idee ??

Viele Grüße
Marc

#7

Hallo,

Ich glaube der -o Schalter ist falsch an dieser Stelle, oder zumindest bewirkt er nicht das, was Sie sich vorstellen. Wenn iptables aus der Adresse+Netzmaske von eth0 ermittelt, welche Pakete hier gemeint sind, würde die Regel nur auf Pakete zutreffen, die direkt an den Router gerichtet sind, und nicht die, die nach draußen sollen.

Die Einstellung, wohin ein Computer die Pakete schicken soll, für die er keine Zuordnung hat (anhand der IP-Adresse+Netzmaske aller Interfaces), ist der Default Gateway, und der sollte auf diesem Server auf die Adresse des Routers zeigen. In der Ausgabe von route -n auf dem Server muß es eine Zeile geben, deren Zieladresse die 0.0.0.0 ist und die das “G” Flag trägt (restliche Zeilen weggelassen):

root@host:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         <router-ip>     0.0.0.0         UG    0      0        0 wlan0

In UCS gibt es dafür die UCR-Variable gateway beziehungsweise ipv6/gateway.

Auf dem Host 192.168.12.12 sollte man gar nichts tun müssen, da wird der Default Gateway durch DHCP verteilt und muß auf den Server (nicht auf den Router!) zeigen. Gehe ich richtig in der Annahme, daß Ihr UCS Server den DHCP Dienst für seine Clients an eth1 selbst bereitstellt? Dann muß an dem betreffenden DHCP Service Objekt eine “Routing” Policy existieren, die auf die IP von eth1 des Servers verweist, da keiner der Clients den Router direkt erreichen kann.

Sollte das alles klappen, können Sie mit Firewall-Regeln die durchzulassenden Pakete beschränken, vielleicht zuerst das Erreichen der anderen Subnetze (die hinter dem Router liegen?) nach REJECT oder DISCARD führen, danach die erlaubten Ports nach ALLOW und am Ende eine REJECT oder DISCARD Regel die den Rest wegwirft (oder eigentlich auch üblich, die Policy des FORWARD Chains als letzte Regel nutzen).

Viele Grüße
Frank Greif.

Mastodon