Mailinglist Archive: opensuse-de (1531 mails)

< Previous Next >
Re: Linux Sicherheit
  • From: Steffen Dettmer <steffen@xxxxxxx>
  • Date: Sun, 23 Dec 2007 21:51:52 +0100
  • Message-id: <20071223205152.GB3584@xxxxxxxxxxx>
* 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?

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.

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.

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.

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.

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).

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.

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.

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. Ob man da
Virenscan mit einbaut oder nicht, muss man sehen (das ständige geupdate
ist zumindestens theoretisch eine ziemliche Sicherheitsgefahr). 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). 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).

(die kurze Antwort ist also "hängt davon ab", aber das ist wohl wenig
hilfreich :))

oki,

Steffen

--
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.

--
Um die Liste abzubestellen, schicken Sie eine Mail an:
opensuse-de+unsubscribe@xxxxxxxxxxxx
Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken
Sie eine Mail an: opensuse-de+help@xxxxxxxxxxxx

< Previous Next >