Artikel

Debian Squeeze: Anmeldung mit Gesichtserkennung

Nachdem wir einen entfernten SSH-Login sicher gemacht haben, sollte ja auch der lokale Login an einem Netbook, welches man überall mitnimmt auch vorhanden sein.
Da ich encfs nutze, sind meine Laufwerke verschlüsselt. Sie werden nach einer weiteren Passwortabfrage nach Login entschlüsselt. Also Loginpass !=Encfspass. Warum propagandieren eigentlich so viele Truecrypt wenn der Kernel schon Alles an Board hat?
Somit habe ich mich einmal durch das Internet gesucht und ein Modul für PAM gefunden, welches Gesichtserkennung unterstütz und es ist auch ansprechbar für reine Shellnutzer.
Also habe ich mir die Sourcen von der Downloadseite pam-face-authentication-0.3.tar.gz des Projektes pam-face-authentication heruntergeladen.
Nach dem entpacken des Verzeichnisses der Wahl wurden erst einmal die Abhängigkeiten installiert:

root@sayuri:/home/seraphyn# aptitude install libpam0g-dev cmake python-opencv libx11-6 libx11-dev libqt4-dev libqt4-core libcv-dev libcv2.1 libcvaux-dev libcvaux2.1 libhighgui-dev libhighgui2.1 -y

Und dann ging es an das kompilieren:

root@sayuri:/home/seraphyn/tmp/googlepam/pam-face-authentication-0.3# mkcd build
 root@sayuri:/home/seraphyn/tmp/googlepam/pam-face-authentication-0.3# cmake -D CMAKE_INSTALL_PREFIX=/usr ..
 root@sayuri:/home/seraphyn/tmp/googlepam/pam-face-authentication-0.3# make && make install

Wer möchte, kann natürlich anstelle des make && make install sich auch ein Debianpaket bauen

Als nächstes sollte der Gesichtstrainer benutzt werden, dies geschieht als User mit qt-facetrainer.
Gute Beleuchtung sollte schon sein und man sollte so viele Mitschneiden wie möglich. Es werden in dem Fall verschiedene Sets angelegt. Unter Advanced lässt sich noch die höhe der Sicherheit einstellen. Mehr Auskunft über das Verfahren gibt die Seite LIFEASIKNOW-IT mit dem Artikel PAM Face Authentication Musings: Face Verification using cascaded MACE and LBP based Classifier in welchem auch PDFs zu dem Thema verlinkt sind.

Nachdem diese Hürde geschafft ist bearbeitet man die Datei /etc/pam.d/login und fügt ein auth required pam_face_authentication.so hinzu.
Als Test sollte man erst einemal sufficient nehmen anstelle von required ;)
Wenn Alles wie gewünscht funktioniert braucht man die Fallback-Lösung nicht mehr und kann es mit required scharf stellen.
Wer das ganze noch für ein substitude user (su) haben möchte muss die Datei /etc/pam.d/su im gleichen Stil bearbeiten. Auch hier gilt erst sufficient, dann required. Nicht vergessen als root auch ein qt-facetrainer zu machen, sonst hat die UID keine Sets anhand man das Gesicht erkennen kann.
Wem das ganze mit einem netten „Login timed out after 60 seconds“ quittiert wird, sollte sich mal das File /etc/login.defs anschauen und zwar den Punkt LOGIN_TIMEOUT
Das Ganze geht auch noch für Loginmanager, aber da ich keinen benutze habe ich es hier nicht abgedeckt.

Das Ganze hat aber keinen Sinn, wenn Euer / nicht verschlüsselt ist, denn dann kann man per Grub, Live-Image das ganze aus PAM rausschmeissen.
Meine Empfehlungen für ein Netbook/Laptop im absoluten Paranoiamode sind deshalb:
– Biospasswort
– Grubpassword
– Festplatte/Ordner per encfs/luks verschlüsseln
– OTP setzen für die Loginshell
– Gesichtserkennung für die Loginshell
– USB-Stick/Smartcard mit Zertifikat
– Wenn Dropbox dann gpg
– Der Rest ergibt sich von selbst wie Emailverschlüsselung etc.
Klar ist das vielleicht überspitzt, aber es ist machbar und sind nette Hürden.

Viel Spaß mit der erweiterten Sicherheit

Artikel

Debian Squeeze: SSH zwei Stufenauthentifizierung mit google-authenticator

Ich habe vor ein paar Tagen mit dem Artikel „Google macht SSHD sicher“ über einen Artikel aus meinem Feedreader berichtet. Nun habe ich das ganze selbst ausgetestet und bin begeistert.

The Google Authenticator project includes implementations of one-time passcode generators for several mobile platforms, as well as a pluggable authentication module (PAM). One-time passcodes are generated using open standards developed by the Initiative for Open Authentication (OATH) (which is unrelated to OAuth).

These implementations support the HMAC-Based One-time Password (HOTP) algorithm specified in RFC 4226 and the Time-based One-time Password (TOTP) algorithm currently in draft.

Vorab zur Information:
– In den Sourcen des Modules für PAM gibt es keinerlei Kontaktaufnahme zu einem Google-Server
– Der einzige Aufruf befindet sich in der Datei ./google-authenticator.c um einen QR-Code zu generieren, dazu später mehr
– Die Androidapp nimmt kein Kontakt in das Netz auf, das einzige was sie möchte ist vibrieren.
– Wenn kein Zugang zu dem Smartphone besteht hat man noch Emergency Scratchcodes.
– Die Software ist eine Erweiterung der Sicherheit des sshd und es sollte nicht sonst ein passwortloser Login erlaubt werden

Ich gehe davon aus, dass der openssh-server und Compiler installiert sind.

root@xbmc:~/# mkcd ga
 root@xbmc:~/ga# aptitude install mercurial libpam0g-dev -y
 root@xbmc:~/ga# hg clone  google-authenticator
 cd google-authenticator/libpam/
 root@xbmc:~/ga/google-authenticator/libpam# make
 root@xbmc:~/ga/google-authenticator/libpam# make install

cp pam_google_authenticator.so /lib/security
 cp google-authenticator /usr/local/bin
 sudo chmod 755 /lib/security/pam_google_authenticator.so 
 /usr/local/bin/google-authenticator

Da wir uns nicht als root per ssh anmelden, so etwas gehört sich nicht, nehmen wir substitude user und wechseln den Account zur generieren des Codes:

root@xbmc:~/ga/google-authenticator/libpam# su seraphyn
 seraphyn@xbmc:/root/ga/google-authenticator/libpam$ google-authenticator
 https://www.google.com/chart?chs=200x200&chld=ETCETCETCETC
 Your new secret key is: BLABLABLABLA
 Your verification code is NUMBERSNUMBERSNUMBERS
 Your emergency scratch codes are:
 MORENUMBERS

Do you want me to update your "~/.google_authenticator" file (y/n) y

Do you want to disallow multiple uses of the same authentication
 token? This restricts you to one login about every 30s, but it increases
 your chances to notice or even prevent man-in-the-middle attacks (y/n) y
 seraphyn@xbmc:/root/ga/google-authenticator/libpam$ exit

Nicht vergessen die ganze Ausgabe abzuspeichern, denn die URL und vor allen die Codes werden später noch gebraucht.
Ich gehe nicht davon aus, dass auf einem Server eine GUI ist.

Jetzt müssen nur noch der SSH-Server und PAM konfiguriert werden um Google Authentication zu nutzen.
In der Datei /etc/pam.d/sshd muss noch pam_google_authenticator.so hinzugefügt werden:

# /etc/default/locale, so read that as well.
 auth required pam_env.so envfile=/etc/default/locale
 auth required pam_google_authenticator.so

und in der Datei /etc/ssh/sshd_config das Challenge-Response-Verfahren aktiviert werden:

# Change to yes to enable challenge-response passwords (beware issues with
 # some PAM modules and threads)
 ChallengeResponseAuthentication yes

Nach der Installation von Google Authenticator auf Android startet man diesen.
Wenn man die aus der Shell generiert URL in seinem Desktopbrowser aufruft bekommt man einen QR-Code, welcher mit dem auf Android installiertem Google Authenticator per Menü > Scan account barcode ausgelesen wird.
Der 6stellige Code generiert sich alle 30 Sekunden neu und man kann in Ruhe die App auflassen und sich davon überzeugen ツ
Auf der Maschine die nun pam-google-authenticator nutzt kann der SSH-Server neu gestartet werden.
Beim erneuten Einloggen erscheint nun:

Verification code:
 Password:

Als erstes soll man den auf dem Smartphone angegebenen Code eingeben, danach das normale Passwort.
Wenn nun das Smartphone nicht vorhanden ist, dann kann einer der 6 emergency scratch codes genommen werden.

Achtung: Falls der User keinen generierten Schlüssel in seinem $HOME hat (.google_authenticator) wird dieser nicht der Zweistufenauthenifizierung unterzogen.

Artikel

Debian Squeeze: Systray für ion3

Ein Systray, etwas was ich normalerweise nicht unter ion3 brauche, wurde von mir Heute doch einmal gebraucht.
Somit habe ich nachgeschaut welche Optionen ich unter ion3 habe und mich für die Beste, trayion, entschieden.

Trayion is meant to be used as an external application for Ion3. Trayion provides a notification area, or „system tray“, in a manner compliant with freedesktop.org’s System Tray Protocol Specification. This allows Trayion to serve as a system tray area for recent GNOME and KDE applications, and it should work for applications from GNOME 2.x and later or KDE 3.x and later.

It behaves like a Window Maker dockapp, so it can be redirected into the Ion3 statusbar. It implements FreeDesktop (XEmbed) trayicon protocol, so it can show trayicons from Qt4 and gtk2 applications.

Das trayion-0.1.2.tar.gz ist relativ schnell heruntergeladen und wer möchte kann sich das ganze auch aus dem Git clonen:

seraphyn@sayuri:~$ git clone git@github.com:laynor/trayion.git

Nach dem kompilieren hat man das Binary in dem Verzeichnis $COMPILEPATH/trayion-0.1.2/trayion, welches ich in $HOME/bin/ kopierte.
Nun muss man die Datei /etc/X11/ion3/cfg_kludges.lua in $HOME/.ion3/ kopieren und den Absatz defwinprop für das systray wie folgt bearbeiten:

defwinprop{
 is_dockapp = true,
 statusbar = "systray",
 --max_size = { w = 64, h = 64},
 --min_size = { w = 64, h = 64},
 }

Nun noch die .xinitrc um folgendes vor dem Ausführen von ion3 erweitern:

trayion -iconsize 10 &

Nach einem Neustart sieht das ganze dann so aus:
Statusbar für Notion ion3
Mir war vor allem die Größe (10) der Icons in der Statusbar wichtig, da sich das ganze auf meinem netbook befindet.

Artikel

Google macht SSHD sicher

Ich kann mich noch daran erinnern wie ich damals den RSA-Schlüsselanhänger implementiert habe.
Tolle Sache diese SecureID. Man hat einen Schlüsselanhänger mit, ach was Erkläre ich das Wikipedia EN: SecureID.
Auf jeden Fall es hat mich fasziniert und ich gebe das gerne immer als Sicherheitstip weiter, das inkl eines Passwortes, welche noch angegeben werden muss als relativ Okay empfinde. Auch wenn es schon Attacken dagegen gab.
Komisch, ich weiss, aber Hey, besser als wenn die User nur ein Passwort haben und das PostIT und Konsortengerecht verteilt, Ihr wisst schon.
Nun hat Google seine Zweifaktorauthentifizierung für Jedermann freigegeben.
Ich habe eine Anleitung Heute in meinem Feedreader gehabt, welche erklärt wie man mit Hilfe von PAM ( Pluggable Authentification Module, ich mag das, damit kann man einiges machen, z.B. Gesichtserkennung für einen Login etc) und einem Smartphone die Authentifizierung durchführen kann.
Ich werde das Ganze mal auf Debian Squeeze testen und mir die Sourcen anschauen.
Denn irgendwie hat man schon ein komisches Gefühl Google an sein PAM zu lassen. Aber fasziniert bin ich von dieser Sache und denke mir Passwort, Key und das Googlepamplugin zusammen sind eine wirklich gute Idee.

Turning on 2-step verification: Installing Google Authenticator
The application doesn’t require an Internet connection, mobile service, or a data plan to generate verification codes.

Artikel

Debian Squeeze: Enlightenment E17

E17 scheint bei vielen Gut anzukommen, auch bei mir.
Nachdem ich mal KDE nutzte, mir Gnome anschaute und dann damals merkte, dass ein DE nicht meine Wünsche erfüllte kam ich zu den spartanischen WMs. Ich nutzte mal waimea, E16 und blieb am Schluss bei ion3 hängen. Es gab auch mal Momente indem ich wmii, ratpoison testete, aber wenn man einmal seinen WM gefunden hat, dann ist es so. In der Arbeit nutze ich auf AIX CDE, aber das ist ein anderes Thema. Weiterlesen

Artikel

Debian Squeeze: rxvt-unicode mit 256bit Farben

Eines nervt mich sehr an urxvt, das ist der Farbsupport.
Zwar ist der Patch in den Sourcen bei Debian Squeeze vorhanden, aber er wird nicht für das Binary angewendet und ich kann somit nur wirklich laue Farben in vim/newsbeuter und Konsorten nutzen. Entschuldigung, aber das ist ein Zustand, welcher behoben werden muss, da ich mein Leben zu 90% auf der Shell verbringen.
Aber seht selbst:

Farbloses URXVT

Farbloses URXVT


Kann ich nicht akzeptieren, ich brauche ja auch mein BlingBling ツ
Die Lösung ist eine einfache: Selbst ein deb bauen, da ich absolut keine mehr hoste und die alten unter Files nur noch wegen der Verlinkung vorhanden sind. Die Gründe dafür lassen sich aus dem Blog rauslesen.

root@sayuri:/home/seraphyn/compileee/# mkcd urxvt
 root@sayuri:/home/seraphyn/compileee/urxvt# apt-get build-dep rxvt-unicode
 root@sayuri:/home/seraphyn/compileee/urxvt# cd rxvt-unicode-9.07/
 root@sayuri:/home/seraphyn/compileee/urxvt/rxvt-unicode-9.07# ls doc/
 root@sayuri:/home/seraphyn/compileee/urxvt/rxvt-unicode-9.07# patch -p1 < doc/urxvt-8.2-256color.patch
 root@sayuri:/home/seraphyn/compileee/urxvt/rxvt-unicode-9.07# dpkg-buildpackage -us -uc
 root@sayuri:/home/seraphyn/compileee/urxvt/rxvt-unicode-9.07# cd ..
 root@sayuri:/home/seraphyn/compileee/urxvt# dpkg -i rxvt-unicode_9.07-2_i386.deb

Und siehe da.

Farbenfrohes URXVT

Farbenfrohes URXVT

Artikel

Debian Squeeze: Redseliges SSH

Was mir bei vielen Paketen einfach nicht gefällt ist ein Faktor:

seraphyn@sayuri:~$ nmap -sV 192.168.1.1

Starting Nmap 5.00 ( http://nmap.org ) at 2011-02-07 09:58 CET
 Interesting ports on 192.168.1.1:
 Not shown: 996 filtered ports
 PORT STATE SERVICE VERSION
 22/tcp open ssh OpenSSH 5.5p1 Debian 6 (protocol 2.0)

Wer dies absolut nicht verknusen kann, welches ich verstehe, sollte sich mal die Datei /debian/patches/debian-banner.patch aus den openssh-server-Sourcen anschauen und das Paket recompilieren.
Das ganze basiert auf den Bugreport #562048, welches schon etwas weniger über das darunterliegende Linux aussagt.
Natürlich ist es auch möglich absolut die Version von dem openssh-Server zu verstecken, aber einen sinn hat dies nicht, siehe dazu auch:
RFC: The SSH (Secure Shell) Remote Login Protocol

und

OpenSSH-FAQ: 2.14 Why does OpenSSH report its version to clients?
This information is used by clients and servers to enable protocol compatibility tweaks to work around changed, buggy or missing features in the implementation they are talking to. This protocol feature checking is still required at present because the SSH protocol has not been yet published as a RFC and more incompatible changes may be made before this happens.

IMHO ist der Rest Security Through Obscurity und hat keinen Sinn.
Lieber den Server richtig sicher machen, dazu gibt es genug Anleitungen im Netz….

Artikel

Und es raschelt wieder mit Debian Squeeze

Hach wie schön ist es alle Releases bei Debian mit den gleichen Kommentaren zu lesen wie bei jedem Release:
Debian ist doch jetzt schon veraltet
Debian ist nur Gut für Server
Debian ist die stabilste Distribution überhaupt
Ich benutze Debian aber doch auf dem Desktop
Firmen nutzen Debian nicht, weil es keinen Enterprise-Support hat.
Debian ist zu schwer für den einfach Endanwender
In Debian ist $DESKTOPENVIRONMENT doch komplett veraltet
Für das Paket $XYZ gibt es doch schon eine neuere Version
Wird es bei Debian für $SOFTWARE ein Backport auf Backports.org geben?
Wenn es Dir bei Debian nicht passt, dann kompiliere es Dir doch selber
Ich habe keine Probleme/Herausforderung mit Debian
Debian macht was es soll
Es ist fertig, wenn es fertig ist…
Dann nimm doch die netinstall, wenn Dir anderes zu groß ist
Gehe zu einem Freund und lade Dir die DVD-Images herunter
Nimm halt Ubuntu
Debian ist die Grundlage für soviele Distribution/ für Distribution $XYZ
Nicht einmal Treiber sind alle onboard, wie soll….?
Die Non-Free-Images bekommst Du…
Das ganze ist beliebig erweiterbar. Da könnte man wirklich mal ein Textbausteinsystem schreiben, denn jedes Release ist es eigentlich das gleiche.
Ich für meine Seite nutze nun die „Auspresser“-Version seit einem Jahr neben Unix und bin Glücklich damit. Nachdem der Bug für rsyslog mit mysql gelöst wurde habe ich von meiner Seite aus keinen weiteren gefunden. Vielleicht noch jener, dass abook öfter sein Adressbuch killt. Kann aber sein, dass dies an mir liegt, wegen runterfahren ohne abook vorher zu schliessen. Es wird vielleicht beim abschliessenden schreiben gekillt. Falls dies nochmals passiert, schaue ich mal, dass ich einen Bugreport schreibe.
Und für mich gibt es nun auch die immerwiederkehrende Aussage, welche ich oben extra ausgelassen habe, aber für mich die wichtigste ist, man kann sie nicht oft genug sagen:

Danke an die Entwickler
Artikel

Debian Squeeze / Wheezy HowTo : In 5 Minuten Access-Point mit hostapd

Wer kennt das nicht, APs welche man kaufen kann werden leider nicht lange genug mit Updates versorgt wie man es sich gerne wünscht.
Auch die Sicherheit ist gerade nicht jene, welche ich gerne hätte und den AP mal schnell als Repeater zu nutzen ist auch bei den meisten nicht möglich.
Da bei mir ein Laptop als Server nun läuft, weil ich meinen Dell-Server nicht den Hitzetod sterben lassen wollte, dachte ich mir, warum nicht gleich die Maschine auch zu einem AP machen. Lösung der Wahl ist der hostapd

Weiterlesen