[Berlin-wireless] sama web-interfaces

Fr Mär 9 22:49:34 CET 2007

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