TeamSpeak Server – the right? (at least encrypted) way

Nachdem eine Neuinstallation unseres TeamSpeak Servers ansteht, haben ich entschlossen einen TeamSpeak Testserver auf einen Root-vServer in einem Datencenter zu installieren. Der neue Server wird auf einer virtuellen Maschine mit Ubuntu 14.04 Server als Betriebssystem laufen. Die Entscheidung, auf Ubuntu 14.04 zu setzen hat mehrere Gründe, welche nicht unbedingt nur technischer Natur sind:

  • LTS-Version (Long-Term-Support Version von Ubuntu, welche eine langen Support-Zyklus aufweist.)
  • Ubuntu Landscape (Wird dzt. von mir nicht verwendet, kann aber vor allem für später nützlich sein, wenn einmal mehrere Maschinen administriert werden müssen.)
  • Eines der benutzerfreundlichsten Linux-Systeme

Am Ende dieses Tutorials soll ein TeamSpeak-Server-System mit folgenden Features bereit stehen:

  • TeamSpeak-Server befindet hinter einer Firewall und NAT-Router (Ähnlich wie in einem Setup wo der TeamSpeak Server zu Hause betrieben wird.)
  • DNS-Namensauflösung für den Server
  • Psychokiller’s TS3 Webinterface mit SSL-Zertifikat und NGINX-Webserver
  • Sprachverschlüsselung

Inhalt:

  1. Firewallkonfiguration (Aliases, Rules, NAT, interne DNS-Namen)
  2. DNS-Konfiguration (für einfache Namensauflösung aus dem Internet)
  3. SSL-Zertifikat besorgen
  4. Linux-System vorbereiten
  5. TeamSpeak-Server installieren
  6. NGINX-Webserver installieren & Webinterface einrichten
  7. Sprachverschlüsselung
  8. Ein paar Worte zu TSDNS & DNS-SRV-Records

Firewallkonfiguration

Auf der Firewall, hinter der sich der V-Server befindet, müssen einige Konfigurationsarbeiten durchgeführt werden. In unserem Fall wird als Firewallsystem pfsense verwendet. Auf diesem müssen vor dem eigentlichen Port-Forwarding einige Aliases angelegt werden. Auch wird ein lokaler DNS-Name angelegt für das Netzwerk hinter dem NAT.

DNS Name

lokaler DNS-Eintrag anlegen

alias

Alias für die Server-IP

Auch die vom Server benutzten Ports sollten als Alias angelegt werden. Eine Aufstellung der Ports, welche eingehend an den Server weitergeleitet werden findet man hier: TeamSpeak.de – Welche Ports benutzt Teamspeak 3?

port aliases

Alias für die benötigten Ports

Anschließend werden nun die Port-Forwarding Rules für den Server angelegt. Dank der Alias ist dies ein relativ einfacher Task.

port forwardings

Port-Forwardings für SSH-Management (dazu später mehr) sowie TeamSpeak 3

DNS-Konfiguration

Am DNS-Server, der die Domain für unseren TeamSpeak-Server auflöst muss ein A-Eintrag angelegt werden. Dieser Vorgang kann von Provider zu Provider unterschiedlich sein. In unserem Fall wird 1&1 als Domain-Registrar sowie DNS-Provider verwendet. Auf der Domain muss erst eine “Subdomain” und anschließend der “A-Eintrag” geändert werden.

Subdomain anlegen

Subdomain anlegen

arecord

A-Record anlegen

SSL-Zertifikat besorgen

Um den Webserver des Teamspeak-Servers abzusichern brauchen wir ein Zertifikat. Obwohl Let’s Encrypt bereit verfügbar ist, verwende ich immer noch Zertifikate von WoSign. Dort gibt es kostenlos für die Stammdomäne+5 Subdomains SSL-Zertifikate mit zwei Jahren Gültigkeit. Für unseren Anwendungsfall reicht dies mehr als aus. Auf die englische Bestellseite gelangt man mit folgendem Link: Request a Free SSL Certificate
Da es sich hier um kein kritisches Zertifikat handelt, lasse ich mir einen CSR Online generieren. Der private Schlüssel hat bei WoSign 2048 Bit. Braucht man mehr, bzw. will man beim SSLLabs-Test dann überall 100 Punkte erreichen, muss man einen eigenen CSR einreichen. Die Zertifikate sind Domain-Validated, d.h. es sollte eine gültige Postmaster-E-Mail-Adresse geben auf dieser Domain auf die man auch Zugriff hat.
Am Ende dieses Schrittes sollte man ein ZIP-File von WoSign erhalten haben, welches mehrere Dateien erhält, u.A. auch einen Ordner mit dem passenden Zertifikatsdateien für NGINX-Server.

Linux-System vorbereiten

Als Linux-System wird ein Ubuntu 14.04 LTS verwendet. Als Shell kommt zsh mit GRML-Konfig zum Einsatz sowie byobu als Terminal-Windowmanager. Weiteres werden unattended Upgrades für Security-Updates aktiviert. Weitere Schritte, welche ich Standardmäßig auf einem Linux-Server durchführe sind die Anlage eines Users für den SSH-Zugriff (weil root-Zugriff via SSH wird deaktiviert), Absichern des SSH-Zugriffs (SSH auf einem anderen Port laufen lassen) sowie die Installation ein paar gängiger Tools, welche ich praktisch finde. Weiteres wird ein komplettes Systemupdate vorab durchgeführt.

root@tstest1:~# apt-get update && apt-get dist-upgrade -y && apt-get install byobu zsh build-essential htop iotop -y

root@tstest1:~# useradd
Adding user `xigoadmin' ...
Adding new group `xigoadmin' (1000) ...
Adding new user `xigoadmin' (1000) with group `xigoadmin' ...
Creating home directory `/home/xigoadmin' ...
Copying files from `/etc/skel' ...
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Changing the user information for xigoadmin
Enter the new value, or press ENTER for the default
 Full Name []: XIGO Server Administrator
 Room Number []:
 Work Phone []:
 Home Phone []:
 Other []:
Is the information correct? [Y/n] Y

root@tstest1:~# wget -O .zshrc http://git.grml.org/f/grml-etc-core/etc/zsh/zshrc
root@tstest1:~# wget -O .zshrc.local http://git.grml.org/f/grml-etc-core/etc/skel/.zshrc
root@tstest1:~# byobu-enable

root@tstest1:~# su xigoadmin
xigoadmin@tstest1:/root$ cd
xigoadmin@tstest1:~$ wget -O .zshrc http://git.grml.org/f/grml-etc-core/etc/zsh/zshrc
xigoadmin@tstest1:~$ wget -O .zshrc.local http://git.grml.org/f/grml-etc-core/etc/skel/.zshrc
xigoadmin@tstest1:~$ byobu-enable
xigoadmin@tstest1:~$ exit

root@tstest1:~# nano /etc/passwd

In der Datei passwd muss die Standard-Shell noch auf zsh umgeschrieben werden.

root:x:0:0:root:/root:/bin/zsh
xigoadmin:x:1000:1000:XIGO Server Administrator,,,:/home/xigoadmin:/bin/zsh

Anschließend wird die Datei /etc/ssh/sshd_config bearbeitet, um den Root-Login auszuschalten und den SSH-Port zu ändern:

Port 9922
PermitRootLogin no

Das Einrichten von Unattended-Upgrades kann ich nur empfehlen. Somit werden Sicherheitsupdates automatisch installiert. Falls ein Neustart nötig ist, kann man diesen automatisch ausführen lassen, oder manuell durchführen.
Für die Installation und Einrichtung von Unattended-Upgrades folge ich folgender Anleitung: Konfiguration › Aktualisierungen › Wiki › ubuntuusers.de

Anschließend kann der Server zwischendurch einmal neu gestartet werden. Ich weiß – bei Linux ist dies nicht unbedingt notwendig. Beim nächsten Login via SSH haben wir dann eine schöne Konsole, wo man mit dem klassischen su dann root-Rechte erhalten kann. Dieser Server gibt nun unsere Grundlage um mit der Installation von TeamSpeak 3 fortzufahren.

ssh console

SSH-Konsole

TeamSpeak Server installieren

Für die weitere Vorgehensweise bei der Installation des TeamSpeak 3-Servers halte ich mich an folgendes HowTo von Ubuntuusers.de: TeamSpeak-Server › Wiki › ubuntuusers.de

Der Installationsvorgang von TeamSpeak 3 geht relativ gut von der Hand. Man sollte sich das Tutorial genau durchlesen und durcharbeiten, und nicht einfach nur die Befehle herauskopieren. Die ausführbare Datei von TS3 Server hat inzwischen z.B. einen anderen Dateinamen, aber dies findet man dann ohnehin schnell heraus. Auf unserem Server wurde TeamSpeak 3 als Service installiert, somit kann er nun einfach mit dem service-Befehl gestartet werden:

root@tstest1 /home/xigoadmin # service ts3server start
 * Starting TeamSpeak 3 Server
Starting the TeamSpeak 3 server
TeamSpeak 3 server started, for details please view the log file
 ...done.

Anschließend sollte man die Server Query Whitelist bearbeiten, sodass das Webinterface dann später unseren Server auch Abfragen darf. Hierzu passt man im TS3-Server Verzeichnis die Datei query_ip_whitelist.txt an. (bei mir im /usr/local/bin/teamspeak3-server_linux_amd64/ Verzeichnis)

root@tstest1 ..ocal/bin/teamspeak3-server_linux_amd64 # nano query_ip_whitelist.txt
127.0.0.1

Im Rahmen des Tutorials erhält man eine Consolen-Ausgabe mit den wichtigen Benutzerdaten, die beim ersten Serverstart angelegt werden. Dies sieht in etwa so aus:

------------------------------------------------------------------
 I M P O R T A N T
------------------------------------------------------------------
 Server Query Admin Account created
 loginname= "serveradmin", password= "xxxxxxxx"
------------------------------------------------------------------
------------------------------------------------------------------
 I M P O R T A N T
------------------------------------------------------------------
 ServerAdmin privilege key created, please use it to gain
 serveradmin rights for your virtualserver. please
 also check the doc/privilegekey_guide.txt for details.
token=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
------------------------------------------------------------------

Den Server Query Admin Account werden wir nicht verwenden, sondern uns einen eigenen Query-Account für den Einstig mittels Webinterface anlegen. Den ServerAdmin privilege key wird verwendet, um dem ersten User, der auf den TS verbindet Server Admin Rechte zu vergeben. Der TeamSpeak-Client fragt beim ersten Verbinden nach diesem Token. Wenn der Token eingegeben wurde, bekommt dieser User dann ServerAdmin als Recht zugewiesen. Nach dem Connect mit dem TS3-Client (auf tstest.meinedomain.de in meinem Fall) sollte es dann in etwa so aussehen:

ts3client

Auf diesem Screenshot sieht man, dass schon einige Servereinstellungen getätigt wurden. (Server Name, MOTD, etc…)

Nun hat dieser Benutzer mit diesem Client Admin-Rechte. Anschließend sollte man sich einen Query-Benutzer anlegen für das Webinterface. Dies kann unter “Extras –> ServerQuery Login” gemacht werden.

server_query_account

Installation von NGINX und des Webinterface

Die Installation von NGINX sowie PHP5-FPM geht unter Ubuntu schnell und einfach:

root@tstest1 ~ # apt-get install php5-fpm nginx

Anschließend kopieren wir unsere Zertifikatsdateien, welche wir von WoSign (das ZIP-archiv enthält einen NGINX-Ordner mit zwei Dateien, dem 1_xxxxx_bundle.crt sowie 2_xxxxx.key) erhalten haben auf den Server und legen sie in den richtigen Ordnern ab. Hierfür gibt es unter /etc/ssl zwei Verzeichnisse. Auf meinem Server sind die Dateien wie folgt abgelegt:

  • 1_xxxxx_bundle.crt liegt in /etc/ssl/certs/ts3server.crt
  • 2_xxxxx.key liegt in /etc/ssl/private/ts3server.key

Wenn die Zertifikatsdateien richtig liegen können wir uns um die Konfiguration des Servers kümmern. Hierfür legen wir unter /etc/nginx/sites-available eine neue Konfigurationsdatei (ts3webinterface) an. Die Datei /etc/nginx/sites-available/ts3webinterface wird dann bearbeitet:

# für den HTTP-Teil interessieren wir uns nicht. Hier wird einfach ein Redirect auf die HTTPS-Seite eingerichtet, wobei wir Port 8080 ohnehinnicht nach außen freigeben.
server {
 listen 8080;
 listen [::]:8080;
 server_name tstest.mydomain.de;
location / {
 return 301 https://tstest.my-industrie.eu:8443/index.php;
 }
}

# SSL
server {
 listen 8443 ssl;
 listen [::]:8443 ssl;
root /usr/share/nginx/html;
server_name tstest.mydomain.de;
# SSL stuff
 add_header Strict-Transport-Security "max-age=31536000; includeSubdomains";
ssl_certificate /etc/ssl/certs/ts3server.cer;
ssl_certificate_key /etc/ssl/private/ts3server.key;

ssl_session_cache shared:SSL:10m;
ssl_dhparam /etc/nginx/ssl/dhparam.pem;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
ssl_prefer_server_ciphers on;
ssl_ecdh_curve secp384r1;
# set max upload size
client_max_body_size 4G;
fastcgi_buffers 64 4K;
index index.php;
location / {
 try_files $uri $uri/ /index.php?$args;
 }
location ~ \.php(?:$|/) {
 fastcgi_split_path_info ^(.+\.php)(/.+)$;
 include snippets/fastcgi-php.conf;
fastcgi_pass unix:/var/run/php5-fpm.sock;
 }
# deny access to .htaccess files, if Apache's document root
# concurs with nginx's one
 location ~ /\.ht {
 deny all;
 }
}

In unserem Fall läuft nun ein Webserver auf Port 8080 sowie 8443. Den Port 8443 müssen wir in der Firewall noch auf den TS3-Server weiterleiten, sodass dies von extern auch erreichbar ist.

nat_webserver

Port-Weiterleitung an der Firewall auf den TS3-Server für’s Webinterface

Nun muss man noch eine Verknüpfung anlegen, die unsere ts3webinterface-Konfig in die “sites-enabled” des Webservers aufgenommen wird:

root@tstest1 /usr/share/nginx/html # cd /etc/nginx/sites-enabled
root@tstest1 /etc/nginx/sites-enabled # ln -s /etc/nginx/sites-available/ts3webinterface ts3webinterface

Anschließend können die Dateien des Webinterface heruntergeladen und entpackt werden. Die neueste Version findet man im TeamSpeak Addon Verzeichnis.

Diese sollten sich dann im Ordner /usr/share/nginx/html befinden. Laut Installationsanleitung des Psychokiller’s Webinterface sollen die Dateirechte auf 777 angepasst werden. Im Prinzip würde es reichen, wenn die Webinterface-Dateien von jedem im System (vor allem dem User unter dem unser NGINX-Webserver läuft) gelesen und geschrieben werden können.

root@tstest1 /usr/share/nginx/html # chmod 777 * -R

Nun muss die Konfigurationsdatei des Webinterface angepasst werden: (/usr/share/nginx/html/config.php)
Folgende Zeilen müssen angepasst werden – ansonsten sollte im Konfigurationsfile nichts geändert werden. Bei jedem Parameter ist eine Beschreibung dabei, für was er zuständig ist:

$server[0]['alias']= "Lokaler Server";
$server[0]['ip']= "127.0.0.1";
$server[0]['tport']= 10011
$cfglang = "de"; //Language German = de, English = en, Netherlandish=nl (by pd1evl), French = fr (by supra63200)
$duration = "300"; //Set the Limit for Clients show per Page on Client List
$fastswitch=true; //If true you can switch the Server on the header
$showicons="left"; //Define the position where the icons on the Viewer will show left or right
$style="new"; //Chose your design set 'new' for the default design or the name of your own create design
$msgsend_name="ADMIN-WEBMESSAGE"; //This Name will be show if you send a message to a Server
$show_motd=true; // Set it to false to not show the message of the day window
$show_version=true; // Set it to false to not show the Webinterface Version on the footer

Wenn die Konfig angepasst ist, alle Files an den richtigen Orten und auf die Dateiberechtigungen nicht vergessen wurde, kann der NGINX-Webserver neugestartet werden:

root@tstest1 /usr/share/nginx/html # service nginx restart
nginx stop/waiting
nginx start/running, process 32161

Sollte hier ein “failed” oder “error” kommen, kann man im Log unter /var/log/nginx/error nachsehen, was schief gelaufen ist beim Starten des Webservers.
Wenn alles geklappt hat, können wir uns mit den zuvor angelegten Benutzerdaten am Webinterface nun anmelden:

ts3webinterface

Sprachverschlüsselung

Wenn man sich das Log des TeamSpeak-Server-Starts genau ansieht, findet man darin folgende Zeile:

2016-02-28 14:50:09.200248|INFO |ServerLibPriv | |Using hardware aes

Die Verschlüsselung von Sprache kann dann im TS3-Client in den Servereinstellungen (man muss als ServerAdmin zum Server verbunden sein) aktiviert werden:

encryption

Über das verwendete Verfahren und dessen Implementierung sowie zum Protokoll an sich gibt es nicht viel Informationen. Außer dass AES zum Einsatz kommt, was grundsätzlich schon mal kein schlechter Ansatz ist aber dennoch keine genauen Rückschlüsse auf die tatsächliche Sicherheit des Systems zulässt.

Ein paar Worte zu TSDNS und DNS

Es gibt noch zwei “Spezialfälle”, die hier nicht behandelt wurden.

  • Fall Nr. 1: Ich habe mehrere Virtuelle TS-Server auf einer Kiste am Laufen (das geht mit einer lizenzierten Version von TeamSpeak) auf verschiedenen Ports, möchte aber ohne Angabe des Ports auf den richtigen Server verbinden können. Hierfür gibt es den TSDNS-Server von TeamSpeak. Dieser befindet sich im Programmverzeichnis unter /tsdns/tsdnsserver. Die Konfigurationsdatei dazu ist tsdns_settings.ini. Dort kann man verschiedene Hostnamen hinterlegen, die dann vom TS3-Client abgefragt werden können. Ich habe bislang kein gutes Tutorial zu TSDNS gefunden, und habe TSDNS bislang auch noch nicht benötigt.
  • Fall Nr. 2: Ich will auf meinen TeamSpeak-Server verbinden, ohne dass ich einen Subdomain-Name angebe. Als z.B. direkt im TS3-Client mit meinedomain.de auf den Server verbinde. TeamSpeak unterstützt SRV-Records im DNS. Somit kann der TS3-Client am PC den Server automatisch finden. Ein guter Artikel diesbezüglich findet sich hier: TeamSpeak KB: Unterstützt TeamSpeak 3 DNS SRV records?

Warum “mailman” suckt!

Eigentlich dachte ich mir, dass ich passend zu heutigem “Hexensabbat” – äh ich meinte natürlich Feiertag – eine schöne Schimpftriade lostreten will. Doch wie so oft in der IT-Security, gibt es mindestens schon jemand, der das selbe Problem hat, und sich auch schon einmal darüber aufgeregt hat. Diesmal geht es um die Mailinglisten-Software “GNU Mailman”. (weitere Infos –> “GNU Mailman” in der Wikipedia)

Als IT-Techniker ist man zwangsläufig in einer oder mehreren Mailinglisten eingetragen. Nur, als ich heute in meinen Posteingang geschaut habe, lag folgendes Mail im virtuellen “Briefkasten”:

Mailman "reminder"

Mailman “reminder”

Fällt was auf? BINGO! – mein Passwort wird da im Klartext durch die Gegend geschickt. Ob deren Mailserver beim Mailversand wenigstens TLS verwendet kann ich ja noch nachprüfen.

Ein blick in die Nachrichtenkopfzeilen: wenigstens wird TLS verwendet.

Ein Blick in die Nachrichtenkopfzeilen: wenigstens wird TLS verwendet.

Aber wie um alles in der Welt ist mein Passwort auf der Datenbank dort abgelegt?

THANK YOU VERY MUCH!

OK, denke ich mir, dann ändere ich schleunigst mal mein Passwort, sollte ja kein Problem sein, oder?
JACKPOT – man werfe einen Blick auf das Webinterface – nicht zu bedienen…

Interessanterweise, wie eingangs erwähnt, bin ich nicht der Erste den diese Dinge stört: Mailman considered harmful.

Wenn diese Software den Endanwender schon so “quält”, wie geht es dann dem Admin damit? Der muss wohl Suizidgefährdet sein…

Komfortable Sicherheit

IT Security ist in aller Munde. Heute bin ich gleich über zwei Probleme gestoßen, die mich dazu bewegt haben, diesen Beitrag zu schreiben. Doch dazu später mehr.

Security muss bequem sein. “Geht das?”, wird sich der eine oder andere vielleicht denken. Nein, es geht nicht, wie die folgende Grafik zeigt:

Sicherheit, Kostensparend, Komfortabel - wähle zwei!

Sicherheit, Kostensparend, Komfortabel – wähle zwei!

Wenn also das Konzept “Security” aufgehen sollte, muss man es den Anwendern so einfach wie möglich machen. Doch wie ich heute erleben musste, gelingt das nicht immer.

Beispiel 1: YubiKey NEO

Der YubiKey ist ein USB-Stick, der es ermöglicht für bestimmte Anwendungen eine zwei-Faktor-Authentifizierung durchzuführen. Dies ist kann beispielsweise für eine Verbindung per SSH auf einen Linux-Server verwendet werden. Auch populäre Passwort-Manager wie LastPass unterstützen den YubiKey. Der Key selbst generiert bei Tastendruck ein Einmalkennwort.

Doch um den YubiKey mit all seinen Facetten nutzen zu können, benötigt man ein Konfigurationstool vom Hersteller. Doch jenes Programm – guess what? – funktioniert natürlich nicht:

Absturz des Yubico-Programms

Absturz des Yubico-Programms

Ziemlicher Frust stellt sich ein. So wird das nie was mit der IT-Sicherheit für die breite Masse.

Beispiel 2: zwei-Faktor Authentifizierung beim Hosting-Provider

Man(n) parkt ja heutzutage mehrere Domains und hierfür nutzt Man(n) einen Hosting-Provider des Vertrauens. Um die Sicherheit zu erhöhen aktiviere ich zwei-Faktor-Authentifizierung mittels einer Authenticator-App. Hierfür nutze ich FreeOTP auf dem iPhone.

Doch was, wenn der Dienst beim Provider streikt? BINGO – man kann sich nur mehr mit den Notfall-Codes in seinen Account einloggen. Wieso? keine Ahnung. Keine Fehlermeldung, nichts…

Fassungslos stehe ich vor den Pforten...

Fassungslos stehe ich vor den Pforten…

Egal welchen Code ich in das Feld eintippte – mit keinem konnte ich mich einloggen. Inzwischen habe ich die Ursache herausfinden können – so simpel und einfach, dass das eigentlich nicht passieren sollte: Wenn man im rechten Eingabefeld den Code aus der App eintippt, dann muss man mit der Maus auf “Validate” klicken. Drückt man nach der Eingabe des Codes die ENTER-Taste auf der Tastatur, so wird die falsche “Validate”-Schnittstelle auf der Webseite ausgelöst.

Unverständlich.

Liebe Hersteller – so wird das nix mit der Security für Jedermann. Das muss schon etwas komfortabler ablaufen. Alleine wenn ich an Mail-Verschlüsselung mit PGP/GnuPG denke wird mir schlecht.

BitLocker als Alternative zu TrueCrypt

Nach dem mysteriösen Verschwinden von TrueCrypt Mitte 2014, kommt immer mehr die Frage nach einer adäquaten Alternative dazu auf. (Die Medien berichteten über diesen Vorfall ausführlich, u.A. hier)

Die Entwickler selbst verweisen auf BitLocker. Doch ist BitLocker eine brauchbare Alternative?
Die Antwort lautet: Ja, bedingt.

BitLocker funktioniert am besten wenn man einen TPM-Chip und ein EFI im Computer zur Verfügung stehen hat. Dann wird der sichere Schlüssel zum entsperren auf dem TPM-Chip abgelegt und das ganze mit SecureBoot garniert.
Als alternative Entsperr-Methode für die verschlüsselte Festplatte bekommt man noch einen Wiederherstellungsschlüssel den man ausdrucken sollte.

TPM-Chip auf einem Motherboard (steckbar)

TPM-Chip auf einem Motherboard (steckbar)

Der Schlüssel ist auf dem TPM durch krytografische Maßnahmen abgesichert. Wenn man am EFI eine Einstellung ändert, greift das SecureBoot ein und BitLocker verlangt nach dem Wiederherstellungsschlüssel. D.h. auch ein Angreifer hat keine Chance, den Systemstart zu modifizieren um an den Schlüssel zu kommen.

Mit EFI und TPM ist BitLocker sehr komfortabel und bietet auch sehr hohe Sicherheit. Auch ohne EFI und TPM kommt man zur Not an seine Daten mit dem zuvor ausgedruckten Wiederherstellungsschlüssel.

Um die optimale Lösung nutzen zu können, muss das Betriebssystem schon im EFI-Modus installiert sein. Man sieht dies in der Datenträgerverwaltung. Es muss bei einer normalen Windows-Installation mindestens eine EFI-Systempartition geben:

Datenträgerverwaltung

EFI-Partition in der Datenträgerverwaltung

Doch was ist nun mit virtuellen Maschinen?
PC’s ohne EFI die nur ein “normales” BIOS haben?
Betriebssysteme die absichtlich im BIOS-Mode installiert worden sind?

Für diese Fälle kann man BitLocker so konfigurieren wie TrueCrypt. Beim Systemstart wird einfach ein Password abgefragt.

Wenn man kein TPM hat, bietet Windows eigentlich diese Funktion nicht an, und quittiert mit folgender Fehlermeldung:

Bitlocker TPM Fehlermeldung

Bitlocker TPM Fehlermeldung

Doch es geht auch anders. Nach einer Einstellung in den Gruppenrichtlinien in der Domäne ODER den lokalen Computerrichtlinien am PC:

Start –> Ausführen –> “gpedit.msc” öffnet den Editor für die Richtlinien. Dann navigieren zu BitLocker und folgende Option setzen (siehe Screenshot):

BitLocker ohne kompatibles TPM zulassen

BitLocker ohne kompatibles TPM zulassen

Et voila. Nach der Einstellung kann BitLocker auch mit einem Kennwort aktiviert werden. Hierzu muss allerdings bei jedem Systemstart das Kennwort eingegeben werden. Es empfiehlt sich dennoch zusätzlich die Wiederherstellungsschlüssel auszudrucken.

BitLocker mit Kennwort

BitLocker mit Kennwort

Anschließend kann der Assistent ganz normal durchgearbeitet werden.