Posts Tagged ‘Verschlüsselung’

Sonntag, 9. Juni 2013

SNMP unter Mac OS X 10.8 Mountain Lion aktivieren

Mac OS X 10.8 (Mountain Lion) bringt Out-of-the-box alles mit, um einen SNMP-Server bereitzustellen. In Verbindung mit cacti zeichne ich so in Echtzeit Systeminformationen meines Mac minis, MacBook Airs und Stephanies Mac mini auf.

Wer Rechner ausschliesslich in seinem heimischen LAN betreibt, kann nachfolgende Minimal-Konfiguration einrichten, damit cacti auf einem Drittserver per SNMP v1 und ohne Passwort darauf zurückgreifen kann:

/etc/snmp/snmpd.conf (Desktop-Rechner)

sysContact  Vorname Nachname 
sysLocation Strasse Strassennummer, PLZ Ort

rocommunity public

includeAllDisks 10%
load    30 10 5

Auf einem portablen Gerät würde ich SNMP abriegeln und den Zugriff nur mittels Benutzernamen und Passwort zugänglich machen. Verwendet man obige Lösung, kann im Flughafen-WiFi oder im Uni-WiFi jedes Script-Kiddie mit nmap-Portscans auf den SNMP-Server aufmerksam werden und mehr oder weniger sensitive Informationen abrufen.

Hierzu eignet sich folgende Konfiguration:

/etc/snmp/snmpd.conf (portabler Rechner)

createUser <username>     MD5 "<password>" DES "<secret>"
authuser   read -s usm  <username> priv  .1

sysContact  Vorname Nachname 
sysLocation Strasse Strassennummer, PLZ Ort

includeAllDisks 10%
load    30 10 5

Sowohl password als auch secret können frei gewählt werden (alphanumerische Zeichenfolge).

Quelle: Setup SNMP V3 USM with encryption.

Daemon (neu) starten

Nach der Konfigurationsanpassung heisst es, den SNMP-Server (neu) zu starten. Dies habe ich mit folgendem Script automatisiert:

#!/bin/sh

echo "Stopping SNMP daemon ..."
sudo launchctl unload /System/Library/LaunchDaemons/org.net-snmp.snmpd.plist

echo "Starting SNMP daemon ..."
sudo launchctl load -w /System/Library/LaunchDaemons/org.net-snmp.snmpd.plist

exit 0

Daemon bei jedem Neustart von Mac OS X laden

Hierzu habe ich die von Apple mitgelieferte plist-Datei /System/Library/LaunchDaemons/org.net-snmp.snmpd.plist angepasst:

	<key>Disabled</key>
	<false/>

Tags: , , , , , , ,
Labels: Linux, Uncategorized

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 4. Oktober 2012

Wie man aus smime.p7s ein .cer-Zertifikat macht

Irgendwie hat es Lotus Notes auf der Arbeit (von mir auch schon liebevoll als „a pile of shit“ bezeichnet) so an sich, dass es so seine Problem mit Private Public-Key-Verschlüsselung hat. Zugegebenermassen habe ich selber auch noch nicht ganz durchblickt, was jetzt was ist — und wann man von Public-Key-Verschlüsselung spricht und wann von Zertifikaten.

Mittlerweile habe ich realisiert, dass die Verschlüsselung dann auf Anhieb klappt, wenn ich das X.509-Zertifikat eines Benutzers in dessen Kontakt importiere (über Actions > Certificates > Import Internet Certificate). Doch manchmal hat man das Zertifikat einfach nicht zur Hand, weil es auf Gottes Erde so viele Arten gibt, den Mailverkehr zwischen zwei Parteien zu verschlüsseln.

So wie heute: Da kam also ein Mail an, welches eine smime.p7s-Signatur im Anhang enthielt (nur sichtbar über den Quelltext des E-Mails). Lotus Notes scheint (zumindest bei uns) nichts damit anfangen zu können.

Ich kopierte die Signatur deshalb manuell in eine Textdatei und speicherte diese als smime.p7s ab. Windows erkennt diese Dateiendung leider nicht. Indem ich .p7s in .p7b änderte, wechselte das Icon der Datei in ein Zertifikat. Ich konnte dieses nun Doppelklicken, Microsoft Certificates wurde gestartet und zeigte mir den Inhalt des Zertifikats an.

Mittels Rechtsklick auf das Zertifikat mit dem Namen der Person wählte ich Actions > Export aus. Ich generierte mir auf diese Weise eine DER-kodierte .cer-Datei. Diese legte ich wiederum als Datei auf dem Desktop ab.

Jetzt erst war es dem „dampfenden Scheisshaufen“ (Lotus Notes) möglich, das Zertifikat dem Kontakt hinzuzufügen. Und somit kann ich seither mit der Gegenpartei verschlüsselt kommunizieren, ohne auf eine webbasierte Secure Mail-Lösung zurückgreifen zu müssen.

Kleingedrucktes: Natürlich benötige auch ich ein entsprechendes Zertifikat. Dieses habe ich über Symantec VeriSign bezogen.

Tags: , , , , , , , , ,
Labels: IT

3 Kommentare | neuen Kommentar verfassen

Mittwoch, 8. Juni 2011

Zertifikatsprobleme mit imapfilter bei einem loadbalancierten Exchange 2010-Server

ACHTUNG: Funktioniert leider doch nicht wie erwünscht.

imapfilter ist das Tool meiner Wahl, um einkommende Mail-Nachrichten in IMAP-Unterordner zu verschieben. Dessen Anwendung habe ich in einem Blog-Artikel erläutert.

Seit mein Arbeitgeber mein E-Mail-Konto von einem Unix-Mailserver auf eine Microsoft Exchange 2010-Lösung migriert hat, gab es Probleme mit den Zertifikaten. (Natürlich hätte ich die Regeln erneut unter Exchange erfassen können, aber der Vorteil von imapfilter ist eben gerade, dass man nur die Serververbindung anpassen muss, und die Mails werden weiter schön sauber sortiert).

imapfilter lässt man bekanntlich beim ersten Verbindungsversuch im interaktiven Modus laufen und akzeptiert dort dann brav das Zertifikat das Mail-Servers:

Server certificate subject: /1.3.6.1.4.1.311.60.2.1.3=CH/ 
1.3.6.1.4.1.311.60.2.1.2=Bern/businessCategory=Government Entity/ 
serialNumber=1834-03-14/C=CH/ST=Bern/L=Bern/O=Universitaet Bern/ 
OU=Informatikdienste - SYS/CN=mail.campus.unibe.ch
Server certificate issuer: /C=BM/O=QuoVadis
Limited/OU=http://www.quovadisglobal.com/CN=QuoVadis 
 Global SSL ICA
Server key fingerprint: CD:10:34:E9:6D:1D:07:09:3D:9E:53:FC:B5:94:B0:10
(R)eject, accept (t)emporarily or accept (p)ermanently? p

Doch leider schien dieser Server in der Folge einfach so den Fingerprint zu wechseln. Als ich imapfilter nach einiger Zeit (und Fehlermeldungen im cron.log) erneut im interaktiven Modus ausführte, erschien folgende Warnung:

Server certificate subject: /1.3.6.1.4.1.311.60.2.1.3=CH/ 
1.3.6.1.4.1.311.60.2.1.2=Bern/businessCategory=Government Entity/ 
serialNumber=1834-03-14/C=CH/ST=Bern/L=Bern/O=Universitaet Bern/ 
OU=Informatikdienste - SYS/CN=mail.campus.unibe.ch
Server certificate issuer: /C=BM/O=QuoVadis
Limited/OU=http://www.quovadisglobal.com/CN=QuoVadis 
 Global SSL ICA
Server key fingerprint: 6D:D9:E8:FF:A3:70:2A:D8:44:10:0C:7D:0E:94:65:FC
ATTENTION: SSL/TLS certificate fingerprint mismatch.
Proceed with the connection (y/n)? y

Leider führte das Bestätigen der Warnung nicht dazu, dass dieses neue Zertifikat akzeptiert wurde (wohl, weil für denselben Server bereits ein anderes Zertifikat gespeichert war). Meine Vermutung: Da mein Arbeitgeber einen loadbalancierte Exchange 2010-Infrastruktur aufgebaut hat, besitzt jeder Server ein anderes Zertifikat (auch wenn beide gegen aussen als mail.campus.unibe.ch in Erscheinung treten).

Der Workaround sah folgendermassen aus:

$ copy ~/.imapfilter/certificates ~/.imapfilter/certificates.old
$ imapfilter -c myconfigfile
(... accept certificate permanently ...)
$ cat ~/.imapfilter/certificates.old >> ~/.imapfilter/certificates

Ab sofort motzte imapfilter nicht mehr über den gelegentlich wechselnden Fingerprint, weil nun einfach beide möglichen Zertifikate in der Datei gespeichert sind.

Tags: , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 25. Mai 2011

Mein neuer PGP-Schlüssel

… lautet neu 2D1F94A8.

Als ich im Sommer 2007 meine Teilzeitanstellung bei der Liip AG antrat, war eine der ersten Aufgaben, einen PGP-Schlüssel zu erstellen.

Ich habe damals den Anfängerfehler begannen, für jede meiner E-Mail-Adressen ein neues Private/Public-Schlüsselpaar zu erstellen. Dieses Problem habe ich heute nun endlich behoben und alle meine E-Mail-Adressen mit einem einzigen universalen Schlüssel ausgestattet und die alten deaktiviert.

Bestehende Schlüssel löschen

Einmal in den Umlauf gebrachte öffentliche PGP-Schlüssel lassen sich nicht mehr löschen. Stattdessen muss der Besitzer diese mittels „revoke“ unbrauchbar machen.

Hierzu war es von Vorteil, dass ich im 2007 bereits bei der Erstellung der Schlüssel mittels gpg --gen-revoke 4A7347BE entschlessende Revoke-Zertifikate erstellt hatte. Diese konnte ich nun endlich einsetzen:

$ gpg --import revocation-4A7347BE.txt
$ gpg --send-keys 4A7347BE

Neue Schlüssel erstellen

Dies geschieht mit grosser Hilfe des GnuPG-Tools ganz einfach mit folgendem Befehl:

$ gpg --gen-key

Als nächstes erstellt man das Revoke-Zertifikat:

$ gpg --gen-revoke 2D1F94A8

Und nun endlich fügt man dem neuen Schlüssel weitere E-Mail-Adressen hinzu:

$ gpg --edit-key 2D1F94A8
> adduid

Sobald man alle E-Mail-Adressen erfasst hat, schickt man den öffentlichen Schlüssel an einen PGP-Keyserver:

gpg --send-keys 2D1F94A8

Um zu überprüfen, dass der Schlüssel beim Server angekommen ist und von anderen Benutzern gefunden werden kann, kann man diesen mittels einer Web-Oberflache abfragen:

pgp.mit.edu

Sonstige nützliche Befehle

Schlüssel vom Server abrufen und lokal speichern:

$ gpg --recv-keys DDB43876

Schlüssel für eine von mehreren E-Mailadresse ungültig machen:

$ gpg --edit-key 2D1F94A8
> uid 2
> revuid
$ gpg --send-keys 2D1F94A8

GUI-Tools für Mac OS X

Mittlerweile existiert für Mac OS X 10.6 ein Software-Paket, dass das Betriebsystem mit allen nötigen (GUI-)Tools ausstattet, die man so benötigt:

GPGTools

Da ich auf einem Rechner noch Mac OS X 10.5 einsetze, musste ich für das dort installierte Apple Mail eine ältere Version des MailBundle installieren.

Tags: , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen