IPTables und der Traffic

[r4z0r.b4ck]

Guten Morgen,

ich habe länger probiert und mehre Konfigurationen versucht, aber leider läuft der Traffic anscheint um IPTables herum.

Chain INPUT (policy ACCEPT 1713 packets, 713K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 2360 packets, 3298K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 1444 packets, 734K bytes)
 pkts bytes target     prot opt in     out     source               destination

So wie ich das sehe, hat IPTables auf den Traffic von cpmac0 oder adsl gar keinen Zugriff. Wenn man diesen Traffic nicht kontrollieren kann, so ist doch eine Erweiterung wie Quota eigentlich sinnlos.

adsl      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:2000  Metric:1
          RX packets:81185 errors:0 dropped:0 overruns:0 frame:0
          TX packets:42415 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:32 
          RX bytes:122834870 (117.1 MiB)  TX bytes:3681809 (3.5 MiB)

cpmac0    Link encap:Ethernet  HWaddr **:**:**:**:**:**  
          inet6 addr: *:*:*:*:*:*/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:44269 errors:0 dropped:0 overruns:0 frame:0
          TX packets:82723 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:3911918 (3.7 MiB)  TX bytes:122588827 (116.9 MiB)

dsl       Link encap:Point-to-Point Protocol  
          inet addr:169.254.2.1  P-t-P:169.254.2.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:2685 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1495 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:3356886 (3.2 MiB)  TX bytes:130475 (127.4 KiB)

Gibt es eine Möglichkeit, dass IPTables den Traffic richtig misst oder diesem Herr werden kann? Ich hoffe mal, ich habe es für jeden verständlich erklärt, viel Text ist es ja eigentlich nicht.

Danke auf jedenfalls schon einmal.

 

[cando]

Hi,

Der traffic läuft schon durch iptables, Deine Regeln für INPUT, OUTPUT und FORWARD sind default auf ACCEPT gesetzt, was soviel heißt, dass iptables alles überallhin durchläßt (also "ausgeschaltet" ist).

iptables mißt nicht den traffic, sondern filtert diesen (netfilter / iptables) und ist die firewall für Linux.

Schau mal in die Wiki, dort ist das Thema beschrieben und dort findest Du auch links zu weiterführender Literatur.

Was Anzahl und Volumen der Pakete angeht, liefert iptables ja keine Statistik pro interface sondern pro chain. Auch ist der Zeitpunkt für den Start / Dauer der Messung bei beiden Verfahren nicht unbedingt synchron.
Vom Volumen her kommt es ja ungefähr hin mit 3.4 MB, was die Anzahl der Pakete angeht ist eine Frage der Definition was ein Paket ist und auf welcher Schicht die gezählt werden.

Du kannst ja mal spaßeshalber ein paar IP Adressen deiner Rechner auf den entsprechenden Interfaces per iptables sperren, dann siehst Du schon, dass iptables funktioniert.

 

[RalfFriedl]

iptables mißt nicht den traffic, sondern filtert diesen

Das ist nicht ganz richtig, es wird auch einen Statistik geführt, die man im ersten Beitrag auch sieht.

In der iptables Terminologie heißt der Default ACCEPT (nicht PERMIT), und die Ausgabe zeigt, auf wie viele Pakete und wie viele Bytes diese Defaults Angewendet wurden. Da oben keine Regeln definiert sind, ist dies die Summe der Pakete bzw. Bytes.

Wenn das NAT über iptables laufen würde, dann müßte die Summe aus FORWARD und OUTPUT mindestens die 116MB enthalten, die ifconfig bei cpmac0 anzeigt. Das ist aber hier nicht der Fall.

Auch ist der Zeitpunkt für den Start / Dauer der Messung bei beiden Verfahren nicht unbedingt synchron.

iptables zählt ab dem Zeitpunkt, wo es geladen wird. Außerdem ist es möglich, die Zähler in iptables zurückzusetzen.
Ich vermute mal nicht, daß jemand die Zähler zurücksetzt und sich nachher über die Differenz wundert. Ein spätes Laden von iptables wäre denkbar, aber man kann auch prüfen, ob die Werte in gleichen Maß anwachsen.

was die Anzahl der Pakete angeht ist eine Frage der Definition was ein Paket ist und auf welcher Schicht die gezählt werden.

Ein Paket sollte in beiden Fällen ein Paket auf der Netzwerk-Ebene sein.

 

[cando]

Im Prinzip richtig, die Interface Statistik startet mit dem restart von dsld nachts irgendwann, wenn die neue ip adresse ausgehandelt wird, was die interfaces cpmac0 und adsl für einen traffic mit wem erzeugen, weiss ich auch nicht, jedenfalls haben sie keine zugewiesene ip Adresse. Ich vermute mal, die Pakete sind Synchronisationspakete / keep alive Pakete mit der DSL Vermittlungsstelle beim Provider und kein "echter" ip Traffic im Sinne von Nutz-Daten.

Deshalb werden sie wohl auch nicht herunter bis zum OS Kernel / iptables durchgereicht. Man müsste mal mit einem Sniffer nachschauen, was da alles an Protokollen zusätzlich abgeht.

Was die iptables Statistik angeht, weiss ich nicht, ob die einfach eine Auflaufsumme seit dem Reboot ist, oder sich eher auf ein Intervall bezieht (Tag oder Stunde). Wie kommt man eigentlich an die iptables Statistik? Ich bekomme z.B. bei iptables -L -v eine Auflistung der Pakete / des Volumens pro Reglel, die Werte sind aber keine Auflaufsumme seit dem Reboot, dafür sind die sind viel zu niedrig, die würden eher auf den Verkehr der letzten Stunde passen.

 

[RalfFriedl]

Wenn iptables einmal geladen ist, wann werden alle Pakete gezählt, bis die Zähler explizit zurückgesetzt werden. Und im Gegensatz zur Anzeige von ifconfig sind es 64-Bit Zähler. Bei mir stimmen zum Beispiel die Werte für das Interface 'lo' zwischen iptables und ifconfig überein.

Das Kommando "iptables -L -v" produziert genau die Ausgabe aus dem ersten Beitrag, wenn keine Regeln geladen sind.

Die Angabe "Chain INPUT (policy ACCEPT 1713 packets, 713K bytes)" besagt, daß in der Chain INPUT auf 1713 Pakete die Default Regel (hier ACCEPT) angewendet wurde, weil nicht vorher bei einer anderen Regel abgebrochen wurde. Wenn man für alles Regeln hat, dann kommt nichts durch, dann würde dort stehen 0 Pakete.

Das gleiche Kommando "iptables -L -v" zeigt auch die Zähler für jede einzelne Regel an, sofern eben Regeln überhaupt vorhanden sind.

Wenn Du bei Dir niedrige Werte hast, die evtl. jede Stunde neu anfangen (was sich feststellen ließe), dann läuft bei Deinem System vermutlich ein cron-Job, der die Statistiken einsammelt und die Zähler zurücksetzt. Auf einer Fritz-Box wird wohl kaum ein derartiger Job eingerichtet sein, wenn man das nicht selbst tut.

cpmac0 ist das Gerät für den internen Switch, hat also nur mit Ethernet zu tun und nichts mit DSL. Daher können das nicht keep-alive Pakete der DSL-Verbindung sein, allenfalls vielleicht bei Internet über LAN1. Da beim Interface adsl ein hoher Wert auf der Empfangsseite steht und bei cpmac0 ein ähnlicher Wert auf der Sendeseite, kann man davon ausgehen, daß das ungefähr der Download ist, seit diese Zähler laufen. Da cpmac0 (und vermutlich adsl) beim Systemstart angelegt werden und danach nicht wieder gelöscht, kann man davon ausgehen, daß die Zahlen den Wert seit Systemstart angeben.

Beim PPP Interface dsl (ohne a) könnte es sein, daß dieses bei jeder neuen Verbindung frisch angelegt wird und daher nur die Werte des jeweiligen Tages enthält.

Sinnvollerweise würde man iptables gleich beim Start der Box automatisch laden und sich die Zahlen mal anschauen, bevor es zu einer Zwangstrennung kommt.

 

[cuma]

Ich hatte das schonmal mit iptables versucht, allerdings sind die Werte viel zu niedrig. Was anscheinend die richtigen Werte liefert "cat /proc/net/dev"

 

[RalfFriedl]

Bei mir liest ifconfig die Datei /proc/net/dev, also stammen die von ifconfig gezeigten Werte möglicherweise genau von dort.

Ich vermute, daß Dein System zu bestimmten Zeiten die Werte ausliest und zurücksetzt.
Mach doch einen cron-Job, der alle paar Minuten die Werte von iptables ausliest und in eine Datei speichert, zusammen mit der Uhrzeit. Dann siehst Du, ob die Werte irgendwann zurückgesetzt werden.

 

[r4z0r.b4ck]

cpmac0 ist das Gerät für den internen Switch, hat also nur mit Ethernet zu tun und nichts mit DSL. Daher können das nicht keep-alive Pakete der DSL-Verbindung sein, allenfalls vielleicht bei Internet über LAN1. Da beim Interface adsl ein hoher Wert auf der Empfangsseite steht und bei cpmac0 ein ähnlicher Wert auf der Sendeseite, kann man davon ausgehen, daß das ungefähr der Download ist, seit diese Zähler laufen. Da cpmac0 (und vermutlich adsl) beim Systemstart angelegt werden und danach nicht wieder gelöscht, kann man davon ausgehen, daß die Zahlen den Wert seit Systemstart angeben.

Der bis dahin entstandene waren diese ca. 100MB. Teilweise zählt IPTables bzw. das Interface DSL kurz mit, allerdings ist es nicht von Dauer. Ich habe die fritz!box neugestartet und mir nach einem Download direkt die Werte ausgeben lassen.

Chain INPUT (policy ACCEPT 264K packets, [B]148M bytes[/B])
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 1582K packets, [B]234M bytes[/B])
 pkts bytes target     prot opt in     out     source               destination         
1346K   [B]90M[/B] ACCEPT     all  --  any    dsl     anywhere             anywhere            

Chain OUTPUT (policy ACCEPT 236K packets, [B]146M bytes[/B])
 pkts bytes target     prot opt in     out     source               destination

Insgesamt sind ja jetzt 324 MByte über FORWARD gegangen und 146 MByte über OUTPUT, allerdings melden adsl und cpmac0 2,1 GByte (+ 327MByte Upload).

Ich vermute, daß Dein System zu bestimmten Zeiten die Werte ausliest und zurücksetzt.
Mach doch einen cron-Job, der alle paar Minuten die Werte von iptables ausliest und in eine Datei speichert, zusammen mit der Uhrzeit. Dann siehst Du, ob die Werte irgendwann zurückgesetzt werden.

Die Werte von heute morgen sind direkt nach dem einschalten der Box entstanden. Er setzt auch nicht die Werte zurück, sondern der Datentransfer läuft gar nicht über IPTables. IPTables sieht nur die Werte des Interfaces dsl.

 

[RalfFriedl]

Es wäre noch ganz nett zu wissen, was Du in der Zeit getan hast, und was ifconfig dazu sagt.

Deine iptables Ausgabe deutet auf einen Download von 234MB und einen Upload von 90MB hin. Außerdem scheint einiges an lokalem Traffik gewesen zu sein mit der Box als Endpunkt.

 

[r4z0r.b4ck]

Es wäre noch ganz nett zu wissen, was Du in der Zeit getan hast, und was ifconfig dazu sagt.

Deine iptables Ausgabe deutet auf einen Download von 234MB und einen Upload von 90MB hin. Außerdem scheint einiges an lokalem Traffik gewesen zu sein mit der Box als Endpunkt.

adsl      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:2000  Metric:1
          RX packets:3267749 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2846868 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:32 
          RX bytes:2235416241 (2.0 GiB)  TX bytes:284393688 (271.2 MiB)

cpmac0    Link encap:Ethernet  HWaddr ***************
          inet6 addr: *****************/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3169325 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3542600 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:441576552 (421.1 MiB)  TX bytes:2377943953 (2.2 GiB)

dsl       Link encap:Point-to-Point Protocol  
          inet addr:169.254.2.1  P-t-P:169.254.2.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:1972785 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1893669 errors:0 dropped:17 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:279733853 (266.7 MiB)  TX bytes:133366635 (127.1 MiB)

Deine iptables Ausgabe deutet auf einen Download von 234MB und einen Upload von 90MB hin. Außerdem scheint einiges an lokalem Traffic gewesen zu sein mit der Box als Endpunkt.

Ja, hatte ich ja auch so geschrieben. Ich habe es nur schon zusammengerechnet. Die Werte vom Interface adsl sind anscheint korrekt, den diese stimmen mit dem Verbrauch der Computer überein. Der Datentransfer von adsl ist also wirklich entstanden und keine Fiktion.

Jetzt nun die Frage aller Fragen, wie kommt ich an diesen Traffic heran?

//edit: Der Versuch alle Pakete per DROP zu verwerfen ist durch den Umstand, dass IPTables keinen vollständigen Zugriff auf dem Datentransfer hat auch nicht möglich. Es bleiben nicht nur Verbindungen offen, sondern man kann auch neue Verbindungen öffnen. :-\

 

[cando]

Hi,

was hast Du für eine Box / Firmware laufen (keine Signatur)? Ich kann mit iptables alles nach aussen und innen steuern. Wenn ich eine Sperre setze, dann ist der Verkehr auch dicht und es kann weder eine Verbindung aufgebaut werden, noch wird eine bestehende Verbindung weiter aufrecht erhalten.

Damit kann man alles nach aussen sperren und nur den Zugriff aus dem LAN auf die Box für alle Protokolle / Ports zulassen. Zugriff in das Internet sowohl von der Box als auch aus dem LAN ist gesperrt. (LAN auf 192.168.0.0/24 konfiguriert). Da geht nicht mal mehr die DNS Auflösung.

iptables -A INPUT -s 192.168.0.0/24 -j ACCEPT        # LAN Zugriff
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT     # stateful response
iptables -A OUTPUT -j LOG --log-prefix "DROP OUTPUT "
iptables -A INPUT -j LOG --log-prefix "DROP INPUT "
iptables -A FORWARD -j LOG --log-prefix "DROP FORWARD "
iptables -P FORWARD DROP
iptables -P INPUT DROP
iptables -P OUTPUT DROP

Versuch mal damit irgend eine Verbindung nach aussen aufzubauen. Auf der Konsole werden die verworfenen Pakete protokolliert. Da kannst Du Dir ansehen, was die Box alles sperrt.

 

[r4z0r.b4ck]

was hast Du für eine Box / Firmware laufen (keine Signatur)?

Das mit der Signatur hole ich nach, es ist eine Fritz!Box 7270 54.04.76freetz-devel-3488M mit Dnsmasq, Dropbear, Openntpd, RRDstats, Vsftpd und so weiter.

Wenn ich eine Sperre setze, dann ist der Verkehr auch dicht und es kann weder eine Verbindung aufgebaut werden, noch wird eine bestehende Verbindung weiter aufrecht erhalten.

Damit kann man alles nach aussen sperren und nur den Zugriff aus dem LAN auf die Box für alle Protokolle / Ports zulassen. Zugriff in das Internet sowohl von der Box als auch aus dem LAN ist gesperrt. (LAN auf 192.168.0.0/24 konfiguriert). Da geht nicht mal mehr die DNS Auflösung.

iptables -A INPUT -s 192.168.0.0/24 -j ACCEPT        # LAN Zugriff
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT     # stateful response
iptables -A OUTPUT -j LOG --log-prefix "DROP OUTPUT "
iptables -A INPUT -j LOG --log-prefix "DROP INPUT "
iptables -A FORWARD -j LOG --log-prefix "DROP FORWARD "
iptables -P FORWARD DROP
iptables -P INPUT DROP
iptables -P OUTPUT DROP

Versuch mal damit irgend eine Verbindung nach aussen aufzubauen. Auf der Konsole werden die verworfenen Pakete protokolliert.

Ich kann nur das sagen, was ich festgestellt habe. Ein Computer hatte, trotz dass ich die Verbindungen unterbunden habe, eine Verbindung hergestellt. ICQ ging ohne Probleme. DNS-Auflösung läuft bei mir über Dnsmasq. Wenn ich iptables -P FORWARD DROP oder iptables -I 1 FORWARD -j DROP, so müsste ich doch eigentlich den gesamten Traffic ins Internet und zu anderen Computer verwerfen. Leider können sowohl über WLAN als auch LAN verbundene Computer weiterhin einige Verbindungen ins Netz offen halten. Leider kann ich bisher noch kein Muster erkennen.

Was auch noch offen bleibt, wenn der gesamte Traffic über iptables läuft, wieso spuckt die Statistik dann falsche Werte bei den Trafficwerten aus? iptables gibt die gleichen Werte wie das Interface DSL aus, nur dieses sind einfach nicht korrekt. Mir bleibt wohl nichts anderen übrig, also einfach auf ein Muster zu hoffen.

Euch allen trotzdem erstmal danke.

 

[crissi99]

Gibt es es schon neue Erkenntnisse, warum iptables nicht allen Traffic sieht bzw wie man das ändern kann?

Es ist schade, wenn man den Trafficzähler per Chain nicht nutzen kann, da die Daten nicht richtig (nicht verwertbar) sind.

 

[Silent-Tears]

Da musst du bei AVM anfragen, denn deren closed-source-part macht da probleme.

 

[RalfFriedl]

Es gibt die alten Erkenntnisse, und man kann versuchen, AVM dazu zu bewegen, das zu ändern (viel Glück dabei).

 

[Silent-Tears]

Alternativ dem Projekt folge leisten, in dem veruscht wird, ohne den AVM-Part auszukommen beim einwählen/routing/bridging/etc. Dann sollte iptables auhc sauber zählen können.

 

[crissi99]

Welches? OpenWRT? Ich würde das gern ausprobieren.

 

[crissi99]

Es gibt die alten Erkenntnisse, und man kann versuchen, AVM dazu zu bewegen, das zu ändern (viel Glück dabei).

Wo muss ich denn hinschreiben? Ich würde es nochmal versuchen (Zählproblem von iptables und Speicherüberlauf bei ip_conntrack).

 

[MaxMuster]

Dieses Thema wäre z.B. ein Ansatzpunkt, denke ich Es geht: FBF ohne dsld aber mit DSL.

Jörg

 

[RalfFriedl]

Wo muss ich denn hinschreiben?

Du wirst ja noch einen Kontakt von AVM herausbekommen.

Ansonsten vermute ich, daß daß jede Adresse von AVM da gleich gut (oder eher gleich schlecht) ist. Mit etwas Glück bekommst Du die Antwort, daß sie darüber nachdenken, ob sie es irgendwann einmal umsetzen werden. Vielleicht bekommst Du auch die ehrliche Antwort, daß sie das auf keinen Fall machen werden.