WLAN ZRH und anderswo - Datensicherheit - Vorsicht!

ANZEIGE

kingair9

Megaposter
18.03.2009
22.381
763
Unter TABUM und in BNJ
ANZEIGE
Wir haben von der Firma aus etwas Geld in die Hand genommen und haben unsere bisherigen VPNs durch ein "Tunnelprogramm" nach neuestem Standard ersetzt und probeweise bei 3 leitenden Angestellten installiert. Dieses Programm ist für uns als user klasse, kompletter Zugriff auf alles incl. Server und bis hin zur Auftragsverarbeitung und Datenarchiv. Der Einzige, bei dem es Probleme machte, war ich - in ZRH...

Das Programm baut die sichere Verbindung auf, alles sieht normal aus aber dann hängt sich alles auf.

Hatten die Firma heute hier und berichteten das Problem am Flughafen, aber wohlgemerkt OHNE die Worte "Schweiz" oder "Zürich" in den Mund zu nehmen. Kommentar: "Das passiert ihnen unter anderem in Zürich, oder?"

:eek: auf unserer Seite...

Es ist in Kreisen von Sicherheitsprogrammen und Verschlüsselungen bekannt, daß es u.a. in ZRH (aber auch an einigen spanischen Airports und auch anderen, die explizit aber nicht genannt wurden) besonders massive Überwachungen des verschlüsselten Emailverkehrs durch "Sicherheitsorgane" gibt. Hier reden wir über Schlapphüte und nicht in grüner Uniform.

Diese brechen die sicheren Kanäle auf, lesen die Daten heraus und "reparieren" die sicheren Kanäle danach wieder. VPN-Programme sind nach deren Aussage nicht "sophisticated genug" um das zu erkennen, das Programm und der user denkt, alles ist okay. Nur Programme neuester Machart (und das sind VPNs im allgemeinen nicht) erkennen den Einbruch und schalten sich ab.

Also in ZRH besondere Vorsicht!
 

ckruetze

Erfahrenes Mitglied
09.07.2009
638
0
EDXK
Ich kenne durchaus die Risiken von VPNs, unsicheren Passwörtern usw. Aber wie die das in Echtzeit schaffen wollen meine VPN Zertifikate zu öffnen und dann sowohl mir als auch den Servern auf der Gegenstelle das nicht auffallen sollte wundert mich doch etwas.

Kannst du irgendetwas zu der von euch eingesetzten VPN Technik sagen? Muß weder ein Hersteller noch wie gut gesichert ihr die habt sein. Einfach nur die Technik wäre interessant. Gibt ja einiges OpenVPN, SSL VPNs, IPSec, ... und wenn einige davon nicht so gut gehen dann wäre das ganz gut zu wissen.

Ich setze fast nur OpenVPN ein und hatte damit in Zürich noch nie Probleme. Alles funktioniert und war auch sicher!


Übrigens bringt das sicherste VPN nichts wenn man mitten in der Lounge sitzt und von hinten jeder aufs Laptop schauen kann.
 

kingair9

Megaposter
18.03.2009
22.381
763
Unter TABUM und in BNJ
Ich setze fast nur OpenVPN ein und hatte damit in Zürich noch nie Probleme. Alles funktioniert und war auch sicher!

Genau das ist nach der Aussage der Herren heute eben NICHT sicher. Du merkst es nur nicht, daß es nicht sicher ist... Ich habe vorher einen IPSEC VPN genutzt und da hieß es heute nur "Kinderspiel". :censored:

Was wir jetzt benutzen sei auch nicht "unknackbar" aber nach Aussage des Herstellers würde man es wenigstens merken, wenn da was nicht stimmt. Frag mich bitte nicht die Details, ich bin KEIN IT-ler, nur user.
 

SleepOverGreenland

Megaposter
09.03.2009
20.442
8.726
FRA/QKL
Das Programm baut die sichere Verbindung auf, alles sieht normal aus aber dann hängt sich alles auf.
Das ist aber ein relativ typisches Verhalten auch in vielen vor allem größeren Firmennetzwerken und hat mit unterdrückten Paketen von Firewalls zu tun. Abhilfe schafft hier eigentlich immer OpenVPN, eingepackt in das HTTPS Protokoll. Ist zwar etwas langsamer, als herkömmliches VPN, aber dafür funktioniert es immer - und das ganze auch noch kostenfrei.

Hatten die Firma heute hier und berichteten das Problem am Flughafen, aber wohlgemerkt OHNE die Worte "Schweiz" oder "Zürich" in den Mund zu nehmen. Kommentar: "Das passiert ihnen unter anderem in Zürich, oder?"
Vieleicht einfach, weil Zuerich ein paar grundlegende Maßnahmen für Netzsicherheit implementiert hat während andere WLANs Scheuentoroffen sind?
 

rofra

Erfahrenes Mitglied
21.04.2009
3.049
0
LCY
Diese brechen die sicheren Kanäle auf, lesen die Daten heraus und "reparieren" die sicheren Kanäle danach wieder. VPN-Programme sind nach deren Aussage nicht "sophisticated genug" um das zu erkennen, das Programm und der user denkt, alles ist okay. Nur Programme neuester Machart (und das sind VPNs im allgemeinen nicht) erkennen den Einbruch und schalten sich ab.
Das ist so nicht möglich. Man kann ein vernünftiges VPN nicht einfach in Echtzeit entschlüsseln.

Ist es dir evtl. möglich genauere (technische) Details zu bekommen, was die Firma da genau meint?
 

SleepOverGreenland

Megaposter
09.03.2009
20.442
8.726
FRA/QKL
Habe nun nochmals den Eingangspost gelesen.

Nur Programme neuester Machart (und das sind VPNs im allgemeinen nicht) erkennen den Einbruch und schalten sich ab.

Sorry, aber alleine diese Aussage passt schon nicht zu der vorherigen finde ich:

Das Programm baut die sichere Verbindung auf, alles sieht normal aus aber dann hängt sich alles auf.

Wenn es sich erkennbar abschaltet könnte es den "Einbruch" ja noch Anwenderfreundlich melden. Würde ich von einem tollen Program neuester Machart zumindest erwarten.

Wenn sich das Programm neuester Machart aber aufhängt und das ganze wirklich an der Kommunikation liegt, dann tippe ich eher auf eine unterdrückte IP-Antwort ohne sauberes Timeout Verhalten. Und das ist ein typisches Verhalten für geblockte Pakete durch eine Firewall.

Schon rein aus Interesse würden mich mehr technische Infos - so diese nicht Firmengeheimnis sind - auch sehr interessieren.
 

peter42

Moderator
Teammitglied
09.03.2009
13.193
1.010
Wir haben von der Firma aus etwas Geld in die Hand genommen und haben unsere bisherigen VPNs durch ein "Tunnelprogramm" nach neuestem Standard ersetzt und probeweise bei 3 leitenden Angestellten installiert. Dieses Programm ist für uns als user klasse, kompletter Zugriff auf alles incl. Server und bis hin zur Auftragsverarbeitung und Datenarchiv. Der Einzige, bei dem es Probleme machte, war ich - in ZRH...

Das Programm baut die sichere Verbindung auf, alles sieht normal aus aber dann hängt sich alles auf.

Hatten die Firma heute hier und berichteten das Problem am Flughafen, aber wohlgemerkt OHNE die Worte "Schweiz" oder "Zürich" in den Mund zu nehmen. Kommentar: "Das passiert ihnen unter anderem in Zürich, oder?"

:eek: auf unserer Seite...

Es ist in Kreisen von Sicherheitsprogrammen und Verschlüsselungen bekannt, daß es u.a. in ZRH (aber auch an einigen spanischen Airports und auch anderen, die explizit aber nicht genannt wurden) besonders massive Überwachungen des verschlüsselten Emailverkehrs durch "Sicherheitsorgane" gibt. Hier reden wir über Schlapphüte und nicht in grüner Uniform.

Diese brechen die sicheren Kanäle auf, lesen die Daten heraus und "reparieren" die sicheren Kanäle danach wieder. VPN-Programme sind nach deren Aussage nicht "sophisticated genug" um das zu erkennen, das Programm und der user denkt, alles ist okay. Nur Programme neuester Machart (und das sind VPNs im allgemeinen nicht) erkennen den Einbruch und schalten sich ab.

Also in ZRH besondere Vorsicht!


Man-in-the-middle bei zertifikatsgestützen IPSEC halte ich in realtime für ausgesclossen.
 

ckruetze

Erfahrenes Mitglied
09.07.2009
638
0
EDXK
Man-in-the-middle bei zertifikatsgestützen IPSEC halte ich in realtime für ausgesclossen.
Auch bei zertifikatgeschützten OpenVPN Verbindungen.


Was sein könnte und was die Firma vielleicht auch meint:

1. Benutzer baut eine VPN Verbindung auf
2. Das VPN Programm stellt den default gateway auf das remote Netz und alles wird durchs VPN geschickt, auch Anfrangen google.com usw.
3. Benutzer surft im Internet/ Intranet usw.
4. Aufgrund von oben beschriebenen Problemen wird die Verbindung unterbrochen.
5. Der Benutzer (nur User, nicht ITler) merkt es nicht
6. Der Benutzer surft jetzt nicht mehr hinter dem sicheren Firmennetz
7. Anfragen an google.com könnten jetzt mitgelesen werden.


Wobei mir das doch recht Theoretisch erscheint. Ich vermute eher das die Firma einfach nur ihr VPN Produkt verkauft hat. Und da billiger als OpenVPN (kostenlos) nicht geht, muß es halt besser sein bzw. OpenVPN schlechter sein.


Ich werde jedenfalls weiterhin mit OpenVPN auch in Zürich surfen.
 

krypta

Erfahrenes Mitglied
23.05.2009
3.493
2
@ all

Auch wenn ich nur die Hälfte kapiere - 1000 Dank für die nützlichen Hinweise (y)
 

airoli

Erfahrenes Mitglied
09.03.2009
398
1
ZRH / YUL
...was mich zu einer Anschlussfrage bringt:

Kennt jemand ein Tool ähnlich VPN, welches den Datenverkehr über öffentliche ungesicherte WLANS (typischerweise an Flughäfen) verschlüsselt? Wenn ich mit meinem Arbeits-Laptop unterwegs bin, wähle ich mich über offene WLANs immer zuerst in mein Firmen-VPN ein, ehe ich irgendwelche Passwörter etc. übers Netz schicke.

Aber auf meinem privaten Laptop habe ich kein Firmen-VPN installiert.
 

togo001

Erfahrenes Mitglied
01.08.2009
491
3
Shenzhen
.....
Was wir jetzt benutzen sei auch nicht "unknackbar" aber nach Aussage des Herstellers würde man es wenigstens merken, wenn da was nicht stimmt. Frag mich bitte nicht die Details, ich bin KEIN IT-ler, nur user.

Interessantes Thema, gerade weil sich in diesem Bereich viele Anbieter bewegen, die mit Halb- und Viertelwissen arbeiten und argumentieren. Es gibt genügend Aussagen, dass man ein VPN in Echtzeit entschlüsseln kann. Gesehen habe ich das noch nicht, auch wenn es theoretische und praktische Ansätze dafür gibt. Dazu gibt es gerade an einem Flughafen hohen Traffic, d.h. es gibt ziemlich viel zum Entschlüsseln :).

Technisch würde es mich auch interessieren, wie Ihr das macht - solange wir nicht Eure Firmeninternas berühren.

Ich tippe auch eher auf ein fehlerhaftes Timeout-Verhalten, denn auf einen grossangelegten erfolgreichen Lauschangriff.

BTW: Schon mal in China getestet? :D
 
E

El_Duderito

Guest
Ich vermute einfach mal, dass das 'Aufhaengen der Verbindung in ZRH' eher ein Problem der Firewalls ist.
Normalerweise bekommt man als Endkunden in WLANs etc nur eine sog. RFC1918 IP-Adresse (192.168.x.x, 172.16.x.x, 10.x.x.x) anstatt einer global erreichbaren. Entsprechend muss im Netz zwischen Endkunden und Internet ein Geraet sein, was sog. Network Address Translation (NAT) macht, d.h. von internen auf (normalerweise eine) externe IP-Adresse uebersetzt. Damit das ganze funktioniert muss das NAT-Geraet den Status von potentiell tausenden parallelen Verbindungen speichern. Entsprechend geht so einem Ding auch mal der Speicher aus und es loescht Status-Eintraege. Als Endkunde merkt man das normalerweise dadurch, dass keine weiteren Daten durchgelassen werden -> 'Aufhaengen der Verbindung'.
Ich halte das weniger fuer einen Angriff als fuer 'proaktives Verbindungsmanagement' durch die WLAN-Betreiber in ZRH.

Vielleicht schneidet jemand in ZRH mal seinen eigenen Datenverkehr mit und guckt was genau passiert :)
 

aerodynamik

vormals xanth
14.04.2009
522
2
MUC
[...]
7. Anfragen an google.com könnten jetzt mitgelesen werden.
Was bei "uns" damit abgesichert wird, dass ein automatischer Proxy, der nur mit bestehender VPN Verbindung erreicht werden kann, eingetragen ist. Browser frägt dann immer zuerst den Proxy, der nicht mehr da ist: keine Antwort von google.com

/ niko
 

ANK660

Erfahrenes Mitglied
01.09.2009
3.603
102
Was bei "uns" damit abgesichert wird, dass ein automatischer Proxy, der nur mit bestehender VPN Verbindung erreicht werden kann, eingetragen ist. Browser frägt dann immer zuerst den Proxy, der nicht mehr da ist: keine Antwort von google.com

/ niko

Ja das ist dann aber nur der Datenverkehr über den Webbrowser. Internet ist nicht nur WWW.
 

ANK660

Erfahrenes Mitglied
01.09.2009
3.603
102
Ich vermute einfach mal, dass das 'Aufhaengen der Verbindung in ZRH' eher ein Problem der Firewalls ist.

So ist es auch. Es ist egal ob ich in ZRH per VPN oder "Offen" unterwegs bin, die Verbindung hängt sich sicherlich mindestens einmal pro 30 Minuten weg. Dazu kommt dort auch die extrem schwankende Verfügbarkeit, in der Lounge im Raucherbereich ist es besonders schlimm.
Ein bischen Paranoia was die Überwachung angeht ist sicher gut, aber gleich solche Dinger raushauen finde ich arg übertrieben. Vor allem ein zertifikatsbasiertes VPN in Echtzeit zu knacken ist mit den üblichen Maschinen nicht drin, dazu braucht es einiges an Rechenaufwand und den wird auch Sunrise oder die Schweizer Schlapphut-Fraktion nicht für jeden 0815-Nutzer in ZRH betreiben.
Es gibt zwar Proxys die eine Man in the Middle Strategie verfolgen (Bluecoat z.B.) aber da braucht es aktive Mithilfe des Enduser der muss nämlich das Zertifikat der Bluecoat akzeptieren. Sonst schmeisst jeder ordentlich konfigurierte (standard) Webbrowser einen Alarm.
 

peter42

Moderator
Teammitglied
09.03.2009
13.193
1.010
...was mich zu einer Anschlussfrage bringt:

Kennt jemand ein Tool ähnlich VPN, welches den Datenverkehr über öffentliche ungesicherte WLANS (typischerweise an Flughäfen) verschlüsselt? Wenn ich mit meinem Arbeits-Laptop unterwegs bin, wähle ich mich über offene WLANs immer zuerst in mein Firmen-VPN ein, ehe ich irgendwelche Passwörter etc. übers Netz schicke.

Aber auf meinem privaten Laptop habe ich kein Firmen-VPN installiert.

Der Tunnel muss ja irgendwo enden, daher brauchst Du irgendwo einen Server oder einen VPN-Provider.

Wir setzen IPSec mit AES und Zertifikaten ein. Splittunnel ist gesperrt, d.h. der komplette Traffic läuft über VPN.


Die Connection-/NAT-Tables einer vernünftigen Firewall können recht viele Verbindungen speichern, anders sieht es natürlich aus, wenn das GW nur ein einfacher WLAN-Router ist.
 

ckruetze

Erfahrenes Mitglied
09.07.2009
638
0
EDXK
So ist es auch. Es ist egal ob ich in ZRH per VPN oder "Offen" unterwegs bin, die Verbindung hängt sich sicherlich mindestens einmal pro 30 Minuten weg.

Bei mir immer dann wenn der WLAN Gutschein abgelaufen ist. Dann passiert es des Öfteren das ich mein Laptop neu starten muß bzw. WLAN ausschalten, ca. eine Minute warten und dann WLAN wieder einschalten.
 

hch

Erfahrenes Mitglied
25.05.2009
1.679
505
INN
Der Tunnel muss ja irgendwo enden, daher brauchst Du irgendwo einen Server oder einen VPN-Provider.

Wir setzen IPSec mit AES und Zertifikaten ein. Splittunnel ist gesperrt, d.h. der komplette Traffic läuft über VPN.

Und wie willst du das sperren? Jeder halbwegs intelligente User kann das auf dem Client umgehen.
 

hch

Erfahrenes Mitglied
25.05.2009
1.679
505
INN
Mit dem passenden VPN-Client wirst Du Probleme haben - immer dran denken: Enduser haben keine Adminrechte auf ihren PCs.

Jeder der physikalischen zugang hat hat Admin-Rechte :) Ich muss nur die API patchen die der VPN client fuer seine routing-table aenderungen Benutzt und schon hab ich wieder die Kontrolle. Dieses jeden Traffic uebers VPN routen ist uebrigens komplett daemlich und brings rein garnichts (ausser viel sinnlosen Ping-Pong Traffic).
 
  • Like
Reaktionen: SmilingBoy

ckruetze

Erfahrenes Mitglied
09.07.2009
638
0
EDXK
Jeder der physikalischen zugang hat hat Admin-Rechte :) Ich muss nur die API patchen die der VPN client fuer seine routing-table aenderungen Benutzt und schon hab ich wieder die Kontrolle. Dieses jeden Traffic uebers VPN routen ist uebrigens komplett daemlich und brings rein garnichts (ausser viel sinnlosen Ping-Pong Traffic).

Das kommt drauf an. Es gibt durchaus Situationen (vorallem Länder) in denen es sehr sinnvoll ist alles übers VPN zu routen.

Ich kenne auch Firmen die alles durchs VPN schicken, weil die Mitarbeiter keinen uneingeschränkten Webzugriff haben. Der Zentrale Proxy bzw. die Firewall filtert fast alles raus. Soetwas lokal auf einem Laptop einzurichten ist nicht ganz einfach.

Klar, man kann viel machen wenn man das Laptop physikalisch vor sich hat, aber die BIOS Festplattenverschlüsselung zu umgehen, und dann unbemerkt ein paar DLLs austauschen ist sicherlich nicht ganz einfach.
 

airoli

Erfahrenes Mitglied
09.03.2009
398
1
ZRH / YUL
Der Tunnel muss ja irgendwo enden, daher brauchst Du irgendwo einen Server oder einen VPN-Provider.
Ja, ich weiss, deshalb eben meine Frage, ob jemand hier einen Dienst kennt, der (idealerweise gratis) VPN-Tunnels anbietet?

Ich habe weniger Probleme damit, meinen privaten Datentraffic verschlüsselt zu einem vetrauenswürdigen VPN-Anbieter zu schicken, als munter über offene WLANs in öffentlichen Bereichen zu funken.