[Wien] DNS Einträge ich bin wenigstens in der map!

[Bernd Petrovitsch]

On Mit, 2007-12-12 at 02:13 +0100, Harald Geyer wrote:
> Markus Gschwendt <(spam-protected)>:
> > das wr brigens auch nicht schlecht fr die router, damit sie am netz
> > berhaupt teilnehman knnen. z.b. sollten beim aufbau von olsr-links
> > zertifikate von einem zentralen server berprft werden. damit htten
> > 'schwarzsurfer' ein problem nehm ich mal an.
> 
> Gibt bzw. gab es schon einmal einen Schwarzsurfer?
> Falls ja: Wurde dadurch der Betrieb des Funknetzes beeintrchtigt?
> 
> Ich sehe das Problem von (meist unabsichtlich) falsch konfigurierten
> devices - jeder kann sich einmal bei einer IP vertippen - die das
> routing beeintrchtigen ...

Ja, aber das läßt sich idR per Email beheben.

> Schlimmer noch: Seit wir die Broadcast Adresse auf 255.255.255.255
> gestellt haben, kann jeder auf einem OLSR device als IP 217.72.204.254
> einstellen und damit einmal eine Runde www.gmx.net spielen und die
> Passwrter von allen webmail usern im Funknetz stehlen ...

Gegen "Passwörter stehlen" kann man auf den Layers < 7 nichts machen
(außer abklemmen), weil es v.a. ein Problem des Users ist, einfach so
sein Passwort irgendwo reinzutippen, nur weil das WebInterface so das
von $BANK ausschaut. Das wird landläufig ja "Phishing" genannt.
"https" zu verwenden ist notwendig (und selbstverständlich), aber keine
hinreichende Lösung.
BTW ist das "Petname Addon" - http://petname.mozdev.org/ - da eine nette
kleine Hilfe.

> Hm, oder war das eh schon vorher mit HNA mglich?

Nicht daß ich's ausprobiert hätte, aber vermutlich ja.

Was aber einfacher geht und mehr bringt: Organisier' Dir eine
IDN-Domain, die optisch auf deinem Default-Windows so ähnlich wie die
gewünschte Zieldomain aussieht und Du kannst sofort weltweit damit
Username+Passwort phishen (und nicht nur im 0xFF-Netz).

> Aber mehr als all das Obige macht mir Sorgen bzw. erscheint mir viel
> wahrscheinlicher, dass jemand das Funknetz einfach nur sabotiert und
> z.B. das Routing gezielt strt. (AFAIK gab's so einen Fall im
> Weinviertel bereits)

*Sowas* auf dem tiefen Level zu verhindern ist extrem mühsam - es wird
aufwendig werden (sowohl initial und im Betrieb - so wie halt jede
Sache, die in die Richtung "Security" geht) und es wird immer noch ein
Restrisiko bleiben. Schon weil es auf unteren Levels nichts gibt, was
man nicht faken oder ändern könnte.

> Mit Zertifikaten (noch dazu auf einem zentralen Server berprft)
> bereiten wir die denial of service Attacke selber vor!

Wobei obiges "zentral" sowieso dem Geist eines Mesh-Netzes widerspricht
(wie war das noch mal? "Jeder ist sein eigener Mini-ISP" oder so
ähnlich). Wobei dann der (oder die) "zentrale Server" die logische
Angriffspunkte sind. Wobei man da erstmal die Security hinkriegen muß.
Vom organisatorischen Aufwand, sowas da und dort reinzukriegen und zu
deployen, den permanenten Aufwand, das am Leben zu erhalten ganz zu
schwiegen.
Und v.a. ist dann halt die Frage zu lösen, wie man die Validität eine
Zertifikats prüfen kann, wenn der zentrale Server gerade nicht
erreichbar ist (egal aus welchem Grund - z.B. könnte ja ein Knoten für 2
Tage offline sein, weil eine Antenne hin ist).
"Warten" kann mitunter länger dauern und ist damit keine akzeptable
Lösung.

> In einem freien (halbwegs offenen) Netz kann meiner Meinung nach
> die Reaktion nur sein, sichere services zu verwenden, nicht das

ACK.
Und genau deshalb ist Verschlüsselung (egal ob es im openvpn oder als
IPsec getarnt daherkommt) am Layer <= 4 überflüssig udn verbraucht nur
sinnlos Strom (und die Performance auf einem 200MHz LinkSys, wo manche
Tunnels enden, kann jeder selber schätzen .....).

> Netz (ab)zuschlieen. Auerdem und im Licht der jngsten
> Gesetzesnderungen, was den Datenschutz betrifft, bin ich
> persnlich auch eher fr weniger Kontrolle als fr mehr.

ACK.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services