Archiv für Kategorie Sicherheit
Server Name Indication (SNI) unter Apache 2.0.63 (Windows)
Verfasst von Schakko unter Apache, Sicherheit, Windows am 13. Oktober 2009
Heute kam bei uns in der Firma wieder das Thema Zertifikate zu sprechen. Unsere momentane Umgebung auf dem auch dieser Blog gehostet ist, ist ein Windows-System, auf dem Apache 2.0.63 läuft. Einige der Subdomains sind über SSL zugänglich, allerdings besteht bei SSL das generelle Problem, dass pro IP-Adresse nur ein SSL-Zertifikat benutzt werden darf. Wenn man mehrere Subdomains als virtuelle Hosts betreibt (https://v1.ecw.de, https://v2.ecw.de u.s.w.) wird immer nur das Zertifikat des ersten VHosts benutzt (im Beispiel das Zertifikat von https://v1.ecw.de).
Seit einiger Zeit bietet das Unternehmen StartCom kostenlose Zertifikate an. Das CA-Zertifikat von StartCom ist in den aktuellen Browsern sowie im Zertifikate-Speicher von Windows verfügbar. Leider besteht nicht die Möglichkeit, ein kostenloses Wildcard-Zertifikat zu erhalten. StartCom teilt nur Zertifikate vom Typ C1 und nicht C2 kostenlos aus.
Mit dem Wildcard-Zertifikat wäre es möglich gewesen, dass alle VHosts unter https://*ecw.de sich ein Zertifikat teilen. Die andere Möglichkeit, für jede Domain ein eigenes Zertifikat einzurichten, entfällt aus den bereits genannten Gründen: pro IP nur ein Zertifikat.
Seit 2003 existiert die RFC 3456, in der Server Name Indication (SNI) definiert wird. Damit ist es möglich, pro IP-Adresse mehrere Zertifikate zu benutzen. Leider implementieren bis jetzt nur wenige Webserver SNI nativ.
Als ich im Internet nach dem Thema googelte, wurde ich in Wolfs Blog fündig. Er beschrieb die Implementierung und Kompilierung von SNI unter Apache 2.2.xx. Durch seine Ausführungen war ich mehr als motiviert und hatte nun den Plan, SNI unter Apache 2.0.63 und Windows zum Laufen zu bringen.
Durch meine letzten Tätigkeiten beim mod_auth_ldap-Patch hatte ich noch die Sourcen von Apache 2.0.63 auf der Festplatte und sammelte nun die benötigten Dateien zusammen:
- OpenSSL 0.9.8j für Windows mit TLS-Extension – hatte Wolf bereits kompiliert
- SNI-Backport-Patch für Apache 2.0.63
- Backport von ap_vhost_iterate_given_conn für Apache 2.0.63
- zlib in Version 1.1x
Nachdem ich die beiden Backport-Patches in meine Sourcen eingespielt hatte, musste ich noch die Lib-Pfade für die OpenSSL-Dateien einpassen und außerdem das zlib-Verzeichnis inkludieren, da OpenSSL irgendwie auf zlib referenzierte.
Die Kompilierung verlief danach ohne Probleme und ich machte mich an das Deployen der Dateien. Wichtig dabei war, das auf dem Server folgende neue Dateien kamen:
- openssl.exe aus Wolfs-SSL-Package nach Apache2/bin
- libeay32.dll und ssleay32.dll aus Wolfs-SSL-Package nach Apache2/bin bzw. %SYSTEM32%
- Release/libhttpd.dll aus dem Apache-Kompiliat nach Apache2/bin
- modules/ssl/Release/mod_ssl.so nach Apache2/modules
Das Starten des Apaches schlug beim ersten Mal fehl, da ich die libhttpd.dll vergessen hatte zu kopieren. Diese wird aber benötigt, da der Backport von ap_vhost_iterate_given_conn auf diese Library abzielt.
Danach fuhr der Apache normal hoch, ich richtete nun in aller Kürze zwei Virtuelle Hosts in meiner httpd.conf ein und erzeugte zwei Self Signed Certificates. Das Ergebnis war mehr als erfreulich, denn soweit funktionierte alles.
Der nächste Schritt wird für mich sein, dass ich nun unsere Zertifikate von der StartCom-CA signieren lasse.
mod_ssl-with-sni-2.0.63-win32.zip (952.1 KiB, 349 hits)
Erstellen eines Active Directory-Benutzers mit Nur-Leserechten
Verfasst von Schakko unter Active Directory / LDAP, Sicherheit, Windows am 8. Mai 2009
Vor einigen Tagen berichtete ich über das Active Directory-Authentifizierungsproblem bei SMTP-Benutzern auf unserer Astaro-Firewall. Nachdem der Support von Astaro sich die Logs auf der Firewall näher angeschaut hatte, bekamen wir folgenden Tip: Der von uns vorgesehene Benutzer besaß im Active Directory zu wenig Rechte.
Normalerweise wird in Applikationen, z.B. bei mod_ldap für Apache, eine Suchanfrage für einen Benutzer gestartet, in dem überprüft wird, ob eine Gruppe oder eine OU den Benutzer enthält. Außerdem geschieht oft das Binding über den zu autorisierenden Benutzer.
Die Software der Astaro-Firewall geht einen etwas anderen Weg: Der Benutzer wird am Active Directory authentifiziert, danach wird geschaut, ob der Benutzer im Attribut memberOf Mitglied der Gruppe ist.
Unser obiger Benutzer – der Einfachheit halber LDAP-Account genannt – war als normaler Domänen-Benutzer im Active Directory eingetragen und konnte somit Anfragen auf OUs oder Gruppen stellen, aber eben nicht das memberOf-Attribut von speziellen Benutzern auslesen.
Mit Hilfe der Aussage des Supports wiesen wir dem LDAP-Account zum Test im Active Directory die Gruppe “Domänen-Administratoren” zu und siehe da: Die Authentifizierung beim SMTP-Relaying funktioniert.
Nun wollten wir aus Sicherheitsgründen aber natürlich nicht, dass der Benutzer weiterhin mit der Rolle des Domänen-Administrators in der Domäne agierte. Der LDAP-Account sollte nur lesend auf die Attribute von Benutzern zugreifen können.
Damit dieses Vorhaben gelingt, muss die MMC ADSI Edit aufgerufen werden. Falls diese nicht installiert ist, muss sie von der Windows Server 2000/2003-CD aus dem Verzeichnis Support Tools nachinstalliert werden.
Nun wählt man die OU aus, in der dem LDAP-Account Leserechte gewährt werden sollen.

Auswahl der OU
Danach muss im Tab Sicherheit mit einem Klick auf Hinzufügen der LDAP-Account dieser OU hinzugefügt werden.

Sicherheitseinstellungen für diese OU

Auswahl des Benutzers
Der LDAP-Account erscheint nun in der Liste der Gruppen- oder Benutzernamen.

Benutzer, nachdem dieser der OU zugewiesen wurde
Mit einem Klick auf Erweitert, Auswahl des LDAP-Accounts und nochmaligen Klick auf Bearbeiten wird dem Benutzer das Recht Berechtigungen lesen entzogen. Weiterhin war das Recht Inhalt auflisten für unsere Anforderungen nicht nötig.

Erweiterte Sicherheitseinstellungen

Spezielle Berechtigungen setzen
Nach diesen Änderungen konnte nun der Benutzer LDAP-Account auf das memberOf-Attribut zugreifen.
Spam the NSA
Verfasst von Schakko unter Sicherheit am 7. April 2009
Bomben-Stimmung nach einer fast geheimen Attacke auf den König.
Ich liebe Schach.
Bitte senden an: noreply@att.com
Edith: Nach Absenden des Blog-Eintrags ist mein Browser abgestürzt. Zufälle gibt’s…
Nessi – Netzwerk-Simulations-Tool
Verfasst von Schakko unter Eclipse, Netzwerk, Sicherheit am 29. Januar 2009
Nessi steht nun als OpenSource-Projekt unter der Apache 2.0 License zum Download bereit. Mit Nessi lassen sich Netzwerke und Angriffsszenarien simulieren. Das Tool basiert auf Eclipse.
HTC Touch Diamond / WPA2 / PEAP / Windows Server 2003
Verfasst von Schakko unter HTC Touch Diamond, Sicherheit, Windows am 9. Dezember 2008
Szenario: HTC Touch Diamond über WPA2 AES mit Hilfe von RADIUS/IAS an das Firmen-Netzwerk anbinden.
Nicht nur ich, sondern auch andere Personen haben das Problem, dass der Wifi-Manager im HTC Touch Diamond bei ausgewähltem PEAP meldet, dass man ein persönliches Sicherheitszertifikat benötigt.
Im Internet gibt es einige Hinweise, dass man entweder ValidateServerCert auf “0″ setzen soll -so habe ich es vor einigen Tagen auch in diesem Blog geschrieben- oder aber, dass man Securew2 benutzt.
Beides reichte bei unserem Netzwerk nicht aus. Deshalb hier eine kurze Anleitung, wie es funktioniert.
Zuerst muss auf dem Domänen-Controller – bei uns ist das ein Windows Server 2003 R2 – das Server-Zertifikat exportiert werden. Microsoft stellt dazu unter http://www.microsoft.com/downloads/details.aspx?FamilyID=6123EB55-6590-4643-8E7F-11C177104DE2&displaylang=en das Tool SslChainSaver zur Verfügung. Dies muss auf der Kommandozeile aufgerufen werden:
sslchainsaver $DOMAENENCONTROLLER
Man erhält nun zwei XML-Dateien und einige Zertifikate. Das Windows Mobile 6-Zertifikat ($DOMAENENCONTROLLER.wm6.xml) muss in _setup.xml umbenannt und danach zu einer CAB gepackt werden:
makecab _setup.xml domaene_rootcert.wm6.cab
Die domaene_rootcert.wm6.cab muss auf das HTC Touch Diamond kopiert und installiert werden. Unter Einstellungen > System > Sicherheitszertifikate sollte nun die Zertifizierungsstelle erscheinen.
Als nächstes folgt der Export des Benutzerzertifikats nach PCKS#12. Auch hier gibt es wieder viele Anleitungen wie man das macht: Unter Windows Server 2003 die MMC starten, das Zertifizierungsstellen-Snap-In laden (muss mit dem Domänen-Controller verbunden werden) und dann unter Ausgestellte Zertifikate den Benutzer auswählen, Details > In Datei kopieren und PKCS#12 auswählen. Aus welchen Gründen auch immer war die PCKS#12-Option bei unserem Server deaktiviert.
Deshalb gilt nun folgendes: Auf einem Client-Computer den Internet Explorer starten und die Adresse http://$DOMAENENCONTROLLER/certsrv aufrufen und sich mit seinem Benutzernamen und Passwort authentifizieren. Nun muss ein neues Benutzer-Sicherheitszertifikat im PCKS#10-Stil angefordert werden. Dieses muss nach der Erzeugung in der Zertifizierungsstelle logischerweise auch im IE installiert werden.
Danach kann man im IE 8 unter Extras > Internetoptionen > Inhalt > Zertifikate > Eigene Zertifikate sein eben gerade erstelltes Zertifikat auswählen und dieses als PCKS#12 exportieren.
Die exportierte Datei muss ebenfalls auf das HTC Touch Diamond kopiert und danach mit einem Doppelklick installiert werden.
Nun kann die WLAN-Verbindung über PEAP und ohne Securew2 erfolgen.
network-manager-pptp unter Ubuntu 8.10
Verfasst von Schakko unter Linux, Sicherheit am 24. November 2008
Nach dem Update auf Ubuntu 8.10 letzten Monat gingen meine VPN-Verbindungen über den Jordan. Ich also eben gerade meine Verbindung zum Firmennetzwerk neu eingerichtet und siehe da: Es funktioniert nicht.
In /var/log/syslog war Folgendes zu lesen:
Nov 24 17:12:32 laptop kernel: [ 1034.472477] PPP generic driver version 2.4.2 Nov 24 17:12:32 laptop modprobe: WARNING: Not loading blacklisted module ipv6 Nov 24 17:12:32 laptop pppd[7594]: pppd 2.4.4 started by root, uid 0 Nov 24 17:12:32 laptop pppd[7594]: Using interface ppp0 Nov 24 17:12:32 laptop pppd[7594]: Connect: ppp0 <--> /dev/pts/1 Nov 24 17:12:32 laptop pptp[7603]: nm-pptp-service-7589 log[main:pptp.c:314]: The synchronous pptp option is NOT activated Nov 24 17:12:32 laptop pptp[7619]: nm-pptp-service-7589 log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request' Nov 24 17:12:33 laptop pptp[7619]: nm-pptp-service-7589 log[ctrlp_disp:pptp_ctrl.c:739]: Received Start Control Connection Reply Nov 24 17:12:33 laptop pptp[7619]: nm-pptp-service-7589 log[ctrlp_disp:pptp_ctrl.c:773]: Client connection established. Nov 24 17:12:33 laptop pptp[7619]: nm-pptp-service-7589 log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request' Nov 24 17:12:33 laptop pptp[7619]: nm-pptp-service-7589 log[ctrlp_disp:pptp_ctrl.c:858]: Received Outgoing Call Reply. Nov 24 17:12:33 laptop pptp[7619]: nm-pptp-service-7589 log[ctrlp_disp:pptp_ctrl.c:897]: Outgoing call established (call ID 0, peer's call ID 5120). Nov 24 17:12:34 laptop pppd[7594]: MS-CHAP authentication failed: Nov 24 17:12:34 laptop pppd[7594]: CHAP authentication failed Nov 24 17:12:34 laptop pppd[7594]: Connection terminated. Nov 24 17:12:34 laptop NetworkManager: <info> VPN plugin failed: 1
Sehr ungewöhnlich – Meine Zugangsdaten (Benutzername, Passwort und Domäne) waren im NetworkManager definitiv korrekt eingetragen.
Ich aktivierte in /etc/ppp/options die Definition “debug” und sah im syslog
Nov 24 17:34:26 laptop pppd[9661]: sent [LCP EchoReq id=0x0 magic=0x6fbd7073] Nov 24 17:34:26 laptop pppd[9661]: rcvd [LCP EchoReq id=0x0 magic=0xf9418ec] Nov 24 17:34:26 laptop pppd[9661]: sent [LCP EchoRep id=0x0 magic=0x6fbd7073] Nov 24 17:34:26 laptop pppd[9661]: rcvd [CHAP Challenge id=0x9a <d25f15a6a126b77cba1ea38f32f093c6>, name = "pptp"] Nov 24 17:34:26 laptop pppd[9661]: sent [CHAP Response id=0x9a <729e199b9717cc49aeacbf4f5f0fe79800000000000000002d555861ec2b61ebb1442f3519018527ad5879336be6323f00>, name = "$DOMAIN\\\\$BENUTZERNAME"] Nov 24 17:34:26 laptop pppd[9661]: rcvd [LCP EchoRep id=0x0 magic=0xf9418ec] Nov 24 17:34:26 laptop pppd[9661]: rcvd [CHAP Failure id=0x9a ""] Nov 24 17:34:26 laptop pppd[9661]: MS-CHAP authentication failed: Nov 24 17:34:26 laptop pppd[9661]: CHAP authentication failed Nov 24 17:34:26 laptop pppd[9661]: sent [LCP TermReq id=0x2 "Failed to authenticate ourselves to peer"] Nov 24 17:34:26 laptop pppd[9661]: rcvd [LCP TermReq id=0x3 "Authentication failed"] Nov 24 17:34:26 laptop pppd[9661]: sent [LCP TermAck id=0x3]
Wichtig ist die CHAP-Response: Aus welchen Gründen auch immer werden die Backslashes doppelt escapt – was zur Folge hatte, dass unsere Firewall die Authentifizierung am IAS mit $DOMAIN\\$BENUTZERNAME durchführte. Völliger Mumpitz.
Deshalb änderte ich NetworkManager die Einträge so, dass ich die Domäne leer ließ und als Benutzernamen $BENUTZERNAME@$DOMAIN festlegte. Somit funktionierte es dann auch.
WPA & PEAP unter Windows Mobile 6.1 ohne Serverzertifikate
Verfasst von Schakko unter Handy, Sicherheit am 15. August 2008
Um unter Windows Mobile 6.1 eine Verbindung mit einem WPA-gesichtern WLAN Verbindung aufzunehmen, das PEAP ohne Server-/Clientzertifikate benutzt, muss folgendes gemacht werden:
Auf dem Handy/PDA einen Registry-Editor installieren, z.B. von http://www.phm.lu/products/.
Danach dann unter HKEY_LOCAL_MACHINE\Comm\EAP\Extension\25 den DWORD-Eintrag ValidateServerCert auf “0″ setzen. Sollte der Eintrag nicht existieren, muss er hinzugefügt werden.
iSCSI über die Kommandozeile
Verfasst von Schakko unter Sicherheit, Windows am 29. Juli 2008
Heute habe ich die Sicherungsstrategie für unsere virtuellen Hosts implementiert. Alle Daten werden ersteinmal auf einer iSCSI-Festplatte gesichert und am Ende dann aufs Band geschrieben. Dabei kam dann die Frage auf, ob man sich über die Kommandozeile mit Targets verbinden kann. Flo hatte schnell die Antwort parat:
iscsicli
ist der gewünschte Befehl.
Zugriff auf meine Dateien
Verfasst von Schakko unter Linux, Sicherheit, Windows, ckl-net am 3. Juli 2008
Heute habe ich seit einiger Zeit mich mal wieder mit meinem Server befasst. Ursprünglich war für heute Abend geplant, dass ich vom NFS-Protokoll auf WebDAV umschwenke. NFS hat für mich das Problem, dass der NFS-Dienst für Windows (SFU) nicht ganz rund läuft und ich außerdem aus der Firma nicht an meine Dateien heran komme.
Deshalb wollte ich Apache + WebDAV über SSL für den Zugriff nutzen. Nachdem ich alles eingerichtet hatte -was recht fix ging- musste ich leider feststellen, dass die Übertragungs-Performance mehr als mies ist: mehr als knapp 120 KByte gingen nicht über die Leitung.
Deshalb kam ich zu dem Entschluss: Weg von NFS, weg von WebDAV – hallo SFTP! Problem dabei -weswegen ich auch WebDAV einsetzen wollte-: mit den Clients SftpDrive oder WebDrive kann man zwar SFTP-Ressourcen als Laufwerk unter Windows mounten, aber sie kosten Geld.
Nach ein paar Minuten stöbern bin ich über diesen Blog-Eintrag gestolpert, in dem Reddrive erwähnt wird. Ist kostenlos und bindet ein SFTP-Laufwerk im Windows Explorer ein.
Sag was!