[Jogges]

Hi

Ich würde gerne auf meine Wep-Verschlüsselung im WLan verzichten. Hätte dann nur noch Schutz vor fremden Zugriff durch eine Mac-Filtertabelle des Routers (T-Sinus 154 Basic). Ich persönlich halte das für ausreichend, wollte jedoch mal noch andere Meinungen einhohlen. Greez
Jogges

[Anderländer]

ok dann schalt die verschlüsselung aus gib mirn notebook mit wlan und ich grig alle deien passwörter raus und persönliche daten.

Gruß Flo

[Jogges]

Jetzt mal angenommen das jemand in meinem Kaff wirklich versuchen würde sich in mein Netzwerk einzuklinken müsste er sich schon bei mir auf die Haustreppe setzen, oder mein Nachbar (der das garantiert nicht macht) sein. Auserdem sollte ihn die Filtertabelle doch auch noch etwas hinder, oder ist die wirklich so leicht zu umgehen.

Greez

[LoD14]

richtfunk... uns es reicht mit ner pringels dose und notebook im auto vor deinem haus zu parken... feritg... man hat zugriff auf dein wlan...

[Jogges]

Hmmm.......

Ok, is ja gut......
ABer was is jetzt mit dem Mac Filter? Taugt der denn Garnix?

[LoD14]

sagen wirs so... solange mal nur mal kurz bei dir online will und dann auf nen macfilter stößt, sucht man vielleicht lieber ein wlan ohne. aber wenn man an deine daten will, ist ein mac filter kein hinterniss. man kann seine Mac fälschen/maskieren und schon ist man drinne... aber für jemand der nur mal kurz auf diene kosten seine email holen will ist das eigentlich zuviel action...

[PaxTrax]

ACL (=MAC Zugangskontrolle) ist 0 (in Worten "Null") Schutz. Ein Linuxbefehl ist nötig, um diesen Schutz zu umgehen. Auch WEP ist innerhalb von 10-30 Minuten kompromittiert. Nutz WPA oder besser, um Dein WLAN zu schützen.

[LoD14]

Zitat (PaxTrax: 25.09.2004, 21:03)

ACL (=MAC Zugangskontrolle) ist 0 (in Worten "Null") Schutz. Ein Linuxbefehl ist nötig, um diesen Schutz zu umgehen. Auch WEP ist innerhalb von 10-30 Minuten kompromittiert. Nutz WPA oder besser, um Dein WLAN zu schützen.

an nem wep key kannste dich doof und dämlich rechnen wenn kein traffik in dem lan ist... bei keinem traffik dauert das jahre. wenn natürlich immer jede menge daten unterwegs sind, dauerts nicht lange.

wpa ist das sehr sicher, aber wird soweit cih weis erst von den 802.11g routern unterstützt...


theoretisch könnte man doch das inet an nen rechner legen, wo ein novell netware server drauf liegt. dann müsste man zuerst da rein kommen um an die daten und das inet zu kommen...

Dieser Beitrag wurde von LoD14 bearbeitet: 25. September 2004 - 20:11

[PaxTrax]

Zitat (LoD14: 25.09.2004, 21:09)

an nem wep key kannste dich doof und dämlich rechnen wenn kein traffik in dem lan ist... bei keinem traffik dauert das jahre. wenn natürlich immer jede menge daten unterwegs sind, dauerts nicht lange.

wpa ist das sehr sicher, aber wird soweit cih weis erst von den 802.11g routern unterstützt...


theoretisch könnte man doch das inet an nen rechner legen, wo ein novell netware server drauf liegt. dann müsste man zuerst da rein kommen um an die daten und das inet zu kommen...

Denk doch mal einen Schritt weiter Ich kann doch als Angreifer genauso Traffic verursachen (Replay Attacke) und so an die IV's kommen. Schonmal daran gedacht?

PS: 802.11g hat nichts mit WPA zutun

Dieser Beitrag wurde von PaxTrax bearbeitet: 25. September 2004 - 20:14

[LoD14]

im prinziep muss man bei der wep verschlüsselung doch datenpackete sammeln. und da wep von einem definierten startkey aus startet und auf dem basierend neue keys produziert und ein key sich alle x datenpackte wiederholt kann man ja den key an hand der 2 gleichen keys berechnen. aber wenn ich nciht in dem lan bin dann kann ich doch keinen traffik verursachen, der mit dem key codiert ist, oder?

sry, bin nciht mehr auf dem aktuellen stand in diesen sachen, hab mich damit vor ner ewigkeit mal beschäftigt, aber fast alles wieder vergessen...

[PaxTrax]

Zitat (LoD14: 25.09.2004, 21:16)

im prinziep muss man bei der wep verschlüsselung doch datenpackete sammeln. und da wep von einem definierten startkey aus startet und auf dem basierend neue keys produziert und ein key sich alle x datenpackte wiederholt kann man ja den key an hand der 2 gleichen keys berechnen. aber wenn ich nciht in dem lan bin dann kann ich doch keinen traffik verursachen, der mit dem key codiert ist, oder?

sry, bin nciht mehr auf dem aktuellen stand in diesen sachen, hab mich damit vor ner ewigkeit mal beschäftigt, aber fast alles wieder vergessen...

Du verwechselst da ein paar Dinge. Der Schlüssel ist ja die ganze Zeit der Gleiche. Der Schlüsselstrom ist aber durch den IV+WEP Key im PRNG ständig variable (aber halt nicht genug -> 16 Bit Permutation). Es gibt ja verschiedene Angriffe auf die Implementation ...... egal, du kannst im Netzwerk durchaus Traffic erzeugen.

Beispiel: ARP Request <-> ARP Response. ARP ist notwendig in jedem Netzwerk. Ständig werden ARP Requests und ARP Response im Netzwerk versendet. Diese besitzen eine markante Paketgröße, welche wir uns zu Nutze machen. Selbst verschlüsselt können wir also sagen, dass es sich wahrscheinlich um ein ARP Request handelt. Dieses schicken wir so wie es ist zurück ins WLAN. Was wird passieren? Auf das vermeidliche ARP Requests bekommen wir ein ARP Response mit neuem IV für unsere Kryptoanalyse. Das können beliebig oft machen (immer mit dem einen abgefangenen Frame) und somit soviel Traffic wie nötig erzeugen. Klappt wunderbar, oder hast du einen ARP Watcher/IDS System @home?

[LoD14]

danke so drinne in der materie bin ich leider nicht wie du, aber jetzt weis ich wieder mehr

[Rika]

Nun ja, aber der ARP-Traffic ist ja auch verschlüsselt, WEP arbeitet ja auf Layer 2. Mal ganz davin abgesehen, mit WLAN-spezifischen Anfragen, z.B. Beacon Requests o.ä. provozierst du sehr wohl Traffic vom Router.
Und dann heißt es entweder: 2-8 Stunden capturen und wenige Minuten rechnen oder wenige Sekunden capturen und einige Tage lang rechnen.

WPA ist übrigens auch nicht sicher, bei vollem Traffic brauchst du nur ca. eine halbe Stunde lang das Netzwerk abwechselnd zu flooden und beim TKIP-Rekeying den Traffic mitlesen - dann noch 10-16 Stunden lang rechnen und schon ist man auch drin.

Bis 802.11i sich durchsetzt und vor allem richtig implementiert wird (WPA ist eine Untermenge von 802.11i, die für eine richtige Implementierung nicht ausreicht), kann man nur auf Linux-Router+OpenVPN oder IPSec+IPSec-fähigen Router (der IPSec _nicht nur durchschleift, sondern wirklich als Endpunkt dient_ = teuer) setzen. Oder man wechselst täglich den WEP-Key.

@PaxTrax: Ich glaube nicht daß du RC4 und dessen Implentierungsschwächen verstanden hast. Es geht um eine spezielle Klasse von IVs (B + 3, 255, x), Kollisionen im PRNG (40 Bit + Geburtstagsparadoxon = 1 Kollision in 2^20 Paketen), Known Plaintext (IP bzw. ARP-Header, SNAP Primary Header) und CRC32 als Checksumme (kryptographisch unsicher).

Dieser Beitrag wurde von Rika bearbeitet: 26. September 2004 - 02:05

[Jogges]

Haltet mich für naiv, aber ich glaub einfach nicht das hier in meinem Kaff jemand schwach geschützte WLan Netzte sucht um an meine Persönliche Daten zu kommen oder sonst irgendnen Käs zu machen der dann auf mich zurück fällt.Da ist die Gefahr die von meinem Dad ausgeht, welcher sich durchaus schon Dialer runtergeladen hat, größer.
Mein Router unterstützt zwar WPA, aber der Client (mein Dad, ich nutz Kabel) hat nen 300 MHZ mit 98Se. ---->WPA nix funz.
Trotzdem Danke an alle. Hab genug Infos

[PaxTrax]

Zitat (Rika: 26.09.2004, 02:58)

Nun ja, aber der ARP-Traffic ist ja auch verschlüsselt, WEP arbeitet ja auf Layer 2. Mal ganz davin abgesehen, mit WLAN-spezifischen Anfragen, z.B. Beacon Requests o.ä. provozierst du sehr wohl Traffic vom Router.
Und dann heißt es entweder: 2-8 Stunden capturen und wenige Minuten rechnen oder wenige Sekunden capturen und einige Tage lang rechnen.

WPA ist übrigens auch nicht sicher, bei vollem Traffic brauchst du nur ca. eine halbe Stunde lang das Netzwerk abwechselnd zu flooden und beim TKIP-Rekeying den Traffic mitlesen - dann noch 10-16 Stunden lang rechnen und schon ist man auch drin.

Bis 802.11i sich durchsetzt und vor allem richtig implementiert wird (WPA ist eine Untermenge von 802.11i, die für eine richtige Implementierung nicht ausreicht), kann man nur auf Linux-Router+OpenVPN oder IPSec+IPSec-fähigen Router (der IPSec _nicht nur durchschleift, sondern wirklich als Endpunkt dient_ = teuer) setzen. Oder man wechselst täglich den WEP-Key.

@PaxTrax: Ich glaube nicht daß du RC4 und dessen Implentierungsschwächen verstanden hast. Es geht um eine spezielle Klasse von IVs (B + 3, 255, x), Kollisionen im PRNG (40 Bit + Geburtstagsparadoxon = 1 Kollision in 2^20 Paketen), Known Plaintext (IP bzw. ARP-Header, SNAP Primary Header) und CRC32 als Checksumme (kryptographisch unsicher).

Also...........

Zitat

Nun ja, aber der ARP-Traffic ist ja auch verschlüsselt, WEP arbeitet ja auf Layer 2. Mal ganz davin abgesehen, mit WLAN-spezifischen Anfragen, z.B. Beacon Requests o.ä. provozierst du sehr wohl Traffic vom Router.
Und dann heißt es entweder: 2-8 Stunden capturen und wenige Minuten rechnen oder wenige Sekunden capturen und einige Tage lang rechnen.

Natürlich ist der ARP-Traffic verschlüsselt, aber das ist ja auch nicht das Thema. Es gab schon 2001 Proof-of-Concept Scripte (ala reject.c), die die markante Paketgröße von ARP sich zu nutze machen (hab ich aber auch schon oben geschrieben). Das bedeutet du hast den verschlüsselten Datenstrom, kannst aber die ARP Request erraten. Ein wiedereinschleussen diesen Paketes gibt schliesslich Aufschluss darüber, ob es einen war oder nicht. Falls ja -> "WLAN zumüllen". Was willst du mit Beacon Requests? Da diese vollständig unverschlüsselt sind, bekommst du auch keine weak IV's. Dein Vorschlag bringt gar nichts...... Auch dauert das sammeln der Informationen keine 2-8 Stunden, da wie du selber schon später schreibst, das Geburtstagsparadoxon dafür sorgt, dass sich innerhalb von ein paar Sekunden/Minuten die ersten IVs wiederholen. Genug Traffic hast du bereits nach 30-60 Minuten gesammelt (802.11b !).

Zitat

WPA ist übrigens auch nicht sicher, bei vollem Traffic brauchst du nur ca. eine halbe Stunde lang das Netzwerk abwechselnd zu flooden und beim TKIP-Rekeying den Traffic mitlesen - dann noch 10-16 Stunden lang rechnen und schon ist man auch drin.

Wo bitte hast du diese Information her? Nein ehrlich - interessiert mich. Das Rekeying geschieht unabhängig vom verursachten Traffic - z.b. alle 5 Minuten. Der TK ändert sich sich also ständig. Selbst wenn du nach 16 Stunden den alten TK hast, nützt Dir das nicht die Bohne, da er ja schon längst veraltet ist. Wie gesagt.....gib mir mal einen Quelle dafür, ich halte das für völligen Unfug.

Zitat

Bis 802.11i sich durchsetzt und vor allem richtig implementiert wird (WPA ist eine Untermenge von 802.11i, die für eine richtige Implementierung nicht ausreicht), kann man nur auf Linux-Router+OpenVPN oder IPSec+IPSec-fähigen Router (der IPSec _nicht nur durchschleift, sondern wirklich als Endpunkt dient_ = teuer) setzen. Oder man wechselst täglich den WEP-Key.

WPA und richtige Implementation? WPA versucht die WEP Fehler auf dessen RC4 Basis auszumerzen. 802.11i nutzt AES (CCMP). Du vergleichst teilweise Äpfel mit Birnen. WPA hat noch Schwächen im MIC, aber aufgrund der fehlenden Leistungsfähigkeit der APs ist in WPA ein guter Kompromiss gefunden worden, die alte Technik zu schützen.

Zitat

@PaxTrax: Ich glaube nicht daß du RC4 und dessen Implentierungsschwächen verstanden hast. Es geht um eine spezielle Klasse von IVs (B + 3, 255, x), Kollisionen im PRNG (40 Bit + Geburtstagsparadoxon = 1 Kollision in 2^20 Paketen), Known Plaintext (IP bzw. ARP-Header, SNAP Primary Header) und CRC32 als Checksumme (kryptographisch unsicher).

Glaube mir, das hab ich sehr wohl. Nur bin ich hier mit Absicht auf keine Details eingangen. Übrigens. Es gibt nicht nur die weaks IVs. dachb0den labs beschreibt eine weitere Abhängigkeit der WEP (Teil)Schlüssel untereinander. Aber du scheinst nicht so völlig fest in der Materie zu sein. Das Geburtstagsparadoxon hat nichts mit den 40 Bit bzw. 104 Bit des WEP Schlüssels zu tun, sondern mit den 16 Bit des IVs. Ich kann Dir das gerne vorrechnen...... Naja, known Plaintext IP und SNAP zusammenzuhauen würde ich nicht. SNAP bezieht sich auf das Überprüfungen vom richtigen Schlüssel bei wepattack (siehe Diplomarbeit der beiden Erfinder). Und eine Plaintext IP Konstellation bezieht sich auf das Brechen des Schlüsselstroms bei gleichem IV.

gruß,
PaxTrax