Herr Reiser und die Zukunft des ReiserFS

Hans Reiser, Entwickler des ziemlich bekannten ReiserFS, wurde wegen Mordes schuldig gesprochen und wird die nächsten Jahre im Gefängnis verbringen. Das Dateisystem “ReiserFS” möchte Herr Reiser an einen Treihandfond übergeben.

Ich denke, die Zukunft von ReiserFS sieht momentan nicht ganz so rosig aus…

del.icio.us Slashdot Digg Facebook Technorati Google Windows Live Yahoo Bookmark.it



Neue ScreenOS Version: 6.1.0r2

Seit wenigen Tagen gibt es die ScreenOS Version 6.1.0r2. Die release-notes für die gefixten Bugs ist alleine mehrere Seiten groß, diese Version soll sehr viele Fehler beheben- allerdings ist der known-issue-Abschnitt für dieses Version ebenfalls mehrere Seiten lang. Ich denke nach einigen Tagen Test kann man abschätzen, wie stabil diese Version ist.

del.icio.us Slashdot Digg Facebook Technorati Google Windows Live Yahoo Bookmark.it



Bruce Schneier über Kaspersky Labs (die Sache mit dem 1024-bit RSA)

Kaspersky Labs hat einen Aufruf gestartet, um unter Mithilfe ganz (ganz ganz) vieler Internetuser einen 1024-bit RSA-key zu knacken. Verschlüsselungs-Guru Bruce Schneier schreibt in seinem Blog dazu:

[...] What are they smoking at Kaspersky? We’ve never factored a 1024-bit number — at least, not outside any secret government agency — and it’s likely to require a lot more than 15 million computer years of work [...]

Witzig.

del.icio.us Slashdot Digg Facebook Technorati Google Windows Live Yahoo Bookmark.it



Neue ScreenOS Versionen 5.4.0r10 und 6.0.0r5a

Nach einiger Zeit Pause, hier mal wieder ein Überblick über die aktuellen ScreenOS-Versionen.

In der 5er-Version ist die 5.4.0r10 aktuell. In dieser Version sind einige Bugs gefixt worden, hier meine persönlichen (weil schon öfters aufgetretene) Favoriten:

  • 240535—PPPoA learned DNS values overwrite the local DNS settings of the firewall, regardless of preference setting.
  • 221831—Debug output using debug tag is not being filtered by ’set ffilter’.
  • 262652—Retrieve subscription did not work via the GUI.

Eine ganz spezielle Version ist die 6.0.0r5a. Es handelt sich hierbei um eine Zwischenversion, die einige bugs behebt, bis ein neues minor-release herauskommt. Juniper beschreibt das in den Release-Notes:

[...] this version of ScreenOS is based on
ScreenOS 6.0.0r5 and will only be available until the next public
mainline release which will contain these fixes [...]

Es handelt sich um insgesamt 12 known-issues, die behoben werden. Für mich eines der Wichtigsten Probleme im Zusammenhang mit kleinen SSGs ist nun auch behoben:

285333, 287030 The switch on the SSG5 may stop responding

In dieses Problem bin ich bei einem Kunden gelaufen- Ohne Grund und ohne Meldung geht kein Traffic mehr durch die bgroup. Wir haben das Problem dann bei Juniper eingekippt und hiermit auch eine Lösung. Bis zu unserem Case war das Problem bei Juniper leider noch nicht bekannt.

Diese Version sollte man wohl nur einspielen, wenn man wirklich exakt eines dieser issues kurzfristig lösen muss.

del.icio.us Slashdot Digg Facebook Technorati Google Windows Live Yahoo Bookmark.it



RFC: "Protokoll zur vereinfachten Einspeisung und Verwendung bundesbehördlicher Trojanersysteme"

Protokoll zur vereinfachten Einspeisung und Verwendung 
bundesbehördlicher Trojanersysteme

Status des Memos

Dieses Memo hat informativen Charakter. Dieses Memo stellt keinen Standard jeglicher Art da. Die Verbreitung ist natürlich untersagt.

 

Inhalt

Zweck
Protokoll

 

Zweck

Dieses Dokument beschreibt ein Protokoll, das es bundesbehördlichen Organen erlaubt, jegliche IT-gestützte Privatsphäre aufzuheben und nach deren Aufhebung legal an beliebige Informationen bezüglich terroristisch-relevanter oder irrelevanter Daten zu gelangen. Da eine immer größer werdende Zahl an illegalen Aktivitäten im Internet verdeckt durchgeführt werden, d. h. vor staatlichen Stellen absichtlich(!) verheimlicht werden, muss mit der Standardisierung eines solchen Protokolls entgegengewirkt werden.

Protokoll

Der komplette Protokollstack “zur vereinfachten Einspeisung und  Verwendung bundesbehördlicher Trojanersysteme”, im weiteren kurz PEST genannt, besteht aus mehreren Schichten.
Schicht 0
Schicht 0 definiert die physikalischen Voraussetzungen zur Implementierung und Verwendung von PEST. Ein PEST-konformes Anwesen (Haus, Wohnung, Garage, Flugplatz, Keller, Bunker, Strand oder sonstiges als Wohnung verwendbares Umfeld) stellt mindestens 2 (In Worten: Drei) “Not-Eingänge Respektive Dateneingänge”, im weiteren kurz NERD genannt, bereit, um die “Not-Eingangs Respektive Dateneingangs-Spezialisten”, im weiteren kurz NERDS genannt, auf einfache Weise physikalischen Zugang (herein- und heraus-laufen) erlangen zu lassen. Ein NERD darf nicht verschlossen, verbarrikadiert, lackiert, zugestellt, verdeckt, versteckt, offen, geschlossen oder auf sonstige Weise unzugänglich gemacht werden. Jeder NERD muss mindestens die Größe von 3m x 2m besitzen und durch ein rot-leuchtendes, 1m x 2m großes Schild gekennzeichnet sein.

Schicht 1
Schicht 1 definiert die Verbindung zum örtlichen “Datenspeicherungs- und Auswertungszentrum”, kurz “DAU”. Jedes netzwerkfähige-, bedingt netzwerkfähige- oder nicht netzwerkfähige Gerät muss per dedizierter Überwachungsleitung an das DAU angeschlossen sein. Diese Verbindung wird per Glasfaser hergestellt, entsprechende Module für PC, Laptop, Ipod, Toaster, Rasenmäher und alle weiteren, hier nicht namentlich aufgeführten Geräte werden vom Gerätebesitzer beschafft. Jegliche Daten, die ein Gerät produziert und die auf beliebige Weise das Gerät verlassen, werden somit schon beim Versenden dupliziert und an das DAU gesendet.

Schicht 2
Schicht 2 definiert die Softwarekomponente, die jedes Gerät implementiert haben muss. Die Softwarekomponente wird als .msi-Paket oder auf sonstige Weise zur Verfügung gestellt und muss installiert werden. Hierbei hat der Benutzer selbst dafür Sorge zu tragen, dass ein Betriebssystem eingesetzt wird, das mit der zur Verfügung gestellten Software auch zurecht kommt. Bei jedem Netzwerkzugriff wird über das DAU geprüft, ob die Softwarekomponente korrekt installiert wurde. Wenn dies nicht der Fall ist, wird der Internetzugriff verweigert. Die “Softwarekomponente zur Normalen investigativen forensischen FeinArbeit”, im weiteren kurz SNIFFA genannt, muss mindestens die folgenden SNIFFA-Kommandos implementieren:
- HEY
- COPYMAILS
- DIR[x]
- FLUSHPGPKEYS
Die Kommandos im einzelnen
HEY
Hiermit bittet das DAU den SNIFFA-Client, sich und den angemeldeten Benutzer zu identifizieren. Als notwendige Daten müssen mindestens zurückgegeben werden: Benutzername, Passwort, Vorname, Nachname, Geburtsdatum, Kontonummern(n), Kontostand, Telefonnummern, Sozialversicherungsnummer, Bookmarks, Windows-Adressbuch, die letzten 10 e-bay-Bestellungen, die letzten 10 geschriebenen Foren-Beiträge. Aus datenschutzrechtlichen Gründen wird darauf verzichtet, mehr Informationen als unbedingt notwendig zu erfragen, daher gibt die HEY-Abfrage nur die oben genannten notwendigsten Daten zurück.
COPYMAILS
Veranlasst den SNIFFA-Client, die letzten 8000 Emails inklusive Anhang an das DAU zu senden.
DIR[x]
Sendet einen kompletten Auszug aller Dateinamen inklusive Metadaten an das DAU
FLUSHPGPKEYS
Sendet die aktuell verwendeten PGP-Keys, den kompletten PGP-Keyring und die mittlerweile gelernten Passwörter an das DAU.

Für alle, die es nicht erkennen: Dies ist kein offizieller RFC oder Draft-standard. Ebenso sollte der Text nicht zu ernst genommen werden. Wirklich vollständig ist dieser auch nicht, aber, was soll´s…

del.icio.us Slashdot Digg Facebook Technorati Google Windows Live Yahoo Bookmark.it