WeizenSpr.eu

Es ist endlich geschafft! Nachdem ich die letzten Tage überlegt habe, wie ich das ganze am unkompliziertesten löse, habe ich nun eine Möglichkeit gefunden: Die Rede ist von der Verwaltung eines hMailServer Mailaccounts.

In den letzten Tagen hatte ich euch VBScripte vorgestellt, mit denen ein Benutzer sein Passwort ändern oder eine Mailumleitung einrichten. Das Problem bestand bisher, diese Funktionen auch remote verfügbar zu machen – denn direkten Zugriff auf den Server wird keiner der Mailbenutzer kriegen.

Im Moment verwende ich immernoch einen ziemlich minimalistischen Webserver auf dem Rechner – trotzdem wollte ich die Konfiguration bereits lauffähig machen. Die einzige Möglichkeit hierfür war die Verwendung eines CGI-Scriptes.
Also habe ich mich auf die Suche gemacht, wie ich ein VBScript über CGI ansprechen und ausführen kein. Dummerweise funktionierte das Codebeispiel bei mir überhaupt nicht! Eine andere Lösung musste also her…

…und diese habe ich hier gefunden. Anstatt eines CGI-Scriptes habe ich einfach eine CGI-Anwendung in Delphi geschrieben ! Dadurch habe ich zum einen gelernt, wie man sowas macht und zum anderen konnte ich das ganze in einer robusten, mir bekannten Sprache erstellen.

Wo ihr ein bisschen aufpassen müsst, ist bei dem Herleiten der Dateipfade: Irgendwie habe ich da das Gefühl, dass der Server die Werte PATH_INFO, PATH_TRANSLATED und SCRIPT_NAME nicht korrekt setzt. Aber das müsste man nochmal durch das Testen mit anderen Webservern überprüfen.

Hier jedenfalls erstmal der Quelltext:

In dem Programm selber gehen wir folgendermaßen vor:

1. Wir parsen den URL-String.
2. Wir führen das entsprechende VBScript aus.
3. Wir lesen den Antwortwert aus stdout.
4. Wir geben den erhaltenen Ergebniscode zurück.

Für den Zugriff habe ich mir ein tolles URL-Schema überlegt, das eingehalten werden muss, damit das Programm die richtigen Daten auslesen kann. Folgende Befehle gelten für das Setzen einer Mailumleitung:

Durch das Setzen des forward-Parameters wird die Umleitung aktiviert. Durch Weglassen des Parameters wird die Umleitung deaktiviert.

Für das Ändern des Passworts wird folgendes URL-Schema benutzt. Wenn man ein Mail-Forwarding einrichten kann, dann kann man auch sein Passwort ändern – die Befehle unterscheiden sich nur geringfügig:

Was haltet ihr von dieser Form der Implementierung? Denkt ihr, ein Benutzer kann sich zwei URLs merke? Wie findet ihr den Lösungsansatz generell?

Update:
Der vorhandene Exploit wurde nun behoben. Das Problem war, dass die übergebenen Parameter nicht überprüft wurden, bevor sie in den auszuführenden Befehl eingebaut wurden. Nun werden Anführungszeichen escaped, um das Hinzufügen von zusätzlichen Parametern und andere Modifikationen des Befehls zu unterbinden (Stichwort Pipes).

Konfigurierende Grüße, Kenny

Es ist teilweise unglaublich, wieviele Probleme man bekommen kann, wenn man einen eigenen Server betreiben will. Das fängt bei der Erreichbarkeit an (Stichwort dynamische IP), geht über die Probleme beim E-Mail-Versenden (Stichwort Reverse-DNS) und endet bei den SSL-Zertifikaten.

Die Zertifikate haben es nämlich ganz schön in sich. Aber fangen wir vorne an: Wenn ein Rechner sich mit einem Server über den Domainnamen verbindet, dann funktioniert das, indem der Rechner bei einem DNS-Server anfragt, wie den die IP des Rechners ist, der sich hinter dem Namen versteckt. Der Rechner verbindet sich dann mit der IP und beginnt mit der eigentlichen Kommunikation.
Wenn der Rechner also bei dem Server aufschlägt, hat der Server garkeine Ahnung, dass der Besucher mit einer bestimmten Domain sprechen möchte. Diese Information wird z.B. einem HTTP-Server erst im weiteren Gesprächsverlauf mitgeteilt.

Jetzt kommt aber das große Problem: Wenn ein Rechner sich mit dem Server verbindet und der Rechner eine verschlüsselte SSL-Verbindung haben möchte, dann muss der Server ein passendes Zertifikat zurückliefern. In diesem Zertifikat steht der Domainname, für den das Zertifikat gilt.
Der Stolperstein ist nun, dass der Server das passende Zertifikat zurückgeben muss, obwohl ihm der Rechner noch garnicht verraten hat, welche Domain er überhaupt abrufen will!

Um dieses Problem zu lösen gibt es nun mehrere Möglichkeiten, von denen ich mir einige angeguckt habe und die ich mal ein bisschen näher erklären will.

Fangen wir mal mit der Lösung an, die wohl die wenigstens Haushalte “einfach so” aus dem Stehgreif lösen können: Dem Rechner mehrere IPs zuweisen. Hintergrund ist, dass einer Netzwerkkarte mehrere IPs zugewiesen werden können. Anhand der IP, an die die Abfrage gerichtet ist, kann der Server nun herausfinden, welche Domain erfragt werden soll. Je nachdem wird dann einfach das passende Zertifikat verteilt.
Die Lösung ist für den Privathaushalt deshalb unpraktikabel, da man als Privatperson von seinem Internetanbieter meist nur eine einzige IP zugewiesen bekommt. Es gibt zwar die Möglichkeit, sich z.B. bei Manitu mehrere IPs zu besorgen, jedoch bekommt man dann das Problem, dass man einen professionellen Router benötigt, der in der Lage ist, mehrere öffentliche IPs zu verwalten.

Deshalb habe ich lange daran gedacht, folgende Lösung umzusetzen: Ich besorge mir eine Domain, über die sämtliche verschlüsselte Kommunikation abläuft. Wenn jemand SSL benutzen möchte und keine Programmwarnungen sehen will, soll er halt über diese designierte Domain gehen, da diese dann in den Zertifikaten steht. Das einzige Problem wäre, dass ein Benutzer sich evtl. wundert, dass er von einer Webseite auf eine komplett andere Domain weitergeleitet wird. Alles andere könnte man durch korrekte Konfiguration und durch Programmierung lösen.

Für viele würde diese Variante sicherlich ausreichen – ich persönlich finde sie allerdings ziemlich unschön. Also habe ich weitergesucht und habe die TLS-Erweiterung namens SNI gefunden. Diese löst genau das oben Problem: Bei der Verwendung von SNI wird bereits beim Aufbau der verschlüsselten Verbindung mitgeteilt, welche Domain angesprochen werden soll. Dadurch kann der Server das passende Zertifikat heraussuchen und die Verbindung korrekt herstellen. An sich eine gute Lösung…

…wenn denn der Server es nicht explizit unterstützen müsste. Leider gibt es immernoch einige Serversoftware, die ausschließlich SSL (bzw. TLS 1.0) unterstützen. Deshalb habe ich noch weiter gesucht und bin schlussendlich beim X.509-Standard gelandet. Dieser beschreibt, welche Werte in einem Zertifikat stehen. Auch dieser hat in letzter eine Veränderung erfahren, die für unsere Belange genutzt werden kann: Gemeint ist die Erweiterung SubjectAltName.
Diese sieht vor, dass man ein Zertifikat erstellen kann, das für mehrere Domains gültig ist – nämlich genau für die, die im Feld SubjectAltName hinterlegt sind.
Der Vorteil ist, dass dieses Vorgehen mit allen Servern funktioniert – auch, wenn sie die Erweiterung nicht unterstützen. Lediglich der Client muss sie auswerten können. Sollte es nun einen Client geben, der lediglich den Common Name (CN) auswertet, so kann man für diesen zumindest noch zusätzlich die oben erwähnte Variante mit der separaten SSL-Domain anbieten.

Abschließend wollte ich euch noch zeigen, wie man relativ einfach ein selbst-signiertes Zertifikat mit integrierten SubjectAltNames erstellen kann. Basis hierfür waren die Artikel auf therowes.net, iiegn.blogspot.com und sial.org.

Wenn man es noch nicht hat, muss man sich zuerst einmal einen privaten Schlüssel erzeugen. Das geht bei OpenSSL mit diesem Befehl:

Denkt bitte dran, dass dies der private Schlüssel ist, der im Moment nicht mit einem Passwort geschützt ist. Einige Serverprogramme brauchen ihn in diesem Zustand. Der Schlüssel muss in diesem Zustand unbedingt vor unbefugtem Zugriff geschützt werden!

Als nächstes muss die Datei “openssl.cfg” der OpenSSL-Installation bearbeitet werden. Über den interaktiven Modus von OpenSSL ist es derzeit nicht möglich, die SubjectAltNames zu definieren, deshalb muss dies in der Konfigurationsdatei geschehen.

Guckt zuerst, ob im Bereich “req” der Wert “req_extensions” auf “v3_req” gesetzt ist:

Als nächtes müsst ihr in den Bereichen “v3_req” und “v3_ca” den Wert “subjectAltName” auf “@subject_alt_names” setzen:

Abschließend müsst ihr einen neuen Bereich “subject_alt_names” anlegen und dort die Domains reinschreiben, für die das Zertifikat gelten soll. Vergesst hier auf keinen Fall die Domain, die im Common Name stehen wird!

Und nun liegt es an euch, auf welchem Weg ihr das Zertifikat erstellen wollt. Wenn ihr über einen CSR gehen wollt, wird die Einstellung im Bereich “v3_req” verwendet. Wenn ihr jedoch gleich selbst signiert, sind die Einstellung in “v3_ca” aktiv.

Ich persönlich habe den zweiten Weg genommen, da ich mir damit das Erstellen einer eigenen CA gespart habe. Der Befehl für den direkten Weg lautet wie folgt:

Beim Ausführen des Befehls werdet ihr nach den Werten für das Zertifikat gefragt. Vergesst nicht, den Common Name richtig zu setzen. Das dabei herauskommende Zertifikat wird 365 Tage lang gültig sein. Dieses Zertifikat muss übrigens nicht (im Gegensatz zum privaten Schlüssel) gesondert gesichert werden – es wird sowieso vom Server an jeden geschickt, der danach fragt!

Sooo… meine Güte! Der Artikel ist länger geworden, als ich gedacht hatte ! Ich muss aber auch zugeben, dass ich ihn eine ganz schöne Zeit vor mir hergeschoben habe und er zeitweise zu einer reinen internen Referenzsammlung verkommen war . Der Artikel ist auch für mich wichtig, damit ich nicht vergesse, welchen Weg ich nun schlussendlich gegangen bin !

Wie hat auch der Artikel gefallen? Standet/steht ihr auch von dem Problem? Wie habt ihr es gelöst? Wäre der gezeigte Weg eine Lösung, die ihr in Betracht ziehen würdet?

Verschlüsselnde Grüße, Kenny

Und noch immer sitze ich am Webserver. Nachdem wir gestern entschieden haben, dass ich die Domains des Bezirks hosten werde, muss ich natürlich dafür sorgen, dass die Leute später nicht nur ihr Passwort ändern können, sondern, dass sie zumindest auch eine Mail-Umleitung einrichten können, falls sie nicht extra ein zusätzliches Postfach abrufen möchten.

Dabei ist wieder ein VBScript herausgekommen, das per cscript.exe aufgerufen werden muss. Es basiert großteilig auf dem Script, mit dem der Benutzer sein Passwort ändern kann.

Ich denke mal, dass damit die beiden wichtigsten Konfigurationsmöglichkeiten für eine E-Mail-Adresse abgedeckt werden sollten.

Habt ihr eine Idee, was man als Endanwender sonst noch konfigurieren können sollte? Wie würdet ihr solch eine Konfiguration am liebsten vornehmen? Würde euch Telnet ausreichen oder würdet ihr eine Webseite bevorzugen?

Umleitende Grüße, Kenny

Ja, gestern war in der Tat ein schöner Tag, denn das Bundesverfassungsgericht hat unter Leitung von Hans-Jürgen Papier die derzeitige Form der verdachtsunabhängigen Vorratsdatenspeicherung für verfassungswidrig erklärt.

Ganz herzlich bedanken möchte ich mich an dieser Stelle zunächst beim AK Vorratsdatenspeicherung, der seit Jahren gegen diesen bürgerfeindlichen Überwachungsapparat gekämpft hat und ich unterstütze auch ihr Anliegen, die Vorratsdatenspeicherung nun europaweit abzuschaffen. Wie es scheint kommt da ja bereits ein bisschen Bewegung ins Spiel.

In der Pressemitteilung des Bundesverfassungsbericht zum Urteil über die Vorratsdatenspeicherung werden u.a. Hürden aufgezählt, die erfüllt sein müssten, damit die Speicherung verfassungskonform ist. Leider stürzen sich darauf im Moment die Politiker und überlegen bereits, wie man die Anforderungen so schnell wie möglich in einen tatsächlichen Gesetzestext überführen kann – selbst das BKA ist sich nicht zu schade, zur Eile zu drängen.

Meiner Meinung nach ist das angestrebte Vorgehen totaler Schwachsinn! Das muss man sich mal auf der Zunge zergehen lassen: Das Bundesverfassungsgericht schreibt vor, was maximal möglich ist, um nicht gegen das Grundgesetz zu verstoßen. Und was tun die Politiker? Sie nehmen diese Maximalwerte und wollen sie als Basis für das neue Gesetz verwenden. So nach dem Motto “Wenn wir das Grundgesetz nicht brechen dürfen, dann können wir es wenigstens möglichst weit ausreizen!”

Einer der Vorreiter ist natürlich mal wieder Wolfgang Bosbach, der auch mir schon mehrfach negativ aufgefallen ist. In einer Debatte auf Phoenix hat dieser gestern abgesondert, dass man nun völlig hilflos sei und die Verbrechen nicht mehr ordentlich aufklären könne. Auch die Terrorabwehr wäre so nicht mehr möglich. Er geht sogar soweit, zu behaupten, dass Kriminelle nun dazu ermutigt werden könnten, ihre Verbrechen in Deutschland zu planen, da sie hier ja keine Verfolgung mehr fürchten müssen.
Bei solchen unqualifizierten und völlig haltlosen Behauptungen frage ich mich manchmal wirklich, ob sie diese ahnungslosen Freizeitpolitiker nur für die Kontroverse mit in die Sendung nehmen. Ich kann mir jedenfalls nicht vorstellen, dass sie aufgrund seines “Sachverstandes” auf ihn aufmerksam geworden sind.
Aber okay, wenn ich mich noch weiter über das Nichtwissen von anderen Politikern aufrege, platzt mir evtl. irgendwann nochmal die Hutschnur!

Was zu sagen bleibt, ist, dass wir noch längst nicht am Ziel angekommen sind – die Vorratsdatenspeicherung ist aufgeschoben, aber nach dem Willen der rechten “konservativen” Politiker noch längst nicht aufgehoben. Wir müssen also weiterkämpfen; für die Bürgerrechte; für die Privatsphäre jedes einzelnen Menschen in Deutschland. Das heißt aber auch für mich, dass die Piratenpartei noch mehr als genug Arbeit haben wird, um Deutschland zu dem zu machen, was das Grundgesetz uns zusichert.

Gespeicherte Grüße, Kenny

Hacker sind auch heute noch ein Mythos. Das liegt wahrscheinlich daran, dass außenstehende nicht verstehen, was diese Leute machen und wie sie es anstellen. Leider gibt es auch solche Exemplare, die zwar keine Ahnung haben, aber trotzdem unbedingt als Hacker angesehen werden wollen. Dabei kommen dann solche Perlen der Unterhaltung heraus:

Ja, in der Tat war dieses Video des “NextGenHacker101″ Anlass für diesen Blogeintrag: Leute, die Ahnung von der Materie haben, finden das Video einfach nur saukomisch – weil nichts davon korrekt ist. Schlimmerweise könnte sich dieses Nichtwissen bei technikfernen Leuten wirklich festsetzen .
Aber es ist kein Einzelfall: Viele Leute verstehen unter “Hacken” das stupide Einbrechen in einem (Windows-) Computer. Jeder Taschenspielertrick scheint recht zu sein, um die Bezeichnung “Hacker” zu erlangen. Z.B. hier:

Dass dieser “Hack” nur dann funktioniert, wenn kein Administrator-Passwort gesetzt ist, wird dabei einfach mal verschwiegen. Stattdessen hätte man lieber zeigen sollen, wie man über Linux das Admin-Passwort zurücksetzen kann. Aber das wäre wohl zu viel Arbeit gewesen .
In der gleichen Liga wie die “Ich kann mich in einen ungeschützten Account einloggen”-Hacker spielen die “Ich kann das Passwort ändern, wenn ich bereits eingeloggt bin”-Hacker:

Darüber gibt es dann eigentlich nur noch die Leute, die sich irgendein Programm besorgen und denken, damit jetzt endlich ein Hacker zu sein. Egal, ob es sich dabei dann um normale Remote-Desktop-Tools handelt oder aber um echte, coole “Hacker-Tools” – mit richtig vielen fiesen Knöpfen wie “Vertausche die Maustasten”, “Gib eine Nachricht aus” aus oder anderes Zeug. Ja, in der Tat! Solche Tools könnten auch richtige Hacker benutzen. Nur mit dem Unterschied, dass die auch den schwierigen Part meistern: Nämlich das Client-Programm auf dem Zielrechner zu installieren!

Wie jetzt? Im Video wurde das ganze nur lokal verwendet? Und sogar noch mit Warnhinweis der Firewall? Na das ist ja mal echt gefährlich .

Aber jetzt mal im Ernst: Wenn das keine Hacker sind, wer ist dann ein Hacker? Dazu gibt es mehrere Antworten – je nachdem, welche Seite man betrachtet. Im Grunde haben jedoch alle Hackerdefinitionen eines gemein: Sie haben ein tiefes Wissen in dem Fachgebiet, auf das sie sich spezialisiert haben.

Grundvoraussetzung um ein richtiger Hacker zu sein ist meiner Meinung nach vor allem das Interesse daran, sich neue Dinge anzueignen, um vorhandene Lösungen verstehen, erforschen und verbessern zu können. Es ist eigentlich völlig egal, ob man sich jetzt nun die Computersicherheit auf die Fahnen geschrieben hat und guckt, wie man Sicherheitsmechanismen umgehen kann – oder, ob man eher technikaffin ist und sich gerne anguckt, wie irgendwelche Geräte intern verdrahtet sind und man solche Hardware gerne mal für den eigenen Gebrauch umbaut.

Es geht dabei garnicht um Ruhm oder Prestige, sondern primär um den eigenen Spieltrieb – herauszufinden, was möglich ist, obwohl es nicht möglich sein sollte; gucken, welche Komponenten man gegen einander ausspielen kann oder um es anders auszudrücken: Gucken, wie weit sich ein System dehnen lässt, bevor es kaputt geht.

Ich persönlich gehe dabei eigentlich immer wie folgt vor: Wenn mir ein neues System (z.B. neue Software) begegnet, gucke ich mir zuerst an, wie sie im Regelfall funktionieren sollte. Wenn ich das verstanden habe, gucke ich mir an, welche Schwachstellen das Gesamtsystem haben könnte (Benutzereingaben, Übergangspunkte zwischen verschiedenen Softwaremodulen, etc.). Anschließend probiere ich aus, wie diese Schwachstellen mit Fehlersituationen umgehen (simple Falscheingaben, gezielte Falscheingaben, usw.). Sollte man nun über ein ungewöhnliches Verhalten stolpern, muss man analysieren, wie es zustande gekommen ist – und man muss überprüfen, ob das Verhalten reproduzierbar und steuerbar ist. Und aus diesen Erkenntnissen baut man dann seine Angriffstragien auf, die dann unter Umständen auch weitere Eingriffe nach sich ziehen können.

Das Vorgehen ist natürlich nur rein exemplarisch – ich bin mir sicher, dass andere Personen auch anders bei ihren Analysen vorgehen.

Wie empfindet ihr gegenüber Hackern? Seid ihr selbst welche? Seht ihr Hacker das absolute Böse? Oder seid ihr solche Fanboys, wie sie in den Videos zu sehen waren?

Hackende Grüße, Kenny

Wie man merkt, steht dieses Wochenende ganz im Zeichen der Informatik-Blogartikel . Keine Sorge, es wird auch wieder andere Zeiten geben, aber zur Zeit steht der Homeserver halt hoch im Kurs . Auch wenn jetzt alle Linux-Fanboys wieder anfangen zu meckern: Der Server läuft unter Windows (XP Pro SP3).

Linuxer werden damit wahrscheinlich kein Problem haben, aber unter Windows ist die Wartung eines Servers ohne grafische Oberfläche ziemlich schwierig, da sich einige Serveranwendungen garnicht über die Kommandozeile administrieren lassen. Eine Lösung musste her!

Mein erster Gedanke war, von außen über VPN einen Tunnels lokale Netzwerk herzustellen und dann im Netzwerk über die Windows-eigene Remotedesktopverbindung auf die grafische Oberfläche zuzugreifen. Das Einrichten von Windows als VPN-Server war überhaupt kein Problem – sowohl die Serverfunktion, als auch die Clientfunktion sind direkt im Betriebssystem enthalten. Allerdings… über den Router wollte das ganze dann nicht mehr funktionieren… trotz etlicher freigegebener Ports .

Zum Glück eilte mir mein Freund @Baschdii (aka. @SBejga) vom rosa Riesen zur Hilfe und erklärte mir, dass man auch über SSH-Verbindung einen Tunnel herstellen kann. Das ist ganz praktisch, denn SSH lief bei mir ja bereits – ich musste in der Konfiguration des Servers (freeSSHd) nur noch die richtige Einstellung finden:

freeSSHd Tunneling

Danach habe ich überlegt, welches Remote-Desktop-Programm ich am besten verwende. Als Protokoll stand VNC relativ schnell fest – doch welche Implementation davon? Es gibt so viele… Nach einigen herben Enttäuschungen (ultraVNC stach dabei als besonders schreckliches Beispiel heraus) habe ich mich dann für realVNC entschieden. Selbst die äußerst eingeschränkte kostenlose Version reicht für meine Zwecke vollkommen aus ! Im Vergleich zu einigen Kontrahenten sind sowohl der Server, als auch der Client, ziemlich einfach zu konfigurieren. Um den Server nach außen hin abzusichern, bedarf es einer besonderen Einstellung:

Only accept connections from the local machine

Zuerst einmal benötigen wir ein Programm, mit dem wir den SSH-Tunnel zum Server aufbauen können. Für viele dürfte Putty als SSH-Client ein Begriff sein. Baschdii hat mich dagegen auf das Programm Tunnelier aufmerksam gemacht: Und in der Tat! Das Einrichten des Tunnels war ein Klacks ! Zuerst einmal trägt man im Login-Tab die SSH-Daten (Host, Port, Benutzername) ein:

Tunnelier: Login-Tab

Tunnelier: C2S-Tab

realVNC-Client

Eigentlich wollte ich ja Mercury/32 auf meinem Heimserver einsetzen, jedoch hat das Programm mich maßlos enttäuscht. Als Ersatz habe ich für den hMailServer entschieden, der stabil läuft und obendrein auch noch wesentlich einfacher zu konfigurieren ist.

Die Sache funktioniert sogar so gut, dass ich überlege, ob ich nicht weitere Domains auf meinen Heimserver umziehen soll. Bei diesen anderen Domains würden allerdings auch externe Benutzer mit dabei sein: Und genau die würden Probleme machen!

Nein, nicht was ihr denkt ! Wer sich die E-Mail-Protokolle (IMAP, POP3, SMTP) schonmal angegeguckt hat, der wird eins feststellen können: Ein Benutzer kann nicht einfach sein Passwort ändern!
Bei den großen Webmail-Anbietern kann man das über deren Webseite machen – das ist ein Zusatzfeature und von Betreiber zu Betreiber unterschiedlich. Doch wie wird das bei mir möglich sein? Eine Lösung musste her! Und die sieht derzeit so aus:

Hierbei handelt es sich um ein VBScript, das die COM-API benutzt, die der hMailServer bereitstellt. Dieses Script wird die Basis eines kleinen Servers werden, an dem man sich mit seiner E-Mail-Adresse und seinem Passwort anmelden und sein Passwort ändern können wird. Wie man das ganze mit SSL absichern kann, habe ich euch ja schon gezeigt.

Ja, für unerfahrene Benutzer könnte das Passwort ändern wirklich eine kleine Herausforderung werden – die geplante grafische Clientanwendung sollte die Hemmschwelle allerdings auf lange Sicht gesehen senken können.

Update:
Mir ist gerade aufgefallen, dass ich eine wichtige Information vergessen habe! Und zwar muss das Script mit dem Windows Script Host cscript.exe aufgerufen werden. Ansonsten funktioniert die Ausgabe des Ergebniscodes nicht korrekt!

E-Mail-Grüße, Kenny

Ich setze schon seit ein paar Tagen meinen Server komplett neu auf. Da der Server dieses Mal länger im Einsatz sein wird, habe ich mir natürlich auch überlegt, wie ich die Kiste ordentlich absichern kann. So biete ich zu allen Protokollen (z.B. IMAP, POP3, SMTP) auch die Varianten mit vorgeschaltetem SSL an (z.B. IMAPS, POP3S, SMTPS).

Wenn der Server direkt SSL unterstützt, ist das ganze garkein Problem. Dummerweise gibt es auch welche, bei denen das nicht der Fall ist. Das Projekt Stunnel kann dabei Abhilfe schaffen ! Das Programm fungiert als Reverse-Proxy, nimmt SSL-Verbindungen entgegen und leitet die Daten unverschlüsselt an den nichts ahnenden, lokalen Server weiter.

So sehen bei mir z.B. die Definitionen für HTTPS, POP3S, IMAPS und SMTPS aus – alles ganz einfach. Beachtet werden muss nur, dass sich hinter der Portnummer, die unter “connect” angegeben ist, auch wirklich ein Server verbirgt:

Bisher konnte ich noch keine größeren Problem festsstellen. Das Programm scheint auch nicht ganz unbekannt zu sein.

Verschlüsselte Grüße, Kenny

Ich habe die letzten Tage an einem Projekt gearbeitet, für das ich systemweit API-Aufrufe hooken können musste. Leider ist dieses Unterfangen nicht so einfach, wie das, was ich euch letztes Mal präsentiert habe.

Im Internet finden sich einige Lösungen für dieses Problem: Angefangen beim Schreiben von Systemtreibern, bis hin zum Injizieren von Threads in bereits laufende Prozesse. Besonders gut scheint das Paket madHookCode zu sein, das leider weder günstig noch einfach zu haben ist.
Glücklicherweise gibt es die uallCollection, die die gleiche Methode wie das Paket madHookCode zu benutzen scheint. Auch sonst scheinen die beiden Projekte eng miteinander verknüpft zu sein – für den Programmierer, der sich zwischen den beiden Paketen entscheiden muss, ist das jedenfalls ein Vorteil, da die uallCollection komplett kostenlos ist.

Lediglich das Injizieren neu gestarteter Prozesse beherrscht die uallCollection nicht. Aber wozu hat man 10 gesunde Finger? Man kan sich relativ leicht eine Möglichkeit schaffen, um selber auf neue Prozesse zu reagieren:

Für alle, die gerne mal sehen wollen, wie man dieses API-Hooking betreibt, habe ich ein einfaches Programm geschrieben. Mit RegRewrite ist es möglich, Einträge in der Registry durch andere Werte zu ersetzen. Sowohl die neuen Werte, als auch die Konfiguration des Programms werden in der Registry abgelegt . Guckt am besten in den Quelltext, wenn ihr wissen wollt, wie ihr das Programm richtig konfiguriert – es ist, wie gesagt, nur ein kleiner Test gewesen .

Zum Schluss noch etwas Rechtliches:
Der Autor dieses Programms haftet nicht für Schäden an Soft- oder Hardware oder Vermögensschäden, die durch das Benutzen des Programms entstehen, es sei denn, diese beruhen auf einem grob fahrlässigen oder vorsätzlichen Handeln des Autors, seiner Erfüllungsgehilfen oder seiner gesetzlichen Vertreter.
Für Schäden an der Gesundheit, dem Körper oder dem Leben des Nutzers haftet der Autor uneingeschränkt.

Hookende Grüße, Kenny

Ich habe gestern Abend meinen Server neu eingerichtet. Neben freeFTPd und freeSSHd habe ich mich auch dazu entschieden gehabt, Mercury/32 zu installieren. Leider ist das Programm nicht so praktisch, wie ich es mir erhofft hatte.

Deshalb wollte ich es gerade deinstallieren und stand vor einem größeren Problem: Das Programm liefert keine Deinstallationsmöglichkeit mit – auch über Systemsteuerung/Software ist nichts zu machen. Glücklicherweise habe ich im PMail-Wiki eine Deinstallationsanleitung gefunden.

Das einzige, was mich wirklich massiv ärgert: In der Beschreibung heißt es: “There is nothing in the Windows Registry to remove.” – Diese Aussage ist nicht korrekt!

In Wirklichkeit legt das Programm beim Starten automatisch die Schlüssel “HKEY_CLASSES_ROOT\Software\Mercury32″, “HKEY_CURRENT_USER\Software\Mercury32″ und “HKEY_USERS\.DEFAULT\Software\Mercury32″ an. Wer keine Lust hat, dass irgendwelcher Datenmüll nach der Deinstallation zurück bleibt, sollte diese Schlüssel problemlos löschen können.

Aber nicht vergessen: Ich hafte nicht für Schäden an Software, Hardware oder für Vermögensschäden, die durch Anwendung dieser Änderungen entstanden sind oder entstehen könnten.

Mercury-freie Grüße, Kenny