jtb.blog

In nicht allzu ferner Zukunft werden Tools wie Kismet, nmap, nessus oder das gute alte SATAN oder Passwortcracker wie L0phtcrack verboten sein.
Jedenfalls falls die aktuelle Gesetzesvorlage so durchkommt.

Denn dort steht (zusammengefasst):

Besonders gefährliche Vorbereitungshandlungen zu Computerstraftaten werden künftig strafbar sein. Sanktioniert wird insbesondere das Herstellen, Überlassen, Verbreiten oder Verschaffen von „Hacker-Tools“, die bereits nach Art und Weise ihres Aufbaus darauf angelegt sind, illegalen Zwecken zu dienen (§ 202c StGB neu).

Das Problem ist, dass die oben genannten Tools sowohl für gute Zwecke als auch für schlechte eingesetzt werden kann.
So schreibt das BSI (Bundesamt für Sicherheit in der Informationstechnik) zum Thema Penetrationstest:

Kenntnisse in der Handhabung von Hackertools und Schwachstellen-Scannern
Zur Durchführung von Penetrationstest ist neben dem erforderlichen Grundlagenwissen auch Erfahrung in der Handhabung mit Hackertools und Schwachstellen-Scannern notwendig. Kenntnisse im Umgang mit diesen Tools sollten in der Praxis erworben worden sein. Aus der Vielzahl der verfügbaren Tools haben sich im Laufe der Zeit einige Produkte eine weite Verbreitung gefunden (z. B. nmap für Portscans, L0phtcrack für Windows-Passwörter). Sowohl kommerzielle Tools für die Durchführung einer effizienten Prüfung als auch frei verfügbare Werkzeuge zur Demonstration der relativ einfachen Durchführbarkeit können zum Einsatz kommen. Die Effizienz des Penetrationstests hängt aber wesentlich davon ab, wie erfahren der Penetrationstester im Umgang mit diesen Tools ist.

So verwendet selbst Trinity in Matrix zuerst nmap und dann einen SSH-Root-Exploit (siehe Screenshot). Einige der o.g. Tools sowie einige mehr wurden auch bei der Lehrveranstaltung Praktikum IT-Sicherheit/Hackers Contest verwendet

Da kann ich nur sagen: Hackertools-Verbot ist genauso wirkungsvoll wie ein Vermummungsverbot für Bankräuber..
Über die potentiellen Auswirkungen will ich garnicht nachdenken: alle Debian, Gentoo usw Mirrors werden illegal, man verliert viele sinnvolle Tools. Wahrscheinlich kommt dann demnächst auch noch das Verbot von starker Kryptographie
Wie man sowas in Zeiten des Internets durchsetzen will, ist auch fraglich.

Heute war mal wieder so ein Tag wo irgendwas schiefgehen muss. Gestern kam neue Hardware – endlich den Domänencontroller auf aktueller Hardware fahren (statt auf Dual P3 500Mhz)
Dies ist nebenbei bemerkt der erste Server mit einer nicht-Intel CPU: ein AMD Opteron…
Gestern also noch schnell Windows 2003 R2 in der 64bit Variante installiert (mit der 32bit Variante würde ich bei der nächsten RAM-Aufrüstung schon Probleme bekommen – und hey es sind 64bit). Eigentlich nicht das Problem, da ich schon drei Server auf 64bit fahre (Datenbank und Virtual Server Hosts). Zwar gibt es bei 64bit noch einige kleinere Probleme, aber bislang konnte man die alle lösen

Doch dann kam ich auf die Idee auch den WSUS (quasi Windowsupdate im Intranet) auf den neuen Server umzuziehen. Als Vorbereitung wollte ich den WSUS endlich auf dem alten Server auf SP1 hochpatchen, damit ich endlich MS-SQL 2005 richtig als Backend benutzen kann.
Also schnell den Patch runtergeladen, per doppelklick gestartet und mir den Dialog angeguckt: ok – erst will er scheinbar die alte Instanz deinstallieren. Eigentlich nichts ungewöhnliches, da einige Setupprogramme erstmal eine saubere Basis schaffen wollen. Man konnte sogar extra wählen, welche Komponenten auf dem Server erhalten bleiben sollen: Update-Dateien (mittlerweile bei ca. 13GB), Datenbank und Logfiles.
Nachdem dann die Deinstallation fertig war, wunderte ich mich, wo die erwartete folgende Installation von SP1 blieb.

Tja, jetzt sollte das Ergebnis wohl klar sein: das vermeidliche Update hat die alte Installation deinstalliert. Nicht so schlimm dachte ich mir – einfach neu installieren, alle Update-Dateien sowie die Datenbank sind ja noch da.
Doch die Installation mit WSUSSetup.exe /f (damit nur das Frontend installiert wird und nicht die Datenbank inkl. Datenbankserver) scheiterte. Zuerst meckerte das Setup, dass der Pfad für die Update-Dateien ungültig wäre, weil nicht mindestens 6GB Platz frei wäre (klar, wenn von einer 18GB Partition schon über 13GB für Update-Dateien belegt sind). Aber auch die testweise durchgeführte Auswahl eines anderen Ordners half nicht weiter.. Ein Blick in das Logfile zeigte, dass die WSUSSetup.exe das MSI in einem Unterverzeichnis sucht, das nicht existierte. Dies war aber nicht die einzige Problemquelle: die Installation des Features PSFSIP scheiterte jedesmal: Error 0x80004005: Unspecified error

Nun dachte ich mir, dass das alles kein Problem wäre, weil ich ja einfach den WSUS auf den neuen Server installieren könnte. Nur leider ist WSUS 2 nicht kompatibel mit einem 64bit Windows
Erst das derzeit in Betastatus befindliche WSUS 3 bietet die Option den WSUS-Server auf einem 64bit Windows zu installieren. Auf Tricksereien wie den IIS auf dem neuen Server im 32bit Modus mit 32bit ASP.Net zu betreiben wollte ich mich nicht einlassen – der neue Domänencontroller sollte ja sauber bleiben. Somit fällt natürlich auch die Installation der Beta2 von WSUS 3 weg…
Auch eine testweise durchgeführte Installation auf einen ausgemusterten Server führte nicht zum Erfolg – es kam derselbe Fehler.

Na ja, jetzt brauche ich erstmal einige Folgen "Bernd das Brot" - dann schau ich am nächsten Arbeitstag nochmal nach WSUS - wenigstens ist kein Patch-Day in Sicht

Gestern kam neue Hardware und ich installierte gleich den Windows 2003 R2 Server in der 64bit Version.
Eigentlich hatte ich bislang mit 64bit keine Probleme. Aber irgendwie haben die Leute bei HP nicht mitgedacht: auf der Support-CD lagen alle Treiber (inkl. des benötigten Netzwerktreiber). Nur leider waren diese Treiber selbstentpackend mit Winzip gepackt. Aber mit der 32bit Variante, was zu

The image file XY is valid, but is for a machine type other than the current machine.

Na ja, als Workaround musste ich dann alle Treiberdateien auf Platte kopieren, die Endung in .zip ändern und ganz normal öffnen. Trotzdem ärgerlich – man sollte meinen, dass man Treiber für ein 64bit Windows auch unter einem 64bit Windows entpacken will.
Da der neue Server Domänencontroller werden sollte, stand ein Update des Active Directory Schemas an – mit dem schönen Befehl adprep /forestprep eigentlich kein Problem. Gleichzeitig habe ich endlich mal den AD-Forest auf ein höheres „Functional Level“ gesetzt (es gibt bei uns keine Windows 2000 Domänencontroller mehr). Mein Changelog-Eintrag dazu wurde nebenbei bemerkt passend von einem Kollegen übersetzt:

Wald-Funktions-Stufe? Wald-Schema? /waldvorbereit?

Das Problem beim Forestprep ist, dass es auf dem Schema-Master ausgeführt werden muss. Also schnell den passenden Server gesucht und gefunden sowie das adprep von der zweiten CD ausgeführt. Doch das wollte nicht klappen:

Danke – adprep gibt es also 32bit und 64bit Executable (gab es AFAIK nicht die Möglichkeit 32bit und 64bit in eine exe zu packen?) – und der Schema-Master ist (noch) auf 32bit…
Was würde ich ohne die MSDN-Universal CD Sammlung machen? Mit dem 32bit adprep von der zweiten Windows 2003 R2 32bit CD klappte aber dann glücklicherweise alles problemlos.