Hallo, >ich habe meinem Paketfilter beigebracht, per default alles zu verweigern >und nur bestimmte Ports (SSH, Web, SMTP, POP3, etc) zu �ffnen und auch >nur in bestimmte Richtungen (SSH und FTP nach aussen sind dicht, aber >von aussen offen). > >Zus�tzlich habe ich mit >$IPT -A OUT -m state --state ESTABLISHED,RELATED -j ACCEPT >$IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT > >(OUT ist eine Zusammenfassung von FORWARD und OUTPUT) > >festgelegt, da� auf jeden Fall bestehende Verbindungen nicht gest�rt >werden sollen.
Hast Du sichergestellt, dass diese "zus�tzlichen" Regeln die ersten der jeweiligen Chains sind? Wenn andere Regeln vorher greifen und das Target dort DROP ist, dann ist es vorbei. Speziell bei der OUT Chain (deren Sinn mir unklar ist) musst Du ausserdem darauf achten, dass nicht in den Chains OUTPUT und FORWARD weitere Regeln stehen, die vorher greifen. >Trotzdem kriege ich ab und an Meldungen wie diese im syslog > >kernel: IN= OUT=eth0 SRC=193.111.112.14 > DST=134.28.62.2 LEN=100 TOS=0x12 PREC=0x00 TTL=64 ID=41329 DF PROTO=TCP > SPT=22 DPT=3293 WINDOW=10944 RES=0x00 ACK PSH URGP=0 >kernel: IN= OUT=eth0 SRC=193.111.112.14 > DST=134.28.62.2 LEN=164 TOS=0x12 PREC=0x00 TTL=64 ID=41329 DF PROTO=TCP > SPT=22 DPT=3293 WINDOW=10944 RES=0x00 ACK PSH URGP=0 Was genau an diesen Logs schlimm sein soll, musst Du noch erkl�ren. Eine solche Zeile entsteht genau dann, wenn eine Regel passt, die ein LOG Target enth�lt. An welcher Stelle stehen in Deiner Konfiguration LOG Targets? >und das oft zeitgleich mit einer urpl�tzlich abgebrochenen >SSH-Verbindung zu besagtem Rechner. >Wo liegt mein Denkfehler? Ich dachte, obige iptables-Regel sollte >bestehende Verbindungen nicht kappen. Oder habe ich mir einen Trojaner >eingefangen? ;*) Bei so wenigen Informationen kann man nur raten, wo das Problem liegt. Wenn ich es richtig verstehe, verd�chtigst Du Netfilter, den Zustand der TCP-Verbindungen nicht oder nicht korrekt zu verfolgen. Folgendes f�llt mir dazu ein: - Falsche Reihenfolge der Regeln, siehe oben. - Irgendwo im Regelwerk fehlt ein "-m state --state NEW" bei einer Regel, die eigentlich nur auf neu initiierte Verbindungen greifen sollte. - Zu lange Idle-Zeiten innerhalb einer Verbindung. Der Kernel schmeisst Verbindungen, �ber die l�ngere Zeit kein Paket geht, aus dem Speicher, um tote Verbindungen nicht ewig zu halten. - Eine der Seiten hat ein TCP RST geschickt - Dein Netfilter l�uft als Kernelmodul, und Dein Rechner ist so konfiguriert, dass Kernel-Module nach einiger Zeit der Inaktivit�t automatisch entladen werden. In diesem Fall vergisst der Kernel die Verbindungen. - Auf einer der Seiten wechselt die IP-Nummer, z.B. weil es sich um eine Dialup-Verbindung mit dynamischer IP-Nummernvergabe handelt. - Die maximale Anzahl gespeicherter Verbindungen wird �berschritten (steht bei Kernel 2.4.19 auf 2089, siehe conntrack_core.c). Ich empfehle Dir, mal mein Firewall-Skript auszuprobieren. Du findest es auf meiner Homepage www.weidner.ch unter Download, ziemlich weit unten. Wenn es damit funktioniert, dann ist der Fehler bei Dir vermutlich im Regelsatz. Gru�, Harald -- Harald Weidner [EMAIL PROTECTED] -- H�ufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
