Cybersicherheit auf der Überholspur: Auf dem Acronis-Partnertag

Wie viele Eindrücke und Erkenntnisse kann man vom ersten Partnertag mitnehmen? Professionell gesehen habe ich eine spannende Cyber Protection Lösung kennengelernt. Und persönlich betrachtet: wie man die ersten Schritte beim Netzwerken meistert.

Passend zum Motto „Reunite & Accelerate“ fand der diesjährige persönliche Partnertag von Acronis in der Motorworld in München statt.

Cyber Security auf der Überholspur sinngemäß, und so beschleunigten wir, zwei Kollegen und ich, gemeinsam morgens in der Haupthalle um 10 Uhr. Alle bekamen die ausgedruckte Agenda in die Hand und unser Gastgeber Acronis, der sich bereits beim Thema Backup einen großen Namen gemacht hat, zeigt in den Programmpunkten, wohin die Reise geht.

Mit Themen wie „Roadmap 2022 – wie Acronis sich dieses Jahr weiterentwickelt“, „Acronis Microsoft 365“ oder „[…] Advanced Security“ wird klar: Hier geht es um mehr als Backup-Lösungen.

Feature-Roadmap und Bekräftigung der Partnerschaft

Die ganze Veranstaltung stand im Rahmen der Partnerschaft und der Vorteile, die Acronis bietet. Für uns als Managed Security Service Provider ist es entscheidend, starke und verlässliche Partner zu haben. So hat jeder Partner von Acronis einen zentralen Ansprechpartner und man landet nicht in einer Hotline.

Ebenso sendeten sie die klare Botschaft, sich stark am Markt und den Kundenbedürfnissen zu orientieren und sich mithilfe ihrer Partner und Mitarbeiter fortzuentwickeln. Im Fokus stand das Motto: „Veränderung ist gut“. Acronis stellt das „WIR“ in den Vordergrund anstatt das „ICH“, was man an der Investition in Partner und Mitarbeiter sieht. Das hat Anerkennung verdient und es zahlt sich aus.

Dank der vielen Partner, mit denen das Produkt kooperiert, ist eine Integration des Produktes in so gut wie jede Umgebung einfach und unkompliziert möglich.

In der Roadmap 2022 wurde unter anderem folgendes vorgestellt:

• In Q1 ist eine Advanced Data Loss Prevention herausgekommen und vorerst als Beta verfügbar. Dadurch sollen Bedrohungen minimiert, Richtlinien eingehalten und die Reaktionszeit verkürzt werden
• Acronis Endpoint Detection and Response: Vorfälle sollen in wenigen Minuten untersucht werden und es wird schneller reagiert
• Papierkorb für Konten und Anwendungen: Falls etwas aus Versehen gelöscht wird, landet es im Papierkorb und kann innerhalb 30 Tagen wiederhergestellt werden
• Agentenlose Sicherung für alle Azure VMs: einfache Bereitstellung, effizientere Verwaltung und plattformübergreifend. Dabei soll alles in der Acronis Cloud gespeichert werden, was eine einfachere Handhabung und schnellere Recovery bei Bedarf als Vorteil hat.
• Wiederherstellung soll komfortabler werden – mit einem Klick und ohne große IT-Kenntnisse soll jeder benötigte Daten wiederherstellen können
• Automatisierte Testfailover mit einem KI-gestützten Screenshot-Überprüfungs-Mechanismus
• Acronis #CyberFit-Score Konfigurationsbewertung: Bewertung der Sicherheitslage der Workloads und Empfehlungen für die Konfiguration
•  Verwaltung von Endpoint-Firewalls, angefangen mit der Windows Firewall
• Eine einzige Verwaltungskonsole für alle Dienste

Das hört sich alles sehr vielversprechend an. Durch die Zusammenarbeit von den verschiedenen Komponenten ist alles in einer Admin-Oberfläche zu finden und man muss nicht mehr von einem auf das andere System hüpfen. Besonders sticht für mich die Verwaltung von Endpoint Firewalls heraus, die ein gutes Zusammenspiel der einzelnen Unternehmen benötigt.

Vorträge über KI, Ransomware und Cyberversicherungen

Hinzu kamen weitere Vorträge zu aktuellen Themen. Besonders beeindruckend finde ich das Thema Künstliche Intelligenz (KI). Hier erwartet uns eine völlig neue, interessante und doch auch erschreckende Welt, die wir derzeit gar nicht richtig einschätzen können. Ich finde alles, was mit KI zu tun hat, sehr aufregend.

In einer Live Ransomware Attacke wurde gezeigt, warum Acronis wichtig und sinnvoll ist. Acronis hat eine Automatisierung, die durch einen Anti-Malware-Schutz automatisch z. B. Verschlüsselungen erkennt und diese stoppt und aus dem Backup direkt die verschlüsselten Dateien wiederherstellt. Acronis prüft Backups, bevor sie gemacht werden, und prüft sie auch nochmals auf Ransomware, bevor die wieder eingespielt werden.

Die Vorträge der Partnersponsoren waren ebenfalls sehr interessant. Unter anderem wurde von einer Cyberversicherung verständlich und kompetent erklärt, wofür und warum überhaupt auch eine Cyberversicherung hilfreich ist. Sie bietet finanziellen Schutz gegen IT- und Cyberrisiken aller Art. Dazu gehören auch eventuelle wirtschaftliche Folgeschäden.

Es entbindet aber nicht vom Einsatz von Cyber-Checkups, Schwachstellen-Scans und Mitarbeiterschulungen, die Risiken von vornherein minimieren.  Zu einem umfassenden Schutz gehören auch Notfall- und Krisenpläne, durch die man für den Ernstfall optimal vorbereitet ist und handlungsfähig bleibt.

Zum Abschluss des Events wurde ebenfalls in der Motorworld ein Carrera-Turnier veranstaltet, wobei im unteren Bereich zwei Bahnen mit jeweils vier Rennwagen aufgebaut wurden. Nach einer kurzen Anleitung und Einlernphase wurden schon die ersten Rennen ausgetragen. Vorsicht: Vollgas geht hier nicht, sonst kommt man schnell aus der Bahn!

Ausklang und die ersten Networking-Schritte

Anschließend hatten wir die Wahl: Zurück zum Hotel oder direkt zur Abendveranstaltung. Keine Frage, für uns ging es selbstverständlich zum Netzwerken und besseren persönlichen Kennenlernen zum Abendevent.

Ich selbst gehörte zu den Jüngeren in der Runde und wurde von den anderen hervorragend aufgenommen. Wir haben alle ein Gespräch auf Augenhöhe geführt. Für mich war alles neu, interessant und perfekt zum Lernen.

Erleichtert wurde das Netzwerken durch die besondere Sitzordnung. Die Tische waren gemischt, Partner und Acronis-Mitarbeitern bunt verteilt. Somit entstand direkt eine entspannte Atmosphäre zum Austausch. Während der Pause zwischen den Gängen habe ich mich sehr gerne mit anderen Teilnehmern und auch den Acronis Mitarbeitern sowohl über deren Unternehmen als auch das Produkt Acronis und seine Vielfältigkeit unterhalten.

Mein Fazit: Gelungener Sprung ins kalte Wasser

Abschließend kann ich nur ein Riesenlob an die Gastgeber und ein herzliches Danke an Acronis mitgeben. Es war überwältigend, informativ und eine großartige Erfahrung. Da ich davor noch nie auf einem Partner Event war, war natürlich alles neu und vieles hat mich positiv überrascht. Ich hatte im Vorfeld zum Beispiel angenommen, dass die Informationen mehr in Richtung Verkauf als technisch gehen würden, wobei sich am Ende das Gegenteil erwies.

Ebenfalls war ich etwas nervös vor dem „Networken“, also das Hingehen und Ansprechen oder angesprochen zu werden. „Worüber kann und darf ich reden?“, habe ich mich anfangs gefragt.  Aber meine Nervosität war unbegründet, es lief viel besser als erwartet und mit jedem Wort habe ich mich wohler und sicherer gefühlt.

Ich habe nun einen besseren und tieferen Einblick in das Acronis-Produkt bekommen sowie die Erfahrung gemacht, sich an einem großen Event persönlich vor Ort mit anderen Menschen zu vernetzen. Vieles war neu für mich, und was ich auf jeden Fall mitgenommen habe, ist diese kurz und knackige Botschaft:

Kein Backup – kein Mitleid!

Die Nacht, in der mein virtueller Server verbrannte

Am Morgen des 10. März fand ich in meinem E-Mail-Postfach Meldungen meines Monitorings aus der Nacht, dass einer meiner Virtual Private Server nicht mehr erreichbar ist. Es dauert einen Moment, bis mir klar wurde, was passiert war. Ein Lehrstück darüber, wie bedeutsam eine feuerfeste Backup-Strategie ist.

Punkt 2:30 Uhr in den frühen Morgenstunden des 10. März teilte mir das Monitoring meines Cloud-Anbieters OVH mit, dass das Virtual Private Server (VPS)-System sich nicht mehr meldete. Als ich die Meldung dann am frühen Morgen wahrgenommen habe, stellte ich fest, dass ich das System tatsächlich nicht mehr erreichen konnte. Eher ungewöhnlich, normalerweise läuft das System ohne Probleme durch. Außerdem konnte ich ein Postfach im Mail-Service bei OVH nicht erreichen, “Connection refused”.

Also in die Web-Oberfläche und den VPS durchstarten. Schon bei der Anmeldung in der Web GUI bei OVH traten seltsame Effekte auf, die Anmeldung hing – alles eher ungewöhnlich. Mit dem Verdacht eines größeren Systemausfalls bin ich mal auf die Suche gegangen. OVH hat verschiedene Status-Seiten in verschiedenen Sprachen: in französischer, englischer, manchmal auch in deutscher Sprache.

Alles nicht wirklich zielführend, bis ich über den Twitter-Account des OVH-Firmengründers stolperte, Octave Klaba. Dort war um 3:42 Uhr etwas zu lesen von einem Major Incident und Feuer im Rechenzentrum SBG2. Dort in Straßburg, wusste ich, lief mein virtueller Server.

Welches Rechenzentrum genau betroffen war, wusste ich nicht. Aber bei den eindrücklichen Bildern vom Ausmaß des Brandes und den Meldungen danach zufolge war das auch ziemlich egal. SBG 2 vollständig zerstört, SBG 1 zu einem Drittel zerstört, SBG 3 und SBG 4 abgeschaltet.

Backup

Backup hatte ich für meinen VPS nicht mitgebucht, sondern auf herkömmlichem Weg mit einem eigenen bewährten Backup-Script auf einen anderen Server gesichert.

Erster Check im eigenen Inventory: Full-Backup vom 1. März, inkrementelle Backups im gleichen Level vom 5. bis zum 9. März, am 10. März hat er keines mehr geschafft, es lief so nach 3 oder 4 Uhr morgens. Wenn das System nicht wieder kommt, dann gibt es wohl fast 24h Datenverlust, auf meinem Spiel-System eher unkritisch.

Daten-Replikation

Aber warum sollte das System nicht wieder kommen? Ein virtueller Server ist erst mal unabhängig vom Blech, auf dem er läuft. Man kann ihn auf jedem Basis-System starten. Wichtig ist die Datenplatte vom System. Die VPS bei OVH wurden beworben mit CEPH-Storage und dreifacher Replikation als ich sie damals gebucht hatte.

Dreifache Replikation klingt super. Die Frage ist: wo stehen die Knoten? Dazu hatte ich keine weiteren Informationen. Den Ausfall meines Spiel- und Bastel-Servers für ein paar Tage konnte ich problemlos verkraften, aber wann sollte ich mit der Wiederherstellung starten? Eigentlich hatte ich auf einen Restore aus dem Backup keine Lust. Darum entschied ich zu warten, bis zu einer endgültigen Klärung, was mit meinen Daten passiert ist.

Nachdem OVH seine eigene Infrastruktur und Web GUI wieder am Laufen hatte, konnte ich feststellen, dass mein System im Cluster 001 os-sbg1-002 laufen sollte, mit der Lokalisation SBG1. Gut, nach meinen aktuellen Informationen war ich dann bei einer Wahrscheinlichkeit von 2/3, dass mein System überlebt hat. Unter der Voraussetzung, dass CEPH-Knoten nicht im gleichen Raum standen, eher sogar noch etwas höher.

Alles verbrannt

Am 12. März kam allerdings die ernüchternde Mitteilung, dass os-sbg1 in Wirklichkeit in SBG2 stand und vollständig verbrannt ist. Nachdem der Totalverlust nun feststand und OVH ein paar Monate Gutschrift bei Neubestellung anbot, habe ich dann das System auf einem vergleichbaren VPS im Rechenzentrum in Gravelines restauriert.

Wie jedes Mal ist das wirkliche Zurückspielen eines vollständiges Backups mit einem gewissen Nervenkitzel verbunden. Erst mal die Keys zur Verschlüsselung heraussuchen, Backup entschlüsseln. Den neuen VServer im Rescue-System starten, Platte vorbereiten und über das Netz restaurieren. IPv4 wurde dynamisch zugewiesen, IPv6 wurde statisch hinterlegt, also das schnell gerade ziehen. Bootloader installieren und aktivieren und dann das System starten. Voilà! Das System ist wieder erreichbar. Im DNS die IP-Adressen korrigieren, die CNAMES ziehen dann automatisch hinterher und schon ist das System für alle Dienste wieder erreichbar.

Am nächsten Morgen noch sicherstellen, dass auch das Backup wieder gelaufen ist und dann kann man das System wieder vor sich hin laufen lassen.

Katastrophenfall-Wiederherstellung

Welche Erkenntnisse lassen sich nun aus diesem kleinen Lehrstück ziehen?

Seit vielen Jahren zitiere ich die Weisheit “Keiner will Backup, alle wollen Restore” in den Diskussionen zum Backup.

Disaster Recovery oder K-Fall-Wiederherstellung sind Dinge, die man auch für die lokale Infrastruktur immer im Hinterkopf halten muss. Feuer und (Lösch-)Wasser sind keine guten Freunde von Servern. Hier ist im Falle eines Falles immer mit Totalverlusten zu rechnen. Auf einer gewissen Flughöhe sind die CPU und der Speicher völlig egal, die lassen sich zeitnah wieder beschaffen. OVH war hier in der Lage, 10.000 neue Server in wenigen Tagen in Gravelines neu bereitzustellen.

Wichtiger sind die Daten. Hier hilft es nichts, wenn alle redundanten Storage-Knoten gemeinsam zerstört werden. Wenn, dann sollten diese Systeme schon in unterschiedlichen Brandabschnitten stehen. Und Backups sollten zudem auch außerhalb in ganz anderen Umgebungen gelagert werden. Entsprechend gesichert verwahrt, und am besten noch verschlüsselt auf den Medien. Aber auch die Entschlüsselung der Backups muss noch funktionieren, wenn die komplette Sicherungseinheit unbenutzbar wurde, d.h. der Key muss ebenfalls außerhalb gesichert sein.

Der Preis von verlorenen Daten

Verlorene Daten sind in der Regel heute auch nicht durch Geld zu ersetzen. Der Umfang der heute verarbeiteten Daten ist einfach so groß, dass wir nicht mehr darüber reden, dass einige Datentypistinnen die Papier-Bestellscheine des Tages erneut abtippen. Es geht um umfangreiche Datenbestände, die sich in den meisten Fällen nicht einfach so wieder rekonstruieren lassen. “Bitte alle Bestellungen vom 10. März noch mal ausführen” ist eine eher hoffnungslose Bitte an… ja, an wen denn?

Spezial-Appliances

Anders als bei den “normalen” Rechnern ist es bei Spezial-Appliances wie beispielsweise Firewalls oder Proxy-Systemen. Hier ist in der Regel die Beschaffung der Ersatz-Geräte selbst noch ein mögliches Problem, neben der vollständigen Sicherung von Konfiguration und auch hier Keys für die Verschlüsselung. Darum sollten auch hier die Cluster-Knoten oder redundanten Systeme in verschiedenen Brandabschnitten installiert sein. Brennt ein Rechenzentrum aus, kann das andere zumindest im K-Fall übernehmen.

Bleibt noch das Thema mit der Internet-Anbindung. Oftmals gibt es hier nur einen Übergabe-Punkt, sodass auch in einem Rechenzentrum die primäre Einführung existiert. In der Regel lässt sich hier aber die Ersatzleitung in das zweite Rechenzentrum legen, wenn das Gelände betreten werden darf. Alternativ können auch LTE-Ersatzleitungen mit dem Carrier verhandelt werden. Aber das ist deutlich schneller zu realisieren als alle Appliances neu zu beschaffen.

Was bietet die Cloud?

Während die lokalen Gegebenheiten sich relativ gut überschauen und verstehen lassen, und somit auch sehr einfach K-Fall-Szenarien beschreiben lassen, ist das in der Cloud  ungleich schwerer. In der Regel kann man davon ausgehen, dass der Cloud-Anbieter sich über seine AGB und TOS weitestgehend aus allen Haftungen herausnehmen wird. In den gängigen Cloud-Umgebungen für Infrastucture as a Service (IaaS), also der Miete von Virtuellen Maschinen und Storage zur freien Verwendung, liegt das Backup in der Regel in der Verantwortung des Kunden. Manchmal werden Snapshots angeboten, die ersetzen aber in der Regel kein Backup.

Bei SaaS-Services gibt es manchmal ein rudimentäres Backup des Anbieters, oder mittlerweile viel häufiger Schnittstellen, an denen die gängigen Backup-Tools andocken können, um eine Datensicherung auch in eigener Verantwortung durchzuführen. Und in der Regel ist nicht das Backup die Herausforderung: Die granulare Wiederherstellung ist in vielfach die eigentliche Herausforderung, für die es spezielle Tools braucht.

Verfügbarkeits-Modellierung in der Cloud

Für Cloud-Rechenzentren gibt es weitere Herausforderungen. Bei AWS muss man auch mal virtuelle Maschinen durchstarten, um sie auf eine andere Hardware umzuziehen, weil Amazon an der ursprünglichen Hardware Wartung durchführen möchte.

Bei Azure ist es beispielsweise so, dass die Redundanz in Availibility Zones und Availability Sets beschrieben ist. Jede Availability Zone besteht aus mindestens einem Rechenzentrum, dessen Stromversorgung, Kühlung und Netzwerkbetrieb unabhängig funktionieren. Die Availability Sets hingegen sind nur unabhängige Server, Speicher und Netzwerk-Komponenten in einem gemeinsamen Rechenzentrum.

Azure in Deutschland bietet heute noch keine Availablity Zones. Wer diese benötigt, muss nach Azure Europe West, also Amsterdam, gehen. Hier zeigt sich, dass der Wechsel in die Cloud im Detail komplizierter ist, als es auf den ersten Blick scheint.

Kosten für Sicherheit

Und hier ist dann die Betrachtung wichtig, woher man kommt: verglichen mit dem Server-Schrank in der Besenkammer ist die Cloud vermutlich besser gesichert. Wer aber schon aus einem gewissen verfügbar modellierten Setup mit getrennten Server-Räumen auf dem eigenen Firmengelände kommt, muss darauf achten, dass er sich in der Verfügbarkeit nicht schlechter stellt als bisher. Und diese verbesserte Verfügbarkeit lassen sich die Cloudanbieter in der Regel bezahlen. Genauso wie alle anderen Themen. Wer schon mal im Calculator bei Azure versucht hat, eine Schätzung für seine Backup-Kosten bei Microsoft zu ermitteln, kann das vermutlich nachvollziehen.

Notfallplanung

Wichtig für alle Verantwortlichen ist tatsächlich, sich über die Risiken und die Auswirkungen von Ausfällen und Zerstörungen klar zu werden. Das kann strukturiert in einem Tool zur Notfallplanung passieren, dass kann auch mit der Hand am Arm in einem Wiki passieren. Wichtig ist nur die Betrachtung, ob nach einem K-Fall diese Dokumentation noch zugreifbar ist. Nicht zu vergessen sind auch regelmäßige Tests für die Wiederherstellung von Systemen. Nichts ist fataler als ein Backup, dass sich nicht restaurieren lässt.

Zum Autor

Oliver Paukstadt
IT-Security Consultant und IT-Architekt

IT-Basics: Wie viele IPv4-Adressen gibt es?

Wir kommunizieren jeden Tag über das Internet und tauschen Daten untereinander aus, aber wie genau erfolgt die Adressierung dieser Daten? Dafür brauchen wir erst mal das Grundverständnis über die Adressen und deren Herkunft. In diesem Beitrag möchte ich daher auf den Aufbau und die Struktur von IPv4-Adressen eingehen.

Jeden Tag werden Millionen von Nachrichten über das Internet Protokoll Version 4 (IPv4) im Internet verschickt. Adressen sehen wie folgt aus 127.0.0.1.

Schreibweise	Beispiel-Adresse
Binär/Dual	0111 1111	0000 0000	0000 0000	0000 0001
Hexadezimal	7F	00	00	01
Dezimal	127	0	0	1

Zur Dimensionierung:

8 Bit = 1 Byte
1024 bytes = 1 Kilobyte (KB)
1024 KB = 1 Megabyte (MB)
1024 MB = 1 Gigabyte (GB)
usw.

IPv4 benutzt 32-Bit-Adressen bzw. ist 4 Byte (32 Bit) groß. Zur besseren Lesbarkeit werden die 32 Bit einer IPv4-Adresse in jeweils 8 Bit (1 Byte) Blöcken durch ein Punkt voneinander getrennt aufgeteilt. Die binäre IPv4-Adresse 01111111.0000000.00000000.00000001 ergibt die IPv4-Adresse (127.0.0.1).

	Netzadressen	Hostadresse	Netzklasse	Subnetzmaske	CIDR-Suffix
IPv4-Adresse	xxx	.yyy.yyy.yyy	A	255.0.0.0	/8
Subnetzmaske	255	.0.0.0
IPv4-Adresse	xxx.xxx	.yyy.yyy	B	255.255.0.0	/16
Subnetzmaske	255.255.	.0.0
IPv4-Adresse	xxx.xxx.xxx	.yyy	C	255.255.255.0	/24
Subnetzmaske	255.255.255	.0

Struktur im IPv4-Adressraum

Der IPv4-Adressraum umfasst 32 Bit und reicht von 0.0.0.0 bis 255.255.255.255. Um die Anzahl der 32-Bit-Adressen zu errechnen, muss man 2^32 Adressen nehmen = 4.294.967.296  IPv4 Adressen.

Beispielsweise hat man bei einem /24 Netz nur noch 8 Bit von 32 Bit übrig. Das sind dann 2^8 Adressen, also 256 IPv4 Adressen. Dann wird noch 1x Netzadresse und 1x Broadcastadrese abgezogen. So erhält man 254 verfügbare Adressen.

Vergabe von IPv4-Adressen

Für die Vergabe von IP-Netzen im Internet war zunächst die Internet Assigned Numbers Authority (IANA) zuständig. Heute übernimmt diesen Job die Internet Corporation for Assigned Namens and Numbers (ICANN). Diese vergibt die Adress-Blöcke an fünf regionale Vergabestellen (RIR – Regional Internet Registry):

• AfriNIC (African Network Information Centre) = zuständig für Afrika
• APNIC (Asia Pacific Network Information Centre) = zuständig für die Region Asien-Pazifik
• ARIN (American Registry for Internet Numbers) = Nordamerika
• LACNIC (Latin-American and Caribbean Network Information Centre) = Lateinamerika und Karibik
• RIPE NCC (Réseaux IP Européens Network Coordination Centre) = Europa, Naher Osten, Zentralasien

In Gebieten mit unterversorgten IPv4-Adressen, ist man sogar darauf angewiesen, dass IPv6-Adressen eingeführt werden.

Ende 2019 teilte die europäische IP-Adressverwaltung Réseaux IP Européens (RIPE) mit, dass das europäische Reservoire an IPv4-Adressen erschöpft ist. Wenn man heute also Bedarf an einer IPv4-Adresse hat, muss erst ein Anderer diese Adresse abtreten. RIPE hat für diesen Fall eine Warteliste eingerichtet, fordert aber zeitgleich nun mehr Engagement bei der Einführung von IPv6. Das IPv6 ist für ein Netz von 21^28 ≈ 340 Sextillionen Adressen ausgelegt.

YubiKey: Authentifizierungsmethoden unter Windows

Wer kennt es nicht, sicheres Anmelden kann manchmal ein zähes Thema sein. Beim Öffnen des Passwortmanagers, um das eigentliche Passwort zu kopieren und einzufügen sowie danach den zweiten Faktor einzugeben, vergeht gefühlt eine halbe Ewigkeit. Hier möchte der YubiKey von Yubico Abhilfe schaffen.

Der YubiKey unterstützt verschiedenste Authentifizierungsmethoden wie z.B. Windows-Anmeldungen und OAUTH, welches unter anderem vom Google Authenticator genutzt wird, oder das von unserem Kollegen beschriebene FIDO2.

In diesem Blogbeitrag gehe ich nur auf die Windows-Funktionen des YubiKey ein, welche aber nur einen kleinen Teil der eigentlichen Funktionen ausmachen.

YubiKey und Windows Hello

Windows Hello ist, im Gegensatz zur früher benutzten msgina.dll (oder aktuell Credential Providers), nicht für Windows-Systemstartkomponenten verantwortlich, sondern für sichere Anmeldemethoden im Allgemeinen. Beispiele hierfür sind Anmeldungen mittels Biometrie oder das Benutzen von FIDO2-Anmeldungen im Microsoft Edge-Browser. Yubico nutzt diese Schnittstelle:

Mit der YubiKey 4 Series und der Windows Hello App ist es möglich jedes Windows 10-Benutzerkonto auf Knopfdruck, sicher und ohne Passwort, zu entsperren. YubiKeys können über diese Methode ausschließlich zum Entsperren genutzt werden. Die Voraussetzung dafür ist, dass man sich mindestens einmal seit dem letzten Start des Windows 10-Gerätes, mit Nutzername und Passwort eingeloggt hat. Das Einloggen mit Benutzername und Passwort kann durch den YubiKey nicht ersetzt werden.

Um den YubiKey für diese Funktion zu nutzen, muss zuerst die „YubiKey for Windows Hello“ aus dem Microsoft Store bezogen werden. Mit dieser können bis zu fünf YubiKeys für ein Benutzerkonto registriert werden. Nach dem Registrieren des YubiKeys, ist dieser direkt einsatzbereit.

Da Windows diese Funktion von Windows Hello ab 1. November 2019 nicht mehr unterstützt, wird vermutlich ab diesem Tag die „YubiKey for Windows Hello“ ebenso nicht mehr verfügbar sein. Außerdem hat Yubico angekündigt, dass aus dem gleichen Grund diese Funktion nicht für die YubiKey 5 Series verfügbar sein wird.

YubiKey und Windows Anmeldungen

Einen Trost bietet die von Yubico verwiesene Alternative „Windows Logon Tool“ nicht. Diese richtet einen YubiKey als zweiten Faktor bei einer Windows-Anmeldung ein. An sich ist das ein großer Sicherheitsgewinn. Dies funktioniert aber nur bei lokalen Benutzerkonten. Cloud- oder Domänenkonten werden nicht unterstützt. Abgesehen davon ist diese Funktion ebenso abgekündigt.

Die letzte und auch noch unterstützte Alternative ist die Smartcard-Funktion des YubiKeys. Damit kann sich ohne Eingeben des Benutzerpasswortes mit einem Benutzer angemeldet werden. Smartcards werden nur für Benutzer in einer Windows-Domäne unterstützt.

Das Konstrukt basiert auf dem Besitz der Smartcard (bzw. in diesem Fall des YubiKeys), dem darauf befindlichen Zertifikat, welches der Windows-Domäne bekannt ist und einem Passcode, welcher ausschließlich dem Benutzer bekannt ist.

Wie installiere ich meinen eigenen DNS-Resolver?

In diesem Beitrag möchte ich zeigen, wie Sie einen eigenen DNS-Resolver innerhalb von wenigen Minuten installieren und konfigurieren können.

Die Voraussetzungen hierbei sind ziemlich übersichtlich:

• Ein System auf dem eine Linux-Distribution installiert werden kann
• Eine IT-Infrastruktur die DNS-Anfragen vom DNS-Resolver an die DNS-Root-Server und
• Anfragen von intern an den an den neuen DNS-Resolver erlaubt

In diesem Beispiel wurde das Open Source-Paket Unbound auf einem Debian Server installiert.

Grundsätzlich ist Unbound mit fast jeder Linux-Distribution kompatibel. Die einzelnen Befehle können jedoch abweichen.

Was ein Resolving Name Server / DNS-Resolver ist und wie eine DNS-Abfrage funktioniert, hat unser Kollege im Beitrag Was ist eigentlich DNS? beschrieben.

Installation und Tests

Als erstes benötigen Sie ein System, auf dem Sie den DNS-Resolver installieren möchten. Hierzu empfiehlt sich eine virtuelle Maschine oder eine kleine bzw. alte Hardware-Appliance mit einem Linux-Betriebssystem. Das System ist optimalerweise neu installiert und besitzt keine weiteren Dienste, die angeboten werden.

In diesem Beispiel wird ein Debian Server in einer virtuellen Maschine benutzt.

Für die meisten Befehle in dieser Anleitung werden administrative Rechte benötigt. Deswegen wird nach der Installation und dem erfolgreichen Start des Systems als erstes mit folgendem Befehl zum Benutzer „root“ gewechselt:

su

Nachfolgend wird Unbound, wie jedes andere Paket in Debian, mit folgendem Befehl installiert:

apt install unbound

Der DNS-Resolver ist bereits lokal auf dem soeben installierten System einsatzbereit. Dies kann mit folgendem Befehl getestet werden:

dig @127.0.0.1 to.com

Mit diesem Befehl wird eine DNS-Suchanfrage nach „to.com“ an localhost gesendet. Wenn die Antwort etwa so aussieht, war die Anfrage erfolgreich:

; <<>> DiG 9.11.3-1ubuntu1.3-Ubuntu <<>> @127.0.0.1 to.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60087
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx (good)
;; QUESTION SECTION:
;to.com.                      IN      A ;; ANSWER SECTION: to.com.           300     IN      A       195.34.188.30

;; AUTHORITY SECTION:
to.com.            172799  IN      NS      b.ns14.net.
to.com.            172799  IN      NS      d.ns14.net.
to.com.            172799  IN      NS      a.ns14.net.
to.com.            172799  IN      NS      c.ns14.net.

;; Query time: 2009 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Feb 20 15:17:49 CET 2019
;; MSG SIZE  rcvd: 151

Unter dem Abschnitt „Answer Section“ kann man nun sehen, dass eine Antwort in Form einer IP-Adresse erfolgreich war.

Damit nun auch andere PCs und Server aus dem Netzwerk den DNS-Resolver benutzen können, muss noch etwas an der Konfiguration von Unbound geändert werden.

Als erstes benötigen wir die IP-Adresse, mit dem der DNS-Resolver mit dem Netzwerk verbunden ist bzw. die IP-Adresse des Interfaces, auf dem DNS-Anfragen in Zukunft beantwortet werden sollen. Die IP-Adressen werden mit folgendem Befehl angezeigt:

ip a

Nachdem Sie sich die IP-Adresse gemerkt oder notiert haben, öffnen Sie mit einem Texteditor Ihrer Wahl die Konfigurationsdatei von Unbound:

nano /etc/unbound/unbound.conf

Nun müssen folgende Zeilen hinzugefügt werden. Bitte passen Sie die fett markierten Werte vor dem Hinzufügen in die Konfigurationsdatei an Ihre IT-Infrastruktur an.

server:
access-control: 192.168.0.0/24
allow interface: 192.168.0.136
interface: 127.0.0.1

Mit dem Parameter „access-control“ werden die Netze bestimmt, von denen Unbound DNS-Anfragen beantworten wird. Mehrere Netze können mit einer zweiten „access-control“ Zeile bestimmt werden (siehe „interface“).

Mit dem Parameter „interface“ wird bestimmt, auf welchem Interface Unbound DNS-Anfragen beantwortet.

Damit die Änderungen gültig werden, muss der Unbound-Dienst neu gestartet werden:

service unbound restart

Falls auf dem Betriebssystem, auf dem Unbound betrieben wird, eine Firewall aktiv ist, ist nun der Zeitpunkt gekommen diese so anzupassen, dass DNS-Anfragen (Port 22) aus dem internen Netz angenommen werden und Unbound DNS-Anfragen an die DNS-Root-Server stellen darf.

Nun können auch andere PCs oder Server den DNS-Server benutzen.
Dies kann mit folgendem Befehl getestet werden:

dig @192.168.0.136 to.com

Der Test war erfolgreich, wenn die Antwort so wie im vorherigen Test aussieht. Damit ist die Installation des eigenen DNS-Resolvers erfolgreich abgeschlossen.

Zum Autor

Anonym

Das (monatl.) 65 Euro Rechenzentrum

Was als kleine Spielwiese zum Testen begonnen hat, ist mittlerweile zu einem virtuellen „Privat Büro“ mit mehreren Remote-Desktops, Wiki und einer Cloud herangewachsen, das ich hier gerne vorstellen möchte.

Als Ausgangslage dient ein Root Server von Hetzner:

Intel® Core™ i7-6700 Quad-Core inkl. Hyper-Threading-Technologie

64 GB DDR4 RAM

2 x 500 GB SATA 6 Gb/s SSD

Kosten pro Monat: 65 Euro

incl. 3 IPs

Betrieben wird er mit der freien Version von vmware ESXi (6.5) als Grundlage für das Rechenzentrum.

Ich habe zwei getrennte Netze, die jeweils von einer Sophos UTM und einer Sophos XG geschützt werden:

Somit sind zwei meiner drei IPs belegt, die dritte dient zum Steuern des ESXi Servers und ist auch gleichzeitig die physikalische IP, da der Hetzner Server nur eine Netzwerkkarte sein Eigen nennt.

Die internen Netze teilen sich wie folgt auf:

„Intranet“, durch die Sophos UTM geschützt

„DMZ“, durch die Sophos XG geschützt

„Transfer“, damit die Netze sich auch ein bisschen unterhalten können. Durch gewisse Eigenheiten des Hetzner Netzwerkes ist dies leider über die öffentlichen IPs meiner Netze nicht möglich.

Verteilt ist das alles über zwei Data Stores, die ich aus Kostengründen einzeln und nicht im Hardware Raid benutze. Ein Software Raid ist mit dem ESXi Server nicht möglich. Somit steht nun die Basis für allerlei Spielereien.

„What’s inside the box?“

Nun, was ist denn drin…

Ein Win 10 Desktop mit einem RDS Zugang, dafür braucht man:

1x Windows 2016 Server als AD

1x Windows 2016 Server als RDS Server

1x Windows 10 Professional als Desktop

Zwei Linux Desktops mit Zugang über einen NoMachine Cloud Server, dafür braucht man:

1x Linux Ubuntu 18.04 Mate + NoMachine Enterprise Terminal Server

1x Linux Ubuntu 16.04 Mate + NoMachine Enterprise Terminal Server

1x Linux Ubuntu 18.04 Server+ NoMachine Cloud Server

Die Geschichte mit NoMachine ist eigentlich ein Blog für sich, darum werde ich hier nicht im Detail darauf eingehen. Wer sich für NoMachine interessiert, kann hier nachlesen: https://www.nomachine.com/

Hier ein kleiner Ausschnitt aus der NoMachine Cloud Server Beschreibung:

„Die Cloud Server Familie verbindet sicheren, zentralisierten Fernzugriff mit zuverlässiger Desktop-Leistung. Durch den umfassenden und effizienten Zugriff auf PCs und Macs ermöglicht es Enterprise Desktop, dass Mitarbeiter und Selbstständige von jedem Ort aus produktiv arbeiten können. Darüber hinaus kann Cloud Server den Zugriff für Benutzer durch die Zentralisierung des Zugangspunkt vereinfachen und bietet eine vereinheitlichte Zugriffsverwaltung für Administratoren, unabhängig davon, ob Ihre Ressourcen vor Ort oder über Netzwerke verteilt sind.“

Somit sind mal die drei Remote Desktops „inside the box“ versorgt. Um munter Dateien, Bilder, Filme etc. aus allen möglichen Himmelsrichtungen verschieben zu können, braucht es natürlich auch eine „Cloud“. Alles ist besser mit einer Cloud.. ;-), dafür braucht man:

1x Linux Ubuntu 18.04 mit „Nextcloud“ als Cloud Lösung.

Um alle möglichen Webseiten hosten zu können, benutze ich „Plesk“. Manch einer mag darüber die Nase rümpfen, aber:

a.) die Lizenz dafür war im Hetzner Hosting Paket enthalten,
b.) ich habe keine Lust mich auch noch mit den Widrigkeiten eines LAMP Servers auseinanderzusetzen.

Momentan ist es mit einem simplen Wiki für Dokumentationen befüllt. Ja, mit Kanonen schießt man auf Spatzen. Zum Schießen braucht man:

1x Linux CentOS 7 + Plesk

So, es haben sich ja mittlerweile viele virtuelle Rechner angesammelt und alle bestehen sie auf Updates. Eine Menge Arbeit… Um den Update-Terror zu minimieren, benutze ich „Desktop Central“ von Manage Engine. Ich zitiere mal aus der Homepage von Manage Engine:
„Desktop Central is a unified endpoint management solution that helps in managing servers, laptops, desktops, smartphones, and tablets from a central location.“

Dieses nützliche Stück Software lebt auf meinem Windows 2016 RDS Server und nimmt mir weitestgehend die Update-Arbeit der Rechner vollautomatisch ab.

Ich sollte hier noch erwähnen, dass Verfügbarkeit in diesem Scenario für mich absolut keine Priorität hat. Es funktioniert oder nicht. Es gibt auch kein Backup. Die ganzen Maschinen auch noch auf ihre Vitalwerte zu überwachen, würde für mich schlicht und einfach den zeitlichen Rahmen sprengen.

Was uns zum nächsten Thema führt…

Sicherheit

Da dieses Setup aus dem Internet erreichbar ist, gibt es hier, so gut wie es geht, keine Kompromisse. Einen Pentest unseres Security Teams aus dem Internet verlief für den Tester erfolglos. Die erreichbaren Ports aus dem Internet sind SSH und HTTP/HTTPS. Alle HTTP/HTTPS Zugänge sind über die Sophos WAF gesichert, der SSH Zugang ist nur über 2nd Auth möglich. Durch die schon genannte „Desktop Central“ Lösung werden OS Updates zeitnah aufgespielt. Eine kleine Ausnahme bildet der Administrationszugang zu meinem ESXi Server. Man würde einen ESXi Server in Produktion nie direkt ans Netz hängen, aber weil ich mir keinen zweiten Hetzner Server leisten will, der die Sicherung übernimmt, muss in diesem Fall eine Beschränkung der IP-Adressen, die für die Administration zulässig sind, ausreichen. Zusätzlich sind alle(!) Accounts über eine 2nd Auth Authentifizierung gesichert. Dazu benutze ich DUO Security (part of Cisco) das für Privatanwender seine Dienste kostenlos zur Verfügung stellt. Zudem bietet es zusätzlich noch einen AUTH PUSH Service an. Einbinden kann man das ganze unter Linux mit PAM und den entsprechenden DUO Security libs, oder als Anwendungsprogramm unter Windows, das in meinem Fall die 2nd Auth Authentifizierung für meinen RDS Server übernimmt.

Nun zu der Frage: Was kann ich eigentlich damit machen? Das Ganze dient schlicht und ergreifend dazu von jedem beliebigem Rechner, der einen Internet Zugriff über HTTPS oder SSH ermöglicht, sein eigenes virtuelles Büro + privaten File Cloud Server sicher zu erreichen. Zur Auswahl steht sowohl ein Linux wie auch ein Windows Desktop zur Verfügung. Wenn man will und kann, ist das ganze Netzwerk natürlich auch noch über VPN erreichbar.

So, das war es im Großen und Ganzen. Warum ich das mache? Richtig, weil ich es kann. Nein, ernsthaft, es ist für mich eine nette Spielwiese, um alle möglichen „virtuelles Büro“ Szenarien „durchzuspielen“, mehr nicht.

Zum Autor

Anonym

Wozu ein ISMS? – 4 Gründe für ein Information-Security-Management-System

Ob ein Unternehmen klein oder groß ist, macht keinen Unterschied bezüglich des übergeordneten Ziels und der Wichtigkeit eines ISMS. Es unterscheidet sich lediglich die Ausführung des jeweiligen ISMS, da die finanziellen und personellen Möglichkeiten ganz andere sind.

Ich habe 4 Gründe gesucht und gefunden, warum sich die Einführung eines Information-Security-Managements-Systems für Unternehmen, egal welcher Größe, lohnt.

Zuallererst: Was ist ein ISMS?

„Ein Information Security Management System (ISMS) definiert Regeln und Methoden, um die Informationssicherheit in einem Unternehmen oder in einer Organisation zu gewährleisten. Das ISMS ist prozessorientiert und verfolgt einen Top-Down-Ansatz ausgehend von der Unternehmensführung.“

– Security-Insider.de

Anhand dieser Definition wird bereits klar, dass es sich bei einem ISMS gar nicht um ein technisches System handelt. Ebenso lässt sich erkennen, dass der Einsatz eines ISMS bei der Geschäftsführung startet, nicht bei der IT.

Ein ISMS ist also ein System, das nicht technisch ist und auf Prozessen aufbaut. Und was ist ein Prozess? „Ein Prozess ist über eine gewisse Zeit sich erstreckender Vorgang, bei dem etwas entsteht oder abläuft.“

Wozu aber braucht es nun ein solches System?

Grund 1: Daten brauchen Schutz

Bei der Implementierung eines ISMS entstehen Dokumente und technische Verfahren, die alle einen Zweck haben: die Sicherheit Ihrer Informationen. Denn der Schutz aller Daten ist nicht nur Aufgabe des externen Datenschutzes, sondern auch der IT-Informationssicherheit.
Kurz gesagt: Nicht nur die Kundendaten, sondern auch interne Daten, wie Personaldaten, Informationen von und über technische Systeme sowie Datenbanken müssen hinsichtlich des Schutzes in Betracht gezogen werden.
Besonders Datenbanken sind kritische Systeme, die einen hohen Wert für viele Unternehmen haben.

Einen Hinweis auf die Wichtigkeit von Daten und deren Schutz bietet auch die weite Verbreitung des Begriffs „Data-Breach“. Bei diesem Angriff verschaffen sich Hacker unter anderem Zugang zu Firmendatenbanken und verteilen bzw. verkaufen die erbeuteten Daten in die weite Welt. Ihre Daten besitzen also nicht nur für Sie selbst einen großen Wert.

Grund 2: Ihre Investitionen sind jederzeit planbar

Zuzüglich zum prozessorientierten ISMS kann man natürlich ein elektronisches Tool zur Unterstützung der Prozesse einführen. Dies hilft vor allem der Geschäftsführung, Einsicht in das Projekt zu haben und die Maßnahmenumsetzung zu verfolgen. Die Berichterstattung ermöglicht es auch Prioritäten zu setzen und entsprechend die nötigen Investitionen zu planen und freizugeben.

Grund 3: Sie bauen Ihren Wettbewerbsvorteil aus

Ein weiterer Vorteil der Einführung eines ISMS ist der entstehende Wettbewerbsvorteil. Einem Unternehmen, das seine Nachhaltigkeit und Daten schützt, wird in der Regel eher vertraut, als einem, das dies nicht tut. Heutzutage ist die IT und deren Sicherheit nicht nur eine geschäftsunterstützende Abteilung, sondern auch ein strategischer Hebel, mit dem die Geschäftsführung die Entwicklung des Unternehmens steuern kann.

Ebenso wird im Bereich Einkauf immer öfter darauf bestanden, dass Lieferanten ein bestimmtes Niveau an IT-Informationssicherheit nachweisen können. Dies steht als einer der Grundsätze in der ISO-Zertifizierung 27001 (Siehe Lieferantenbeziehungen). Wer vorweisen kann, dass Informationssicherheitsmaßnahmen umgesetzt werden, hat seine Zukunft zum Teil schon gesichert.

Grund 4: Sie können Compliance-Richtlinien einhalten

Zuletzt ist die Compliance ein wichtiges Thema, da Nachweisbarkeit gegenüber Ämtern und Kunden vorhanden sein muss. Auch hierbei unterstützt ein ISMS. Die Vielfalt der Anforderungen kann für ein kleines Unternehmen, bzw. für nur eine Person (GF) überwältigend sein; daher empfehlen wir Spezialisten hinzuzuziehen, die sich mit den rechtlichen Vorgaben auskennen.

Fazit

Warum es wichtig ist, ein ISMS einzuführen, ist nun also klar.
Natürlich sollte man es nicht übertreiben. Jedes ISMS kann an die Größe und die Anforderungen eines Unternehmens angepasst werden, ansonsten wäre es überhaupt nicht tragbar. Etwas zu tun ist grundsätzlich besser als nichts zu tun, solange der Aufwand realistisch bleibt und sich lohnt. Auch für KMUs ist es sehr wichtig, das Thema IT-Sicherheit in den Alltag zu bringen, da ansonsten die Nachhaltigkeit des Unternehmens heutzutage nicht mehr gewährleistet ist.

Der allerwichtigste Bestandteil eines ISMS ist die Initiierung und die Unterstützung durch die Geschäftsführung. Natürlich können Geschäftsführer das Thema IT-Sicherheit auch ignorieren, nur wie lange geht das gut?

Bei Bedarf unterstützen wir Ihr Unternehmen dabei, Ihre IT-Sicherheit auf Vordermann zu bringen und eventuell ein ISMS einzuführen. Um dieses Ziel zu erreichen, setzen wir auf unsere Erfahrung und organisatorischen Kenntnisse der IT-Sicherheit sowie auf gewählte Partner für ISMS-Tools. Kontaktieren Sie uns!

Zum Autor

Daniela (ehemalige Mitarbeiterin)

History of Hacks – Adrian Lamo hackt die New York Times

Im Jahr 2002 hackt Adrian Lamo, auch bekannt als Homeless Hacker, die New York Times. Wie und wieso erkläre ich in diesem Blog-Beitrag der Serie „History of Hacks“.

Der Hacker: Adrian Lamo

Adrian Lamo wurde am 20. Februar 1981 in Boston, Massachusetts geboren. Während seiner Kindheit zog er oft mit seinen Eltern um, bevor sie sich schlussendlich in Washington D.C. niederließen. Sein Vater arbeitete als Übersetzer und Kinderbuchautor, die Mutter war Englischlehrerin.
Zum ersten Mal in Kontakt mit Computern kam Lamo als er 7 Jahre alt war in Form von Computerspielen auf dem C64 seines Vaters. Später vertrat er die Meinung, dass es sich mit Computern, wie mit Fremdsprachen verhielt: je eher man mit ihnen in Kontakt käme, umso leichter seien sie zu lernen. (Quelle: Wikipedia)

Seinen Spitznamen „Homeless Hacker“ (deutsch: Obdachloser Hacker) bekam er von seiner Lebensart: Lamo hatte lange keinen festen Wohnsitz. Er übernachtete entweder in verlassenen Gebäuden oder in den Wohnungen von Freunden.

In dieser Zeit hatte er Spaß daran Sicherheitslücken in der IT von Unternehmen zu finden und zu veröffentlichen. Dies sah er selbst weder als gut noch als böse an. Durch seine Vorgehensweise stand er in Kritik die Aufmerksamkeit der Öffentlichkeit zu suchen und keine tiefergehenden Kenntnisse bzw. Hacker-Fähigkeiten zu besitzen.

Der Hack

Lamos Standard-Vorgehensweise war es über die Websites von Unternehmen Schwachstellen bzw. Fehlkonfigurationen der Proxy-Server zu suchen und diese auszunutzen. Mit dieser Methode hatte er auch Erfolg auf der Website der New York Times. Er sendete Test-Mails an den Auto-Responder der Zeitschrift, probierte diverse IP-Adressen aus und stieß letzendlich auf eine Seite, die neben anderen Dinge, eine Datenbank mit Informationen über Gastautoren enthielt. Darunter Schauspieler wie Robert Redford oder auch den ehemaligen Chef der NSA Bobby Inman. Die Datenbank enthielt unter anderem Telefonnummern und Adressen.

Nachdem er sich ein bisschen „umgeschaut“ hatte, ergänzte er sich selber in der Liste mit vollem Namen und seiner Telefonnummer. Im Feld „Kenntnisse“ gab er  „computer hacking, national security, communications intelligence“ an. Als er fertig war, rief er Kevin Poulsen an, zu dieser Zeit Reporter bei SecurityFocus.com, der, um die Geschichte zu verifizieren, die New York Times kontaktierte.

Die New York Times schaltete die Staatsanwaltschaft ein, die herausfand, dass Lamo sich nicht nur selbst als Autor und Experte angelegt hatte, sondern sich über verschiedene Passwörter Zugang zu einem Account der New York Times bei Lexis-Nexis verschafft hatte. Lexis-Nexis ist einer der weltweit größten Anbieter professioneller Datenbank-Zugänge. Lamos‘ Suche in den Zeitungsarchiven bei Lexis-Nexis war allerdings kostenpflichtig. Laut New York Times recherchierte Lamo auf Kosten der Zeitung für 300.000 Dollar.

Die Strafe

Für seine Taten wurde Adrian Lamo 2004 zu sechs Monaten Hausarrest, zwei Jahre auf Bewährung und einer Geldstrafe von 65.000 US Dollar verurteilt.

Heute

Richtig bekannt wurde Lamo allerdings durch eine andere Sache: Im Jahr 2010 lernte Lamo Chelsea Manning kennen. Als er von ihr erfuhr, dass sie geheime Aufnahmen veröffentlicht hatte, meldete er sie dem FBI. Dies führte später auch zu ihrer Verurteilung. Für die Meldung von Chelsea Manning wurde Lamo von vielen Seiten stark kritisiert.

Adrian Lamo wurde am 14. März 2018 tot in einer Wohnung in Kansas aufgefunden. Seinen Tod gab sein Vater über einen seiner Social Media Kanäle bekannt. Lamo wurde 37 Jahre alt.

Folgen Sie uns schon auf LinkedIn? Bleiben Sie immer auf dem Laufenden.