SuSEfirewall2 - kein interner Zugriff auf internen www-Server
Hi Liste, Ich betreibe eine Gateway-Box mit SuSE 8.2, auf der u.a. auch ein www-Server läuft. Verwendet wird SuSEfirewall2. Der Server ist extern prima zu erreichen, intern jedoch nur mit der internen Netzadresse, nicht jedoch über die externe Namensauflösung: Pakete mit einer SRC-Adresse aus dem lokalen Netz und der externen Zieladresse werden von SuSEfirewall zurückgewiesen: Apr 27 11:11:41 server3 kernel: SuSE-FW-ACCESS_DENIED_INT IN=eth0 OUT= MAC=00:80:ad:85:4f:f5:00:e0:18:d2:dd:6a:08:00 SRC= 192.168.XX.XX DST=80.142.XX.XX LEN=48 TOS=0x08 PREC=0x00 TTL=128 ID=7666 DF PROTO=TCP SPT=3087 DPT=80 WINDOW= 16384 RES=0x00 SYN URGP=0 OPT (020405B401010402) Die wesentlichen Konfigurationseinstellungen sind: FW_DEV_EXT="ppp0" FW_DEV_INT="eth0" FW_MASQUERADE="yes" FW_MASQ_NETS="0/0" FW_AUTOPROTECT_SERVICES="yes" FW_SERVICES_EXT_TCP="http imap imaps pop3 pop3s smtp" Ich habe die Einstellung für FW_SERVICES_INT_TCP mal verändert, aber das bringt nichts. Kann mir jemand einen Tipp geben? Danke, Dirk.
Am Son, 2003-04-27 um 11.35 schrieb Dirk Ellinger:
Der Server ist extern prima zu erreichen, intern jedoch nur mit der internen Netzadresse, nicht jedoch über die externe Namensauflösung: Pakete mit einer SRC-Adresse aus dem lokalen Netz und der externen Zieladresse werden von SuSEfirewall zurückgewiesen:
Das ist so bei der susefirewall2. Du kannst händische Regeln einführen, irgendwo in /etc/rc.config.d/*firewall* So habe ich es gemacht, nervt mich tierisch, bin daher auch auf der Suche nach einer anderen Firewall, die wirklich nur rein auf iptables basiert, ohne irgendeine Meta-ebene dazwischenzuschieben, durch die man nicht mehr durchsteigt. Gruß, Ratti -- -o) /\\ fontlinge Font management for Linux _\_V http://www.gesindel.de Schriftenverwaltung fuer Linux
Joerg Rossdeutscher wrote:
Am Son, 2003-04-27 um 11.35 schrieb Dirk Ellinger:
Der Server ist extern prima zu erreichen, intern jedoch nur mit der internen Netzadresse, nicht jedoch über die externe Namensauflösung: Pakete mit einer SRC-Adresse aus dem lokalen Netz und der externen Zieladresse werden von SuSEfirewall zurückgewiesen:
Das ist so bei der susefirewall2.
Du kannst händische Regeln einführen, irgendwo in /etc/rc.config.d/*firewall*
bei der 8.2 wohl eher in '/etc/sysconfig/scripts/SuSEfirewall2-custom'.
So habe ich es gemacht, nervt mich tierisch, bin daher auch auf der Suche nach einer anderen Firewall, die wirklich nur rein auf iptables basiert, ohne irgendeine Meta-ebene dazwischenzuschieben, durch die man nicht mehr durchsteigt.
von was für einer Meta-ebene sprichst du? was ausser iptables denkst du wird noch genutzt? du kennst 'http://prdownloads.sourceforge.net/susefaq/firewall2-a4-0-9.pdf?download'? micha
-----Ursprüngliche Nachricht----- Von: Michael Meyer [mailto:mime@gmx.de] Gesendet: Sonntag, 27. April 2003 13:16 An: suse Betreff: Re: SuSEfirewall2 - kein interner Zugriff auf internen www-Server Joerg Rossdeutscher wrote:
Am Son, 2003-04-27 um 11.35 schrieb Dirk Ellinger:
Der Server ist extern prima zu erreichen, intern jedoch nur mit der internen Netzadresse, nicht jedoch über die externe Namensauflösung:
Pakete mit einer SRC-Adresse aus dem lokalen Netz und der externen Zieladresse werden von SuSEfirewall zurückgewiesen:
Das ist so bei der susefirewall2.
Du kannst händische Regeln einführen, irgendwo in /etc/rc.config.d/*firewall*
bei der 8.2 wohl eher in '/etc/sysconfig/scripts/SuSEfirewall2-custom'.
So habe ich es gemacht, nervt mich tierisch, bin daher auch auf der Suche nach einer anderen Firewall, die wirklich nur rein auf iptables basiert, ohne irgendeine Meta-ebene dazwischenzuschieben, durch die man nicht mehr durchsteigt.
von was für einer Meta-ebene sprichst du? was ausser iptables denkst du wird noch genutzt? du kennst 'http://prdownloads.sourceforge.net/susefaq/firewall2-a4-0-9.pdf?downloa d'? micha Danke an alle, habe es gerade auch selbst gefunden! Dirk
Am Son, 2003-04-27 um 13.15 schrieb Michael Meyer:
Joerg Rossdeutscher wrote:
Du kannst händische Regeln einführen, irgendwo in /etc/rc.config.d/*firewall*
bei der 8.2 wohl eher in '/etc/sysconfig/scripts/SuSEfirewall2-custom'.
Vermutlich, ich verwende kein 8.2
So habe ich es gemacht, nervt mich tierisch, bin daher auch auf der Suche nach einer anderen Firewall, die wirklich nur rein auf iptables basiert, ohne irgendeine Meta-ebene dazwischenzuschieben, durch die man nicht mehr durchsteigt.
von was für einer Meta-ebene sprichst du? was ausser iptables denkst du wird noch genutzt?
Ich rede davon, daß die meisten Firewalls irgendwelche Textdateien in Pseudocode "nach iptables übersetzen". Da kannst du dann reinschreiben "von $ALLES nach $DRINNEN port http reject", und dir werden ein halbes Dutzend iptables-Regeln erstellt. Schön und gut, und wenn mal irgendwas /nicht/ klappt, steigt man durch das Gewurschtel nicht mehr durch.
du kennst 'http://prdownloads.sourceforge.net/susefaq/firewall2-a4-0-9.pdf?download'?
Nein, kannte ich nicht. Susefirewall2 ist aber auch "so eine" Sorte Firewall. Ich bin noch auf der Suche nach einen Script, welches wirklich nur pures iptables enthält, naja, gerne mit einer for-Schleife, aber so in der Art. Da ich ein paar recht detaillierte Wünsche habe, kann ich damit mehr anfangen. Ansonsten habe ich gegen die Susefirewall2 nix. Gruß, Ratti -- -o) /\\ fontlinge Font management for Linux _\_V http://www.gesindel.de Schriftenverwaltung fuer Linux
Joerg Rossdeutscher wrote:
Am Son, 2003-04-27 um 13.15 schrieb Michael Meyer:
Joerg Rossdeutscher wrote: von was für einer Meta-ebene sprichst du? was ausser iptables denkst du wird noch genutzt?
Ich rede davon, daß die meisten Firewalls irgendwelche Textdateien in Pseudocode "nach iptables übersetzen". Da kannst du dann reinschreiben "von $ALLES nach $DRINNEN port http reject", und dir werden ein halbes Dutzend iptables-Regeln erstellt. Schön und gut, und wenn mal irgendwas /nicht/ klappt, steigt man durch das Gewurschtel nicht mehr durch.
du hast dir '/sbin/SuSEfirewall2' noch nie angesehen, oder?
du kennst 'http://prdownloads.sourceforge.net/susefaq/firewall2-a4-0-9.pdf?download'?
Nein, kannte ich nicht. Susefirewall2 ist aber auch "so eine" Sorte Firewall.
Ich bin noch auf der Suche nach einen Script, welches wirklich nur pures iptables enthält, naja, gerne mit einer for-Schleife, aber so in der Art. Da ich ein paar recht detaillierte Wünsche habe, kann ich damit mehr anfangen. Ansonsten habe ich gegen die Susefirewall2 nix.
'/sbin/SuSEfirewall2' enthält im grossen und ganzen nur 'pures iptables'. schaue es dir einfach mal an. das setzen von variablen in einer externen konfigurationsdatei ist nichts ungewöhnliches. in '/sbin/SuSEfirewall' steht nichts, dass nicht nachzuvollziehen wäre. zum bauen von paketfiltern wird auch oft 'fwbuilder' empfohlen. <http://www.fwbuilder.org/> ich kenne es aber nicht. ich nutze immer noch 'ipchains'. um iptables zu begreifen, wirst du wohl wenigstens ein mal dein eigenes script schreiben müssen. micha
Moin, Am Son, 2003-04-27 um 18.04 schrieb Michael Meyer:
Joerg Rossdeutscher wrote:
Ich rede davon, daß die meisten Firewalls irgendwelche Textdateien in Pseudocode "nach iptables übersetzen". Da kannst du dann reinschreiben "von $ALLES nach $DRINNEN port http reject", und dir werden ein halbes Dutzend iptables-Regeln erstellt. Schön und gut, und wenn mal irgendwas /nicht/ klappt, steigt man durch das Gewurschtel nicht mehr durch.
du hast dir '/sbin/SuSEfirewall2' noch nie angesehen, oder?
Liest du meine Mails? Die Susefirewall macht genau das, was ich nicht will. Sie trennt "Programm" und "Daten". Wenn ich die Konfigurationsdatei editiere, kann ich daraus nicht besonders gut erkennen, was die Firewall daraus macht. Hast du bei einer nicht korrekt arbeitenden FIrewall schonmal iptables -L gemacht und versucht, aus dem Resultat schlau zu werden? Man macht einfach immer doppeltes Debugging: - einmal die Firewall selbst, in deren Planung man vielleicht einen Denkfehler hat - ...oder die Firewall enthält gar nicht den Code, den man /glaubt/ daß man ihn per "Pseudocode" generiert. Ich bin einfach auf der Suche nach einen Script, welches gut kommentiert einen Haufen iptables-Befehle hintereinander enthält. Es ist dann wesentlich einfacher zu sehen, was man eigentlich tut.
'/sbin/SuSEfirewall2' enthält im grossen und ganzen nur 'pures iptables'. schaue es dir einfach mal an. das setzen von variablen in einer externen konfigurationsdatei ist nichts ungewöhnliches.
in '/sbin/SuSEfirewall' steht nichts, dass nicht nachzuvollziehen wäre.
Sehe ich anders. Das Script liegt irgendwo, holt sich Parameter von anderswo, hängt noch die Hooks aus einer dritten Datei rein, das sind drei Dateien, und das Ergebnis kann ich mir mit iptables -L angucken und enthält logischerweise nichtmal Kommentare. Wie schön ist im vergleich dazu _eine_ Datei mit vielen Kommentaren, in der einfach iptables Befehle untereinanderstehen.
zum bauen von paketfiltern wird auch oft 'fwbuilder' empfohlen.
<http://www.fwbuilder.org/> ich kenne es aber nicht. ich nutze immer noch 'ipchains'.
fwbuilder kenne ich. Ist noch abstrakter. ipchains hat meines Wissens einen großen Vorteil gegenüber iptables: Man kann Testpakete durchschicken. Soviel ich weiss, ist das bei iptables nicht mehr eingebaut. Sehr schade. Jemand anderer Meinung? :-)
um iptables zu begreifen, wirst du wohl wenigstens ein mal dein eigenes script schreiben müssen.
iptables begreifen ist nicht so sehr das Problem, da komm ich schon mit klar. Schön wäre es, einfach ein Script zu haben, welches schonmal die Gemeinheiten abfeiert wie gespoofte IPs und kaputte Pakete, damit man selber nur noch seine Portfreigaben hintendranhängen muß. Rad neu erfinden und so.... du weisst schon. :-) Gruß, Ratti -- -o) /\\ fontlinge Font management for Linux _\_V http://www.gesindel.de Schriftenverwaltung fuer Linux
Joerg Rossdeutscher wrote:
Am Son, 2003-04-27 um 18.04 schrieb Michael Meyer:
Joerg Rossdeutscher wrote:
Ich rede davon, daß die meisten Firewalls irgendwelche Textdateien in Pseudocode "nach iptables übersetzen". Da kannst du dann reinschreiben "von $ALLES nach $DRINNEN port http reject", und dir werden ein halbes Dutzend iptables-Regeln erstellt. Schön und gut, und wenn mal irgendwas /nicht/ klappt, steigt man durch das Gewurschtel nicht mehr durch.
du hast dir '/sbin/SuSEfirewall2' noch nie angesehen, oder?
Liest du meine Mails?
bisher ja.
Die Susefirewall macht genau das, was ich nicht will. Sie trennt "Programm" und "Daten". Wenn ich die Konfigurationsdatei editiere, kann ich daraus nicht besonders gut erkennen, was die Firewall daraus macht.
sie trennt nicht 'programm und daten'. was auch immer _genau_ damit von dir gemeint ist. sie hat bestimmte variablen in einer externen datei. und das macht bei einem für die allgemeinheit geschriebenen paketfilter-script, IMHO, wirklich sinn.
Hast du bei einer nicht korrekt arbeitenden FIrewall schonmal iptables -L gemacht und versucht, aus dem Resultat schlau zu werden?
ja.
Man macht einfach immer doppeltes Debugging: - einmal die Firewall selbst, in deren Planung man vielleicht einen Denkfehler hat - ...oder die Firewall enthält gar nicht den Code, den man /glaubt/ daß man ihn per "Pseudocode" generiert.
ich kann immer noch nichts mit pseudocode anfangen. was meinst du damit? variablen in einer externen datei?
Ich bin einfach auf der Suche nach einen Script, welches gut kommentiert einen Haufen iptables-Befehle hintereinander enthält. Es ist dann wesentlich einfacher zu sehen, was man eigentlich tut.
dass kann, je nach umfang des scriptes, täuschen.
'/sbin/SuSEfirewall2' enthält im grossen und ganzen nur 'pures iptables'. schaue es dir einfach mal an. das setzen von variablen in einer externen konfigurationsdatei ist nichts ungewöhnliches.
in '/sbin/SuSEfirewall' steht nichts, dass nicht nachzuvollziehen wäre.
Sehe ich anders. Das Script liegt irgendwo, holt sich Parameter von anderswo, hängt noch die Hooks aus einer dritten Datei rein, das sind drei Dateien, und das Ergebnis kann ich mir mit iptables -L angucken und enthält logischerweise nichtmal Kommentare. Wie schön ist im vergleich dazu _eine_ Datei mit vielen Kommentaren, in der einfach iptables Befehle untereinanderstehen.
sie liegen nicht _irgendwo_. wo die einzelnen dateien der SF2 liegen, ist sehr gut dokumentiert. genauso finden sich in allen dateien, zum teil sehr umfangreiche, kommentare.
zum bauen von paketfiltern wird auch oft 'fwbuilder' empfohlen.
<http://www.fwbuilder.org/> ich kenne es aber nicht. ich nutze immer noch 'ipchains'.
fwbuilder kenne ich. Ist noch abstrakter.
sorry, aber generiert dieses fwbuilder nicht genau das, was du willst? ich kenne es wirklich nicht, dachte aber immer, es generiert genau eine datei mit den einzelnen iptables aufrufen.
ipchains hat meines Wissens einen großen Vorteil gegenüber iptables: Man kann Testpakete durchschicken. Soviel ich weiss, ist das bei iptables nicht mehr eingebaut. Sehr schade. Jemand anderer Meinung? :-)
ja, iptables --help. ,----[ iptables --help ] | --check -C chain Test this packet on chain `----|
um iptables zu begreifen, wirst du wohl wenigstens ein mal dein eigenes script schreiben müssen.
iptables begreifen ist nicht so sehr das Problem, da komm ich schon mit klar. Schön wäre es, einfach ein Script zu haben, welches schonmal die Gemeinheiten abfeiert wie gespoofte IPs und kaputte Pakete, damit man selber nur noch seine Portfreigaben hintendranhängen muß. Rad neu erfinden und so.... du weisst schon. :-)
also <http://buug.de/~aleks/iptables/> sieht ganz interessant aus. du musst dich nur von deiner 'alles muss in einer datei sein'-phobie befreien. micha -- Ich habe seinerzeit <http://buug.de/~aleks/iptables/> verwendet, weil der Mann weiß, was er Tut(tm). Robin S. Socha in d.c.o.u.l.m
Am Sonntag, 27. April 2003 21:29 schrieb Michael Meyer:
Hast du bei einer nicht korrekt arbeitenden FIrewall schonmal iptables -L gemacht und versucht, aus dem Resultat schlau zu werden?
ja.
versuchs mal mit "/sbin/SuSEfirewall2 debug" - das zeigt die iptables die das script anlegen würde und ist wesentlich übersichtlicher als "iptables -L" Alfred
Alfred Reinhard wrote:
Am Sonntag, 27. April 2003 21:29 schrieb Michael Meyer:
Hast du bei einer nicht korrekt arbeitenden FIrewall schonmal iptables -L gemacht und versucht, aus dem Resultat schlau zu werden?
ja.
versuchs mal mit "/sbin/SuSEfirewall2 debug" - das zeigt die iptables die das script anlegen würde und ist wesentlich übersichtlicher als "iptables -L"
eben. die, die es anlegen _würde_. es sagt nichts über den aktuellen status aus. micha
Moin, Am Son, 2003-04-27 um 21.29 schrieb Michael Meyer:
Joerg Rossdeutscher wrote:
Am Son, 2003-04-27 um 18.04 schrieb Michael Meyer:
Joerg Rossdeutscher wrote:
Die Susefirewall macht genau das, was ich nicht will. Sie trennt "Programm" und "Daten". Wenn ich die Konfigurationsdatei editiere, kann ich daraus nicht besonders gut erkennen, was die Firewall daraus macht.
sie trennt nicht 'programm und daten'. was auch immer _genau_ damit von dir gemeint ist. sie hat bestimmte variablen in einer externen datei.
Eben. Unschön.
Man macht einfach immer doppeltes Debugging: - einmal die Firewall selbst, in deren Planung man vielleicht einen Denkfehler hat - ...oder die Firewall enthält gar nicht den Code, den man /glaubt/ daß man ihn per "Pseudocode" generiert.
ich kann immer noch nichts mit pseudocode anfangen. was meinst du damit? variablen in einer externen datei?
Ich will ein script haben, in dem sowas drinsteht: iptables -A input -p tcp --sport 80 -j ACCEPT Die meisten Firewalls parsen Textdateien, in denen sowas drinsteht (Beispiel entnommen der shorewall): ACCEPT $FW net:$TIME_SERVERS udp 123 ...und da stellt sich mir die Frage: Welche ip-Regel baut der daraus? Wirklich die, die ich glaube? ...und der versuch, die generierte Regel per iptables -L wiederzufinden ist ein Alptraum. Die meisten Firewall-Scripte, und dazu gehört m.E. auch die Susefirewall, halten den Anwender von der technischen Ebene möglichst fern und geben ihm eine Variablendatei an die Hand, in der er 20 Sachen ändern kann. Ich möchte aber z.B. ssh von außen zulassen, smtp auch, aber smtp zusätzlich mit einer MAC-Adresse des Clients schützen. Das geht mit der Susefirewall nur über die Hooks. Und in der Regel geht es erstmal nicht, weil ich was falsch mache. Diesen Fehler jetzt zu finden ist deutlich einfacher mit einer Firewall, die von vornherein vielleicht etwas unkomfortabler ist, wo ich aber ein Script Zeile für Zeile durchsehen kann, wo mein Kram eigentlich hängenbleibt.
Sehe ich anders. Das Script liegt irgendwo, holt sich Parameter von anderswo, hängt noch die Hooks aus einer dritten Datei rein, das sind drei Dateien, und das Ergebnis kann ich mir mit iptables -L angucken und enthält logischerweise nichtmal Kommentare. Wie schön ist im vergleich dazu _eine_ Datei mit vielen Kommentaren, in der einfach iptables Befehle untereinanderstehen.
sie liegen nicht _irgendwo_. wo die einzelnen dateien der SF2 liegen, ist sehr gut dokumentiert. genauso finden sich in allen dateien, zum teil sehr umfangreiche, kommentare.
Es liegt an drei Stellen im System, und der Start ist über diverse Scripte verteilt. Ich finde das unübersichtlich.
zum bauen von paketfiltern wird auch oft 'fwbuilder' empfohlen.
<http://www.fwbuilder.org/> ich kenne es aber nicht. ich nutze immer noch 'ipchains'.
fwbuilder kenne ich. Ist noch abstrakter.
sorry, aber generiert dieses fwbuilder nicht genau das, was du willst? ich kenne es wirklich nicht, dachte aber immer, es generiert genau eine datei mit den einzelnen iptables aufrufen.
Ich will pures iptables, manuell programmiert und kommentiert, und kein Programm, das mir iptables /rausschreibt/. Ich will ein schönes bash-script, das kommentiert ist, mit solchen schönen Dingen wie # entkommentieren sie die nächste Zeile, # wenn sie wollen, daß... mit ordentlichen Einrückungen und Variablen. Ich will, daß jemand schreibt iptables -s $INT -d EXT -j .... iptables -s $EXT -d INT -j .... iptables -s $INT -d INT -j .... ... und nicht irgendwelche Schleifen for $I in $INTERFACES iptables -d $I ... ...in denen mit kryptischen awk und sed-Kommandos superclever hantiert wird, nur lesen kann man's nicht mehr. Ich will maximale Nachvollziehbarkeit. Ich will iptables -L eintippen und erkennen, wo die Regeln herkommen.
ipchains hat meines Wissens einen großen Vorteil gegenüber iptables: Man kann Testpakete durchschicken. Soviel ich weiss, ist das bei iptables nicht mehr eingebaut. Sehr schade. Jemand anderer Meinung? :-)
ja, iptables --help.
,----[ iptables --help ] | --check -C chain Test this packet on chain `----|
Nö. man iptables: BUGS Check is not implemented (yet).
also <http://buug.de/~aleks/iptables/> sieht ganz interessant aus.
Jepp. Grob überflogen, sieht sehr ordentlich aus. Genau das meinte ich: Dieses Script kann man lesen!
du musst dich nur von deiner 'alles muss in einer datei sein'-phobie befreien.
Nö. Geht doch, siehe dein eigener Vorschlag. :-) Gruß, Ratti -- -o) /\\ fontlinge Font management for Linux _\_V http://www.gesindel.de Schriftenverwaltung fuer Linux
Joerg Rossdeutscher wrote:
Am Son, 2003-04-27 um 21.29 schrieb Michael Meyer:
Joerg Rossdeutscher wrote: Die meisten Firewalls parsen Textdateien, in denen sowas drinsteht (Beispiel entnommen der shorewall):
ACCEPT $FW net:$TIME_SERVERS udp 123
...und da stellt sich mir die Frage: Welche ip-Regel baut der daraus? Wirklich die, die ich glaube? ...und der versuch, die generierte Regel per iptables -L wiederzufinden ist ein Alptraum.
ich mag paketfilter nach obiger manier auch nicht. die SF2 ist aber _nicht_ so eine art von paketfilterscript.
Die meisten Firewall-Scripte, und dazu gehört m.E. auch die Susefirewall, halten den Anwender von der technischen Ebene möglichst fern und geben ihm eine Variablendatei an die Hand, in der er 20 Sachen ändern kann.
ja klar. überlege doch mal auf wen die SF2 zugeschnitten ist. wenn sie alles in eine datei gepackt hätten, kämen hier alle 2 tage anfragen nach dem motto: 'ich habe an der konfiguration der SF2 gebastelt, jetzt kommt immer parse error...'
Ich möchte aber z.B. ssh von außen zulassen, smtp auch, aber smtp zusätzlich mit einer MAC-Adresse des Clients schützen. Das geht mit der Susefirewall nur über die Hooks.
ja, dazu sind sie ja da.
Und in der Regel geht es erstmal nicht, weil ich was falsch mache. Diesen Fehler jetzt zu finden ist deutlich einfacher mit einer Firewall, die von vornherein vielleicht etwas unkomfortabler ist, wo ich aber ein Script Zeile für Zeile durchsehen kann, wo mein Kram eigentlich hängenbleibt.
das sehe ich nun wieder anders. ich finde bei mir ein ipchains -L übersichtlich.
ich kenne es wirklich nicht, dachte aber immer, es generiert genau eine datei mit den einzelnen iptables aufrufen.
Ich will pures iptables, manuell programmiert und kommentiert, und kein Programm, das mir iptables /rausschreibt/. Ich will ein schönes bash-script, das kommentiert ist, mit solchen schönen Dingen wie
du willst? dann schreib es dir am besten selbst. dann gibts auch nichts mehr zu meckern.
# entkommentieren sie die nächste Zeile, # wenn sie wollen, daß...
mit ordentlichen Einrückungen und Variablen.
Ich will, daß jemand schreibt
iptables -s $INT -d EXT -j .... iptables -s $EXT -d INT -j .... iptables -s $INT -d INT -j ....
... und nicht irgendwelche Schleifen for $I in $INTERFACES iptables -d $I ... ...in denen mit kryptischen awk und sed-Kommandos superclever hantiert wird, nur lesen kann man's nicht mehr.
auch das sehe ich anders. genau das von dir kritisierte macht es oft sehr viel übersichtlicher.
Ich will maximale Nachvollziehbarkeit. Ich will iptables -L eintippen und erkennen, wo die Regeln herkommen.
du glaubst, iptables -L sieht anders aus, nur weil du alles in einer datei schön untereinander hast?
ipchains hat meines Wissens einen großen Vorteil gegenüber iptables: Man kann Testpakete durchschicken. Soviel ich weiss, ist das bei iptables nicht mehr eingebaut. Sehr schade. Jemand anderer Meinung? :-)
ja, iptables --help.
,----[ iptables --help ] | --check -C chain Test this packet on chain `----|
Nö. man iptables:
BUGS Check is not implemented (yet).
*boa* wie gemein. dann hätten sie es ja auch aus --help nehmen können.
also <http://buug.de/~aleks/iptables/> sieht ganz interessant aus.
Jepp. Grob überflogen, sieht sehr ordentlich aus. Genau das meinte ich: Dieses Script kann man lesen!
sehr witzig. hast du es dir angesehen? eine konfig, eine init, das script an sich ...
du musst dich nur von deiner 'alles muss in einer datei sein'-phobie befreien.
Nö. Geht doch, siehe dein eigener Vorschlag. :-)
ja, ich habe ihn gesehen. du auch? lass uns doch per PM weitermachen. ist ja vielleicht auf dauer doch zu OT. micha
Moin, Am Mon, 2003-04-28 um 11.17 schrieb Michael Meyer:
Joerg Rossdeutscher wrote:
Ich will pures iptables, manuell programmiert und kommentiert, und kein Programm, das mir iptables /rausschreibt/. Ich will ein schönes bash-script, das kommentiert ist, mit solchen schönen Dingen wie
du willst? dann schreib es dir am besten selbst. dann gibts auch nichts mehr zu meckern.
Du bist ein Spaßvogel. Erst quetscht du mich aus, was mich an der FW2 stört, und wenn ich es aufliste, sagst du ich meckere. Die FW2 ist vollkommen OK, privat setze ich's in meinem 3-Rechner-Netz ein. Beruflich suche ich halt was anderes, was da besser paßt, und, wie schön, man hat ja die Wahl, und das Angebot ist riesig. :-)
BUGS Check is not implemented (yet).
*boa* wie gemein. dann hätten sie es ja auch aus --help nehmen können.
Wie langweilig. :-)))
lass uns doch per PM weitermachen. ist ja vielleicht auf dauer doch zu OT.
Och, eigentlich ist das Thema doch sowieso durch. Gruß, Ratti -- -o) /\\ fontlinge Font management for Linux _\_V http://www.gesindel.de Schriftenverwaltung fuer Linux
participants (4)
-
Alfred Reinhard -
Dirk Ellinger -
Joerg Rossdeutscher -
Michael Meyer