Jitsi Videokonferenzen funktionieren bei geeigneten Einstellungen mit über 100 Teilnehmern. Voraussetzung dafür ist, dass der erste Teilnehmer (der Veranstalter) dafür sorgt, dass der erste Teilnehmer (Moderator des Raumes) in den Settings “Everyone start muted”, “Everyone start hidden” und “Everyone follows me” anwählt. Dieses Szenario ist mit über 90 Teilnehmern erfolgreich getestet worden. Dann senden die Zuschauer nicht, können ihre Kamera und Mikrofon aber selber einschalten. Wenn das der Reihe nach getan wird, kann sehr einfach ermittelt werden, wie viele gleichzeitige Teilnehmer funktionieren, da der Teilnehmer mit der geringsten Bandbreite das Nadelöhr darstellt. Für reine Vorlesungsszenarien reicht das aber häufig schon aus.

Jitsi bietet aber auch die Möglichkeit externe Streaming Dienste anzubinden wie z.B, youtube oder einen eigenen nginx-Streamingserver. Wie das technisch realisiert werden kann, wird hier kurz beschrieben. Mir fehlt leider die Zeit das detailliert zu tun, da ich nicht mehr lange für die Uni Duisburg-Essen (UDE) arbeiten werde.

Die Komponente in Jitsi, die Aufzeichnungen und Stream ermöglicht heißt Jibri. https://github.com/jitsi/jibri

Bitte beachten, wenn mehrere Streams oder Aufzeichnung zur gleichen Zeit erfolgen sollen, benötigt man eine ganze Farm von Jibri-Maschinen, die mit einem unterschiedlichen „Nickname“ (siehe unten) konfiguriert werden müssen. Best Practice: Einen jibri konfigurieren und dann klonen. („Nickname“ anpassen nicht vergessen). Das schreit eigentlich nach dynamischen Instanzen, die per Docker oder ähnlich on the fly erzeugt werden können (hier nicht realisiert, nur als Idee angerissen).

Die Installation von Jibri funktioniert, anders als in der Anleitung angegeben, auch unter Ubuntu 18.4LTS (und sehr wahrscheinlich auch 20.4LTS). Wichtig ist aber, dass unbedingt Java8 konfiguriert wird:

$ sudo update-alternatives –config java

Achtung: Anders als in der Anleitung heißen die Jitsi-internen Virtual Hosts für die beiden Control-Kanäle (hier im Beispiel heißt der Jitsi-Server jitsi.zim.uni-due.de, dass muss individuell angepasst werden):

VirtualHost “auth.jitsi.zim.uni-due.de” (in /etc/prosody/conf.avail )

und

Component “internal.auth.jitsi.zim.uni-due.de” “muc”

Diese Namen müssen sich in der jibji config.json wiederspiegeln.

Unbedingt sind dann auch die Passwörter für die richtigen “virtuellen” Domänen (mit Domain meint Jitsi ein eigenes virtuelles Subdomain-Konzept, dass gar nichts mit echten Subdomains zu tun hat) zu setzen:

$ prosodyctl register jibri auth.jitsi.zim.uni-due.de *********

$ prosodyctl register recorder recorder.jitsi.zim.uni-due.de ********

(Mit den vergebenen Passwörtern im Config-File.)

Damit alle Komponenten zusammenspielen, muss auch die Jicofo-Konfiguration angepasst werden:

Man editiere dazu  /etc/jitsi/jicofo/sip-communicator.properties, um für die MUC (Multi User Conference, Jitsi basiert ja auf Jabber) die Jitsi-Stream-Brauerei (ein Bier für den Admin ;-) , also die Jibri-Worker bekannt zu  machen. Das muss mit dem Eintrag in der jibri’s config.json korrespondieren. Jicofo muss nach der Änderung neu gestartet werden.

org.jitsi.jicofo.jibri.BREWERY=JibriBrewery@internal.auth.yourdomain.com

muss bei unserem Beispiel

org.jitsi.jicofo.jibri.BREWERY=JibriBrewery@internal.auth.jitsi.zim.uni-due.de

sein!

Dann müssen noch in /usr/share/jitsi-meet/interface_config.js
die  TOOLBAR_BUTTONS für ‘livestreaming’ aktiviert werden.

Damit kann man dann z.B. schon zu youtube streamen, wenn man dort einen Streaming Account hat. Ich denke auch Wowza würde  mit dem /etc/hosts Hack gehen, ich hatte aber keine Zeit mehr das an der UDE auszuprobieren.

Damit die Jibri-Instanzen (Farm) nicht zu youtube sondern auf einen eigenen Server streamen, einfach in /etc/hosts für youtube.com die IP des Streamingservers einsetzen. D.h. die Rechner der Jibri-Farm halten den eigenen Streamingserver für youtube. Das hat den Vorteil, dass nichts im Jitsi-Quellcode geändert werden muss.

Im Beispiel an der UDE heißt der Streamingserver livestream.zim.uni-due.de .

Die  JIBRI Farm

Jeweils in /etc/jitsi/jibri/config.json die Nicknamen ändern.

“nickname”: “jibri-nickname2″

siehe: https://github.com/jitsi/jibri/issues/187 (ganz unten)

dann

$ sudo systemctl restart jibri

In den Logfiles sieht man dann, ob sich die Jibri-Instanzen ordentlich am jicofo anmelden.

Ein eigener Open-Source Streaming-Server

Der Streaming-Server, hier ganz in Open Source ist ein nginx mit selbst kompilierten Modul realisiert worden:

Prinzipiell bin ich nach dieser Anleitung vorgegangen

https://obsproject.com/forum/resources/how-to-set-up-your-own-private-rtmp-server-using-nginx.50/

Zum Bauen des nginx:

$ sudo apt-get install build-essential libpcre3 libpcre3-dev libssl-dev

$ wget http://nginx.org/download/nginx-1.15.1.tar.gz

Das RTMP-Modul:

$ wget https://github.com/sergey-dryabzhinsky/nginx-rtmp-module/archive/dev.zip

$ tar -zxvf nginx-1.15.1.tar.gz

$ unzip dev.zip

$ cd nginx-1.15.1

Build  nginx:

$ ./configure –with-http_ssl_module –add-module=../nginx-rtmp-module-dev

$ make

$ sudo make install

Als Ergänzung habe ich auch ein LDAP-Modul in den nginx einkompiliert:

hiermit:

https://github.com/kvspb/nginx-auth-ldap/blob/master/example.conf

mit

$ ./configure –with-http_ssl_module –add-module=../nginx-rtmp-module-dev  –add-module=../nginx_ldap_module/nginx-auth-ldap-master

$ make

$ sudo make install

Restart nginx:

$ sudo /usr/local/nginx/sbin/nginx -s stop

$ sudo /usr/local/nginx/sbin/nginx

Der nginx ist selbstkompiliert und lebt nach install unter /usr/local/nginx.

Gestartet wird er bei einem Reboot über einen cronjob:

@reboot root /usr/local/nginx/sbin/nginx

@reboot root /home/zim026/worker.sh 2>/dev/null (für die Playlist, siehe unten)

So wie er nun ist, kann man den Streaming-Server mit OBS-Studio oder Videolan per RTMP füttern und sich den Stream in einem vlc medial player anschauen.

Per OBS-Studio geht das so:

Ein Profil erzeugen mit:

Streaming Service: Custom
Server: rtmp://<your server ip>/live
Play Path/Stream Key: test

Und dann mit VLC (Videolan):

rtmp://<your server ip>/live/test

Das war der einfache Teil ;-).

Ich will aber mehr und den Stream im Browser per Javascript als HLS anschauen. Dazu habe ich folgendes getan:

Der Job /home/zim026/worker.sh (landet in der Crotab) erzeugt eine dynamische Übersichtsseite:

#!/bin/bash

#erst mal dauernd
while :
do
cd /tmp/hls
#alias proj=”cd /tmp/hls”

#jhome () {
#  cd /tmp/hls

#touch test.m3u8
#touch test2.m3u8
echo > /usr/local/nginx/html/playlist_cont.html
j=0
x=X
for i in *.m3u8 ; do
if [ "${i:0:1}" != "X" ]
then
echo “<a href=’https://livestream.zim.uni-due.de/stream5.html?s=$i’>Stream: [$i] <base target=”_parent”></a><br><br>” >> /usr/local/nginx/html/playlist_cont.html
fi
j=$(( $j + 1 ))
done

OUTPUT=`cat /usr/local/nginx/html/playlist_cont.html`
if echo “$OUTPUT” | grep -q “*”; then
echo “<p>Kein öffentlicher Livestream verfübar.</p>” >/usr/local/nginx/html/playlist_cont.html
j=$(( $j – 1 ))
fi

echo  “<p>”  >>/usr/local/nginx/html/playlist_cont.html
echo $j >> /usr/local/nginx/html/playlist_cont.html
echo ‘ aktive Streams.’  >> /usr/local/nginx/html/playlist_cont.html

#cat /usr/local/nginx/html/playlist_head.html /usr/local/nginx/html/playlist.txt /usr/local/nginx/html/playlist_footer.html > /usr/local/nginx/html/playlist.html

#} # fuer das cd

sleep 5
done

Optional können auch verborgene Streams erzeugt werden, denen im Namen ein “X” vorangestellt wird. Diese tauchen dann nicht auf der Playlist auf, sind aber, wie unten in der Anleitung beschreienen, aufrufbar.

Das passende stream5.html HTML dazu, dass die hls-Videos mit Hilfe des  videojs-contrib-hls.js javascript-Library abspielt:
Siehe auch (es klappt bei mir mit Version 7):
https://videojs.com/getting-started/

Da es Umbruchprobleme im Blog gibt, hier die Datei stream5.html auch zum Herunterladen.

<!DOCTYPE html>
<html>
<head>
<meta charset=utf-8 />
<title>ZIM Livestream</title>

<!–

Uses the latest versions of video.js and videojs-contrib-hls.

To use specific versions, please change the URLs to the form:

<link href=”video-js.css” rel=”stylesheet”>
<script src=”video.js”></script>
<script src=”videojs-contrib-hls.js”></script>

–>

<link href=”videojs7/video-js.css” rel=”stylesheet”>
<script src=”videojs7/video.min.js”></script>

</head>
<body>
<!– onload=”myFunction()”> –>
<img src=”UDE-logo-claim.svg” height=”100″><img src=”zim.jpg” height=”100″>
<h1>Livestream – Play Button klicken fC<r Start</h1>

<video id=”myvideo1″ controls preload=”auto”
width=”640″
height=”360″
data-setup=’{}’>

<!–   <source src=”https://livestream.zim.uni-due.de/hls/novideo.m3u8″ type=”applicat
–>

</video>
<br>
<a href=”playlist.html”>zurC<ck zur Live-Stream Auswahl</a>

<script>
window.onload = myFunction();

function myFunction(){

function getUrlParam(parameter, defaultvalue){
var urlparameter = defaultvalue;
if(window.location.href.indexOf(parameter) > -1){
urlparameter = getUrlVars()[parameter];
}
return urlparameter;
}

function getUrlVars() {
var vars = {};
var parts = window.location.href.replace(/[?&]+([^=&]+)=([^&]*)/gi, function(m,key,
vars[key] = value;
});
return vars;
}

var mystream = getUrlParam(‘s’,'Empty’);
var video = document.getElementById(‘myvideo1′);
/*alert(video);*/
var source = document.createElement(‘source’);
var streambase = ‘https://livestream.zim.uni-due.de/hls/’;
var streamurl = streambase.concat(mystream);
source.setAttribute(‘src’, streamurl);
source.setAttribute(‘type’, “application/x-mpegURL”);
video.appendChild(source);
/*let insertedNode = myvideo.insertBefore(insertedNode, source);*/
/*
video.play();
*/
}
</script>

</body>
</html>

Der Datei wird der Stream-URL durch die Playlist per Parameter übergeben und es wird ein bisschen mit Javascript gezaubert. Die Geschichte mit dem Parameter und der Playlist stammt von mir. Das kann man sicher mit einem beliebigen Framework viel eleganter machen, ist wollte allerdings eine rasche Lösung, da ich erwartet hatte, dass so etwas in Corona-Zeiten an der UDE benötigt wird.
Dieses ist meine fertige nginx.conf. Wer auf LDAP verzichten will, lässt die entsprechenden Konfigurationseintrage füe LDAP und das Modul einfach weg. Das Streaming geht auch ganz ohne LDAP. Das war nur ein Feature für die Uni Duisburg-Essen, um auch hochschulöffentliche Streams zu realisieren, die erst nach Anmeldung angeschaut werden können:

Da es Umbruchprobleme im Blog gibt, hier die Datei nginx.cfg auch zum Herunterladen.

#user  nobody;
worker_processes  10;

#error_log  logs/error.log;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;

#pid        logs/nginx.pid;

events {
worker_connections  2048;
}

http {
include       mime.types;
default_type  application/octet-stream;

#log_format  main  ‘$remote_addr – $remote_user [$time_local] “$request” ‘
#                  ‘$status $body_bytes_sent “$http_referer” ‘
#                  ‘”$http_user_agent” “$http_x_forwarded_for”‘;

#access_log  logs/access.log  main;

sendfile        on;
#tcp_nopush     on;

#keepalive_timeout  0;
keepalive_timeout  65;

#gzip  on;
#LDAP
ldap_server test1 {
url ldaps://ldap2.uni-duisburg-essen.de/ou=people,dc=uni-duisburg-essen,dc=de?uid?sub?(objectClass=inetOrgPerson);
binddn “cn=*******,ou=admin,dc=uni-duisburg-essen,dc=de”;
binddn_passwd “********”;
#group_attribute uniquemember;
group_attribute_is_dn on;
require valid_user;
}
#bis hier LDAP

server {
#listen 80;
listen 443 ssl;
#ssl on;
##  livestream.zim.uni-due.de-key.pem  livestream_cert.pem root@stream:/usr/local/nginx/certs
ssl_certificate /usr/local/nginx/certs/livestream_cert.pem;
ssl_certificate_key /usr/local/nginx/certs/livestream.zim.uni-due.de-key.pem;
server_name livestream.zim.uni-due.de;
#  server_name  localhost;
#LDAP
# auth_ldap “Anmeldung mit UDE-Unikennung/Passwort”;
# auth_ldap_servers test1;
#LDAP bis hier
#charset koi8-r;

#access_log  logs/host.access.log  main;

location / {
root   html;
index  index.html index.htm;
}

#error_page  404              /404.html;

# redirect server error pages to the static page /50x.html
#
error_page   500 502 503 504  /50x.html;
location = /50x.html {
root   html;
}

# proxy the PHP scripts to Apache listening on 127.0.0.1:80
#
#location ~ \.php$ {
#    proxy_pass   http://127.0.0.1;
#}

# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
#
#location ~ \.php$ {
#    root           html;
#    fastcgi_pass   127.0.0.1:9000;
#    fastcgi_index  index.php;
#    fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
#    include        fastcgi_params;
#}

# deny access to .htaccess files, if Apache’s document root
# concurs with nginx’s one
#
#location ~ /\.ht {
#    deny  all;
#}
# Andreas
location /hls/ {
root /tmp;
add_header Cache-Control no-cache;
}
# Andreas
location ~  /hls/U {
root /tmp;
add_header Cache-Control no-cache;
auth_ldap “Anmeldung mit UDE-Unikennung/Passwort”;
auth_ldap_servers test1;

}

}

# another virtual host using mix of IP-, name-, and port-based configuration
#
#server {
#    listen       8000;
#    listen       somename:8080;
#    server_name  somename  alias  another.alias;

#    location / {
#        root   html;
#        index  index.html index.htm;
#    }
#}

# HTTPS server
#
#server {
#    listen       443 ssl;
#    server_name  localhost;

#    ssl_certificate      cert.pem;
#    ssl_certificate_key  cert.key;

#    ssl_session_cache    shared:SSL:1m;
#    ssl_session_timeout  5m;

#    ssl_ciphers  HIGH:!aNULL:!MD5;
#    ssl_prefer_server_ciphers  on;

#    location / {
#        root   html;
#        index  index.html index.htm;
#    }
#}

}

rtmp {
server {
listen 1935;
chunk_size 4096;

application live2 {
live on;
record off;
#Andreas
meta copy;
wait_key on;
wait_video on;
idle_streams off;
hls on;
hls_path /tmp/hls;

}
}
}

Aus der Nutzeranleitung, die ich für die UDE erstellt habe:

Livestreams bzw. Webcasts
Wählen Sie zur Nutzung von Livestreams bzw. Webcasts auf dem Server
jitsi.zim.uni-due.de  (nicht auf jitsi.uni-due.de) die Funktion “start live stream” im Menue rechts unten (drei Punkte übereinander). Vergeben Sie dann im Dialog einen aussagekräftigen Namen für den Stream (ohne Leerzeichen). Der Stream wird nicht zu youtube gesendet, wie es im GUI angezeigt wird, sondern zum Server https://livestream.zim.uni-due.de . Wenn Sie ein großes “X” dem Stream-Namen voranstellen, wird dieser nicht in der Streamübersicht angezeigt. Ihre Studierenden können den Stream dann unter der URL

https://livestream.zim.uni-due.de/stream5.html?s=X<ihrstreamname>.m3u8

betrachten. Sie müssen Ihren Studierenden den URL dann per Mail oder in Moodle mitteilen. Bitte keine Leer- oder Sonderzeichen im Stream-Namen verwenden.
Wenn Sie dem Stream-Namen mit einem großen “U” beginnen, z.B. “Utest”, können nur NutzerInnnen der UDE erst nach Eingabe der Unikennung und dem Passwort den Stream ansehen.
Stoppen können Sie den Livetream ebenfalls über das Menue.
Der Livestream kann dann über die Seite livestream.zim.uni-due.de von vielen hundert Teilnehmern angeschaut werden,

Den Streamingserver livestream.zim.uni-due.de können Sie beispielsweise aber auch mit Hilfe von OBS-Studio produzierten Livestreams aus dem Uninetz auf den Port 1935 beschicken. Die beiden Optionen mit dem vorangestellten “X” bzw. “U” gelten dann ebenfalls.

Ich hoffe diese Zusammenstellung hilft dem einen oder anderen Admin weiter. Insbesondere für große Veranstaltungen kann das sehr hilfreich sein.


Als kurz vor dem Lockdown der DFN-Verein (Deutsches Forschungsnetz) ankündigte, dass der DFN-Conf Videokonferenzservice für alle Eventualitäten gerüstet sei und keine Kapazitätsprobleme zu erwarten sind, war Fachleuten im ZIM sofort klar, dass die Kapazitäten niemals ausreichen werden. Der DFN-Verein hat in Vor-Corona-Zeiten Kapazitäten von gerade einmal 2000 gleichzeitigen Videokonferenzteilnehmern bereitgehalten. Bei über 400 angeschlossenen Hochschulen kann so eine geringe Kapazität nicht ausreichen, wenn der Dienst plötzlich stark nachgefragt wird.

Leider hat aber das zentrale Videokonferenzangebot des DFN dafür gesorgt, dass lokal an vielen Hochschulen keine eigenen Lösungen mehr vorgehalten worden sind. An der UDE war das anders. Unterstützt von den Kolleginnen und Kollegen im Bereich Lerntechnologien habe ich mir vor einigen Jahren diverse freie Videokonferenzsoftwarelösungen (z.B. OpenMeetings, Palava, Jitsi-Desktop) angeschaut. Openmeetings, ein freier Adobe Connect Clone, war einige Zeit im Testbetrieb an der UDE und damals noch Flash-basiert. OpenMeetings , Jitsi und BigBlueButton (BBB) nutzen WebRTC als Basistechnologie. BBB hat ähnlich wie OpenMeeting früher Flash als Video- und Audio-Übertragungstechnik eingesetzt.

Es war zu Beginn des Lockdowns nicht klar, wie die Hochschullehre im folgendem Semester organisiert werden kann. Sollte der Weg gewählt werden alle Vorlesungen einfach per Videokonferenz anzubieten oder nur in eine Richtung ohne Rückkanal für die Studierenden ein Stream anzubieten oder besser auf ein Learning Content Management System wie Moodle gesetzt werden, um die Lehre asynchron zu realisieren? Im (aus IT-Sicht) Worst-Case-Szenario würde man alle Veranstaltungen einfach per Videokonferenz anbieten. Allerdings kommen Videokonferenzlösungen dann sehr schnell an Ihre Grenzen. Wenn Sie beispielweise eine Videokonferenz mit 100 Teilnehmern veranstalten möchten, muss jeder Teilnehmer 99 Videobilder gleichzeitig empfangen können, was private Internetzugänge von der benötigten Bandbreite nicht hergeben. Deshalb reduzieren alle Videokonferenz-Werkzeuge die Anzahl der maximal gleichzeitig übertragenen Streams.  Teilnehmerzahlen von über 1000 sind so gar nicht zu realisieren. Bei einem normalen synchronen Vorlesungsbetrieb an einer Universität mit über 40.000 Studierenden ist das technisch mit Inhouse-Lösungen zu Spitzenlastzeiten möglicherweise auch nicht zu stemmen. Da sich aber die Hochschule für einen asynchronen Lehrbetrieb mit Moodle entschieden hat, verteilt sich die benötigte Bandbreite über den ganzen Tag und Lastspitzen werden vermieden.

Wir im ZIM haben uns dazu entschieden, mehrgleisig auf die neuen Bedarfe zu reagieren. Einerseits haben wir sehr rasch einen Jitsi-Server für WebRTC-Videokonferenzen aufgesetzt und später Lizenzen für ZOOM-basierte Videokonferenzen in der Cloud beschafft. In der Fakultät Biologie hat Ken Dreger zeitgleich damit begonnen den WebRTC-Dienst BigBlueButton zu evaluieren. Dieser Dienst wurde später gemeinsam mit der Fakultät Biologie, der Wirtschaftsinformatik und dem ZIM auch hochschulweit in den Betrieb genommen. Ein spezieller BBB-Server für die Gremienarbeit, der für alle Teilnehmer eine Anmeldung mit der Unikennung erzwingt, wurde ebenfalls realisiert.

Bei der eingekauften proprietären Lösung ZOOM liegen die live Audio- und Video-Streams Prinzip bedingt beim Anbieter auf dem Vermittlungsserver unverschlüsselt vor. Um auch Konferenzen zu ermöglichen, in denen personenbezogene Daten oder anderweitig schützenswerte Inhalte ausgetauscht werden, wurde im ZIM auch ein sogenannter „on-premise“ ZOOM-Server installiert, bei dem alle Audio-und Videodaten unverschlüsselt nur auf einem Server in der Hochschule vorliegen. Um die Sammlung von Metadaten durch den Anbieter zu verhindern, ist nun auch eine völlig anonyme Anmeldung der Initiatoren einer Zoom-Videokonferenz im ZIM realisiert worden. Wenn allerdings auch nur ein Teilnehmer per Telefon oder WebRTC an einer Konferenz auf dem ZOOM-on-premise-Server teilnimmt, werden im ersten Fall Audio und im zweiten Fall auch das Video der Konferenz über ZOOM-Server in die Cloud geleitet. Die Daten, die Sie darüber hinaus in Ihrem ZOOM-Profil pflegen und auch die Aufzeichnungen dort, verantworten Sie aber als Lehrende selber.

WebRTC (Web Real Time Conferencing)

WebRTC, also Echtzeitkonferenzen im Browser sind heute in allen aktuellen Browsern nutzbar, selbst der Microsoft Browser Edge und Apples Safari beherrschen das mittlerweile gut. Dazu ist in den Webbrowsern Programmcode integriert, der auf die Webcam und das Audio-Interface (Mikrofon/Lautsprecher) zugreift, Ton und Video komprimiert (kodiert) und empfangene Daten dekomprimiert (dekodiert).  Diese Softwarekomponente wird CODEC (von coding und decoding) genannt. Wegen der im WebRTC-Standard notwendigen Interoperabilität der verschiedenen Browser muss die das W3C-Standartisierungsgremium (World Wide Web Consortium) auf CODECs einigen, die von allen Browser-Herstellern unterstützt werden (VP8, H264 für Video und Opus, G711 PCMA und PCMU für Audio). Da die beiden führenden Browser mit einer Open Source-Lizenz entwickelt werden, müssen auch die verwendeten CODECs Open Source sein. Und hier zeigt sich der wesentliche Unterschied zu proprietärer Videokonferenz Software wie z.B. Zoom. Diese muss nicht mit anderer standardisierter Software zusammenarbeiten, ist nur für diesen einzigen Zweck geschrieben worden und kann auch hochwertige kommerzielle Closed Source CODECS einsetzen, die eine höhere Kompression ermöglichen. Insofern ist der Vergleich der Audio- und Video-Qualität von WebRTC basierten Lösungen mit proprietären, nicht interoperablen Lösungen müßig. WebRCT-basierte Videokonferenzen mit BBB und Jitsi werden an der UDE über Uni-eigene Server abgewickelt. Weder Metadaten (wer kommuniziert mit wem) noch Inhalte können auch dem über sichere HTTPS abgesicherten Transportweg abgehört werden. Eine echte Ende-zu-Ende Verschlüsselung kann Prinzip bedingt auf einfache Weise nun zwischen zwei Kommunikationspartnern realisiert werden. Jitsi bietet beispielsweise so eine Möglichkeit. Wenn Sie zu zweit eine Jitsi-Konferenz durchführen, werden weder Ton noch Bild über den Jitsi-Server der UDE geleitet. Sie kommunizieren dann direkt Ende-zu Ende verschlüsselt und kein Geheimdienst dieser Welt kann sie abhören, sofern sie Ihrem PC und dem installierten Betriebssystem vertrauen können.  Eine Ende-zu-Ende Verschlüsselung mit mehr als zwei Teilnehmern ist viel schwieriger zu realisieren, da dann beim Verbindungsaufbau ein geheimer Session-Schlüssel mit allen Teilnehmern ausgetauscht werden müssen, den der zentrale Server nicht mitbekommen darf.

Ein weiterer Vorteil der WebRTC-Dienste ist die einfache Integration in vorhandene Webdienste wie z.B. Moodle und Rocket-Chat.

In Webbrowsern sind Sicherheitsmechanismen eingebaut, die verhindern sollen, dass eine Browser-Nutzerin oder ein Nutzer heimlich beim Besuch einer Webseite abgehört wird. Deshalb fragen die Browser immer nach, ob der Zugriff auf Kamera, Mikrofon und gegebenenfalls den Desktop, falls etwas präsentiert werden soll, durch den Nutzer erlaubt wird. Die Freigabe wird für jeden Server einzeln gespeichert und kann auch widerrufen werden. Im Falle von BBB sind das aber 10 verschiedene Server auf die, je nach aktueller Last, verwiesen wird. Leider ist das für ungeübte Nutzer eine zusätzliche Fehlerquelle bei webbasierten Videokonferenzen. Übrigens unterstützt auch ZOOM den Zugang über WebRTC zu Videokonferenzen ohne Installation des ZOOM-Clients. Allerdings ist diese Funktion (möglicherweise beabsichtigt) etwas versteckt und funktioniert nicht so zuverlässig wie von Jitsi und BBB gewohnt.

WebRTC-Probleme mit Mikrofon, Kamera oder Netzwerkanbindung können Sie auf dieser Testseite ganz hervorragend eingrenzen: https://test.webrtc.org/

Beschränkte Internetzugänge

Alle hier beschriebe Dienste funktionieren nun auch über extrem limitierte Internetzugänge, wie z.B. dem Verwaltungsfirewall der UDE oder in NAT-Netzen mit privaten Internet-Adressen. Auch die von Providern gerne verkauften limitierten DSLite-Internetzugänge stellen kein Problem mehr dar. Sofern auch nur der Port 443 für HTTPS offen ist, lassen sich Jitsi und BBB nutzen. Ermöglicht wird das durch im ZIM betriebene STUN und TURN-Server, die bei solchen limitierten Zugängen für eine „Vermittlung“ zwischen Client und Server sorgen. Auf wenn diese „Vermittlung“ wegen einem beschränten Internetzugang beim Verbindungsaufbau benötigt wird, bleibt die oben erwähnte Ende-zu-Ende-Verschlüsselung bei Jitsi mit zwei Teilnehmern intakt.

Echtzeit Videokonferenz versus Live-Stream versus Stream einer Konserve

Häufig wird die Qualität einer Videokonferenz an Streaming-Angeboten für vorher aufgezeichnete und komprimierte  Videokonserven wie Netflix oder Youtube gemessen. Da bei einer Videokonferenz die Latenz höchsten 150 Millisekunden betragen darf, ist der technische Aufwand aber bei einer Konferenz ungleich höher als bei einem Live- oder Konserven-Stream.  Bei höheren Verzögerungen fallen sich die Teilnehmerinnen unabsichtlich ins Wort, weil sie von einer Sprechpause des Gegenübers ausgehen. Bei einem (Live) Stream ist es völlig egal, ob er erst nach 10 Sekunden beginnt und der CODEC die Zeit für eine verbesserte Kompression und für ein Puffern (Buffering) nutzen kann, welches Latenz und Jitter (Verzögerungen und ungleichmäßige Übertragung in Paketen) überbrücken kann. Insofern ist es für eine Streaming-Anwendung im Gegensatz zu einer Videokonferenz auch gleichgültig, ob LAN oder WLAN eingesetzt wird, wenn nur die verfügbare Bandbreite insgesamt ausreicht. Die Kompression über eine lange Pufferzeit spart viel Übertragungsbandbreite, weil der CODEC nur Blöcke im Bild neu übertragen muss, in denen sich etwas ändert. Der CODEC kann in einem langen Puffer auch Blöcke zwischenspeichern, was schnelle Bewegungen im Vordergrund bei wenig Veränderung im Hintergrund abfedert. Daher schaffen Streaming-Dienste es, eine höhere Videoqualität mit geringerem Bandbreitenbedarf zu übertragen, als es in Videokonferenzen möglich ist. Und hier wird bisher nur ein wirklicher Live-Stream mit einer Echtzeit-Videokonferenz verglichen. Wenn eine Quelle als Konserve vorliegt, kann mit speziellen CODECS vorher offline komprimiert werden, da der CODEC dann “alle Zeit der Welt” hat, um das Video vorab zu komprimieren. Hochkomprimierende offline-CODECS für Konserven benötigen dazu ein Vielfaches der Laufzeit des Videos und sind deshalb für Live-Anwendungen nicht geeignet. All das ist einem CODEC für Echtzeit-Videokonferenzen nur eingeschränkt oder im Fall der Konserve gar nicht möglich.

Welches Tool für welche Anwendung?

Für eine spontane kleine Videokonferenz oder selbstorganisierte Lerngruppen von Studierenden ohne große Organisation eignet sich besonders Jitsi, da gar keine Zugangsdaten eingegeben werden müssen und man sich den Raum, also die URL einfach ausdenken kann. Z.B. https://jitsi.uni-due.de/spontanestreffen funktioniert sofort und weltweit. Der erste Teilnehmer kann auch die Eingabe eines Passwortes erzwingen, so dass sichergestellt werden kann, dass der Nutzerkreis eines Raumes eingeschränkt wird. Ein spezieller Datensparmodus ermöglicht auch die Teilnahme ausschließlich per Audio, so dass notfalls auch ein sehr limitierter Internetzugang, beispielsweise ein stark volumenbeschränkter LTE-Zugang, ausreicht.  Für Android und IOS gibt es jeweils auch eine komfortable Jitsi-App. Auch ein Streaming-Server für automatisierte Streams ist im ZIM an Jitsi angebunden worden. In der aktuellen Jitsi-Version ist es auch möglich eine sehr große Teilnehmerzahl mit zunächst abgeschalteten Mikrofonen und Kameras beitreten zu lassen, wenn der Moderator (Initiator) dieses in den Einstellungen festlegt. Der Moderator ist aber auf die Disziplin der Teinehmer angewiesen. Schauen Sie sich für Details die Dokumentation auf den ZIM-Seiten zu Jitsi an. Für Konferenzen ab ca. 10 Teilnehmern nutzen Sie aber besser BBB, dass dem Moderator wesentlich mehr Möglichkeiten bietet.

Für sehr komfortable Konferenzen in BBB mit guter Präsentations- und Moderationsmöglichkeiten ist es erforderlich, dass zumindest die/der Einladende sich mit Unikennung und Passwort am BBB-Server anmeldet um einen Meeting-Raum zu erstellen. Die Berechtigung dazu muss vorher dazu vergeben werden, wenden Sie dafür an die Hotline des ZIM. Sowohl für Jitsi als auch BBB (Gremienserver) ist im ZIM eine Telefoneinwahl mit FreePBX (Asterisk) realisiert worden.

Über den Microsoft-Bundesvertrag haben Sie darüber hinaus auch die Möglichkeit kostenfrei MS-Teams zu nutzen. Dazu müssen sie aber als Einzelperson die Vertragsbedingungen von Microsoft akzeptieren und ein MS-Office365-Konto anlegen. Das ist allerdings kein Dienst des ZIM und wir können keinen Support oder eine Datensicherung dazu anbieten. Damit Studierende und Lehrende dort überhaupt zusammenarbeiten können, war eine Zusammenlegung der Tenents für Mitarbeiter und Studierende der UDE durch Kollegen im ZIM notwendig. Sie sind persönlich verantwortlich, wenn Sie in der Microsoft-Cloud dienstliche personenbezogene Daten speichern und verarbeiten. Bedenken Sie dabei die DSGVO und die vom EUGH „gekippte“ Privacy Shield Regelung. Aktuell hält ein Arbeitskreis der Datenschutzkonferenz  den rechtskonformen Einsatz von Microsoft 365 in öffentlichen Institutionen für unmöglich.

Auch der DFN-Conf-Dienst scheint nun wieder zuverlässig zu funktionieren. Ob er allerdings dem Semesterbeginn Stand hält, bleibt aber abzuwarten.

Den ZOOM-Cloud-Dienst können Sie für Lehre einsetzen, sofern Sie keine Datenschutzbedenken haben. Bei Dienstbesprechungen dürfen Sie ausschließlich Dienste einsetzen, die an der UDE betrieben werden, d.h. Jitsi, BBB oder ZOOM mit dem „on-premise“-Server. Für Gremiensitzungen empfehlen wir ausdrücklich den BBB-Gremienserver, da dort bei der Anmeldung jeder Teilnehmer mit Unikennung und Passwort authentifiziert wird.

Was alles schiefgehen kann – die drei Feinde der Videokonferenz:

  • Latenz und Jitter
    Wenn Sie am Teilnahmeort eine LAN-Verkabelung haben, nutzen Sie diese auch! Im WLAN haben Sie immer ein geteiltes Medium, daheim mit Nachbarn und Familienangehörigen an der Uni mit Kollegen und Studierenden, die unvermittelt und unabsichtlich für kurzfristige Verzögerungen beim Datentransfer sorgen. Selbst wenn Sie ganz allein einen WLAN-Router nutzen und wirklich Niemand mit einem Gerät in der Nähe ist, fangen Sie sich durch das WLAN eine vermeidbare zusätzliche Latenz (also Verzögerungen) ein. Sowohl bei der Telefonie als auch bei einer Videokonferenz akzeptieren Menschen eine Latenz von höchstens 150 Millisekunden. Bei höheren Verzögerungen fallen sich die Teilnehmerinnen unabsichtlich ins Wort, weil sie von einer Sprechpause des Gegenübers ausgehen. Schlimm wird es auch wenn Sie sich den WLAN Funkkanal teilen und Audio- und Video-Pakete unregelmäßig verzögert ankommen (Jitter), da dann Aussetzer in Ton und Bild vorkommen.
  • Rückkopplungen
    Benutzen Sie bei Videokonferenzen immer ein Headset oder zumindest einen Kopfhörer. Ansonsten kann es passieren, dass ihr Mikrofon den Ton aus Ihrem Lautsprecher aufnimmt und so ein Echo der aktuell Sprechenden erzeugt, was speziell für den Sprecher aber auch für alle Teilnehmerinnen sehr unangenehm ist. Im schlimmsten Fall erzeugen sie sogar einen unangenehmen Pfeifton, der sich immer weiter aufschaukelt. Moderne Videokonferenzsysteme versuchen solche Echos per Software zu unterdrückten, was aber nicht immer zuverlässig funktioniert. Auch eine schlechte Entkopplung von Mikrofon und Lautsprecher in einem minderwertigen Headset kann so eine Rückkopplung auslösen. Einige Bluetooth-Headsets vertragen sich nicht gut mit dem WAN-Chipsatz mancher Notebooks und können so für zusätzliche Latenz sorgen. Wenn Sie über kein Headset verfügen, schalten Sie Ihr Mikrofon immer ab, wenn Sie nicht selber sprechen.
  • Bandbreite Zuhause / der gebuchte Tarif und die Wirklichkeit
    Internet-Provider überbuchen ihre verfügbare Bandbreite, weil sie davon ausgehen, dass nicht alle ihre Kunden den Zugang gleichzeitig mit der gebuchten Maximalgeschwindigkeit nutzen. Deshalb können Sie nicht davon ausgehen, dass Ihnen wirklich die gebuchte Bandbreite immer zur Verfügung steht. Derzeit sind durch massive Homeoffice-Nutzung viele Internetprovider überlastet.  Unter unter https://www.uni-due.de/zim/speedtest/ können Sie testen, wie schnell Ihr Internetzugang wirklich ist.  Auch kurzfristige Verzögerungen und Jitter durch einen geteilten Zugang können Probleme verursachen. Ihre Internetverbindung ist immer der Flaschenhals, ganz selten der Server. Fast alle privaten Internetzugänge sind asynchron konfiguriert, d.h. die Daten von Ihrer Webcam bzw. Audio sind im Upstream (also von Ihnen aus zum Server) begrenzt. Vermeiden Sie die zeitgleiche Nutzung auch durch Familienmitglieder von anderen Internetdiensten während einer Videokonferenz. Wählen Sie immer eine geringe Videoauflösung, sofern die VC-Software das erlaubt. Die Tonübertragung benötigt sehr viel weniger Bandbreite als ein Videobild. Wenn es in einer größeren Konferenz Probleme gibt, sollte nur der aktuell Sprechende ein Videobild senden. Notfalls sollten Sie ganz auf Video zugunsten der Audiokonferenz verzichten.
    Alternativ können Sie Ihren Router daheim so konfigurieren, dass die Bandbreite fair aufgeteilt wird. Das funktioniert rudimentär mit jeder Fritz-Box  und ganz ausgezeichnet mit einem Router der mit der Open Source DD-WRT-Firmware (Einstellung unter NAT/QoS) betrieben wird. Die Fritzboxen priorisieren in der Default-Einstellung Dienste, die sie für Echtzeitanwendungen halten, allerdings liegen sie dabei häufig falsch. Beispielsweise wird der Dienst Wetransfer von Fritzboxen als Echtzeitanwendung priorisiert und killt bei einem großen Upload dann gerne gleichzeitig ablaufende Videokonferenzen. In der DD-WRT-Routerfirmware ist, im Gegensatz zu OpenWRT , die Priorisierung komfortabel konfigurierbar, ohne dass Software nachinstalliert werden muss. Möglichweise haben Sie noch ein älteres unterstütztes Gerät herumliegen, dass Sie für diesen Zweck weiterverwenden können.

36C3 wieder die CCC-Rakete

36C3 wieder die CCC-Rakete

 

Auch in diesem Jahr habe ich den Chaos Communication Congress besucht und wieder allerhand neues zu IT-Security, KI, Netzpolitik und  Medienkunst erfahren. Eine kleine Auswahl an Vorträgen, die ich sehr empfehlen kann,  möchte ich Euch hier nicht vorenthalten.

Zum Thema IT-Security gab es einen Vortrag von Linus Neuman, dem aus Funk und Fernsehen bekannte Pressesprecher des CCC, der wegen der aktuellen Bedrohung mit EMOTET für uns alle sehr interessant ist. Da Linus Neuman als ausgebildeter Psychologe nicht nur IT-spezifische Dinge anspricht, ist der Vortrag auch allgemeinverständlich und sehr sehenswert. Es geht dort um Angst und Lageweile, zwei Faktoren, die uns dazu bringen auf Phishing-Mails hereinzufallen.

Linus Neumann Hirne Hacken – Menschliche Faktoren der IT-Sicherheit

Einen umfassenden Blick auf die IT-(Un)sicherheit der elektronischen Patientenakte bekommt Ihr in dem Vortrag von  Martin Tschirsich, Dr. med. Christian Brodowski und Dr. André Zilch.

“Hacker hin oder her”: Die elektronische Patientenakte kommt!

Was passiert, wenn man Intel-CPUs per Software „undervoltet“, d.h. mit einer niedrigen Spannung betreibt, sieht man im Vortrag von Daniel Gruss und Kit Murdock. Ein Seitenkanalangriff per Software.

Plundervolt: Flipping Bits from Software without Rowhammer

Wer bei der Bahn sparen möchte und wichtige Tipps mitnehmen möchte, wann und ob sich Reservierungen und Sparpreise lohnen, kann sich den  sehr sehenswerten Vortrag ist der von David Kriesel anhören. David Krisel ist wegen seiner Talks auf den Kongressen schon eine Berühmtheit.

BahnMining – Pünktlichkeit ist eine Zier

Wie man aus einer virtuellen Maschine ausbrechen kann, erfahrt Ihr hier im Vortrag von “f1yyy”.

The Great Escape of ESXi - Breaking Out of a Sandboxed Virtual Machine

Wie SQLITE, dass sowohl in jedem IOS und  Android-Device, in Firefox, Chrome als auch in Windows 10 enthalten ist, angegriffen werden kann, kann sich diesen Vortrag von Omer Gull anschauen.

SELECT code_execution FROM * USING SQLite; -Gaining code execution using a malicious SQLite database

Alles was Ihr jemals über SIM-Karten wissen wolltet, beantwortet Euch der Mobilfunkspezialist  Harald Welte aka „Laforge“ in seinem Vortrag.

SIM card technology from A-Z

Wer demnächst in den Urlaub fliegt, kann sich den Spaß am Fliegen durch den spannenden Vortrag von Bernd Sieker verderben lassen.

Boeing 737MAX: Automated Crashes - Underestimating the dangers of designing a protection system

Wer etwas zu den illegalen Überwachungsmaßnamen der US-Geheimdienste  in der Botschaft Ecuadors in London, in der Julian Assange Asyl gewährt worden ist erfahren möchte, kann sich diesen verstörenden Vortrag von Andy Müller-Maguhn anschauen.

Technical aspects of the surveillance in and around the Ecuadorian embassy in London - Details about the man hunt for Julian Assange and Wikileaks

Wie sich die radikalen Rechten im Netz austoben, erfahrt Ihr hier im Vortrag von Arne Vogelsang. Verstörend, aber sehr informativ.

Let’s play Infokrieg - Wie die radikale Rechte (ihre) Politik gamifiziert

Wie man mit WLAN so richtig weit einen Videostream für Drohnen oder überhaupt beliebige Daten übertragen kann, sieht man hier (Spoiler: 10Km Live-HD Video von einer Drohne!) im Vortrag von „befi2.

Wifibroadcast – How to convert standard wifi dongles into digital broadcast transmitters

Für die Fans von Retro-Computing  gibt es hier von Matt Evens den Talk:

The Ultimate Acorn Archimedes talk

Medienkunst bzw. Musik von Frauen gibt es in den Talks von Helen Leight und Jasmine Guffond zu sehen. Hellen Light erwähnt u.A. die Komponistin der original  Dr. Who Titelmelodie:

Hackers & makers changing music technology

Und Jasmine Guffond verwandelt Browser-Cockies in Sounds:

Listening Back Browser Add-On Tranlates Cookies Into Sound - The Sound of Surveillance

Wie man die Verkehrwende selber hacken kann, wie Sharebike und E-Scooteranbieter bei Ihrer Software pfuschen und wie man Open Data in die Stadtverwaltungen bringt, findet sich in diesem großartigen Vortrag von „robbi5“ und „ubahnverleih“, der auch zum Kongressthema Nachhaltigkeit passt:

Verkehrswende selber hacken

Wie man in seiner Garage eine Quantencomputer selber bauen kann erfährt man in dem großartigen Talk von Yann Allain:

Build you own Quantum Computer @ Home – 99% of discount – Hacker Style !

Viel über die Sicherheitslücken in iMessage auf IOS erfährt man im ausgezeichneten Talk von Samuel Groß vom Google Project Zero. Außerdem eine Menge zu Heap-Spraying und ASLR :

Messenger Hacking: Remotely Compromising an iPhone through iMessage

Was sonst alles noch so beim Instant messaging schiefgehen kann, erfährt man bei Will Scott:
What’s left for private messaging?

Alle interessanten Talks kann ich hier gar nicht aufführen, aber unter  https://media.ccc.de/c/36c3 gibt es fast alle Vorträge als Video-Konserven. Viel Spaß damit!

Hi, AI – Liebesgeschichte aus der Zukunft

https://www.hiai-film.de/

Filmforum Duisburg

Dellplatz 16

https://filmforum.de/

10.00 -19:40 Uhr Vorführung

Der AI-Roboter Pepper

Der AI-Roboter Pepper

Den Trailer zum Film können Sie hier finden:

https://vimeo.com/310599944

19:40 – 20:20 Diskussion und Expertengespräch mit Isabelle Reiff und Dr.-Ing. Andreas Bischoff

Anlässlich des Expertengespräches zur Künstlichen Intelligenz habe ich hier einen kleinen Reader zu den Themen AI (im Deutschen KI) und Robotik zusammengestellt:

Eine sehr schöne umfassende und aktuelle Zusammenstellung zum Thema künstliche Intelligenz finden Sie im ganz wunderbaren Buch „Künstliche Intelligenz“ von Manuela Lentzen.

https://www.chbeck.de/lenzen-kuenstliche-intelligenz/product/22250137

Mein Kollege Dr.-habil. Burkhard Wald hat anlässlich eines Vortrages zum Thema KI eine recht umfassende Linkliste in drei Blogbeiträgen zusammengefasst, die gespickt mit Erklärungslinks in die Wikipedia, sowohl die Geschichte der KI, als auch aktuelle Entwicklungen vorstellt.

Blog 1: http://blogs.uni-due.de/zim/2016/12/11/leseempfehlungen-zur-kuenstlichen-intelligenz-teil-1/

Blog 2: http://blogs.uni-due.de/zim/2016/12/27/leseempfehlungen-zur-kuenstlichen-intelligenz-teil-2/

Blog 3: http://blogs.uni-due.de/zim/2017/01/02/leseempfehlungen-zur-kuenstlichen-intelligenz-teil-3/

Sehr visionäre Ideen zu künstlicher Intelligenz und Bewusstsein finden sich in der Vortragsreiche von Joscha Bach aufgezeichnet auf diversen CCC-Kongressen in englischer Sprache:

https://media.ccc.de/search?q=Joscha

Und in deutscher Sprache in diesem sehr hörenswerten Podcast:

https://wrint.de/2013/03/09/wr156-ortsgesprach-joscha-bach-wg-kunstlicher-intelligenz/

Wer selber programmierren kann oder möchte:

Tensorflow ist ein Softwareframework von Google für Künstliche Neuronale Netze, das in C++ und Python programmiert wird. Wer sich ein bisschen mit Webtechniken und Javascript auskennt, kann auch tensorflow.js ausprobieren:

https://www.tensorflow.org/js

Ganz ohne eigenes Programmieren lässt sich dieses tensorflow.js Beispiel im Browser ausprobieren:

tensorflow.js-Demo Webcam Controller für PACMAN im Browser.

Viele Infos in englischer Sprache zum Thema Roboter gibt es im The Robot Report.

Kommentare zum Dokumentarfilm:

Da der Film beabsichtigt unkommentiert verschiedene Robotermodelle mit ganz unterschiedlichen Eigenschaften zeigt, möchte ich hier einige technische Einordnungen zu einzelnen Robotern vornehmen:

Der zittrig gehende humanoide (menschenähnliche) Roboter der italienischen Forschergruppe ist möglicherweise wirklich ein mit einer AI (einem neuronalen Netz) selbst lernendes System. In der AI (KI) wird tatsächlich diskutiert, ob für künstliche Intelligenz (künstliches Bewusstsein) ein Körper nötigt ist.

Pepper, der Roboter, der mit die älteren Dame auf Japanisch kommuniziert zeigt einige Eigenschaften, die man in autonomen Robotern künstlich implementiert, damit sich ein für Menschen glaubhaftes Kommunikationsverhalten realisiert werden kann. Menschen mögen es, wenn Sie angesehen werden, wenn man mit Ihren spricht. Das dauernde Anstarren  durch einen Roboter wird aber als psychologisch unangenehm empfunden. Wenn der Roboter umher oder zur Decke blickt, wir dieses von Menschen als nachdenken interpretiert.

Der weibliche „Gummipuppen-Roboter“ ist offensichtlich ein Sprach-Dialogsystem, dass in der Cloud läuft, ähnlich Alexa und Siri. Die Antworten und Dialoge des Systems sind recht primitiv und lassen vermuten, da eine Chat-Bot Software eingesetzt wird. Eine sehr bekannte Chat-Bot Software mit den Namen Eliza wurde schon in den 70er Jahren realisiert. Ethiker beschäftigen sich aber  tatsächlich damit, Roboter vor einem Einsatz als Sex-Sklaven zu schützen.

Ein kleiner Tipp: Wenn Sie auf Webseiten im Chat oder in Sprachdialogsystemen überprüfen wollen, ob Sie es wirklich mit einem Menschen zu tun haben, machen Sie einen kleinen Turing-Test (ein Test der das Gegenüber auf Intelligenz testet) und fragen Sie den Chat-Partner was er sieht, wenn er aus seinem Bürofenster schaut.

Starke KI – schwache KI – wie weit die Forschung wirklich ist

Mit schwacher KI bezeichnet man Systeme die konkrete Aufgaben lösen wie z.B. künstliche Sprachausgabe, Spracherkennung, Bilderkennung usw. Diese Probleme können mit dem heutigen Stand der Technik als gelöst bzw. beherrschbar angesehen werden. Mit starker KI bezeichnet man echte Künstliche Intelligenz bzw. künstliches Bewusstsein. Eine Definition von KI besagt, dass wenn ein Mensch einen künstlichen Kommunikationspartner nicht von einem echten unterscheiden kann, ist dieser als intelligent zu bezeichnen (Turing-Test).

Alle gezeigten AI-Systeme sind sehr weit von echtem künstlichem Bewusstsein entfernt. Unabhängig vom derzeitigen KI-Hype und Darstellungen in der Science Fiction, ist die Forschung derzeit noch sehr weit von einem künstlichen Bewusstsein entfernt, was unter anderem daran liegt, dass niemand weiß, wie unser Bewusstsein genau funktioniert. Allerdings zeigen die teils bedrückenden Dialoge, was echte oder auch nur vorgegebene AI mit uns Menschen anstellen. Wollen wir im Alter wirklich von Pflegerobotern unterhalten werden? Sollen Dialoge mit Sexspielzeugen in irgendwelchen Clouds abgespeichert werden? Wie verhalten sich Menschen gegenüber intelligenten Maschinen?

Interessanter ist auch die Frage, welche Auswirkungen trainierte künstliche neuronale Netze auf unser Alltagsleben haben werden (oder schon haben). Diese entscheiden schon heute, basierend auf Datenspuren die wir hinterlassen (Big Data), welche Werbung wir angezeigt bekommen, welche Versicherungen uns verweigert werden, welche Therapie bei einer Erkrankung für uns die richtige ist oder nehmen gar Social Scoring (wie in China) vor. Ein Problem künstlicher neuronaler Netze ist immer die Auswahl der Trainingsdaten. Wenn diese Trainingsdaten schon Vorurteile und gefärbte Einschätzungen enthalten, werden die Netze in dieser schon „befangenen“ Weise trainiert. Ein weiteres Problem ist, dass es unmöglich ist, die einzelne Entscheidung eines künstlichen Neuronalen Netzes genau zu verifizieren, also den Grund für eine  Entscheidung herauszufinden.

Isabell Reiff und Andreas Bischoff

Isabelle Reiff:

Isabelle Reiff, geboren 1968 in Bremen, arbeitet als freie Journalistin für Fachverlage und Unternehmen. 1994 noch geduldig aufs Freizeichen ihres 14.4k-Modems wartend, ist ihr heute oft nach Digital Detox. Dem Redaktionsvolontariat folgten zwei Informatik-Forschungsprojekte, seitdem gilt ihr Augenmerk den sozialen Implikationen von IT. Das Kulturhauptstadtjahr brachte sie 2010 nach Dortmund, wo sie als Autorin im »2-3 Straßen«-Konzeptkunstwerk von Jochen Gerz die Bewohner der Nordstadt um »Satz-Spenden« bat. In Köln erschienen ihre ersten Kurzgeschichten wie die über einen Mann, den Spam bis in seine Träume
verfolgt. In ihrem 2017 erschienenen Near-Future-Krimi »UhrZeit« sollen alle Dortmunder per Smartwatch optimiert werden.

https://www.text-der-trifft.de/

https://www.reiff-fuer-die-insel.de

Der Near-Future-Krimi »UhrZeit«:

https://www.amazon.de/UhrZeit-ein-Near-Future-Krimi-Isabelle-Reiff-ebook/dp/B074B9TV6W

Andreas Bischoff:

Dr.-Ing. Andreas Bischoff ist seit 19 Jahren wissenschaftlich in Bereichen Robotik, virtueller und augmentierter Realität unterwegs. Seit 9 Jahren beschäftigt er sich an der Universität Duisburg-Essen mit Hochschul-IT. Ab 2011 Ausstellungen mit interaktiven audio-visuellen Videokunstprojekten. Schwerpunkt ist die kritische künstlerische Auseinandersetzung mit dem Leben im Zeitalter von Big Data und globaler Überwachung.

Kunst: https://mediaart.robotnet.de/

Blog: https://www.robotnet.de/

HP: https://www.dr-bischoff.de/

Uni DUE: https://www.uni-due.de/~bischoff/

Größer, schneller, weiter – das Wachstum setzt sich fort! Mit über 17 Tausend Besuchern war der 35. Chaos Communication Congress unter dem Motto „refreshing memories“(*) Ende Dezember 2018 der bisher größte. Die neuen Räumlichkeiten bieten auch noch ein wenig Reserven für ein weiteres Wachstum.

Der 35C3 in Leipzig in den Hallen der neuen Leipziger Messe. Laserprojektion in der zentralen Messehalle.

Der 35C3 in Leipzig in den Hallen der neuen Leipziger Messe. Laserprojektion in der zentralen Messehalle.

Die Organisation war wie immer perfekt. Über 5000 freiwillige „Engel“ halfen in unzähligen Arbeitsstunden mit, den 35C3 zu einem unvergesslichen Erlebnis zu machen.

Meine Lieblingstalks dort in recht zufälliger Auswahl nach eigenen Präferenzen habe ich hier zusammengestellt. Thematisch ist von KI, Smart Home, Kryptographie, Kryptowährungen, Gesundheits-Apps, Datenschutz und Hardware-Hacking für jede/jeden Interessierten etwas dabei. In der fachlichen Tiefe gab es sowohl Vorträge für Anfänger als auch hochtechnische Talks für echte Nerds.

Alles kann man wegen der vielen parallelen Sessions gar nicht anschauen, aber da helfen wie immer die Aufzeichnungen vom Kongress die vom großartigen VOC-Team (Video Operation Center) unter https://media.ccc.de/b/congress/2018 nachhaltig zur Verfügung gestellt werden. Thematisch reicht der Kongress weit von Algorithmen in der Kryptographie, Angriffen auf Apps, Software, Hardware bis hin zu Auswirkungen von Netzpolitik und Datenschutz auf unser gesellschaftliches Zusammenleben.

Sehr sehenswert waren die vielen Aufbauten (Assemblies) der Regionalgruppen (Erfta-Kreise) des CCC. Da Fotos von Personen auf dem Kongress wegen Einhaltung der Privatsphäre verpönt sind, gibt es hier nur einige Fotos von Exponaten zu sehen.

In der Blog-Version dieses Artikels werde ich noch Vorträge ergänzen, die ich mir zwischenzeitlich noch als Aufzeichnung angeschaut habe.

Das Hauptthema des Kongresses war natürlich Security:

Nexus 5-Besitzer aufgepasst: Einen technisch anspruchsvollen Bluetooth-Angriff auf Broadcom Chipsatz kann man sich im Vortrag „ Dissecting Broadcom Bluetooth“ von jiska und mantz anschauen.

https://media.ccc.de/v/35c3-9498-dissecting_broadcom_bluetooth (en)

Biometrie ist so ziemlich auf allen Gebieten gebrochen. Auf diesem Kongress war die Venenerkennung dran:  „Venenerkennung hacken

Vom Fall der letzten Bastion biometrischer Systeme“ -  ein sehr sehenswerter Vortrag von starbug und Julian.

https://media.ccc.de/v/35c3-9545-venenerkennung_hacken

Festplattenverschlüsselung in Hardware – warum manchmal Bitlocker gar nicht nützt, erfährt man hier:  „Self-encrypting deception weaknesses in the encryption of solid state drives (SSDs) von Carlo Meijer“.

https://media.ccc.de/v/35c3-9671-self-encrypting_deception  (en)

Warum Lampen nicht in die Cloud gehören, erläuterte Michael Steigerwald in seinem Talk „Smart Home – Smart Hack -Wie der Weg ins digitale Zuhause zum Spaziergang wird“. Viele dieser Geräte nutzen ein und dieselbe Software eines chinesischen Herstellers, welche leicht angreifbar ist. Vielen Nutzern ist unklar welche Risiken daraus entstehen. Sie nehmen an, dass dann ein Hacker nur auf dem Internet eine Lampe an- und ausschalten kann. Viel schlimmer ist aber ein Eindringling, der ein Gerät im eigenen Netzwerk übernehmen und von dort aus Rechner im LAN angreifen kann.

https://media.ccc.de/v/35c3-9723-smart_home_-_smart_hack

Wer (glücklicher oder unglücklicher ;-) Besitzer einer Cryptowährung ist, sollte sich diesen Angriff auf Hardware-Wallets einmal anschauen. Eine Besonderheit ist dort, dass auch ein reiner Hardwareangriff mittels Glitches durchgeführt wurde:

„wallet.fail – Hacking the most popular cryptocurrency hardware wallets“von Thomas Roth, Dmitry Nedospasov und Josh Datko.

https://media.ccc.de/v/35c3-9563-wallet_fail

„Open Source Firmware – Eine Liebesgeschichte“ von zaolin bringt Euch Coreboot näher, in das sich der Vortragende wohl verliebt hat.

https://media.ccc.de/v/35c3-9778-open_source_firmware

Das Facebook uns allen DSGVO-widrig hinterherspioniert, auch wenn wir gar keinen Account dort haben zeigt:

„How Facebook tracks you on Android (even if you don’t have a Facebook account)“ von Frederike Kaltheuner und Christopher Weatherhead.

https://media.ccc.de/v/35c3-9941-how_facebook_tracks_you_on_android (en)

“All Your Gesundheitsakten Are Belong To Us – So sicher wie beim Online-Banking”: Die elektronische Patientenakte kommt – für alle.  Warum es keine gute Idee ist Gesundheitsdaten einer App anzuvertrauen zeigt Martin Tschirsich in seinem deutschsprachigen Vortrag. So ganz nebenbei erfährt die Zuschauerin, wie Angriffe auf Apps und auf Webseiten funktionieren und warum Public-Private-Key Verschlüsselungsverfahren auf Smartphones immer wieder versagen.

https://media.ccc.de/v/35c3-9992-all_your_gesundheitsakten_are_belong_to_us

Wer ein bisschen Retrocomputing mag, interessiert sich vielleicht für den Talk von Yaniv Balmas und Eyal Itkin. Der Angriff ist allerdings hochmodern und betrifft jeden HP-Multifunktionsdrucker, der FAX kann! Wenn der Angreifer einmal auf diesem Weg im LAN ist, kann er weitere Rechner infizieren. „What The Fax?! Hacking your network likes it’s 1980 again“:

https://media.ccc.de/v/35c3-9462-what_the_fax (en)

Mobilfunk:

„Die verborgene Seite des Mobilfunks – HF-Störquellen im Uplink“ von Peter Schmidt. Viel über Störquellen beim Uplink in den Mobilfunknetzen erfährt man hier von einem echten Experten aus erster Hand. Man lernt viel über Mobilfunkmasten und kann im Vortrag Tipps abgreifen, wie man einen kostenpflichtigen und ungebetenen Besuch der Bundesnetzagentur vermeiden kann.

https://media.ccc.de/v/35c3-9407-die_verborgene_seite_des_mobilfunks

KI:

Für mich der wahre KI-Experte schlechthin ist Joscha Bach, über dessen Vorträge ich schon einmal berichtet hatte. Der letzte Vortrag dieser Reihe zu Bewusstsein, also starker KI, schlägt in der Einführung einen Bogen von Denkern und Philosophen wie Wittgenstein, Russel zu Turing und Minski zu seinen eigenen Ideen zum künstlichen Bewusstsein.

Auch seine Folien sind ein Genuss – vom kleinem Prinzen bis zur einfachen Erklärung von neuronalen Netzwerken mit einem mechanischen Modell ist alles dabei.

“The Ghost in the Machine – An Artificial Intelligence Perspective on the Soul”

https://media.ccc.de/v/35c3-10030-the_ghost_in_the_machine (en)

Wer Lust auf mehr bekommt, hier sind alle Vorträge von Joscha Bach zu finden:

https://media.ccc.de/search?q=Joscha

Post Quantum Cryptography:

Was mit Kryptographie passiert, wenn es in Zukunft einmal Quantencomputer gibt, kann man sich in diesem Talk anhören (es schadet nicht, wenn man Mathematiker ist ;-).  „The year in post-quantum crypto“ von djb und Tanja Lange.

https://media.ccc.de/v/35c3-9926-the_year_in_post-quantum_crypto (en)

Wissenschaft:

Im Talk „Inside the Fake Science Factories“ von @sveckert, @tillkrause, Peter Hornung and Dr Dade Murphy, kann man sich einmal für die RWTH-Aachen fremdschämen und bekommt einen Einblick in das pervertierte Publikationssystem der Wissenschaft. Eine Warnung vor Fake Science und Fake Konferenzenan alle Wissenschaftler:

https://media.ccc.de/v/35c3-9744-inside_the_fake_science_factories (en)

Kunst:

Auch Kunst und Musik sind in diesem Jahr nicht zu kurz gekommen.

Einen sehr schönen Talk zum Thema Digital Painting hat der Künstler Jeffrey Alan Scudder „Radical Digital Painting – Fantastic Media Manipulation“ gehalten. Er mischt analoge mit digitalen Dingen in seine spannenden Live-Präsentation:

https://media.ccc.de/v/35c3-9774-radical_digital_painting (en)

Eine Installation aus Monoblock Stühlen.

Eine Installation aus Monoblock Stühlen.

Netzpolitik:

Zu Netzpolitik, DSGVO, den Polizeigesetzen und dem Staatstrojaner gab es natürlich auch eine Menge an Vorträgen. Vielleicht ein recht handfester Ratschlag: “Verhalten bei Hausdurchsuchungen

Praktische Hinweise für den Kontakt mit der Staatsmacht” von qbi und Kristin Pietrzyk.

https://media.ccc.de/v/35c3-10018-verhalten_bei_hausdurchsuchungen

Metainformationen zum Hacken

Wer nun jetzt selber Lust aufs Hacken bekommt, sollte sich erst die beiden folgenden Vorträge anschauen.

Wie einen Metadaten verraten (und beim aktuellen Hack von Politiker-Daten den Verursacher verraten haben) erfährt man vom CCC-Sprecher Linus Neumann und Thorsten Schröder im Vortrag „Du kannst alles hacken – du darfst dich nur nicht erwischen lassen – OpSec für Datenreisende“.

https://media.ccc.de/v/35c3-9716-du_kannst_alles_hacken_du_darfst_dich_nur_nicht_erwischen_lassen

Wenn der “Hacker” Orbit diesen Talk gehört und beherzigt hätte, wäre er wohl nicht so schnell geschnappt worden.

Und Frank Riegers (auch einer der Sprecher des CCC) Vortrag:

„Hackerethik – eine Einführung

Verantwortung und Ethik beim schöpferisch-kritischen Umgang mit Technologie“

https://media.ccc.de/v/35c3-10011-hackerethik_-_eine_einfuhrung

Ein Tipp für Besucher des nächsten Kongresses: Das Messegelände ist sehr ausgedehnt – ohne Tretroller macht man dort Kilometer und der Besuch artet in Sport aus!

(*) Dynamisches RAM muss regelmäßig “refreshed” werden. „Memory is RAM!“ –  IT-Crowd ;-)

https://www.youtube.com/watch?v=NdREEcfaihg

Eine verkürzte Version der Informationen hier gibt es auch als PDF-Foliensatz.

Ein Zertifikat läuft ab – na und?

Was bei einem Webserver keine große Sache ist, kann im eduroam so richtig Probleme bereiten. Denn hier läuft nicht irgendein Zertifikat ab, nein ein Root-Zertifikat läuft ab. Das ist bisher im eduroam-Verbund, den es schon fast 15 Jahre gibt, bisher nicht vorgekommen.

Zur Erinnerung: Root -Zertifikate sind sehr viel „haltbarer“, als herkömmliche Server-Zertifikate. Tatsächlich geht der Trend derzeit in Richtung sehr kurzlebiger Zertifikate, wie beispielsweise bei “Let‘s Encrypt“, wo Zertifikate alle drei Monate erneuert werden müssen. Für eduroam, also für den Radius-Server der Uni, handelt es sich um das „Telekom Root CA2„ -Zertifikat, welches nur noch bis zum 9.7.2019 gültig ist. Danach müssen  alle eduroam-Klienten, die sich mit unserem Radius-Server verbinden, neu konfiguriert werden. Vorher einfach ein neues  Server-Zertifikat ausstellen und ausrollen ist nicht so einfach möglich, weil dieses mit einem neuen Root-Zertifikat unterschrieben werden muss. Typische Radius-Klienten für z.B. Windows oder Android unterstützen aber nur ein einziges Root-Zertifikat für Radius. Daher entsteht folgendes Dilemma: Wenn ein neues Root-Zertifikat gewählt wird, funktionieren sofort alle bisher konfigurierten Klienten nicht mehr. Wenn einfach abgewartet wird, müssen alle Geräte an einem Termin neu konfiguriert werden.

Der Ausweg – so machen wir es

Aber es gibt einen Ausweg. Wir haben gemeinsam mit der eduroam-Community und dem DFN-Verein, der den zentralen Radius-Server für die de-Top-Level-Domain betreibt, eine Konfiguration ausgetüftelt, die einen Parallelbetrieb mit einem einzigen Radius-Server erlaubt. Dazu wird die eduroam-Konfiguration anhand der sogenannten äußeren Identität aufgeteilt. Ein Klient, der als äußere Identität „anonymous@uni-due.de“ oder eine Kennung vorweist, bekommt die bisherige Konfiguration mit dem alten Telekom-Root Zertifikat, welches am 9.7.2019 abläuft (und schon seit 1999 gültig ist), zu sehen. Einem Klienten der in der äußeren Identität „eduroam@uni-due.de“ konfiguriert hat, wird das neue Zertifikat “T-Telesec Global Root Class 2″, gültig bis zum Jahr 2033, vorgezeigt. (Falls ein eduroam-freeradius-Admin mitliest – es handelt sich um die “Straufsche-Zertifikatsweiche”, in den Folien hier ab Seite 10).

Die neue äußere Identitat

Die neue äußere Identität – alle Folien dazu gibt es hier

Damit läuft sowohl die alte Konfiguration, diese allerdings nur bis zum 31. Mai 2019 (siehe unten), als auch die neue sofort und auch über den Termin hinaus weiter. Diese Lösung hat auch den Charme, dass Klienten, die keine Einstellung einer äußeren Identität ermöglichen, wie z.B. das relativ seltene Windows Phone, welches nicht von  weiter unten betriebenen eduroam CAT unterstützt wird, weiter bis zum 31.5. 2019 betrieben werden können. Nach dem 31. Mai ist eine Unterscheidung der Zertifikate nicht mehr erforderlich, d.h. auch solche Geräte müssen dann mit dem neuen Zertifikat manuell konfiguriert werden und können so weiter an der Uni benutzt werden.

Termine – Termine

Das Datum  9. Juli 2019 (Jul  9 23:59:00 2019 GMT) bezieht sich auf das Root-Zertifikat mit dem unser Radius-Server-Zertifikat unterschrieben worden ist. Das eigentliche Radius-Server-Zertifikat ist nur noch bis zum 31.5. 2019 um 14:28 Uhr (GMT) gültig und eine Verlängerung für nur zwei Monate mit dem alten Root-Zertifikat ist nicht mehr möglich. Deshalb wird bei uns an der UDE der 31.5. 2019 der spannende Termin für den Zertifikatsablauf werden. An anderen Hochschulen wird möglicherweise erst am 9.7. umgeschaltet. Für UDE-Nutzer ist aber unser Termin relevant, auch wenn sie unterwegs sind.

Warum die äußere Identität wichtig ist

Zur Erinnerung, die äußeren (auch anonym genannten) Identitäten sollen im eduroam verhindern, dass Radius-Administratoren an anderen Universitäten mitbekommen, mit welcher Kennung sich ein “roamender” Nutzer anmeldet. Auch dortige oder lokale Netzwerkadministratoren bekommen die innere Identität nicht zu sehen und können so keine Verknüpfung von MAC-Adressen (also Geräten) zu Personen vornehmen, immer vorausgesetzt die äußere Identität ist korrekt und anonym konfiguriert. Das ist also ein Datenschutz-Feature, auf das keinesfalls bei der Konfiguration verzichtet werden sollte.

Leider sind viele Klienten so konfiguriert, dass datenschutzunfreundlich in der äußeren Identität auch die Kennung steht. Diese Einstellungen entstehen so: Apple (bei IOS) und Microsoft (bei Windows Phone und Windows 10) wollen es den Nutzern möglichst einfach machen und verlangen in Enterprise WPA2 WLANs wie eduroam nur nach einer ID und einem Kennwort und würfeln die restlichen Einstellungen ohne Zutun des Nutzers aus.

Schlampige Klienten

Diese „schlampig“ eingestellten Klienten untergraben dann den Datenschutz und verschleiern vor den Nutzern die wichtigen Detaileinstellungen.

Wenn beispielsweise der sogenannte „realm“, d.h. die Endung „@uni-due.de“ hinter der Kennung weggelassen wird, kann Ihre eduroam-Konfiguration an anderen Hochschulen gar nicht funktionieren, da die dortige IT nicht herausfinden kann zu welcher Heimatorganisation Sie gehören. Der „realm“ lautet bei allen Mitgliedern der Hochschule, auch bei  den Studierenden, immer „@uni-due.de“. Es handelt sich also nicht um eine Mailadresse, d.h. „stud“ hat dort gar nichts zu suchen.

Auch der oben beschriebene Weg mit der äußeren Identität „eduroam@uni-due.de“ ist mit so einem “schlampigen” Klienten nicht zu realisieren. Aber es gibt Abhilfe: Der eduroam.org-Dachorganisation, dem DFN-Verein und auch uns ist das Problem der Komplexität der Konfiguration bewusst. Daher wurde ein webbasiertes Konfigurationstool geschaffen, welches den Nutzerinnen komfortabel passende Konfigurationsprofile für alle eduroam.org Partnerorganisationen zur Verfügung stellt. Das eduroam CAT ist unter der Adresse https://cat.eduroam.org zu erreichen. Der Vorläufer “cat.eduroam.de” wird nicht mehr gepflegt und soll nicht mehr verwendet werden.

Die Webanwendung erkennt Ihr Betriebssystem und, falls Sie im Browser ihre Standortinformationen freigeben und sich an einem der Campi der UDE befinden, das passende Profil für die UDE automatisch. Falls die Betriebssystemerkennung oder die Erkennung der Heimatorganisation fehlschlägt, kann auch manuell ausgewählt werden. Wichtig ist, dass immer die Heimatorganisation gewählt wird, auch wenn man unterwegs an einer anderen Universität zu Gast ist.

Geräte die die Zertifikate gar nicht überprüfen – warum Zertifikate wichtig sind

Leider erlauben die Radius-Klienten vieler Betriebssysteme auch den Verzicht auf die Konfiguration von Zertifikaten für die sichere Kommunikation mit dem Radius-Server. Wir haben auf Server-Seite leider keine Möglichkeit die Zertifikatsüberprüfung zu erzwingen. Ohne Zertifikat können Sie niemals sicher sein, mit dem richtigen Radius-Server der UDE verbunden zu sein. Ein Angreifer in Ihrer Nähe kann einfach einen WLAN-Accesspoint betreiben, der die SSID (den WLAN-Namen) “eduroam” ausstrahlt und durch einen eigenen manipulierten Radius-Server versuchen zu erzwingen, dass ein Klartextpasswort übertragen wird. Einen solchen Angriff hat es schon gegeben. Er wurde unter dem Namen PEAPing Tom auf der Black Hat Konferenz vorgestellt. Ein ähnlicher Angriff ist hier beschrieben.

Falsch und Unsicher: keine Zertifikate installiert!

Falsch und Unsicher: keine Zertifikate installiert!

PEAP-ing Tom Angriff: Der Angreifer sieht das UNI-Passwort im Klartext!

PEAP-ing Tom Angriff: Der Angreifer sieht das UNI-Passwort im Klartext!

Sie gefährden mit dem Verzicht auf Zertifikate im Radius Protokoll die IT-Sicherheit und die Integrität ihrer Uni-Kennung. Auch ein Identitätsdiebstahl, also Handlungen Dritter in ihrem Namen, z.B. bei Prüfungsanmeldungen im oder im SAP, wären in so einem Szenario denkbar.

Zusammenfassung

Wenn Ihr Gerät vom CAT-Tool unterstützt wird, das ist für Windows Vista, 7, 8, 10, MacOS ab 10.7, Android ab 4.3, IOS ab IOS5 und Chrome OS der Fall, sollten Sie umgehend mit dem CAT-Tool die neue Konfiguration installieren. Sie können die Thematik dann vergessen und haben auf keinen Fall ein Problem nach dem 31.5. 2019. Außerdem ist Ihr Gerät dann datenschutzfreundlich und sicher konfiguriert.

Alle bisherigen Konfigurationen und auch das alte CAT funktionieren bis zum 31.5. 2019 wie gewohnt.

Wenn Sie ein Gerät haben, dass nicht von CAT unterstützt wird (z.B. ein Windows Phone), bzw. keine Konfiguration einer äußeren Identität zulässt, müssen Sie nach dem 31.5. 2019 eine Konfigurationsänderung vornehmen, bei der Sie ein Root-Zertifikat einstellen bzw. installieren müssen. Nach dem 31.5. 2019 wird dann jeder äußeren Identität das neue Root-Zertifikat präsentiert. Anleitungen dazu finden Sie auf den Support-Seiten des ZIM unter:

https://www.uni-due.de/zim/services/wlan/eduroam-konfiguration.shtml

So soll nun konfiguriert werden:

  • EAP-Methode: PEAP oder TTLS
  • Innere Authentifizierung: MSCHAPv2
  • Zertifikat: “T-Telesec Global Root Class 2” wählen, wenn installiert oder nachinstallieren unter https://www.pki.dfn.de/fileadmin/PKI/zertifikate/T-TeleSec_GlobalRoot_Class_2.crt
  • innere Identität: <Unikennung>@uni-due.de   (immer “@uni-due.de” niemals “stud” oder eine Mailadresse)
  • äußere Identität: eduroam@uni-due.de
  • Radius-Server: radius1.uni-duisburg-essen.de (hier Langform)
  • Passwort: <Unipasswort> ODER WLAN-Passwort, falls in der Benutzerverwaltung gesetzt

User Experience ist großen Playern wie Google, MS und Apple (die Reihenfolge stimmt heute nicht mehr, MS gehört nun verdient auf den letzten Platz) heute scheinbar in vielen Bereichen wichtiger als Konfigurationsoptionen für erfahrene Nutzer. So hat Google bei der Android-Entwicklung ab Android 7 mit einem Federstrich entschieden, die Konfigurationsoption unter „Einstellungen“ – „WLAN“ – „Erweitert“ -“Bandauswahl 2,4GHz/5GHz/automatisch“, also die „freedom of choice“, zu entfernen. Nun ist alles „automatisch“ und der Nutzer hat keine Möglichkeit mehr einzugreifen.

Einstellungen-WLAN-erweitert-ab-Android7

Hier war es bis Android 6 möglich 5GHz zu erzwingen. Ab Android 7 hat nun der Nutzer keine Möglichkeit mehr 5GHz zu erzwingen.

 

Das ist aber in überbuchten 2,4 GHz Netzen, wie typischerweise an Hochschulen verbreitet, unbedingt erforderlich! Die Empfehlung in Foren doch einfach eine andere SSID für 5 GHz (nach IEEE 802.11ac) zu wählen ist eine Option für Heimnetze und im WPA-Enterprise-Umfeld (nach IEEE_802.1X) nicht einfach umzusetzen. Wenn man sich die Schnitzer von Apple und Google bezüglich professionellen Enterprise-WPA2-Netzten so anschaut, erkennt man, dass dort wohl in erster Linie nur an die Heimnutzer gedacht wird.

Professionelle WLAN-Controller bieten vielfach Optionen an, um Klienten in 5GHz Netze zu verschieben, sofern sie beide Netze unterstützen. Das klappt aber nicht immer, da in diesem Fall der nicht nur der Access Point (bzw. der Controller) sondern auch der Klient mitspielen muss, was im Fall von „halbschlauen“ Heuristiken, die jeder Treiberhersteller oder gar das Betriebssystem selbst implementiert, oft nicht gegeben ist.

Im eduroam-Verbund ist es von eduroam.org vorgeschrieben, die Netze auch mit „eduroam“ im SSID (WLAN-Namen) zu benennen. Klar, eine Einstelloption für das zu verwendende WLAN-Band birgt für unerfahrene Benutzer die Gefahr, sich das WLAN zu „ver-konfigurieren“ und dann das eigenen Netz nicht mehr wiederzufinden. Man hätte die Option aber beispielsweise auch in den Developer-Einstellungen unterbringen können. So vertraut Google Heuristiken und Automatismen, die auf ausschließlich Empfangsstärke (Signal-Level) beruhen und Nutzer in eduroam-Netzen regelmäßig mit dem naturgemäß (5GHz wird wegen der höheren Frequenz durch Wände stärker gedämpft als 2,4Ghz) stärkerem 2,4 GHz SSID „eduroam“ verbindet mehr als kompetenten Menschen. Der Durchsatz in den 5GHz Bändern ist aber sehr viel höher, da dort wesentlich mehr Kanäle zur Verfügung stehen. Deshalb sollte das 5GHz-Band in hochfrequentierten Netzen an Hochschulen immer bevorzugt werden. Wir empfehlen auch immer in unseren Anleitungen nur solche Geräte zu kaufen, die auch 5 GHz unterstützen.

Aber was nützt das, wenn die Hersteller den Nutzer nicht selber entscheiden lassen? Apple erlaubt solche Einstellungen den iPhone-Besitzern und den MacOS-Nutzern überhaupt gar nicht erst, da man dort vielleicht auch zurecht davon ausgeht, dass der Großteil der eigenen Kunden technisch ahnungslos seien. Diesem schlechten Beispiel folgt nun leider auch Google, was wegen des hohen Android-Anteils von über 80% bei den Smartphones an der Uni-DUE (von allen Android-Smartphones sind derzeit [Stand 7/2018] etwa 33% mit Android 7 oder 8 ausgestattet, dieser Anteil wird stark ansteigen) signifikante Auswirkungen auf die „gefühlte“ WLAN-Qualität haben wird. Während bei den „alten“ Windows-Versionen die Treiber über die Systemsteuerung es erlaubten 5GHz zu priorisieren, ist das in Windows 10 (ausnahmsweise, die Privatspäreneinstellungen sind eine Katastrophe) besser mit einer zentralen Einstellungsoption gelöst worden. Auch das mittlerweile abgekündigte Windows Mobile verfügt über eine solche Funktion.

Die Nutzer von Android und MacOS können sich derweil damit trösten, dass sie sich die möglicherweise falsche automatische Wahl ihres Betriebssystems wenigstens anschauen können. Bei MacOS funktioniert das mit Alt+ Klick auf das WLAN-Symbol. Wenn dort nicht wie in diesem Beispiel 5GHz für das WLAN angezeigt wird, kann man sich bei Apple für die schlechte WLAN-Performance bedanken.

so macht Apple das

Alt + Klick auf das WLAN Symbol und der MAC verrät, ob er am schnellen 5GHz-WLAN hängt.

 

Android-Nutzer müssen nun zu einer App greifen (hier empfohlen, WIFIAnalyzer, com.vrem.wifianalyzer) um zu schauen, welches Band die „schlaue“ Automatik ausgesucht hat. Eine Änderung der Wahl ist leider mit der App nicht möglich. WIFIAnalyzer eignet sich auch hervorragend um die beiden weiter unten empfohlenen Apps auf Wirksamkeit zu testen, da der aktuell verbundenen AP gekennzeichnet und mit MAC-Adresse angezeigt wird. Eine ähnliche Funktionalität würde übrigens auch die normale Android WLAN-Anzeige hinbekommen, wenn in den Android-Entwickleroptionen (so aktiviert man diese zusätzliche Option in den Android-Einstellungen) die Option “Ausführliche WLAN-Protokolle” aktiviert wird.

WifiAnalizer

Der WifiAnalyzer zeigt, dass sich das schlaue Android mit dem 2,4 GHz-WLAN verbunden hat, obwohl 5GHz verfügbar ist!

Screenshot_20180802-111709

Hier wird in den Android-Entwickleroptionen die Option “Ausführliche WLAN-Protokolle” aktiviert.

 

Screenshot_20180802-110309

So sieht die Android-WLAN-Anzeige für “Erwachsene”aus, wenn in den Android-Entwickleroptionen die Option “Ausführliche WLAN-Protokolle” aktiviert wurde. Hier hat der WI-FI-Switcher, die zweite App, siehe unten, 5GHz erzwungen. Unter f wird die Frequenz angezeigt, alles mit 5xxx bedeutet 5Ghz 24xx bedeutet 2,4 Ghz. Es werden auch MAC-Adressen und rssi angezeigt.

 

Die App Wifi-Switcher erlaubt zumindest pro Accesspoint einzelne 5 GHz-APs zu priorisieren. Eine weitere  App mit dem sehr ähnlichen Namen Wi-Fi-Switcher erlaubt auch generell 5GHz zu priorisieren. Vor der gleichzeitigen Verwendung der beiden Apps ist aber abzuraten.

WI-FI-Switcher erlaubt die Priorisierung von 5GHz mit dieser Option.

WI-FI-Switcher erlaubt die Priorisierung von 5GHz mit dieser Option.

 

Allerdings muss bei schon verbundenem eduroam die WLAN-Verbindung einmal ab- und wieder angeschaltet werden, damit die Einstellung greift. Das läßt sich direkt in der App erledigen. Möglicherweise ist auch ein Neustart erforderlich, damit die App im Hintergrund die Kontrolle über die WLAN-Auswahl übernehmen kann. Bei beiden Apps muss die Standortfreigabe aktiviert sein – eine weitere Limitierung, die sich Google für neuere Android-Versionen ausgedacht hat. Apps, welche die Wifi-API benutzen, benötigen nun eine Standortfreigabe (Standort nur Gerät, d.h. nur GPS funktioniert auch und ist Datensparsam, da der Standort dann nicht ständig an Google weitergegeben wird, bzw. der Nutzer für Google als War-Driver unterwegs ist). Die App-Autoren müssen nun mit schlechten Bewertungen ahnungsloser Android-Nutzer rechnen, die diese Zusammenhänge nicht verstehen. Auch auf die Bewertungsfunktion im Google Play Store kann man sich, bei der Vielzahl der Laien, die sich eine Bewertung zutrauen, nicht mehr uneingeschränkt verlassen.

Es scheint leider so, als hätte man bei Google Nägel mit Köpfen gemacht, und auch die Auswahl per Android-API entfernt, so dass auch einige  weitere ältere Apps, die so etwas anboten, ab Android 7 gar nicht mehr oder nur noch mit eingeschalteter Standortfunktion funktionieren. (Quelle: https://stackoverflow.com/questions/17345788/scanning-for-wifi-signals-only-in-2-4ghz-band )

Wenn ein Leser eine Möglichkeit kennt unter IOS oder MacOS 5GHz zu erzwingen, wäre ich für einen kurzen Hinweis dankbar.

* Ein Zitat aus dem Film „2001 Odyssee im Weltraum“ in dem die KI “HAL9000″ versucht die Menschen an Bord eines Raumschiffes zu töten, indem sie mit der Begründung “I’m sorry Dave, I’m afraid I can’t do that” einen Befehl eines Menschen ignoriert.  Eine Anspielung auf das Zitat von HAL stammt aus der South Park Folge “You Have 0 Friends“. Als Stan dort versucht seinen facebook Account zu löschen, erhält er die Systemmeldung: “I’m afraid I can’t let you do that, Stan Marsh.”.

Ich bin unterwegs auf dem 34C3 – tuwat in Leipzig auf dem neuen Messegelände. Endlich hat der Kongress fast genug Platz, nur die Bestuhlung der Säle (4000 max) verglichen mit den 15000 verkauften Karten limitieren noch die freie Auswahl einer der 4 parallelen großen Sessions. Dafür ist für die Assemblies nun mehr als genug Raum vorhanden. Während ich zunächst in der kühlen weiten und hellen Umgebung etwas gefremdelt habe, gefällt mir die neue Location sehr gut.

  Security

Kein Chaos Communication Congress ohne das Thema Security: Auch in diesem Jahr gab es neben medienwirksamen Talk zu KRACK (WPA2) und Mobile Banking Apps. Ich hatte ja schon in meinem kleinen ECSM-Talk davor gewarnt, so etwas einzusetzen und dabei auf einen Vortrag auf dem 33C3 verwiesen. Und auch in diesem Jahr hagelte es wieder Angriffe auf schlecht implementierte Banking Apps. Siehe dazu den Talk von Vincebt Haupert: Die fabelhafte Welt des Mobile Bankings.

Mediaart

Eine weitere interessante Thematik auf dem Kongress, die ich bisher etwas vernachlässigt habe sind Beiträge zu Art&Culture, also Medienkunstvorträge. In diesem Jahr sind mir drei großartige Vorträge aufgefallen.

1. Robot Music, Zwei Musiker, die ernsthaft einen Roboter einsetzen um einen C64 basierten-Tracker zu steuern sind etwas Besonderes. Wenn Sie dabei auch noch so cool auftreten kann das nur klasse sein.

2. Electroedibles – Open Source Hardware for Smart Candies von Denisa Kera, Yair Reshef und Zohar Messeca-Fara Was haben Zucker Kant und Elelektronik gemeinsam? Klar, die Anwort kann nur Electroedibles heißen! Eine weltweit einmalige Kombination aus Elekronik mit Sensorik und LEDs, die in Zucker eingegossen interaktive Lollies mit philosophischen Background ergeben. Sehenswert sowohl für den Koch als auch für den Bastler.

3. Deconstructing a Socialist Lawnmower von Darsha Hewitt Ein supercooler Vortrag zu einem DDR-Rasenmäher, der mich sofort an den Roboter Maximilian aus „das schwarze Loch“ von 1979 erinnert hat. Darsha hat das militärische Aussehen des Roboters sofort fasziniert und sie hat dazu beeindruckende Fotos und Videos geschaffen. Auch Ihre frühen Audio-Arbeiten zu dem ersten mechanische Sequenzer von Wurlitzer haben mir sehr gefallen.

Ich diesem Jahr ist aufgrund der Baulichkeiten sehr viel mehr Platz für Medienkunstinstallationen übrig geblieben, was zumindest gefühlt zu mehr Installationen geführt hat. Außerdem kommen solche Dinge mit etwas mehr Platz viel besser zur Geltung.

Mobile Security – Virus auf dem Handy – Malware und Trojaner auf dem Smartphone

Ähnlich wie Windows auf dem Desktop ab Ende der 90er Jahre Ziel von Angriffen über das Internet wurde, blüht dieses Schicksal nun Android als dominierender Betriebssystemplattform für Smartphones. Aber auch Angriffe auf iPhones und iPads werden von uns zurzeit vermehrt beobachtet. Dabei handelt es sich überaschenderweise noch um XhostGhost.

Wie werden die Infektionen erkannt?

Wir bekommen vom DFN-Verein (Deutsches Forschungs-Netz, der Internet-Provider der Uni) automatisierte Warnmeldungen, wenn sich ein Computer oder ein Smartphone aus dem IP-Adressbereich der Uni Duisburg-Essen mit dem Kommandoserver eines bekannten Bot-Netzes verbinden will. In so einem Fall informieren wir die Nutzerinnen und Nutzer über den Befall und empfehlen den Besuch des e-Points bzw. des PC-Services um das Gerät von der Schadsoftware zu säubern.

malware

Viele Nutzer setzen Virenscanner auf Smartphones ein. Deren Wirksamkeit auf Smartphones wird aber von Experten stark angezweifelt. Virenscanner erfordern viele, wenn nicht alle, App-Rechte ein  und schaffen so möglicherweise neue Sicherheitslücken. Apple hat den Herstellern von Virenspanner den Vertrieb dieser Software über den iTunes-Store untersagt.

Was kann so eine Infektion anrichten?

Ist ein Smartphone erst einmal von Schadsoftware durchdrungen, ist es ein Leichtes, diese Geräte und so die Nutzer zu verfolgen, persönliche Kontaktdaten
und Passwörter abzugreifen oder das Telefon gar als Abhörwanze zu betreiben. Kein einziger Account und kein Passwort, welches jemals auf so einem Gerät eingegeben worden ist, ist dann noch vertrauenswürdig. Das gilt auch für die Zugänge zu den App-Stores, die möglicherweise auch Zahlungen mit Kreditkarten zulassen.

Vorsicht mit App-Rechten!

Man sollte sich immer bewusst sein, das jede App, die bestimmte Rechte, wie etwa auf die Kamera, oder das Mikrofon, einfordert die Kamera bzw. das Mikrofon zu jeder Zeit auch benutzen kann. Insofern vertraut man immer dem Programmierer bzw. Anbieter der App. Besonders vertrauenswürdig müssen Apps sein, die eine VPN oder eine zusätzliche Tastatureingabemethode realisieren, da sie alle Eingaben bzw. den gesamten Netzwerkverkehr auch anderer Apps belauschen können. Wenn man Bedenken wegen der geringen Anzahl der bisherigen Installationen oder den geforderten App-Rechten hat, sollte man lieber nach einer alternativen App suchen.

 Wie kommt die Schadsoftware auf das Smartphone?

Häufig installieren die Anwender die Schadsoftware selbst in Form von Spielen oder gefälschten Apps unklarer Herkunft. Google und Apple versuchen Schadsoftware aus dem Android Play Store bzw. dem iTunes App Store fernzuhalten, was ihnen aber nicht immer gelingt. Ganz besondere Vorsicht ist bei Apps aus alternativen App-Stores wie z.B. AndroidPit (Android) oder Cydia (für IOS-Geräte mit Jailbreak) geboten, da hier möglicherweise Apps mit sehr unklarer Herkunft gehandelt werden. Siehe auch diese Zusammenstellung von App-Stores für diverse Smartphone-Betriebssysteme. Viele Android-geräte werden bereits mit einem Zugang zu einem alternativen App-Store verkauft.

Die bei uns aktuell beobachteten Fälle mit XhostGhost haben gar eine manipulierte Entwicklungsumgebung für iPhone-Apps als Ursache. Diese manipulierte XCODE-Version wurde 2015 Entwicklern untergeschoben und hat dazu geführt, dass APPs wie WeChat oder die chinesische Version von “Angry Birds 2″ mit einem Trojaner infiziert worden sind.

Aber auch Sicherheitslücken in Smartphone-Betriebssystemen können die Ursache für eine Infektion mit Schadsoftware sein. Achten Sie darauf alle Sicherheitsupdates für Ihr Betriebssystem auch zu installieren. Auch die Apps sollten Sie regelmäßig aktualisieren.

Leider haben die Hersteller wenig Interesse daran, für Security-Updates zu sorgen, nachdem die Geräte erst einmal verkauft worden sind. Apple hat da ein abweichendes Geschäftsmodell und versorgt die sehr viel teureren IOS-Geräte recht lange mit Updates, während es bei Android-Geräten mit Updates eher mau aussieht. Android-Geräte, die von der alternativen Firmware LineageOS unterstützt werden (Geräteliste hier) können sehr viel länger sicher betrieben werden. Wer nachhaltig und IT-sicher agieren möchte, sollte nur Geräte kaufen, die in dieser Liste aufgeführt werden.

Einige Geräte sind „ab Werk“ mit vorinstallierten Apps des Herstellers  oder gar eigenen App-Stores (siehe oben) ausgestattet, die Sicherheitslücken enthalten. Preiswerte Geräte aus China stehen in Verdacht, schon „ab Werk“ Schnüffelsoftware mitzubringen, die den Anwender ausspioniert. Update: Hier noch zwei ganz aktuelle Fälle (Smartphones von Blue Products und Nomu).

Auf Smartphones laufen Webbrowser, die wir ihre Desktop-Pendants Sicherheitslücken haben können. Insofern können Sie sich  auch Schadsoftware per Drive-by-Download einfangen. Besonders perfide sind beispielsweise Pop-Ups auf Webseiten, die die Besucher zu Downloads überreden sollen. Sowohl für Android (Adblock Browser) als auch für IOS (Adblock Browser) gibt es mobile Adblocker, die die Gefahr von Drive-by-Downloads verringern.

Staatliche Malware – der Staatstrojaner

Eher ein politisches Trauerspiel ist es, dass nun auch Strafverfolgungsbehörden in Deutschland Sicherheitslücken ausnutzen oder für neue sorgen dürfen. Der Staatstrojaner soll Daten vor der sicheren Ende-zu-Ende-Verschlüsselung auf dem Gerät abgreifen. Das deutet auf ähnliche Technologien hin, wie Sie open bei VPN und Tastatur-Apps beschrieben worden sind. Auch solche durch Steuergelder finanzierte Trojaner können Sicherheitslücken enthalten, die möglicherweise von Kriminellen ausgenutzt werden.

Was tun bei einer erkannten Infektion?

Wenn die Infektion durch das ZIM erkannt wurde, bitten wir Sie  umgehend die WLAN-Verbindung in das eduroam unterbrechen und das eduroam-WLAN-Profil löschen. Dann sollten Sie versuchen persönliche Daten vom Smartphone auf einen vertrauenswürdigen Speicher zu kopieren. Wenn Ihre Google bzw. Apple Zugangsdaten gestohlen worden sind, ist auch der Cloudspeicher dort möglicherweise nicht mehr sicher.  Kopieren Sie alle Ihre persönlichen Daten (Kontakte, Fotos) auf einen PC oder die vertrauenswürdige Sciebo-Cloud (auch das Sciebo-Passwort müssen Sie nachher ändern!). Notieren Sie sich alle Zugangsdaten der installierten Apps/Dienste. Für Android-Gräte die OTG-fähig sind gibt es USB-Sticks, die sich für ein Backup auch direkt an der Mikro-USB-Buchse anschließen lassen. Alternativ tut es auch ein OTG-Adapter, an den schon vorhandene USB-Datensticks angeschlossen werden können.

Auch beim Verkauf eines Android Smartphones muss es hier auf den Werkszustand zurückgesetzt werden.

Auch beim Verkauf eines Android Smartphones muss es hier auf den Werkszustand zurückgesetzt werden.

Setzen Sie erst danach Ihr Smartphone auf die Werkseinstellungen zurück. Unter Android geht das so:  „Einstellungen“, „Sichern und Zurücksetzen“, „Auf Werkszustand zurück“.

Unter IOS müssen Sie nach Apples Anleitung vorgehen.

Ändern sie danach Ihr Uni-Passwort im Selfcareportal der Uni. Wir empfehlen Ihnen dringend auch die Passwörter der Google/Apple App-Store-Account und aller auf dem Smartphone verwendeter Dienste zu ändern! Dann können Sie Ihr Smartphone wieder neu mit Ihrem Google/Apple-Account einrichten. Sie sollten dann alle verfügbaren Updates herunterladen. Verzichten Sie darauf Ihr Smartphone mit Hilfe von Google „meine Daten sichern“ bzw. dem Pendant von Apple wieder automatisiert einzurichten, da Sie dann möglicherweise die Schadsoftware wieder automatisch installieren, wenn sie diese aus dem Google-play-Store installiert haben. Ignorieren Sie keinesfalls eine erkannte Infektion, da sowohl Ihre Privatsphäre als auch die Sicherheit des Uni-Netzes betroffen sind.

Phishing-Mails mit Office-Makros waren anlässlich der Locky-Ransomware-Welle das Einfallstor in Windows-Systeme.  Damals hatten wir unsere Kunden gewarnt Office-Anhänge zu öffnen und alternativ auf PDF als Austauschformat zurückzugreifen. Das ist aber nur die halbe Wahrheit, weil gut gemachte Phishing-Mails nun auch Verschlüsselungstrojaner über PDF-Anhänge verbreiten. Der Grund dafür sind aktive Inhalte in PDF-Dokumenten. Wenig bekannt ist, dass auch ein PDF-Dokument aktive Inhalte, wie Videos, Audio und auch JavaScript enthalten kann.

Ich habe hier einmal ein Beispiel für ein aktives PDF-Dokument verlinkt. Wenn Sie es im Browser öffnen, sollte nichts interaktiv passieren, sofern Sie einen modernen Browser verwenden. Wenn Sie das Dokument abspeichern und darauf klicken, poppt ein JavaScript „Hallo Welt“ Dialog auf, sofern der Acrobat Reader installiert ist. Der JavaScript-Code könnte auch potentiell gefährliche Dinge mit Ihrem PC anstellen.

Der in Firefox integrierte PDF-Reader ist selber in JavaScript geschrieben und führt keine aktiven Inhalte aus. Zur Erhöhung der Sicherheit auf dem Windows-Desktop kann alternativ zu Adobe Acrobat SumatraPDF verwendet werden, welches ebenfalls keine aktiven PDF-Elemente zulässt. PDF/A1-Dateien für Langzeitarchivierung dürfen per Definition gar keine aktiven Inhalte wie  z.B. Javascript enthalten und sind deshalb als PDF-Austauschformat zu bevorzugen. Ein schöne Anleitung wie Sie ein solches ungefährliches PDF/A1 einfach aus Word heraus erzeugen findet man hier (einfach beim Exportieren als PDF in den Optionen „ISO 19005 kompatibel“ anwählen). Für Dokumente, die nicht weiter bearbeitet werden müssen, sollte ausschließlich PDF/A1 als Austauschformat eingesetzt werden!

Neben Phishing-Mails gibt es weitere Verbreitungswege von Ransomware, wie z.B. Drive-by-Downloads, Verbreitung über das LAN mit Zero-Day-Lücken und neuerdings auch über gekaperte Software-Updateserver. Ein paar Tipps wie man sich gegen Drive-by-Downloads schützen kann, finden sich in unserer Dokumentation.

Gegen schlimme Zero-Day-Lücken, wie bei WannaCry oder gar die Verteilung von Ransomware über Updateserver wie bei NotPetja helfen solche Vorsichtsmaßnamen alleine nicht. Die frühzeitige Warnung unserer Kunden und besonnenes Handeln kann möglicherweise in so einem Fall Schlimmeres verhindern, sofern überhaupt Informationen zum Verbreitungsweg vorliegen. Man darf gespannt sein, was uns in Zukunft noch alles an kreativer Ransomware begegnet. Der aktuelle NotPetja Angriff hat wieder gezeigt, dass hoch zentralisierte Systeme mit „Standardsoftware“ besonders angreifbar sind, wenn es dem Angreifer gelingt in die gemanagte Umgebung einzudringen. Insofern ist die UDE durch die Diversität der eingesetzten Betriebssysteme und der teils dezentralen IT vor einem worst case „IT-Totalschaden“ gesichert. Wenn allerdings zukünftig alle Betriebssysteme virtualisiert auf einer einheitlichen Virtualisierungsumgebung laufen, kann ein erfolgreicher Angriff auf diese die ganze IT der UDE auf einen Schlag lahmlegen. Auch ein erfolgreicher Angriff auf die – oder auch nur ein Fehler in der – Update-Infrastruktur von Microsoft kann zu einem IT-Blackout zu mindestens der MS-Welt führen. Beide Szenarien sind (hoffentlich) sehr unwahrscheinlich und werden hier nur erwähnt, damit ich beim Eintritt Fefes „told you so“-Spruch loswerden kann ;-).

Im Ernst: Die beste Strategie gegen Verschlüsselungstrojaner ist die Erstellung regelmäßiger Backups. Wer alle wichtigen Dateien im Fileservice auf einen unserer Netzwerklaufwerke im ZIM speichert ist auf der sicheren Seite, da diese durch regelmäßige Snapshots unserer NetApp-Dateiserver geschützt sind. Frei nach Marius Mertens: „Es gibt gesicherte Daten und unwichtige Daten“ oder wie es die C‘t formuliert: Kein Backup? Kein Mitleid!