Kleine und große Linux AHAs
Beiträge getaggt mit daemon
Unleserliches debuggen, oder: Fehlersuche in verschlüsselten Protokollen
03. Mai
Immer mehr Datenverkehr wird verschlüsselt. Einerseits natürlich richtig und gut. Andererseits ein Problem. Früher konnte man mit Hilfe von Tools wie Wireshark (Ethereal) oder tcpdump relativ schnell Probleme (z.B.) in der Kommunikation zwischen Programm und Server herausfinden. Einfach den Netzwerkverkehr mitschneiden, ansehen / auswerten und es zeigten sich Fehler die man im Programm möglicherweise nicht zu Gesicht bekommen hat.
Mittlerweile sind die Pakete weitestgehend verschlüsselt und man kann nicht mehr einfach so “mit schreiben” – naja, man kann natürlich; aber lesen kann man es nicht. Also fällt ein mitschreiben – einfach mal so – flach.
Eine andere Möglichkeit die Kommunikation zwischen Programmen zu debuggen ist, sich einfach manuell zu verbinden und die Kommandos direkt einzugeben um zu prüfen ob der Server richtig reagiert. Dazu nahm man früher telnet … Auch telnet ist kein Kandidat mehr für verschlüsselte Protokolle.
Verbindung zu einem SSL geschützten Dienst
Eine Möglichkeit sich auf einen solchen Dienst zu verbinden bietet der Befehl
openssl s_client -connect <Zielrechner>:<Port>
Mit diesem Befehl kann man sich beispielsweise direkt auf einen per SSL geschützten IMAP Server (Port 993) verbinden und manuell Kommandos absetzen. Das ganze über eine SSL geschützte Verbindung – die nicht mitgeschnitten werden kann 
Ganz wie früher mit telnet *freu*
(No Ratings Yet)
Loading ...
Openvpn: Tür auf, Tür zu, Tür auf, Tür zu …
20. Aug
Betreibt man einen Openvpn Server – beispielsweise zur Einwahl von Dienstleistern oder auch einfach nur für “normale” Benutzer – so sollte man das ganze mit einem Zertifikat abgesichert haben. Das ganze geht unter Debian/Ubuntu (und auch anderen) recht einfach mit easy-rsa. Jeder Client bekommt seinen eigenen Key und kann damit den Tunnel aufbauen.
Tür zu?
Was nun, wenn man einen Client aussperren möchte? Der Dienstleister ist ab sofort “böse”. Die Zusammenarbeit beendet. Er hat noch seinen Key und kann sich damit per Openvpn verbinden und ins interne Netz (soweit die Firewall den Zugriff zulässt). Eigentlich ganz einfach. Der Key des Benutzers wird “revoked” – das geht auch per easy-rsa recht einfach. Ist der Key revoked, so ist der Key für Openvpn ungültig und die Verbindung kann nicht mehr aufgebaut werden. Fertig.
Tür wieder auf?
Ganz anders sieht das aus, wenn man einen Benutzer hat der sich einwählen können soll, jedoch nur dann wenn man es möchte. Man vereinbart quasi einen Termin an dem irgendetwas gemacht werden soll und zu diesem Termin hat der Client Zugriff. Ist der Key eines Benutzers einmal “revoked”, dann ist das erstmal so. Einen Key wieder freizuschalten ist nicht so einfach zu machen.
Tür zu, Tür auf: Openvpn Switching
Ganz einfach ist das ganze zu machen, indem man den Parameter ccd-exclusive dazu benutzt. Dieser Parameter lässt nur Clients zu, die eine Konfigurationsdatei im sogenannten client-config-dir (Parameter in der openvpn Konfig) besitzen. Man kann diese Dateien nutzen, um Clientkonfigurationen zu setzen. Dazu wird in dem Verzeichnis eine Datei mit dem CN (der eindeutige Name/Zeritifikat) des Benutzers angelegt.
Der Parameter ccd-exclusive bewirkt nun, dass nur Clients sich verbinden dürfen, für die eine Datei im ccd vorhanden ist – mit dem genauen Namen (CN). Ob diese Datei nun gefüllt ist mir einer Clientspezifischen Konfiguration oder leer ist, das macht dabei keinen Unterschied. Um einen Client zu sperren muss man also lediglich die Datei im ccd beispielsweise in “disabled-<CN>” umbenennen. Das ganze funktioniert ohne Neustart des Daemons 
(No Ratings Yet) Loading ...
Home NAS mit iSCSI – Format, Crypt und gut (Teil 3/3)
12. Apr
Teil I (hier) zeigte die Einrichtung des Servers inkl. iSCSI-Target.
Teil II (hier) zeigte die Einrichtung des Initiators – des Clients.
Teil III zeigt nun die restlichen Arbeiten – verschlüsseln der Platte, formatieren und den “luxuriösen” Zugriff darauf.
Verschlüsseln
Alleine um sich davor zu schützen, irgendwelche Daten aus versehen – z.B. wenn man eine alte Festplatte verkauft – an “unbefugte” weiter zu geben, sollte man seine Daten verschlüsseln. Daher habe ich die Daten auf meinem Laptop verschlüsselt und mache gleiches natürlich auch mit meinem Backup.
Unter Linux gibt es mehrere Möglichkeiten Festplatten, Partitionen oder auch nur Dateien zu verschlüsseln. Ich halte LUKS / Cryptsetup (Homepage) für eine der einfachsten Möglichkeiten.
Unter Ubuntu ist cryptsetup nicht in der Standardinstallation enthalten. Von daher muss das Paket installiert werden ->
apt-get install cryptsetup
Aus dem vorhergehenden Artikel sollten wir eine weitere Festplatte im System sehen. Beispielsweise /dev/sdb. Auf dieser Platte legen wir nun eine Partition an (/dev/sdb1) und verschlüsseln diese:
cryptsetup luksFormat /dev/sdb1
Nach Aufruf dieses Befehls wird nach einer Passphrase gefragt. Diese sollte – wie jedes Passwort – möglichst sicher gewählt werden. Mit Hilfe von LUKS / Cryptsetup werden die Daten während des Schreibens auf die Festplatte verschlüsselt, bzw. während des Lesens entschlüsselt. Dadurch dauert die Initiale Verschlüsselung nicht lange. Wirklich verschlüsselte Daten gelangen erst mit der Formatierung auf den Datenträger.
Formatieren
Die Passphrase für die Platte ist eingegeben. Nun muss die Platte ein Dateisystem bekommen damit wir damit arbeiten können. Dazu muss die Platte zuerst einmal per Luks “geöffnet” werden (wir haben bisher nur den Schlüssel angelegt).
cryptsetup luksOpen /dev/sdb1 SecureISCSI
Dieser Befehl fragt nun nach der Passphrase und legt – bei korrekter Eingabe – ein Device unter /dev/mapper mit Namen “SecureISCSI” an. Dieses ist dann das wirkliche Device, mit dem wir ganz normal arbeiten können.
mkfs.ext3 -L SecureISCSI /dev/mapper/SecureISCSI
Damit ist die Platte formatiert und kann gemountet / beschrieben werden.
Um das ganze zu vervollständigen: nach dem umounten kann das “entsicherte” Device (/dev/mapper/SecureISCSI) mit dem Befehl
cryptsetup luksClose /dev/mapper/SecureISCSI
wieder “verriegelt” werden.
Luxuriöser Zugriff
Was ich mittlerweile wirklich geil finde und vorher so gar nicht gewusst habe ist, wie man diese Festplatte nun unter Ubuntu nutzen kann.
Wenn ich meinen Laptop starte und mein Server ist verfügbar, werden mir die iSCSI Platten in Nautilus (Dateimanager) angezeigt (ich habe mehrere erzeugt). Die verschlüsselten Platten werden dabei als “290 GB verschlüsselt” angezeigt, die anderen mit ihrem Label (s. mkfs.ext3 -L …). Klickt man nun auf die “290 GB verschlüsselt”, so öffnet sich ein Dialog der mich nach der Passphrase fragt. Ich gebe die Passphrase ein und bekomme die Platte gemountet – mit ihrem Label, welches das System nun nach der Entschlüsselung erkannt hat. Ich kann direkt darauf zugreifen und beispielsweise per rsync meine Daten vom Laptop sichern.
fstab
Damit das ganze so einfach funktioniert, ist eine kleine Erweiterung der /etc/fstab notwendig. Macht man das ganze ohne diese Erweiterung, so wird man nach der Passphrase gefragt, zum mounten wird der Admin Zugriff abgefragt und als normaler User hat man dann keinen Zugriff sondern nur als root.
Um das zu umgehen trägt man in der fstab folgendes ein:
LABEL=SecureISCSI /media/SecureISCSI ext3 defaults,user,noauto 0 1
Damit ist der mountpoint bekannt und das wichtigste – es sind Optionen gesetzt. Die interessanteste dabei ist “user”, was so viel bedeutet wie “jeder Benutzer darf dieses Device auf diesem Mountpoint mounten und es auch wieder umounten”.
Wichtig ist hier auch, dass man dem Filesystem ein Label vergibt. Die iSCSI Platten müssen nicht immer den gleichen Gerätenamen (z.B. /dev/sdb) bekommen. Je nach dem ob beispielsweise ein USB Stick eingesteckt ist, kann es auch mal /dev/sd{c,d,e,f…} sein. Hat man jedoch ein Label vergeben, so spielt das eigentliche Device keine Rolle mehr. Alternativ könnte man auch mit der UUID arbeiten.
Ich hoffe dieser Artikel war recht interessant – über Feedback würde ich mich durchaus freuen
.
(No Ratings Yet) Loading ...
xdrp: auch ne Möglichkeit für Remote Zugriff
26. Feb
Es gibt unter Linux viele Möglichkeiten sich remote an einem System anzumelden – auch viele das grafisch zu tun. Da gibt es zum Beispiel XDMCP, X11 über einen ssh Tunnel, VNC, freenx oder das kommerzielle Pendant, … All diese Möglichkeiten waren mir bisher bekannt und ich habe sie auch schon mal ausprobiert. Aus irgendeinem Zufall bin ich nun auf was – für mich – neues gestossen: xrdp.
xrdp kann quasi VNC in das RDP Protokoll umschreiben und dadurch VNC über RDP zur Verfügung stellen. Das ganze ist recht interessant, da der RDP Client bekannterweise in einem von mir nicht zu nennenden “Betriebssystem” zur Standardausrüstung gehört und somit von diesen Clients aus keine extra Software / Installation benötigt wird.
Installation
Die Installation unter Ubuntu ist denkbar simpel -> apt-get install xrdp.
Konfiguration
xrdp läuft nach der Installation automatisch. Allerdings muss man um Zugriff auf den Rechner zu gewähren über die Gnome Desktop Einstellungen den VNC Server starten. Das ganze findet sich unter Menü-System-Einstellungen-Entfernter Bildschirm. Dort muss man “Anderen Benutzern erlauben, Ihren Bildschirm anzuzeigen” und “Anderen Benutzern erlauben, Ihren Bildschirm zu steuern” aktivieren. Des Weiteren sollte man ein Passwort setzen. Dieses hat jedoch nichts mit dem Anmeldepasswort des Accounts zu tun.
Anmeldung per RDP
Nun wird der RDP Client mit dem Rechner verbunden. Es erscheint ein Menü, in diesem man den Typ “Console” für die Sitzung wählt und kann dann mit dem vergebenen Passwort auf seine Sitzung zugreifen.
Naja
Also so wie ich es beschrieben habe gefällt es mir an sich selbst nicht. Ein großer Nachteil der Lösung ist, dass der Vino-Server (VNC Server unter Gnome) bei einem gesperrten Bildschirm versagt -> einen schwarzen Bildschirm zeigt. Des Weiteren ist in diesem Szenario der RDP Port als auch der VNC Port auf der Maschine offen. Gepaart mit dem “schwachen” Passwort welches wie oben konfiguriert haben, ist das nicht wirklich Sicher.
Man kann den Vino-Server auch deinstallieren und dafür x11vnc nehmen. Damit funktioniert das ganze auch bei gesperrtem Bildschirm. Leider ist damit die Performance um einiges schlechter. Ich habe keine Einstellung gefunden mit der x11vnc über xrdp so flüssig läuft wie mit dem Vino-Server. Da beißt sich die Katze in den Schwanz.
(No Ratings Yet) Loading ...
sftp Server Teil II – “Jail made easy”
08. Feb
Im ersten Teil haben wir das aktuelle openssh Paket für RHEL gebaut und sollten das auch mittlerweile installiert haben. Die Konfiguration des SSH-Servers hat sich nur wenig geändert. Es gibt eigentlich auch nur wenig neue Stellen die hier für uns interessant sind. Aber wir beginnen am Anfang:
Gruppe für sftp
Die Steuerung ob ein Benutzer in einer “gechrooteten” Umgebung landet wird über eine Gruppe gesteuert. Diese könnte man beispielsweise “sftpchroot” nennen. Diese Gruppe wird also angelegt:
groupadd sftpchroot
Benutzer anlegen
Als nächstes muss der Benutzeraccount angelegt werden, der sich auch in der Gruppe sftpchroot befindet:
useradd testuser -G sftpchroot
(Passwort setzen oder disablen, je nach dem ob sich per Key oder Passwort eingeloggt werden soll. Eine Shell benötigt der User auch nicht unbedingt.)
Benutzerhome anpassen
Das Benutzerhome (/home/testuser) muss von den Rechten her angepasst werden, damit das “chrooten” funktioniert. Gleichzeitig legen wir ein Verzeichnis (exchange) an, in welches der Benutzer über sftp schreiben darf.
chown root:sftpchroot /home/testuser mkdir /home/testuser/exchange chown testuser:testuser /home/testuser/exchange
Möchte man die Authentifizierung per Key machen, so muss folgendes ebenfalls eingerichtet werden:
mkdir /home/testuser/.ssh chown testuser:testuser /home/testuser/.ssh
Der Key kommt dann in die authorized_keys; die Rechte werden auf 0600 gesetzt und fertig.
Logging
Wir möchten genau sehen, welche Befehle auf dem SFTP Server abgesetzt werden. Daher muss auch das Logging aufgesetzt werden. Dazu ist es nötig, dass in jedem Home ein dev Verzeichnis angelegt wird (-> mkdir /home/testuser/dev). Dort wird dann vom dem Syslog Server des Vertrauens eine Pipe angelegt und damit ist das Logging im System.
Wir verwenden den syslog-ng (syslog-ng). Die Konfiguration dafür sieht wie folgt aus:
source s_sftpchroot {
# Please add each chrooted environment here
# These logs stay on the local machine; not sended to the syslog-server
unix-stream ("/home/testuser/dev/log");
};
destination d_sftplog { file("/var/log/sftp_chrooted.log"); };
log { source(s_sftpchroot); destination(d_sftplog); };
Jede Chroot Umgebung muss hier im Abschnitt “source” eingetragen werden. Damit fließen alle sftp logs in eine Datei. Alternativ kann natürlich auch für jeden Benutzer ein eigenes Log geschrieben werden. Welche Konfigteile dazu angepasst werden müssen sollte ersichtlich sein
Openssh Chroot
Nun zu dem früher schwierigsten, heute jedoch einfachsten Teil. Das Openssh Chroot. Ich zeige einfach die Konfiguration – it`s that easy !
Subsystem sftp internal-sftp Match group sftpchroot X11Forwarding no AllowTcpForwarding no ForceCommand internal-sftp -l VERBOSE ChrootDirectory /home/%u
Mit dieser Konfiguation am Ende der sshd_config (/etc/ssh) bekommt jeder Benutzer, der sich in der Gruppe sftpchroot befindet, besondere Optionen. Unter anderem wird lediglich der interne sftp-server (internal-sftp) zugelassen, der mit dem Parameter “-l VERBOSE” sämtliche Befehle des Benutzers loggt. Fertig.
(No Ratings Yet) Loading ...perl daemon mit input aus einer named pipe
07. Mai
Auch sowas wo ich lange nach gesucht habe. Möchte man, dass ein Perl Programm den Input einer named pipe verarbeitet, so wird man als erstes auf ein Problem stossen. Das Programm wird sich nach jeder Eingabe beenden. Mein erster Code sah zum Beispiel so aus:
#!/usr/bin/perl -w
open(THISPIPE, ") {
echo $_;
}
close THISPIPE;
So würde wohl jeder erste Versuch aussehen. Das Problem liegt darin, dass sobald Daten über die Pipe ausgetauscht werden, auch ein EOF mitgegeben wird. Dieses EOF wird von Perl als solches auch interpretiert und die Datei wird geschlossen.
Umgehen kann man das, indem man einen Trick anwendet und die Datei nicht nur zum lesen öffnet, sondern zum Lesen und Schreiben. Dadurch wird die Datei nicht nach einem EOF geschlossen und der Daemon lauscht weiterhin auf der Pipe. Das sieht dann so aus:
#!/usr/bin/perl -w
open(THISPIPE, "+) {
echo $_;
}
close THISPIPE;
(No Ratings Yet) Loading ...
