[Berlin-wireless] sama web-interfaces

So Mär 11 08:22:28 CET 2007

Hi Marco,

so einen hartnaeckigen Fall hatte ich vor ein paar Monaten bei Bocki, Nur 
Bittorent + TOR. Ich hab' dann folgendes gemacht:

- Notebook gegriffen, Karte auf "taub" und erstemal durch die Gegend 
geschlichen um zu gucken wo genau der wohnt. Dabei ermittelt, das der Mensch 
bei Bocki im Haus wohnt, irgendwo unter ihm. Er braucht also gar kein OLSR 
zum Filesharen.

- Dann fuer die MAC-addr eine Redirect-Seite eingerichtet mit dem Inhalt "Du 
Ar*** - ich weiss wo du wohnst. Geh aus der Leitung".

- Dann ein kleines Script aufgesetzt um bei wechselnder MAC und IP trotzdem zu 
blocken. Bisschen brutal aber geht (fuer Bittorrent auch ueber Port 80):

#!/bin/sh

eval $(grep "dport=6881 src" /proc/net/ip_conntrack|
sed -e 's/\(.*\)src=.*/\1/;s/^.*src=\([0-9\.]\+\).*/IP_\1=\$(( \$IP_\1 + 
1 ));/;s/\./_/g')
for i in $(set | grep ^IP_|sed -e 's/=.*//');do
  eval "n=\$$i"
  if [ $n -gt 5 ];then
    ip=$(echo $i|sed -e 's/^IP_//;s/_/./g')
    arp="0$(arping -c 1 -I eth2 $ip|
sed -ne '/^Unicast/{s/^.*\[\([0-9a-f:]\+\).*/\1/;p}')"
    echo "Killing MAC: $arp"
    iptables -I FORWARD -s $ip -j DROP
    iptables -I FORWARD -d $ip -j DROP
    iptables -I FORWARD -m mac --mac-source $arp -j DROP
# Wir wollen nur Forward blocken, damit er nicht irgendeine
# anderen Router via OLSR bekommen kann. Input blocken ==
# OLSR sucht sich einen anderen weg.
#    iptables -I INPUT -m mac --mac-source $arp -j DROP
  fi
done

- Irgendwann kam dann eine "Sorry" Mail. Er hat dann seine Experimentierfreude 
woanders ausgelebt. War leider nicht zum aktiven Freifunken zu ueberreden.

Ich fuerchte, dass es immer wieder ein paar Einzelne gibt (Abteilung: Feige 
Sau will nicht ueber eigenen DSL filesharen), die machen uns dann punktuell 
platt. Dagegen gibts technisch nur bedingt Mittel - das laeuft dann auf 
Hausbesuche oder auf restriktive Handhabung der Inet-GWs hinaus...

// Sven-Ola

Am Freitag, 9. März 2007 22:49 schrieb Marco Tidow:
> On Fri, Mar.09. 20:09 +0100, offlinehorst wrote:
> > oder, warum sind:
> > [...]
> > - auf der SAMA keine web-IFs mehr öffentlich zu sehen?
>
> moinmoin @all
>
> vorab, die vier sama-nodes (104.131.25.10 .12 .14 .16) bestehen aus
> SE505v2, haben also nur 8MB RAM.
>
> (für Luet´ von außerhalb:)
> wohne einen hop daneben und kümmer mich deshalb um die Kisten inkl.
> Telefon-support von ca. einem Dutzend FF-Bekannten im Umkreis der Kirche.
>
>
> Seit letzten Herbst gibt es einen unfreundlichen Nachbarn, der zu allen
> vier routern direkten Funk-Kontakt hat, mit olsr & co vertraut ist
> (linux-Kiste, olsrd, kein ff-router), und sehr wahrscheinlich auch eine
> eigene DSL o.ä. für nicht-musik-file-sharing internet-Zugang nutzen kann.
> Offenbar um anonym an Musik zu gelangen, nutzte er(sie? bleibe jetzt
> einfach mal beim "er") FF zum sharing, rund um die Uhr.
>
> Versuche meinerseits, ihn per www-redirect auf eine info-Seite davon
> abzubringen, weil´s andere im Sama-Kiez massiv störte, irgendwie eine
> e-mail von ihm zu bekommen, scheiterten, weil er niemals über die
> Verbindung was anderes als das sharing machte.  Funktionieren konnte das,
> weil es inet-gateways ohne P2P-filter in der Umgebung der Kirche gab und
> gibt.  Auf den Siemens-Teilen ist dafür selbst kein Platz.  port-blocks
> unmöglich, weil sharing-tools auch gern tcp-80 (=www) nehmen.   Als 104er
> nutzte er sowohl geografisch-weitentfernt-vergebene wie auch
> nicht-vergebene.
>
> (routing-mäßig funktionierte dies, weil damals entweder ein gateway direkt
> neben der Kirche, oder aber der früher vorhandene Fernlink zum BoxPl. die
> einzigen funktionierenden und damit per olsr ausgewählten Wege <->
> Sama-Kirche darstellten, keiner weiter als 4 hops)
>
> Dann wurde es mir zu bunt und ich habe seine MAC manuell gesperrt.  Dieses
> Spiel setzte sich mit seinerseits manuell geänderten MACs fort (Feldstärke
> des Störers blieb gleich, deshalb der Schluß).
>
> Zusätzlich
> wurden die web-interfaces der Sama-router per script mit Abfragen
> überhäuft, also ein ganz gezielter DoS-Angriff, der auch wirkte. 
> memmory-overrun. Andere prozesse, cron, olsr, dropbear hingen sich deshalb
> ebenfalls auf, die Funktion der router wurde massiv eingeschränkt.
>
> Entweder derselbe oder sonst jemand nutzte zudem parallel
> vorhandene Lücken im web-interace aus, um gezielt files auf den
> routern zu manipulieren (dabei stellte er sich leider selbst ein Bein, weil
> er das vlan-tagging setup der router nicht kennt; immer wenn er
> /etc/local.fw löschte, sprach der jeweilige router nicht mehr mit seinen 3
> Kollegen per ethernet;  funkt-mäßig tun´s sie´s auch nicht, da auf
> unterschiedlichen ESSIDs/BSSIDs/channels  ;-) ).
> Also jemand, der die FF-firmware Interna kennt, was aber auch kein großes
> Ding ist.
>
> DESHALB sind dort die web-interfaces weg.
>
>
>
> Zuletzt im Januar liefen auch brute-force Einbruchsversuche über den ssh-
> daemon, verursachten wegen einer bekannten Macke im dropbear
> (halbbegonnener connect wird vom initiator nicht fortgesetzt)
> memory-overruns
> oder brachten den dropbear zum Abschmieren.  Seitdem wird auch der
> ssh-Zugang gefiltert, geht u.a. nur noch von bestimmten source-IP´s aus,
> die
> yokoy und ich kennen.
>
>
>
> Letzlich lassen sich auch so Info´s (LQ´s, Neighbours) zu den
> Sama-routern aus der Topologie-table jedes anderen nodes ablesen.
> (wenn´s von weiter weg nicht so flüssig läuft, tja, schade.)
>
>
> scannen: geht eben nicht remote.
>
>
> richtig scheiße ist das Fehlen der Kontakt-Seite.
>   Per redirekt auf eine fittere Maschine machbar, Zeitfrage.
> Wenn´s nicht deshalb auch wieder Gemoser und Verdächtigungen gibt :-(
> Oder evtl. dann auf den 5GHz-cube (im Sommer oder Herbst, 2007 ?)
>
>
>
> nvram-setup Details :
>   unterscheiden sich dort nicht von dem, was ich hier
> bereits lang und breit auf der Liste dargestellt habe:
>
>   b+g-mode, no-RTS, no-CTS-protecton, no frameburst, kleine frag : 384,
>   fixe bitrate 2Mbit + txpwr
>
>   channels:
>     sama-nord : 10
>     sama-ost  :  1
>     sama-süd  : 13
>     sama-west : 10    **** würde ich gern auch auf 1 ändern,
>                        Abstimmung (unter den Betroffenen!) vorausgesetzt
>
> ... ist nicht das FF-default-Dogma, stattdessen funktioniert es auch ohne
> private Richtfunk-Strecken mit 15dbi-Antennen, weil für b-mode Raten
> (also CCK,FSK,BPSK-Modulation) weniger SNR nötig ist.  Nach meinem
> Bild + den Äußerungen der Betroffenen nach ist jedenfalls
>
>  der Unterschied zwischen   "kein Netz"   oder   "Netz mit 100 KByte/s"
>
>  maßgebend größer als
>
>  der zwischen   "Netz mit 100 KByte/s"   und  "Netz mit 16 MByte/s"
>
> . <- Punkt
>
> Die alte Native hieße, 5..6 teure kByte/s in kurzen dial-up Zeitfenstern.
>
>
>
> ARP-preset (kann man sowieso nicht per web-if sehen):
>
> Alle bekannten MAC´s sind zudem permanent der jeweiligen 104er IP
> zugeordnet, spart die ARP-requests.  So kommt man auf 64bit-ping´s
> von typ. ~ 3ms / pro hop.  Mit dem 1. packet.
>
> Dann liegt es zumindest nicht mehr am dauernden re-negotiate auf layer2
> über bitrate, kann-der-andere-auch-framebursts? etc. ,  wenn die
> Antwortzeiten doch mal größer werden.  Hierfür zeigten sich bislang
> ausschließlich congestion seitens wlan auf Nachbar-Kanälen als
> Ursache.  Selbst dann bleibt der ping i.d.R. unter 30ms / hop, laufen
> hinreichend flüssig packets.
> (dachte, wir wollten mal streamen, multicasten usw. ?)
>
> Das entsprechende init-script ("S41ethers") zum ARP-preset hatte ich
> vor Monaten über die Liste gemailt.
>
>
> Für mich ist das Interesse der Leute im Sama-Kiez maßgebend, Netz zu
> haben, daß die router dort eben routen.
>
>
> schluß.  jetzt gibt´s gleich sahne-mucke aus "Saint-Petersburg",
> punk vom feinsten, der funktioniert immer.
>
> marco
>
>
>
> _______________________________________________
> Berlin mailing list
> Berlin at olsrexperiment.de
> https://www.olsrexperiment.de/cgi-bin/mailman/listinfo/berlin

_______________________________________________
Berlin mailing list
Berlin at olsrexperiment.de
https://www.olsrexperiment.de/cgi-bin/mailman/listinfo/berlin