Hallo Linuxfreunde, ich habe mal eine Konzeptionsfrage: Aufbau des Netzwerkes: Workstation --> Server --> Firewall --> Internet ------(alles Linuxkisten)-------- Dial-up-Verbindung, Home-Netzwerk Wie sollte ich DNS konfigurieren? Momentan hab ich einen Master DNS auf dem Server für die Home PC's keine öffentlichen Domains. Die Anfragen aus dem LAN werden vom Server --> ISP DNS-Server aufgelöst. Was wäre sinnvoll aus sicherheitstechnischen Gründen? Master DNS auf Firewall und Caching-only auf Server oder Master DNS auf Firewall und Slave auf Server oder Master DNS auf Server und nichts auf der Firewall ? Für Kommentare wäre ich sehr dankbar. -- MfG Waldemar Brodkorb Linux rulez! --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Waldemar Brodkorb wrote:
Hallo Linuxfreunde,
ich habe mal eine Konzeptionsfrage: Aufbau des Netzwerkes: Workstation --> Server --> Firewall --> Internet ------(alles Linuxkisten)--------
Dial-up-Verbindung, Home-Netzwerk Wie sollte ich DNS konfigurieren? Momentan hab ich einen Master DNS auf dem Server für die Home PC's keine öffentlichen Domains. Die Anfragen aus dem LAN werden vom Server --> ISP DNS-Server aufgelöst.
Was wäre sinnvoll aus sicherheitstechnischen Gründen? Master DNS auf Firewall und Caching-only auf Server oder Master DNS auf Firewall und Slave auf Server oder Master DNS auf Server und nichts auf der Firewall ?
Für Kommentare wäre ich sehr dankbar.
Hi Waldi, Wenns sicher sein soll, wuerde ich eine Firewall immer nur *einzig* und *allein* Firewall sein. Auf einer Firewall sollte es *nicht* moeglich sein, sich ueber das Netz auf irgendeine Art und Weise einloggen zu koennen. Desweiteren sollten alle Ports gesperrt werden. Sie sollte eben nur mit ein paar IPCHAINS-Regeln den Verkehr zwischen zwei Interfaces hin und her schieben. IMHO ist jeder Netzwerkdienst auf einer Firewall ein Risiko. Ich wuerde DNS daher auf den Server hinter der FW stellen. Gruss Marc -- .~. *** /V\ ************************************************************ * // \\ Center of Excellence Linux * Marc Schiffbauer * * /( )\ * Siemens ITS GmbH & Co. OHG * ** ^`~'^ ** mailto:Marc.Schiffbauer@koe.siemens.de ***************** --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
* Marc Schiffbauer wrote on Fri, Mar 31, 2000 at 09:24 +0200:
Wenns sicher sein soll, wuerde ich eine Firewall immer nur *einzig* und *allein* Firewall sein.
Yepp, und Firewall ist Packet Filter plus Proxies (plus logging etc.pp)
Auf einer Firewall sollte es *nicht* moeglich sein, sich ueber das Netz auf irgendeine Art und Weise einloggen zu koennen.
Und wie administrierst Du sie dann?
IMHO ist jeder Netzwerkdienst auf einer Firewall ein Risiko. Ich wuerde DNS daher auf den Server hinter der FW stellen.
Wenn er kein DNS nach außen anbieten muß, kann er ihn hinter Masquerading stellen. Ich finde es auch nicht schlecht, wie in der anderen Mail beschrieben einen Forward-only auf die Firewall zu stellen, der genau die ISP Server fragen darf, damit müssen die Packetfilter nur domain packets von drei Maschinen durchlassen. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Steffen Dettmer wrote:
* Marc Schiffbauer wrote on Fri, Mar 31, 2000 at 09:24 +0200:
Wenns sicher sein soll, wuerde ich eine Firewall immer nur *einzig* und *allein* Firewall sein.
Yepp, und Firewall ist Packet Filter plus Proxies (plus logging etc.pp)
proxies? Meinst du jetzt Squid oder sowas? Nun, wenn jemand sich zu Hause nen Rechner fuer den Internetzugang hinstellt, gebe ich Dir recht. Wenn es aber im professionellen Umfeld realisiert werden soll, sprich, wenn du zB. das Intranet einer Firma mit 500 MAs vor Angreifern aus dem Internet schuetzen sollst, weil es in der Firma sehr sensitive Daten gibt und Du die Verantwortung hast, dann: Auf keinen Fall!
Auf einer Firewall sollte es *nicht* moeglich sein, sich ueber das Netz auf irgendeine Art und Weise einloggen zu koennen.
Und wie administrierst Du sie dann?
lokal? Die Firewall ist das Glied zwischen Internet und DMZ. In obigem Beispiel benoetigt man vielleicht eine Firewall. Wer eine Firewall remote adminstriert, ist IMHO sehr leichtsinnig.
IMHO ist jeder Netzwerkdienst auf einer Firewall ein Risiko. Ich wuerde DNS daher auf den Server hinter der FW stellen.
Wenn er kein DNS nach außen anbieten muß, kann er ihn hinter Masquerading stellen. Ich finde es auch nicht schlecht, wie in der anderen Mail beschrieben einen Forward-only auf die Firewall zu stellen, der genau die ISP Server fragen darf, damit müssen die Packetfilter nur domain packets von drei Maschinen durchlassen.
Kommt wieder auf das Umfeld an. Gruss Marc -- +-----Du hast eine nützliche Linuxseite? Du suchst eine?-----------+ | --> http://www.Links2Linux.de <-- | | | +---Registered-Linux-User-#136487------------http://counter.li.org + --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
* Marc Schiffbauer wrote on Fri, Mar 31, 2000 at 22:19 +0200:
Steffen Dettmer wrote:
Yepp, und Firewall ist Packet Filter plus Proxies (plus logging etc.pp)
proxies? Meinst du jetzt Squid oder sowas?
Na ja, Squid ist schon ein ziemlicher Hammer an Proxy, aber ist einer, ja.
Wenn es aber im professionellen Umfeld realisiert werden soll, sprich, [...] dann:
Auf keinen Fall!
Redest Du von Packetfiltern? Firewall ist Packetfilter plus Proxies (etc), egal, wo sie rumsteht... Falls Dich das interessiert, da gibt's im Internet viel Doku zu, z.B. für den Überblick vielleicht www.whatis.com.
Und wie administrierst Du sie dann?
lokal? Die Firewall ist das Glied zwischen Internet und DMZ.
AFAIK ist DMZ in der Regel die Zone, die noch vom Internet aus ereicht werden kann, im "klassischen Fall" also genau vor der Firewall (wenns eben eine und nur eine gibt). Derartige Begriffe werden vermutlich aber auch anders verwendet...
Wer eine Firewall remote adminstriert, ist IMHO sehr leichtsinnig.
Na, geht in der Praxis oft nicht anders, weil man nicht für jeden erlaubten User ins Rechenzentrum rennen kann. Und starke kryptographie ist auch schon was wert :) Wir reden ja nicht von telnet :) Wenn man da IPSec oder SSH oder SSL oder Hardwarekryptographie verwendet (je nach Geldbeutel :)), ist das IMHO nicht leichtsinnig (gibt ja auch BSI zertifizierte Lösungen). oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Am Fre, 31 Mär 2000 schrieb Steffen Dettmer:
* Marc Schiffbauer wrote on Fri, Mar 31, 2000 at 09:24 +0200:
Wenns sicher sein soll, wuerde ich eine Firewall immer nur *einzig* und *allein* Firewall sein.
Yepp, und Firewall ist Packet Filter plus Proxies (plus logging etc.pp)
Apropos Proxies, wenn ich auf der Firewall Proxies laufen lasse kann ich zum Beispiel das IP-Forwarding komplett abschalten, das sollte doch die Sicherheit auch erhöhen oder nicht? Oder sollten die Proxies lieber hinter der Firewall auf dem Server laufen ? Gibts da Vor- oder Nachteile ?
Auf einer Firewall sollte es *nicht* moeglich sein, sich ueber das Netz auf irgendeine Art und Weise einloggen zu koennen.
Und wie administrierst Du sie dann?
Stimmt, ich denke SSH sollte ausreichend sicher sein um das einloggen über Port 22 zulassen zu können.
IMHO ist jeder Netzwerkdienst auf einer Firewall ein Risiko. Ich wuerde DNS daher auf den Server hinter der FW stellen.
Wenn er kein DNS nach außen anbieten muß, kann er ihn hinter Masquerading stellen. Ich finde es auch nicht schlecht, wie in der anderen Mail beschrieben einen Forward-only auf die Firewall zu stellen, der genau die ISP Server fragen darf, damit müssen die Packetfilter nur domain packets von drei Maschinen durchlassen.
Denke ich auch. -- MfG Waldemar Brodkorb Linux rulez! --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
* Waldemar Brodkorb wrote on Sat, Apr 01, 2000 at 12:00 +0200:
Am Fre, 31 Mär 2000 schrieb Steffen Dettmer:
* Marc Schiffbauer wrote on Fri, Mar 31, 2000 at 09:24 +0200:
Wenns sicher sein soll, wuerde ich eine Firewall immer nur *einzig* und *allein* Firewall sein.
Apropos Proxies, wenn ich auf der Firewall Proxies laufen lasse kann ich zum Beispiel das IP-Forwarding komplett abschalten, das sollte doch die Sicherheit auch erhöhen oder nicht?
Yepp, dann sind die Netze auf Netzwerklayer getrennt. Das gilt dann als sehr sicher, solange den Proxies vertraut wird (sendmail ist zwar technisch gesehen auch als Proxy verwendbar, davon würde ich aber dringend abraten :) ). Braucht man einzelne Dinge dann doch, kann man die "relayen", d.h. einen Proxy nehmen, der die Daten ungesehen durchreicht (z.B. rinetd), falls man für eine Sache keinen passenden Proxy hat. Das hat dann den Vorteil, daß auch eingeschleuste Trojaner nicht mehr so richtig funktionieren.
Oder sollten die Proxies lieber hinter der Firewall auf dem Server laufen ?
Na, verstehe die Frage nicht... Also, Firewall ist ein Oberbegriff für Proxies (mit den entsprechenden Eigenschaften: klein, stabil, filtern bestimmter Daten, robust programmiert; cache usw. gehört eben nicht dazu) und Packetfiltern. Gut gehen auch Packetfilter (in den Routern), dann einen Server, der nicht routet, aber Proxies hat, und der nächste Router macht wieder Packetfilterungen (z.B. Cisco ACLs usw.).
Und wie administrierst Du sie dann?
Stimmt, ich denke SSH sollte ausreichend sicher sein um das einloggen über Port 22 zulassen zu können.
Genau, und alle Packetfilter akzeptieren nur Packete für firewall port 22, wenn sie von einer der Admin Kisten kommen (die müssen natürlich auch gewisse Sicherheitsvorraussetzungen erfüllen). oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Oder sollten die Proxies lieber hinter der Firewall auf dem Server laufen ?
Na, verstehe die Frage nicht... Also, Firewall ist ein Oberbegriff für Proxies (mit den entsprechenden Eigenschaften: klein, stabil, filtern bestimmter Daten, robust programmiert; cache usw. gehört eben nicht dazu) und Packetfiltern. Gut gehen auch Packetfilter (in den Routern), dann einen Server, der nicht routet, aber Proxies hat, und der nächste Router macht wieder Packetfilterungen (z.B. Cisco ACLs usw.).
Ja so ähnlich meinte ich das, einen PC der Proxies installiert hat und nicht forwardet und dahinter den Paketfilter. Also: Inneres Netz -- Proxy-Server -- Paket-Filter-Firewall -- Internet (ein PC) (auch ein PC) Oder wäre das unsinnvoll, wenn der Proxy-Server gleichzeitig noch Samba oder NFS-Dienste bereitstellt. Sollte dann eher der Firewall-PC beides übernehmen, Application-Firewall und Paket-Filter. Wobei du ja sagst das Caching nicht zu den Aufgaben der Firewall gehören sollte. Also Proxy ohne Cache wie z.B. Socks 5 oder werfe ich da was durcheinander ? -- MfG Waldemar Brodkorb Linux rulez! --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
IMHO ist jeder Netzwerkdienst auf einer Firewall ein Risiko. Ich wuerde DNS daher auf den Server hinter der FW stellen.
Aber ich muß doch dann trotzdem den Port 53 für den DNS freischalten damit der Server die Anfragen an den ISP-DNS durchläßt. Ich würde zum jetzigen Zeitpunkt auf dem Server einen DNS-Server der für die Home-Domain zuständig ist installieren und den Caching-DNS auf der Firewall abfragt, wenn es um fremde Domains geht. Der Caching-DNS auf dem Firewall soll dann in ein /chroot-Verzeichnis installiert werden. Das sollte doch AFAIK keinen Nachteil in Bezug auf Sicherheit einbringen. Oder ? Port 53 muß so oder so für die IP-Nummern des ISP-DNS freigeschaltet werden. Gibt es eigentlich noch weitere Informationen zu chroot, nicht nur in Kombination mit bind ? RTFM erwünscht. :-) -- MfG Waldemar Brodkorb Linux rulez! --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Waldemar Brodkorb wrote:
IMHO ist jeder Netzwerkdienst auf einer Firewall ein Risiko. Ich wuerde DNS daher auf den Server hinter der FW stellen.
Aber ich muß doch dann trotzdem den Port 53 für den DNS freischalten damit der Server die Anfragen an den ISP-DNS durchläßt.
Ob er nur Port 53 fuer DNS durchlaesst, oder selbst ein DNS ist, ist aber noch ein grosser Unterschied, oder?
Ich würde zum jetzigen Zeitpunkt auf dem Server einen DNS-Server der für die Home-Domain zuständig ist installieren und den Caching-DNS auf der Firewall abfragt, wenn es um fremde Domains geht. Der Caching-DNS auf dem Firewall soll dann in ein /chroot-Verzeichnis installiert werden.
ist auf jeden Fall sicherer.
Das sollte doch AFAIK keinen Nachteil in Bezug auf Sicherheit einbringen. Oder ? Port 53 muß so oder so für die IP-Nummern des ISP-DNS freigeschaltet werden.
Wie definierst Du Nachteil? Das kommt immer drauf an, in welchem Umfeld die Firewall laeuft. (und wie paranoid der Admin ist ;-) ) Aber im ernst: Wenns so sicher sein soll wie eben moeglich, dann wuerde ich, wie gesagt, sonst nix drauf machen.
Gibt es eigentlich noch weitere Informationen zu chroot, nicht nur in Kombination mit bind ? RTFM erwünscht. :-)
weis nix ;) Gruss Marc -- +-----Du hast eine nützliche Linuxseite? Du suchst eine?-----------+ | --> http://www.Links2Linux.de <-- | | | +---Registered-Linux-User-#136487------------http://counter.li.org + --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Am Fre, 31 Mär 2000 schrieb Marc Schiffbauer:
Waldemar Brodkorb wrote:
IMHO ist jeder Netzwerkdienst auf einer Firewall ein Risiko. Ich wuerde DNS daher auf den Server hinter der FW stellen.
Aber ich muß doch dann trotzdem den Port 53 für den DNS freischalten damit der Server die Anfragen an den ISP-DNS durchläßt.
Ob er nur Port 53 fuer DNS durchlaesst, oder selbst ein DNS ist, ist aber noch ein grosser Unterschied, oder?
Aber kein großer oder? Wenn ich sowieso nur die IP-Adressen von meinem ISP anfrage. (forward only) Und zusätzlich keine Anfragen von außen zu lasse. (allow-query,listen on) Und dann noch als chroot, ich denke nicht das es die Sache in irgendeiner Weise unsicherer macht, dann auch auf der Firewall einen Caching-DNS zu haben oder?
Ich würde zum jetzigen Zeitpunkt auf dem Server einen DNS-Server der für die Home-Domain zuständig ist installieren und den Caching-DNS auf der Firewall abfragt, wenn es um fremde Domains geht. Der Caching-DNS auf dem Firewall soll dann in ein /chroot-Verzeichnis installiert werden.
ist auf jeden Fall sicherer.
Das sollte doch AFAIK keinen Nachteil in Bezug auf Sicherheit einbringen. Oder ? Port 53 muß so oder so für die IP-Nummern des ISP-DNS freigeschaltet werden.
Wie definierst Du Nachteil? Das kommt immer drauf an, in welchem Umfeld die Firewall laeuft. (und wie paranoid der Admin ist ;-) )
Du kennst mich doch, Marc, ich bin sehr paranoid :-)) Ich möchte das halt nur mal korrekt durchexercieren! Und ich finde das in Sicherheitssachen die Details sehr wichtig sind.
Aber im ernst: Wenns so sicher sein soll wie eben moeglich, dann wuerde ich, wie gesagt, sonst nix drauf machen.
Ja ?
Gibt es eigentlich noch weitere Informationen zu chroot, nicht nur in Kombination mit bind ? RTFM erwünscht. :-)
weis nix ;)
Schade :-( -- MfG Waldemar Brodkorb Linux rulez! --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
* Waldemar Brodkorb wrote on Sat, Apr 01, 2000 at 11:54 +0200:
Am Fre, 31 Mär 2000 schrieb Marc Schiffbauer:
Waldemar Brodkorb wrote:
Aber kein großer oder? Wenn ich sowieso nur die IP-Adressen von meinem ISP anfrage. (forward only) Und zusätzlich keine Anfragen von außen zu lasse. (allow-query,listen on)
... und das auch so in den input rules definierst.
Und dann noch als chroot, ich denke nicht das es die Sache in irgendeiner Weise unsicherer macht, dann auch auf der Firewall einen Caching-DNS zu haben oder?
Na jaaa... Sicher ist immer so ein Ding. Ein Hacker könnte ja Deinen ISP DNS hacken, und dann gibts noch ein ganz besonderes Sicherheitsloch... Na ja. Aber steht der DNS Server intern, ist's noch schlimmer, wenn da ein Hacker raufkommen würde. chroot macht IMHO nur mit nicht-root Processen Sinn (kann ja bind inzwischen auch), und gilt IIRC nicht als 100% Sicher.
Gibt es eigentlich noch weitere Informationen zu chroot, nicht nur in Kombination mit bind ? RTFM erwünscht. :-)
Einfach mal mit rumspielen! mit ldd schauen, was ein tool benötigt, und immer nach /chroot/lib kopieren usw., bis es geht :) Oder statisch linken, ist einfacher. Dann schnappst Du Dir chroot(1), und startest damit Deinen Kram... So z.B.: mkdir /tmp/bin cp `which sash` /tmp/bin ( cd /tmp ; chroot /tmp /bin/sash ) Falls Du sash installiert hast (ist statisch gelinkt, kann ls usw. als built-in)... oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
participants (3)
-
linux@netcologne.de
-
marc.schiffbauer@links2linux.de
-
steffen@dett.de