Tag: Sicherheit

Posted on

Keychain: Alternative zu Gnome-Keyring um SSH-Schlüssel zwischen Logins zu verwalten


An Gnome ist nicht alles schlecht. Das merkt man spätestens dann, wenn man sich näher mit der Situation von Archivmanagern wie Squeeze oder Xarchiver befasst und diese File-Roller gegenüberstellt. Ähnlich verhält es sich mit Gnome-Keyring und Seahorse. Beide Anwendungen vereinfachen das Verwalten von Passwörtern, GPG- und SSH-Schlüsseln enorm.
Die Kehrseite der Medaille ist, bei einer reinen Fenstermanager-Lösung oder bei LXDE werden viele Gnome-Bibliotheken und Ballast mitinstalliert.
Ich habe bisher noch keine perfekte leichtgewichtige Lösung gefunden, die alle meine Wünsche erfüllt. Insbesondere ist das automatische Entsperren aller Schlüssel im Schlüsselring von Gnome eine große Erleichterung, die ich in dieser Form vielleicht noch bei KDE vermute. Ein leichtgewichtiges Pendant zu Seahorse und Co., das aktiv betreut wird - Fehlanzeige.

Keychain

Ich habe mich mal wieder im Wiki von Arch Linux umgesehen und diesen Eintrag zum Thema SSH-Keys gefunden. Schließlich habe ich mich dafür entschieden mir Keychain näher anzusehen, eine in Shell-Skript geschriebene Anwendung, die meinen Anforderungen am besten gerecht wird.
Bisher sah mein Umgang mit SSH-Schlüsseln so aus. Zuerst wurden sie mit ssh-keygen erzeugt und wie im Artikel zur Absicherung des SSH-Servers beschrieben, dann entweder mit Hilfe von Gnome-Keyring in meinem Schlüsselbund dauerhaft gespeichert oder auf der Konsole mit ssh-agent und ssh-add für die Dauer einer Sitzung entsperrt.
Der Vorteil von SSH-Schlüsseln ist, sie verbessern nicht nur die Sicherheit, sondern sie sind auch bequem zu benutzen. Einmal entsperrt und man kann sich bequem ohne Passworteingabe zu einem entfernten Rechner verbinden.
Keychains Vorteil gegenüber der manuellen Methode ist, dass automatisch beim Einloggen in den Terminal ssh-agent und ssh-add ausgeführt werden. Üblicherweise muss man nach jedem Ab- und Anmelden und Wechsel der Sitzung den SSH-Schlüssel erneut entsperren. Mit Keychain startet ein dauerhafter Prozess des ssh-agent, der für jede neue Sitzung wiederverwendet wird. Das heißt, einmal entsperrt lässt sich der Schlüssel bis zum nächsten Reboot ohne weitere Passworteingabe benutzen.

keychain --quiet id_pc1_rsa id_pc2_rsa
[ -z "$HOSTNAME" ] && HOSTNAME=`uname -n`
[ -f $HOME/.keychain/$HOSTNAME-sh ] &&
        . $HOME/.keychain/$HOSTNAME-sh
[ -f $HOME/.keychain/$HOSTNAME-sh-gpg ] &&
        . $HOME/.keychain/$HOSTNAME-sh-gpg

Dieser Code-Schnipsel wird entweder in der Datei ~/.bash_profile, oder wenn man ZSH benutzt in ~/.zshrc eingefügt. Keychain fügt automatisch die privaten SSH-Schlüssel id_pc1_rsa und id_pc2_rsa dem SSH-Agenten hinzu bzw. GnuPG-Agent, wenn dieser installiert sein sollte. Die Parameter für die laufende Sitzung werden standardmäßig in ~/.keychain/ gespeichert. Die Option --quiet sorgt noch dafür, dass nur Warnungen oder Fehlermeldungen ausgegeben werden, wenn man sich einloggt. Ansonsten würde eine ähnliche Meldung wie diese jedes Mal erscheinen.

* keychain 2.7.1 ~ http://www.funtoo.org
* Found existing ssh-agent: 2797
* Known ssh key: /home/apo/.ssh/id_pc1_rsa
* Known ssh key: /home/apo/.ssh/id_pc2_rsa

Fazit

Keychain ist eine leichtgewichtige Lösung um SSH-Schlüssel über Sitzungsgrenzen hinweg zu entsperren und bequem nutzen zu können. Auch für Cron-Jobs sicherlich eine nützliche Lösung. Das Handbuch man keychain ist empfehlenswert und informativ. Weitere Informationen gibt es wie immer in /usr/share/doc/keychain oder auf der Projektseite. Ich denke, der Gnome-Keyring und Seahorse sind weiterhin die bequemste Möglichkeit. Keychain ist für mich momentan jedoch ein sehr guter Ersatz auf einem leichtgewichtigen System.
Wie geht ihr mit dem Thema Passwörter und Schlüssel um?

Posted on

SSH: Deaktivieren von StrictHostKeyChecking

Auf meinem Intel-Core-Duo-Rechner benutze ich verschiedene Betriebssysteme und betreibe ein Multiboot-System. Das hilft mir dabei Aufgaben und Software zu trennen, die ich nicht alle gemeinsam unter einem System installieren möchte.
Regelmäßig kommt es jedoch vor, dass ich mich per SSH von einem Laptop zu diesem Rechner verbinde oder Daten per scp austausche. Als vertrauenswürdiges Ziel habe ich dabei meine Debian-Testing-Installation mit Gnome 3 ausgewählt und den dortigen Host-Key zu meiner Datei ~/.ssh/known_hosts hinzugefügt.
Wechsele ich dann zu einem parallel installierten Betriebssystem, begrüßt mich diese Meldung hier.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!

Der SSH-Klient macht hier alles richtig und warnt mich davor, dass die Identifikation des Rechners sich nun geändert hat. Das hat mich bisher nie richtig gestört. Entweder habe ich die Datei .ssh/known_hosts gelöscht oder mich von einem anderen Laptop eingeloggt, der diese Installation als vertrauenswürdig eingestuft hat.
Man kann aber auch das sogenannte StrictHostKeyChecking deaktivieren, indem man sich eine entsprechende Konfiguration in ~/.ssh/config anlegt. Prinzipiell würde ich nie auf die Idee kommen dieses Sicherheitsfeature auszuhebeln, insbesondere dann nicht, wenn ich mich im Internet zu einem entfernten Rechner verbinde. Mein Laptop und der Core Duo stehen jedoch nur wenige Meter auseinander und werden dazu oft noch per Kabel verbunden. Von daher ist das Risiko eines Man-in-the-Middle-Angriffs überschaubar.

Meine Lösung sieht nun so aus:
Ich habe die Datei ~/.ssh/config mit folgendem Inhalt angelegt.

Host loki
         StrictHostKeyChecking no
         UserKnownHostFile /dev/null

Wenn ich nun ssh loki eingebe, wird SSH diesen speziellen Host weniger streng prüfen und ich kann mich problemlos zum selben Rechner verbinden, selbst wenn sich das Betriebssystem geändert hat.
Anstatt loki lässt sich auch 192.168.1.207 schreiben und mit der Wildcard * sogar jeder Rechner von der strengen Überprüfung ausnehmen, was ich aber nicht empfehlen kann.
Eine weitere Möglichkeit bietet der Alias-Befehl.  z.B.

alias insecssh='ssh -o "StrictHostKeyChecking=no" -o "UserKnownHostsFile=/dev/null"


Mit insecssh loki könnte man sich danach auch ohne Anlegen einer config-Datei zum entfernten Rechner verbinden.
Für die eigenen vier Wände ist das erst einmal ausreichend. 😉
Changelog:
01.09.2012 Alias insecssh der GRML-Konfiguration hinzugefügt.

Posted on

Debian-Server mit der unkomplizierten Firewall ufw absichern

Zwischen dem Sperren des Root-Zugangs für SSH und dem Installieren des ersten Spieleservers musste ich eine Firewall einrichten. Ich bin noch kein Firewall-Experte, weswegen ihr genau überlegen solltet, ob die folgende Anleitung euren Ansprüchen genügt. Fakt ist aber, dass ich damit momentan meinen Spieleserver mit Debian schütze und ich damit bisher zufrieden sein kann. 😉
Die Errichtung einer Barriere mit Hilfe von netfilter und iptables unterstützen heute viele Werkzeuge. Ich hatte mir ufw und arno-iptables-firewall als mögliche Kandidaten ausgesucht und mich dann für die "unkomplizierte Firewall" entschieden.
Ursprünglich von Ubuntu entwickelt bietet ufw eine einfache Möglichkeit nur die Dienste freizugeben, die tatsächlich öffentlich verfügbar sein sollen.

Installation

aptitude install ufw

Konfiguration

ufw enable


Aktiviert die Firewall. Bestehende SSH-Verbindungen können unter Umständen getrennt werden. Standardmäßig werden eingehende Verbindungen geblockt und ausgehende Verbindungen erlaubt. Bevor man die Firewall aktiviert, kann man z.B. mit

ufw allow proto tcp from any to any port 22


explizit Port 22 für den SSH-Zugang freigeben.

ufw allow 44443/tcp


In der vergangenen Erklärung konnte man sich über Port 44443 per SSH einloggen, also muss zuerst dieser Port mit allow freigeschaltet werden. Dabei lässt sich mit /udp oder /tcp die Erlaubnis auf bestimmte Protokolle eingrenzen oder ohne auf beide ausdehnen.

ufw limit 44443/tcp


Noch mehr Sicherheit bietet die Limit-Funktion von ufw, mit der die Anzahl von eingehenden Verbindungen pro IP begrenzt wird, wodurch Brute-Force-Attacken deutlich erschwert werden.

ufw default deny


Im Prinzip der wichtigste Schritt, da dadurch standardmäßig alle eingehenden Verbindungen abgewiesen werden. (Genauer, jedes eingehende Packet wird kommentarlos verworfen. DROP)

ufw status verbose


Zeigt den Status der Firewall an. Oder einfach nur ufw status.

ufw allow 27960/udp


Gibt den UDP Port 27960 für OpenArena frei.

ufw allow 40000:40009/udp


Gibt die Ports von 40000 bis 40009 für UDP frei (XPilot-ng)

ufw allow http


Eine andere Schreibweise um Standard-Port 80 für den Webserver freizugeben

ufw logging on und ufw logging medium


Der erste Befehl schaltet die Logfunktion der Firewall ein (standardmäßig auf niedrig). Weiterhin gibt es noch medium, high und full.

ufw delete allow 44443/tcp


Mit der Delete-Funktion lassen sich Regeln im laufenden Betrieb auch wieder löschen.

Ausgehende Verbindungen

Ausgehende Verbindungen werden standardmäßig erlaubt. Im meinem Fall bin ich der einzige Benutzer mit Shellzugriff auf meinem Server und es gibt bisher weder CGI noch PHP-Anwendungen, die man manipulieren könnte um diese Einstellung zu missbrauchen. An dieser Stelle scheiden sich die Geister. Tatsache ist, man kann sein System so fest zuschnüren, dass nicht einmal ausgehende Verbindungen erlaubt sind oder einen Mittelweg finden.

ufw deny out to any


Blockiert alle ausgehenden Verbindungen

ufw allow out 80,443/tcp


Erlaubt ausgehende TCP-Verbindungen für Port 80 und 443.

IPv6

UFW blockt standardmäßig alle Anfragen mit IPv6. Damit ufw mit IPv6 zusammenarbeitet muss in /etc/default/ufw die Variable IPV6 auf Yes gesetzt und die Firewall einmal mit ufw reload neu gestartet werden.

Fazit

Die unkomplizierte Firewall macht ihrem Namen alle Ehre. Das Prinzip ist immer das gleiche. Alle eingehenden Verbindungen verwerfen und nur die tatsächlichen Dienste freigeben, die man wirklich braucht. Wie restriktiv man ausgehende Verbindungen behandelt, hängt vom eigenen Benutzerszenario ab. Die Regeln lassen sich noch deutlich verfeinern. Mehr Informationen verrät man ufw oder die folgenden Links.

Links

Ubuntu ufw Documentation
Firewall Ubuntu Servers

Posted on

SSH-Schlüssel, Port ändern und Anmeldung als Root verwehren

Nachdem mir meine Zugangsdaten zum vServer übergeben worden waren, war meine erste Aktion mit dem neuen SpielArbeitsgerät den SSH-Zugang abzusichern. Die folgende Anleitung zeigt in Kürze, wie man verhindert, dass Root sich per SSH anmelden darf, SSH auf einem anderen Port lauscht und eine Anmeldung nur noch mit einem gültigen SSH-Schlüssel möglich ist und das Einloggen per Passworteingabe deaktiviert wird.
Diese Prozedur ist bei jedem öffentlich zugänglichen Server sinnvoll, wie ein Vorfall letzte Woche wieder einmal gezeigt hat. In einer größeren Institution wurde ein Server kompromittiert, bei dem sich der Angreifer mit Hilfe einer Wörterbuch-Attacke direkt Rootzugriff über SSH verschaffen konnte, indem er innerhalb weniger Stunden ca. 40.000 Passwörter ausprobieren durfte. Software wie denyhosts, fail2ban oder eine Firewalleinstellung, die nur Zugriff aus "vertrauenswürdigen" Netzen erlaubt und natürlich ein stärkeres Passwort, wäre hier eine Möglichkeit gewesen den Einbruch zu verhindern.
Mein kleines Projekt bietet mir die einfache Möglichkeit auf noch mehr Sicherheit, da außer mir selbst niemand Shellzugriff benötigt und nichts dagegen spricht den berechenbaren Namen des Root-Zugangs zu deaktivieren und nur noch die Authentifizierung per SSH-Public-Key-Verfahren zu erlauben. Bevor das geschieht, muss man natürlich einen weiteren, unprivilegierten Benutzer mit adduser hinzufügen.

Schlüsselerzeugung

ssh-keygen

Ohne weitere Argumente erstellt dieser Befehl einen privaten und öffentlichen RSA-Schlüssel für die SSH-Protokollversion 2 auf dem lokalen Rechner. Bejaht man alle folgenden Fragen, wird das Schlüsselpaar in ~/.ssh/ gespeichert. Ebenso wird man nach einem Passwort gefragt, um den privaten Schlüssel später entsperren zu können. Ich empfehle eines zu setzen, auch wenn man dadurch einmal pro Sitzung das Passwort eingeben muss.

Öffentlichen Schlüssel auf den Server transferieren

ssh-copy-id user@euervps123.de

Der öffentliche RSA-Schlüssel befindet sich danach auf eurem Server in ~/.ssh.

Einloggen

Funktioniert wie bisher,

ssh user@euervps123.de

nur dass ihr jetzt das Passwort zum Entsperren des privaten Schlüssels auf eurem Rechner eingeben müsst. Die Rechte der privaten Schlüsseldatei id_rsa müssen restriktiv sein.

chmod 600 ~/.ssh/id_rsa

Schlüssel ohne Eingabe des Passworts benutzen

Unter Gnome 3 genügte bei mir

ssh-add

auszuführen, um den privaten Schlüssel dem Authentifizierungsagenten, ssh-agent, hinzuzufügen, der hier durch die Anwendung gnome-keyring bereitgestellt wird. Nach einmaliger Eingabe des Passwortschutzes für den privaten Schlüssel ist dieser die gesamte Sitzung ohne weitere Passwortabfrage benutzbar.
Arbeitet ihr ohne X auf der Konsole müsst ihr zuerst den

ssh-agent zsh


mit eurer bevorzugten Shell aufrufen und könnt danach den privaten Schlüssel wieder wie oben beschrieben mit ssh-add für die Sitzung dauerhaft entsperren.

Root-Zugang deaktivieren, Port verändern und Passwort-Authentifizierung abschalten

Hierzu muss die Datei /etc/ssh/sshd_config auf dem Server angepasst werden.
Wichtig! Bevor ihr die Veränderung vornehmt, solltet ihr absolut sicher sein, dass ihr euch mit dem neu generierten Schlüssel anmelden könnt. Ebenso müsst ihr unbedingt die Einstellungen der Firewall so anpassen, dass ein Anmelden über den neuen SSH-Port erlaubt ist. (siehe nächster Beitrag).
Folgende Optionen werden geändert:

Port 44443
PermitRootLogin no
RSAAuthentication yes
PubkeyAuthentication yes
PasswordAuthentication no
X11Forwarding no

Fazit

Der Port kann im Prinzip beliebig gewählt werden. Die Liste der standardisierten Ports hilft bei der Entscheidung. Der Wechsel von Port 22 auf z.B. Port 44443 lässt die Mehrzahl automatischer Programme ins Leere laufen, die nur überprüfen, ob auf dem Standardport ein SSH-Dienst angeboten wird. Anmelden kann man sich ab sofort mit

ssh -p 44443 user@euervps123.de


Das Abschalten der Passwort-Authentifizierung macht Wörterbuch-Attacken aussichtslos. Das Deaktivieren des Root-Logins erzwingt die Anmeldung mit einem unprivilegierten Benutzer, so dass ein Angreifer nicht nur die Hürde des SSH-Schlüssels überwinden, sondern noch ein weiteres Passwort in Erfahrung bringen muss.
Sicherheit ist ein Prozess, heißt es so schön. Für mein spezielles Benutzerszenario funktioniert dieser Weg. Fehlerhaft konfigurierte Dienste und Sicherheitslücken kann aber auch diese Anleitung nicht verhindern.

Links

https://help.ubuntu.com/community/SSH/OpenSSH/Configuring
http://bodhizazen.net/Tutorials/SSH_keys
Sicherer Datentausch: Ein sftp-Server mit chroot

Posted on

Arch Linux: Paketsignaturen mit GnuPG und Pacman 4

Vor drei Tagen wurde auf archlinux.org die gute Nachricht verkündet, dass Archs neuer Paketmanager Pacman 4 nun in den "Core"-Paketquellen verfügbar ist. Ich hatte im letzten September noch laut über die Sicherheitsarchitektur der Paketverwaltung nachgedacht und damals die Diskussion zu dem Thema näher verfolgt, die schon vor Jahren angestoßen wurde aber erst durch einen kritischen lwn.net Artikel an Fahrt gewann.
Währenddessen war man nicht untätig und 893 commits von 24 Helfern später, ist es nun gelungen eine Reihe von neuen Feature zu implementieren, darunter eben auch das Signieren von Paketen mit GnuPG.
Zuerst fiel mir auf, dass ich yaourt und dessen Abhängigkeit package-query vor einem Systemupgrade entfernen musste, da package-query auf Pacman in einer Version < 3.6 angewiesen war. Danach wurde zuerst Pacman aktualisiert, bevor ich mir das neue Sicherheitskonzept näher anschauen konnte.
Als erstes sollte man den neuen GnuPG Schlüsselbund mit pacman-key --init anlegen. Zum Thema Package Signing und Pacman-Key gibt es schon einen hilfreichen Eintrag im Wiki. Ausführlich wird der gesamte Prozess auch auf Allan McRaes Homepage erläutert.
Nachdem mit pacman-key sowohl Schlüsselbund und ein Grundgerüst an Konfigurationsdateien angelegt worden ist, kann man in /etc/pacman.conf seine persönlichen Vorstellungen von Sicherheit einstellen. Zur Zeit ist das Überprüfen der Paketsignaturen nämlich noch mit der Variablen SigLevel = Never abgeschaltet.
Mit SigLevel = Optional TrustedOnly werden Pakete auf ihre Signaturen hin überpüft, jedoch muss man jedem unbekannten Schlüssel noch einzeln vertrauen. Eine typische Fehlermeldung sieht dann am Anfang so aus:

pacman -S transmission-gtk
resolving dependencies...
looking for inter-conflicts...
Targets (1): transmission-gtk-2.42-2
Total Download Size: 0.61 MiB
Total Installed Size: 2.57 MiB
Proceed with installation? [Y/n]
:: Retrieving packages from extra...
transmission-gtk-2.42-2-i686 625.7 KiB 410K/s 00:02 [########################################] 100%
(1/1) checking package integrity [########################################] 100%
error: transmission-gtk: key "E8F18BA1615137BC" is unknown
:: Import PGP key 615137BC, "Ionut Biru ", created 2011-04-19? [Y/n] n
error: failed to commit transaction (invalid or corrupted package (PGP signature))
Errors occurred, no packages were upgraded.

Deswegen sollte man zuerst die sogenannten MasterKeys importieren. Diese fünf Hauptschlüssel werden dazu benutzt um die Schlüssel anderer ArchLinux-Entwickler zu unterschreiben. Gemäß dem Web of Trust ist das marginale Vertrauen in drei dieser Schlüssel ausreichend, um einen anderen mit ihnen unterschriebenen Schlüssel als gültig anzusehen. Selbst im schlimmsten Fall, wenn zwei der MasterKeys widerrufen werden müssten, wäre also das Sicherheitskonzept weiter in Takt.
Problematisch ist momentan die Verteilung dieser Schlüssel. Es gibt z.B. noch kein pacman-keyring Paket, mit welchem alle GnuPG-Schlüssel automatisch und benutzerfreundlich eingerichtet werden können. Außerdem haben noch nicht alle ArchLinux-Entwickler ihre GnuPG-Schlüssel unterschreiben lassen, weswegen es zu Warnmeldungen kommt. Dies ist auch der ausschlaggebende Grund, warum Arch Linux mit Pacman 4 standardmäßig noch auf die Validierung verzichtet.
Eine einfache Möglichkeit die fünf MasterKeys zu importieren, ist diese For-Schleife zu benutzen.

for key in FFF979E7 CDFD6BB0 4C7EA887 6AC6A4C2 824B18E8; do
pacman-key --recv-keys $key
pacman-key --lsign-key $key
printf 'trustn3nquitn' | gpg --homedir /etc/pacman.d/gnupg/
--no-permission-warning --command-fd 0 --edit-key $key
done

Halten wir mal fest, dass Arch Linux einen großen Schritt in Sachen Paketsicherheit nach vorne gemacht hat. Es braucht aber noch den letzten Feinschliff in den kommenden Wochen, um das Vertrauen in das neue System auch tatsächlich herzustellen.

Posted on

GPA oder Nautilus-Actions: Dateien intuitiv mit GnuPG verschlüsseln

Die seahorse-plugins waren früher für mich immer der Garant dafür, dass ich mit einem simplen Rechtsklick in Nautilus eine Datei ganz leicht mit GnuPG verschlüsseln oder entschlüsseln konnte. Wie im letzten Beitrag zu Gnome 3 erwähnt, dauert es mit der Wiedereinführung dieses Pakets noch bis Gnome 3.4. Zwar lassen sich die wichtigsten GnuPG-Kommandos auch schnell in der Konsole ausführen, ein grafisches Frontend für die Gnome-Desktopumgebung macht den Umgang mit den vielfältigen Optionen aber deutlich bequemer. Wer nicht warten möchte, hat eine Reihe von Alternativen. Für mich funktionieren die folgenden ganz gut.

Gnu Privacy Assistant (GPA)

Eine Möglichkeit viele Dateien auch mit verschiedenen Schlüsseln bequem mit Hilfe eines grafischen Frontends zu verschlüsseln, bietet das Programm Gnu Privacy Assistant kurz GPA genannt. Im Prinzip lässt es sich wie ein gewöhnlicher Dateimanager bedienen. Zu verschlüsselnde Dateien werden über den "Öffnen"-Dialog importiert, wonach man sie signieren, verschlüsseln und natürlich auch wieder entschlüsseln kann. GPA verwendet dabei die modularisierte und erweiterte Version 2 der GnuPG Software.

Nautilus Actions

Mit der Anwendung Nautilus-Actions lassen sich zusätzliche Menüeinträge zu Nautilus hinzufügen. Sie wird entweder als externes Programm in der Gnome-Shell oder mit dem Befehl nautilus-actions in einem Terminal gestartet. Mit dieser Erweiterung zum Dateimanager Nautilus ist es möglich angepasste Befehle, Funktionen und sogar Skripte an einen Menüeintrag zu binden.

Aktion definieren


Zuerst wird unter dem Reiter Aktion der Kontextbezeichner für den zukünftigen Menüeintrag festgelegt. In diesem Fall also Verschlüsseln oder Entschlüsseln. Zusätzlich lässt sich noch ein Symbol definieren, welches als Miniaturausgabe neben dem Eintrag erscheinen soll.

Befehl festlegen


Um GnuPG bedienen zu können und die Passwortabfrage möglich zu machen, habe ich mich entschieden meinen Terminalemulator rxvt-unicode zu benutzen. Im Prinzip ist es der gleiche "Trick" wie bei den "Benutzerdefinierten Aktionen" in Thunar, den ich im Beitrag zu GnuPG vorgestellt habe. Eigentlich hätte ich erwartet, dass dieses Verhalten standardmäßig von Nautilus-Actions unterstützt wird oder sich zumindest unter dem Reiter Ausführung festlegen lässt. Leider funktionierte das so bei mir aber nicht.
Als Pfad trägt man /usr/bin/urxvt oder den für den eigenen Terminal entsprechenden Namen ein und als Parameter dann -e sh -c "gpg -ser 11111111 %f"
Dabei muss für 11111111 natürlich euer GnuPG-Schlüsselwert stehen. Die restlichen Einstellungen kann man für "Verschlüsseln" so belassen. Der Eintrag erscheint dann bei jeder Datei und mit einem Klick darauf wird gpg in rxvt-unicode ausgeführt. Dateien werden sowohl signiert als auch verschlüsselt. %f ist der Platzhalter für die Datei.

Entschlüsseln nur für gpg und pgp Dateien anzeigen

Der Parameter für den Entschlüsseln Eintrag im Reiter Befehl sieht bei mir so aus. -e sh -c "gpg -o %w -d %f"
Dadurch erhält die entschlüsselte Datei auch wieder ihren Originalnamen (%w). Damit der Eintrag nur bei *.pgp und *.gpg Dateien angezeigt wird, müssen unter dem Reiter Basisnamen und MIME-Typen zwei Filter angelegt und die Option "Muss einem entsprechen" bei beiden ausgewählt werden.
Für Basisnamen

*.pgp
*.gpg

Für MIME-Typen

application/pgp
application/gpg

Nützliche Links

Viele vorgefertigte Schemata gibt es auf der Entwicklerseite. Diese lassen sich direkt in Nautilus-Actions importieren. Ebenfalls nützlich ist der Blogeintrag auf upubuntu.com, der Schritt für Schritt mit Bildern zeigt, wie man z.B. den shred-Befehl in das Nautilusmenü einbindet.

Posted on

WineHQ kompromittiert – Eine Erinnerung

Mich hat heute die schlechte Nachricht per E-Mail erreicht, dass die AppDB- und Bugzilla-Datenbank von winehq.org gehackt worden ist. Da ich Wine in der Vergangenheit für World of Warcraft, Starcraft II oder Runes of Magic benutzt und Kommentare hinterlassen habe, besitze ich dort einen Account.
Die Meldung zum Einbruch in die WineHQ-Datenbank reiht sich dieses Jahr nahtlos in eine Serie von Angriffen auf bekannte Websites ein, namentlich Sony, Kernel.org oder DigiNotar. Es besteht aber kein Zusammenhang zwischen den Vorfällen. Alle Angriffe waren verschieden und nutzten unterschiedliche Sicherheitslücken aus.
Ich finde es gut, dass der Vorfall so schnell von den Verantwortlichen von WineHQ mitgeteilt worden ist, schlaflose Nächte bereitet er mir zum Glück nicht. Da ich keine Kontrolle über jeden Server und Internetdienst habe, probiere ich es mit diesen Vorsätzen.

  • Kein Passwort doppelt benutzen.
  • Passwörter benutzen, die schwer zu erraten sind.

Es macht mir deswegen nichts aus, dass mein gehashtes Passwort in die Hände von Fremden gefallen ist, da ich es nur auf WineHQ verwende. Ehrlich gesagt ist es so kompliziert, dass ich es mir selbst nicht merken kann. Da ich mich nur selten auf der Seite einloggen muss, genügt es mir das Passwort lokal auf meinem Rechner abzuspeichern und bei Bedarf wieder hervorzuholen.
Der beste Tipp für ein sicheres und einfach zu merkendes Passwort ist immer noch sich einen Satz auszudenken, den man sich leicht merken kann und daraus das Passwort abzuleiten.
"Im glühend heißen Sommer 2003 war ich am 8. 8 in München auf dem Viktualienmarkt um Peter zu besuchen und viel $ auszugeben."
Die Anfangsbuchstaben des Satzes sind genau wie Datumsangaben und Sonderzeichen, wie z.B. $ für Geld, Teil des Passworts.
IghS2003wia88iMadVuPzbuv$a
Das Beispiel ist natürlich ausgedacht. Aber auf genau diese Art und Weise erstelle ich meine Passwörter, die für mich Sinn ergeben, für andere aber extrem schwer zu erraten sind.
Hier ist noch einmal die Original-Mail von WineHQ.

We are sorry to report that recently our login database for the
WineHQ Application Database was compromised. We know that the entire
contents of the login database was stolen by hackers. The password
was encrypted, but with enough effort and depending on the quality
of your old password, it could be cracked.
We have closed the hole in our system that allowed read access to
our database tables.
To prevent further damage we have reset your password to what is shown
below. We strongly suggest that if you shared your AppDB password on
any other sites that you change that password as soon as possible.
For more detailed information about this hacking, please read about
it at this link:
http://www.winehq.org/pipermail/wine-users/2011-October/097753.html
Again, we apologize for any inconvenience this has caused.
-WineHQ Staff
http://appdb.winehq.org/

Posted on

Pacman und das Bedürfnis nach Sicherheit

In den letzten Tagen und Wochen habe ich mich öfter mit Pacman dem Paketmanager von Arch Linux auseinander setzen müssen. Kurioserweise ist er mir bei der Konfiguration von ConnochaetOS vertrauter geworden und weniger beim Umgang mit Arch Linux selbst. Irgendwann habe ich mich gewundert, wie Pacman eigentlich die Integrität der heruntergeladenen Pakete sicherstellt und nach Parallelen zu Debian GNU/Linux gesucht.
Ein wichtiges Hilfsmittel sind MD5-Hashes um zu bestimmen, ob ein vom Server heruntergeladenes Paket auch tatsächlich intakt auf dem eigenen Rechner ankommt. Auch Arch Linux greift genau auf diese Methode zurück. MD5 gilt seit einiger Zeit nicht mehr als ausreichend sicher und eignet sich daher auch nicht um die Echtheit von Paketen zu verifizieren.
Mittlerweile weiß ich auch, dass im Gegensatz zu Debians apt der Paketmanager von Arch Linux noch über keine ausreichende Implementierung zur Überprüfung von sicheren Paketsignaturen mit Hilfe von GnuPG verfügt. Bei meiner Suche nach Informationen bin ich dann auf einige lesenswerte und interessante Artikel gestoßen.
Zum einen wäre da der LWN Artikel "Arch Linux and (the lack of) package signing" und die Antwort darauf von Dan McGee, einer der Hauptentwickler von Pacman und Arch Linux. Kurz zusammengefasst wurde die Problematik am 23. März 2011 deutlich in den Fokus der interessierten Öffentlichkeit gerückt, obwohl das Problem schon seit mehreren Jahren im Bugtracker und Forum von Arch Linux bekannt war. Nach dem ich mir beide Artikel durchgelesen habe, denke ich, dass die Behauptung zutrifft, dass eine funktionierende Paketsignierung bei Arch Linux nicht existiert.

Weniger schwer wiegen da die verletzten Befindlichkeiten der Pacman-Entwickler und des im LWN-Artikels zitierten Arch-Nutzers, der die ganze Sache "ans Licht brachte". Offensichtlich gab es seit Jahren aus verschiedenen Gründen kein Interesse ein solches Sicherheitsfeature zu implementieren und gleichzeitig auch keine echte Hilfe von Seiten der Community. Die Entwicklung stagnierte. Die Frage ist nur, ob man ein solches Problem nur zur Aufgabe einiger Paketentwickler degradieren oder es nicht doch besser zu einer Aufgabe und zu einem Ziel der ganzen Distribution hätte machen sollen.
Natürlich ist jeder User immer ein Stück weit selbst für die Sicherheit seines Systems verantwortlich. Dennoch sollte es eine Möglichkeit geben zu überprüfen, ob es sich bei den heruntergeladenen Paketen auch wirklich um die offiziellen handelt und nicht möglicherweise doch um kompromittierte.
Seit dem Artikel sind sechs Monate vergangen und ein Blick auf die offizielle ArchLinux-Seite zeigt, dass man das Problem zumindest nicht versucht zu verbergen. Es gibt eine eigene Wikiseite zum Thema "Pacman package signing" und auch die FAQ listet unter dem Punkt "Warum man Arch nicht nutzen sollte" auf, dass man dann auf eine sichere Paketsignierung nicht verzichten muss.

Arch Linux ist nicht die einzige Distribution, die eine solche Verifizierung noch nicht vorgesehen hat. Sie wird deswegen auch nicht nutzlos. Selbst Debian hatte nicht von Anfang an eine Möglichkeit um die Echtheit von Paketen zu überprüfen. Doch im Gegensatz zu Arch Linux gab es bereits vor elf Jahren eine breite Diskussion zu diesem Thema. In der Dokumentation zur Absicherung von Debian finden sich hier zwei Links zu den wöchentlichen Neuigkeiten aus dem Jahr 2000 und 2001.
Wenn man etwas daraus lernen kann dann das, man sollte jede Distribution darauf überprüfen, ob sie zu den persönlichen Anforderungen passt. Wenn ich mich auf meine Software zu 100% in jeder Situation verlassen muss, greife ich eher zu Debian Stable als zu Arch Linux. Wenn ich der Meinung bin, dass das Risiko auf ein paar älteren privaten Laptops vernachlässigbar ist und die Distribution ansonsten wunderbar für mich funktioniert, werde ich die betreffende Distribution auch weiterhin verwenden. Ganz allgemein gesprochen kann es nicht schaden die vielen Drittquellen, wozu z.B auch die PPAs bei Ubuntu gehören, genauer unter die Lupe zu nehmen und nicht jedes Paket blindlings herunterzuladen. Schließlich sollte doch ein zentrales und vor allem sicheres Paketmanagement Linux von anderen Betriebssystemen positiv unterscheiden.

Posted on

Webseiten mit elinks in screen über eine SSH-Verbindung mit rxvt-unicode solarisiert betrachten

Die Überschrift sagt schon alles. Ich vermute ein ähnliches Problem dürfte weniger als ein Milliardstel der Weltbevölkerung betreffen, aber aus Spaß hier die kurze Geschichte.
Ich hatte mich per SSH in den Toshiba Portégé 3110CT alias speedy eingeloggt und wollte nun mit Solarized und meinem neuen 256-Farben-Terminal rxvt-unicode das System updaten und überprüfen, ob mein Blog in elinks irgendwie anders als zuvor aussah. Wenn ich mich remote zu meinem mit Debian Stable betriebenen Laptop verbinde, starte ich danach für gewöhnlich screen, womit es mir leichter fällt mehrere Anwendungen parallel wie mit einem grafischen Fenstermanager zu nutzen.
Als erstes erhielt ich die Fehlermeldung

Error opening terminal: rxvt-unicode

als ich versuchte eine Anwendung wie htop zu starten. Das Problem resultiert daraus, dass das System den Terminal rxvt-unicode-256color nicht kennt und deshalb auch nicht weiß, wie es das aufgerufene Programm darstellen soll. Da das scheinbar ein uraltes Problem ist konnte ich sowohl im englischen Gentoo als auch im deutschen Arch Linux Wiki eine Lösung hierzu finden. Kurz gesagt, muss die Terminfo Datenbank auf den aktuellen Stand gebracht werden und eine Infodatei im versteckten Ordner .terminfo im Home-Verzeichnis des Benutzers auf dem entfernten Rechner angelegt werden.
Im Gentoo-Wiki wird das elegant so gelöst:

infocmp rxvt-unicode | ssh USER@REMOTE_IP 'mkdir -p .terminfo && cat >/tmp/ti && tic /tmp/ti'

Auf dem lokalen Rechner werden die Informationen über den verwendeten rxvt-unicode-Terminal abgefragt und über SSH auf die entfernte Maschine geschickt, wo die Infodatei mit Hilfe von tic von einem Quellformat in ein kompiliertes Format umgewandelt wird. Danach konnte ich dann wie gewohnt Programme öffnen.
Obwohl ich den Terminaltyp in elinks nicht auf 256 Farben eingestellt hatte, sondern weiterhin bei den 16 ANSI Farben belassen hatte, wurde meine Webseite ohne weiteres Zutun schon in den Solarized-Farben dargestellt. Als allgemeiner Tipp solltet ihr bei Farbproblemen % in elinks drücken, womit man zwischen verschiedenen Dokumentfarben umschalten kann. Ich verstehe nur noch nicht, warum bei manchen Farbkombinationen die Schrift fett dargestellt wird und bei manchen normal. Vermutlich hat das etwas mit dem ANSI-Farbcode zu tun. Und so sieht gambaru in elinks solarisiert aus. 😉

Posted on

Sicherer Datentausch: Ein sftp-Server mit chroot

Vor zwei Jahren wollte ich mehrere 100 MB an Fotos mit ein paar Freunden teilen, die sich nach einem gemeinsamen Urlaub angesammelt hatten. Damals waren Dropbox und ähnliche Dienste noch nicht ganz so präsent wie heute. Außerdem war es eine gute Gelegenheit mehr über FTP- und SSH-Server zu lernen und manch bekennenden Windowsnutzer ordentlich zu verwirren: "Ja, du musst ssh benutzen. Es gibt keine andere Möglichkeit um an die Fotos zu gelangen." haha 😈
Zu dieser Zeit sollte es unbedingt ein sftp-Server sein, da ich für viele andere Aufgaben sowieso schon ssh einsetzte. Damit spart man sich das Einrichten eines zusätzlichen ftp-Servers und erhält gleichzeitig noch eine sichere Methode zum Datenaustausch dazu.
Die folgende Anleitung beschreibt die Einrichtung eines ssh-Servers, der für eine Gruppe von Benutzern nur als sftp-Server zugänglich sein soll. Alle User werden dabei in einer chroot-Umgebung eingesperrt und Shell-Zugriff verwehrt um die Sicherheit auf dem Server zu erhöhen. Als Beispiel dient mir der Benutzer mika und die Gruppe freunde. Das HowTo sollte mit jeder auf Debian basierenden Distribution funktionieren und sich mit jeder anderen nachvollziehen lassen.

Installation

aptitude install ssh

Anlegen der für sftp berechtigten Nutzer und der Gruppe freunde

adduser mika
addgroup freunde
adduser mika freunde

Absichern des Chroot Verzeichnisses

chown root.root /home/mika

Mikas Heimverzeichnis sollte im Besitz von root sein, damit er effektiv darin eingesperrt ist und er standardmäßig keine Dateien auf dem Server hochladen kann. Da aber ein Datenaustausch auch manchmal in umgekehrter Richtung sinnvoll sein kann, genügt es, einen Ordner wie upload in diesem Verzeichnis zu erstellen und ihn Mika mit

chown mika.mika /home/mika/upload

zu überantworten.

Konfiguration von /etc/ssh/sshd_config

Notwendige Sicherheitsvorkehrungen

    • Port 42123

Der Standardport für SSH ist 22. Mit dieser Variablen lässt sich der Listen Port z.B. auf 42123 für den Server ändern. Das macht den Server zwar kein bisschen sicherer (security through obscurity), hilft aber unter Umständen die Existenz des ssh-Servers zu verschleiern.

    • PermitRootLogin no

Wenn ein Angreifer root werden möchte, muss er mit dieser Einstellung mindestens noch das Passwort eines weiteren Users auf dem Server kennen.

    • PermitEmptyPasswords no

SSH-Nutzer ohne Passwort sind natürlich ein Unding. Obwohl ich mir gut vorstellen kann, dass man das als eine weitere Möglichkeit zu "Was man mit alten Computern machen kann" hinzufügen könnte. Anstatt selbst zu lernen wie man in den eigenen alten Rechner einbricht, könnte man das doch auch andere tun lassen... 😉

    • Subsystem sftp internal-sftp

Das aktiviert sshds internen sftp-Service. Normalerweise verweist Subsystem sftp auf eine ausführbare Binärdatei wie z.B. /usr/lib/openssh/sftp-server. Diese muss durch den internen Dienst ersetzt werden.
Am Ende der /etc/ssh/sshd_config sollte dann folgender Match-Eintrag hinzugefügt werden.

Match group freunde
      ChrootDirectory /home/%u
      X11Forwarding no
      AllowTcpForwarding no
      ForceCommand internal-sftp

Der Match-Block gilt nur für die Gruppe freunde und jeden Nutzer, der sich darin befindet. Mika kann sich deswegen nur per sftp mit dem Server verbinden und landet danach im festgelegten Chroot-Verzeichnis. Der Shell Zugriff mit ssh wird effektiv unterbunden. Das Chroot muss nicht zwangsläufig mit Mikas Homeverzeichnis übereinstimmen und kann beliebig gewählt werden. Der Parameter %u wird durch den eingeloggten Nutzer ersetzt.

Der erste Test

Jetzt ist es an der Zeit den OpenSSH-Server neuzustarten. Als SFTP-Klienten eignen sich später z.B. das Firefox Addon Fireftp, Filezilla, WinSCP für Windows oder ganz einfach das Kommandozeilenprogramm sftp.

/etc/init.d/ssh restart

Danach sollte der sftp-Zugriff für Mika am Beispielrechner 192.168.0.200 funktionieren.

sftp -P 42123 mika@192.168.0.200

und der ssh-Zugriff verwehrt werden

ssh -p 42123 mika@192.168.0.200

DynDNS.org

Es ist zwar schön, dass der Server nun in unserem internen Netzwerk funktioniert, aber irgendwie müssen die Freunde von außerhalb darauf zugreifen können. Die meisten werden sicherlich eine dynamische IP vom Provider zugewiesen bekommen, weshalb es Sinn macht einen kostenlosen DNS-Dienst wie z.B. dyndns.org zu benutzen, um eine leicht zu merkende URL wie z.B. 4freunde.dyndns.org zu erhalten.
Nachdem man sich bei dyndns.org angemeldet hat, muss man dem Dienst auf irgendeine Art noch mitteilen wie die aktuelle IP-Adresse des Heimservers lautet. Dazu bietet sich z.B. ddclient an. Bei der Installation wird man nach Login und Passwort bei dyndns.org gefragt und kann ansonsten die Standardeinstellungen verwenden.
Sollte man eine Firewall einsetzen oder wie ich einen Router mit eingebauter Firewall haben, dann muss nur noch der SSH-Dienst mit Hilfe von PortForwarding an den Zielserver und Port 42123 weitergeleitet werden. Danach kann sich dann Mika von überall auf der Welt mit

sftp -P 42123 mika@4freunde.dyndns.org

auf dem Heimserver einloggen.

Last but not least - Denyhosts

Wenn man seinen Server eine Weile laufen lässt und spaßeshalber mal die Datei /var/log/auth.log öffnet, fallen einem die regen Zugriffsversuche auf...die allesamt nicht von den Freunden stammen. Willkommen im Internet! John Doh und Nihao versuchen mit Brute-Force-Attacken in den ssh-Server einzubrechen. Eine wirksame Methode das zu unterbinden ist z.B. denyhosts oder noch besser gleich den SSH-Port ändern und auf SSH-Schlüssel umstellen.
Bei Debian konnte ich nach der Installation mit den Voreinstellungen sehr gut leben. Die Datei /etc/denyhosts.conf ist aber hervorragend kommentiert und lässt sich leicht an die eigenen Wünsche anpassen. Das Programm registriert fehlgeschlagene Logins und setzt die IP Adresse des Angreifers nach einer festgelegten Anzahl von Versuchen in die Datei /etc/hosts.deny, womit jeder weitere Loginversuch verwehrt wird. Es gibt noch viele weitere Möglichkeiten einen Mißbrauch zu verhindern. Ich fand damals diesen Heise-Artikel zum Thema sehr lesenswert. Wenn man sehr restriktiv ist und vielleicht sogar die IP-Adresse der Freunde kennt, kann man auch alle Zugriffe mit Hilfe von /etc/hosts.allow und /etc/hosts.deny verbieten und nur ausgewählte IPs erlauben.
SSH ist ein ausgesprochen vielseitiges und nützliches Werkzeug. Als Beweis, dass ich nicht der Einzige bin, der positive Erfahrungen mit ssh gemacht hat, hier mal ein Link zu keros Artikel "sperr mich ein baby".

Meine Quellen