Hallo, Sorry Steffen, ich habe beim Antworten leider falsch geklickt! Am Sonntag, 23. Dezember 2007 schrieb Steffen Dettmer:
* R. C. Graulich wrote on Sun, Dec 23, 2007 at 19:21 +0100:
Ich plane ein mittelgroßes Netz (50++ homogene Clients), derzeit allein mit w2k3-Server, um eine DMZ mit interner und externer Firewall zu erweitern.
wie dick ist der uplink?
Falsche Frage;-) es handelt sich um aDSL 6000. Mehr ist nicht drin.
Für die externe Firewall stehen mir alternativ ein einfacher Router (D-Link) und/oder ein älterer PC mit OSS-10.3 (Oss ist mir lediglich vertrauter als slackware/Debian) zur Verfügung. Der Router kann DynDNS und hat eine komfortabel konfigurierbare Firewall. Was würdet ihr vorziehen und warum?
Ist mit "Firewall" hier lediglich ein Paketfilter gemeint? Wird Masquerading verwendet? Wenn ja, könnte der D-Link Router ja eventuell tatsächlich reichen; portforwarding ähnliche Sonderregeln, die man für die DMZ braucht, müsste er natürlich unterstützen. Wenn er reicht, würde ich ihn nehmen, weil einfacher.
Masquerading steht noch nicht genau fest. Hängt vom Proxy ab, und davon, ob auch "fremde" Benutzer mit ihren Notebooks ohne Domainen Account in das Internet dürfen.
Für die Interne Firewall soll ein relativ schneller PC als Gateway, ebenfalls mit OSS 10.3 eingesetzt werden.
FÜr einen Paketfilter an einer nicht allzufetten Leitung (wenns um ein paar wenige MBit geht) braucht man vermutlich gar nicht unbedingt einen schnellen PC. Kommt aber auf vieles an. Könnte mir vorstellen, dass ein aktuelles Firewallscript schnell automatisch (mehr oder weniger ungewollt) Tausende von Regeln erzeugt. Wenn man mehrere MBit VPN mit starker Verschlüsselung machen möchte, sollte die Rechenleistung natürlich auch nicht zu knapp sein.
VPN wird bestenfalls von mir zur gelegentlichen Fernwartung des W2k3 Servers genutzt. Der gewollte Zugriff von außen ist ansonsten eher die Ausnahme. Eigentlich wird nur die Fernwartung (vpn/ssh) benötigt. Der Apache2 in der DMZ ist für eine noch zu schaffende Groupwarelösung angedacht und dient ansonsten kleinen Entwicklungsprojekten. Er könnte natürlich auch im LAN stehen, doch sollen hier die Schülern das Konzept einer DMZ kennenlernen.
Derzeit laufen darauf, wegen eines massiven Softwareupdates auf dem internen und temporär inaktiven w2k3-Servers, die Serverdienste:
Serverdienste, die wirklich wichtig sind, hab ich am liebsten auf virtuellen Maschinen, aber das muss man natürlich mit Performance oder mehr Hardware bezahlen. Virtuelle Maschinen kann man aber im Problemfall schnell mal auf andere Hardware schmeissen.
Nice to have;-)
Apache2, DNS und DHCP. DHCP soll dort deaktiviert werden, da dies auf dem w2k3-Server laufen soll.
Ist solch eine Häufung von Serverdiensten auf der internen Firewall sinnvoll?
na ja, ich würde das lieber vermeiden wollen. Dann lieber ne kleine alte Maschine zusätzlich, wenn möglich. Ich würde auf einer Firewallmaschine jedenfalls keine Useraccounts wollen, auch keine virtuellen. Ein Webserver für statische Seiten geht natürlich erstmal, aber wenn da auch noch persönliche Seiten (~/public_html) draufliegen sollen oder so, würde ich lieber eine extra-Maschine machen.
Oder sollte ich da eher zwei Rechner, einen für die Firewall und einen für die restlichen, ausschließlich intern genutzten Serverdienste, reservieren? Der zweite Rechner müßte ein älteres Modell bleiben.
Ich würde das ältere dann als Firewall verwenden. Meist meint man ja damit eher einfache Paketfilter. Dafür braucht man bei kleineren uplinks (wenige MBit) keine besonders grosse CPU. Wenn man verschlüsseln muss und/oder ein sehr komplexes Setup hat, würde ich natürlich unbedingt einen Performance-Test machen (die Scripte dann natürlich unbedingt aufheben).
Was sind eure Erfahrungen?
Je einfacher, desto besser die Chancen, dass etwas funktioniert. Keep it simple, stupid.
Ja, das sehe ich eigentlich auch so und wenn ich es auch nirgends so sehe ...
Das gilt auch für die Konfiguration. Wenige Dienste, einfache Regeln usw. Wird ja schnell unübersichtlich. Manchmal werden Sachen einfach, wenn man statt 2 auch mal 3 oder 4 Netzwerkkarten einbaut (da kann man die Zugriffsbereiche segmentieren, ohne intelligenten Switches programmieren zu müssen etc).
Das währe machbar und doch nicht nötig. Könnte mal erforderlich sein, wenn wirklich alle Schüler mit ihren eigenen Notebooks über das Schulnetz in das Internet wollten.
Als Paketfilter müsste ich auch gar nicht unbedingt SuSE nehmen wollen. Lieber was kleines. Da gibts ja etliche Projekte. Würde das Filesystem vielleicht sogar auf DVD brennen (man kann ja ne RW nehmen), schwieriger zu manipulieren, wenn gehackt, da gabs Projekte, hab leider gerade keinen Namen im Kopf. Vielleicht geht das auch mit http://leaf.sourceforge.net/ oder OpenWRT.
Da hatte ich auch schon drüber nachgedacht, falls es eine reine Firewall werden sollte.
Hat man mehrere einfache und von einander unabhängige Teile (z.B. Router/Firewalls/Server), kann man die oft einfacher administrieren. Man updated dann nur den Paketfilter usw. Sonst (all-in-one) hat man vielleicht das Problem, dass man den Paketfilter nicht aktualisieren kann, weil das neue PHP dann die Anwendung XYZ nicht mehr richtig ausführt (gut ist, wenn mans voher weiss, weil man es wirklich getestet hat :)). Daher finde ich die Idee mit den dedizierten (ggf. virtuellen) Servern gut. Wenn am Ende die Anwendung XYZ dann heute noch auf SuSE 8.2 laufen muss, störts ja kaum, wenn man der Firewall trauen kann, weil da alle patches (und möglichst wenig) drauf sind.
Das stimmt natürlich und wehe man übersieht dann den einen oder anderen Patch im alltäglichen Stress der Nichtigkeiten.
Wenn es um ein "normales Netz" geht, reicht das oft vermutlich schon. Für höheren Schutzbedarf muss man zusehen, dass keine Verbindung direkt nach aussen oder gar umgekehrt möglich ist. Ob die DMZ unter diese Regel fällt oder nicht und wie im Detail, muss man sehen. Intern müsste dann jedenfalls *alles* über einen entsprechenden Proxy.
Ein Proxy erscheint mir sehr wahrscheinlich. Derzeit teste ich gerade, ob der eine gewisse Performancesteigerung bringt. Ich erwarte das, weil die üblichste Nutzung so aussieht: 30 Clients starten dieselben Abfragen (Google, Wiki, etc.) nahezu gleichzeitig, weil alle Schüler in etwa die gleiche Aufgabe abarbeiten.
Ob man da Virenscan mit einbaut oder nicht, muss man sehen (das ständige geupdate ist zumindestens theoretisch eine ziemliche Sicherheitsgefahr).
Virenscannern traue ich per se nicht. Die zerschossen mir regelmäßig wichtige Systemkomponenten (winlogon.exe, winvnc.exe, etc.) und jeder traut den Dingern mehr als dem eigenen Verstand ...
Bei HTTP und Mail ist ein Proxy noch eher einfach (kommt natürlich sehr drauf an, wieviel funktionieren muss und was man verbieten möchte etc).
Da bin ich der Auffassung, dass Zensur nicht stattfinden sollte. Also per se ist alles erlaubt. Unsere Schüler sollen ja aufgeklärte Erwachsene werden und lernen, mit dem Internet sinnvoll umzugehen. Der Proxy macht nur als Cache Sinn, da die DSL-Leitung eher als dünn denn als dick zu bezeichnen ist.
Für Mail kann man einen kleinen Mailserver nehmen (was evtl. gegen zu kleine Linuxe wie OpenWRT sprechen könnte). Na ja, und dann muss man sehen, was für Protokolle man wie filtern können muss. Manchmal ist sowas wie SOCKS akzeptabel, manchmal nur für bestimmte Benutzer (wenn man sich den am Paketfilter anmelden kann, was mit Boardmitteln vermutlich erstmal nicht mehr) oder für bestimmte PC (also IPs, geht evtl. in einem einfachen Windows-Netz, da hat ja oft jeder "seinen" PC).
Mail ist kein so dringlicher Service. Aus (fernmelde-)rechtlichen Gründen wird es in absehbarer Zeit erstmal keine eigenen Mail-Dienste im LAN geben.
(die kurze Antwort ist also "hängt davon ab",
ja, die Antwort habe ich oft selbst parat. ;-) Dennoch ist so ein Brainstorming hilfreich, da man sich über seine eigenen Ziele mal selbst klarer werden kann. Wie gesagt, mit Kollegen kann ich Fragen zur IT-Struktur kaum erörtern.
aber das ist wohl wenig hilfreich :))
Im Gegenteil Danke! -- Mit freundlichen Grüßen R. C. Graulich -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org