Am 19.03.2015 19:05, schrieb Lentes, Bernd:

Hi,

ich habe da ein kleines grundsätzliches Verständnisproblem:

Grundlage ist ein SLES12 mit folgenden Regeln (ich habe die Kette FORWARD, forward_ext und reject_func der besseren Lesbarkeit wegen weggelassen):

==================================================== Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 9612K 4434M ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 53952 96M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate ESTABLISHED 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED 7105 1531K input_ext all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 6 level 4 prefix "SFW2-IN-ILL-TARGET " 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ... Chain OUTPUT (policy ACCEPT 34770 packets, 1965K bytes) pkts bytes target prot opt in out source destination 9612K 4434M ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0 ... Chain input_ext (1 references) pkts bytes target prot opt in out source destination 6918 1493K DROP all -- * * 0.0.0.0/0 0.0.0.0/0 PKTTYPE = broadcast 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 4 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 8 0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 5 tcp dpt:80 flags:0x17/0x02 LOG flags 6 level 4 prefix "SFW2-INext-ACC-TCP " 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 5 tcp dpt:7937 flags:0x17/0x02 LOG flags 6 level 4 prefix "SFW2-INext-ACC-TCP " 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:7937 0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 5 tcp dpt:7938 flags:0x17/0x02 LOG flags 6 level 4 prefix "SFW2-INext-ACC-TCP " 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:7938 1 52 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 5 tcp dpt:22 flags:0x17/0x02 LOG flags 6 level 4 prefix "SFW2-INext-ACC-TCP " 1 52 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:7938 185 38600 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 PKTTYPE = multicast 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 PKTTYPE = broadcast 0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 5 tcp flags:0x17/0x02 LOG flags 6 level 4 prefix "SFW2-INext-DROP-DEFLT " 0 0 LOG icmp -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 6 level 4 prefix "SFW2-INext-DROP-DEFLT " 0 0 LOG udp -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 5 ctstate NEW LOG flags 6 level 4 prefix "SFW2-INext-DROP-DEFLT " 1 40 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ... ===================================================

Als Beispiel nehmen wir das Betrachten einer Webseite mit Firefox: nehmen wir an, Firefox hat ein Socket mit Quellport 54321 und Zielport 443. Diese Pakete kommen problemlos raus, da die policy für die Kette OUTPUT auf ACCEPT lautet. Was ist aber jetzt mit dem Antwortpaket ? Das hat Quellport 443 und Zielport 54321. Für den Zielport 54321 gibt es in input_ext keine Regel. Kommt das Antwortpaket mit der Kette schon mal nicht an. Schauen wir uns die Kette INPUT an. Die erste Regel passt nicht, da das device lo nicht involviert ist. Die 2. Regel könnte passen. Dazu sagt aber die man-page: " conntrack - This module, when combined with connection tracking, allows access to the connection tracking state for this packet/connection. [!] --ctstate statelist statelist is a comma separated list of the connection states to match. Possible states are listed below."

und etwas weiter unten: " ESTABLISHED - The packet is associated with a connection which has seen packets in both directions."

Es sind aber noch nicht Pakete in beide Richtungen geflogen, sondern erst in eine. Wieso kommt dann die Antwort von dem Webserver an ? Oder greift da irgendeine andere Regel, die ich übersehe ?

Bernd

Hi, bitte korrigiere mich wer, wenn ich irre... aber für mich greift da die ESTABLISHED-Regel; weil die Verbindung von innen eingerichtet ("etabliert") wurde, sind mit ihr verbundene Antwortpakete akzeptiert. Vielleicht ist die Formulierung "connection which has seen packets in both directions." ein wenig unglücklich ... bzw. könnte man annehmen, dass die Regel dann eben auch greift, wenn das erste Paket in der 2. Richtung kommt. Entscheidend ist IMHO, dass dem ein zugelassenes Paket in einer Richtung vorausging. Zugegebenermaßen steht bei mir da "ESTABLISHED, RELATED" BTW zumindest für mich wären die iptables-Befehle, die in Deiner FW-config stehen evt. besser lesbar, egal womit Du die konfigurierst, sollte es ja irgendwo eine Datei dafür geben... cu jth -- www.teddylinx.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Jörg schrieb: ...

...

Hi,

bitte korrigiere mich wer, wenn ich irre... aber für mich greift da die ESTABLISHED-Regel; weil die Verbindung von innen eingerichtet ("etabliert") wurde, sind mit ihr verbundene Antwortpakete akzeptiert. Vielleicht ist die Formulierung "connection which has seen packets in both directions." ein wenig unglücklich ... bzw. könnte man annehmen, dass die Regel dann eben auch greift, wenn das erste Paket in der 2. Richtung kommt. Entscheidend ist IMHO, dass dem ein zugelassenes Paket in einer Richtung vorausging.

Zugegebenermaßen steht bei mir da "ESTABLISHED, RELATED"

BTW zumindest für mich wären die iptables-Befehle, die in Deiner FW- config stehen evt. besser lesbar, egal womit Du die konfigurierst, sollte es ja irgendwo eine Datei dafür geben...

cu jth

--

Hallo Jörg, das ist letztendlich auch mein Erklärungsansatz, das die man-page ist in diesem Punkt nicht ganz korrekt ist. Obwohl ich man-pages immer als Bibel betrachtet habe. Bernd Helmholtz Zentrum München Deutsches Forschungszentrum für Gesundheit und Umwelt (GmbH) Ingolstädter Landstr. 1 85764 Neuherberg www.helmholtz-muenchen.de Aufsichtsratsvorsitzende: MinDir´in Bärbel Brumme-Bothe Geschäftsführer: Prof. Dr. Günther Wess, Dr. Nikolaus Blum, Dr. Alfons Enhsen Registergericht: Amtsgericht München HRB 6466 USt-IdNr: DE 129521671 -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org