Heiko Zimmermann
SAP-Berater, System Engineer und Entwickler.

Weblog

23. Juli 2019, 12:47

Jetzt bin ich bereits das zweite Mal darüber gestolpert, dass ich nach einem Upgrade von Debian bzw. von Armbian folgenden Fehler bekam:

WARN: initcaps
[Errno 2] iptables: Operation not supported.

Die Lösung ist schnell erledigt:

update-alternatives --config iptables

  Auswahl      Pfad                       Priorität Status
------------------------------------------------------------
* 0            /usr/sbin/iptables-nft      20        automatischer Modus
  1            /usr/sbin/iptables-legacy   10        manueller Modus
  2            /usr/sbin/iptables-nft      20        manueller Modus

Drücken Sie die Eingabetaste, um die aktuelle Wahl[*] beizubehalten,
oder geben Sie die Auswahlnummer ein: 1

Auswahl: 1 (iptables-legacy)

Danach wollten ufw bzw. firetable wieder arbeiten.

1. Juni 2019, 16:09

In den letzten Jahren hatte ich meine Server und vServer meist bei Hetzner. Ich war immer sehr zufieden und bin es auch noch immer.

Aus verschiedenen Gründen wollte ich die Ping-Zeiten drücken, die Server näher am DE-CIX und mehr als eine IPv4 am vServer haben.

Nachdem ich mehrere Anbieter, mehr oder weniger erfolgreich, getestet habe, war für mich ip-projects.de die richtige Wahl. Laut eigenen Angaben haben die, außer mir, gerade zwei weitere OpenBSD Kunden. Und dennoch läuft in deren XEN-Umgebung alles prima. Man bekommt bis zu 5 IPv4 kostenfrei und nahezu beliebig viele Ipv6. Der DDoS-Schutz ist von voxility.

Den Netzwerk Uplink kann man bei Bedarf erhöhen. Der Support ist vorbildlich und als einzige Einschränkung ist zu nennen, dass IPv6 kein ganzes Netz ist, sondern die IPs einzeln geroutet und gebunden werden.

Bei meinem 6.5-Current mochte lediglich eine Einzige arbeiten. Bisher hatte ich keine Zeit und Lust das genauer zu untersuchen. Wer eine Lösung kennt, darf sie mir gerne sagen. :)

Ich habe noch eine paar Dinge in der sysctl.conf angepasst und bin Preis-Leistung und Service sehr zufrieden. Danke an IP-Projects.

Leider muss man ja das jetzt immer sagen, ich bezahle meine Leistung voll und erhalte nichts dafür, dass ich die Firma positiv erwähne. Ich bin einfach ein sehr zufriedener Kunde.
 

5. März 2019, 23:04

Heute habe ich meine Server mit QualysGuard VM gescannt. Bei OpenSMTPD ist TLSv1 in der Standardeinstellung möglich, was beim Scan angemahnt wird.

In /etc/mail/smtpd.conf brachte folgende Option gute Ergebnisse:

smtp ciphers "HIGH:!aNULL:!TLSv1:!MD5:!RC4:!GOST89MAC:@STRENGTH"

TLSv1 wurde deaktiviert. MD5 und RC4 habe ich explizit nochmal deaktiviert, um sicher zu gehen. GOST wurde diese Tage kritisch hinterfragt, deshalb habe ich es vorsorglich deaktiviert. @STRENGTH schlägt die sichersten Cipher in absteigender Reihenfolge vor.

23. Februar 2019, 10:38

Ich habe bei edis.at seit 2013 einen kleinen Raspberry Pi Model B Rev 2 als VPN-Server.

Bisher läuft OpenVPN darauf. Allerdings, durch die schwache Hardware, wenig performant. Da liegt es nahe, dass ich mir WireGuard als Alternative ansehe. Da WireGuard als Linux-Kernelmodul läuft gibt es unter Linux einen Performance-Schub. Das gilt entsprechend nicht für wireguard-go Implementierungen. Diese soll man unter Linux auch dringend vermeiden.

Ich habe einmal für meine Geräte etwas verglichen. Mein MacOS zu OpenBSD (beide wireguard-go) ist mit WireGuard langsamer, als mit OpenVPN (AES-NI mit nur AES-128-CBC). Mein Pine64 mit Ambian (Kernelmodul) zu OpenBSD (wireguard-go) ist schneller mit WireGuard, als mit OpenVPN. Mein iOS (APP, kein Kernelmodul) zu OpenBSD (wireguard-go) ist mit OpenVPN (AES-NI) schneller, als mit WireGuard. Dafür gewinnt WireGuard beim Verbindungsaufbau um Längen und kann problemlos VPN-On-Demand. Es lohnt sich selbst zu testen.

Der übliche Weg am Raspberry Pi ist: "deb http://deb.debian.org/debian/ unstable main" einzubinden und WireGuard normal zu installieren.

Leider macht mir da Debian einen Strich durch die Rechnung. Denn bei wg bekomme ich "segmentation fault". Die Ursache ist, dass mein kleiner Pi nur eine "ARMv6"-CPU besitzt und Debian Binär-Pakete für "ARMv7a" liefert.

Zur Lösung kompiliere ich WireGuard aus der Source selbst:

sudo apt install libmnl-dev build-essential git raspberrypi-kernel-headers qrencode
git clone https://git.zx2c4.com/WireGuard
cd WireGuard/src
make
sudo make install
sudo modinfo wireguard
sudo modprobe wireguard

Danach konnte ich WireGuard wie gewohnt benutzen

Nun zum Ergebnis. Mit OpenVPN vom Pine64 (Armbian) zum Raspberry Pi Model B Rev 2 (Raspbian) erreichte ich im Durchschnitt 8500 kbit/s. Mit WireGurad erreichte ich im Durchschnitt 21000 kbit/s. Ich bin beeindruckt.

Abschließend sei noch ausdrücklich erwähnt, dass WireGuard zwar vielversprechend ist, sich dennoch in der Entwicklung befindet und experimentell ist. Hierzu einige Überlegungen vom VPN-Anbieter Perfect-Privacy.

PS: qrencode ist nicht nowendig, nur angenehmer, um die Konfiguration in der iPhone-App einzulesen:
qrencode -t ansiutf8 < mobile.conf

Update:
"Warning: modules_install: missing 'System.map' file. Skipping depmod."
kann ignoriert werden.

Nach einem Kernel-Update muss Wireguard neu gebaut werden.

Im Hiawatha Webserver <= 10.8.3 befindet sich eine Sicherheitslücke, die umgehend mit der Version 10.8.4 geschlossen wurde.

Die Lücke wurde nur aktiv, wenn man die Standardoption für "AllowDotFiles" manuell auf "yes" geändert hat. Default ist "no".

Bitte dringend auf die aktuelle Version updaten.

Vielen Dank an Paul Bernal und das Audit-Team, die viel Zeit und Arbeit investiert haben. Und vielen Dank an den Entwickler Hugo Leisink, dass trotz intensiven Suchens nur eine einzige Lücke in Hiawatha gefunden wurde. Hiawatha ist und bleibt mein Lieblings-Webserver.