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)
