Entries tagged as security
Related tags
bad world blog blogging browser captcha changes computer dns firefox fun google hardware html life lighttpd linux&unix media misc murphy networking opensource politics privacy programming s9y server software spam stuff tail -f /var/log/life tv video web webdesign webwide zeitgeist code contentmanagement free markup rss ruby tool wordpress javascript linux shortys android apple cheatsheet comic css datamining documentation eigenfaces encryption feedreader gui howto http im ios iphone jabber java mail mobile newsbeuter picture podcast presentation psi rant realtime regular expression rest scala screenshot sdk subnetting swing test truecrypt unix websockets windows xml xslt perl coffee conference dslr nikon photography science codec vp8 forum unb 1 2An meiner Hochschule findet nun am 25. April 2008 der erste "Security Day" im Jahr 2008 statt.
Wie bisher gibt es interessante Vortraege von Studenten und Menschen, die sich beruflich mit dem Thema befassen. Reinschauen lohnt sich.
§ 5 Abs. 2 Nr. 11 Satz 1 Alt. 2 VSG, der den heimlichen Zugriff auf informationstechnische Systeme regelt ("Online-Durchsuchung"), verletzt das allgemeine Persönlichkeitsrecht in seiner besonderen Ausprägung als Grundrecht auf Gewährleistung der Vertraulichkeit und Integrität informationstechnischer Systeme und ist nichtig.
Der Bundestrojaner wurde zwar nicht komplett verboten aber zum Glueck stark eingeschraenkt. Hier mal ein Zitat von SpOn:
Es sind Hürden, die weit höher liegen als die bei Eingriffen in das Post- und Fernmeldegeheimnis oder gar die allgemeine Handlungsfreiheit - und die mehr den strengen Kautelen ähneln, die für den Schutz der Unverletztlichkeit der Wohnung gelten wie beim Großen Lauschangriff.
Quarks & Co: Die Waffen der Terror-Fahnder
Quarks & Co: Einkaufen - Wie wir uns manipulieren lassen
Kuckt es euch mal an. Es lohnt sich. ![]()
Doener berichtet ueber einen brandheissen Bug in StudiVZ der dadurch entsteht, dass beim Verlinken von Bildern User-IDs nicht ueberprueft werden:
Es geht um folgendes: Im StudiVZ kann jeder ihm bekannte Personen auf Fotos verlinken. Von dieser Möglichkeit wird auch reger Gebrauch gemacht. Wie ein Freund von mir nun feststellte, ist es möglich mittels des Firefox-Plugins Web Developer, den Wert, wer ein bestimmtes Foto mit wem verlinkt hat, beim Setzen des Links zu manipulieren. Mit Hilfe des Web Developer-Tools ist es also möglich, Fotos zu verlinken und dabei so zu tun, als hätte jemand anderes das entsprechende Foto mit einer bestimmten Person verlinkt.
Ihr findet dort auch eine Anleitung wie man das mit der Webdeveloper-Erweiterung fuer Firefox realisiert. Da ich StudiVZ selbst nicht nutze, kann ich das leider nicht ausprobieren. Ich waere aber interessiert an weiteren Berichten.
Wer immer noch glaubt, dass durch Wahlcomputer die Wahlen schneller ausgezaehlt werden koennten, sollte sich ma das hier ankucken. Da ist durch den Einsatz von Wahlcomputern die Wahlbeteiligung von 60% auf 7% gesunken. Das Ergebnis wurde dann zurueck gezogen und neu gewaehlt. Das Ergebnis spricht fuer sich.
Wann lernen die Leute endlich, dass man so etwas wichtiges wie eine Wahl nicht einem leicht manipulierbaren Geraet wie einem Computer anvertrauen will?
Dieses Mal ganz boeses Foul bei den Hessen.
Neben massiver Behinderung der Wahlbeobachtung in mehreren Gemeinden kam es zu einer Reihe von Vorfällen, welche die Behauptungen des hessischen Innenministeriums über die Sicherheit und Zuverlässigkeit der Wahlcomputer klar widerlegen. In mindestens einer Gemeinde wurden die Computer über Nacht in den Privatwohnungen von Parteimitgliedern gelagert. Dies sei "gängige Praxis", bestätigten Mitarbeiter des Ordnungsamtes den Wahlbeobachtern. Alle neun Wahlcomputer der Gemeinde Niedernhausen seien privat gelagert worden.
Na dann hoffen wir mal, dass die die Wahl nun nochmal und zwar auf Papier durchfuehren muessen.
Ich musste gerade > 20 Spam-Trackbacks loeschen, die im letzten Tag hier aufgetroffen sind. Das geht zwar schnell und schmerzlos, aber als bekennender Spamhasser muss ich da wohl noch weitere Massnahmen ergreifen um diesem unwuerdigen Abschaum keine Angriffsflaeche zu bieten. narf
Zur Entspannung:
Und hier der Direktlink.
.. liefert Heise Security. Mit verdammt realistischen Vorraussagen.
Hier findet man mal ein paar einleuchtende Argumente gegen PHP als Programmiersprache der Wahl.
Bei dieser Gelegenheit koennte ich mal laut darueber nachdenken auf ein Blog-System wie Typo oder Mephisto umzusteigen. Beide sind, im Gegensatz zu Wordpress, in Ruby on Rails geschrieben.
Leider hatte mein Server in letzter Zeit seltsame Performanceprobleme. Der Apache hat mir staendig meinen Swapspace voll gemacht und wollte dann nicht mehr. Das war mehr als unbefriedigend.
Da ich schon lange mal den schicken und schnellen lighty ausprobieren wollte, habe ich nun komplett auf lighty umgestellt. Zusammen mit xcache laeuft das Setup, im Vergleich, verdammt schnell. Ein gutes Howto wie man php mit lighty sicher aufsetzt findet man hier.
Probleme gab es nur bei den Rewrite-Regeln fuer Wordpress. Hier haben folgende Anweisungen das Problem geloest:
"^/(.*)?/?files/$" => "index.php",
"^/(.*)?/?files/(.*)" => "wp-content/blogs.php?file=$2",
"^/(wp-.*)$" => "$1",
"^/([_0-9a-zA-Z-]+/)?(wp-.*)" => "$2",
"^/([_0-9a-zA-Z-]+/)?(.*\.php)$" => "$2"
)
server.error-handler-404 = "/index.php"
Das mit dem "server.error-handler" ist zwar nicht besonders schoen aber funktioniert.

Vorwort:
Vielen werden grosse Teiles dieses Howtos wohl bekannt vorkommen. Mittlerweile sind schon ein paar Monate vergangen, seit ich das letzte cryptsetup-LUKS Howto geschrieben habe. Ich habe mir hier beim Ueberarbeiten auch mehr Zeit genommen als beim eigentlichen Howto.
Eigentlich war noch ein Howto zum Verschluesseln aller Partitionen geplant, aber ich habe nun erstmal beschlossen das bestehende zu erweitern. Dieses hatte noch ein paar Macken und daher bin ich der Meinung, dass es sich lohnt es nochmals zu ueberarbeiten und neue Erkenntnisse einfliessen zu lassen. Ein paar Rechtschreibfehler wurden nebenbei auch korrigiert.
Ausserdem war, je nach System, auf technischer Seite zu viel Handarbeit beim Backup notwendig. Ich habe mir Gedanken gemacht, wie man die Vorgaenge der Verschluesselung moeglichst einfach automatisieren koennte und zum Entschluss gekommen, dass udev-Regeln, ein Eintrag in der /etc/fstab und die Arbeit mit zusaetzlichen Keyfiles das Ganze weitgehend optimieren und automatisieren koennen.
Das Howto:
Das Backup wichtig ist und die vorhandenen Daten auf einem Computer prinzipiell immer den Wert einer zusaetzlichen Festplatte uebersteigen, sollte wohl den meisten klar sein. Wer mit seinem PC arbeitet und damit vielleicht sogar sein Geld verdient kann sicherlich bestaetigen von was ich rede. Auch bei privaten Daten bin ich der Meinung, dass sich eine Sicherung lohnt.
Allerdings ist eine externe Festplatte auch ein Sicherheitsrisiko: Prinzipiell koennte jeder die Festplatte an seinen PC anschliessen und haette Zugriff auf alle gespeicherten Daten. Dieses Problem laesst sich mit der Verschluesselug der betroffenen Daten loesen - wenn man bereit ist einen etwas geringeren Datendurchsatz in Kauf zu nehmen. Doch ganz ehrlich: Wer legt bei einer Sicherungsfestplatte schon einen hoeheren Wert auf ein paar MB/s mehr Datendurchsatz wenn die Daten dafuer nicht gegen unbefugten Zugriff geschuetzt sind?
Vorbereitung
Zuerst muss im Kernel dm_mod und dm_cypt sowie aktiviert sein. Dies ist bei den meisten Distributionen sowieso der Fall. Bei einem selbst gebauten Kernel benoetigt man folgende Optionen:
Device Drivers --->
Multi-device support (RAID and LVM) --->
[*] Multiple devices driver support (RAID and LVM)
<> RAID support
<M> Device mapper support
<M> Crypt target support
Cryptographic options ---> --- Cryptographic API <M> SHA256 digest algorithm <M> Blowfish cipher algorithm <M> AES cipher algorithms (i586)
Zusaetzlich benoetigt man noch cryptsetup-LUKS. Dieses wird wird bei den meisten Distributionen ueber das Paketmanagement installiert werden koennen. Im Fall von Arch Linux waere das mit pacman moeglich:
pacman -S cryptsetup
Bei anderen Distributionen heisst das Paket entweder auch cryptsetup oder cryptsetup-luks. Dieses laesst sich dann mit apt, yum, portage etc. problemlos nachinstallieren. Wichtig ist nur, dass die notwendigen Kernelmodule vorhanden sind.
Ist cryptsetup-luks installiert, sollte man die Daten auf der zu verwendeten Festplatte zerstoeren. Also nicht nur loeschen oder die Festplatte neu formatieren, denn da besteht immer noch die Moeglichkeit, dass sich die Daten teilweise wiederherstellen lassen. Einen guten Artikel zum Loeschen von Daten findet man bei pro-linux.
Wird eine neue, ungebrauchte Festplatte verwendet, kann dieser Schritt uebersprungen werden.
Fuer die meisten duerfte hier dd das Tool der wahl sein. /dev/sdc1 ist in diesem Fall das Device ueber das ich meine Backupplatte anspreche. Welches das ist, sollte man genau (!!) wissen, da es sonst zu boesen Ueberraschungen in Verbindung mit den folgenden Aufrufen kommen koennte. Wer also kein Lust hat aus Versehen die falsche Platte zu loeschen, sollte hier lieber mehrfach pruefen.
Mit dd kann man die Festplatte sowohl mit Zufallswerten wie im ersten Aufruf oder mit Nullen wie im zweiten Aufruf ueberschreiben. Letzteres ist schneller aber dafuer unsicherer.
dd if=/dev/urandom of=/dev/sdc1
dd if=/dev/zero of=/dev/sdc1
dev/sdc1 ist hierbei das Device der verwendeten Festplatte. Ich empfehle hierzu die Manpage von DD. Alternativ kann man auch mit dem Befehl shred arbeiten. Hier gibt "-n" die Anzahl der Vorgaenge an. In diesem Fall wird die Platte 10x ueberschrieben:
shred -fv -n 10 /dev/sdc1
Verschluesseln:
Ist die Festplatte sauber, kann man mit sie cryptsetup formatieren:
cryptsetup -c aes-cbc-essiv:sha256 -y -s 256 luksFormat /dev/sdc1
Hiermit wird eine AES-Verschluesselung, SHA256 Hashes, ESSIV in Verbindung mit einem 256-Bit Schluessel verwendet.
Die Option "-s" gibt die Laenge des Schluessels an und die Option "-y" fordert den User auf eine Passphrase zu waehlen. Alternativ kann man mit "-d" auch ein Keyfile statt der Passphrase verwenden.
Weitere Optionen findet man in der Manpage.
Nun legt man sein Crypto-Device an:
cryptsetup luksOpen /dev/sdc1 backup
An dieser Stelle wird man nach der Passphrase gefragt, die man beim Formatieren eingegeben hat. Verwendet man ein Keyfile, muss man dieses ebenfalls mit "--key-file" angeben.
Der Befehl legt ein neues Device unter /dev/mapper an. In unserem Fall /dev/mapper/backup. Dieses kann man nun wie ein normales Blockdevice formatieren, mounten und beschreiben. Die Ver- und Entschluesselung laeuft transparent im Hintergrund ab.
Formatieren:
mkfs.ext3 /dev/mapper/backup
Mounten:
mount -t ext3 /dev/mapper/backup /mnt/tmp
Alle Daten die man in /mnt/tmp speichert, landen nun verschluesselt auf der Platte.
Will man die Platte wieder abhaengen geht man folgernder massen vor:
Festplatte unmounten:
umount /mnt/tmp
Un danach Crypto-Device schliessen:
cryptsetup luksClose /dev/mapper/backup
Jeder der jetzt auf die Daten der Festplatte zugreifen will, braucht die Passphrase bzw. das Keyfile.
Automation
Um diese komplette Prozedur nicht jedes mal aufs neue ausfuehren zu muessen, kann man das ganze auch automatisieren. Waere ja Unsinn, wenn man die ganzen Sachen von Hand ausfuehren muesste, wenn man die Moeglichkeiten hat dies mit ein paar Kniffen weitgehend zu automatisieren.
Vorerst lege ich noch einen Eintrag in der /etc/fstab fuer das Backupsystem an:
/dev/mapper/backup /backup ext3 noatime,noauto,noexec 0 0
Dann lege ich ebenfalls mit dd ein 256Bit grosses Keyfile an. Da bei mir das root-Filesystem verschluesselt ist, kann ich den Schluessel, der fuer die Backup-Festplatte gebraucht wird, auf diesem ablegen. Ist dies nicht der Fall, sollte aus Sicherheitsgruenden eher weiter mit einer Passphrase gearbeitet werden. Eine Alternative waere es, das Keyfile zu erstellen und nun mit GPG zu ver/entschluesseln. Darauf moechte ich allerdings nicht weiter eingehen. Also wird das Keyfile nun erstmal erstellt:
dd if=/dev/urandom of=/etc/crypto/backuphdd.key bs=256 count=1
Nun muss cryptsetup-luks noch Bescheid wissen, dass sowohl die Passphrase als auch das Keyfile verwendet werden kann:
cryptsetup luksAddKey /dev/sdc1 /etc/crypto/backuphdd.key
War dies Erfolgreich schaut das ganze etwa so aus:
Enter any LUKS passphrase: key slot 0 unlocked. Command successful.
Jetzt kann mal testweise auf die Platte zugegriffen werden:
cryptsetup luksOpen /dev/sdb1 backup --key-file /etc/crypto/backuphdd.key
Und siehe da: "key slot 1 unlocked.". Es musste also keine Passphrase eingegeben werden. Somit ist schonmal der erste Schritt der Automation vollstaendig. Nun kann das Crypto-Device wieder ausgehaengt werden:
cryptsetup luksClose backup
Allerdings steht man nun vor einem Problem: Wechselnde Device-Nodes. Bei USB-Datentraegern unterscheiden sich, je nach Reihenfolge in der sie eingesteckt werden, die Devices ueber die man die Platte ansprechen kann. Zudem ist ja erwuenscht, dass beim Einstecken der Festplatte automatisch mit dem Keyfile das crypto-Device erstellt wird. Danach soll die Platte, ebenfalls automatisch, gemountet werden. Somit hat man nichts weiter zu tun als die Platte einzustecken und man kann sofort darauf zugreifen, obwohl sie komplett verschluesselt ist.
Alles was dazu gebraucht wird ist udev und eine Regel.
Also brauche ich, wie beim vorherigen Udev-Howto beschrieben, erstmal ein Identifikationsmerkmal mit dem ich die Festplatte von anderen unterscheiden kann:
udevinfo -a -p `udevinfo -q path -n /dev/sdc` | grep ATTRS{serial}
ATTRS{serial}=="1234567898253894C400000123456789"
ATTRS{serial}=="0000:00:1d.7"
Nun wird mit diesen Infos eine Udev-Regel erstellt. In meinem Fall lege ich dazu die Datei /etc/udev/rules.d/00.rules an.
ACTION=="add", BUS=="usb", ATTRS{serial}=="1234567898253894C400000123456789", KERNEL=="sd?1", NAME="%k", SYMLINK+="ext/backup", GROUP="storage", RUN+="/etc/crypto/scripts/backuphdd", ENV{ACTION}="add"
Mit diesen Regeln wird ein Symlink fuer die Festplatte auf /dev/ext/backup erstellt. Da man die Festplatte beim Einstecken im Normalfall einhaengen moechte, wird das Script /etc/crypto/scripts/backuphdd beim Einstecken gestartet. Dieses Script schaut folgendermassen aus:
# check action
if [ $ACTION = "add" ];
then
#pause
/bin/sleep 2
# create cryptodevice
/usr/sbin/cryptsetup -c aes-cbc-essiv:sha256 --key-file /etc/crypto/backuphdd.key -h sha256 luksOpen /dev/ext/backup backup
# and mount it
/bin/mount /backup
fi
exit 0
Dieses Script pausiert kurz, legt dann das mit Hilfe des Keyfiles das Cryptodevice an und haengt die Platte am richtigen Punkt ein. Somit wird die Festplatte nun sofort beim Anstecken automatisiert eingehaengt. An diesem Punkt ist es auch kein Problem weitere Aktionen ins Script einzubinden. So koennte zum Beispiel nach dem Mounten auch automatisch ein Backup loslaufen.
Backupsystem
Fuer die eigentlichen Backups kommt bei mir rsnaphot zum Einsatz. Dies ist ein Perl-Script welches auf rsync basiert und in der Lage ist sowohl Vollbackups als auch inkrementelle Sicherungen auf Festplatten oder entfernte Rechner durchzufuehren. Zudem laesst es sich vernuenftig konfigurieren.
rsnapshot is a filesystem snapshot utility for making backups of local and remote systems. Using rsync and hard links, it is possible to keep multiple, full backups instantly available. The disk space required is just a little more than the space of one full backup, plus incrementals.
Installieren kann man das Ganze unter Arch Linux mit "pacman -S rsnapshot".
Ein ausfuehrliches Howto findet man auf der offiziellen Seite. Ich moechte hier eher auf die Automation in Verbindung mit der verschluesselten Festplatte eingehen. Hier werden die Optionen in der /etc/rsnapshot.conf festgelegt:
# before rsnapshot syncs files
#
# cmd_preexec
# Specify the path to a script (and any optional arguments) to run right
# after rsnapshot syncs files
#
cmd_postexec /bin/umount /backup && /bin/sleep 1 && /bin/cryptsetup luksClose backup
Hier muessen zwischen cmd_[pre|post]exec und dem eigentlichen Befehl TABs und keine Leerzeichen stehen, da rsnapshot seinen Dienst verweigert wenn letztere eingesetzt wurden. Im beschriebenen Fall wurde die Festplatte schon automatisch eingehaengt. Also kann man das preexec-Kommando auslassen. Im postexec-Kommando muss das Cryptodevice zuerst ausgehaengt und dann wieder geschlossen werden, vorrausgesetzt man will die Festplatte nach dem erfolgreichen Backup einfach wieder abziehen.
Nun ein finaler Testlauf:
[root@wopr:~]# rsnapshot hourly Enter LUKS passphrase: key slot 0 unlocked. Command successful.
Nachdem das Backup also moeglichst automatisiert und sicher vonstatten geht, kann man nun seine wichtigen Daten regelmaessig sichern und ist in der Lage boesem Datenverlust vorzubeugen. Wer nun immer noch der Meinung ist, dass er kein Backup braucht, ist selbst schuld.
Weiterfuehrende Links:
- DM-Crypt im Gentoo-Wiki
- DM-Crypt im Ubuntuusers-Wiki
- Luks Website
- weiteres DM-Crypt Howto
- LUKS encrypted Root im Archwiki
- Erstellen der udev-Regeln
- rsnapshot howto
Wichtig:
Ich uebernehme keine Verantwortung fuer Datenverlust oder sonstige Verluste. Ihr solltet euch beim Durchfuehren dieses Howtos, insbesondere beim Loeschen und Formatieren absolut sicher sein was ihr tut. Vor allem solltet ihr genau pruefen, dass ihr das richtige Device verwendet und sich auf der Platte keine wichtigen Daten befinden!
Hilfestellung:
Ich habe das beschriebene Setup bei mir am Laufen und soweit funtioniert es auch. Einziges Manko: Wenn das Script ueber den Udev-Event aufgerufen wird, dauert es ca. 5min bis die Platte eingehaengt ist. Ruft man das Script von Hand auf, dauert es ein paar Sekunden. Vielleicht kann mir ja hier einer der Leser beim Debuggen helfen.
Ich bin gerade durch Zufall auf diesen Artikel bei heise security gestossen. Dazu gibt es auch dieses Howto.
Ich habe das Ganze mal getestet und muss sagen: Funktioniert prima ![]()
Fuer diejenigen, die daran interesse haben: Dieses Blog gibts nun auch SSL-gesichert ueber HTTPS. Wer den Feed z.B. nun per HTTPS abonnieren will, kann dies tun.
Die Standard-URL ist daher nun auch blog.roothausen.de, da es sonst Probleme mit dem Zertifat gibt.
Wichtige Sachen wie z.B. Logins etc. hab ich mit Redirects auf HTTPS umgebogen. Der Rest bleibt wie gehabt. Sowohl der Feed als auch der Rest der Seite ist erreichbar wie sonst auch.
Zum Testen: https://blog.roothausen.de
Dovecot ist ein kleiner und schneller IMAP/POP3-Server. Zusaetzlich wird Wert auf Sicherheit gelegt. Wikipedia meint dazu folgendes:
Das Hauptaugenmerk bei der Programmierung wird auf die Sicherheit gelegt. Der Server kann mit den Formaten maildir und mbox umgehen und ist dazu vollständig kompatibel zum Courier-Server und UW-IMAP. Dovecot unterstützt u. a. folgende Merkmale:
- IMAP4rev1
- THREAD- und SORT-Erweiterung
- TLS / SSL
- IPv6
Dank diesem Post und dem beschriebenen Script und dem Eintrag im dovecot-Wiki war die Migration relativ einfach.
Die Konfigurationsdateien sind zumindest bei Debian recht ausfuehrlich kommentiert und so funktioniert auch die Datenbankanbindung fuer die virtuellen User, die Integration des VMail-Verzeichnisses und die Anzeige der User-Quota im Client.
Alles in allem ist das Teil wirklich schneller als Courier und verbraucht dabei weniger Ressourcen. In Sachen Features fehlt mir nichts. Also eine klare Empfehlung ![]()


