Kategorie: Linux

Raspberry Pi – Installation und Betrieb von WireGuard

WireGuard Logo

Obwohl die Bekanntheit von WireGuard in den letzten Monaten stark zugenommen hat, ist das VPN-Protokoll bzw, die VPN-Software immer noch verhältnismäßig unbekannt. Ich nutze WireGuard seit einigen Monaten und möchte es nicht mehr missen. Vor allem der schnelle Verbindungsaufbau, das exzellente Roaming-Verhalten und die gute Performance haben mich überzeugt.

Was sich genau hinter WireGuard verbirgt und wie die Software arbeitet, habe ich bereits in meinem Artikel „​WireGuard – neues VPN-Protokoll mit großer Zukunft“ beschrieben. Jetzt folgt sozusagen der zweite Teil, in dem ich detailliert auf die Einrichtung unter Raspbian Buster und Android eingehe.

WireGuard Installation

Die Installationsanleitung funktioniert nicht bei folgenden Raspberry Pi Modellen: 1, 2 (Ausnahme v1.2), Zero & Zero W. Bei diesen Modellen fehlen benötigte CPU-Features und WireGuard muss dort von Hand compiliert werden. Wie das geht habe ich relativ am Ende meines Artikels aufgezeigt. Davon abgesehen macht die Nutzung auf diesen Modellen aber nur eingeschränkt Spaß.

Zunächst bringen wir die Paketquellen und alle Pakete auf den aktuellen Stand. Anschließend installieren wir noch die Kernel Headers.

sudo apt update
sudo apt upgrade
sudo apt install raspberrypi-kernel-headers

Nachdem dies erledigt ist, widmen wir uns der Installation von WireGuard.

echo "deb http://httpredir.debian.org/debian buster-backports main contrib non-free" | sudo tee --append /etc/apt/sources.list.d/debian-backports.list
wget -O - https://ftp-master.debian.org/keys/archive-key-$(lsb_release -sr).asc | sudo apt-key add -
sudo apt update
sudo apt install wireguard
sudo reboot

Die Installation an sich ist damit erledigt. Jetzt können wir mit der Konfiguration fortfahren.

Generierung der benötigten Schlüsselpaare

Zum Start benötigen wir jeweils einen privaten und öffentlichen Schlüssel für den Client und den Server.

Die Erstellung der Keys wird im Verzeichnis „/etc/wireguard“ durchgeführt. Damit alle Dateien bei der Erstellung direkt restriktive Berechtigungen haben, muss die umask auf 077 gesetzt werden.

sudo su
cd /etc/wireguard
umask 077
wg genkey | tee peer1_private.key | wg pubkey > peer1_public.key
wg genkey | tee server_private.key | wg pubkey > server_public.key

Mittels „ls“ prüfen wir, ob alle vier Dateien erstellt wurden:

ls
peer1_private.key  peer1_public.key  server_private.key  server_public.key

Zum Schluss können die Keys mittels „cat“ ausgegeben werden, da wir diese später sowieso benötigen.

exit
sudo cat /etc/wireguard/peer1_private.key
sudo cat /etc/wireguard/peer1_public.key
sudo cat /etc/wireguard/server_private.key
sudo cat /etc/wireguard/server_public.key

WireGuard Server Konfiguration erstellen

Im ersten Schritt aktivieren wir das IPv4 Forwarding in der Datei „/etc/sysctl.conf“. Dies kann entweder mit Entfernen der Auskommentierung der Zeile „net.ipv4.ip_forward = 1“ oder alternativ mit diesem Befehl erfolgen:

sudo perl -pi -e 's/#{1,}?net.ipv4.ip_forward ?= ?(0|1)/net.ipv4.ip_forward = 1/g' /etc/sysctl.conf

Wer IPv6 nutzt, muss stattdessen entsprechend die Auskommentierung der Zeile „net.ipv6.conf.all.forwarding=1“ aufheben.

Anschließend muss der Raspberry Pi neugestartet werden.

sudo reboot

Wir überprüfen den Status mit folgendem Befehl:

sysctl net.ipv4.ip_forward

Wenn das IPv4 Forwarding aktiv ist muss als Ergebnis „net.ipv4.ip_forward = 1“ zurückgegeben werden.

Jetzt erstellen wir die WireGuard-Konfiguration „/etc/wireguard/wg0.conf“. Welchen Editor ihr bevorzugt, bleibt natürlich euch überlassen.

sudo vim /etc/wireguard/wg0.conf

Folgendes Template könnt ihr als Ausgangsbasis nutzen.

[Interface]
Address = 100.64.0.1/24
ListenPort = 51820
PrivateKey = <insert server_private.key>

#replace eth0 with the interface open to the internet (e.g might be wlan0)
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

#Client1 Smartphone
[Peer]
PublicKey = <insert peer1_public.key>
AllowedIPs = 100.64.0.2/32

Neben den IP-Adressen müsst ihr den privaten Schlüssel vom Server und den öffentlichen Schlüssel vom Client ergänzen. Außerdem müsst ihr bei den iptables-Regeln evtl. die Netzwerkschnittstelle anpassen. Optional könnt ihr zudem einen anderen Port definieren. Wenn alles erledigt ist, solltest ihr die Datei unbedingt speichern.

Die für den Tunnel verwendeten IP-Adressen, dürfen sich mit den lokal verwendeten, privaten IPv4-Blöcken (RFC 1918) nicht überschneiden. Beim Einsatz einer FRITZ!Box als Router wird lokal standardmäßig 192.168.178.0/24 verwendet, d.h. alle anderen Adressbereiche können ohne Probleme genutzt werden.

Eine elegante Alternative ist die Verwendung von IP-Adressen (100.64.0.0/10), die für Carrier-Grade-NAT (RFC 6598) reserviert sind. Damit ist sichergestellt, dass die Tunnel-IPs nie mit den privaten Adressbereichen kollidieren können.

WireGuard Client Konfiguration erstellen

Am besten erstellt ihr für jeden Client eine eigene Konfiguration.

sudo vim /etc/wireguard/peer1.conf

Folgendes Template könnt ihr als Ausgangsbasis nutzen.

[Interface]
Address = 100.64.0.2/32
DNS = 192.168.178.1
PrivateKey = <insert peer1_private.key>

#Server
[Peer]
PublicKey = <insert server_public.key>
Endpoint = t6bibneqwcjxplum.myfritz.net:51820
AllowedIPs = 0.0.0.0/0, ::/0
#PersistentkeepAlive = 25

Hier müsst ihr unter „[Interface]“ die IP-Adresse des Clients anpassen und den gewünschten DNS-Server eintragen. In meinem Beispiel verwende ich die private IP der FRITZ!Box. Wer daheim Pi-Hole im Einsatz hat, kann hier die Pi-Hole Adresse eintragen und kommt somit auch von unterwegs in den Genuss der Werbefreiheit.

Außerdem müsst ihr noch den privaten Schlüssel des Clients ergänzen.

Unter „[Peer]“ tragt ihr zunächst den öffentlichen Schlüssel des Servers ein.

Anschließend folgt die Internetadresse, unter welcher der WireGuard-Server erreichbar ist. Üblicherweise gibt es hier zwei Dinge zu beachten. Bei eurem Internetanschluss daheim, bekommt ihr mit großer Wahrscheinlichkeit eine dynamische IP-Adresse vom Provider zugewiesen. Der WireGuard-Client müsste die wechselnden IP-Adressen stets kennen, um sich zu verbinden. Als Hilfe kommt hier ein dynamischer DNS-Anbieter ins Spiel, der einen festen Domainnamen bereitstellt und dahinter automatisch die jweils aktuelle IP-Adresse zuweist. Bei Verwendung einer FRITZ!Box könnt ihr beispielsweise den Dienst „MyFRITZ!“ nutzen. Eine andere Alternative wäre FreeDNS. Der zweite Punkt ergibt sich, wenn der Raspberry Pi in eurem Heimnetzwerk steht. In diesem Fall müsst ihr an eurem Router ein Port-Forwarding einrichten (UDP 51820), sodass der WireGuard-Traffic des Clients auf den Server weitergeleitet wird.

Unter „AllowedIPs“ wird definiert, welche IP-Ranges über das WireGuard-VPN geroutet werden. Mit „0.0.0.0/0, ::/0“ wird der komplette IPv4- und IPv6-Traffic geroutet (full tunnel). Mit 192.168.178.0/24 könnt ihr z.B. nur euer Heimnetzwerk routen (split tunnel).

„PersistentKeepalive“ ist standardmäßig deaktiviert. Zunächst ein paar Hintergrundinfos um einzuordnen, ob ihr dieses Feature benötigt oder nicht. Normalerweise ist WireGuard nicht sehr gesprächig und sendet nur Daten, wenn etwas zu übertragen ist. Ansonsten verhält sich WireGuard ruhig. Wenn sich der Server hinter einem NAT oder einer Firewall befindet und der Client für eine bestimmte Zeit keine Daten zum Server sendet, entfernt der NAT-Router bzw. die Firewall den Host-Status aus der Verbindungstabelle. Falls jetzt der Server ein Paket zum Client sendet, kommt dieses nicht an, da der NAT-Router bzw. die Firewall nicht weiß, was mit dem Paket zu tun ist. Mit der Option „PersistentKeepalive“ sendet der Client alle x Sekunden ein leeres Paket, um die Verbindung aufrechtzuhalten. Ein Wert von 25 Sekunden hat sich in der Praxis bewährt und funktioniert mit einem Großteil von Firewalls und NAT-Routern.

Kurz zusammengefasst benötigt ihr dieses Feature also nur, wenn ihr vom Server euren Client erreichen möchtet, obwohl dieser seit längerer Zeit keine Pakete gesendet hat. Die meisten Benutzer werden dieses Feature nicht benötigen. Falls doch, einfach die Auskommentierung der Zeile rückgängig machen.

WireGuard Server starten

Nun können wir WireGuard auf dem Server starten. Anstatt alle einzelnen Schritte manuell mit dem „wg“-Tool durchzuführen, bedienen wir uns beim Tool „wg-quick“.

sudo wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 100.64.0.1/24 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Danach prüfen wir den Status der wg0-Schnittstelle.

sudo wg
interface: wg0
  public key: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxljP1wpITnI=
  private key: (hidden)
  listening port: 51820

peer: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxtJd9/esWN4=
  allowed ips: 100.64.0.2/32

Der Server läuft und ist für die Verbindung des Clients bereit.

WireGuard beenden funktioniert mit diesem Befehl:

sudo wg-quick down wg0

Wenn WireGuard beim Systemstart automatisch geladen werden soll, kann dies mit folgendem Befehl realisiert werden:

sudo systemctl enable wg-quick@wg0
Created symlink /etc/systemd/system/multi-user.target.wants/wg-quick@wg0.service → /lib/systemd/system/wg-quick@.service.

Der Daemon kann folgendermaßen gesteuert werden. Dabei müsst ihr allerdings darauf achten, dass ihr WireGuard zuerst beendet, sofern ihr es manuell gestartet habt.

sudo systemctl start wg-quick@wg0
sudo systemctl stop wg-quick@wg0
systemctl status wg-quick@wg0

Zum Schluss werden die Berechtigungen von „/etc/wireguard/“ und allen Dateien noch einmal korrigiert. Damit wird sichergestellt, dass nur root die entsprechenden Berechtigungen besitzt.

sudo chown -R root:root /etc/wireguard/
sudo chmod -R og-rwx /etc/wireguard/*

WireGuard Client unter Android einrichten

Die Einstellungen in der Android-App können manuell, mittels einer Datei oder mit einem QR-Code erfolgen. Die letzte Variante ist dabei am bequemsten. Hierfür muss auf dem Server der QR-Code erstellt werden.

sudo apt install qrencode

Nach dem Installieren von „qrencode“ kann der QR-Code von der Client-Konfiguration erstellt werden:

sudo cat /etc/wireguard/peer1.conf | qrencode -t ansiutf8

Auf dem Android-Gerät muss zunächst die WireGuard App via Google Play installiert werden. Daraufhin kann der erstellte QR-Code mit der App gescannt werden, um die Konfiguration zu importieren. Nachdem ein Name vergeben wurde, kann die Verbindung aktiviert werden.

Mit einem Klick auf den gerade erstellten Tunnel werden einige Infos angezeigt, unter anderem auch eine Trafficstatistik.

Auf dem Server kann ebenfalls der Status ausgegeben werden. Dort werden unter anderem alle verbundenen Clients angezeigt:

sudo wg
interface: wg0
  public key: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxljP1wpITnI=
  private key: (hidden)
  listening port: 51820

peer: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxtJd9/esWN4=
  endpoint: 11.12.13.14:53019
  allowed ips: 100.64.0.2/32
  latest handshake: 56 seconds ago
  transfer: 927.04 KiB received, 64.85 MiB sent

Der Client kann nun auch via Ping erreicht werden:

ping 100.64.0.2
PING 100.64.0.2 (100.64.0.2) 56(84) bytes of data.
64 bytes from 100.64.0.2: icmp_seq=1 ttl=64 time=95.9 ms
64 bytes from 100.64.0.2: icmp_seq=2 ttl=64 time=112.4 ms
64 bytes from 100.64.0.2: icmp_seq=3 ttl=64 time=71.7 ms

Noch zwei kleine Tipps für die Android-App. Ich importieren die Konfig vom Server immer zweimal. Einmal als „full tunnel“ mit „0.0.0.0/0, ::/0“ und einmal als „split tunnel“, lediglich mit dem Heimnetzwerk eingetragen, z.B. 192.168.178.0/24. So habt ihr volle Kontrolle und könnt je nach Situation den richtigen Tunnel nutzen.

Beim Bearbeiten eines Tunnels (Tunnel Infos anzeigen und dann rechts oben auf das Stift-Icon) könnt ihr außerdem festlegen, welche Apps keinen Traffic über den Tunnel schicken dürfen.

Troubleshooting

WireGuard ist ein Kernel-Modul, das via DKMS automatisch installiert wird, sobald das System einen neuen Kernel benutzt. In seltenen Fällen kann es jedoch passieren, dass WireGuard nicht automatisch eingebunden wird und mit dem neuen Kernel nicht mehr funktioniert.

In diesem Fall sollte zunächst geprüft werden, ob das WireGuard Modul geladen wurde:

lsmod | grep wireguard

Falls nicht kann es hilfreich sein, das Kernel-Modul neu zu konfigurieren:

sudo dpkg-reconfigure wireguard-dkms
sudo modprobe wireguard

Wenn dies keine Abhilfe schafft, könnt ihr noch folgendes ausprobieren:

sudo apt remove wireguard
sudo apt install bc libncurses5-dev
sudo apt install wireguard

Sollte dies auch keine Besserung bringen, könnt ihr alternativ das WireGuard Kernel Module und das wg Tool selber kompilieren. Davor muss aber sichergestellt sein, dass alle installierten WireGuard-Pakete deinstalliert sind!

sudo apt remove wireguard
# Toolchain installieren
sudo apt install libmnl-dev raspberrypi-kernel-headers build-essential git pkg-config
#Code laden
git clone https://git.zx2c4.com/wireguard-linux-compat
git clone https://git.zx2c4.com/wireguard-tools
# Kernel Module und das wg Tool kompilieren und installieren
make -C wireguard-linux-compat/src -j$(nproc)
sudo make -C wireguard-linux-compat/src install
make -C wireguard-tools/src -j$(nproc)
sudo make -C wireguard-tools/src install
# Neustarten und fertig
sudo reboot

Die aktuell installierte Version könnt ihr am besten via „dmesg“ herausfinden:

dmesg | grep wireguard
[   15.677458] wireguard: loading out-of-tree module taints kernel.
[   15.687104] wireguard: WireGuard 0.0.20200318 loaded. See www.wireguard.com for information.
[   15.687119] wireguard: Copyright (C) 2015-2019 Jason A. Donenfeld . All Rights Reserved.

Quellen

  • https://www.wireguard.com/install/
  • https://github.com/adrianmihalko/raspberrypiwireguard
  • https://www.reddit.com/r/pihole/comments/bnihyz/guide_how_to_install_wireguard_on_a_raspberry_pi/
  • https://emanuelduss.ch/2018/09/wireguard-vpn-road-warrior-setup/
  • https://www.bachmann-lan.de/raspberry-pi-mit-wireguard-als-vpn-server-mit-wireguard/

WireGuard – neues VPN-Protokoll mit großer Zukunft

WireGuard Logo

WireGuard erfreut sich seit geraumer Zeit wachsender Beliebtheit. Hinter WireGuard verbirgt sich sowohl ein VPN-Protokoll, als auch eine VPN-Software. Während es vor zwei Jahren quasi unbekannt war, hat die Bekanntheit in den letzten Monaten stark zugenommen. Grund dafür ist neben der guten Performance und dem schnellen Verbindungsaufbau sicherlich auch die Aufnahme in den stabilen Linux Kernel 5.6, welcher Anfang April 2020 erscheinen dürfte.

Ich selbst bin im Herbst 2019 auf WireGuard gestoßen, als jemand in einem Forum WireGuard vorstellte und als „heißen Scheiß“ bezeichnet hatte. Mittlerweile nutze ich WireGuard seit mehreren Monaten und kann dieser Aussage nur zustimmen :-)

Einleitung

Das VPN-Protokoll WireGuard und die gleichnamige Open Source Software wurden von Jason A. Donenfeld ins Leben gerufen. WireGuard sieht sich selber als extrem einfache, aber dennoch schnelle und moderne VPN-Lösung. Gleichzeitig soll es durch die Nutzung der neuesten Kryptographie-Techniken extrem sicher sein. Im direkten Vergleich mit IPsec und OpenVPN soll es leistungsfähiger, einfacher, schlanker und schneller sein.

Ursprünglich wurde WireGuard nur für den Linux-Kernel entwickelt, ist mittlerweile aber zudem für Windows, macOS, BSD, iOS und Android verfügbar.

Die ersten Snapshots wurden im Juni 2016 veröffentlich. Zwei Jahre später im Juni 2018 wurde der Code und das Protokoll als experimentell bezeichnet und darauf hingewiesen, dass noch kein stabiles Release existiert. Dies trifft bis zum heutigen Tag zu, könnte sich aber bald ändern.

Rund eineinhalb Jahre nach dem Vorschlag von Donenfeld zur Aufnahme in den Hauptzweig ist es nun soweit. Linus Torvalds hat vor wenigen Tagen den Entwicklungszweig Net-Next in den Hauptzweig der Kernel-Entwicklung integriert. Damit wird WireGuard erstmals Teil eines stabilen Linux-Kernels. Der Kernel 5.6 wird für Anfang April erwartet. Grund der langen Verzögerung war der Crypto-Unterbau von WireGuard, welcher einen anderen Ansatz als die Crypto-API des Linux-Kernels verfolgt und deshalb für Unstimmigkeiten gesorgt hatte. Letztlich wurden die neuen Crypto-Funktionen aber im kürzlich veröffentlichten Kernel 5.5 umgesetzt.

Technik

Der Grundgedanke hinter WireGuard ist erfrischend neu und simpel. WireGuard arbeitet ausschließlich auf Schicht 3 des OSI-Modells und ermöglicht die Netzwerkkopplung auf Peer-to-Peer-Basis. Softwareseitig gibt es keine Unterschiede zwischen den Teilnehmern. Alleine die Konfiguration entscheidet, ob ein Peer als Client oder Server arbeitet. Aus diesem Grund sind sogenannte Road-Warrior-Szenarien mit einem zentralen Server und mehreren Clients kein Problem.

Unterstützt wird neben IPv4 auch IPv6. Des Weiteren kann IPv4 in IPv6 getunnelt werden und umgekehrt. Die Verbindung zwischen zwei Peers wird über einen einzelnen, frei wählbaren UDP-Port geregelt. Standardmäßig ist dies UDP-Port 51820.

Zum Verbindungsaufbau wird auf beiden Seiten der VPN-Verbindung lediglich ein Schlüsselpaar benötigt. Der private Schlüssel bleibt dabei lokal, der öffentliche Schlüssel wird der Gegenstelle bekannt gemacht. Auf eine Zertifikat-Infrastruktur kann getrost verzichtet werden. Außerdem kann optional ein symmetrischer Schlüssel (PSK) verwendet werden, der die Verbindung zusätzlich sichert.

Andere VPN-Protokolle unterstützen eine Vielzahl von Algorithmen zum Schlüsselaustausch, zum Chiffrieren und zur Hash-Berechnung. WireGuard geht einen anderen Weg und kennt für jede Aufgabe nur einen fest codierten Algorithmus. Curve25519 für den Schlüsselaustausch, ChaCha20 für die Verschlüsselung, Poly1305 für die Authentifizierung, BLAKE2 für das Hashing und SipHash24 für die Hashtable.

Durch die vollständige Neuentwicklung und den Fokus auf Grundfunktionen kann komplett auf Altlasten verzichtet werden, was sich auch im Quelltext zeigt. Während OpenVPN und IPSec auf mehrere Hunderttausend Zeilen Code kommen, begnügt sich WireGuard mit ca. 7.000 Zeilen.

Ein weiteres Merkmal ist das eingebaute „Roaming“. Wechselt ein Peer (Client), also z.B. ein Smartphone, zwischen WLAN und Mobilfunknetz, bleibt die WireGuard-Verbindung bestehen und der Anwender bekommt davon nichts mit. Selbst wenn es in seltenen Fällen zu einem Verbindungsabbruch führt, ist die Verbindung fast unmittelbar wiederhergestellt. Andere VPN-Protokolle wie IPSec oder OpenVPN sind im direkten Vergleich quälend langsam.

Die gute Performance ist unter anderem darin begründet, dass WireGuard unter Linux direkt im Kernel arbeitet. Somit entfallen häufige Kontextwechsel zwischen Userland und Kernel und die Datenpakete können deutlich schneller abgearbeitet werden. Zudem besitzt WireGuard spezielle Optimierungen für die MIPS-Prozessor-Architektur, sodass es auch für leistungsschwache Geräte interessant ist.

Fazit

Ich habe WireGuard vor ca. fünf Monaten auf meinem Raspberry Pi und meinem Smartphone installiert. Seitdem ist mein Smartphone zu 100% über den WireGuard-VPN-Tunnel online. Weder daheim noch unterwegs musste ich bisher irgendwelche Probleme feststellen. Die Performance ist super und das Roaming-Verhalten spitze. Wie vom Entwickler versprochen gibt es hier keine Abbrüche oder Verzögerungen. Einziger Negativpunkt ist das spärliche Logging auf beiden Seiten.

In einem weiteren Artikel werde ich detailliert auf die Einrichtung unter Raspbian Buster und Android eingehen. Stay tuned!

Raspberry Pi – SSH Hardening

Raspberry Pi Logo

Die wohl am häufigsten genutzte Methode zur Administration eines Raspberry Pis ist Secure Shell (SSH). In den aktuellen Raspbian Versionen ist SSH bereits integriert und muss lediglich aktiviert werden.

Im aktuellen Raspbian Buster (basiert auf Debian 10 Stable) kommt OpenSSH in Version 7.9p1 zum Einsatz. Die Standard-Konfiguration ist in puncto Sicherheit zwar in Ordnung, aber mit einigen Handgriffen lässt sich die Administrationsschnittstelle deutlich besser absichern. Damit steigt die Hürde für potenzielle Angreifer deutlich. Dies ist vor allem wichtig, wenn euer Pi aus dem Internet erreichbar ist.

Mein Artikel bezieht sich auf Raspbian Buster mit OpenSSH 7.9, ist aber größtenteils auch für andere Distributionen und OpenSSH-Versionen anwendbar.

Grundlagen und hilfreiche Befehle

OpenSSH besteht aus zwei Teilen: Dem Server Daemon (sshd) und dem Client (ssh). In diesem Tutorial widme ich mich ausschließlich sshd. Die Konfigurationsdatei des Servers befindet sich hier:

/etc/ssh/sshd_config

Der Status des sshd-Daemons kann mit folgendem Befehl abgefragt werden:

systemctl status ssh.service
● ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2019-11-02 08:44:33 GMT; 2 weeks 3 days ago

Damit könnt ihr sicherstellen, dass sshd automatisch startet (enabled) und gerade läuft (active (running)). Des Weiteren seht ihr auch die 10 letzten Logeinträge.

Mit folgendem Befehl könnt ihr die aktiven SSH-Sessions einsehen:

ss -n -o state established '( dport = :22 or sport = :22 )'

Bei Änderungen an der Server-Konfiguration empfehle ich diese vor dem Neustart des Dienstes zu prüfen. Damit könnt ihr Syntaxfehler und Probleme mit ungültigen Einstellungen in „/etc/ssh/sshd_config“ verhindern:

sudo sshd -t

Zum Anwenden der Änderungen empfehle ich sshd folgendermaßen neuzustarten. Mit dieser Variante besteht die größte Chance, dass offene Remote-Sessions nicht geschlossen werden.

sudo systemctl reload ssh.service

SSH-Server: Einstellungen

Wie oben bereits erwähnt lassen sich die Einstellungen in der Datei „/etc/ssh/sshd_config“ anpassen und sind nach einem Neustart von sshd aktiv. Einige Einstellungen sind bereits standardmäßig deaktiviert. Diese sind in der Config-Datei auskommentiert. Es schadet jedoch nicht diese noch einmal zu überprüfen.
Über die Protokoll-Version müssen wir uns keine Sorgen machen, da ab OpenSSH 7.0 SSH Version  1 bereits beim Kompilieren deaktiviert wird.
Standardmäßig hört der Server auf Port 22. Dieser kann geändert werden, um beispielsweise die Anzahl der Angriffe zu verringern. Einen Sicherheitsgewinn gibt es meiner Meinung nach nicht.
Wenn der Server mehrere IP-Adressen besitzt, kann über „ListenAdress“ eingeschränkt werden, auf welcher IP eine Verbindung akzeptiert werden soll.

#Port22
#ListenAddress 0.0.0.0
#ListenAddress ::

Da wir auf unserem Raspberry keine grafische Benutzeroberfläche haben, können wir das X11-Protokoll getrost deaktiviert lassen. Davon abgesehen wird vom Server ein Rückkanal zum Client geöffnet, was sicherheitstechnisch nicht ganz unbedenklich ist.

#X11Forwarding no

Mittels .rhosts-Datei kann der Zugriff von fremden Systemen lediglich anhand der IP-Adresse erlaubt werden. Dieser Zugriff ist heutzutage nicht mehr üblich und daher standardmäßig deaktiviert.

#IgnoreRhosts yes

Useraccounts ohne Passwort dürfen sich nicht via SSH anmelden. Auch diese Option ist per Default deaktiviert.

#PermitEmptyPasswords no

Eine direkte Anmeldung mit dem Account „root“ sollte in der Regel nicht erlaubt werden (PermitRootLogin no). Falls dies aus bestimmten Gründen dennoch notwendig sein sollte, ist die Option „without-password“ in Ordnung. Diese ist standardmäßig gesetzt und erlaubt eine Public-Key-Authentifizierung mit dem root Account.

#PermitRootLogin without-password

Die maximale Zahl der Anmeldeversuche pro User sind standardmäßig auf 6 gesetzt. Ich würde empfehlen den Wert weiter zu verringern, beispielsweise auf 3.

MaxAuthTries 3

Inaktive Sessions können nach einer bestimmten Zeit automatisch beendet werden. Mit „ClientAliveInterval“ wird festgelegt, nach wie vielen Sekunden Inaktivität der Server eine Nachricht an den Client sendet. „ClientAliveCountMax“ ist die Anzahl, wie oft dies der Server wiederholt, bis der Client getrennt wird. In meinem Beispiel oben wird der Client nach 15 Minuten getrennt.

ClientAliveInterval 300
#ClientAliveCountMax 3

Normalerweise erfolgt die Anmeldung am Server mit Username und Passwort. Eine bessere Alternative ist die Public-Key-Authentifizierung. Diese ist bereits standardmäßig erlaubt.

#PubkeyAuthentication yes

Zur Einrichtung muss auf dem Client zunächst ein neues Schlüsselpaar generiert werden. Wählt hier „Ed25519“, sofern nichts gravierendes dagegenspricht. Unter Windows könnt ihr dies prima mit PuTTYGen erledigen. Ab Windows 10 1809 kann dies auch direkt via PowerShell oder der Eingabeaufforderung erledigt werden. Unter Linux nutzt ihr ssh-keygen. Der Einsatz einer Passphrase ist zwar optional, aber ich empfehle ein starkes Passwort zu verwenden, um den Key vor Missbrauch zu schützen.

ssh-keygen -o -a 100 -t ed25519 -f ~/.ssh/id_ed25519

Im nächsten Schritt muss der Public Key auf dem Server eingetragen werden. PuTTYGen stellt euch den String bereit, den ihr in die „authorized_keys“ kopieren müsst.

ssh pi@192.168.10.10
mkdir ~/.ssh
chmod 700 ~/.ssh
vi ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Unter Linux geht dies mit „ssh-copy-id“ etwas einfacher.

ssh-copy-id -i ~/.ssh/id_ed25519.pub pi@192.168.10.10

Abschließend solltet ihr prüfen, ob die Anmeldung via Public-Key-Authentifizierung funktioniert. Falls ja, könnt ihr nun die Passwort-Anmeldung an eurem SSH-Server deaktivieren.

PasswordAuthentication no
#ChallengeResponseAuthentication no

SSH-Server: Cipher-Suites und Verschlüsselungsalgorithmen

Zur Prüfung, welche Cipher-Suites und Verschlüsselungsalgorithmen euer OpenSSH-Server anbietet, eignet sich das Python-Script „ssh-audit“:

cd ~
wget https://github.com/jtesta/ssh-audit/releases/download/v2.1.0/ssh-audit-2.1.0.tar.gz
tar -xvzf ssh-audit-2.1.0.tar.gz
~/ssh-audit-2.1.0/ssh-audit.py localhost

Alternativ könnt ihr auch Nmap dazu verwenden:

nmap -p22 -n -sV --script ssh2-enum-algos localhost

Schauen wir uns zunächst die Algorithmen für den Schlüsseltausch an. Falls Curve25519 nicht ausreichend ist, könnt ihr noch „diffie-hellman-group-exchange-sha256“ hinzufügen.

KexAlgorithms curve25519-sha256@libssh.org

Danach folgen die Schlüssel bzw. Algorithmen für die Authentifizierung. Hier solltet ihr alle vorhandenen Host-Schlüssel löschen und neu generieren.

cd /etc/ssh
sudo rm ssh_host_*key*
sudo ssh-keygen -t ed25519 -f ssh_host_ed25519_key -N "" < /dev/null
sudo ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key -N "" < /dev/null

Anschließend könnt ihr in eure „sshd_config“ folgendes eintragen:

HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key
HostKeyAlgorithms ssh-ed25519,ssh-rsa

Als nächstes nehmen wir uns den symmetrischen kryptographischen (Ciphers) sowie MAC (Message Authentication Code) Algorithmen an. Folgendes gilt aktuell als sicher:

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com

Prüft zur Sicherheit, dass ihr vor dem Neustart von sshd eine Verbindung habt, damit ihr euch im Notfall nicht den Zugang zu eurem Raspberry absägt.

Einen guten Artikel mit weiteren Details über die einzelnen Cipher-Suites und Verschlüsselungsalgorithmen findet ihr hier: https://stribika.github.io/2015/01/04/secure-secure-shell.html

Veeam Backup & Replication 9.5 Community Edition – kostenlose Version mit mehr Möglichkeiten

Veeam Backup & Replication 9.5 Update 4

Das vor einigen Tagen veröffentlichte Veeam Backup & Replication 9.5 Update 4 bringt trotz des kleinen Versionssprungs einige Neuerungen mit sich. Neben zahlreichen neuen Features gibt es auch eine Änderung bei der Lizenzierung, die vor allem Privatleute und kleine Firmen erfreuen dürfte.

Das Update 4 von Backup & Replication 9.5 ersetzt die bisherige Free Edition durch die Community Edition. Dabei können alle Features der Standard Version benutzt werden, es existiert lediglich eine Beschränkung auf 10 Instanzen. Die 10 Instanzen können beliebig kombiniert werden und ermöglichen beispielsweise folgende Kombinationen:

  • 10 VMs
  • 10 Workstations
  • 5 VMs + 5 Workstations
  • 5 VMs + 1 Server + 2 Workstations
  • 1 VM + 3 Servers
  • 3 Servers + 1 Workstation

Bei der Free Edition bis Veeam Backup & Replication 9.5 Update 3a war hingegen keine Beschränkung vorhanden. Allerdings kann mit der Free Edition nur VeeamZIP genutzt werden. Ein zeitgesteuertes Backup ist nicht möglich, ebenso können VMs damit nur komplett gesichert werden. Insgesamt ist die neue Community Edition in den meisten Fällen also ein deutlicher Gewinn im Vergleich zur Free Edition.

Darüber hinaus bringt das Update 4 auch einige neue Features mit. Veeam Cloud Tier ist eine weitere Storage-Option und ermöglicht eine Langezeit­archivierung via Amazon S3, Azure Blob Storage oder S3-kompatible Services. Veeam Cloud Mobility ist eine Verbesserung von „Direct Restore to Microsoft Azure“, es werden jetzt auch AWS und Azure Stack als Ziele akzeptiert. Veeam DataLabs ist der Nachfolger für Virtual Labs und bringt ein paar neue Funktionen für das Einrichten einer Testumgebung mit. Des Weiteren lässt sich mit Role-Based Access Control (RBAC) for vSphere der Zugriff auf Backups und Jobs in VMWare regeln und es existieren neue Daten­sicherung-Plugins für SAP HANA und Oracle RMAN.

Einen detaillierten Überblick über alle Neuerungen findet ihr auf dieser Seite.

Download Veeam Backup & Replication 9.5 Update 4

Veeam Backup & Replication Community Edition

36 Jahre alte Sicherheitslücke in SCP gefähredet OpenSSH, PuTTY und Co.

Der Sicherheitsforscher Harry Sintonen hat im Secure Copy Protocol (SCP) mehrere Schwachstellen entdeckt. Dadurch können Angreifer Dateiübertragungen manipulieren und z.B. Schadcode ausführen lassen. Betroffen sind alle Programme, die auf SCP aufsetzen. Die bekanntesten dürften OpenSSH, PuTTY und WinSCP sein.

Mit SCP können Dateien zwischen einem lokalen und einem entfernten Computer sicher über das Netzwerkprotokoll SSH ausgetauscht werden. Sintonen von F-Secure warnt vor fünf Sicherheitslücken in SCP, die teilweise bereits 36 Jahre alt sind. Entdeckt wurden diese allerdings erst im August 2018.

Many scp clients fail to verify if the objects returned by the scp server match those it asked for. This issue dates back to 1983 and rcp, on which scp is based. A separate flaw in the client allows the target directory attributes to be changed arbitrarily. Finally, two vulnerabilities in clients may allow server to spoof the client output.

Konkret könnte sich ein Angreifer über einen Man-in-the-Middle-Angriff in die SSH-Verbindung einklinken und bösartige Dateien einschleusen. So könnten beispielsweise Konfigurationsdateien geändert oder eine bash-Datei im Home-Verzeichnis abgelegt werden.

Nur CVE-2018-20685 ist mit dem Bedrohungsgrad „hoch“ eingestuft. Wer auf Nummer sicher gehen möchte, kann vorerst komplett auf SCP verzichten. OpenSSH im SCP-Modus ist von allen Lücken betroffen. In der aktuellen OpenSSH Version 7.9 ist nur die Schwachstelle CVE-2018-20685 behoben. WinSCP ist seit der neuen Version 5.14 komplett abgesichert. Die letzte Version 0.70 von PuTTY wurde Mitte 2017 veröffentlicht und bietet daher noch keinen Schutz.

Raspberry Pi – Ein Blick auf den Stromverbrauch

Raspberry Pi Logo

Der Raspberry Pi kann für eine Vielzahl von Projekten verwendet werden und zeichnet sich durch eine ausreichende Performance und einen geringen Stromverbrauch aus. Doch was bedeutet ein geringer Stromverbrauch genau? Falls der Raspberry Pi mit Akkus betrieben oder als Server verwendet wird und rund um die Uhr läuft, ist es wichtig genaue Werte zu kennen.

Ich habe den aktuellen Raspberry Pi 3B+ genauer unter die Lupe genommen und liefere euch ein paar Werte. Alle Messungen wurden ohne Monitor, Tastatur und Maus durchgeführt. Als Betriebssystem kam das aktuelle Raspbian Lite Stretch (13.11.2018) zum Einsatz.

Raspberry Pi 3B+ StatusStromverbrauch
Idle (kein Ethernet oder WLAN)1,6 W
Idle (WLAN)1,9 W
Idle (Ethernet 100 MBit/s)1,8 W
Idle (Ethernet 1 GBit/s)2,1 W
Idle (Ethernet 1 GBit/s + WLAN)2,4 W
stress –cpu 1 (Ethernet 1 GBit/s)3,2 W
stress –cpu 2 (Ethernet 1 GBit/s)3,9 W
stress –cpu 3 (Ethernet 1 GBit/s)4,6 W
stress –cpu 4 (Ethernet 1 GBit/s)5,2 W

Zusammengefasst benötigt der Raspberry Pi 3B+ im Leerlauf 1,6 Watt. WLAN zusätzlich macht 0,3 Watt aus, LAN je nach Geschwindigkeit 0,2 Watt (100 MBit/s) oder 0,5 Watt (1 GBit/s).

Stromverbrauch minimieren

Insbesondere beim mobilen Einsatz mit Batterien oder Akku ist eine möglichst lange Laufzeit wünschenswert. Mit einigen kleinen Tweaks kann der Stromverbrauch weiter reduziert und damit gleichzeitig die Laufzeit erhöht werden. Nichtsdestotrotz sollte man sich die Frage stellen, ob ein Raspberry Pi Zero W oder ein anderes älteres Modell eine bessere Alternative wären.

HDMI

Wenn kein Bildschirm verwendet wird, kann der HDMI-Port on-the-fly deaktiviert werden:

sudo tvservice -o

Dies spart ca. 20 mA, also 0,1 Watt. Wenn HDMI automatisch deaktiviert werden soll, kann dies z.B. über die „/etc/rc.local“ erfolgen. Vor „exit 0“ ergänzt man folgendes in der Datei:

# Disable HDMI
/usr/bin/tvservice -o

Eine schönere Alternative ist dies aber über die Datei „/boot/config.txt“ zu erledigen:

disable_splash=1
hdmi_blanking=1
hdmi_ignore_hotplug=1
hdmi_ignore_composite=1

Damit die Änderungen aktiv werden ist ein Neustart notwendig.

LEDs

Des Weiteren können die Aktivitäts- und Power-LED deaktiviert werden. Dies geschieht ebenfalls über Einträge in der „/boot/config.txt„:

# Disable the ACT LED.
dtparam=act_led_trigger=none
dtparam=act_led_activelow=off

# Disable the PWR LED.
dtparam=pwr_led_trigger=none
dtparam=pwr_led_activelow=off

Nach einem Neustart lassen sich hier pro LED rund 5 mA sparen, insgesamt also 10 mA oder 0,05 Watt.

Bluetooth & WLAN

Die integrierte WLAN-Funktionalität kann im laufenden Betrieb deaktiviert werden:

sudo ifconfig wlan0 down

Wer WLAN automatisch immer deaktiviert haben möchte, kann dies wiederrum über die „/boot/config.txt“ erledigen:

# Disable Bluetooth and Wifi
dtoverlay=pi3-disable-wifi
dtoverlay=pi3-disable-bt

USB & Ethernet

Einen wirklich großen Effekt erzielt die Deaktivierung des USB-Chips. Damit lassen sich rund 200 mA, respektive 1 Watt einsparen. Allerdings muss einem bewusst sein, dass damit automatisch auch das Ethernet deaktiviert ist, WLAN funktioniert aber weiterhin.

sudo echo '1-1'|sudo tee /sys/bus/usb/drivers/usb/unbind

Hat das Betriebssystem Einfluss auf den Stromverbrauch?

Angeregt durch einen Kommentar von tux. habe ich mir zudem den Stromverbrauch unter NetBSD / FreeBSD / OpenBSD angesehen. Leider wird der neue Raspberry Pi 3B+ noch nicht von allen BSD-Betriebssystemen vollständig unterstützt, sodass das Gerät nicht automatisch bootet und keine IP-Adresse per DHCP bezieht. In diesem Fall ist die Installation etwas aufwändiger. Abhilfe schafft entweder eine Tastatur und ein Bildschirm oder der Consolen-Zugang mit einem USB to TTL Serial Cable.

NetBSD / FreeBSD

Von NetBSD gibt es ein speziell auf Raspberry Pis angepasstes Image, den Download-Link findet ihr in Zeile 14. Zu beachten ist, dass das integrierte WLAN des Raspberry Pi 3B+ unter BSD aktuell nicht funktioniert.

Bei FreeBSD verwendet ihr am besten FreeBSD-12.0-RELEASE  oder FreeBSD-13.0-CURRENT. Hier gibt es jeweils spezielle Versionen (-RPI3) für den aktuellen Pi, die out-of-the-box laufen. Allerdings funktioniert auch hier das WLAN mangels entsprechendem Treiber nicht.

Raspberry Pi 3B+ StatusRaspbianNetBSDFreeBSD
Idle (kein Ethernet oder WLAN)1,6 W1,9 W1,7 W
Idle (Ethernet 100 MBit/s)1,8 W2,1 W1,9 W
Idle (Ethernet 1 GBit/s)2,1 W2,5 W2,2 W

Insgesamt betrachtet liegt der Stromverbrauch unter NetBSD und FreeBSD leicht höher als bei Raspbian.

Weitere Messungen

Alternative Messergebnisse inklusive Vergleichsmessungen zu älteren Raspberry-Pi-Modellen findet ihr bei RasPi.TV und Raspberry Pi Dramble.

Raspberry Pi – Inbetriebnahme und Basisinstallation

Raspberry Pi Logo

Der Raspberry Pi ist wohl der bekannteste und auch beliebteste Einplatinencomputer weltweit. Im Smart Home kommt er oft zum Einsatz, da er für fast alle Projekte genügend Leistung liefert und gleichzeitig einen geringen Stromverbrauch aufweist. In diesem Artikel möchte ich euch zeigen, wie ihr den Raspberry Pi mit einer Basisinstallation bzw. -konfiguration in Betrieb nehmen könnt. Darauf aufbauend lassen sich viele spannende Projekte (unbound, Pi-hole, EDOMI, openHAB, ioBroker, usw.) mit dem kleinen Computer realisieren.

Hardware

Zur Grundausstattung, damit der Raspi in Betrieb genommen werden kann, gehören neben dem Raspberry Pi ein passendes Netzteil und eine Speicherkarte. Ein Bildschirm und eine Tastatur sind im Normalfall nicht notwendig, dazu aber später mehr. Meine Hardwarekomponenten sehen beispielsweise folgendermaßen aus:

Als Alternative zum offiziellen Micro-USB-Netzteil kann selbstverständlich auch ein anderes Netzteil mit 2,5A/5V verwendet werden. Allerdings möchte ich erwähnen, dass es bei USB-Netzteilen bzw. Handyladegeräten teilweise zu Problemen kommt, Stichwort Undervolt-Icon. Das hängt damit zusammen, dass viele Netzteile eine Spannung von 4,9V oder genau 5V am Micro-USB-Stecker liefern. Durch die Bauelemente zur Spannungsregelung auf dem Raspberry Pi führt das aber dazu, dass beim Raspi lediglich 4,7 – 4,8V ankommen, was zu wenig ist. Das offizielle Netzteil liefert am Ausgang 5,1V, wodurch beim Raspi ausreichende 4,9A anliegen. Wer seinen Raspberry Pi 3B+ via PoE betreiben möchte, kann sich den offiziellen PoE-HAT ansehen.

Beim Speicher solltet ihr darauf achten, dass die microSD-Karte den Standard UHS-I unterstützt, sonst bremst ihr euren Pi unnötig aus. Schnellere Karten sind aber auch nicht sinnvoll, da der Minicomputer davon nicht profitiert. Der Speicherplatz sollte mindestens 8 GByte betragen. Bei den aktuellen Preisen, bei denen selbst 32 GByte unter 10 Euro inklusive Versand erhältlich sind, setze ich aber auf mindestens 32 GByte.

Software

Update 06.11.2019: Artikel auf Raspbian Buster angepasst.

Die empfohlene Linux-Distribution für den Raspberry Pi ist Raspbian. Die aktuelle Version basiert auf Debian 10 Stable (Buster), hat aber einige Anpassungen für den Minicomputer an Bord. Das ist auch der Grund, warum ihr das Betriebssystem immer direkt bei der Raspberry Pi Foundation herunterladen solltet. Raspbian ist in drei Varianten erhältlich:

Für viele Projekte genügt das aufs Nötigste reduzierte Raspbian Lite. Sofern möglich bevorzuge ich immer die Lite-Variante.

Installation

Die Installation von Raspbian auf die SD-Karte kann mit verschiedenen Methoden durchgeführt werden. Anfänger können auf NOOBS (New Out Of the Box Software) zurückgreifen, welches das gewünschte Betriebssystem vollautomatisch herunterlädt und auf die SD-Karte packt. Nichtsdestotrotz empfehle ich den „manuellen“ Weg, der nicht viel mehr Aufwand bedeutet.

Nach dem Herunterladen der gewünschten Raspbian-Version, kann diese unter Windows, Linux oder macOS mit dem Tool Etcher auf die SD-Karte installiert werden. Das Ganze geht schnell und ist quasi selbsterklärend. Etcher starten, das Raspbian-Image- bzw. -ZIP auswählen, anschließend die SD-Karte angeben und zum Abschuss auf den Button „Flash!“ klicken.

Etcher

Alternativ existieren noch weitere Möglichkeiten, die in den offiziellen Anleitungen der Raspberry Pi Foundation beschrieben sind:

Unter Linux und macOS können die Boardmittel genutzt werden. Unter Windows existiert mit dem Tool Win32 Disk Imager eine Alternative zu Etcher, die aber fast identisch funktioniert. Nachdem die Image-Datei und die SD-Karte als Ziel-Laufwerk angegeben wurden, kann Raspbian mit einem Klick auf die SD-Karte geschrieben werden.

Win32 Disk Imager

Einrichtung / Grundkonfiguration

Nachdem Raspbian auf der SD-Karte installiert wurde, müsst ihr dort auf die Partition „/boot“ zugreifen. Unter Windows wird die Boot-Partition als separates Laufwerk angezeigt. Direkt darunter solltet ihr eine neue Datei mit dem Namen „ssh“ anlegen. Dies ist notwendig, damit ihr via SSH auf euren Raspberry Pi zugreifen könnt. Das Vorhandensein einer Tastatur und eines Bildschirms ist nicht notwendig.

Grundsätzlich solltet ihr das Gerät wenn möglich via LAN verbinden. Diese Variante ist stabiler als WLAN und bringt niedrigere Latenzzeiten als zusätzlichen Bonus mit. Falls ihr kein LAN nutzen könnt oder einen Raspberry Zero W ohne LAN-Anschluss habt, müsst ihr auf der Boot-Partition noch eine zweite Datei namens „wpa_supplicant.conf“ erstellen. Anschließend folgenden Inhalt in die Datei einfügen. Vergesst nicht die SSID und das WLAN-Passwort anzupassen.

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=DE
network={
    ssid="<SSID Ihres WLAN>"
    psk="<WLAN-Passwort>"
    key_mgmt=WPA-PSK
}

Im nächsten Schritt steckt ihr eure microSD-Karte in den Raspberry Pi. Anschließend verbindet ihr euren Pi mit dem Netzwerk (bei LAN) und schließt die Stromversorgung an. Innerhalb einer Minute ist der Minicomputer betriebsbereit und sollte via DHCP eine IP-Adresse bekommen haben, sofern in eurem Netzwerk ein DHCP-Server läuft (üblicherweise euer Internet-Router). Dort könnt ihr die vergebene IP einsehen. Bei einer FRITZ!Box findet ihr die benötigte Information unter „Heimnetz –> Netzwerk“. Darüber hinaus sollte das Gerät auch über den Hostnamen „raspberrypi“ erreichbar sein.

Jetzt kann die erste Verbindung zum Raspberry Pi via SSH aufgebaut werden. Unter Windows könnt ihr neben PuTTY auch KiTTY oder unter Windows 10 sogar die PowerShell nutzen. Bei Linux oder macOS einfach eine Konsole öffnen und den Befehl „ssh pi@IP-Adresse“ verwenden. Die Standard-Zugangsdaten lauten User „pi“ und Passwort „raspberry„.

Als Erstes ändert Ihr direkt das Standard-Passwort mit dem Befehl:

passwd

Daraufhin werden das Betriebssystem und die Pakete auf den aktuellen Stand gebracht. Das kann bis zu einer Viertelstunde dauern.

sudo apt update
sudo apt upgrade
sudo apt dist-upgrade

Danach ist euer Raspberry Pi auf dem neuesten Stand und betriebsbereit.

Jetzt könnt ihr mit folgendem Befehl die Grundkonfiguration starten:

sudo raspi-config

Dort lassen sich unter anderem der Hostname, die Sprache, das Tastaturlayout oder die Zeitzone anpassen.

Dennoch möchte ich euch nachfolgend noch ein paar weitere nützliche Konfigurationen vorstellen.

Statische IPv4-Adresse definieren

In Raspbian Buster wird empfohlen, eine IPv4-Konfiguration über den DHCP Client Daemon (DHCPCD) vorzunehmen. Auch wenn der Dienst „dhcpcd“ standardmäßig aktiv sein sollte, überprüfen wir zunächst, ob „dhcpcd“ läuft:

systemctl status dhcpcd

Der Befehl sollte „dhcpcd“ als installiert und aktiv zurückmelden. Anschließend die Datei „/etc/dhcpcd.conf“ öffnen:

sudo nano /etc/dhcpcd.conf

Weiter unten in der Datei befindet sich bereits eine beispielhafte Konfiguration für eine statische IP. Dort müsst ihr bei den folgenden vier Zeilen das „‚#“ entfernen und die IP-Daten anpassen. Achtet dabei darauf, dass ihr keine IP-Adresse verwendet, die sich im Pool des DHCP-Servers befindet.

interface eth0
static ip_address=192.168.178.100/24
static routers=192.168.178.1
static domain_name_servers=192.168.178.1 8.8.8.8

Nachdem die Änderungen vorgenommen wurden, kann die Datei mit STRG + O gespeichert und mit STRG + X geschlossen werden.

Zum Schluss müssen die Änderungen noch angewandt werden. Da wir via SSH auf den Pi verbunden sind, ist die beste Variante einfach einen Neustart durchzuführen.

sudo reboot

Shell-Konfigurationen

Zum bequemeren Arbeiten können in der „.bashrc“ noch weitere Aliase aktiviert werden.

nano ~/.bashrc

Folgende drei Aliase sind bereits vorhanden und müssen lediglich auskommentiert werden:

# some more ls aliases
alias ll='ls -l'
alias la='ls -A'
alias l='ls -CF'

Des Weiteren arbeite ich gerne mit „vim“. Da der Texteditor standardmäßig nicht vorhanden ist, muss dieser nachinstalliert werden:

sudo apt install vim

Anschließend aktiviere ich das Syntax-Highlighting und die Unterstützung für dunklen Hintergrund:

sudo nano /etc/vim/vimrc

Dort bei folgenden zwei Optionen das “ entfernen:

" Vim5 and later versions support syntax highlighting. Uncommenting the next
" line enables syntax highlighting by default.
syntax on

" If using a dark background within the editing area and syntax highlighting
" turn on this option as well
set background=dark

Stromverbrauch verringern

In meinem Artikel „Raspberry Pi – Ein Blick auf den Stromverbrauch“ habe ich den Stromverbrauch genauer unter die Lupe genommen. Außerdem habe ich dort einige Tipps aufgeführt, wie ihr den Stromverbrauch verringern könnt.

Firefox 62 – Die Neuerungen

Bereits am 5. September hat Mozilla Firefox 62 veröffentlicht. Die neue Version bietet einige Änderungen und Neuerungen. Wie immer liste ich die wichtigsten nachfolgend auf:

  • Tracking-Schutz ist per Klick auf das Info-Symbol in der Adressleiste erreichbar
    Firefox 62 Trackingschutz
  • Ebenfalls neu: eine Schaltfläche zum Löschen aller Cookies und Websitedaten der aktuell besuchten Webseite
  • Dialog zum Speichern von Lesezeichen zeigt nun Favicon und Vorschau der Webseite
  • mehr Anpassungsmöglichkeiten für die Firefox-Startseite ()
  • nach dem Abmelden von Firefox Sync wird gefragt, ob Daten wie Chronik und Lesezeichen gelöscht oder beibehalten werden sollen
  • Unterstützung für variable Schriften
  • Neue Enterprise Policies
  • weitere kleine Verbesserungen, eine komplette Übersicht aller Änderungen und Neuerungen findet ihr wie immer bei Sören Hentzschel
  • Behebung diverser Sicherheitslücken

Download Firefox 62 (64 Bit)
Portable Firefox @ Horst Scheuer

Firefox 60 – Die Neuerungen

Firefox Logo 57+

Firefox 60 wurde gestern am 09. Mai 2018 veröffentlicht. Neben der normalen Version gibt es auch eine neue ESR-Version (Extended Support Release) mit verlängertem Support. Firefox 60 ESR löst Firefox 52 ESR ab und beinhaltet die Vorzüge der Quantum-Verbesserungen. Darüber hinaus ist die versprochene Policy-Engine enthalten, wodurch sich Firefox besser in Unternehmen einsetzen lassen soll.

  • Policy-Engine zur Verteilung von Unternehmensrichtlinien
  • Firefox-Startbildschirm überarbeitet: weitere Optionen um Ansicht zu individualisieren, responsives Layout, mehr Inhalte auf breiten Bildschirmen, „gesponsorte Inhalte“ in US-Version
  • Quantum CSS wird zum Rendern des Browser-UIs genutzt
  • Überarbeitete Ansicht der Optionen zu Cookies und Webseitendaten
  • Unterstützung für das Web-Authentication-API, ermöglicht Authentifizierung an Webseiten mit Hilfe von USB-Tokens (kompatible Hardwaretoken nach FIDO U2F-Konvention sind von Yubikey, Nitrokey oder U2F Zero erhältlich)
  • Symantec-Zertifikate, die vor dem 01.06.2016 ausgestellt worden sind, werden nicht mehr akzeptiert
  • Firefox deaktiviert Webcam und dazugehöriges Licht beim Beenden einer Videoaufnahme
  • Warnhinweise beim Besuch von unverschlüsselten Webseiten im privaten Modus
  • Verbesserte Audioübertragung per WebRTC unter Linux
  • weitere kleine Verbesserungen, eine komplette und sehr ausführliche Übersicht aller Änderungen und Neuerungen findet ihr wie immer auf der Webseite von Sören Hentzschel
  • Behebung diverser Sicherheitslücken

Download Firefox 60 (64 Bit)
Download Firefox 60 ESR (64 Bit)
Portable Firefox @ Horst Scheuer

Firefox 59 – Die Neuerungen

Firefox Logo 57+

Nach dem großen Update auf Firefox 57 und einigen Anpassungen bzw. Verfeinerungen in der folgenden Version 58, geht es Mozilla mit Firefox 59 langsamer an. Firefox 58 wurde gestern am 13. März 2018 veröffentlicht und bietet folgende Neuerungen:

  • Im privaten Modus werden weniger Referrer im HTTP-Header versendet
  • Screenshot-Funktion (in Firefox 56 eingeführt) bietet nun einen Editor mit ein paar grundlegenden Funktionen (Zuschneiden, Zeichen- sowie Textmarker-Werkzeug mit neun Farben)
  • Verfeinerte Kontrolle von Web-Benachrichtigungen
  • „Firefox Health Report“ wurde aufgrund zu weniger Nutzer entfernt und die Funktionalität von „about:healthreport“ nach „about:telemetry“ umgezogen.
  • Auf der neuen Startseite kann die Reihenfolge „Wichtigen Seiten“ nun per Drag-and-Drop angepasst werden
  • Neue Startseite soll nun deutlich schneller laden als bisher, wenn viele verschiedene Informationen angezeigt werden
  • Verbessertes Rendering unter macOS dank Off-Main-Thread Painting (OMTP)
  • Neue Suchmaschine „Ecosio“ hinzugefügt (nur für Nutzer der deutschsprachigen Version)
  • Suchmaschine Yahoo! für alle Sprachen entfernt
  • Verbesserte Performance dank Race Cache With Network (RCWN) (bei langsamen Cache-Zugriffen wird parallel eine Anfrage an das Netzwerk gesendet und die Quelle genutzt, welche als erstes eine Antwort liefert)
  • Nutzung von TCP Fast Open unter Windows
  • Genauigkeit der Timing-Funktionen auf 2ms reduziert, als Gegenmaßnahme zur CPU-Schwachstelle Spectre (Firefox 57.0.4 hatte die Genauigkeit bereits von 5μs auf 20μs reduziert)
  • Zahlreiche neue Möglichkeiten und Verbesserungen bei WebExtensions
  • viele weitere kleine Verbesserungen, eine komplette Übersicht aller Änderungen und Neuerungen findet ihr wie immer bei Sören Hentzschel
  • Behebung diverser Sicherheitslücken

Download Firefox 59 (64 Bit)
Portable Firefox @ Horst Scheuer

Firefox 60 kommt mit Enterprise-Policies

Firefox Logo 57+

Firefox bringt von Haus aus keine Unterstützung für die Konfiguration via Gruppenrichtlinien mit. Aus diesem Grund berichtete ich kürzlich über zwei gängige Möglichkeiten, wie sich Firefox-Einstellungen per Gruppenrichtlinien steuern lassen.

Jetzt kommt Bewegung in das Thema, denn Mozilla möchte den Browser fit für Unternehmen machen. Im nächsten Extended-Support-Release (ESR) soll Firefox eine Policy-Engine enthalten. Ursprünglich war die nächste ESR-Version für Firefox 59 geplant, wurde mittlerweile aber auf Version 60 verschoben, um mehr Zeit für die Implementierung der Enterprise-Policies zu haben. Der geplante Releasetermin ist der 8. Mai 2018.

Durch die Policy-Engine soll die Verteilung von Unternehmensrichtlinien ermöglicht werden. Da Mozilla eine universelle Lösung für alle Betriebssysteme entwickeln möchte, wird vorerst keine direkte Unterstützung für Windows-Gruppenrichtlinien geboten. Vielmehr werden die Einstellungen mit Hilfe einer JSON-Datei verteilt, die dann durch die Richtlinien-Engine ausgewertet und angewendet werden. Im Mozilla-Wiki existiert bereits ein Artikel mit weiteren Details zur Umsetzung und Konfiguration. Darauf aufbauend sollen später dann auch zusätzliche Funktionen von Betriebssystemen unterstützt werden, also z.B. Windows-Gruppenrichtlinien.

Ich bin gespannt wie Mozilla das Thema weiter ausbaut. Anfangs wird man sich auf wenige Funktionen beschränken. Beispielsweise soll es möglich sein, den Zugriff auf die Konfigurationsseiten „about:config“ oder „about:addons“ zu unterbinden oder Funktionalitäten wie Pocket und Screenshots zu deaktivieren. Bei der weiteren Entwicklung der Policy-Engine möchte Mozilla die Möglichkeiten deutlich ausbauen. Ebenso möchte man bei der Weiterentwicklung auch das Feedback von Nutzern mit einfließen lassen. Obwohl man das Thema Jahre verschlafen hat, scheint man mit der vorläufigen Planung auf einem guten Weg zu sein um auch bei Unternehmen wieder Fuß fassen zu können.

Firefox 58 – Die Neuerungen

Firefox Logo 57+

Am 23. Januar 2018 hat Mozilla Firefox 58 veröffentlicht. Nach dem wohl größten Update (Firefox 57) in der Geschichte von Firefox geht es der Hersteller in der neuen Version etwas langsamer an. Dennoch bringt Version 58 einige Neuerungen und Performanceverbesserungen.

  • optimiertes Caching für JavaScript sorgt für höhere Performance
  • schnelleres Rendern von Grafiken und Webseiten unter Windows durch Off-Main-Thread Painting (OMTP)
  • Benutzerprofile die mit Firefox 58 erzeugt werden, sind mit älteren Browserversionen nicht mehr kompatibel
  • Screenshot-Funktion bietet nun die Möglichkeit Screenshots direkt in die Zwischenablage zu kopieren und funktioniert nun auch im Private-Modus
  • Unterstützung für Autofill bei Kreditkarteninformationen
  • WebVR-Unterstützung für Apple macOS
  • Warnung wenn Webseiten Symantec-Zertifikate einsetzen (ab Firefox 60 werden keine Symantec-Zertifikate mehr akzeptiert, die vor dem 01.06.2016 ausgestellt worden sind, ab Firefox 63 überhaupt keine Symantec-Zertifikate mehr, dies betrifft auch Zertifikate von Thawte, VeriSign, Equifax, GeoTrust sowie RapidSSL, da diese zu Symantec gehören)
  • Root-Zertifikate von StartCom und WoSign entfernt
  • viele weitere kleine Verbesserungen, eine komplette Übersicht aller Änderungen und Neuerungen findet ihr wie immer bei Sören Hentzschel
  • Behebung diverser Sicherheitslücken

Download Firefox 58
Download Firefox 58 (64 Bit)
Portable Firefox @ Horst Scheuer