Veröffentlicht am

Hinter dem Horizont geht’s weiter

Horizont und KommunikationEine alte Weisheit sagt, dass der Blick über den eigenen Tellerrand manchmal hilfreich ist.

Soll sagen: Man muss technische Dinge immer hinterfragen und die Tragweite des eigenen Handelns abschätzen.

Machen wir uns an einem fast fiktiven Beispiel klar, warum das wichtig ist.

Das Beispiel ist ein aktueller Vorgang rund um den DynDNS (Dynamic Domain Name Service) des Anbieters „NoIP“.

DynDNS ist eine Möglichkeit, um von unterwegs auf den heimischen Datenbestand zuzugreifen. Oft haben kleiner Unternehmen und Privatanwender keine feste IP-Adresse auf die sie zugreifen, sondern bekommen vom Provider nur eine dynamische IP zugeteilt.

Welche IP-Adresse das dann genau im Moment ist, bekommt man aber nur heraus, wenn man im eigenen Netz ist. Der VPN-Client auf dem Smartphone oder das Musikprogramm, das die eigenen Lieder unterwegs abrufen soll, wissen das von aussen nicht.

Hier hilft es, einen festen Namen wie „homeserver.no-ip.org“ einzustellen und der DynsDNS-Server der Zone „no-ip.org“ kümmert sich darum, welche IP das dann im Moment ist.

Was ist denn in unserem Beispiel eigentlich passiert?

Da scheiden sich noch die Geister, der eigentlich Sachverhalt WARUM ein großer Software-Anbieter aus den USA den Dienst übernommen hat, spielt aber für meine Betrachtung keine Rolle.

Mir geht es um das WIE.

Offenbar hat der Software-Hersteller bei Gericht beantragt, die Domains von „NoIP“ im DNS übernehmen zu dürfen, um so eine größere Anzahl von Servern mit Schadsoftware unschädlich zu machen. Also ist die Rechtsabteilung mit einer eigentlich sinnvollen Idee los marschiert und hat Recht bekommen.

(Die Frage, warum sich ein privatwirtschaftliches Unternehmen dazu berufen fühlt, einen solchen im Grunde bei der Exekutive angesiedelte Aufgabe zu übernehmen, lasse ich erst einmal offen im Raum stehen. Was aber nicht heißt, dass dieser Aspekt so ganz unbemerkt bleiben sollte!)

Jetzt kommt das Problem.

Offenbar hat man im Vorfeld nicht genau genug bei der Technik nachgefragt wie man so eine Übernahme denn realisieren könnte. Die Technik hat vermutlich geantwortet „Kein Problem, wir machen das als Proxy DNS, holen uns die Originaldaten von den Servern bei NoIP und filtern die bösen Hostnamen einfach heraus“.

Der Weg ist technisch prinzipiell durchaus gangbar. Nur leider hat die Rechtsabteilung entweder bei der Frage vergessen die Anzahl der aktiven Kunden zu nennen, oder hat bei der Antwort aus der Technikabteilung ein einschränkendes „Wir setzen das auf einer VM auf, damit können wir etwa x Requests pro Sekunde abwickeln“ einfach überhört.

Das passiert ganz oft in der Kommunikation zwischen Technikern und Nicht-Technikern. Die einen reden ihre eigene Sprache (siehe oben) und bei den anderen kommt ein Teil der Kommunikation nur als nutzloses Rauschen an. Denn eins ist klar: Was man nicht auf Anhieb versteht, das übersieht man.

Das Resultat?

Nun, momentan sind wohl die DNS-Proxies gnadenlos überlastet oder das Filtern der Domains per Script ist doch langsamer als gedacht. Fakt ist jedenfalls, dass eine riesige Anzahl an DNS Abfragen leer laufen. Natürlich mit dem Resultat, dass die dahinter liegenden Rechner im heimischen Netz nicht mehr erreichbar sind.

Im Ergebnis hat man also jetzt um ein Dutzend Server mit Schadsoftware zu blockieren, Tausende von anderen Servern einfach lahmgelegt. Man nennt so etwas wohl Kollateralschaden. Das Wissen wie man das nennt, hilft den Betroffenen nur leider nicht.

Was hilft?

Nachdenken und Kommunikation, die den anderen erreicht.

Ist es denn so schwer, den Juristen zu entgegenen: „Das ganze können wir unter Beachtung der aktiven Benutzer des Dienstes machen. Von wie vielen Anwendern reden wir? Wie viele Kunden hat der Dienst? Wie viele Servernamen sind zu erwarten?“

So eine Rückfrage entschleunigt den Prozess, das ist sicher. Aber ist das denn schädlich? Bei so einer Rückfrage hätten die Juristen nämlich durchaus auf die Idee kommen können, diese Zahlen zu hinterfragen. Da wäre dann vermutlich schnell heraus gekommen, das man ein Dutzend Schadsoftware-Schleudern blocken will und dafür aber Abertausende von anderen DNS-Abfragen bearbeiten muss. Dann wäre die nächste Frage an die Technik vermutlich gewesen: „Können wir das stemmen, was kostet der Betrieb intern und funktioniert das ohne, dass uns fälschlich Betroffene mit Regress kommen?“.

„Ihr macht das jetzt einfach mal und dann sehen wir schon…“ ist einfach der falsche Ansatz, wenn es um IT geht. Man sollte sich nicht zu schade sein zuzugeben, dass die eigenen Kenntnisse von anderen Bereichen (insbesondere technischen Bereichen!) unzureichend sind und man sich auf den Sachverstand der anderen verlassen und mit den Experten aus der Technik kommunizieren muss.

Solange Unternehmensprozesse aber immer weiter und weiter aufgespalten werden, damit jeder Anlernling sie mit Hilfe eines einzelnen A4-Zettels ohne Nachfrage ausführen kann, sind solche Sachen einfach vorprogrammiert.

Hier sollten Entscheider in Unternehmen ganz schnell gegensteuern und dafür sorgen, dass Menschen im Unternehmen verbleiben, die den Überblick haben.

Denn sonst passiert einem Unternehmen das, wovor die Wikinger am meisten Angst hatten: Das die Erde eine Scheibe ist und man am Ende des Horizonts einfach herunter fällt.
Veröffentlicht am

Hut ab…

Instagram umgeschaltetHeute muss ich doch einmal kurz den Hut ziehen.

Anlass ist dieser Artikel bei Wired.com. Er beschreibt, was da in den letzten Wochen so leise im Hintergrund bei Instagram passiert ist.

Der Instagram Gründer Mike Krieger hat es sehr schön bildhaft umschrieben:
‘The users are still in the same car they were in at the beginning of the journey, but we’ve swapped out every single part without them noticing.’

Und da kann ich als Techniker wirklich nur den Hut ziehen. Nach meiner Wahrnehmung gab es nämlich in der Übergangsphase kaum merkliche Unterbrechungen im Service.

Das ist schon eine wirklich gewaltige Leistung der Facebook- und Instagram-Techniker im Hintergrund.

Was ist passiert? Ganz einfach. Man hat die Daten von Instagram vom bisherigen Ablageort in der Amazon-Cloud in Facebook-eigene Rechenzentren umgezogen.

Das klingt erst einmal nicht spektakulär, aber machen wir uns einmal klar, was da an Daten umgelagert werden musste: Wir reden über rund 20 Milliarden Fotos. Das ist eine unglaubliche Menge an Daten, die es zu migrieren galt.

Der Haken dabei: Am Dienst nehmen ca. 200 Millionen Apps auf Smartphones verteilt über alle Zeitzonen teil. Die sollen von der Migration natürlich nichts merken.

Hand auf’s Herz: Mittelständische Firmen haben oftmals mit dem Umzug der eigenen Daten schon Probleme wenn man den zweistelligen Terabyte-Bereich verlässt. In diesem Fall reden wir von einem zweistelligen Petaybyte Bereich!
Dazu noch die ganzen Datenbanken und Datensicherungen. Etwas mehr zu den technischen Hintergründen gibt es im Entwickler-Blog bei Instagram

Das ist schon ein gewaltiges Projekt, bei dem auch noch im Produktivbetrieb umgelagert werden musste.

Deswegen: Statt kritischer Worte mal ein ehrliches „Hut ab…!“ an die Techniker dahinter.

Veröffentlicht am

TrueCrypt am Ende?

TrueCryptDie Entwickler der Software TrueCrypt warnen vor ihrem eigenen Produkt.

Himmelfahrt 2014 gibt es bei Twitter viel Seltsames zum Thema „TrueCrypt“ zu beobachten. Unter dem Hashtag #truecrypt tauchen Meldungen auf, wonach die Entwickler der Verschlüsselungssoftware TrueCrypt das eigene Produkt als unsicher erachten:

“WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues”

Das Ganze wirkt im ersten Moment wie ein schlechter Scherz. Die frei verfügbare Software TrueCrypt wird von vielen Sicherheitsexperten eigentlich noch immer empfohlen, da sie für alle gängigen Betriebssysteme zur Verfügung steht. Sie ist sogar in der Lage komplette Festplattenpartitionen zu verschlüsseln.

Wenn man dann den Vorgang genauer betrachtet, erscheint er noch seltsamer.

Für einen bloßen Scherz oder ein Webseiten-Defacement (Also das Entstellen einer Website durch Hacker), sind einige Fakten viel zu strukturiert. So leitet die originale Website unter truecrypt.org mit Hilfe einer Webserver-Direktive auf die Entwicklerplattform Sourceforge um. Hierzu benötigt man entweder Zugriff auf die Konfiguration der eigentlichen Server-Software oder muss zumindest das Recht haben per .htaccess-Datei bestimmte Funktionen des Servers zu steuern.

Zeitgleich wurde auch eine neue Version 7.2 der Software bei Sourceforge veröffentlicht. Diese ist neu kompiliert und es wurde die Funktionen zur Verschlüsselung entfernt. Dafür aufgenommen wurden offenbar Warnhinweise, dass man auf andere Produkte ausweichen möge.

Es wurden auch alle vorherigen Versionen bei Sourceforge entfernt.

Allein das würde bedeuten, dass ein Hacker nicht nur Zugriff auf den Webserver von truecrypt.org erlangt haben müsste, sondern auch auch sehr weitreichende Rechte auf das Entwicklerportal hatte.

Die neue Version wurde auch mit einem private Key der Entwickler signiert, was bedeuten würde, dass auch dieser in fremde Hände gefallen sein müsste.

Ebenfalls spannend: Scheinbar sind auch alte Versionen der Website von TrueCrypt aus Web-Archiven wie der WayBack-Machine entfernt worden.

Das ist alles schon sehr merkwürdig und ist bestimmt kein Unfall.

Noch seltsamer wird der Vorgang nämlich wenn man weiß, dass vor einiger Zeit eine externe Sicherheitsfirma begonnen hat, den Code von TrueCrypt zu auditieren. Hierbei kam in der ersten Auditierungsstufe heraus, dass es keine eklatanten Sicherheitslücken gibt. Das steht in krassem Widerspruch zur jetzt vorgenommenen Selbsteinschätzung der Entwickler.

An diesem Punkt sprießen die Verschwörungstheorien.

TrueCrypt gehörte genau wie der E-Mail Anbieter Lavabit zu den bevorzugten Werkzeugen von Edward Snowden. Lavabit erhielt vor einiger Zeit von US-amerikanischen Behörden eine Aufforderung, sämtliche Verschlüsselungs-Keys herauszugeben, damit die verschlüsselten Inhalte entschlüsselt werden können. Lavabit hat daraufhin von einem Tag auf den anderen den Dienst eingestellt und sämtliche Daten gelöscht.

Aufforderungen dieser Art beinhalten in den USA stets auch die Aufforderung nicht über den Vorgang zu sprechen oder sich zu äußern.

Ist so etwas jetzt auch bei TrueCrypt passiert? Natürlich kommen sofort Gerüchte dieser Art auf. Es besteht aber erst einmal kein Grund zu einer Panikreaktion.

Gehen wir einmal besonnen mit der Situation um:

TrueCrypt sagt, die Software ist nicht mehr sicher.

Gut, das ist nicht schön, aber kein Grund zur Panik. Die letzte Version 7.1a ist jetzt seit fast zwei Jahren unverändert. Es gibt also keinen Grund sie nicht zumindest noch für die Umspeicherung der eigenen Daten zu benutzen.

Auch der angegebene auslaufende XP-Support ist kein ausreichender Grund von jetzt auf gleich an der Sicherheit der Software zu zweifeln. Die Entwickler benutzen zwar einen uralten Compiler unter Windows XP um die Software zu übersetzen, aber das war in den vergangenen Jahren aber auch kein Problem.

TrueCrypt empfiehlt, Tools nutzen die die Betriebssysteme mitbringen.

Das ist nicht wirklich zielführend. TrueCrypt hatte eben den charmanten Vorteil, dass verschlüsselte in der Cloud abgelegte Daten unabhängig vom Betriebssystem genutzt werden konnten. Das geht mit diesem Ansatz nicht.

Sinnvoll erscheint mir momentan, das eigene Sicherheitskonzept zu hinterfragen.

Wer seine Daten in einem TrueCrypt-Container in Dropbox oder sonst einem Cloudspeicher aufbewahrt, tut gut daran, das zu ändern. Was vor einiger Zeit noch als gangbarer Weg galt, um das Sicherheitsrisiko von Daten in der Cloud zu minimieren, muss mit diesem Tag als überholt betrachtet werden.

Sensible Daten raus aus der Public Cloud muss die aktuelle Devise sein.

Also Daten zurückholen in eine sichere Umgebung, entschlüsseln und nur das auf einem Stick mitnehmen was man unterwegs braucht. Diese Entscheidung ist ja jederzeit reversibel, wenn sich der aktuelle Wirbel um TrueCrypt legt und die Situation sich nachhaltig klärt.

Meine Empfehlung zum Thema Nachhaltigkeit: Zurück zu einem Konzept mit eigenen Servern und VPNs um an die Daten zu gelangen.

Durch den Aufbau einer sicheren „Privaten Cloud“ lässt sich durchaus der gleiche Nutzen erreichen ohne das Risiko offener Daten bei einem fremden Diensteanbieter einzugehen.

Veröffentlicht am

Kommunales WLAN?


WLAN als kommunales NetzWLAN von der Stadt?

Ein Gedankenspiel.

 

Strom kommt auch aus der Steckdose und Wasser aus der Leitung. Warum sollte man nicht einmal über so ein Projekt nachdenken?

Bringen wir doch einmal ein wenig Licht ins Dunkel.


Geht das eigentlich prinzipiell? Was für Probleme tauchen auf? Ist das bezahl- und verwaltbar?

Das sind so ersten Fragen, die mir durch den Kopf schießen. Sie werden schnell konkreter. Welche Reichweite hat ein aktuelles WLAN mit 2.4 oder 5 GHz? Welche Abstrahlleistung muss an der Antenne vorhanden sein, wie leuchtet man eine ganze Stadt mit all ihren Häuserschluchten flächendeckend aus? Schon hier wird es wirklich kompliziert. Man muss nur einmal in den Bereich der Handynetze blicken, um zu merken, dass es gar nicht so einfach ist, das in den Griff zu bekommen.

Und wir sind dann auch schnell auf einer anderen Ebene der IT-Technik. Nämlich bei der eigentlichen Paketvermittlung und der IT-Sicherheit.

WLAN ist vom Prinzip her eigentlich ein sogenanntes „Shared Media“-Netzwerk. Also alle Teilnehmer an einem Zugangspunkt teilen sich die Funkbandbreite. Es ist darüber hinaus sogar so, dass der langsamste Teilnehmer im Netz die Gesamtgeschwindigkeit der Funkzelle bestimmt. Einzige Lösung: Mehr Funkzellen ins Netz nehmen, damit jeder Teilnehmer eine ausreichende Feldstärke bekommt. Damit steigt aber wieder das Problem, dass sich die verschiedenen Funkkanäle gegenseitig beeinflussen.

Es muss also möglichst automatisch dafür gesorgt werden, dass die Kanäle sich automatisch neu ausrichten und es immer einen optimalen Frequenzabstand benachbarter WLAN-Zugangspunkte gibt.

Der nächste Aspekt ist der Übergang zum Internet-Backbone.

Legt man diesen redundant aus, müssen im gesamten WLAN-Verbund Entscheidungen getroffen werden, in welche Richtung ein Datenpaket vermittelt werden kann. Das löst dann wieder Aufgaben im Bereich der dynamischen IP-Adressierung aus.
Und was passiert bei einem Ausfall eines Übergangspunktes? Der Ausfall muss anderen Zugangspunkten mitgeteilt werden, damit diese einen alternativen Weg suchen können.

Dann  wieder einmal das leidige Thema IT-Sicherheit.

In einem kabelgebundenen Netzwerk ist relativ klar, wer als Teilnehmer im Netz mitspielt. Und damit ist auch klar, wer möglicherweise Daten mitlesen kann. In einem freien WLAN wird das schon schwieriger. Die Realität wird so sein, dass sich jederzeit Unbekannte ins Netzwerk einbuchen können. Und da wir im WLAN eben über ein geteiltes Medium kommunizieren, hat diese Unbekannte also die Möglichkeit mitzulesen.

Und nein, da hilft auch keine zeitgemäße Verschlüsselung mit WPA2. Denn die Teilnehmer sind ja alle berechtigte Teilnehmer des Netzes. WPA2 hilft nur gegen fremde Augen, die den Zugang nicht kennen. Einmal angemeldet ist das Netz quasi transparent.

Im Grunde entstehen in so einem Projekt unendlich viele Probleme, die aber eigentlich jedes für sich gelöst werden können. Intelligente WLAN-Controller, neue Routing-Protokolle wie OLSR (im Freifunk-Projekt schon aktiv) oder auch VPN-Lösungen um sich in diesem Netz sicher bis zu einem vertrauten Gateway zu verbinden. Aber das alles bringt das letzte große Problem auf.

Die Finanzierung.

Denn alle diese kleinen Details kosten Geld. Sei es dadurch, das bestimmte Geräte beschafft werden müssen, die einige der Funktionen besitzen. Dann die Entwicklung nicht vorhandener Funktionalitäten. Das alles macht es relativ teuer. Und damit für Kommunen heutzutage wieder unrealisierbar. Also doch Werbung ins Boot nehmen? Ist das Netz dann aber noch neutral? Oder wird es im stillen Käbelchen nicht doch ein wenig nach den Interessen der Finanzierer ausgerichtet?

Eigentlich ist die Idee wirklich verlockend und die Freifunker in Berlin und anderswo zeigen eigentlich, dass so etwas in kleinem Rahmen auch funktioniert. Aber das tut es vermutlich nur, weil ganz viele Menschen mit Eigeninteresse und Enthusiasmus die Entwicklung antreiben.

Veröffentlicht am

Bring Your Own Device

byod - bring your own deviceNutzerverhalten ändert sich. Das ist normal wenn sich Möglichkeiten ändern. Das ist allerdings auch ein Risiko wenn Unternehmen sich darauf nicht vorbereiten.

Bring your Device (BYOD) wird heiß diskutiert und oft eher nur als Risiko gesehen. Es bringt aber auch klare Vorteile.

 

Warum also eigentlich nicht?

 

Immer mehr Nutzer haben Smartphones oder private Laptops, die momentan als Risiko für Unternehmensnetzwerke gesehen werden.

Natürlich geht von diesen Geräten ein bestimmtes Risiko aus. Aber sie bringen ganz sicher auch einen Nutzen. Der Versuch einer sachlichen Näherung.

Menschen sind vernetzt. Mit Menschen aus dem beruflichen Umfeld. Oder mit Menschen, die gemeinsame Interessen haben. Wie viele Maschinenbauer sind z.B. begeisterte Schrauber oder RC-Modellbauer und sind gewohnt in dem Bereich zu improvisieren und nach Lösungen zu suchen? Wie viele Elektrotechniker basteln privat an Mikrocontrollersteuerungen für die Hausautomation?

Warum nicht auch als Unternehmen von dieser Tatsache profitieren? Das ist doch auch gar nicht so ungewöhnlich in der analogen Welt. Man hört von Freunden und Bekannten von Seminaren oder Fortbildungen, erhält interessante Denkanstöße. Alles Gelernte wird auch im Beruf indirekt genutzt.

Und heute passiert diese Vernetzung eben über Smartphones, Tablets und soziale Medien.

Die Vernetzung ist schneller, breiter und oft auch inhaltlich tiefer als früher. Wir leben in einer Informationsgesellschaft.

Und Informationen laufen ganz oft auf diesen privaten Geräten zusammen. In einer der persönlichen Arbeitsweise des Mitarbeiters entsprechenden Form. Auf einem Betriebssystem, das der Anwender mag. Mit dem er sich auskennt und souverän umgeht.

Warum muss ein Mitarbeiter im Betrieb auf seine aus dem privaten Umfeld gewohnten Arbeitsumgebung verzichten? Nur weil es die interne Unternehmensrichtlinie vorsieht?

Nehmen wir den Arbeitsplatzrechner doch einmal unter dem Gesichtspunkt Mitarbeitermotivation unter die Lupe. Mit dem „Nebenaspekt“ Sicherheit.

Von IT-Verantwortliche hört man oft das Killerargument: „Das können wir nicht unterstützen.

Mag sein. Aber muss man das? Kann der User das oft nicht sogar besser selbst? Warum nicht ein wenig mehr dem Anwender vertrauen und Verantwortung an den User weitergeben? Man erhält im Gegenzug einen dem Equipment positiv gegenüberstehenden Mitarbeiter. Der sich mit Sicherheit um „sein Eigentum“ besser kümmert als wenn er das Gerät einfach in der IT pflegen lassen muss.

Auch das ist ein Argument: Der Mitarbeiter sorgt mit Sicherheit für besseren Datenschutz, wenn auch die eigenen Daten betroffen sind, wenn ein Virus zuschlägt.

Oder ein anderer Ansatz: Alarmketten in der IT. Welcher IT-Mitarbeiter kriegt wirklich immer alle aktuellen Sicherheitswarnungen mit? Hand auf’s Herz…. Mir geht durchaus auch mal was durch. Und dann bin ich dankbar für Informationen über Facebook, Twitter oder RSS-Streams.

Warum also nicht über den Twitter-Account eines Mitarbeiters von aktuell genutzten Sicherheitslücken erfahren? Ich fand sowohl die Warnung über offene WLAN-Router der Telekom, als auch die Warnung vor einer als Telekom-Rechnung getarnten PDF-Datei absolut hilfreich und wusste ganz sicher sehr früh davon. Und konnte das weitergeben.

Man kann als IT-Verantwortlich also durchaus auch von dieser Vernetzung profitieren!

Lieber vor einer pdf-Datei mit Schadcode warnen, als hinterher im ganzen Unternehmen einen Virenscan mit Beseitigung fahren zu müssen. Also kann man „Bring your own device“ auch für proaktives Handeln nutzen.

Was her muss, sind Regeln und Richtlinien, wie mit den Devices umzugehen ist.

Das fängt im Bereich Infrastruktur damit an, dass Port-Security als Thema aktiv angegangen wird. Jeder Mitarbeiter darf nur wirklich sein freigegebenes Gerät ins Netzwerk einbringen. Clientzertifikate, 802.1x als Thema. Aufklären, warum das so sein muss.

Oder für mobile Devices wie Smartphones einen eigenen WLAN-Bereich aufziehen? Der Mitarbeiter ist froh, wenn seine Datentarife nicht über die Drosselungsgrenze gehen.

Solange die Arbeit nicht darunter leidet, ist eigentlich kein Argument zu sehen was dagegen spricht. Im Gegenteil. Im Alltag gibt es immer wieder Lücken, wo einfach nichts zu tun ist. Warum also nicht dem Mitarbeiter zugestehen, dass er stattdessen seinen Twitter-Stream liest? In Zeiten wo viel Arbeit anfällt, hat man als Unternehmer dafür einen hoch motivierten, sich im Unternehmen wohlfühlenden Mitarbeiter.

Das nutzt der Unternehmenskultur ganz sicher.

Nachdenken lohnt sich also.

Veröffentlicht am

Grenzen der Bequemlichkeit

WLAN SicherheitEin WLAN abzusichern kann man jedem zumuten.

Kann man.
Sollte man aber nicht.

 

Sicherheit bleibt etwas Individuelles.

 


Aktuell in der Presse und sogar im Fernsehen: Massenhaft eingesetzte Endgeräte der Telekom haben eine „Sicherheitslücke“.

Was einem dabei zu denken geben sollte? Ganz einfach. Ob man Sicherheitsfeatures im IT-Bereich so umsetzen kann und muss, dass jeder, der einen Toaster bedienen kann sich zutraut das eigene IT-Equipment zu bedienen.

Das mag provokant klingen, aber machen wir uns die Situation einmal klar.

Die Rechtsprechung verlangt vom Betreiber eines Drahtlos-Netzwerks (WLAN), dass dies so konfiguriert sein muss, dass es dem Stand der Technik entspricht. Das bedeutet klar eine Absicherung gegen unbefugte Nutzung und leitet aus dem Nichtvorhandensein von Sicherungsmaßnahmen eine Haftung ab. Den Beteuerungen von Beklagten wurde zum Beispiel nie Glauben geschenkt, dass Netz nicht offen betrieben zu haben. Klare Beweislastumkehr, die im Zivilprozess so auch immer funktionierte, wenn es um Schadenersatzforderung der Film- oder Musikindustrie ging.

Mit dieser Argumentation war klar, dass ein WLAN mit der im Auslieferungszeitpunkt bestmöglichen Verschlüsselung abzusichern ist. Im Grunde kann man als Hersteller bei allen in Deutschland verkauften Geräten eigentlich die Modi „offenes WLAN“, „WEP“ und „WPA“ aus der Firmware heraus lassen. Also rückte „WPA2“ in den Fokus. Längere Passworte, andere Verschlüsselungverfahren und sogar Authentisierungen per Radius-Server…

Und damit wird es problematisch. Die Hersteller trauen oder muten den Anwendern ja nicht einmal zu, Passworte einer bestimmten Länge in all ihre WLAN-Geräte einzutippen. Statt als Hersteller aber hier klar zu empfehlen „Suchen Sie sich einen Experten“, versucht man diese Funktionen durch Automatismen mit Knöpfendrücken zu umschiffen.

Also statt den User für Sicherheit in der IT zu sensibilieren, macht man Sicherheit simpel.

Leider ist IT auch im Heimbereich schon lange nicht mehr simpel. Die kleinsten Router bringen schon Sicherheitsfeatures mit, bei denen der Normalanwender völlig überfordert ist. Wie viele Menschen können denn beurteilen, ob sie Prioritizing, Paketshaping, QoS oder LowLatency Ping brauchen? Oder welche Ports in der Firewall freizugeben sind und welche nicht? Richtig. Das wissen 5% der Anwender. Also von 100.000 Betroffenen im aktuellen Fall 5000. Bei den restlichen 95.000 Anwendern stehen die Geräte mit ziemlicher Sicherheit in den unveränderten Werksvoreinstellungen.

Ist ja auch alles ganz einfach. Gerät verkabeln, Strom drauf, läuft.

Damit man als Hersteller oder Provider auch noch Support leisten kann, falls der Anwender doch mal experimentiert und im Endergebniss nun wirklich alles zerschraubt hat, werden Hintertüren eingebaut. Für die Konfiguration des Router wurde z.B. TR-069 entwickelt. Ein Verfahren, bei dem sich der Router alle notwendigen Konfigurationsdaten selber holt. Und es sind noch weit mehr Dinge damit möglich. Der obige Wikipedia-Artikel sei dem interessierten Leser sehr empfohlen!

Nebenbei werden in die Geräte vermutlich auch feste Testkonfigurationen einprogrammiert, um das WLAN zu testen. Das wäre nämlich eine mögliche Erklärung für das aktuell gefundene Sicherheitsloch. Im Grunde sind beides aus Sicht der Hersteller und Provider völlig nachvollziehbare Funktionen.

Diese Fakten sollten aber vor dem Aspekt Sicherheit klar kommuniziert werden! Und diese Funktionen haben so umgesetzt zu werden, dass der Anwender diese abschalten kann. Zum Beispiel gelten für den Home-Office-Zugang die gleichen Sicherheitsrichtlinien wie im Betrieb. Und da hat niemand ohne explizite Zustimmung Funktionen zu aktivieren oder Logdateien auszuwerten. Auch Software-Updates sind ohne Freigabe durch den Eigentümer fast nach §202 und §303 StGB zu werten.

Vor dem rechtlichen Hintergrund ergibt sich eigentlich nur eine Konsequenz: Wenn ich keinen Einfluss auf die Sicherheit meines WLANs habe, lehne ich auch die Haftung dafür ab! Es ist doch wohl ein schlechter Witz, dass mein WLAN trotz Abschaltung der „Knöpfchen“-Lösung und sogar bei expliziter ABSCHALTUNG des WLAN einen Zugang mit fest einprogrammierten PIN bietet. Und dann auch noch „01234567“.

Die von Hersteller und Inverkehrbringer gezeigte Art mit IT-Sicherheit umzugehen, ist aus meiner Sicht mehr als grob fahrlässig.

Letztendlich liefen in Deutschland einige Prozesse, bei denen es den verklagten Anwendern unmöglich war, den Nachweis zu erbringen, dass das ausreichend abgesicherte WLAN unbefugt genutzt worden sein könnte. Richter haben stets argumentiert, dass die eingesetzten Verfahren zur Absicherung des WLAN sicher sein. Sind die Verfahren auch. Nur die Implementierung in der Hardware aber nicht. Was nun hinreichend bewiesen ist. Bereits gefällte Urteile sollten vor dem Hintergrund der jetzt verfügbaren Informationen noch einmal hinterfragt werden!

Man sollte dem Inverkehrbringer die Geräte auf den Hof kippen und sämtliche Prozesskosten seit der Inverkehrbringung weitergeben!
Veröffentlicht am

IPv6 – Ein erstes Fazit

Seit zehn Monaten sprechen meine Geräte IPv6.

Warum ist das so erwähnenswert? Die Erklärung ist einfach: Nachdem die letzten IPv4 Adressen vergeben wurden, wird es langsam eng im IPv4-Adressraum.

Natürlich ist jetzt nicht schlagartig Schluss mir neuen IP-Adressen, denn durch Wechsel bei den Providern und Hostinganbietern werden immer auch wieder einmal Adressen frei.

Obwohl also kein akuter Zeitdruck herrscht, habe ich mich entschlossen den nächsten Schritt zu vollziehen und praktische Erfahrungen zu sammeln. Nach den erfolgreichen Tests am IPv6 Tag im Juni 2011 besteht nur noch geringe Skepsis, dass ein zweigleisiger Betrieb funktionieren wird.

Wie sieht jetzt das Fazit nach rund zehn Monaten Dualstack-Betrieb aus?

Ganz einfach. Im Grunde hat niemand von der Umstellung etwas bemerkt. Für den Empfänger/Kunden/Besucher ändert sich in der Regel auch nichts. Die Implementierung des neuen IP-Protokolls ist so ausgelegt, dass beide Verfahren nebeneinander funktionieren. So sind alle unsere Maschinen auch weiterhin über die altbewährten IPv4 Adressen erreichbar.

Kurz zur Erinnerung ein paar Grundlagen:

Was ist IPv6 eigentlich?

IPv6 ist eigentlich nichts anderes als was wir mit den neuen Postleitzahlen gemacht haben: Die Anzahl möglicher Adressen wurde ausgeweitet. Unter IPv4 ist die Länge einer IP-Adresse begrenzt auf 32 Bit. Hier stehen somit insgesamt 2^32 Adressen (ca. 4.2 Milliarden Adressen) zur Verfügung. Das klingt eigentlich viel, nur sind diese Adressen nicht einzeln vergebbar, sondern werden in der Regel in Blöcken vergeben. Und diese Blöcke sind derzeit erschöpft.

Was liegt also näher, als die Anzahl der Adressen zu vergrößern? Es wurde also beschlossen, die Länge der Adressen auf 128 Bit auszuweiten. Das bedeutet dann 2^128 Möglichkeiten. Und diese Anzahl dürfte erst einmal reichen.

Wie sieht man etwas von IPv6?

Eigentlich gar nicht. Weder bei den Mailadressen, noch beim Aufruf von Webseiten ändert sich für den Nutzer etwas. Nur die Administratoren im Netzwerk haben ein wenig zu tun.

Neue Routen müssen gesetzt werden, Firewallregeln angepasst werden und Router umkonfiguriert werden.

Aus den alten Adressen der Form „178.63.52.37“ wird jetzt „2a01:4f8:120:7386::2“. Beides wird aber im Webbrowser immer noch als „www.vico.de“ angesprochen. Im Hintergrund laufen die eigentlichen Abfragen vor dem Aufruf der Seite automatisch ab. Alle Browser und Hilfsprogramme sind mittlerweile so ausgelegt, dass sie je nach Konfiguration zunächst versuchen, das Ziel per IPv6 anzusprechen. Wenn das nicht klappt, wird einfach auf das altbewährte IPv4 zurück geschaltet.

Und wie sieht die Empfehlung aus?

Erfahrungen sammeln schadet nicht. Also einfach in bestimmten Bereichen den Schritt wagen und auf den Dualbetrieb wechseln. Also zum Beispiel externe Server und Firewalls umstellen und Erfahrungen sammeln.

Danach dann IPv6 in einzelnen (unkritischen!) Bereichen des eigenen Netzwerks in Betrieb nehmen und sehen, ob alles wie geplant funktioniert. Also vielleicht erst einmal nur einen Proxyserver mit einem Tunnel an den IPv6 Backbone anbinden. Und wieder Erfahrungen sammeln. Denn hier wird es spannend: Bislang vorhandene Zugriffsbeschränkungen auf Basis der IP-Adresse greifen möglicherweise nicht. Also aufgepasst, das nicht plötzlich mehr erlaubt ist, als geplant.

Spätestens wenn Endgeräte im internen Netzwerk mit IPv6 angebunden werden, muss man sich darüber im Klaren sein, dass jetzt das interne Netz nicht mehr durch ein bislang vorhandenes NAT abgetrennt wird. Das Internet reicht also möglicherweise bis auf den lokalen Schreibtisch!

Um einen gangbaren Weg in Ihrem Unternehmen aufzuzeigen und Fehler zu vermeiden, stehen wir gerne zur Verfügung. Sprechen Sie uns an.

Veröffentlicht am

Ein Handy auf Reisen

Die Vorratsdatenspeicherung und was allein mit den beim Handynetzbetreiber gespeicherten Daten möglich ist:

http://www.zeit.de/datenschutz/malte-spitz-vorratsdaten

Das muss man eigentlich nicht weiter kommentieren. Was man daraus so alles in Kombination mit Daten aus sozialen Netzwerken machen kann mag jeder einmal selber überlegen.

Und das die Daten ohne Rechtsgrundlage genutzt werden hat Dresden klar bewiesen. Ein Beitrag des Magazins Fakt:

http://www.youtube.com/watch?v=DXIBOjMg6l0

Im Grunde kann aus diesem Beispiel nur eines ableiten: Öfter mal das Handy ausmachen. Oder in Keksdosen legen wie in so manchem Unternehmen, Evonik wird schon wissen warum man das macht. Quelle: Spiegel Online

 

Veröffentlicht am

IPv6-Chance und Risiko


IPv6 - Die Zeit ist reifIm Hintergrund wird schon fleißig am Internet der Zukunft gewerkelt.

 

IPv6, also Internet Protocol, Version 6 steht seit einiger Zeit in den Startlöchern. Ein paar Hintergründe finden sie hier.

Der größte Antrieb für IPv6 dürften Multimediaanwendungen im Netz sein. Welcher Admin hat nicht schon Stunden damit verbracht, ein neu eingeführtes Übertragungsprotokoll für Video- oder Audiotelefonate zu implementieren? Da viele dieser Protokolle auf UDP-Basis agieren, war es unendlich schwer, Firewalls dazu zu bringen sich diesen Netzverkehr ordentlich zu merken. So lange nur ein Anwender im Netz telefoniert, ist ja noch alles einfach. Aber das verbindungslose UDP ist einfach nicht in der Lage sich zu merken, wer mit wem telefoniert, wenn mehrere Datenströme gleichzeitig aktiv sind.

Als Hilfsmittel wurde dann in allen Bereichen mit externen Vermittlungsservern gearbeitet. Fast alle Messenger wie Hotmail (MSN) oder ICQ arbeiten mit solchen Login-Servern. Selbst Skype setzt mit seinen verschiedenen Nodes auf diese externen Knotenpunkte. Anders wäre auch ein Rechner hinter einem NAT-Router auch nicht erreichbar. Der sich hinter dem NAT befindliche Rechner meldet sich bei der Vermittlung per TCP an, diese merkt sich die offizielle IP-Adresse, spricht diese im Bedarfsfall über einen TCP Rückkanal an und lässt es dann klingeln. Ab diesem Punkt können dann die Endteilnehmer miteinander per UDP reden, wenn der Firewall-Admin ausreichend Löcher in die Firewall gebohrt hat.

Dies alles entfällt mit IPv6, da jedes Endgerät direkt im Internet adressierbar wird. Damit wird dann endlich direkte Ende-zu-Ende Kommunikation möglich.

Leider liegt auch da genau das Risiko, denn momentan sind interne Netzwerke bei Privat- und Businessanwender durch den Router per NAT (Network Address Translation) aus Sicht des Internet ja unerreichbar. Im Internet taucht immer nur die IP-Adresse der Router-Aussenseite auf. Und auch nur diese kann angesprochen werden. Insofern kann NAT also durchaus als ein kleiner Baustein im Sicherheitskonzept gesehen werden.

Mit IPv6 wird sich das ein wenig verändern. Denn IPv6 wurde ja entwickelt, damit wieder jedes Gerät eine eindeutig im Internet erreichbare Adresse bekommen kann. NAT ist bei IPv6 in ganz klar definierten und seltenen Szenarien noch ein Thema.

Es ist also aus unserer Sicht durchaus angeraten, vor Einführung von IPv6 das eigene Firewall- und Routing-Konzept zu überprüfen und auf einen sicheren Stand zu bringen.

Veröffentlicht am

Die App als Sicherheitsrisiko

Apps als SicherheitsrisikoDie App als Sicherheitsrisiko ? !

Eine nicht ganz unberechtigte Frage. Oder nein. Eigentlich schon eine Antwort.

Der Versuch eines Lösungsansatzes.

Momentan tauchen jeden Tag neue Meldungen auf, das wieder eine App für iPhone oder andere Smartphones gefunden wurde, die Daten ungewollt und unbemerkt heraus gibt.

Der erste Lösungsansatz „Nicht mehr benutzen…“ ist für so manchen SocialMedia-Manager aber kaum realisierbar. Für Kommunikationsprofis stellen diese Apps einen klaren Vorteil dar und sind unverzichtbares Werkzeug der täglichen Arbeit.

Ohne ein belastbares Netz von Kontakten ist die Arbeit einfach nicht zu machen. Und diese Kontakte müssen eigentlich auch ständig im Zugriff sein.

Auf den zweiten Blick ist das, was die Apps tun, allerdings rechtlich nicht ganz ohne Brisanz.

Konstruieren wir als Beispiel den Fall eines SocialMedia-Profis, der für einen Konzern Kommunikationsstrategien entwickelt. Er/Sie wird auf seinem Smartphone eine Menge Kontakte des Auftraggebers haben. Auch andere Kontakte, nämlich die seiner Referenten für Schulungen. Event-Locations, Dienstleister. Im Grunde ist der projektleitende SocialMedia Manager die Spinne in dem Mitte des Netzes, bei der alle Fäden zusammenlaufen.

Das geht möglicherweise so weit, dass für interne Events vertrauliche, interne Konzernkontakte dabei sind, deren Daten in der Öffentlichkeit unerwünscht oder sogar schädlich sind.

Nun verliert dieser Kommunikationsprofi über so eine App die Daten. Damit sind diese Daten als kompromittiert zu betrachten. Anvertraute Daten sind weitergegeben worden.

Widerspricht das nicht klar der abgegebenen Vertraulichkeitserklärung? Stellt so ein Sachverhalt bei einem Journalisten nicht auch eine nach dem Journalistenkodex unerlaubte Quellenweitergabe dar? Und was ist mit dem Bundesdatenschutzgesetz?

Die nicht authorisierte Weitergabe personenbezogener Daten stellt einen Verstoß gegen das Bundesdatenschutzgesetz dar.

Also ganz konkret nachgefragt: Hat jemand, der Pinterest, Path oder Foursquare auf seinem Smartphone benutzt schon einmal seine vorgeschriebene Informationspflicht erfüllt und die betroffenen Kontakte über den nachgewiesenen Datenverlust informiert?

Die ersten Klagen werden spätestens dann kommen, wenn solche Daten für den Auftraggeber wahrnehmbar von Dritten genutzt werden. Und dann hilft dann kein Jammern mehr.

Hier ist ganz schnell ein Umdenken erfoderlich.

So bequem all diese Smartphone-Tools auch sind, sie sind gefährlich. Für alle, die damit umgehen oder damit erfasst werden.

Die klare Konsequent für jeden SocialMedia Profi muss aus meiner Sicht sein, alle genutzten Apps auf Herz und Nieren zu prüfen. Also im Sinne des Risikomamagements klar festhalten, welche Daten fließen sicher ab, welche nur eventuell und welche gar nicht.

Nur dann kann der Auftraggeber entscheiden, welche Tools in der Kampagne genutzt werden dürfen und welche Informationen einem Verlustrisiko ausgesetzt sein dürfen. Und erst auf dieser Basis darf dann die klar formulierte Vertraulichkeitserklärung abgegeben werden!

Es gibt die zur Bewertung nötigen technischen Möglichkeiten um den Datenstrom zu scannen und zu bewerten. Wer vorhandene Möglichkeiten nicht nutzt und den Kopf in den Sand steckt, handelt zumindest grob fahrlässig.