5. Mai 2007
Die häufigste Komponente die bei Servern zur Zeit ausfällt sind Festplatten. Und meistens sind das auch die Komponenten die am ärgerlichsten sind. Netzteile lassen sich einfach austauschen. Modul raus, neues Modul rein, fertig. Man braucht nichts neu installieren, alles läuft wieder. Motherboards sind schon schlimmer. Eventuell bootet das System nicht richtig, weil Treiber fehlen und bei einigen Computerspiel-Betriebssystemen benötigt es sogar eine „Reaktivierung“, weil sich die Hardware geändert hat. Defekte Festplatten aber sind ärgerlich (sofern kein RAID die Daten rettet).
Das System muss neu installiert werden; wenn Backups nicht regelmäßig laufen, sind auch noch Daten verloren (irgendwas ist immer futsch, weil die Backups ja nicht minütlich stattfinden) und der Arbeitsaufwand ist immens höher als nur ein Netzteil zu tauschen. Neulich erst ist einem Kunden die (nicht gespiegelt) Platte des Mailservers abgeraucht. Da ist schnell ein dreiviertel Tag um, bis ein neuer Mailserver installiert und konfiguriert ist. Selbst wenn der Datenverlust keine Rolle spielt.
Zum Glück gibt es inzwischen halbwegs brauchbare statistische Daten, um die Fehlerwahrscheinlichkeit der Platten abzuschätzen. Google hat beispielsweise einen Bericht zu Festplattenfehlern in ihren Serverfarmen veröffentlicht (Failure Trends in a Large Disk Drive Population, PDF). Die Carnegie Mellon University wiederum hat sich mit dem Begriff MTTF auseinandergesetzt (Disk failures in the real word: What does an MTTF of 1,000,000 hours mean to you, PDF). Beide Arbeiten sind auf der 5. USENIX Konferenz für File und Storage Technologien (2007) veröffentlich worden.
Die Kernaussagen sind:
- Festplatten gehen viel schneller kaputt gehen, als anhand der Datenblätter zu erwarten wäre
- es gibt keinen relevanten Unterschied zwischen SCSI und SATA
- es gibt sehr wohl relevante Unterschiede zwischen den einzelnen Herstellern (aber die besseren Hersteller werden leider nicht genannt)
- wenn eine Platte mal die ersten Macken zeigt, ist sie ruck zuck ganz kaputt
- die meisten Platten gehen entweder im ersten Jahr (early failure period) oder nach fünf Jahren (wearout period) kaputt
Und mein Fazit: bei gespiegelten Platten ist der Datenverlust (meistens, Controllerfehler mal außen vor) zu vermeiden und Backups sollte man auch ab und zu machen.
4. Mai 2007
Jetzt am Wochenende ist im Kulturzentrum Scheune das vierte Symposium Datenspuren des CCC Dresden. Wer Zeit hat soll hingehen. Der Eintritt ist frei.
Sehr zu empfehlen (weil sehr amüsant) ist der Vortrag „Biometrics in Science Fiction“ von Constanze Kurz. Und vorher am besten von Frank Rieger noch den Vortrag über Wahlcomputer anhören. Das öffnet Euch die Augen.
Hier ist der komplette Fahrplan.
Ja geht’s denn schon wieder los?
Die Month of the irgendwas Bugs scheinen langsam eine Institution zu werden. Alleine wenn wir schauen, was schon alles war:
Und dann gibt es natürlich noch die Spaßvögel die auf den Zug aufspringen wollen: McAfee mit dem Month of Bug Bugs (Aprilscherz) und ein paar Spaßvögel mit dem Month of MySpace Bugs.
Und jetzt im Mai gibt es also den Month of ActiveX Bugs.
Bei ActiveX bin ich mir gar nicht sicher, ob da ein einzelner Monat reicht oder ob es ein Jahr der ActiveX Bugs braucht. HD Moore hatte letztes Jahr mit einem (inzwischen veröffentlichten) Fuzzer nach eigener Auskunft über 100 Fehler in ActiveX gefunden. ActiveX selbst gehört vermutlich zu den schlechtesten und unsichersten Techniken, die überhaupt für das Internet veröffentlicht wurden (ok, flashbasierte Homepages sind auch eine Seuche).
Alleine die Idee, dass lokal auf einem Rechner installierte Programme von einer Webseite aus ausgeführt werden dürfen und mit den Rechten des Benutzers ablaufen … da reicht ein billiger Buffer Overflow oder Format String Fehler und schon ist der Rechner unter der Kontrolle einer fremden Webseite. Natürlich kann man einzelne ActiveX Controls „Safe for Scripting“ erklären, oder eben nicht. Aber selbst die angeblich sicheren ActiveX Controls verursachen schon viele Probleme. Selbst wenn man sie nachträglich mit einem Kill Bit in der Windows Registry wieder deaktivieren kann.
Die Sicherheit einer Ausführung in einer Sandbox wie bei Java fehlt ActiveX. Ein böser Designfehler, der eigentlich nur durch die Hektik erklärt werden kann, mit der Microsoft diese Technologie gegen Java platzieren musste.
Am besten in meiner Ansicht nach daher, einen Browser zu verwenden der einfach gar kein ActiveX unterstützt.
Zertifizierungen gibt es wie Sand am Meer und der Deutsche Michel schwört auf jedes Stück Papier, das er sich an die Wand hängen kann. Besonders beliebt sind Herstellerzertifizierungen. Egal ob MCSE, Check Point CCSA/CCSE, Cisco CCNA/CCIE oder irgendeine andere Urkunde … so kann man zeigen, was man angeblich alles kann. An zweiter Stelle stehen dann die Zertifizierungen eines mehr oder weniger unabhängigen Instituts (klingt besser als Marketingklitsche, ist aber meist das gleiche). Da gibt es dann den Certified Ethical Hacker (CEH) von EC-Council, den OSSTMM Professional Security Expert (OPSE) von ISECOM und für die Leute mit mehr Geld (und meist noch weniger Wissen) so tolle Sachen wie CISSP, CISA und CISM.
Aber am besten sind die, für die es auch einen schönen Braindump gibt, den man auswendig lernen kann. Das hat den positiven Effekt, dass man das Zertifikat bekommt, ohne auch nur im geringsten was zu wissen oder verstanden zu haben.
Ich habe schon mit Kollegen gearbeitet die theoretisch alles hätten wissen müssen. Zumindest wenn man der langen Liste von Titeln auf der Visitenkarte hätte glauben wollen. Die Praxis sah leider genau umgekehrt aus. Die Kollegen bei denen auf der Visitenkarten nur der Namen und vielleicht noch „System Engineer“ stand, das waren meistens die, die am meisten drauf hatten. Und je größer das Unternehmen um so krasser die Erfahrung.
Ich vermute, das Problem hängt mit den Personalabteilungen der großen Unternehmen zusammen. Der Abteilungsleiter aus der Technik kann höchstens auf Basis der Papierunterlagen eine Vorauswahl treffen und hat da wenig andere Anhaltspunkte als die Zertifikate. Der Personalverantwortliche wiederum nimmt halt den, der im Gespräch am besten abschneidet. Und das sind öfter die Blender und seltener die Techniker. Aber gut, so haben kleinere Firmen mit einer klugen Mitarbeiterauswahl eine reelle Chance im Markt. Die großen Unternehmen kaufen für viel Geld die Blender weg und die richtig guten bekommt man manchmal für ’nen Appel und ein Ei.
Zumindest ist es bei uns im Unternehmen so. Wir sind nur ein paar Leute, aber jeder von uns kann leicht 3 oder 4 Pappnasen der großen Riesen in die Tasche stecken. Und wenn die nicht mehr weiter wissen, dann kommen sie ja doch immer wieder auf uns zu und fragen nach Unterstützung.
3. Mai 2007
Der HD-DVD Processing Key, mit dem es möglich ist alle bisherigen veröffentlichten HD-DVDs zu entschlüsseln macht im Internet die große Runde. Die AACS LA, die für die Lizenzierung des Verschlüsselungsverfahrens zuständig ist, versucht mittels des amerikanischen DMCA die weitere Verbreitung zu verhindern und überzieht diverse Webseiten mit einstweiligen Verfügungen. Digg.com scheint sich nun zu wehren, jedenfalls werden neue Postings mit dem Schlüssel nicht weiter gelöscht. Die schwedischen ThePiratebay.org (darf ich die nun verlinken oder nicht? Egal, Google is your friend) haben den Schlüssel sogar auf ihre Homepage gepackt. Dumm, dass der DMCA in Schweden nicht greift.
Eigentlich geht es aber um etwas ganz anderes.
Jedes symmetrische kryptographische System, dass irgendeinen Content irgendwann auf dem Rechner eines Nutzers entschlüsseln muss, ist fast zwangsweise zum Scheitern verurteilt. Nämlich genau solange, wie der Nutzer die Kontrolle über seinen PC hat. Der User kann (die entsprechenden Kenntnisse vorausgesetzt) einen Debugger verwenden, Breakpoints setzen, ein System virtualisieren, … um herauszufinden was da passiert. Und irgendwann muss der Schlüssel ja vorhanden sein (auch wenn nur bitweise und vielleicht nur in einzelnen Registern der CPU), sonst könnte man die Daten nicht entschlüsseln. Da gibt es kein sicheres Verfahren dagegen.
Anti-Debugger Tools, wie sie z.B. von vielen Computerspielprogrammierern eingesetzt werden oder auch von Skype, und geschützte Kernel die nur signierte Treiber zulassen, wie bei Vista, erschweren das ganze, machen es aber nicht unmöglich. Und es genügt, wenn ein einzelner Hacker (in diesem Fall im Forum Doom9) einen solchen Schlüssel gefunden hat, die Information verbreitet sich in Minuten über das Internet. Ist die Nachricht erst einmal aus der Büchse der Pandora, lässt sie sich nicht mehr einfangen.
Doch, ein sicheres Verfahren gibt es. Wenn die Schlüssel nämlich nicht in Software sondern in Hardware abgelegt werden. Dann wird es nämlich so kompliziert, da noch irgendwelche Daten herauszulesen, dass es praktisch nicht mehr möglich ist. (Ich habe gehört Intel, IBM, AMD, können so etwas mit Elektronenmikroskopen, keine Ahnung ob das stimmt.) Und das ist vermutlich die Hauptmotivation für das Trusted Platform Module. Man hat endlich eine vertrauenswürdige Hardware und braucht dem User Anwender Kunde Melkvieh nicht mehr vertrauen.
Das schlimme dabei ist, dass sich nicht mal TeleTrusT Deutschland e.V. zu schade ist, völlig kritikfrei Werbung für TPM (PDF) zu machen. Da ist alles toll und sicher und super und öffnet ganz neue Möglichkeiten. Schade eigentlich, ich habe die bisher für einen seriösen Laden gehalten. Aber ich bin beeindruckt, wie es Prof. Reimer in seinem Verharmlosungs- und Täuschungspamphlet vermieden hat den Begriff „DRM“ zu verwenden.
2. Mai 2007
http://kryptochef.net/
ohne weiteren Kommentar.
(via Heise)
Marc hat sich gemeldet, nachdem ich sein neues Buch erwähnt hatte:
Handbuch Penetration Testing
von Marc Ruef
C & L Computer- u. Literaturverlag
ISBN-10: 3936546495
ISBN-13: 978-3936546491
Marc schreibt über sein Buch:
„Ich habe den Hang entwickelt, Dinge sehr eigenwillig lösen zu wollen. Das zieht sich durch das ganze Buch. So diskutiere ich in einem Kapitel die Analyse von Firewall-Regelwerken auf dem Papier. Gerade wenn man wirklich formal festlegen muss, ob eine Installation optimal ist, kann sowas nützlich sein. Zu diesem Thema habe ich bei meinen Recherchen aber praktisch nichts gefunden… Eine solche Betrachtung ist aber eine ausgezeichnete Grundlage, muss man in einem nächsten Schritt ein echtes Exploiting-Szenario durchspielen. Anhand der formalen Analyse kann man nämlich dann viele Techniken gleich mal wieder verwerfen und sich auf die nützlichen Mechanismen fokussieren. Mein kleines Buechlein ist zu grossen Teilen sehr technisch. Kein TCP-Segment, das über das Netzwerk gejagt wird, kommt ohne Besprechung der einzelnen Bits davon 😉 ! Der Titel hätte also auch „Volle Kontrolle“ heissen können 😉 !“
Auch wenn Amazon bereits Vorbestellungen annimmt, liebe Leute, geht doch mal zu Eurem lokalen Buchhändler und bestellt es da. Meistens ist der Service klasse, oft kann man Bücher zur Ansicht bestellen und manchmal findet man auch überraschend Bücher, die man gar nicht auf dem Radar hatte. Leider verschwinden die Buchhandlungen zuerst, wenn es den Leuten schlechter geht …
1. Mai 2007
Nach dem ich neulich schon auf das nette ASCII Bulletin Board hingewiesen habe, ist mir heute bei Robert Basic dieses nette Blog im C64 Design untergekommen.
Sehr nett 🙂
Neal Stephenson gehört zu den wenigen Science Fiction Autoren, deren Bücher ich gerne lese, öfter lese und auch mal weiterempfehle, obwohl einges darin wahrscheinlich nur von IT-Freaks so ganz verstanden wird. Immerhin ist die Science Fiction so nahe an der aktuellen Realität, dass vieles davon schon recht wahrscheinlich klingt.
Das erste Buch, das ich von Stephenson gelesen hatte war Cryptonomicon. Es beschreibt in zwei Handlungssträngen einen amerikanischen Cryptoanalytiker im zweiten Weltkrieg, der in Ostasien gegen Japan kämpft sowie seinen Enkel, der versucht einen sicheren verschlüsselten Datenhafen zu schaffen. Sehr interessant ist auch, dass Bruce Schneier für dieses Buch ein Verschlüsselungsverfahren namens Solitaire entwickelt hat, das sich mit einem Satz Spielkarten ausführen lässt.
Das zweite Buch ist Snow Crash, in dem Hiro Protagonist, bester Schwertkämpfer im Metaversum, gegen eine Sekte kämpft, die einen Virus entdeckt hat der sowohl Menschen als auch Computer befallen kann. Faszinierend ist die Beschreibung der USA als Land, in dem sämtliche staatlichen Organisationen inkl. Polizei und Justiz privatisiert und an Franchise-Unternehmen vergeben sind.
Also Nerds, schnappt Euch ein Buch und raus in die Sonne 🙂
30. April 2007
Ich war neulich bei einem Kunden, um eine (relativ) einfache Failover-Lösung zu konfigurieren. In der Hauptniederlassung steht eine Juniper NetScreen-50 Firewall (HA-Konfiguration) angeschlossen an eine Standleitung, in den diversen Niederlassungen NetScreen-5GT Firewalls mit günstigem DSL. Das alles mit einem hübschen Site-to-Site VPN, ein paar Zertifikate zur Authentisierung, alles soweit ganz ok.
Jetzt kam die Geschäftsleitung auf die Idee, wenn das VPN ausfällt, z.B. weil eine DSL-Leitung ausfällt, dann muss es eine Wählbackupleitung geben. Also wurde für jede Niederlassung ein kleiner Cisco 800 angeschafft, der sich bei Ausfall des VPN-Tunnels in die Zentrale einwählen soll. Natürlich auch verschlüsselt. In der Zentrale steht dafür ein etwas größerer Cisco Router. Wie konfiguriert man das nun am einfachsten? Austausch der NetScreen-Geräte war natürlich nicht erwünscht 🙂
Ich hab ein wenig rumexperimentiert, z.B. mit OSPF über die Cisco und Juniper, aber bei Routing im VPN will Cisco einen GRE-Tunnel, den Juniper wieder nicht so gerne hat, die Konfiguration wird richtig fies komplex und das hat sich alles nicht so recht als zufriedenstellend herausgestellt.
Am Ende bin ich auf eine ganz primitive Lösung verfallen: Die NetScreen Firewalls bekommen eine statische Route mit hohen Kosten zum jeweiligen Cisco Router, über den VPN-Tunnel sprechen die Firewalls OSPF und wenn der Tunnel steht bekommt man eine Route mit niedriger Metrik. Das klappt erstaunlich gut, man muss auf den Juniper Firewalls lediglich Route-based VPN einrichten, mit Policy-based VPN geht das leider nicht. OSPF sprechen so nur die NetScreen, nur im VPN und ohne GRE. Die Cisco-Geräte bekommen davon gar nichts mit.
Sehr hilfreich war in diesem Zusammenhang die Juniper Dokumentation. Es gibt da eine Reihe von Anleitungen unter dem Begriff ScreenOS Concepts & Examples. Da sind diverse Konfigurationsvarianten anschaulich sowohl mit GUI als auch CLI beschrieben. Zwar leider nur zwischen Juniper-Geräten aber besser als nichts.
Schade, dass es vergleichbares von Check Point nicht gibt. Da fehlt mir das immer wieder. Könnte fast eine Marktlücke für ein Buch werden. Fall jemand ein solches Buch schreiben will, bitte melden. Ich steuere ein Kapitel zu „Check Point VPN-1 SecureClient zertifikatsbasierte Authentisierung mittels Active Directory und Microsoft Zertifikatsdiensten“ bei. Also LDAP-User mit AD-Zertifikaten authentisieren. Die kurze Anleitung mit ein paar Screenshots hat 68 Seiten 🙂
