FB Gastzugang loggen

[sf3978]

...
Ok, also emule und co suchen sich Ihre Ports, das ist bescheiden.
...

Das ist ausgeklügelt, gewieft und clever.

 

[cybertron]

ich muss das Thema nochmal rauskramen, da ich vor der selben herausforderung stehe.

Ich habe versucht, mit iptable, privoxy bzw. iptable, polipo zum einen den Gastzugang auf den Proxy zu zwingen, damit die Besucher nichts am PC einstellen müssen, zum anderen mit den anfallenden Logfiles die über den proxy gelaufenen seiten zu loggen.
Polipo cacht zwar die Seiten, loggt aber irgendwie gar nichts von wegen.. wer-wohin..
gleiches gilt für privoxy...

Den Weg über httpry hab ich im Moment so ein wenig in den Hintergrund verworfen, da ich hier keine Möglichkeit sehe, nur den Gastzugang zu loggen.
Den gesamten verkehr zu loggen, würde in meinen Augen den Rahmen sprengen, da die anfallenden Daten dann schon erheblich sind.

Vielleicht hat jemand ja noch ne Idee, wie man es realisieren kann.

P.S. die Disskusion über die rechtliche Verwendbarkeit brauchen wir bitte da nicht weiter führen... das ist mir klar ..

Gruß
Cyby

 

[sf3978]

...
Den Weg über httpry hab ich im Moment so ein wenig in den Hintergrund verworfen, da ich hier keine Möglichkeit sehe, nur den Gastzugang zu loggen.
...

Warum geht das nicht, nur den Gastzugang zu loggen mit httpry?

 

[andilao]

Ähnliches habe ich auch vor, und zwar soll alles außer Port 80 und 443 für den WLAN-Gast gesperrt werden.

Nun ist das Gateway für das Gast-WLAN wohl immer 192.168.179.1 und da könnte man doch alle Ports für alle Hosts bis auf diesen sperren, der bekommt Port 80 und 443. Nur bekomme ich das nicht hin, weil da ja noch ein Subnetz ist, das ich komplett offen lassen will/muss.

 

[sf3978]

Was meinst Du mit:

..., weil da ja noch ein Subnetz ist, das ich komplett offen lassen will/muss.

?

EDIT:
Mit tcpick sollte man den Datenverkehr über das guest interface loggen können:

root@fritz:/var/mod/root# [B]tcpick[/B] -i [B][COLOR="red"]guest[/COLOR][/B] -a -td -C "tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and dst port 80 or dst port 443"
Starting tcpick 0.2.1 at 2011-02-25 22:10 CET
Timeout for connections is 600
tcpick: [COLOR="blue"]listening on guest[/COLOR]
setting filter: "tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and dst port 80 or dst port 443"

Als Filter, kann der tcpdump-Filter verwendet werden.

 

[andilao]

Das "Subnetz" ist das normale LAN+WLAN.

 

[sf3978]

...
Nun ist das Gateway für das Gast-WLAN wohl immer 192.168.179.1 und da könnte man doch alle Ports für alle Hosts bis auf diesen sperren, der bekommt Port 80 und 443. ...

Das Interface guest1 kann man auf unterschiedlich 192.168.179.1, konfigurieren (rc.custom), z. B.:

ifconfig guest1 inet 192.168.177.1 netmask 255.255.255.0 broadcast 192.168.177.255

und per WLAN über dieses Interface/Subnetz, eine Verbindung zur Box herstellen. Mit iptables kann man für dieses Subnetz, nur die Ports 80 und 443 freigeben. Routing und S-NAT (MASQUERADE) muss evtl. angepasst werden.

 

[Ernest015]

Ähnliches habe ich auch vor, und zwar soll alles außer Port 80 und 443 für den WLAN-Gast gesperrt werden.

Was aber auch nicht viel bringt, da Torrent-Clients wie beispielsweise Vuze (Azureus) die Verbindung auch über den TCP-Port 80 abwickeln können.

mfg

 

[cybertron]

Also ich log das ganze jetzt bei mir über den httpry je Device in ein separates Logfile und importiere die Logfiles dann über Cron in eine Sqlite3-DB, die sich schön per php darstellen lässt.

Für mich war es in erster Line auch nicht das massgebende irgenwelche Ports zu sperren oder den Gastzugang zu beschränken. Für mich war eher massgebend, sehen zu können, was über den Gastzugang passiert.
Letztendlich würde ich, wenn ich in den Logs verdächtige Sachen sehe, den Gastzugang abschalten und den jenigen direkt ansprechen.
Wie in div. Thread's ja schon mehrfach beschrieben, bleibt die rechtliche Verantwortung ja eh bei mir als Anschlussinhaber.
Und wenn ich dem entgehen will, bleibt einem schliesslich nur, keinen an seinen Anschluss zu lassen. Alles andere ist für mich eine Balance aus Vertrauen und "Logging/Kontrolle".

 

[andilao]

auch über den TCP-Port 80

Das war mir noch geläufig. Mir geht es um die Gelegenheits-Downloader, die dann nicht mehr "aus Versehen" per Opera oder FDM einen .torrent laden können ohne etwas Konfigurationsarbeit. Da der Zugang meist nur kurzzeitig vergeben wird, setze ich da einfach auf das Abschreckungsmoment.

Eine DPI-Firewall bekommt man wohl nicht für die Fritzbox. ;-)