• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Erledigt Frage zu Firewall und Routing unter 9.0 Danke!

Ich habe ein Gateway, das zwischen zwei netzwerken hängt (LAN, WAN) und möchte nun mein LAN gegen das WAN sichern, indem ich mein Gateway auf SuSe 9.0 aufgesetzt habe und dann die firewall2 nutzen will.
Ich habe routing aktiviert. Wenn ich nun die Firewall2 starte, ohne das Häkchen bei "IP weiterleitung aktivieren und IP-Masquerading durchführen" zu setzen, werden LAN und WAN voneinander getrennt und es wird einfach nicht mehr geroutet.

Meine Frage ist ganz simpel:
Wenn ich beide Netze miteinander verbinden will und dabei die Firewall nutzen will, um unliebsame Gäste fernzuhalten, muß ich dann einfach in der Sysconfig-Datei der Firewall FW_ROUTE=yes und FW_Masquerade=no setzen?

PS: Ich darf/kann kein Masquerading einsetzen.
 

NeoMan

Member
Ich denke LAN ist dein internes Netzwerk und mit WAN meinst du das Internet. Richtig?

Um von einen Rechner aus dem internen Netz ins Internet zu routen und von der Gegenstellen dann auch wieder Antwort zu erhalten, brauchst du Masquerading/NAT.

Dein Gateway übersetzt nämlich die Netzinterne IP-Adresse in eine echte, für das Internet routebare Adresse und leitet dann die Antworten wieder zu dem Rechner mit der dazugehörigen Netzinternen IP-Adresse.

Ja, hört sich verwirrend an, ist aber leider so... :)

Also, nochmal im Klartext, um aus einem lokalen Netz über einen Gateway ins Internet zu gehen brauchst du Masquerading/NAT.
 

Martin Breidenbach

Ultimate Guru
Ich denke mal mit WAN meint er WAN den sonst hätte er Internet geschrieben.

Wenn man ein lokales Netz (LAN) an ein 'größeres Netz' (WAN) koppelt dann stellt sich die Frage wie Antwortpakete den Weg zurückfinden sollen. Das kann man über Masquerading hintricksen. Die andere Lösung ist es die Router des 'großen Netzes' so zu konfigurieren daß sie das LAN kennen. Mit dem Internet wird einem das nicht gelingen, bei einem Firmennetz ist das durchaus möglich. Da muß man sich mit den Netzadministratoren des WAN unterhalten.
 

gaw

Hacker
Mit dem Abschalten des Forwarding werden beide Netze auf jeden Fall getrennt, weil dies jede Weiterleitung abschaltet. Die Poststelle streikt sozusagen. Ankommende Pakete werden ignoriert und wandern ins Datennirwana. Das gilt generell und ist sicher keine Lösung um ein lan gegen ein wan abzusichern. Das Masquerading abzuschalten ist nur dann wirksam wenn im LAN private IP-Adressen und im WAN öffentliche IP-Adressen benötigt werden. Es ist für die Anbindung privater Netze an das Internet konzipiert und gilt als Sonderform des s-nat (source network adress translation) bei der die Quell IP-Adressen im Header des IP-Datagrammes umgeschrieben werden (Die Poststelle überklebt die Absender Informationen auf dem Paket). Sonderform deshalb, weil beim Masquerading alle Pakete die nach draussen gehen umgeschrieben werden. Auch damit lässt sich nicht bestimmen von wo nach wo Verbindungen aufgenommen werden dürfen.

Das Problem ist einfach erklärt und beruht auf einem Mißverständnis das vielerorts herrscht wenn von Verbindungen zwischen dem Internet und einem Rechner in einem LAN die Rede ist. Zu jedem Surfen ins Internet (oder in ein anderes WAN) gehören prinzipiell zwei Datenströme, vom Client zum WWW-Server irgendwo im WAN und vom WWW-Server zum Client zurück. Die Verbindung ist also bi-direktional wie bei einem Telefongespräch.
Würde der zurücklaufende Datenstrom getrennt und klemmt man das Mikrofon eines Telefons ab, wäre eine sinnvolle Kommunikation nicht möglich,. Das gleiche gilt für die Verbindungen zwischen LAN und WAN; der Client aus dem LAN könnte weder surfen noch seine email abholen oder ftp nutzen wenn die Verbindungen zwischen WAN und LAN gekappt werden würde.

Bleiben wir beim Beispiel des Telefons oder einer Telefonanlage die sich so einstellen lässt dass sie Anrufe entgegennehmen kann, aber keine Gespräche nach aussen zulässt. Das wird letztlich dadurch gesteuert dass der Verbindungsaufbau nicht zugelassen wird. Wenn eine Verbindung aber besteht ist sie stets bidirektional, wir können gleichzeitig reden und hören. Ebenso verhält es sich mit den Verbindungen von einem LAN in ein WAN. Was eine Firewall also leisten muss ist neue Verbindungsaufnahmen zu erkennen und ggf. zu verbieten.

Auf der IP-Ebene (3. OSI Schicht oder 2.Schicht im DoD Modell) ist es nicht möglich zwischen ankommenden Paketen zu unterscheiden die zu existierenden Verbindungen gehören oder eine neue Verbindung einleiten (Die Poststelle sieht nur das Kuvert eines Briefes und kann kaum erkennen ob der Brief eine neue Geschäftsbeziehung einleiten soll).

Eine gute Firewall kann trotzdem unterscheiden ob ein Daten-Paket eine neue Verbindung einleitet. Diese Fähigkeit wird als stateful inspection beschrieben. Es gibt verschiedene Ansätze, die aber alle bedingen, das sich die Firewall die Header der höheren Protokolebene anschaut. Zum Beispiel merkt sich die Firewall jedes Paket das ein neues socket pair verwendet und trägt es in eine Tabelle ein (So verfährt iptables bei UDP). Oder es untersucht die Header der Anwendungsprotokolle (So verfährt das ftp-contracking Modul von iptables im Zusammenhang mit passiven ftp). Oder es erkennt bei bestimmten Protokollen anhand eines gesetzten Bit ob das Paket einen neuen Verbindungsaufbau einleitet (So verfährt iptables bei TCP).

Auf dieser Ebene lässt sich zwischen den Datenströmen oder genauer eigentlich nur zwischen der Verbindungsaufnahme von Datenströmen differenzieren. Verfügt eine Firewall über stateful inspection lässt sie sich so konfigurieren, dass ein Verbindungsaufbau nur vom LAN ins WAN erlaubt wird und nicht umgekehrt. Das Programm iptables verfügt über diese Fähigkeit. Die SuSEFirewall ist ein Frontend zu iptables und beherrscht ebenfalls stateful inspection. Mit der SuSEFirewall werden Verbindungen aus dem WAN ins LAN mit Kombinationen aus FW_FORWARD und FW_REDIRECT definiert.

Das ganze lässt sich mit iptables Befehlen auch direkt einrichten. Mit folgenden Befehl erlaube ich allen Paketen aus dem WAN, die zu bestehenden Verbindungen gehören, ins LAN zu gelangen:
Code:
/usr/sbin/iptables -A FORWARD -i $INTERFACE_EXT -o $INTERFACE_INT -m state --state  ESTABLISHED,RELATED -j ACCEPT
Der nächste Befehl untersagt dagegen jeden Verbindungsaufbau vom WAN ins LAN:
Code:
/usr/sbin/iptables -A FORWARD -i $INTERFACE_EXT -o $INTERFACE_INT -m state --state NEW -j DROP

$INTERFACE_EXT und $INTERFACE_INT sind zwei Variable welche die externe und das interne Schnittstelle bezeichnen zum Beispiel ppp0 und eth0.

Übertragen auf das Telefonmodell bedeutet die erste Regel dass der Anrufer aus dem LAN der einen Gesprächspartner im WAN anruft ihn auch hören kann. Die zweite Regel verhindert dagegen, dass ein Anruf aus dem WAN ins LAN erfolgen kann.

Letztlich ist das wohl das Szenario, dass dir vorschwebt.

mfG
gaw
 
OP
B

BrotBraeuner

Member
Slow Down, Leute, Slow Down!!!!!!

OK, das Internet ist ein GAN (Global Area Network) ich rede hier von einem WAN und einem LAN. Derzeit sind beide durch mein Gateway per IP-Weiterleitung miteinander verbunden. Da von meinem LAN aus gesehen (das übrigens ein lizensiertes Klasse-B Netz darstellt und damit routingfähigen IP-Bereich besitzt) nach dem Router ein Layer-3-Switch kommt, habe ich also als Standardgateway den Switch angegeben.

Also, wenn ein Rechner ins WAN will, so meldet er sich beim Gateway, und wird dann lediglich an den Switch weitergeleitet. Dieser vermittelt dann weiter ins WAN.

Ich möchte nun lediglich die verbindung LAN-Switch durch eine Firewall schützen.

Mein Problem ist, wenn ich die Firewall aktiviere und das Häkchen "IP-Weiterleitung und Masquerading durchführen" nicht setze, wird augenblicklich die Routingfunktion ausgeschaltet.

Das Netzwerk soll weiterhin von außen sichtbar bleiben, jedoch sollen nur noch die benötigten Ports offen bleiben und nicht wie bisher das ganze Netzwerk geöffnet bleiben.
 
Für sowas (tolles) ist die SUSEFW2 IMHO nicht geeignet. Da helfen gezielte iptables-Anweisungen wahrscheinliche mehr, es bleibt dokumentierbar (scheint ja was produktives zu sein) und vor allem auch wartbar.
Schau mal in den "Nützlichen Links" nach nem iptable-Generator und bastel dir das sleber hin, davon hast du sicher mehr.

Grüße
 

gaw

Hacker
Die Unterscheidung zwischen GAN und WAN wird in der Fachliteratur nicht durchgängig so getroffen. Die meisten unterscheiden nur zwischen LAN und WAN, andere zwischen LAN, MAN, WAN, wieder andere zwischen LAN, WAN und GAN und letztlich andere zwischen SAN, LAN, MAN, WAN und GAN. Die entsprechende Unterscheidung ist für dein Problem aber völlig irrelevant. Aus der Sichtweise des LAN's lässt sich dein WAN als Bestandteil des Internets ansehen, denn das Internet besteht aus miteinander verbundenen Netzen.

Wenn du aber schon uns deine Begriffsdefinitionen - gerade gelernt? - um die Ohren haust, solltest du aber auch in anderen Dingen genau sein und nicht nur ein Fachbuch oder einen Lehrer als Maß aller zu Dinge betrachten. Ganz vermeiden würde ich zum Beispiel im gleichen Atemzug solcher naseweisen Anmerkungen von Klasse-B Netzen zu sprechen - seit den neunziger Jahren gibt es keine Klasseneinteilung im Internet mehr. IP-Netzwerke werden nur durch Adressen und Netzwerkmasken definiert und schon lange nicht mehr durch Klassen. Normalerweise erwähne ich das nicht, aber bei einem Genauigkeitsfanatiker der auf die Unterschiede zwischen WAN und GAN pocht. will ich mal eine Ausnahme machen ;)

Gänzlich losgelöst von solchen Definitionen mutet allerdings der drittletzte Satz deines Beitrages an, dass du die Verbindung LAN-Switch durch eine Firewall schützen möchtest.
Mit einer Firewall werden keine Verbindungen geschützt, sondern ein internes Netz (oder ein einzelner Rechner ) wird vor dem geschützt was von außen an Datenströmen hereinkommt und je nach eingesetzten Techniken kann das auf verschiedenen Ebenen geschehen. Man kann die Firewall ebenso vor Angriffen aus dem internen Netz schützen und regeln was nach außen darf. Verbindungen lassen sich jedoch mit einer Firewall nicht schützen, weder physikalisch - mit einer Schere lässt sich jederzeit instruktiv belegen wie sinnlos so ein Unterfangen im Ernstfall wäre - noch auf der Softwareebene. Eine Firewall kann nicht verhindern dass eine reale oder virtuelle Verbindung gekappt wird, sie kann höchsten Verbindungen selbst kappen. Schützen kann sie Verbindungen definitiv nicht.

Mir scheint, da existieren völlig obskure Vorstellungen vom Aufbau und der Funktion einer Firewall. Ich empfehle ein paar Grundlagen nachzulesen, nicht nur über Aufgaben und Wirkungsweisen einer Firewall sondern auch über die Protokollebenen, letzeres wegen dem rätselhaften Bemerkungen übder die Verbindung zwischen LAN und Switch, Was hat denn dein Switch mit deiner Firewall zu tun?

Aber vielleicht verwendest du ja einen Layer-3-Switch mit den entsprechenden Funktionen oder möchtest auf der 2.Ebene mit MAC-Nummern spielen?

Wie auch immer mit iptables lässt sich ziemlich viel erledigen, was fertige Firewall's oder Frontends nicht immer schaffen. Das erfordert allerdings Kenntnisse über das Zusammenwirken der einzelnen Protokolle.

mfG
gaw
 
OP
B

BrotBraeuner

Member
OK, gaw.

Also, daß ich die Verbindung Gateway-Switch schützen will, damit wollte ich ausdrücken, daß ich damit mein LAN vor dem WAN schützen will.

Die Unterscheidung WAN-GAN treffe ich deswegen, weil das WAN, das ich meine, nicht eine einzige Leitung, Kabel oder wie du's nennen willst mit dem Internet gemeinsam hat, und deswegen also auch nicht als Teil davon gesehen werden kann.

Abgesehen davon habe ich weiterhin ein Klasse-B Netz, da genau dieses vor langer, langer Zeit zugewiesen wurde.
Daß man die Bit's auch "stufenlos" verändern kann, weis ich auch.
Sonst hätten wir nicht als Subnet-Mask 255.255.240.0

Damit man mich hoffenlich endlich richtig versteht:

Ich will, daß die Verbindung LAN-WAN eine Firewall darstellt, die KEIN Masquerading betreibt, und einfach nur nach Ports Filtert.

d.h. kommt ein Paket von "links" oder "rechts" und es will über einen Port, den ich zulasse, soll es durch. Kommt es über einen Port, den ich sperre, soll es verworfen werden.

Für das normale Routing ohne Firewall mußte ich bisher keine Routingtabelle anlegen, das hat er schon dadurch gemacht, daß ich ihm gesagt habe, er soll routen und ich habe ihm die IP des Switches als Gateway gegeben.

Also nochmal die Frage, die ich beantwortet haben wollte.
Reicht es aus, routing in der Firewall-Config zu aktivieren und gleichzeitig Masquerading zu deaktivieren oder muß ich unbedingt eine routingtabelle oder sonstnochwas einstellen? Wie gesagt, bisher läufts ohne Routingtabelle, und dabei solls bleiben.

PS: an gaw: Daß ich nicht seit kurzem mitNetzwerken arbeite, solltest du an dem Begriff "Klasse-B" Netz gemerkt haben. Aber ich arbeite erst seit kurzem mit Linux, was man anhand der wenigen Beiträge in diesem Forum merken kann.
 

gaw

Hacker
Es ist schwierig wenn du uns deine Informationen immer brökchenweise zukommen lässt und wir nur dunkel erahnen können was du meinst. Dein WAN ist also nicht ans Internet angeschlossen aber gleichzeitig verfügst du über eine offizielle Adresse, dein Switch ist vielleicht ein Router über den du aber keine Verfügung hast und du willst kein Masquerading betreiben aber unbedingt ein Firewall-Frontend benutzen die im Prinzip genau zu dem Zweck konzipiert worden ist, den du ablehnst.
Der Sinn des Ganzen bleibt dunkel (Außer der Tatsache, dass du dein LAN schützen willst)

Noch einmal die Antwort, die dir carsten schon gegeben hat, iptables ist das eigentliche Programm das hinter der SuSEFirewall steht und selbstverständlich lassen sich damit einzelne Ports sperren.

Und ob und wie du routen musst hängt von deiner Konfiguration ab. Und da ist mir einiges noch nicht ganz klar und deswegen kann ich deine Frage nicht beantworten. Zum Beispiel redest du immer vom Switch und dem LAN. Die Frage, die sich mir dabei stellt, wie sind denn die Rechner in deinem LAN miteinander verbunden? Existiert ein zweiter Switch oder ein HUB, so dass die Firewall zwischen LAN-Switch und deinem WAN-Layer-3-Switch angeordnet werden soll? Oder sind die anderen Rechner auch alle an deinem Layer-3-Switch angeschlossen?

Warum benutzt du offizielle Adressen wenn dein WAN nicht am Internet hängt? Existiert da noch ein anderer Zugang?

Ohne diese Informationen könnte ich nur raten, ob und welche Routingbefehle du vielleicht benötigst und ob du mit der SuSEFirewall dein Problem lösen kannst.

Deine These man könne aus dem Alter des Besitzes einer vermeintlichen Klasse-B-Adresse auf die Fähigkeit schließen ein Netzwerk einzurichten und zu unterhalten klingt interessant.


mfg
gaw
 
OP
B

BrotBraeuner

Member
Warum versteht mich keiner?

Also nochmals ganz einfach. Die Konfiguration sieht wie folgt aus:


LAN------Router (soll Firewall bekommen)------Layer-3-Switch-------WAN


Das LAN soll fürs WAN sichtbar bleiben! Deswegen KEIN Masquerading.
Aber es sollen eben nicht alle Ports ins oder aus dem LAN heraus offen stehen.

Und gaw: Du sagtest "Der Sinn des Ganzen bleibt dunkel (Außer der Tatsache, dass du dein LAN schützen willst) "

GENAU!!!! Genau das will ich! Mein LAN schützen!!! Ist das schwer begreiflich??
Ich will eigentlich nur die Ports sperren. Und ich denke eigentlich, daß das die hauptaufgabe einer Firewall ist. Eine zusätzliche Schutzfunktion ist dabei das Masquerading, doch genau das kann und will ich nicht betreiben, weil manche Server und Clients in meinem LAN direkt angesprochen werden über Ihre IP-Adresse. Wenn aber mein ganzes LAN nur eine IP hat, wird das schwierig.

Ich möchte aber Ports wie z.B. 135 und viele andere zumachen, damit zukünftige Blasters und wie sie alle heisen zwar mein Netzwerk sehen, aber nicht rein können!!!!!!!

NOCHMAL: ICH will Ports Sperren ohne die Zusatzfunktion Masquerading und dennoch weiterleiten.
Stell dir ein Sieb vor, das alles rausfischt, was kein offenes Loch findet und zwar in beide Richtungen.
Du kannst durchsehen, aber eben nur gefiltert.

Also: kann man In der Config der Firewall IP_ROUTE=yes und IP_Masquerade=no setzen um eine Weiterleitung zu haben ohne zu maskieren??????
 
Nu mal alle wieder locker...

Die Antwort steht aber schon da: iptables
Die SuSE-FW2 ist ein Produkt, was iptabels nutzt und für einen bestimmten Zweck optimiert ist, nämlich den Schutz eines LAN gegen das I-Net.

Für deine Anforderung ist iptables, ggfs. mit nem table-Generator (siehe "nützliche Links") erzeugt, sinnvoller als FW2.
Außerdem dukumentiert und wartbar.

Grüße
 

gaw

Hacker
Selbstverständlich kannst du einen Parameter auf no stellen und den anderen auf yes nur damit hast du noch nichts konfiguriert.
In der Konfigurationsdatei steht zu FW_ROUTE:
Code:
# You need only set this to yes, if you either want to masquerade internal
# machines or allow access to the dmz (or internal machines, but this is not
# a good idea). This option supersedes IP_FORWARD from
# /etc/sysconfig/network/options
#
# Setting this option one alone doesn't do anything. Either activate
# massquerading with FW_MASQUERADE below if you want to masquerade your
# internal network to the internet, or configure FW_FORWARD to define
# what is allowed to be forwarded!

Du kannst das also einstellen, nur bewirkt das eben....nichts, solange du keine FW_FORWARD -Regeln aufgestellt hast.

Hier helfen die Kommentare in der Konfigurationsdatei der SuSE-Firewall. Dort findet sich zu FW_FORWARD u.a. dieser Text:
Code:
# Which services accessed from the internet should be allowed to the
# dmz (or internal network - if it is not masqueraded)?
# REQUIRES: FW_ROUTE

Allerdings erkennen wir schon an den Kommentaren und dem Fragezeichen, dass die SuSE-Firewall nicht dazu gedacht ist als interne Firewall zu dienen. Sie bietet diese Möglichkeit nicht ausdrücklich an, aber es ist durchaus möglich, nur eben umständlich. Wenn du deine Firewall einschaltest und keine FW-FORWARD-Regeln in der SuSE-Firewall-Syntax besitzt geschieht mit dem Setzen des FW_ROUTES auf yes und des FW_MASQUERADE auf no allerdings erst einmal nichts, was das Testen zu diesem Zeitpunkt unmöglich macht.

Insbesondere wird allein durch diese Anweisung nicht geroutet, was eigentlich auch nicht die Aufgabe einer Firewall ist. Vor allem kann die SuSE-Firewall nicht erkennen welche Netze jemand besitzt und wie diese zu routen sind. Sie "denkt" in Kategorien internes Netz, DMZ und Internet. Wenn es dir gelingt deine Situation auf diese SuSE-Firewall-Welt zu mappen, also dein WAN als Internet zu betrachten und mit FW_FORWARD Regeln alles zu definieren was rein und raus darf sollte das auch funktionieren. Ob das sinnvoll ist ist eine andere Frage, wie dir schon mehrfach nahegelegt wurde, macht es mehr Sinn es mit iptables direkt zu versuchen. Zurück zur SuSEFirewall: Ohne Regeln passiert nichts, was wie gesagt aus Sicht einer Firewall auch vernünftig ist. Warum sollte die Firewall auch Regeln einleiten die weder einer Standardsituation Rechnung trägt noch die ihr explizit mitgeteilt worden ist? Die Reaktion der SuSEFirewall ist also logisch, ohne ausrückliche Anweisungen erst einmal nichts durchzulassen.

Da deine Firewall ein Router ist, solltest du auch routen. Am einfachsten du definierst zwei Netze:

LAN..............................Firewall......................layer3-switch
192.168.22.0/24-----192.168.22.19/10.0.0.3--------10.0.0.5

In deinem LAN wirst du in diesem Beispiel auf den Clients als Gateway 192.168.22.19 eintragen müssen. Auf der Firewall sollten u.a. auch folgende Routen existieren:

Netz/Netzmaske/Interface (oder IP)
192.168.22.0 255.255.255.0 ethx(192.168.22.19)
10.0.0.0 255.255.255.0 ethy(10.0.0.3)
default * 10.0.0.5

Da das masquerading nicht aktiv ist, spielt es keine Rolle ob deine Adressen privat sind oder nicht. Damit sind deine Fragen mehr als hinreichend beantwortet worden und du solltest *** als alter Netzwerker mit einer Oldtimer-Netz-IP *** schon in der Lage sein dein Routen selbst zu konfigurieren. oder etwa nicht?

Wenn du soweit bist, dann hast du die Qual der Wahl, entweder FW_Forward Regeln in /etc/sysconfig/SuSEfirewall2 definieren - was die SuSE-Autoren selbst für keine gute Idee halten (siehe Kommentar), oder besser es mit iptables direkt zu versuchen. Ich würde zweiteres empfehlen. Apropos empfehlen hier findest du ein gutes Buch über TCP/IP, in dem die Basics zum Routen erklärt werden:
http://www.oreilly.de/catalog/tcp3ger/ und wo wir gerade dabei sind:
http://www.oreilly.de/catalog/linuxfireger/
http://www.millin.de/linux_firewall_buch.html
Beide Bücher in deutscher Sprache enthalten gute Anleitungen über den Aufbau und Konfiguration einer Firewall insbesondere mit iptables.


mfg
gaw
 
OP
B

BrotBraeuner

Member
Gut, daß ich nur mit diesen zwei Parametern nicht weit komme ist mir klar.

Mit iptables hab ich halt (noch) keine Erfahrung. Ich probiers mal mit deinen Links. Vielleicht klappts dann.

Gibts eigentlich ein anständiges Frontend für iptables? auf der Kommandozeile hab ich immer ein bisschen das Problem der Übersichtlichkeit. Habe es mal mit Webmin ausprobiert. Der scheint für die Firewall auch iptables zu benutzen.
 

gaw

Hacker
Wenn es um die Übersichtlichkeit geht, probiere doch einfach einen xterm oder eine Konsole unter X. Dann lässt sich auch auf der Konsole übersichtlich arbeiten.

Vermutlich wird es Frontends geben, ich selbst arbeite gerade an einem webtool in perl, weiß aber noch nicht wann ich fertig werde.

Soweit ich weiß existiert ein externes Modul für webmin, ich weiß aber nicht wie gut das ist.
Auf meinem Router laufen Skripte die dynamisch bestimmte Regeln ein und ausschalten können. Das lässt sich dann unter webmin automatisieren, indem das Skript als eigenen Befehl formuliert wird. So kann ich durch ein Button ftp ein- oder auschalten, dcc Anfragen zulassen oder den gesammten html-Transport entweder über einen squid lenken oder einen direkten Internetzugang gewähren. Damit ließe sich Firewallregeln nach Bedarf erstellen.

Es existieren aber auch Skriptgeneratoren wie der FWbuilder. Darüberhinaus verwenden viele sogenannte Hardwarerouter eigene Webtools. Im Hintergrund werkelt meist iptables als Paketfilter. An sich ist auch die SuSE-Firewall unter yast eine Art GUI.Frontend, allerdings eiingeschränkt.

Das Problem wird es aber oft geben, ein grafisches Frontend wird meistens nur die Standardkonfigurationen abdecken können. Wenn es darüber hinaus Möglichkeiten anbietet, wird es schwieriger, sowohl für den Entwickler, als auch für den Benutzer.

Das Programm iptables ist ein Werkzeug mit dem sich Regeln definieren lassen. Was letztlich damit angestellt kann auf ganz unterschiedlichen Strategien basieren. Und das ist zusätzlich ein Problem, denn diese Strategien sind nicht kompatibel zueinander. Es gibt Firewall's die aktiv Ports sperren und alles was nicht gesperrt ist durchlassen (fli4) und andere die prinzipiell alles verbieten und nur definierte Verbindungen zulassen. Und selbst da gibt es Unterschiede. So kann mit stateful inspecton grundsätzlich alle Paketen die zu etablierten oder in Beziehung stehenden Verbinungen gehören der Durchlass gewährt werden und die Kontrolle erfolgt über den Verbindungsaufbau. Dieser Weg wird von Bärtels in seinem Firewallbuch vorgeschlagen. Andere zu denen ich auch gehöre preferieren eher auch bei den Paketen die zu bestehenden Verbindungen gehören nur bestimmte Ports zu berücksichtigen. Diese zusätzliche Sicherheit wird mit einem erhöhten Konfiguartionsaufwand erkauft, weil für jeden Dienst mindestens zwei Regeln formuliert werden müssen. Es ist vielleicht einsichtig dass diese Startegien sich gegenseitig ausschließen und das kann eine GUI nicht ändern.

Mitunter kann die Verwendung von Frontends gleich ob GUI oder Skriptgenerator dazu führen, dass die Regeln des Skriptgenerators oder des Frontend ähnlich komplex werden wie die Originalaufrufe in iptables. Dann ist die Frage gerechtfertigt, ob es sinnvoll ist, sich in einen solchen Skriptgenerator oder in eine GUI einzuarbeiten oder besser gleich zu lernen, wie man mit iptables umgeht. Die meisten werden wohl eher Probleme haben die Grundlagen zu begreifen und das kann eine GUI nicht immer ersetzen. Ohne die Kenntnis über Dinge wie OSI- oder DoD Protokollstapel, IP-Datagramme, TCP-Segmente, 3-Wege-Handschlag syn-Bit, Portnummern, Socket, well-known Ports, aktives und passives ftp, Paketfilter, stateful inspection, transparente Proxies u.a. wird ein Administrator eine Firewall nie wirklich beherrschen, eher beherrscht sie ihn, ganz unabhängig, ob man die Einstellugen in einer GUI vornimmt oder auf der Konsole eingibt oder in ein Skript einbettet.


mfG
gaw
 
Oben