[ENC]BladeXP's Blog

Bei Android ist ja Standardmäßig kein CACert im Zertifikatsmanager als Root-CA hinterlegt.

Bei vielen Webdiensten ist ein Verzicht auf ordentliche HTTPS-Sicherheit vielleicht noch akzeptabel, spätestens bei Mails auf dem eigenen Server aber vollkommen inakzeptabel!

Man hat nun verschiedene Möglichkeiten das Problem zu lösen:

• CACert Root Certificate in den Zertifikatsmanager importieren: Umständlich
• VPN verwenden: Möglich
• IMAP über SSH mit ConnectBot tunneln: Einfach

Das Tunneln über ConnectBot geht natürlich nur wenn man Shellzugriff auf den Server hat, was bei einem eigenen Rootserver ja der Fall ist.

Man richtet sich ConnectBot ganz normal, wie jeden anderen SSH Clienten ein. Ich selbst bevorzuge ein Passwortloses Login über das integriert Public Key Verfahren welche mit einer Passphrase geschützt sind.

Im nächsten Schritt baut man den Tunnel auf, hierzu einfach auf die Verbindung im ConnectBot gehen (langer Druck mit dem Finger) und dann die Portforwardings bearbeiten, folgende benötigen wir für IMAP und SSH:

• SMTP von 1125 auf 127.0.0.1:25
• IMAP von 1143 auf 127.0.0.1:143

Sobald man jetzt eine Verbindung zu diesem Host aufbaut wird automatisch auch die Portweiterleitung aktiviert. Im Mailclient wird jetzt immer 127.0.0.1 (alternativ auch gerne localhost) als Server verwendet, der Port für IMAP ist dann die 1143 und für SMTP nimmt man 1125. Die Verbindung zum Server ist aber nicht Verschlüsselt, das übernimmt ja der gute alte ConnectBot für uns. Ob man für den Postausgangssserver (SMTP) ein Passwort benötigt kommt auf die Konfiguration des Mailservers an, oft benötigt man kein Login wenn man über SSH zugreift, da es sich dann um eine lokale Verbindung hat die meistens in der my_networks vom Postfix schon erlaubt ist.

Abgesehen davon kann man den Mailclient wie gewohnt verwenden und konfigurieren, einen Nachteil möchte ich aber nicht verschweigen: Automatische Mailchecks oder Aktionen die ausgeführt werden wenn kein ConnectBot im Hintergrund läuft funktionieren mit dieser Lösung natürlich nicht. Wird dies benötigt muss man also auf den umständlichen Weg das CACert Certificate importieren.

Schöner fände ich es wenn man Root-CAs einfacher importieren könnte, und nicht dieses umständlichen Weg gehen müsste, der noch dazu Root Rechte erfordert! Leider kann Android auch kein OpenVPN ohne Root, so macht das mit einem VPN natürlich auch keinen Spaß :-(

Es passiert so ca. 2 mal pro Jahr: ICQ geht nicht mehr!

Genau zu dieser Zeit gibt es dann in diversen Foren Beiträge das die Welt untergeht und man ohne ICQ nicht mehr länger leben möchte.

Sind wir doch mal ehrlich: Warum verwendet man überhaupt ein zentrales Protokoll wo man genau weiß das der Serviceprovider ausdrücklich die Verwendung alternativer Clients verbietet?

Als Antwort gibt es dann den Klassiker "Meine Freunde haben doch alle ICQ!", was ich aber nicht als Grund zählen lasse warum man dieses proprietäre Protokoll verwenden muss. Wenn niemand endlich mal anfängt auf alternative (offene) Protokolle umzusteigen, schiebt man doch diese Art von Problemen immer und immer wieder vor sich hin. Ich selbst habe mein ICQ (ja, ich war auch mal jung und dumm) schon vor langer Zeit abgeschaltet, wer mich erreichen möchte kann mir ne Mail schreiben oder aber auf Jabber umstellen.

Just my 2 cents...

Ein guter Link den ich erst heute wieder gefunden habe: Link

Der sollte so einige Fragen zu Verschlüsselung beantworten, gerade für Einsteiger ist das immer wieder ganz nett. Neulich gab es hierzu ne Diskussion im Forum von Ubuntuusers (Link natürlich vergessen).

Momentan gibt es im Linux Kernel 4 Sicherheitserweiterungen die alle mehr oder weniger eine MAC (Mandatory Access Control) nachrüsten. Diese sind:

• SELinux
• SMACK
• TOMOYO
• AppArmor

SELinux wird schon immer von Fedora/RedHat/CentOS verwendet, das sind auch die Leute welche hinter diesem System stehen. Die Anpassung ist natürlich bei diesen Distributionen am besten. SELinux benötigt einige Anpassungen im Userspace, was mich persönlich etwas stört.

SMACK habe ich mir bisher noch garnicht angesehen, ggf. hat jemand schon damit Erfahrungen gemacht. Soweit ich weis ist es aber auch bei keiner Distribution Standard, und auch SMACK benötigt einige Anpassungen im Userspace.

TOMOYO ist seit 2.6.30 im Kernel dabei, das ganze ist eine relativ junge Sicherheitserweiterung bei der noch einige Features fehlen. Der IMHO größte Vorteil von TOMOYO ist dass man einen schönen Live Editor (tomoyo-editpolicy) hat, mit diesem kann man den Learning Mode von TOMOYO prima überprüfen und auch neue Regeln eintragen sowie alte Löschen. Die Userspace Tools von TOMOYO sind relativ klein, so dass man fast nichts nachinstallieren muss.

AppArmor ist ein etwas älterer bekannter, welcher mit Kernel 2.6.36 auch endlich Einzug in den Standardkernel erhält. Unschön an AppArmor finde ich dass die Userspace Tools etwas fett sind, dies fällt einem aber erst auf wenn man sie zum Beispiel unter Arch installiert und massig Abhängigkeiten nachinstalliert werden.

Problematisch finde ich eigentlich nur das viele Distributionen unterschiedliche Sicherheitserweiterungen installieren. Ohne einen Standard werden viele Leute sowas einfach nicht einrichten wollen, da man es für jede Distribution neu lernen darf. Ubuntu hat z.B. AppArmor, Fedora SELinux und Arch kann TOMOYO und AppArmor, openSuSE wiederum verwendet auch AppArmor, usw...

Wenn jetzt noch GRSecurity in den Kernel kommt haben wir alle Sicherheitserweiterungen die mir bekannt sind im Kernel, doch keine einzige die irgendwie ein Standard wäre. Schade eigentlich, da geht viel Potential verloren... :-/

Gerade für Serverdienste wäre das erstmal wichtiger als Unity, Themes oder Wallpapers!

Endlich ist das Programm der Ubucon 2010 Online. Ich selbst habe mir natürlich gleich ein paar Vorträge ausgesucht die ich auf jeden Fall besuchen werde.

Freitag

Freitag haben wir natürlich erstmal die Anreise in Leipzig, danach geht es (wie jedes Jahr) direkt auf die Ubucon um beim Aufbauen mit zu helfen. Es gibt hierzu auch eine Helferliste, in welcher ich mich selbst aber noch nicht eingetragen habe. Da ich aber schon jedes Jahr mitgeholfen haben kann man natürlich wieder mit mir Rechnen.

Abgesehen davon werde ich zusammen mit einigen Kollegen eine Diskussion über unsere ganzen Server welche wir für Ubuntuusers.de und den Ubuntu Deutschland e.V. verwenden mitmachen. Dies ist mir sehr wichtig da eine bessere / zuverlässigere Serverbasis natürlich wichtig für die vielen Dienste ist, welche wir den Anwendern kostenfrei und in unserer Freizeit zu Verfügung stellen.

Samstag

Am Samstag werde ich mir auf jeden Fall den Talk / Workshop über Mercurial ansehen, welches ich zwar schon lange verwende, aber wo man doch immer wieder was neues lernen kann.

Die Server-Fragestunde steht natürlich auch wieder auf meinem Programm, was es mit Verschlüsselung auf sich hat konnte mit das Programm leider nicht verraten :-/

Sonntag

Am Sonntag ist natürlich der IPv6 Talk / Workshop genau das was ich Suche. Ich verwende IPv6 bei mir Zuhause ja schon eine Weile über einen SixXS Tunnel oder bei Hetzner für meinen Server, aber auch hier kann man noch viel lernen.

Das Closing-Event ist natürlich wie jedes Jahr ein Pflichtbesuch, zumindest wenn es sich mit der Abfahrtszeit von meinem Zug vereinbaren lässt.

Da mir Ubuntu 10.04 nicht wirklich gefällt habe ich heute meinen Homeserver von Ubuntu Hardy auf Debian Lenny aktualisiert.

Das ganze habe ich natürlich ohne Neuinstallation gemacht, sonst hätte sich dieser Post wohl auch kaum gelohnt!

Es gibt dabei ein paar Sachen zu beachten, die ich hier nur mal grob auflisten möchte:

1. Man muss die Debian Keys importieren, damit apt nicht wegen Paketen jammert die nicht vertrauenswürdig sein sollen.
2. Es müssen vor dem Reboot und nach dem dist-upgrade, alle Pakete von Ubuntu durch die von Debian getauscht werden. Tut man das nicht wird das System ggf. nicht booten, da die Initramfs fehlerhaft sein könnte.
3. Das Paket locales muss installiert werden (wirft einem das dist-upgrade leider runter), und man muss libc6 neu installieren da sonst localedef nicht gefunden werden kann und so das erzeugen der locales fehlschlägt.

Das waren eigentlich die 3 wichtigsten Punkte die mir dabei aufgefallen sind.

Natürlich sollte man ein solches Update nur machen wenn man weis was man tut, und auch in der Lage ist die entstandenen Probleme selbst wieder fixen.

Wer wie ich oft SSH verwendet und sich gerne darüber aufregt das ein Login bei großen Schlüsseln (z.b. 4096 Bit) oft lange dauert kann SSH etwas pimpen.

OpenSSH kann nämlich sog. Multiplexing, d.h. es kann mehrere Sessions zum gleichen Server über nur eine Verbindung verwalten. Der Vorteil ist das man sich nicht über jeden Channel neu Authentifizieren muss, und somit die neue Session ziemlich schnell verfügbar ist. Nachteil ist natürlich das beim Abbruch der einen TCP Verbindung auch alle Sessions auf einmal weg sind :-/

Das ganze wird folgendermaßen in der ~/.ssh/ssh_config konfiguriert:

ControlMaster auto
ControlPath /tmp/ssh-%h-%r-%p

ControlPath sorgt dafür das der Modus aktiviert wird und automatisch eine neue multiplex Session gestartet wird wenn es noch keine gibt. Als Pfad für das nötige Controlsocket wird der unter ControlPath angegebene Pfad verwendet. Die Platzhalter werden prima in der Manpage von ssh_config erklärt (man 5 ssh_config).

Wenn man in der ssh_config spezifische Einstellungen für bestimmte Hosts hat sollte man diese Einstellungen ganz oben in die Datei schreiben, so das diese für jeden Host gelten.

Mit dem neuen OpenSSH 5.6 das gestern veröffentlich wurde gibt es noch eine zusätzliche, aber sehr nützliche Option:

ControlPersist on

Was dafür sorgt das auch beim schließen der letzten noch aktiven Session die Verbindung für immer aktiv bleibt. Natürlich sollte man aus Sicherheitsgründen statt on lieber 10m Eintragen was für 10 Minuten steht.

Auf der Ubucon 2008 habe ich ja einen Vortrag über LVM gehalten.

Das ganze hat mir viel Spaß gemacht, und ich denke auch bei den Teilnehmern kam das Thema gut an. Einziger Kritikpunkt waren die LVM-Snapshots, den diese konnte man damals zwar erstellen, aber nicht einfach mal eben zurücksichern.

Dies ist jetzt möglich da Kernel und LVM-Tools die nötigen Patches erhalten und akzeptiert haben. Man benötigt dafür aber Kernel 2.6.33 sowie LVM-Tools in Version 2.02.58 welche es leider nicht mehr in Lucid geschafft haben. Somit muss man auch auf der aktuellen LTS Version, auf dieses sinnvolle Feature verzichten.

Debian Testing hat die benötigte Version der LVM-Tools schon in den Paketquellen, allerdings ist zu hoffen das 2.6.33 es vielleicht doch noch schafft.

Heute haben wir pyNeighborhood in der Version 0.5.1rc2 veröffentlicht. Hier der Eintrag vom Launchpad.

Für Ubuntu gibt es natürlich wieder ein PPA (Link), für Arch Linux ein AUR (Link) und für Debian kommen Pakete sobald die Final Version 0.5.1 veröffentlicht wurde.

Es werden noch freiwillige gesucht die im Launchpad die Übersetzungen für andere Sprachen wie Deutsch und Englisch fertig machen (Link) könnten.

Da ich ja neulich von Ubuntu auf Arch gewechselt bin, habe ich dort natürlich keine Tools um Debian Pakete für testing oder diverse PPAs zu bauen.

Dies ist natürlich ärgerlich da ich das ein oder andere Paket natürlich weiterhin für Debian und Ubuntu anbieten will, insbesondere pyNeighborhood ist ja eher für Einsteiger und damit Ubuntu Anwender gedacht.

Damit ich weiterhin diese Pakete bauen kann habe ich mich für schroot entschieden. Damit kann man einfach und effektiv verschiedene chroot Umgebungen verwalten, so das ich mit einem einzigen Befehl in einem Debian System bin.

Für die Installation der benötigen Programme habe ich yaourt verwenden:

yaourt -S debootstrap schroot

Der nächste Schritt bestand daraus ein neues Logical Volume einzurichten und darauf dann ein Debian Basissystem zu packen:

sudo lvcreate -L 5G -n sid main
sudo mkdir /mnt/sid
sudo mount /dev/mapper/main-sid /mnt/sid
sudo debootstrap --arch=amd64 sid /mnt/sid http://ftp.de.debian.org/debian
sudo umount /mnt/sid

Nun müssen nur noch 2 Sachen gemacht werden damit man schroot verwenden kann. Das wichtigste wäre die Anpassung der Datei /etc/schroot/schroot.conf, hier muss dies am Ende der Datei (alternativ auch sonstwo) einkopiert und angepasst werden:

[sid]
type=block-device
device=/dev/mapper/main-sid
root-groups=wheel

Damit kann jeder Benutzer der in der Gruppe wheel ist auch schroot voll verwenden. Natürlich sollte man bei größeren Sicherheitsanforderungen die Manpage der schroot.conf aufmerksam durchlesen! Zusätzlich sollte man noch in der Datei /etc/schroot/default/nssdatabases die Zeile mit networks kommentieren, da sonst ein Start der chroot Umgebung nicht funktioniert, dies liegt daran das Arch Standardmäßig keine /etc/networks hat welche vom Startscript kopiert werden könnte.

Nun kann man mit

schroot -c sid -p

eine Benutzershell in chroot öffnen. Dabei wird sogar das /home-Dateisystem vom Hostsystem übernommen.