Hallo zusammen,
befürchtet habe ich es ja schon länger..., aber mein erstes iptables -L hat mir dann doch die Sprache verschlagen. Die README.Debian schreibt aber dann doch: ... The Package does not provide any rules or security.
Also habe ich mir die Man-Page reingezogen und wollte mich dann erstmal an die Regeln von Andreas Kretschmer halten ( Linux Tag in Dresden ... ).
Aber wie mache ich die Regeln permanent?
Es scheint keine zentrale Konfigurationsdatei zu geben?!
In: /usr/share/doc/iptables/examples/... wird von einem Script "iptables" gesprochen. Dieses Script finde ich aber nirgends...
Thomas für jede Hilfe dankbar
On Thu, Dec 02, 2004 at 09:05:31PM +0100, Mötzing Thomas wrote:
Hallo zusammen,
befürchtet habe ich es ja schon länger..., aber mein erstes iptables -L hat mir dann doch die Sprache verschlagen. Die README.Debian schreibt aber dann doch: ... The Package does not provide any rules or security.
Hallo,
da jede Konfiguration anders ist, muss man selber ein Script schreiben. Die angehängte Datei steht bei mir in /etc/init.d/firewall.
Dieses Script dann mit dem debian-specifischen Befehl update-rc.d einbinden.
Meine iptables Konfig findest du hier: http://www.thomas-guettler.de/scripts/firewall.sh.txt
Gruß, Thomas
Danke Thomas!
Am 2 Dec 2004 um 21:44 hat Thomas Guettler geschrieben:
da jede Konfiguration anders ist, muss man selber ein Script schreiben. Die angehängte Datei steht bei mir in /etc/init.d/firewall.
Dieses Script dann mit dem debian-specifischen Befehl update-rc.d einbinden.
Meine iptables Konfig findest du hier: http://www.thomas-guettler.de/scripts/firewall.sh.txt
Ich habe ganz klein angefangen:
#!/bin/sh
# alles von außen kommende wegwerfen iptables -P INPUT DROP
# bereits bestehende Verbindungen akzeptieren iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# kommendes icmp ( z.B. ping ) akzeptieren iptables -A INPUT -p icmp -j ACCEPT
iptables -A INPUT -p TCP -j REJECT --reject-with tcp-reset iptables -A INPUT -p UDP -j REJECT --reject-with icmp-port-unreachable
Dann mit: update-rc.d <Dateiname> defaults das ganze ins System eingepflegt. Sieht auch so aus, wie ich mir das für's erste vorgestellt habe, ABER!!!!
Beim Booten bleibt der Rechner bei: Starting NFS common utilities: statd wieder mindestens 30 Sekunden hängen.
nach: update-rc.d -f <Dateiname> remove ist alles wieder ganz normal.
Was geht da ab? Die /etc/resolves.conf ist LEER!
bis dann
Thomas - verzweifelt
am Fri, dem 03.12.2004, um 21:19:38 +0100 mailte Mötzing Thomas folgendes:
Ich habe ganz klein angefangen:
[ Script, IMHO Okay ] Du könntest aber eine Log-Regel einfügen, um zu sehen, was weggeworfen wird. Vor den REJECT-Regeln.
Beim Booten bleibt der Rechner bei: Starting NFS common utilities: statd wieder mindestens 30 Sekunden hängen.
klingt nach DNS-Timeout.
Bist Du Dir sicher, den statd zu brauchen? Ich habe ihn bisher nicht benötigt, aber das ist latürnich nicht maßgeblich.
nach: update-rc.d -f <Dateiname> remove ist alles wieder ganz normal.
Ich sehe keinen Zusammenhang mit dem iptables-Script. Aber ich kenne mich mit dem statd auch nicht aus.
Was geht da ab? Die /etc/resolves.conf ist LEER!
/etc/resolv.conf
sollte den/die Nameserver beinhalten, die Du brauchst.
Andreas
Hi
Am 3 Dec 2004 um 22:01 hat Andreas Kretschmer geschrieben:
am Fri, dem 03.12.2004, um 21:19:38 +0100 mailte Mötzing Thomas folgendes:
Ich habe ganz klein angefangen:
[ Script, IMHO Okay ]
Danke! It ja auch von Dir. :-)
Beim Booten bleibt der Rechner bei: Starting NFS common utilities: statd wieder mindestens 30 Sekunden hängen.
klingt nach DNS-Timeout.
Bist Du Dir sicher, den statd zu brauchen? Ich habe ihn bisher nicht benötigt, aber das ist latürnich nicht maßgeblich.
...keine Ahnung, was der macht und ob ich ihn brauche...
Was geht da ab? Die /etc/resolves.conf ist LEER!
/etc/resolv.conf
... genau die meine ich...
sollte den/die Nameserver beinhalten, die Du brauchst.
... habe ich nur probehalber leer gemacht, um zu sehen, ob es daran liegt
bis dann Thomas
On Fri, Dec 03, 2004 at 09:19:38PM +0100, Mötzing Thomas wrote:
Danke Thomas!
...
Sieht auch so aus, wie ich mir das für's erste vorgestellt habe, ABER!!!!
Beim Booten bleibt der Rechner bei: Starting NFS common utilities: statd wieder mindestens 30 Sekunden hängen.
Hallo,
kurze Anmerkung zu deinem Script: Das man mit "DROP" mehr Sicherheit hat als mit "REJECT" mag sein, aber man handelt sich auf jeden Fall mehr Ärger ein. Die Programme warten lange bis sie es aufgeben (Timeout).
Als vorletzte Regel kannst du ja die abgeblockte Verbindung ins Logfile schreiben:
iptables -A INPUT -j LOG --log-prefix "iptables-input-reject " iptables -A INPUT -j REJECT
Dann solltest du finden welche Ports der NFS-Dienst nicht erreicht.
Gruß, Thomas
am Fri, dem 03.12.2004, um 22:13:02 +0100 mailte Thomas Guettler folgendes:
On Fri, Dec 03, 2004 at 09:19:38PM +0100, Mötzing Thomas wrote:
Danke Thomas!
...
Sieht auch so aus, wie ich mir das für's erste vorgestellt habe, ABER!!!!
Beim Booten bleibt der Rechner bei: Starting NFS common utilities: statd wieder mindestens 30 Sekunden hängen.
Hallo,
kurze Anmerkung zu deinem Script: Das man mit "DROP" mehr Sicherheit hat als mit "REJECT" mag sein, aber man handelt sich auf jeden Fall mehr Ärger ein. Die Programme warten lange bis sie es aufgeben (Timeout).
Er hat die Policy auf DROP gestellt, es gibt (leider) keine REJECT-Policy. Dafür hat er am Ende aber Regeln mit REJECT. Paßt also.
Als vorletzte Regel kannst du ja die abgeblockte Verbindung ins Logfile schreiben:
iptables -A INPUT -j LOG --log-prefix "iptables-input-reject " iptables -A INPUT -j REJECT
ACK.
Andreas
Am 4 Dec 2004 um 8:50 hat Andreas Kretschmer geschrieben:
iptables -A INPUT -j LOG --log-prefix "iptables-input-reject " iptables -A INPUT -j REJECT
ACK.
Hi Andreas,
hat leider nix gebracht... das Prinzip ist aber klar geworden und so hat dann:
iptables -A INPUT -p UDP -j LOG --log-prefix "iptables-input-UDP-reject " iptables -A INPUT -p UDP -j REJECT --reject-with icmp-port-unreachable
ein ständig wiederkommendes:
iptables-input-UDP-reject IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=767 DPT=111 LEN=64
ins Log-File gezaubert. Dabei ändert sich ständig di ID=0 auf ID=1, ID=2 u.s.w. bis ID=11. Dann geht es wieder von vorn los...
Hast hier jemand eine Ahnung was das ist? Und was macht man am besten dagegen? Eine Regel mit i=127.0.01 und ACCEPT beseitigt vermutlich das Problem, aber die Ursache doch wohl nicht, oder?! Schickt sich meine Netzwerkkarte selbst Pakete?
bis dann Thomas
Am 4 Dec 2004 um 19:33 hat Mötzing Thomas geschrieben:
Am 4 Dec 2004 um 8:50 hat Andreas Kretschmer geschrieben:
iptables -A INPUT -j LOG --log-prefix "iptables-input-reject " iptables -A INPUT -j REJECT
ACK.
Hi Andreas,
hat leider nix gebracht... das Prinzip ist aber klar geworden und so hat dann:
iptables -A INPUT -p UDP -j LOG --log-prefix "iptables-input-UDP-reject " iptables -A INPUT -p UDP -j REJECT --reject-with icmp-port-unreachable
ein ständig wiederkommendes:
iptables-input-UDP-reject IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=767 DPT=111 LEN=64
ins Log-File gezaubert. Dabei ändert sich ständig di ID=0 auf ID=1, ID=2 u.s.w. bis ID=11. Dann geht es wieder von vorn los...
Hast hier jemand eine Ahnung was das ist? Und was macht man am besten dagegen? Eine Regel mit i=127.0.01 und ACCEPT beseitigt vermutlich das Problem, aber die Ursache doch wohl nicht, oder?! Schickt sich meine Netzwerkkarte selbst Pakete?
... und das war's auch...
iptables -A INPUT -i lo -j ACCEPT
und alles ist wieder in Ordnung... ( aus der Firewall von Thomas Guettler )
... aber wie gesagt, keine Beseitigung der Ursache...
Vielleicht weiß ja jemand Rat.
bis dann Thomas
Mötzing Thomas schrieb:
iptables -A INPUT -i lo -j ACCEPT
Die Regel sollte immer da sein, da viele Programme auch auf dem lokalen Rechner über TCP/IP miteinander kommunizieren. Das geht dann über das Loopback-Device (lo, 127.0.0.1). Das ist eine 'virtuelle' Netzwerkkarte und hat nichts mit deiner richtigen Netzwerkkarte zu tun.
... aber wie gesagt, keine Beseitigung der Ursache...
Welcher Ursache?
Port 111 (sunrpc) wird vom Portmapper benötigt und dieser wiederum vom NFS-Server (oder Client?).
Ciao, Rico
Am 6 Dec 2004 um 20:53 hat Rico Koerner geschrieben:
Mötzing Thomas schrieb:
iptables -A INPUT -i lo -j ACCEPT
Die Regel sollte immer da sein, da viele Programme auch auf dem lokalen Rechner über TCP/IP miteinander kommunizieren. Das geht dann über das Loopback-Device (lo, 127.0.0.1). Das ist eine 'virtuelle' Netzwerkkarte und hat nichts mit deiner richtigen Netzwerkkarte zu tun.
... aber wie gesagt, keine Beseitigung der Ursache...
Welcher Ursache?
Port 111 (sunrpc) wird vom Portmapper benötigt und dieser wiederum vom NFS-Server (oder Client?).
... ich akzeptiere gern, wenn das so in Ordnung ist ...
bis dann Thomas
am Sat, dem 04.12.2004, um 19:33:36 +0100 mailte Mötzing Thomas folgendes:
ein ständig wiederkommendes:
iptables-input-UDP-reject IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=767 DPT=111 LEN=64
ins Log-File gezaubert. Dabei ändert sich ständig di ID=0 auf ID=1, ID=2 u.s.w. bis ID=11. Dann geht es wieder von vorn los...
Hast hier jemand eine Ahnung was das ist? Und was macht man am besten dagegen?
kretschmer@kaufbach:~$ grep 111/udp /etc/services sunrpc 111/udp portmapper # RPC 4.0 portmapper UDP
Eine Regel mit i=127.0.01 und ACCEPT beseitigt vermutlich das Problem, aber die Ursache doch wohl nicht, oder?! Schickt sich meine Netzwerkkarte selbst Pakete?
Nein, es ist der Portmapper. In Umgebungen mit NFS wohl benötigt, ich habe bisher noch keine Anwendung dafür gehabt.
Andreas
Tag auch,
Am Donnerstag, 2. Dezember 2004 21:05 schrieb Mötzing Thomas:
Aber wie mache ich die Regeln permanent?
Es scheint keine zentrale Konfigurationsdatei zu geben?!
In: /usr/share/doc/iptables/examples/... wird von einem Script "iptables" gesprochen. Dieses Script finde ich aber nirgends...
...die meinen wahrscheinlich das Initscript. Liegt wie gewöhnlich unter /etc/init.d/iptables. Eine Möglichkeit, den Status der Firewall permanent zu machen ist: '/etc/init.d/iptables save active'. Ich wurde auch erst vor ein paar Tagen darauf gestossen - das sei wohl der Standardweg. Das Script ohne Parameter gibt eine kurze Hilfe. Dieser Weg scheint mir allerdings für dynamischen Umgebungen nicht geeignet. Wie zum Beispiel bei ständig hinzukommenden und wieder verschwindenden Netzwerkverbindungen (z.B. Tunnel o.ä.). Da muss man halt durch entsprechnde Scripte eingreifen...
Sebastian ...der hofft, helfen zu können.
am 03.12.2004, um 9:50:20 +0100 mailte Sebastian Zwietz folgendes:
Tag auch,
Am Donnerstag, 2. Dezember 2004 21:05 schrieb Mötzing Thomas:
Aber wie mache ich die Regeln permanent?
Es scheint keine zentrale Konfigurationsdatei zu geben?!
In: /usr/share/doc/iptables/examples/... wird von einem Script "iptables" gesprochen. Dieses Script finde ich aber nirgends...
...die meinen wahrscheinlich das Initscript. Liegt wie gewöhnlich unter /etc/init.d/iptables. Eine Möglichkeit, den Status der Firewall permanent zu machen ist: '/etc/init.d/iptables save active'. Ich wurde auch
Das speichert den aktuellen Zustand via iptables-save. Da muß man aber vorher halt die Regeln irgendwie gesetzt haben. Das, was Thomas Guettler schrieb, war so schon okay.
Dieser Weg scheint mir allerdings für dynamischen Umgebungen nicht geeignet. Wie zum Beispiel bei ständig hinzukommenden und wieder verschwindenden Netzwerkverbindungen (z.B. Tunnel o.ä.). Da muss man halt durch entsprechnde Scripte eingreifen...
So ganz genau versteh ich nicht, was Du jetzt meinst...
Ich bezweifle, daß der Fragesteller häufig wechselnde Tunnel hat, IMHO wäre er mit einem Script, das er sich anhand meiner Folien, des Scriptes von Thomas und http://netfilter.org schreibt und es als normales Startscript einbindet, am besten bedient. Dazu sollte er aber auch seine Dienste nach Möglichkeit schon so konfigurieren, daß sie nicht unnötig nachaußen lauschen.
Andreas
Tag,
Am Freitag, 3. Dezember 2004 10:10 schrieb Andreas Kretschmer:
...die meinen wahrscheinlich das Initscript. Liegt wie gewöhnlich unter /etc/init.d/iptables. Eine Möglichkeit, den Status der Firewall permanent zu machen ist: '/etc/init.d/iptables save active'. Ich wurde auch
Das speichert den aktuellen Zustand via iptables-save. Da muß man aber vorher halt die Regeln irgendwie gesetzt haben. Das, was Thomas Guettler schrieb, war so schon okay.
Ist schon klar - aber wie es verstanden habe, ist dies der von der Distribution vorgegebener Weg, seine Firewallregeln zu speichern/verwalten - sofern man davon sprechen kann. Es steht natürlich jedem frei, eingene Scripte aufzusetzen und starten zu lassen. Zugegeben, ich mache das immernoch so. Theoretisch kann mann ja auch die von iptables-save geschriebenen Daten bearbeiten - ich finde das aber wenig praktisch, zumal das Debianscript auch noch unbedingt die Counter mitspeichern will und die Angelegenheit noch unübersichtilicher (ok - kann man auch abstellen). Der praktikabelste Weg scheint mir da ein Schript zu schreiben, das die Regeln aufsetzt und zum Schluss 'iptables save active' aufruft. Sobraucht man sich keine Gedanken über Bootreihenfolge oder Initscripte zu machen - je mehr man 'basteln' muss, desto mehr Probleme können Auftreten.
Dieser Weg scheint mir allerdings für dynamischen Umgebungen nicht geeignet...
So ganz genau versteh ich nicht, was Du jetzt meinst...
Ich bezweifle, daß der Fragesteller häufig wechselnde Tunnel hat, IMHO ... nachaußen lauschen.
Ok, zugegeben - ein wenig konstruiert, aber nicht weltfremd ;-)
Sebastian ...der dann doch lieber keine Verwirrung stiften will.
Hallo,
On Fri, Dec 03, 2004 at 11:18:13AM +0100, Sebastian Zwietz wrote: [cut]
Theoretisch kann mann ja auch die von iptables-save geschriebenen Daten bearbeiten - ich finde das aber wenig praktisch ...
Aus meiner Sicht ist das Tool "iptables-save" sinnlos. Bei komplexen iptables Regeln wird man sicherlich mit Variablen arbeiten.
Zum Beispiel $ETH_LAN $ETH_INET $ETH_DMZ (Intern, Internet, Demilitarisierte Zone)
Bei der Methode 1 (Setzen der Regeln per Shell-Script) ist es kein Problem, wenn sie die IP-Adresse von ETH_LAN ändert.
Bei iptables-save hat man ein Problem. In der abgespeicherten Datei sind keine Variablennamen sondern die IP-Adressen und die müsste man durch umständliches Ersetzen ändern.
Gruß, Thomas
am Fri, dem 03.12.2004, um 20:47:09 +0100 mailte Thomas Guettler folgendes:
Hallo,
On Fri, Dec 03, 2004 at 11:18:13AM +0100, Sebastian Zwietz wrote: [cut]
Theoretisch kann mann ja auch die von iptables-save geschriebenen Daten bearbeiten - ich finde das aber wenig praktisch ...
Aus meiner Sicht ist das Tool "iptables-save" sinnlos. Bei komplexen iptables Regeln wird man sicherlich mit Variablen arbeiten.
Jein. In Verbindung mit -c ist es nett, um den Regelsatz komplex zu sehen & um zu sehen, welche Regeln getroffen werden. Diagnose. You know?
Andreas
Thomas Guettler schrieb:
Hallo,
Aus meiner Sicht ist das Tool "iptables-save" sinnlos. Bei komplexen iptables Regeln wird man sicherlich mit Variablen arbeiten.
Für eine grundlegende Konfiguration setze ich auch ein separates Skript ein, das aber nur bei Konfigurationsänderungen benutzt wird.
Für den laufenden Betrieb ist iptables-save ganz brauchbar.
Zum Beispiel $ETH_LAN $ETH_INET $ETH_DMZ (Intern, Internet, Demilitarisierte Zone)
Bei der Methode 1 (Setzen der Regeln per Shell-Script) ist es kein Problem, wenn sie die IP-Adresse von ETH_LAN ändert.
Wie häufig ändert sich denn die LAN-IP der Firewall? Das ist kein praktisches Problem.
Bei iptables-save hat man ein Problem. In der abgespeicherten Datei sind keine Variablennamen sondern die IP-Adressen und die müsste man durch umständliches Ersetzen ändern.
Beim der öffentlichen IP, welche wahrscheinlich die einzige sich ständig verändernde IP (dynIP) ist, kann man auch auf das Interface statt auf die IP matchen und muß damit nicht bei jeder Einwahl die Regeln ändern.
Ciao, Rico
Hallo Andreas
Erstmal Danke für den Vortrag in Dresden und die Folien...
Am 3 Dec 2004 um 10:10 hat Andreas Kretschmer geschrieben:
...
...die meinen wahrscheinlich das Initscript. Liegt wie gewöhnlich unter /etc/init.d/iptables. Eine Möglichkeit, den Status der Firewall permanent zu machen ist: '/etc/init.d/iptables save active'. Ich wurde auch
sorry, aber ich schrieb doch, dass es das script nicht gibt?!
Das speichert den aktuellen Zustand via iptables-save. Da muß man aber vorher halt die Regeln irgendwie gesetzt haben. Das, was Thomas Guettler schrieb, war so schon okay.
deshalb funktioniert auch das '/etc/init.d/iptables save active' nicht...
Nach einem 'updatedb' findet 'locate iptables' nur in /sbin je ein: iptabes iptables-save und iptables-restore
?das sind aber keine sripte?
Ich bezweifle, daß der Fragesteller häufig wechselnde Tunnel hat, IMHO wäre er mit einem Script, das er sich anhand meiner Folien, des Scriptes von Thomas und http://netfilter.org schreibt und es als normales Startscript einbindet, am besten bedient. Dazu sollte er aber auch seine Dienste nach Möglichkeit schon so konfigurieren, daß sie nicht unnötig nachaußen lauschen.
Ich habe versucht, mich bei der Installation zurückzuhalten, bin aber nicht wirklich sicher, was alles für Dienste laufen ( und ob sie nach außen arbeiten ).
bis dann Thomas
am Fri, dem 03.12.2004, um 21:37:41 +0100 mailte Mötzing Thomas folgendes:
Hallo Andreas
Erstmal Danke für den Vortrag in Dresden und die Folien...
Am 3 Dec 2004 um 10:10 hat Andreas Kretschmer geschrieben:
...
...die meinen wahrscheinlich das Initscript. Liegt wie gewöhnlich unter /etc/init.d/iptables. Eine Möglichkeit, den Status der Firewall permanent zu machen ist: '/etc/init.d/iptables save active'. Ich wurde auch
sorry, aber ich schrieb doch, dass es das script nicht gibt?!
ich schrieb das auch nicht...
Das speichert den aktuellen Zustand via iptables-save. Da muß man aber vorher halt die Regeln irgendwie gesetzt haben. Das, was Thomas Guettler schrieb, war so schon okay.
deshalb funktioniert auch das '/etc/init.d/iptables save active' nicht...
Nach einem 'updatedb' findet 'locate iptables' nur in /sbin je ein: iptabes iptables-save und iptables-restore
?das sind aber keine sripte?
Korrekt. Und?
Ich bezweifle, daß der Fragesteller häufig wechselnde Tunnel hat, IMHO wäre er mit einem Script, das er sich anhand meiner Folien, des Scriptes von Thomas und http://netfilter.org schreibt und es als normales Startscript einbindet, am besten bedient. Dazu sollte er aber auch seine Dienste nach Möglichkeit schon so konfigurieren, daß sie nicht unnötig nachaußen lauschen.
Ich habe versucht, mich bei der Installation zurückzuhalten, bin aber nicht wirklich sicher, was alles für Dienste laufen ( und ob sie nach außen arbeiten ).
netstat
Andreas
Moin Andreas
Am 3 Dec 2004 um 22:05 hat Andreas Kretschmer geschrieben:
...
...die meinen wahrscheinlich das Initscript. Liegt wie gewöhnlich unter /etc/init.d/iptables. Eine Möglichkeit, den Status der Firewall permanent zu machen ist: '/etc/init.d/iptables save active'. Ich wurde auch
sorry, aber ich schrieb doch, dass es das script nicht gibt?!
ich schrieb das auch nicht...
Sorry, hab ich nicht richtig aufgepaßt...
Ich habe versucht, mich bei der Installation zurückzuhalten, bin aber nicht wirklich sicher, was alles für Dienste laufen ( und ob sie nach außen arbeiten ).
netstat
probiere ich heute mal aus...
bis dann Thomas
N'abend,
On Friday 03 December 2004 21:37, Mötzing Thomas wrote:
sorry, aber ich schrieb doch, dass es das script nicht gibt?!
Ach so - ich dachte es gab nur Probleme mit dem Ort der Scripte.
Ich muss auch zu meiner Schande gestehen, dass in Debian dieses Script scheinbar nicht im iptables-Paket drin ist. Derjenige, der mir dieses Script gezeigt hat, verwies dabei auf eine Installation aus einem Knoppix. Bisher ging ich davon aus, dass Knoppix nicht allzuviel am ursprünglichen Debian geändert hat - aber scheinbar sind sämtliche Initscripte "angepasst" - Mist. Bleibt also erstmal der Weg eines eigenen Scriptes.
freundliche Grüße
Sebastian Zwietz ...der jetzt selber verwirrt ist.
Sebastian Zwietz schrieb:
Ich muss auch zu meiner Schande gestehen, dass in Debian dieses Script scheinbar nicht im iptables-Paket drin ist. Derjenige, der mir dieses Script
Doch, ich hab hier ein Sarge bei dem das Skript vorhanden ist. Es gibt kein weiteres installiertes Paket, welches von iptables abhängig ist oder von diesem empfohlen wurde. Es muß also im Paket iptables stecken.
Ich war ursprünglich überrascht als in /etc/init.d schon ein Skript iptables existierte, als ich mein eigenes dorthin kopieren wollte. Fand den Mechanismus allerdings ganz praktikabel.
Ciao, Rico
Hallo,
On Monday 06 December 2004 20:38, Rico Koerner wrote:
Doch, ich hab hier ein Sarge bei dem das Skript vorhanden ist. Es gibt kein weiteres installiertes Paket, welches von iptables abhängig ist oder von diesem empfohlen wurde. Es muß also im Paket iptables stecken.
Ich war ursprünglich überrascht als in /etc/init.d schon ein Skript iptables existierte, als ich mein eigenes dorthin kopieren wollte. Fand den Mechanismus allerdings ganz praktikabel.
Ciao, Rico
Ok, ich hab mal im debian-Pool nachgesehen. Die woody-Pakete scheinen das Script zu enthalten (iptables_1.2.6a-5.0woody1_i386.deb, iptables_1.2.6a-5.0woody2_i386.deb). Die testing- und unstable-Pakete (iptables_1.2.11-8_i386.deb, iptables_1.2.11-10_i386.deb) hingegen erstellen es nicht. Wäre mal interessant zu wissen, warum man es rausgenommen oder noch nicht reingenommen hat.
freundliche Grüße
Sebastian Zwietz EMAIL: sebastian@darkcity.de ICQ: 99430906
Am 6 Dec 2004 um 20:38 hat Rico Koerner geschrieben:
Sebastian Zwietz schrieb:
...
Ich war ursprünglich überrascht als in /etc/init.d schon ein Skript iptables existierte, als ich mein eigenes dorthin kopieren wollte. Fand den Mechanismus allerdings ganz praktikabel.
Hi Rico,
kannst Du das bitte auch verschicken? Vielleicht am Besten PM?! t_moetzing@gmx.de
Danke!
bis dann Thomas
Am Freitag, 3. Dezember 2004 21:37 schrieb Mötzing Thomas:
Hallo Thomas
...
...die meinen wahrscheinlich das Initscript. Liegt wie gewöhnlich unter /etc/init.d/iptables. Eine Möglichkeit, den Status der Firewall permanent zu machen ist: '/etc/init.d/iptables save active'. Ich wurde auch
sorry, aber ich schrieb doch, dass es das script nicht gibt?!
unter Woody wird das Script erst nach dpkg-reconfigure iptables zugänglich. Unter Sarge klappt das, zumindest bei mir, nicht.
hth, Thomas
Am 4 Dec 2004 um 18:44 hat Thomas Klose geschrieben:
Am Freitag, 3. Dezember 2004 21:37 schrieb Mötzing Thomas:
Hallo Thomas
...
...die meinen wahrscheinlich das Initscript. Liegt wie gewöhnlich unter /etc/init.d/iptables. Eine Möglichkeit, den Status der Firewall permanent zu machen ist: '/etc/init.d/iptables save active'. Ich wurde auch
sorry, aber ich schrieb doch, dass es das script nicht gibt?!
unter Woody wird das Script erst nach dpkg-reconfigure iptables zugänglich. Unter Sarge klappt das, zumindest bei mir, nicht.
Hi Thomas,
funktioniert bei mir auch nicht ( Sarge )
bis dann Thomas
lug-dd@mailman.schlittermann.de
-
Andreas Kretschmer -
Andreas Kretschmer -
Mötzing Thomas -
Rico Koerner -
Sebastian Zwietz -
Thomas Guettler -
Thomas Klose