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

[Bernd Petrovitsch]

On Mit, 2007-12-12 at 14:40 +0100, Markus Gschwendt wrote: 
> On Wed, 2007-12-12 at 10:14 +0100, Bernd Petrovitsch wrote:
> > > Gibt bzw. gab es schon einmal einen Schwarzsurfer?
> > > Falls ja: Wurde dadurch der Betrieb des Funknetzes beeintrchtigt?
> 
> ja, martin berichtet von einem fall und akku bestätigt das.
> mir gefällt das wort 'schwarzsurfer' eigentlich nicht, es kann ja jeder

Gibt es ein besseres? Ansonsten wird es beim schlechten bleiben müssen.

> mitmachen, nur funktioniert das halt nur unter einhaltung bestimmter
> regeln.
> 
> ...
> > > Mit Zertifikaten (noch dazu auf einem zentralen Server berprft)
> > > bereiten wir die denial of service Attacke selber vor!
> > 
> > Wobei obiges "zentral" 
> 
> mit 'zentral' hab ich nicht an einen einzelnen server gedacht. eher ein
> system, das man zentral verwalten kann.

Auch das ist "zentral" (und ob sowas auf einem Server oder mehreren oder
allen Knoten im Netz läuft, ist mbMn technisches Implementierungsdetail,
solange wir auf der Spezifikationsebene unterwegs sind).

BTW ist es dann aus mit "FunkFeuer ist ein Verbund/Kooperation von
Mini-ISPs" sondern das ist dann eher ein Franchise-Unternehmen, weil man
Selbständigkeit an eine zentrale Instanz abgibt.

> > 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).
> 
> ich werfe da mal ein paar fragen/ideen auf:
> wäre das über cacert-zertifikate möglich?

Detailfrage der Implementierung - ist im Moment irrelevant.

> wie könnte man sonst auf technischem weg ausschliessen dass jemand einen
> router (auch irrtümlich) ins netz hängt mit einer ip die ihm nicht
> gehört?

Gar nicht: Ich konfiguriere Deine IP-Adresse bei mir (vorsätzlich oder
irrtümlich - egal). Wie willst Du das verhindern können?

BTW *will* ich gar nicht irrtümlich verkonfigurierte Router
ausschließen: Wie soll sonst der arme Tropf dahinter die Chance haben,
etwas auszuprobieren oder ausreichend zu lernen, um es richtig zu
machen?
Und da kommen wir zum Kern des Problems: Wie ist "korrekt konfigurierter
Router" technisch vollständig definiert - und für alle Situationen?
Ohne Antwort auf die Frage, kann man schlecht entscheiden, ob eine
gegebener Router falsch oder richtig konfiguriert ist (unabhängig davon,
wie man das dann konkret implementiert).
Und jede Lösung, die in Richtung "Security" geht, braucht als notwendige
(aber nicht hinreichende) Voraussetzung, das alles definiert ist. Das
kann a priori oder im Laufe der Zeit passieren. Rein persönlich würde
ich "im Laufe der Zeit" nicht machen wollen, weil das Denk- und
Entscheidungsarbeit und -verantwortung von jetzt in die Zukunft
verschiebt (nenn' es "Salami-Taktik" oder "schrittweises Vorgehen" - es
ändert nichts dran, daß man frühzeitig gerne Detailentscheidungen fällt,
weil es einfach ist und spätere Entscheidungen vorwegnimmt.).
Und wieviel Aufwand schmeißt man weg, wenn man nach einiger Zeit mit
einem halbfertigen System erst draufkommt, daß das Konzept Müll ist und
man am besten zurück an den Start geht?

> könnte der router beim hochfahren die redeemer-db abfragen um sich ins
> netz einklinken zu dürfen?

Was ist, wenn der nicht erreichbar ist (for whatever reason)?
In das Konzept muß eine Lösung für das Problem rein.

> können nachbarknoten eine verifizierung durchführen um einen router
> mitmachen zu lassen.

Falls sie schon laufen, vielleicht. Man wird auch nicht umhinkommen,
diese Verifizierung periodisch neu zu machen.

BTW wenn wir schon Evildoers erkennen wollen: Wie weiß mein Knoten, daß
der Nachbarknoten vertrauenswürdig ist (und mich nicht frotzelt)?
In das Konzept muß eine Lösung für das Problem rein.

> wichtig ist dass das netz offen bleibt, aber wir müssen auch dafür
> sorgen das die sicherheit nicht zu kurz kommt.

BTW unterscheide ich 2 ziemlich verschiedene Sachen:
1) Irrtümlich Konfigfehler (weil vertippt, unwissend, Doku falsch, Doku
   falsch interpretiert, ....) erkennen und überleben können (zumindest
   das Netz muß das überleben).
2) Vorsätzlich verkonfigurierte Dinger wie "geborgte" IP-Adressen oder
   "Schwarzsurfer".

1) sollte ohne großartigen technischen Aufwand auskommen können, weil
man den Leuten ja sagen wird wollen, wo was falsch ist. Der Zustand wird
auch nur temporär sein. Daher das "erkennen und überleben".

2) zu verhindern ist technisch mbMn nicht möglich, weil man da ziemlich
weit unten (im OSI-Schichtenmodell) entscheiden muß, on das eine "guter"
oder "böser" ist. Insofern würd' ich das aus dem Anforderungskatalog
streichen.
Und das schlechteste ist - wie bei allen Security-Systemen - eine halbe
Lösung, die (schon konzeptionell) nicht gscheit funktioniert und deshalb
wenig bringt - außer jede Menge Aufwand und Probleme.

Versteh' mich nicht falsch, ich hab nichts gegen eine Lösung. Aber die
soll konzeptionell stehen und funktionieren können bevor die erste Tool-
o.ä. Detailentscheidung getroffen wird.
MbMn ist da *locker* eine Diplomarbeit/Masterarbeit drin - allein an der
Analyse einiger weniger Möglichkeiten bzw. Varianten und deren
Auswirkungen und Implikationen auf das Mesh-Netz.

> spamfilter sind ja auch state of the art, keiner schreibt an einen
> spammer zurück: 'bitte, bitte lass das'

Schön wärs - ich befürchte, du überschätzt Otto Normaluser;-)

Dazu wird die große Masse von Spammails von 2 Gruppen von Leuten in die
Welt gesetzt:
- Spammer: Die machen das vorsätzlich und sind deshalb nicht belehrbar.
- Schlechte Mailadmins (gerne auch bei größeren ISPs), die
  "Backscatter" (das sind Antwortmails auf die gefakte From:-Adresse in
  Spammails, meist wegen "Account gibt es nicht") verursachen.
  Wenn sie gute Admins wären, würden sie das nicht tun. Sind also auch
  nicht wirklich belehrbar.
Und wie geht man bei Spamfiltern mit False Positives und False Negatives
um?
Das kann man technisch auch nicht entscheiden (sonst würde es gemacht
werden und es gäbe kein Spamproblem). Man kann ja technisch noch nicht
mal eindeutig entscheiden, ob eine Mail Spam ist oder nicht - das kann
erst der User (händisch oder mit Tools, egal), weil was im Marketing ein
"Newsletter" ist, ist für den Techniker u.U. "Spam".

Und beim IP-Routing sind wir ein paar Layer tiefer unterwegs .....

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