Suse Linux Server Firewall
Jörg
ich habe schon mehrere "Firewall" System unter Suse Linux (6.3,7.0)
aufgesetzt. D.h. an sich weiss ich was IPChains als solches kann und was
Paket-Filterung bedeuted und wie ich es einsetzen muss. 3. Grundlegene
Fragen zu dem Thema habe ich;
1) Was kann eine - nennen wir es waschechte - Firewall mehr als
Paket-Filtering bei Linux?
2) Bekommt man ein Netz mit einen Paket-Filterung sicher (ein Netz ist nie
sicher solange die Kabel stecken, aber ich hoffe ihr wisst was ich meine)?
3) wo ist kurzgefasst der Unterschied zwischen IPChains und IPTables?
Ich bedanke mich im Vorraus
JB
Andreas Kretschmer
^^^^^^
da fehlt der Realname. Fixe das bitte.
> 1) Was kann eine - nennen wir es waschechte - Firewall mehr als
> Paket-Filtering bei Linux?
Lese die FAQ. Eine 'Firewall' ist ein Konzept, ein Paketfilter eine
Umsetzung. Eine Kabelschere wäre auch eine Umsetzung.
> 2) Bekommt man ein Netz mit einen Paket-Filterung sicher (ein Netz ist nie
> sicher solange die Kabel stecken, aber ich hoffe ihr wisst was ich meine)?
Das kommt auf das Konzept und die Realisierung an. Eine Firewall schützt
weder vor Viren (sofern Mail durchgeht) noch vor Vogelscheiße auf dem
Autodach.
Du brauchst eine Policy, die vorschreibt, was gehen soll und was nicht.
> 3) wo ist kurzgefasst der Unterschied zwischen IPChains und IPTables?
Es sind Frontends zu netfilter, und zwar verschiedene. Iptables ist
ipchains überlegen, da bessere Möglichkeiten bestehen. Ich kenne
ipchains nicht so genau, habe gleich mit iptables angefangen.
Andreas
--
Diese Message wurde erstellt mit freundlicher Unterstützung eines frei-
laufenden Pinguins aus artgerechter Freilandhaltung. Er ist garantiert
frei von Micro$oft'schen Viren. (#97922 http://counter.li.org)
Was, Sie wissen nicht, wo Kaufbach ist? : N 51.05082°, E 13.56889° ;-)
Lasse Kliemann
> 1) Was kann eine - nennen wir es waschechte - Firewall mehr
> als Paket-Filtering bei Linux?
Was ist eine "waschechte Firewall"? Ich fürchte, ich verstehe
diese Frage nicht.
> 2) Bekommt man ein Netz mit einen Paket-Filterung sicher
> (ein Netz ist nie sicher solange die Kabel stecken, aber
> ich hoffe ihr wisst was ich meine)?
Du bekommst ein Netz auch ohne Paketfilter sicher. Kommt eben
auf das Netz an. Wenn zum Beispiel keine Dienste angeboten
werden oder nur solche, die sich vernünftig verhalten,
besteht wenig Bedarf an einem Paketfilter.
> 3) wo ist kurzgefasst der Unterschied zwischen IPChains und
> IPTables?
Bei IPTables kommen die Pakete, die nicht für den Rechner
selber sind, gleich in die FORWARD Chain und nur die Pakete,
die für den Rechner selber bestimmt sind, landen in der INPUT
Chain. Bei IPChains ist das anders, dort landet AFAIK erstmal
alles in der INPUT Chain, was überhaupt 'reinkommt. Ich habe
schon erlebt, wie das zu Schwierigkeiten führen kann.
Man siehe <http://netfilter.gnumonks.org/documentation/HOWTO/
packet-filtering-HOWTO-6.html> und vergleiche mit der
Dokumentation von IPChains.
Jörg Bauer
ein kleines Lan bedient...wir nehmen weiter einen Email-Dienst, Proxy und
einen Virenscanner der der sich automatisch updated....das heisst ich habe
verschiedene Dienste die offen sind.....bekommt man das mit ipchains (bzw
IPTables) abgesichert??
"Andreas Kretschmer" <krets...@kaufbach.delug.de> schrieb im Newsbeitrag
news:rbhd6a...@kaufbach.delug.de...
Andreas Kretschmer
> Ok...dann lass mich die Frage anders stellen...wir nehmen einen Server der
Okay, Realname ist da. Nächste Aufgabe: http://learn.to/quote lesen!
> ein kleines Lan bedient...wir nehmen weiter einen Email-Dienst, Proxy und
> einen Virenscanner der der sich automatisch updated....das heisst ich habe
> verschiedene Dienste die offen sind.....bekommt man das mit ipchains (bzw
> IPTables) abgesichert??
Ja. Ich gehe davon aus, daß all diese Dinge nur Verbindung von innen
nach außen aufbauen, es werden keine Dienste nach außen angeboten.
Richtig?
Iptables unterstützt statful, d.h. es wird nicht nur nach Adresse + Port
gefiltert, sondern auch nach der 'geschichte'. Lese Dir das
Packet-Filtering-HOWTO durch, insbesondere Punkt 5.
Setze einfach solch einen Filter vor Dein Netz und mache Masquerade für
den Mail/Proxyserver. Beachte dabei Punkt 9 des Packet Filtering HOWTO.
Jörg Bauer
> Ja. Ich gehe davon aus, daß all diese Dinge nur Verbindung von innen
> nach außen aufbauen, es werden keine Dienste nach außen angeboten.
> Richtig?
Es sollten lediglich Antworten zurückkommen. ALso keine SYN-bits (gesetzt
dem Fall jede Erstverbindung hat ein SYN-bit ).
> Iptables unterstützt statful, d.h. es wird nicht nur nach Adresse + Port
> gefiltert, sondern auch nach der 'geschichte'. Lese Dir das
> Packet-Filtering-HOWTO durch, insbesondere Punkt 5.
Hab mir das HowTo angeschaut.Punkt 5 zeigt ja erst mal ein kurzes Beispiel.
Wie gesagt, IPTables ist absolutes neuland.Aber unter dem Keyword
Established
versteh ich, das die connection schon aufgebaut ist.Würde das nicht einem
Syn-bit
entsprechen?
> Setze einfach solch einen Filter vor Dein Netz und mache Masquerade für
> den Mail/Proxyserver. Beachte dabei Punkt 9 des Packet Filtering HOWTO.
Warum Masq für Mail und Proxy?Gesetzt dem Fall beide laufen auf dem Server,
hab
ich doch eine Direktverbindung. D.h. Lan connected zum Server, Server Dienst
nimmt
an und erledigt den Rest. Ich dachte bis jetzt, das ich Masq nur brauche
wenn ich Clients
direkt durchleiten will.
Andreas Kretschmer
> Es sollten lediglich Antworten zurückkommen. ALso keine SYN-bits (gesetzt
> dem Fall jede Erstverbindung hat ein SYN-bit ).
Ja, sag ich doch.
>> Iptables unterstützt statful, d.h. es wird nicht nur nach Adresse + Port
>> gefiltert, sondern auch nach der 'geschichte'. Lese Dir das
>> Packet-Filtering-HOWTO durch, insbesondere Punkt 5.
> Hab mir das HowTo angeschaut.Punkt 5 zeigt ja erst mal ein kurzes Beispiel.
> Wie gesagt, IPTables ist absolutes neuland.Aber unter dem Keyword
> Established
> versteh ich, das die connection schon aufgebaut ist.Würde das nicht einem
> Syn-bit
> entsprechen?
Nein, SYN hat nur das aller erste Packet einer Verbindung. Ab dann merkt
sich iptables die Verbindungen, ESTABLISHED sind Pakete zu einer
bestehenden Verbindung, RELATED sind Verbindungen, die zu einer anderen
gehören. Siehe FTP.
Oder anders: Pakete mit SYN sind NEW, und die sind nicht von außen her
erlaubt.
>> Setze einfach solch einen Filter vor Dein Netz und mache Masquerade für
>> den Mail/Proxyserver. Beachte dabei Punkt 9 des Packet Filtering HOWTO.
> Warum Masq für Mail und Proxy?Gesetzt dem Fall beide laufen auf dem Server,
> hab
> ich doch eine Direktverbindung. D.h. Lan connected zum Server, Server Dienst
> nimmt
> an und erledigt den Rest. Ich dachte bis jetzt, das ich Masq nur brauche
> wenn ich Clients
> direkt durchleiten will.
Ja, das stimmt schon, man _kann_ auf dem Paketfilter-Rechner auch
Dienste wie Squid und SMTP anbieten, aber das will man eigentlich nicht.
Eine komplette DMZ halte ich in Deinem Szenario, welches dem bei mir auf
Arbeit sehr ähnlich ist, für übertrieben, aber ich habe einen einfachen
Linuxrechner mit iptables _vor_ das Netz gestellt und muß dann natürlich
sehr wohl NAT machen.
PS.: nachdem nun der Realname und das Quoting stimmt, kannst Du ja noch
etwas an dem etwas eigenartig anmutendem Zeilenumbruch feilen ...
Andreas, diese Woche die 3. Niederlassung der Firma mit sowas versorgt.
Jörg Bauer
> Ja, das stimmt schon, man _kann_ auf dem Paketfilter-Rechner auch
> Dienste wie Squid und SMTP anbieten, aber das will man eigentlich nicht.
> Eine komplette DMZ halte ich in Deinem Szenario, welches dem bei mir auf
> Arbeit sehr ähnlich ist, für übertrieben, aber ich habe einen einfachen
> Linuxrechner mit iptables _vor_ das Netz gestellt und muß dann natürlich
> sehr wohl NAT machen.
Also im Prinzip eine Maschine die die Dienste anbietet, und eine die
filtert?
> PS.: nachdem nun der Realname und das Quoting stimmt, kannst Du ja noch
> etwas an dem etwas eigenartig anmutendem Zeilenumbruch feilen ...
Vielleicht gehört das nicht dazu, aber wie bekomme ich den Zeilenumbruch
anständig hin? Hoffe das hier geht jetzt. Ist das Reader-abhängig?
Andreas Kretschmer
> Also im Prinzip eine Maschine die die Dienste anbietet, und eine die
> filtert?
Ja, so habe ich es. Die Filter-Maschine hat als Dienst nur ssh und macht
nur Masq. für den Mail/Proxy-Rechner. Sicher, das ist noch keine DMZ mit
2 Filtern, aber da wir von außen nicht erreichbar sind und alle
Verbindungen von uns initiiert werden, ist es IMHO ein hinreichend
sicheres Konzept. Direkte Angriffe von innen werden durch die
Firmenleitung ausgeschlossen.
> Vielleicht gehört das nicht dazu, aber wie bekomme ich den Zeilenumbruch
> anständig hin? Hoffe das hier geht jetzt. Ist das Reader-abhängig?
Von "X-Newsreader: Microsoft Outlook Express 6.00.2600.0000" habe ich
genau Null Ahnung. Hilfe könnte hier kommen:
"de.comm.software.newsreader", aber besser wäre es wohl, den Dreck in
der Tonne zu versenken.
Andreas
Urs [Ayahuasca] Traenkner
> > 3) wo ist kurzgefasst der Unterschied zwischen IPChains und IPTables?
> Es sind Frontends zu netfilter, und zwar verschiedene. Iptables ist
> ipchains überlegen, da bessere Möglichkeiten bestehen. Ich kenne
> ipchains nicht so genau, habe gleich mit iptables angefangen.
In kurzgefasst: ipchains ist stateless filtering und iptables
stateful. Das ist der Unterschied.
Gruss Urs...
--
"Ich muss schweigend hinnehmen, was kommt?"
"Euer Leben besteht daraus, oder?"
God's Army II
Andreas Kretschmer
> Aber trotzdem kannst Du iptables mit ipchains welches Du nach eigenem
> Bekunden nicht " so genau" kennst, vergleichen und zu einem Schluss
> kommen?
Iptables ist neuer und hat einiges mehr. Ich habe mich nicht so intensiv
mit ipchains beschäftigt, da zu dem Zeitpunkt, wo ich es brauchte,
iptables verfügbar war. Und ich denke, wer neu mit dem Thema anfängt,
sollte sich mit iptables beschäftigen, nicht mit ipchains, nicht mit
ipfwadm oder wie das beim 2.0-er Kernel noch hieß.
> Was kann denn iptables, was ipchains nicht kann (achtung: als naechtes
> kommt die Frage, wie sich das auf die Sicherheit auswirkt!)?
,----[ lese bitte ]
| Linux User FAQ: iptables: Das Packet-Filtering-HOWTO
| 10. Unterschiede zwischen iptables und ipchains
`----
Das sollte Deine Fragen erklären.
Letztendlich sind beides Frontends zu netfilter, ich ich verstehe Deine
Tonfall nicht ganz, vielleicht kannst Du das ja mal mir erklären.
Jürgen Wexel
> Tonfall nicht ganz, vielleicht kannst Du das ja mal mir erklären.
>
Da ich als ^Laie hier mit Interesse mitgelesen habe würde mich das aber denn
auch mal interessieren , was soll das ?
Jürgen
Andreas Kretschmer
> In Kinderueberaschung sind jetzt die TinkyWinkys (ganz neu) und die
> Schokolade ist nach den neuesten ernaehrungstechnologischen
> Erkenntnissen gemischt worden.
Was willst Du uns damit sagen?
>> Ich habe mich nicht so intensiv
>> mit ipchains beschäftigt, da zu dem Zeitpunkt, wo ich es brauchte,
>> iptables verfügbar war.
> Das ist aber ein merkwuerdiges Argument.
Warum? Weil iptables eine Überarbeitung von ipchains ist, weil es eine
modularere Struktur hat, die IMHO mehr Platz für künftige Erweiterungen
hat? Ich habe angefangen mich damit zu beschäftigen als ich den Bedarf
hatte, dies zu tun.
>> Und ich denke, wer neu mit dem Thema anfängt,
>> sollte sich mit iptables beschäftigen, nicht mit ipchains, nicht mit
>> ipfwadm oder wie das beim 2.0-er Kernel noch hieß.
> Ja und _warum_?
> Weil man mit ipchains und einem 2.2.20 nicht den Thrill beim Lesen der
> Bugtrackinglisten hat?
Mir sind, bis auf ein Problem im Zusammenhang mit Peer-to-Peer - Netzen,
von iptables keine Probleme bekannt. Das in den letzten Tagen bekannt
gewordene Problem trifft mich nicht, daher habe ich auch keinen Thrill.
> Wenn es keine Rolle spielt, da beides letztendlich das selbe macht (wie
> Du das jetzt behauptest), wieso empfielst Du dann iptables?
Warum fährst Du ein schnelles Auto, wenn es ein Dreirad auch tun würde?
Dort bräuchtest Du keinen Airbag.
Was soll dieser Krieg ipchains <-> iptables?
Nenne doch bitte Deine Gründe gegen iptables, ich bin immer bereit, mich
über Fehler meinerseits belehren zu lassen. Nur tue es bitte sachlich.
Andreas Kretschmer
> Du, _ich_ kenne den Unterschied. Die Frage ist, ob _Du_ den auch kennst.
Nur mal so: warum beantwortest Du dann nicht Frage 3 des Fragestellers?
Felix von Leitner
> ich habe schon mehrere "Firewall" System unter Suse Linux (6.3,7.0)
> aufgesetzt. D.h. an sich weiss ich was IPChains als solches kann und was
> Paket-Filterung bedeuted und wie ich es einsetzen muss. 3. Grundlegene
> Fragen zu dem Thema habe ich;
> 1) Was kann eine - nennen wir es waschechte - Firewall mehr als
> Paket-Filtering bei Linux?
Äh, du behauptest, mehrere Firewall-Systeme mit Linux aufgesetzt zu
haben, und jetzt fragst du uns, was Firewalls eigentlich mehr tun als
Pakete zu filtern?! Merkst du eigentlich noch was?
> 2) Bekommt man ein Netz mit einen Paket-Filterung sicher (ein Netz ist nie
> sicher solange die Kabel stecken, aber ich hoffe ihr wisst was ich meine)?
Nein.
> 3) wo ist kurzgefasst der Unterschied zwischen IPChains und IPTables?
Beginnt beim 3. Buchstaben. ;)
--
* Florian:
Florian, alte Säge! Was macht die Geschlechtskrankheit? Oder
sollte ich dich mit einem anderen Florian verwechselt haben?
--Thorsten Wiegel in de.comp.os.unix.shell
Rainer Weikusat
> Guido Hennecke <news-0...@debian.dyndns.org> wrote:
> > Aber trotzdem kannst Du iptables mit ipchains welches Du nach eigenem
> > Bekunden nicht " so genau" kennst, vergleichen und zu einem Schluss
> > kommen?
>
> Iptables ist neuer und hat einiges mehr.
zB Fehler.
[ "tiefergelegt" ]
Das ist wohl kaum eine technische Kategorie.
> > Was kann denn iptables, was ipchains nicht kann
Cisco-Fans beeindrucken.
> > (achtung: als naechtes
> > kommt die Frage, wie sich das auf die Sicherheit auswirkt!)?
Negativ.
Ralf Gross
--
Right now, I'm listening to...
Artist: King L
Album : Great Day For Gravity # Song: The Dumbest Story
Ralf Gross
>
>> > 3) wo ist kurzgefasst der Unterschied zwischen IPChains und IPTables?
>
>> Es sind Frontends zu netfilter, und zwar verschiedene. Iptables ist
>> ipchains überlegen, da bessere Möglichkeiten bestehen. Ich kenne
>> ipchains nicht so genau, habe gleich mit iptables angefangen.
>
>In kurzgefasst: ipchains ist stateless filtering und iptables
>stateful. Das ist der Unterschied.
Mir gefällt die Trennung con INPUT/OUTPUT und FORWARD chain, ist für
mich einfach übersichlicher und logischer. Stateful finde ich
persönlich auch nützlich, wobei da ja die Meinungen auseinandergehen.
Ralf
Philipp Schulte
> * Ralf Gross <tat...@gmx.de> wrote:
> > Mir gefällt die Trennung con INPUT/OUTPUT und FORWARD chain, ist für
> > mich einfach übersichlicher und logischer.
>
> Was genau meinst Du damit?
Ich bin mir sicher, daß er damit die Tatsache meint, daß bei iptables
Pakete, die nicht für den filternden Rechner bestimmt sind, sondern
nur weitergeleitet werden, lediglich FORWARD und nicht auch
INPUT/OUTPUT passieren - im Gegensatz zu ipchains.
Und ich bin mir genauso sicher, daß du genau wußtest, was Ralf
meinte. Ich bin mir nur nicht sicher, was du hier versuchst.
Phil
Ralf Gross
>>>In kurzgefasst: ipchains ist stateless filtering und iptables
>>>stateful. Das ist der Unterschied.
>> Mir gefällt die Trennung con INPUT/OUTPUT und FORWARD chain, ist für
>> mich einfach übersichlicher und logischer.
>
IPTABLES
Incoming / \ Outgoing
-->[Routing ]--->|FORWARD|------->
[Decision] \_____/ ^
| |
v ____
___ / \
/ \ |OUTPUT|
|INPUT| \____/
\___/ ^
| |
----> Local Process ----
Bei ipchains gingen noch alle Packete durch die INPUT/OUTPUT chain,
auch die, die eigentlich nur für FORWARD bestimmt waren. Entsprechend
musste man für IN/OUT ebenfalls Regeln erstellen.
Ralf
Jörg Bauer
> Thus spake Jörg (cald...@gmx.de):
> > ich habe schon mehrere "Firewall" System unter Suse Linux (6.3,7.0)
> > 1) Was kann eine - nennen wir es waschechte - Firewall mehr als
> > Paket-Filtering bei Linux?
>
> Äh, du behauptest, mehrere Firewall-Systeme mit Linux aufgesetzt zu
> haben, und jetzt fragst du uns, was Firewalls eigentlich mehr tun als
> Pakete zu filtern?! Merkst du eigentlich noch was?
Ja, manchmal merke ich noch was. Z.B. die "" um das Wort Firewall
> > 2) Bekommt man ein Netz mit einen Paket-Filterung sicher (ein Netz ist
nie
> > sicher solange die Kabel stecken, aber ich hoffe ihr wisst was ich
meine)?
>
> Nein.
Warum?
> > 3) wo ist kurzgefasst der Unterschied zwischen IPChains und IPTables?
>
> Beginnt beim 3. Buchstaben. ;)
Sehr schön.
Nachdem ich mir die ges. Diskussion durchgelesen habe bin ich teils schlauer
teils unentschlossener. Was wäre denn jetzt ein geeigneter Paketfilter um
z.B. eine Maschine zu "sichern", welche vor einem Proxy/Mail System steht,
welches wiederum ein LAN bedient?
Ralf Gross
>* Ralf Gross <tat...@gmx.de> wrote:
>> Guido Hennecke (news-0...@debian.dyndns.org) wrote:
>>>* Ralf Gross <tat...@gmx.de> wrote:
>>>> Mir gefällt die Trennung con INPUT/OUTPUT und FORWARD chain, ist für
>>>> mich einfach übersichlicher und logischer.
>>>Was genau meinst Du damit?
>> Bei ipchains gingen noch alle Packete durch die INPUT/OUTPUT chain,
>> auch die, die eigentlich nur für FORWARD bestimmt waren. Entsprechend
>> musste man für IN/OUT ebenfalls Regeln erstellen.
>
>dass die entsprechenden Pakete ueberhaupt in die Forward Chain kommen
>bzw. auch den Rechner wieder verlassen koennen.
Es stört mich eben etwas, daß weitergeleitet Packete zwangsweise auch
durch die INPUT und OUTPUT chain gehen und damit ja AFAIK auch
mitgezählt werden. Den iptables Ansatz finde ich da logischer.
>Mir faellt aber eigentlich kein Szenario auf Anhieb ein, bei dem man da
>wirklich mehr als 2 oder drei Regeln fuer brauchen sollte.
Für ipchains habe ich noch nicht so viel skripte geschrieben, aber das
läßt sich mit ipchains sicher auch geschickt lösen.
>Bei ipchains musst Du eben _anders_ arbeiten, als bei iptables (alleine
>deswegen kann ich irgendwelchen Scripts, die ipchains Regeln in iptables
>Regeln "umwandeln" nichts abgewinnen).
Keine Frage. Es bleibt auch immer etwas Geschamcksache, mit was man
lieber arbeitet.
An iptables stört mich eher, das es REJECT nicht als default Policy
gibt.
Ralf
Lasse Kliemann
> > Bei ipchains gingen noch alle Packete durch die
> > INPUT/OUTPUT chain, auch die, die eigentlich nur für
> > FORWARD bestimmt waren. Entsprechend musste man für
> > IN/OUT ebenfalls Regeln erstellen.
>
> dafuer sorgen, dass die entsprechenden Pakete ueberhaupt in
> die Forward Chain kommen bzw. auch den Rechner wieder
> verlassen koennen.
>
> bei dem man da wirklich mehr als 2 oder drei Regeln fuer
> brauchen sollte.
Das größte Problem ist wohl auch etwas anders gelagert:
Angenommen wir haben einen maskierenden Rechner, der ipchains
einsetzt. Dann wüßte ich nicht, wie ich bei einkommenden
Paketen solche rejecten sollte, die für den maskierenden
Rechner selber bestimmt sind. In der input chain sind diese
nämlich noch nicht von den Antworten für die im Netz dahinter
liegenden Rechner zu unterscheiden, und nach der input chain
wird sofort demaskiert und nach der "routing decision" an
lokale Prozesse weitergeleitet. Da ist keine Möglichkeit mehr
gegeben einzugreifen.
Wie hatten hier mal eine Frage dazu, siehe
<e4o13a...@ID-22445.user.dfncis.de> und folgende.
Sven Heinzel
> "Felix von Leitner" <usenet-...@fefe.de> schrieb
>
>> Äh, du behauptest, mehrere Firewall-Systeme mit Linux aufgesetzt zu
>> haben, und jetzt fragst du uns, was Firewalls eigentlich mehr tun als
>> Pakete zu filtern?! Merkst du eigentlich noch was?
>
> Ja, manchmal merke ich noch was. Z.B. die "" um das Wort Firewall
Was verstehst Du denn unter "Firewall", bzw. unter Firewall? Wenn
die '"' fuer Dich so wichtig sind, dann solltest Du mal die Bedeutung
erklaeren.
Unter einer Firewall versteht man ein Konzept. Dieses kann _auch_ mit
einem Paketfilter realisiert werden.
>>> 2) Bekommt man ein Netz mit einen Paket-Filterung sicher (ein Netz ist
> nie
>>> sicher solange die Kabel stecken, aber ich hoffe ihr wisst was ich
> meine)?
Dein Quoting ist defekt. Und ausserdem deklarierst Du Deine Umlaute
nicht. Fuer Tipps zu Deinem Newsreader lies mal
<news:de.comm.software.newsreader>
> Was wäre denn jetzt ein geeigneter Paketfilter um z.B. eine
> Maschine zu "sichern", welche vor einem Proxy/Mail System steht,
> welches wiederum ein LAN bedient?
Was soll wovor geschuetzt werden?
Gruss
Sven
Lasse Kliemann
> > <e4o13a...@ID-22445.user.dfncis.de> und folgende.
>
> sein soll. Sorry - ehrlich.
>
> Du willst auf einem Rechner in einem privaten Netz Dienste
> im Internet anbieten ueber Masquerading?
Nein, bei dem Szenario, was ich vor Augen habe, bietet der
maskierende Rechner selber Dienste an. Davon sind aber einige
nicht für die Außenwelt, sondern für das interne Netz
bestimmt. Nun gibt es neben dem Einsatz von TCP Wrappern oder
dem Binden ans interne Interface auch noch die Möglichkeit,
einen Paketfilter zur Durchsetzung der gewollten Restriktion
einzusetzen. [Wenn dies auch eher nicht ganz so schön ist.
Aber ich muß gestehen, daß ich bei sehr wichtigen Dingen dazu
neige, alle drei Möglichkeiten zu kombinieren.]
So, zurück zum Thema. Ursprünglich sah ich bei meinem
Szenario folgendes Problem:
Ich möchte zum Beispiel verhindern, daß jemand aus dem
Internet meinen Squid auf 0.0.0.0:3128 verwendet. Was soll
ich aber mit einem Paket in der input chain tun, welches aus
dem externen Netz an die offizielle IP Adresse des
maskierenden Rechners, Port 3128 gesendet wurde? Rejecten,
weil es für den Squid sein könnte? Oder durchlassen, weil es
auch einfach nur ein Antwortpaket einer maskierten Verbindung
für einen Clienten im lokalen Netz sein könnte?
Und jetzt, wo ich das hier schreibe, fällt mir auf, daß
letzteres garnicht möglich ist. Antworten auf maskierte
Verbindungen sind ja nichts anderes als Antworten auf
Anfragen des maskierenden Rechners. Aber dieser hätte eine
solche Anfrage niemals von 3128 aus gestartet, da dort schon
ein Dienst hängt. Man kann also getrost alles, was nicht aus
dem lokalen Netz kommt und an 3128 geht, rejecten.
Ich muß somit meinen Einwand zurückziehen. Warum ist mir das
nicht schon damals bei dem erwähnten Thread aufgefallen?
Daniel Meyer
kiel.de says...
> Nein, bei dem Szenario, was ich vor Augen habe, bietet der
> maskierende Rechner selber Dienste an. Davon sind aber einige
> nicht für die Außenwelt, sondern für das interne Netz
> bestimmt. Nun gibt es neben dem Einsatz von TCP Wrappern oder
> dem Binden ans interne Interface auch noch die Möglichkeit,
> einen Paketfilter zur Durchsetzung der gewollten Restriktion
> einzusetzen. [Wenn dies auch eher nicht ganz so schön ist.
> Aber ich muß gestehen, daß ich bei sehr wichtigen Dingen dazu
> neige, alle drei Möglichkeiten zu kombinieren.]
Bei sehr wichtigen Dingen solltest du deinen Paketfilter und die
angebotenen Dienste physikalisch trennen. Alles andere ist ein Zeichen
dafuer das du es nicht verstanden hast was eine Firewall samt
dazugehoerenden Konzept bedeutet.
Daniel
--
Whenever, wherever http://www.cyberdelia.de
We're meant to be together ea...@cyberdelia.de
I'll be there and you'll be near
And that's the deal my dear
Felix von Leitner
> > > 2) Bekommt man ein Netz mit einen Paket-Filterung sicher (ein Netz ist
> nie
> > > sicher solange die Kabel stecken, aber ich hoffe ihr wisst was ich
> meine)?
> >
> > Nein.
> Warum?
Ich würde dir ja antworten, aber du kannst nicht quoten.
Leuten, die nicht quoten können, helfe ich nicht.
Lasse Kliemann
> > Internet meinen Squid auf 0.0.0.0:3128 verwendet. Was soll
> > ich aber mit einem Paket in der input chain tun, welches aus
> > dem externen Netz an die offizielle IP Adresse des
> > maskierenden Rechners, Port 3128 gesendet wurde?
>
Ja, genau. Man könnte sogar noch das -y weglassen.
[...]
> ipchains -A input -i extern -p tcp -y -j REJECT
>
> Ist natuerlich nicht so voll krass sicher gegen StealthScans von
> fortgeschrittenen ScriptKiddyTrotteln. ;-)
Ein Scan ist nur ein Scan.
> > Ich muß somit meinen Einwand zurückziehen. Warum ist mir
> > das nicht schon damals bei dem erwähnten Thread
> > aufgefallen?
>
> Wald, Baeume, sehen ;-)
Vor allem, weil ich mich erinnerte, beim Umstieg auf iptables
in der neuen Aufteilung keine Vorteile erkennen zu können.
Lasse Kliemann
> > Nein, bei dem Szenario, was ich vor Augen habe, bietet
> > der maskierende Rechner selber Dienste an. Davon sind
> > aber einige nicht für die Außenwelt, sondern für das
> > interne Netz bestimmt. Nun gibt es neben dem Einsatz von
> > TCP Wrappern oder dem Binden ans interne Interface auch
> > noch die Möglichkeit, einen Paketfilter zur Durchsetzung
> > der gewollten Restriktion einzusetzen. [Wenn dies auch
> > eher nicht ganz so schön ist. Aber ich muß gestehen, daß
> > ich bei sehr wichtigen Dingen dazu neige, alle drei
> > Möglichkeiten zu kombinieren.]
>
> Bei sehr wichtigen Dingen solltest du deinen Paketfilter
> und die angebotenen Dienste physikalisch trennen.
Natürlich ist das besser.
> Alles andere ist ein Zeichen dafuer das du es nicht
> verstanden hast was eine Firewall samt dazugehoerenden
> Konzept bedeutet.
Als Firewall habe ich mein Szenario nicht bezeichnet. Es geht
dort nur um einen Rechner, der, weil er vielleicht der
einzige ist, der zur Verfügung steht, sowohl maskiert, als
auch Dienste anbietet. Und natürlich darum, wie man diese
absichert. Dabei finde ich dann die Idee, verschiedene
Methoden zu kombinieren, nicht unsinnig.