[Frage] Logging des Gästezugangs

Hallo,

mit iptables und einem geeigneten Log-Target müßte das gehen.

Grüße,

JD.

Moin

Falls die Informationen auch allgemeiner Art sein dürfen,
und du freetz auf der Box hast, lohnt sich vielleicht auch
ein Blick auf: DarkStat

Und das Interface kann im LAN mit Webbrowser erreicht werden.

Out of the box: ganz klar nein ...
Durch Monitoring der NAT-Mappings (ob das machbar ist, hängt von der Box ab) und Auflösung der dort verwendeten IP-Adressen unmittelbar im Anschluß: durchaus möglich

Unter der Annahme, daß ein Besuch einer Webseite mit HTTP(S) erfolgen müßte und dabei dann NAT stattfinden würde.

Aber mit Aufwand verbunden ... wer sich damit aus der Störerhaftung vorauseilend "befreien" will - z.B. in einer kleinen Pension - darf auch den Datenschutz-Aspekt nicht aus den Augen lassen. Eine "Überwachung" ohne das Wissen des Überwachten wäre unzulässig.

Aktive NAT-Sessions (so etwas ähnliches wie die conntrack-Liste bei iptables) gibt die 7390 unter /proc/kdsld/dsliface/internet/ipmasq/mappings preis, die MAC-Adressen zu den IP-Adressen unter /proc/kdsld/neigh/ipaddr ... da sogar, an welchem LAN-Port der Client angeschlossen ist.

Es gibt keine Trigger, tail funktioniert imho auch nicht richtig für das proc-Interface und inotify schon mal gar nicht. Man muß also Polling machen, je nach Anzahl der Clients dauert die Verarbeitung in Shell-Code auch etwas.

Ob man auch HTTP/1.0-Sessions komplett erwischt, wenn man nicht schnell genug ist, habe ich noch nie getestet ... HTTP/1.1-Sessions (eigentlich heutzutage die Regel) dauern länger und sind auch im 3-Sekunden-Abstand gut zu sehen. Die Belastung des Prozessors durch ein ordentliches Shell-Skript ist zu vernachlässigen, allerdings ist an Tiefschlaf bei 20 Loops pro Minute natürlich nicht zu denken.

@koerli:
Nein (jedenfalls keines, was ich rausgeben würde, ist ja nun aber auch kein wirkliches Kunststück). Ja, sollte es ...

Ich habe allerdings #1 nicht richtig gelesen ... da ist ja vom "Gästezugang" die Rede (eigentlich hatte ich das doch registriert, deshalb auch die Pension-Vermutung, dann aber wieder verdrängt).
Ob die NAT-Verbindungen über die guest-Bridge auch dort verwaltet werden, mußt Du selbst mal prüfen ... ich weiß es nur für "normales" (W)LAN.

Da spielen so viele Aspekte rein ... wenn man das "mal" machen will, reicht Shell-Code, als permanente Installation ist ein kleines C-Programm logischerweise die schnellere Alternative.

Einfacher geht es vermutlich, wenn man mit iptables die SYN Pakete aus dem LAN Protokolliert, da hat man die MAC Adresse des Clients und die IP-Adresse und Port des Servers gleich drin und braucht auch kein Polling, sondern kann das bequem aus dem Syslog auslesen.

Mein Fehler, hab nicht auf das Forum geachtet, in dem der Thread steht.

Wenn man auf der 7390 Freetz mit iptables hat, ist das natürlich der einfachere Weg.

Meines Wissens - gerne korrigieren, wenn das falsch ist - braucht man dann eine ältere Firmware-Version für die 7390, die von AVM selbst nicht mehr angeboten wird und keinen Fix für die Lücke erhalten hat. Oder funktioniert iptables wieder mit einer der im Trunk für die 7390 unterstützten Versionen (>= 05.2x) ? Da ich es nicht benutze auf der FRITZ!Box, habe ich da absolut keinen Überblick ...

Das Problem mit iptables ist, dass man kein conntrack verwenden kann. Das liegt daran, dass die binären Kernel Module von AVM nicht kompatibel mit dem Rest sind, wenn man conntrack aktiviert. Conntrack wiederum ist Voraussetzung für NAT, was eine häufige Anwendung für iptables auf der Box ist, denn ein Firewall ist ja bereits vorhanden.

Hierfür braucht man kein conntrack, es reicht ein Filter auf gesetztes SYN und ggf. Zieladresse.

RalfFriedl schrieb:

Das Problem mit iptables ist, dass man kein conntrack verwenden kann. Das liegt daran, dass die binären Kernel Module von AVM nicht kompatibel mit dem Rest sind, wenn man conntrack aktiviert. Conntrack wiederum ist Voraussetzung für NAT, was eine häufige Anwendung für iptables auf der Box ist, denn ein Firewall ist ja bereits vorhanden.

Zum Vergrößern anklicken....

Spannend ... nur damit ich es nicht falsch verstehe, noch einmal eine Nachfrage (hat mit dem Anliegen des TE dann nichts zu tun):

Wenn ich auf nf_conntrack verzichte (mit allem, was da dran hängen könnte ... das funktioniert dann sicherlich auch nicht), kann ich iptables auf aktueller Firmware verwenden ?

Also z.B. auch DNAT für eingehende Dienste auf dem dsl-Interface machen, wenn das Ziel bekannt ist (notfalls das lan-Interface der Box selbst), denn dafür braucht es ja nur feste Umsetzungen und kein Connection Tracking ? Wenn es ein Paket vom DSL-Port des Switches bis zum CPU-Port schafft (durch die Flow Routing Tables), dann müßte es sich ja auch weiterverarbeiten lassen. Oder wird am Ende das reject für ein solches Paket schon in den Flow Routing Tables direkt gemacht ?

So viele Fragen ... dann wäre ja iptables doch wieder eine Lösung für Freigabe-Probleme bzw. auch andere Sachen, wie redirect-Targets, ipset-Tables oder Limits müßten klaglos funktionieren ... das wäre ja glatt eine Überlegung wert, den DoS-/BruteForce-Schutz des SSH-Servers dann vom internen Server direkt auf die FRITZ!Box zu verlagern und dort dann auch den HD-Receiver von KDG direkt auf die 6360 umzulenken, wenn die Zieladresse im KDG-Netz liegt. Das muß ich dann tatsächlich mal ansehen ... reichen Module aus, um iptables nachzurüsten bei 7390/7490 oder braucht es zwingend den eigenen Kernel ? (Ich weiß, ich sollte selbst nachlesen, aber fragen kostet ja auch nichts. Weißt Du jemanden, der sich mit dem Packet Accelerator von AVM mal intensiver befaßt hat ? Bitte nicht "AVM" antworten ... )

PeterPawn schrieb:

Wenn ich auf nf_conntrack verzichte (mit allem, was da dran hängen könnte ... das funktioniert dann sicherlich auch nicht), kann ich iptables auf aktueller Firmware verwenden ?

Zum Vergrößern anklicken....

Zumindest spricht aus meiner Sicht nichts dagegen, nur weiß ich nicht, ob jemand das bereits versucht hat. Die meisten interessanten Anwendungen brauchen conntrack.

Also z.B. auch DNAT für eingehende Dienste auf dem dsl-Interface machen, wenn das Ziel bekannt ist (notfalls das lan-Interface der Box selbst), denn dafür braucht es ja nur feste Umsetzungen und kein Connection Tracking ?

Zum Vergrößern anklicken....

DNAT braucht conntrack. Redirect auch.

Weißt Du jemanden, der sich mit dem Packet Accelerator von AVM mal intensiver befaßt hat ? Bitte nicht "AVM" antworten ... )

Zum Vergrößern anklicken....

Dann eben keine Antwort

koerli schrieb:

... ein fertiges ...

Zum Vergrößern anklicken....

Versuch mal auf deiner FritzBox, mit z. B.:

@koerli:
Ich habe jetzt den ersten Beitrag noch einmal richtig gelesen ... und bin dabei an "welche ip/ website(adresse)" hängen geblieben. Unter "website(adresse)" würde ich die besuchte Domain mit der Webpräsenz verstehen, nicht den Reverse-DNS-Namen des besuchten Servers.

Wenn Du nicht nur die besuchten IP-Adressen, sondern wirklich auch die besuchten Websites protokollieren willst, wird das - Thema VirtualHost - weder mit iptables, noch mit dem AVM-proc-Interface ausreichend sein.

Dafür müßtest Du dann wohl doch die komplette Verbindung analysieren, denn der eigentlich angeforderte Inhalt (der HTTP-Request) steht nicht in einen SYN-Paket und wird erst nach dem erfolgreichen Abschluß des 3-Wege-Handshakes vom Client an den Server gesendet. Je nachdem, wie genau die Protokollierung (nur bei ungesicherter Verbindung überhaupt möglich, bei TLS müßte man die Verbindung aufbrechen) sein soll, wäre ein iptables-Logging anhand des Paketinhalts (-m string) vielleicht ausreichend, wenn man die HTTP-Request-Pakete loggt.

Und auch wenn das Beschränken der Protokollierung auf die TCP-Ports 80 und 443 naheliegend erscheinen mag (ich weiß natürlich genauso wenig wie die anderen hier, warum Du das Logging haben willst) ... es kann genauso gut auch Verbindungen auf anderen Ports geben, wenn da innerhalb einer HTML-Seite (oder was auch immer) URLs mit einem anderen Port auftauchen. Für eine komplette Protokollierung würde ich daher keine Beschränkung auf 80/443 vornehmen.

Das Problem mit dem "VirtualHost" gilt am Ende (Stichwort SNI) auch für SSL-Verbindungen, da kommt man mit iptables (oder irgendwelchen anderen Paket-Loggern) dann aber ohnehin nicht mehr weiter, da eine Analyse des Inhalts auf der FRITZ!Box nicht möglich ist.