GnuPG, S/MIME, Thunderbird und Firewalls

Ich selbst bevorzuge für die Verschlüsselung von E-Mails GnuPG. Ich brauch da keine Infrastruktur Dritter und das gefällt mir. Einmal eingerichtet läuft das über Jahre. Einfach so. Ohne Kosten.

Für S/MIME spricht jedoch, dass der Standard von viel mehr MUAs unterstützt wird und dass die Handhabung oft einfacher ist. Kein zu unterschätzendes Argument, wenn man eine ganze Redaktion zu versorgen hat, die Frickeln „doof“ findet und von Windows über Apple bis Linux alles (un-)mögliche als Betriebssystem nutzt.

Ein Prüfstein war für mich diese Woche die Handhabung von GnuPG und S/MIME, wenn man mit seinem Laptop hinter der schulischen Firewall hockt, bei der nur Port 80 und Port 443 offen sind und man deswegen auf Webmail angewiesen ist. Thunderbird kommt hier schlicht nicht ins Netz.

Was dann?

S/MIME

Im Webmailfenster (wir nutzen EGroupware) auf speichern klicken.

Auf die EML Datei doppelt klicken – der lokale Thunderbird macht die Datei auf, entschlüsselt diese und fertig.

Versenden von verschlüsselten Nachrichten ist dann kein so ein großer Spaß mehr.

Man verfasst die Nachricht im Thunderbird und speichert diese im Ordner „Entwürfe“ ab. Dann klickt man diese rechts an und speichert diese über den entsprechenden Eintrag im Kontextmenü auf dem Desktop als EML.

Diese EML kann man dann als Anhang an eine Mail dran hängen, die man über den Webmailer verschickt. Beim Empfänger wird der Anhang entschlüsselt angezeigt – die Mail mit dem Anhang oben, der einst verschlüsselte Anhang unten (ähnlich wie bei einer Weiterleitung).

GnuPG

Die Nachricht – und hier nur den Nachrichteninhalt – per Copy and Paste in einen lokalen Texteditor werfen und als irgendwas.asc speichern.

Dann über das Kontextmenü (oder per Doppelklick – je nach Konfiguration) der Datei z.B. mit KGpg (je nach Desktop) öffnen und die Passphrase eingeben. Die neu erzeugte, entschlüsselte Nachricht im Editor lesen.

Das Schreiben von Nachrichten erfolgt ebenfalls im lokalen Texteditor. Man speichert die Datei lokal ab, verschlüsselt den Inhalt (Kontextmenü der Datei) und kopiert diesen aus der neu angelegten Datei mit der Endung asc wieder in den Webmailer zurück.

Und nun?

Das einfache Lesen von S/MIME-verschlüsselten Nachrichten unter den genannten Bedingungen wird in der Redaktion sicherlich gut ankommen. Ich selbst finde weiterhin den Weg für Lesen und Schreiben bei GnuPG sympathischer. Das ist zwar in beiden Fällen fummelig – aber einheitlich, unterliegt einer Logik, einer Vorgangsweise und nicht derselben zwei.

Eine berechtigte Frage ist natürlich, wie oft so was vorkommt und ob man nicht schlicht warten kann mit dem Lesen und Schreiben verschlüsselter Nachrichten, bis man wieder zu Hause / im Office ist.

Ach ja – getestet habe ich mit Textmails. Wie sich das mit HTML Mails und Anhängen anfühlt … die Tests stehen noch aus.

KDE Rekonq Suchmaschineneintrag

Suchmaschineändern_001

… eine Kleinigkeit für den KDE-Merkzettel, da es bei dem Versuch, https://startpage.com als meine bevorzugte Suchmaschine für den Browser Rekonq einzurichten, hier gerade etwas hakelte.

Mit dem folgenden Eintrag

https://startpage.com/do/search?query=\{@}

funktioniert die Eingabe von Suchbegriffen in die URL Zeile, sofern man diesen Eintrag als Standard in den Rekonq-Einstellungen definiert. Ansonsten kann man ein beliebig festlegbares Webkürzel voranstellen.

Jameica / Hibiscus 2.6.x Trouble

Das von mir seit vielen Jahren ohne Probleme eingesetzte Banking-Duo Jameica/Hibiscus zickte unter Ubuntu 12.04.4 64 Bit seit dem Update auf 2.6 und nervte durch unmotivierte Abstürze.

Da sich aus den Absturzmeldungen für mich kein klares Bild ergab, nutzte ich eine Zeit lang wieder Onlinebanking im Browser und wartete auf die nächste Version des Duos. Jedoch – auch das Ende Dezember 2013 erschienene 2.6.1 brachte keine Besserung. Geholfen hat bei mir erst der Umstieg von openjdk6 auf openjdk7:

sudo apt-get remove icedtea-6-jre-* openjdk-6-jre*

Ubuntu installiert dann gleich von sich aus openjdk-7 als Alternative. Das Plugin icedtea-7-plugin muss von Hand nachinstalliert werden.

LM 6.1

Auf linuxmuster.net liegt seit ein paar Tagen die Beta der nächsten Version als VM für alle möglichen VM Hostsysteme. Ich hab das hier mal unter VirtualBox auf meinem Laptop für eine Konfiguration ausprobiert, die nur green und red als Interfaces nutzt.

Die heruntergeladenen Archive lokal mit tar xvfJ archiv.tar.xz entpacken und dann in VBox über das Menü /Datei /Appliance importieren in VBox … naja, eben: importieren. Dann erfolgen einige Anpassungen.

Da ich auf meinem, doch etwas älteren, Laptop als VMHost nur 4GB RAM habe, gab ich der Firewall die voreingestellten 256MB, dem Server 1GB und dem Client unter Lubuntu 512MB. Da musste mein Laptop zwar schwer schnaufen – und auch der virtualisierte Server – aber es läuft, wenn man Lubuntu 12.04 von der Alternate CD installiert .

Firewall

lm6-1_ipfire - Ändern_001

Die MAC Adresse der Netzwerkkarte, die später die rote Schnittstelle werden soll, habe ich hinten mit einer 0 versehen und lasse diese NATen.

lm6-1_ipfire - Ändern_002

Die Schnittstelle, die später mal grün sein soll, versah ich am Ende der MAC mit einer 1 und stellte diese auf „Internes Netzwerk“.

lm6-1_ipfire - Ändern_003

Blau will ich hier auf dem Laptop zum Testen nicht nutzen, also hab ich das „Kabel“ schlicht entfernt und die Schnittstelle nicht angeschlossen.

lm6-1_ipfire [wird ausgeführt] - Oracle VM VirtualBox_004

Beim Hochfahren des IPCop wählte ich nicht den voreingestellten PAE Kernel. Die Firewall kommt mit 256 MB RAM. Da erschien mir das nicht sinnvoll zu sein.

lm6-1_ipfire [wird ausgeführt] - Oracle VM VirtualBox_005

IPFire motzt dann beim Hochfahren, dass es seine Schnittstellen nicht finden kann, was an dieser Stelle nicht weiter stört.

lm6-1_ipfire [wird ausgeführt] - Oracle VM VirtualBox_006

Hat man sich als root und dem Passwort muster einmal eingeloggt, kann man sich durch den Setup-Prozess von IPFire hangeln, den ein setup auslöst.

Die bestehende Zuordnung der Netzwerkkarten muss man zuerst entfernen und dann neu vornehmen. Die vorher vergebenen MAC Adressen helfen bei der Orientierung.

Ein Ping ins Netz zeigt nach Beendigung des Setups, ob alles geklappt hat.

Server

Das Netzwerkinterface des Servers konfiguriert man sich in VBox wie die grüne Schnittstelle des IPFire als „Internes Netzwerk“.

Im Detail ist der Setup-Prozess im Handbuch für Version 6.0 beschrieben.

Nach dem Hochfahren des Servers einloggen (linuxadmin, muster), etwas Zeit verstreichen lassen, bis der Server Kontakt über die VBox interne Schnittstelle zum IPFire erhalten hat und dann mit ping testen, ob die Namensauflösung klappt. Dann mit sudo apt-get update ; sudo apt-get dist-upgrade evtl. vorhandene Updates einspielen und nun – nach einem Wechsel in eine Root-Shell mit sudo su – – das eigentliche Setup beginnen durch Eingabe von

linuxmuster-setup –first

Das kann dauern. LM6.1 zieht nun alle möglichen Pakete aus dem Netz, bis der eigentliche Installationsdialog beginnt (zu diesem siehe den Link zum Handbuch weiter oben).

Subnetting hab ich nicht aktiviert. Ich will vor allem mit Linbo spielen, weil wir schulintern gerade einige Höllenprobleme mit einer zickigen Hardwareklasse (Lenovo T410) haben. Alle anderen Einstellungen habe ich deswegen so übernommen, wie vom Installer als default vorgesehen.

Clients

Die Netzwerkkarten von virtuellen Clients werden wie die grüne Schnittstelle am IPFire bzw. wie die Serverschnittstelle als Internes Netzwerk konfiguriert.

Will man echte Clients testen, dann muss man sich mehr Arbeit machen. In diesem Fall legt man sich auf dem Host-System eine Netzwerkbrücke auf einer unkonfigurierten physischen Schnittstelle ethX an und verpasst dieser eine passende interne IP (siehe Netzwerksetup Homeserver NXT). Statt mit dem Internen Netzwerk von VBox verbindet man dann IPFire und Server mit dieser Bridge.

Ich weiß nicht, ob ich das extra schreiben muss, aber das klappt nur mit Netzwerkschnittstellen am Host in die man ein Kabel stecken kann. WLAN Interfaces sind außen vor. Wer WLAN virtualisiert und keine AccessPoints hierzu nutzen will, kann sich mit USB WLAN Sticks helfen, die man als USB Gerät an die VM durchreicht.

An diese physikalische Schnittstelle des Hosts hängt man einen Switch und an den Switch wiederum den physikalischen Client. Voila.

Sofern die MAC Adressen gleich bleiben, kann man dann zwischen dem physikalischen, ge-bridge-ten Netz und dem VBox internen Netz an den ausgeschalteten VMs hin- und her-schalten wie man will.

Datenschutz

Schritt für Schritt durchkämme ich meine Installationen auf Servern und Rechnern auf der Suche nach datenschutzkritischen Anwendungen. Das braucht Zeit, weil in den letzten Jahren viel schlicht gewachsen ist, einem auch quelloffene Software nicht immer hilft, weil man immer wieder etwas übersieht oder weil man keine funktionierende Alternativen zu haben scheint.

Ein Beispiel: Allein Firefox in den Griff zu bekommen ist nicht einfach, weil Mozilla eng mit Google kooperiert. Hier im KvFG Wiki habe ich einige sinnvolle Einstellungen und Addons einmal zusammen gefasst: Internetsicherheit

Ein anderes Beispiel: Hier im Blog setzte ich bis vor ein paar Minuten Recaptcha und Akismet ein. Recaptcha gehört schon länger zu Google und Akismet hat seine Server in den USA. Also wurden diese WordPress-Plugins nun ersetzt durch Antispam Bee und Math Captcha.

Und noch ein Beispiel: Im Backend von WordPress kann man einstellen, ob Kommentatoren ein Gravatar-Bildchen erhalten sollen oder dürfen. Diese werden über US Server gezogen und sind damit auch Mist.

Langsam nährt sich das Eichhörnchen von Ast zu Ast …

 

Katzenbefreiung

catfree

Unsere zwei Katzenkinder durften heute zum ersten Mal an die frische Luft – leider noch mit Halsband ausgestattet, falls sie hektisch davon laufen und sich finden lassen müssen. Die Katzenmama besteht darauf.

Carlson zeigte sich sehr vorsichtig und ging systematisch vor: Immer wieder die gleichen Wege laufen und von mal zu mal den Radius leicht erweitern, dann den Rückzug ins Wohnzimmer alle paar Minuten testen. Frieda nutzte die hektischere Variante: Geduckt bis zu Carlson huschen, dann vor irgendwas erschrecken und panisch wieder zurück ins Wohnzimmer rennen.

Mal sehen, wie lange es die beiden hier durchhalten. Irgend ein Nachbar frisst hier unsere Katzen. Im Schnitt sind unsere Miezen nach 2 Jahren spurlos verschwunden.

Senfnebel

cimg0806

Gestern war die Alb in Hochnebel gehüllt, der zusammen mit dem Raureif die Landschaft in einen zarten Senfton tauchte.

Kurz hinter Melchingen in süd-süd-westliche Richtung aufgenommen – aber leider als Bild nicht so beeindruckend wie in der Realität.

VirtualBox NAT Port-Weiterleitung

Wird die nach „Außen“ zeigende Schnittstelle einer VM über VBox NAT geleitet, erscheint diese nicht selbst im Netz, sondern nur der Host. Will man von Außen durch das VBox NAT zurück auf die Gast-Maschine, muss VBox die Weiterleitung der Pakete übernehmen.

Sollte aus Sicherheitsgründen die VM aus einem normalen Benutzeraccount heraus gestartet worden sein, dann weigert sich VBox jedoch, die Ports 1-1024 als Weiterleitungen einzurichten. Diese Ports gehören root. Man kann sich aber wie hier für Port 443 beschrieben helfen und damit auch Webserver-VMs (Port 80 und 443) mit ihrer öffentlichen / roten / nach Außen zeigenden Schnittstelle am VBox NAT betreiben.

Auf dem Router wird eine Weiterleitung auf den Host eingerichtet:

fritzbox_portweiterleitung

Port 443 wird schlicht auf Port 4433 auf dem Host weitergeleitet. Mit Port 80 ginge das genau so. Den könnte man z.B. auf Port 8080 weiterleiten.

Welche Ports man als Weiterleitungsziel wählt ist wie beschrieben egal – Hauptsache diese liegen im Bereich zwischen 1025 und 65536.

vbox_eth_nat

In der VM und dort am ge-nat-etten Adapter klickt man auf „Port-Weiterleitung“.

nat_portforwarding_2

Der Host-Port ist dann der auf dem Router eingestellte Port über 1024 (hier: 4433), der lokale Port ist wieder 443.

Den Apachen muss man also nicht umbiegen. Host-IP und Gast-IP kann man freilassen – die Zuordnung übernimmt dann VBox.

Sollte man die Webserver-VM im orangenen Netz der Firewall liegen haben, dann sind die entsprechenden Regeln auf dieser anzulegen – siehe Netzwerksetup für Homeserver NXT.

Netzwerksetup für Homeserver NXT

Die ID88 bringt wie bereits geschildert zwei Netzwerkschnittstellen mit, die dann an die virtuellen Maschinen durchgereicht werden müssen. Damit dies reibungslos funktioniert und auch die Zusammenarbeit mit dem Router (hier: Fritzbox) klappt, kann man wie folgt vorgehen, um sich eine virtualisierte Firewall zu installieren:

In der Fritzbox wird der DHCP abgeschaltet. Die IP für den Host / den Homeserver wird auf dessen nach Außen / zum Router zeigendem / rotem Interface händisch vergeben. In meinem Fall wäre das eth1 auf dem Host.

  • Der Router hat die IP 192.168.2.1 und nutzt eine Netzmaske 255.255.255.0
  • Das vom Host zum Router zeigende Interface erhält im folgenden Beispiel die IP 192.168.2.200

Auf dem nach Innen / zum Heimnetz zeigenden / grünen Interface des Hosts / Homeservers (in meinem Fall eth0) benötigt man eine Bridge, damit alle virtuellen Maschinen im internen Netz mit ihren eigenen MACs (und damit später auch ihren eigenen IP-Adressen) auftauchen können. Hier ist die IP der Bridge auf dem Host nicht mehr als die IP eines Switches – die IP Adresse des Gastes wird im Gast selbst festgelegt.

  • Nach Innen erhält der Host die IP 10.16.1.100 (eingestellt auf dessen Bridge br0 und nicht auf eth0. Eth0 auf dem Host bleibt komplett unkonfiguriert)
  • Das Heimnetz selbst ist ein 10.16er Netz mit Netzmaske 255.255.0.0 oder  10.16.0.0/16 (damit bekomme ich genug Freiraum für die nächsten Jahre und kann außerdem dafür sorgen, dass Geräte, die ich zwischen Schule und zu Hause hin und her trage immer die gleiche IP haben)

Sollte Ubuntu als Host-Betriebssystem zum Einsatz kommen, dann greift man zur Server-Ausgabe. Diese bringt keinen network-manager mit, der einem beim Setup dazwischen schießen würde. Setzt man eine Desktop-Version ein, dann muss der network-manager zuerst entfernt werden. Das Setup funktioniert nur, wenn man die Interfaces selbst konfigurieren kann.

Zusammengefasst: Auf dem Host steht in /etc/network/interfaces:

# Das Interface in Richtung Router
auto eth1
iface eth1 inet static
address 192.168.2.200
netmask 255.255.255.0
network 192.168.2.0
broadcast 192.168.2.255
gateway 192.168.2.1
dns-nameservers 213.73.91.35 192.168.2.1 85.214.20.141

# Das Interface in Richtung Heimnetz
auto br0
iface br0 inet static
address 10.16.1.100
netmask 255.255.0.0
bridge_ports eth0
bridge_fd 5
bridge_stp no

Eth0 auf dem Host bleibt – wie oben schon geschildert – unkonfiguriert. Der Host ist dann aus dem Heimnetz unter der IP der Bridge direkt zu erreichen und lässt sich so leicht warten.

Eth1 auf dem Host habe ich nicht nur mit dem Nameserver auf dem Router, sondern zusätzlich noch mit den DNS des CCC und Foebud versorgt. Man weiß ja nie.

Nun legt man sich die erste Virtuelle Maschine (hier unter VirtualBox, das unter einem normalen Benutzeraccount läuft) mit zwei Netzwerkkarten an.

vbox_eth_nat

Das „zum Router“ zeigende Interface der VM wird als NAT angelegt.

Damit ich die Netzwerkkarten später in der VM wieder finde, schreibe ich deren MAC Adressen immer so um, dass „rot“ eine 1 (für eth1 des Hosts) am Ende hat – und „grün“ eine 0 (für eth0 des Hosts).

vbox_eth_bridged

Das „nach Innen“ ins Heimnetz zeigende Interface der VM wird an die Bridge br0 des Hosts angeschlossen.

Ist der erste Host (hier IPFire als Firewall) gestartet, richtet man dessen Interfaces ebenfalls händisch her. Das nach Außen zeigende, rote Interface erhält vom DHCP auf dem NAT der VirtualBox irgendeine 10er Adresse. Welche, ist relativ egal. Später eingerichtete Portweiterleitungen übernimmt VirtualBox. Wichtig sind die Angaben für das interne, grüne Interface (also das, das an der Bridge des Hosts hängt). Hier muss die /etc/network/interfaces des Gastes angepasst werden (im Falle von IPFire über dessen Weboberfläche).

# Das rote Interface zeigt in Richtung Router und haengt am VBox NAT
auto eth0
iface eth0 inet dhcp

# Das gruene Interface zeigt in Richtung Heimnetz und haengt an der Bridge des Hosts
auto eth1
iface eth1 inet static
address 10.16.1.1
netmask 255.255.0.0

Die erste VM ist aus dem Heimnetz dann unter 10.16.1.1 zu erreichen.

So lange auf dem IPFire noch kein DHCP Server auf grün läuft, muss man sich auf einem Client eine 10.16.er Adresse händisch selbst zuweisen, damit man an die Weboberfläche kommt.

Die Installation weiterer VMs hängt direkt vom Sicherheitsbedürfnis ab. Zwei Wege sind möglich: einer führt über virtuelle Netzwerkkarten an der Firewall-VM (blau und orange), der andere richtet VMs „neben“ der Firewall ein.

vbox_internalnetwork

Wählt man die sicherere Variante (weitere Netzwerkkarten in der Firewall-VM), richtet man diese NICs in VirtualBox als „Internes Netzwerk“ ein. Die VMs hängen dann mit ihrem roten Interface direkt an der Firewall und ebenfalls im VM-internen-Netzwerk. Das wäre z.B. ein Weg, um ein orangenes Netz einzurichten (siehe Bild oben für die Netzwerkkarte eines Webservers im orangen Netz von IPFire).

Aside: Ein blaues Netz ist nicht so einfach zu haben, weil WLAN Karten auf dem Host nicht als solche in VMs hinein gereicht werden können. Man kann sich hier aber mit USB-WLAN-Sticks helfen, die an die VM gebunden und aus dieser heraus konfiguriert werden.

Wählt man die unsicherere Variante, richtet man weitere VMs „neben“ der Firewall ein. Das Setup entspricht hierbei jeweils der Einrichtung der ersten VM: Eth1 des Gastes mit VBox-NAT zeigt nach Außen. Die nach Innen zeigende Schnittstelle des Gastes (eth0) wird im Gast händisch mit einer IP versorgt und klebt an der Bridge br0 auf dem Host.

Fällt ein derartiger Gast in fremde Hände, steht dem Angreifer das komplette interne Netz offen. Die Firewall ist hier reduziert auf ihre Webfilter-/DHCP-Funktionen für das interne Netz. Schutz von Außen bietet sie so nur bedingt. Man sollte aber wegen einer derartigen Konstruktion nicht gleich in Panik ausbrechen. Ge-nat-ete VMs dürften von Außen schwer zu knacken sein. Bei Portweilterleitungen vom Router auf eine solche VM macht man jedoch ein Türchen für Angriffe auf und muss eine derartige VM (eine Brücke zwischen Internet und Heimnetz) dann noch einmal gesondert absichern (iptables, fail2ban, tripwire etc. pp.). Oder man spart sich das interne Interface gleich komplett.

Hier vermehren sich die VMs fast täglich: Die Firewall war zuerst da, dann kam ein Fileserver, dann ein Nameserver, ein Webserver, ein Gameserver … 10er Netze und viel RAM auf dem Host lassen viel Raum für Spinnereien 🙂

Latitude E6410 Keyboardchaos

IMG_20131128_175238

Janis bekommt zu Weihnachten einen seiner dickeren Wünsche erfüllt und erhält unter Selbstbeteiligung plus Beteiligung der Großeltern sowie unter Verzicht auf Geburtstagsgeschenke einen „neuen“ Laptop. Das bei Lapstore bestellte Gerät hat Vattern mit 8GB RAM und einer SSD konfiguriert, damit die nächsten paar Jahre Ruhe im Karton ist. Flott ist die Büchse – Hut ab.

Allerdings erhielt ich eine Konfiguration, bei der die linke Hälfte der Tastatur (QWERTZ) deutsch und die rechte Hälfte US war. So lange man weiß, wo Umlaute zu finden sind fällt einem das nicht weiter auf. Ich installierte fröhlich vor mich hin und erst als ich zum ersten Mal eine Umleitung und eine Pipe brauchte blickte ich auf die Tasten …

Größer-/Kleinertasten sowie Pipe gibt es nicht, wenn man ein US Keyboard auf deutsch betreibt, da darf man umschalten. Nicht weiter schlimm, aber nervig, wenn man das Umschalten des Layouts beim Wechsel auf eine Shell verschnarcht und dann erst wieder verstehen muss, was eigentlich los ist.

Also hab ich die Jungs von Laptstore angeschrieben und umgehend eine andere Tastatur zugeschickt bekommen. Mit Hilfe von Youtube war dann klar: Der Tastaturenwechsel ist kein Problem.

https://www.youtube.com/watch?v=m25N1eZj1FQ

Früher gab es Handbücher.