ubuntuusers.de

Alexa, Siri, Google, Cortana – Spracherkennung ist in aller Munde. Und in den festen Händen kommerzieller Anbieter. Dies macht Mozillas Common Voice-Projekt so wichtig. Mozilla hat Common Voice auf Deutsch gestartet und benötigt nun eure Hilfe, um auch auf Deutsch eine hochwertige Sprachdatenbank für jeden zur Verfügung stellen zu können.

Mozilla Common Voice-Webseite aufrufen

Mozillas Arbeit im Gebiet der Spracherkennung kann neben der Arbeit an Firefox durchaus zu einem der wichtigsten Projekte der Not-for-Profit-Organisation Mozilla gezählt werden. Immer mehr Geräte sind miteinander vernetzt und lassen sich über Sprache steuern. Was vor Jahren noch nach Science Fiction geklungen hätte, ist mittlerweile für immer mehr Menschen Realiät. Der Erfolg eines Gerätes mit Spracherkennung steht und fällt dabei natürlich vor allem mit der Qualität der Spracherkennung.

Der Markt für Spracherkennung wird von den ganz großen Namen kommerzieller Anbieter dominiert: Amazon, Apple, Google, Microsoft. Darum hat Mozilla im vergangenen Jahr das Projekt Common Voice gestartet. Mit Common Voice versucht Mozilla, eine kostenlose Alternative zu etablieren, zu der jeder beitragen kann und die jedem zur Verfügung steht, denn nach Ansicht von Mozilla sollte diese Technologie für jeden zugänglich sein und nicht den großen Anbietern vorbehalten sein. Common Voice ergänzt damit ein weiteres Projekt von Mozilla, nämlich ein Open Source Spracherkennungsmodell, welches unter dem Namen Deep Speech von Mozilla entwickelt wird.

Bislang stand Common Voice nur für englischsprachige Nutzer zur Verfügung. Nun hat Mozilla Common Voice zusätzlich in den Sprachen Deutsch, Französisch und Walisisch gestartet. Dabei wird es nicht bleiben: es sind bereits mehr als 40 weitere Sprachen in Arbeit, die bald starten sollen. Darunter sollen nicht nur am meisten verbreitete Sprachen sein, sondern auch kleinere wie unter anderem Friesisch, welche von den großen kommerziellen Anbietern häufig vernachlässigt werden.

Technik alleine bringt keine gute Spracherkennung, dafür braucht es vor allem eine große Datenmenge an Sprachaufnahmen. Und an dieser Stelle kommt die Community ins Spiel: über die Webseite oder die iOS-App kann jeder helfen, indem er oder sie die Sätze in das Mikrofon seines Computers spricht, oder die Sätze anderer auf Korrektheit überprüft.

Optional kann ein Profil auf der Webseite angelegt werden, um mit Angaben über Akzent, Alter und Geschlecht eine bessere Zuordnung der Sprachaufnahmen zu ermöglichen.

Seit dem Start von Common Voice vor gut einem Jahr wurden bereits mehrere hunderttausend englischsprachige Aufnahmen gesammelt und im November 2017 schließlich eine erste Version des Datensatzes kostenlos bereitgestellt – was zu dem Zeitpunkt bereits den zweigrößten öffentlichen Datensatz für Sprachaufnahmen dargestellt hat. Mozillas Arbeit im Bereich der Spracherkennung wird bereits von Open Source-Projekten wie Kaldi aber auch von kommerziellen Produkten wie Mycroft genutzt.

Mozilla Common Voice-Webseite aufrufen

Der Beitrag Mozilla startet Common Voice auf Deutsch erschien zuerst auf soeren-hentzschel.at.

Einleitungsbild: © Rogatnev / Fotolia.com

Die mediale Aufmerksamkeitsspanne ist kurz, Sicherheitslücken sind langlebig. Die Berichterstattung mag abgeklungen sein, aber EFAIL hat nichts von seiner Brisanz verloren. GnuPG erhält nun allerdings ein Update, womit mittelfristig Besserung in Aussicht steht, da GnuPG als zentrale Instanz in vielen Programme fungiert.

Das Update verschärft die Integritätsprüfung (MDC), die bisher nur optional war. So viel im übrigen zu der Verteidigungslinie, dass es sich lediglich um ein clientseitiges Problem handelt (siehe: Kommentar: EFAIL - Nebelkerzen und was ist eigentliche eine Lücke?).

Sobald alle Clients bzw. Addons für Outlook & Co nachgezogen haben, dürfte die Lücke etwas weniger kritisch sein. Grundsätzlich behoben ist sie jedoch nicht. Weiterhin ist vollkommen unklar, ob der ebenfalls schwer beschädigte S/MIME Standard aktualisiert wird. Dieser ist standardmäßig in quasi allen Mailprogramme enthalten und insbesondere im Businessumfeld verbreitet.

Ehrlich gesagt ist diese Woche (außer der "einschlagenden" ersten Meldung) nicht viel passiert. Trotzdem ein kleiner Überblick:

• Letzte Woche schon vermutet, wurde es Montag nun verkündet: GitHub wurde von Microsoft gekauft. Neuigkeiten gab es nun von der Linux Foundation (deren "Chef" immerhin Git entworfen hat), die dazu Stellung nimmt und sich über die Übernahme offenbar erfreut zeigt.
• Der Rundfunkbeitrag könnte schon bald an die Inflation gekoppelt sein. Warte, wozu haben wir die dann überhaupt noch?
• Noch mehr Microsoft: das Unternehmen versucht immer weiter seine Kühlung zu optimieren. Neuste Idee: RZs im Meer versenken.
• Die USA haben wieder den schnellsten Supercomputer.
• Diese Woche wurde außerdem der legendäre 8086er-Prozessor 40 Jahre alt.
• Der Yahoo Messenger wird eingestellt.

Ehrlich gesagt ist diese Woche (außer der "einschlagenden" ersten Meldung) nicht viel passiert. Trotzdem ein kleiner Überblick:

• Letzte Woche schon vermutet, wurde es Montag nun verkündet: GitHub wurde von Microsoft gekauft. Neuigkeiten gab es nun von der Linux Foundation (deren "Chef" immerhin Git entworfen hat), die dazu Stellung nimmt und sich über die Übernahme offenbar erfreut zeigt.
• Der Rundfunkbeitrag könnte schon bald an die Inflation gekoppelt sein. Warte, wozu haben wir die dann überhaupt noch?
• Noch mehr Microsoft: das Unternehmen versucht immer weiter seine Kühlung zu optimieren. Neuste Idee: RZs im Meer versenken.
• Die USA haben wieder den schnellsten Supercomputer.
• Diese Woche wurde außerdem der legendäre 8086er-Prozessor 40 Jahre alt.
• Der Yahoo Messenger wird eingestellt.

Bild von 3dman_eu via pixabay / Lizenz: CC0 Creative Commons

Die beherrschenden Technikthemen unterliegen einem schnellen Wandel. Vor wenigen Jahren war Cloud das alles beherrschende Thema, nun liest man überall von künstlicher Intelligenz. Manche mögen dabei an Roboter und den legendären Terminator denken, aber die Themen sind inzwischen viel greifbarer.

Bei den proprietären Betriebssystemen gewinnen so genannte selbstlernende Systeme immer mehr an Bedeutung. Dabei geht es nicht nur um die smarte Sprachsteuerung durch Siri & Co, sondern auch um maschinelles Lernen. Ganz praktisch kann man das bei Software wie Pixelmator Pro auf macOS betrachten, bei dem das Programm mit der Zeit Motive selbstständig erkennt und in Ebenen einteilt. Andere Funktionen sind die Steuerung per Gesichtserkennung oder auch nur Spielereien wie Animojis. Hinzu kommen eigene Geräteklassen mit smarten Funktionen, oftmals zusammengefasst im Bereich IoT. Der Fantasie sind jedoch fast keine Grenzen gesetzt, die Entwicklung verläuft rasant und lässt sich kaum vorher sagen.

Die Implikationen hinsichtlich des Datenschutzes sind unterschiedlich. Wenn diese Systeme die notwendige Leistung per Cloudanbindung extern auslagert ist das ein erhebliches Problem - nicht zuletzt wegen des quasi unbeschränkten Zugriffs auf die Daten. Noch schlimmer ist das, wenn die Geräte von Firmen kommen, die exzessives Datensammeln zum Geschäftsmodell erhoben haben. Hier dürfte eine Zusammenführung und Auswertung der Daten fest im Geschäftsmodell verankert sein. Manche Firmen wie Apple haben dies erkannt und verlagern deshalb die Verarbeitung zunehmend auf das Gerät und geben sich ein bewusst datenschutz-freundliches Image.

Die ganze Entwicklung passiert jedoch bisher vor allem im Kreis der Anbieter proprietärer Systeme. Manche Firmen positionieren sich datenschutzfreundlicher als andere, aber letztlich müssen wir ihnen immer vertrauen. Viele dieser Geräte lassen nur noch minimale haptische Benutzerinteraktion zu, weshalb man kaum kontrollieren kann, was der kleine Kasten so macht. Das ist bei klassischen Betriebssystemen schon problematisch, aber wenn man bedenkt, in welche Richtung sich smarte Geräte mit KI entwickeln (siehe auch: Kommentar: Der Siegeszug der smarten Lautsprecher) waren die früheren Debatten wie Microsoft vs. Linux harmlos.

Die Open Source-Gemeinschaft konnte bisher mit dieser Entwicklung überhaupt nicht Schritt halten. Schon Spracherkennung wie beispielsweise Simon ist auf dem Linux-Desktop im experimentellen Stadium, von weiterführenden Funktionen ganz zu schweigen.

Sehen wir hier die Grenzen des Open Source Entwicklungsmodells? Open Source hat großartiges hervorgebracht, nicht zuletzt Linux als universales Betriebssystem. Dazu hat man gar nicht so lange gebraucht, bereits um 2006 herum hatte man in vielen Bereichen aufgeholt zur proprietären Konkurrenz. GNU/Linux ist jedoch - abgesehen vom Kernel - vor allem die Komposition vieler kleiner Einzelprojekte mit wenigen Entwicklern. Großprojekte mit zahlreichen Entwicklern sind absolute Mangelware, selbst die großen Desktopprojekte KDE und GNOME sind in Subprojekte gegliedert, die nicht immer reibungslos miteinander interagieren.

Dieses Entwicklungsmodell hat für die Welt klassischer Betriebssysteme mit letztlich doch limitierten Funktionen ausgereicht. Möglicherweise lässt sich mit diesen beschränkten Ressourcen nicht mit dieser Entwicklung Schritt halten. Im mobilen Sektor kann man ähnliche Schwierigkeiten beobachten (siehe: Freie Mobilbetriebssysteme - Ein Trauerspiel). Namhafte Open Source-Player wie beispielsweise Red Hat fokussieren sich zudem inzwischen immer stärker auf den Cloud- und Serverbereich, während die - bisher sichtbaren - Entwicklungen im KI-Sektor eindeutig Consumerbereich verortet sind.

Sofern sich nicht ein Sponsor findet, der entweder die Entwicklung freier Alternativen massiv fördert oder bestehende Entwicklungen öffnet, muss man wohl fürchten, dass hier der Anschluss verloren geht.

Bild von mcmurryjulie via Pixabay / Lizenz: CC0 Creative Commons

Smarte Lautsprecher sind hinsichtlich des Datenschutzes eine unfassbare Katastrophe. Faktisch handelt es sich dabei um eine Wanze, die permanent in den Raum horcht und auf ein Signalwort hin aktiv wird. Bisher gibt es ausschließlich proprietäre Lösungen, weshalb eine transparente Analyse der Funktionen unmöglich ist. Der erzwungene Cloudzugang ist unkontrollierbar.

Hinzu kommt, dass bisher fast alle verbreiteten Lösungen von den größten Datenkraken entwickelt und dann zu Dumpingpreisen auf den Markt geworfen werden - ein Schelm der dahinter anderweitigen Profit vermutet.

Die neuen Lautsprechen waren hier bereits letztes Jahr Thema (siehe: Wanzen für das Wohnzimmer mit Firmen-Branding). Damals konnte man noch hoffen, dass die Geräte sich außerhalb eines kleinen Kreises technischer Enthusiasten nicht verbreiten würden. Die Kampfpreise von Amazon haben jedoch eine erhebliche Verbreitung gefördert und inzwischen integrieren auch immer mehr Anbieter Amazons und Googles Lösungen in ihre Geräte.

Das Ausmaß der Datenschutz-Katastrophe ist eigentlich kaum zu beschreiben. Diese Geräte sind nämlich eigentlich nicht smart, sondern immer noch unfassbar dumm. Das liegt einfach am Stand der KI-Forschung. Kurz gesagt: Fällt das Schlüsselwort, springt das Gerät an. Der Lautsprecher kann nämlich nicht unterscheiden, ob er gemeint ist oder eventuell nur über ihn gesprochen wird. Mal abgesehen davon, dass z. B. Alexa in manchen Ländern auch einfach ein gängiger Vornahme ist.

Hinzu kommt, dass die Geräte scheinbar mit der heißen Nadel entworfen wurden - oder die dahinter stehenden Firmen Datenschutz und -sicherheit keine besondere Priorität beimessen. Anders kann man die nicht abreißenden Meldungen über ungewollte Datenübertragung nicht interpretieren. So versendet Alexa auch mal Privatgespräche oder die Konkurrenzlösung interpretiert das Signalwort sehr weitläufig.

Die obligatorische Cloudanbindung und massenhafte Datenversand an Herstellerserver ist selbstverständlich. Keine der Lösungen besitzt genug Leistung um die notwendigen KI-Vorgänge auf dem Gerät vorzunehmen.

Im Grunde genommen kann man nur fassungslos sein bei diesen Geräten. Wer sich so etwas freiwillig in die Wohnung stellt scheint jeden Bezug zu Datenschutz verloren zu haben. Als Google vor einigen Jahren mit der Google Glass experimentierte, gab es unzählige Debatten, wo man die Brille tragen darf und wo nicht. Manche Betreiber wollten Leute mit der Brille nicht in ihre Cafés und Kneipen lassen.

Im politischen Diskurs bezeichnete man das permanente Überschreiten roter Linien, als kalkulierten Tabubruch. Nichts anderes machen die großen IT-Giganten: Permanente Missachtung des Datenschutzes und unzählige Debatten bis die Öffentlichkeit völlig abgestumpft ist und eine Wanze im Wohnzimmer auch noch als technische Errungenschaft feiert.

New Tab Override ist eine Erweiterung zum Ersetzen der Seite, welche beim Öffnen eines neuen Tabs in Firefox erscheint. Die beliebte Erweiterung mit mehr als 140.000 aktiven Nutzern ist nun in Version 13.0 erschienen.

Was ist New Tab Override?

Seit Firefox 41 ist es nicht länger möglich, die Seite anzupassen, welche beim Öffnen eines neuen Tabs erscheint, indem die Einstellung browser.newtab.url über about:config verändert wird. Da diese Einstellung – wie leider viele gute Dinge – in der Vergangenheit von Hijackern missbraucht worden ist, hatte sich Mozilla dazu entschieden, diese Einstellung aus dem Firefox-Core zu entfernen. Glücklicherweise hat Mozilla nicht einfach nur die Einstellung entfernt, sondern gleichzeitig auch eine neue API bereitgestellt, welche es Entwicklern von Add-ons erlaubt, diese Funktionalität in Form eines Add-ons zurück in Firefox zu bringen.

New Tab Override war das erste Add-on, welches diese Möglichkeit zurückgebracht hat, und ist damit das Original. Mittlerweile hat New Tab Override mehr als 140.000 aktive Nutzer, wurde im Dezember 2016 sogar auf dem offiziellen Mozilla-Blog vorgestellt und schon mehrfach im Add-on Manager von Firefox beworben.

Download New Tab Override (WebExtension) für Firefox

Die Neuerungen von New Tab Override 13.0

Eine Änderung in Firefox 60 hat verursacht, dass die Option, eine komplett leere Seite als neuen Tab anzuzeigen, nicht mehr ordnungsgemäß funktioniert hat. Statt einer leeren Adressleiste stand in jedem neuen Tab „about:blank“ in der Adressleiste. Es wurde ein Workaround implementiert, welcher dieses Problem umgeht.

Ein weiteres Problem dieser Option war, dass diese nicht funktioniert hat, wenn das URL-Feld der Option „Benutzerdefinierte Adresse“ nicht leer war. Dies konnte zum Beispiel dann auftreten, wenn der Nutzer zunächst eine benutzerdefinierte URL als neuen Tab ausgewählt hatte und später dann auf „about:blank“ gewechselt ist, ohne das URL Feld vorher zu leeren. Auch dieses Problem wurde behoben.

Neben all den funktionalen Optionen gab es in New Tab Override auch eine Pseudo-Option „Standard-Seite für den neuen Tab“, welche dem Nutzer erklärt hat, dass zur Verwendung dieser Seite die Erweiterung im Add-on Manager deaktiviert werden muss. Diese Pseudo-Option wurde mit dem Update entfernt und Nutzer, welche diese Option ausgewählt hatten, automatisch zu „about:blank“ migriert.

Ein Danke geht nach China an den neuen Contributor tiansh, welcher die Lokalisierungs-Architektur so verbessert hat, dass bessere Übersetzungen in andere Sprachen möglich sind, in denen die Satzstellung von der verwendeten Satzstellung abweicht.

Eben jener tiansh war es auch, der die chinesische Übersetzung wieder zurück nach New Tab Override gebracht hat. Das ist großartig, weil chinesische Nutzer im Ranking der Nutzer von New Tab Override auf Platz 4 stehen. Weitere Dankeschöns gehen an MissingUser für die spanische Übersetzung sowie an Sopor- für die schwedische Übersetzung. Damit steht New Tab Override derzeit in zehn Sprachen zur Verfügung – und weitere werden kommen!

Außerdem wurden mit dem Update wieder sämtliche Abhängigkeiten auf den neuesten Stand gebracht. Neue Mindestanforderung ist Firefox 60, ältere Firefox-Versionen werden von New Tab Override nicht länger unterstützt.

Der Beitrag New Tab Override 13.0 (WebExtension) veröffentlicht erschien zuerst auf soeren-hentzschel.at.

Mozilla hat mit Firefox 60.0.2 ein Update für Firefox 60 veröffentlicht und behebt damit eine Sicherheitslücke sowie mehrere Probleme der Vorgängerversion.

Download Mozilla Firefox 60.0.2 für Microsoft Windows, Apple macOS und Linux

Mit dem Update auf Firefox 60.0.2 behebt Mozilla eine Sicherheitslücke in Zusammenhang mit SVG-Grafiken. Ein Update ist daher bereits alleine aus Gründen der Sicherheit für jeden Nutzer ratsam.

Außerdem behebt Mozilla ein Problem mit der Darstellung von Schrift, welches ausschließlich Nutzer von Apple OS X 10.11 und älteren Versionen betrifft, die außerdem eine Drittanbieter-Software zur Schrift-Verwaltung auf dem Computer installiert haben.

Darüber hinaus wurde ein Fehler in den Entwicklerwerkzeugen behoben, der verursachte, dass unter bestimmten Umständen Elemente, teilweise sogar der komplette Inhalt des body-Elements, im Inspektor fehlen konnten.

Weiter wurde die sporadisch auftretende Fehler-Meldung SSL_RX_MALFORMED_SERVER_HELLO behoben, welche auf Webseiten auftreten konnte, die auf den Sicherheits-Standard TLS 1.3 aktualisiert haben.

Schließlich wurde noch ein Hängenbleiben des Browsers bei Verwendung eines Gerätes zur Zwei-Faktor-Authentifizierung behoben. Dieses Problem betraf ausschließlich Nutzer des Apple-Betriebssystems.

Der Beitrag Mozilla veröffentlicht Sicherheits- und Bugfix-Update Firefox 60.0.2 erschien zuerst auf soeren-hentzschel.at.

CloudPets sind sogenannte smarte Plüschtiere. Das Spielzeug kann Sprachaufnahmen machen und ist mit dem Internet verbunden. Auf Druck von Mozilla haben diverse Online-Händler wie Amazon den Verkauf nun aufgrund von Sicherheits-Defiziten gestoppt.

Die smarten Plüschtiere CloudPets haben bereits in der Vergangenheit negative Schlagzeilen gemacht. So erlangten im Februar 2017 Angreifer Zugriff auf die Datenbank der Herstellerfirma und damit auf E-Mail-Adressen, Passwörter, Profilbilder sowie Sprachaufzeichnungen von Kindern. Betroffen waren damals 800.000 Kunden, sogar Lösegeld-Forderungen gab es in mehreren Fällen.

Die US-Ketten Walmart und Target sowie Amazon haben den Verkauf der CloudPets nun gestoppt, um einer Kampagne von Mozilla zuvorzukommen. Anlass hierfür ist eine Sicherheits-Prüfung, welche Mozilla beim deutschen Sicherheits-Dienstleister Cure53 in Auftrag gegeben hat, mit denen Mozilla häufiger im Rahmen seines Secure Open Source-Programms zusammenarbeitet. Demnach seien Sicherheitslücken, welche dem Hersteller bereits vor mehr als einem Jahr gemeldet worden sind, immer noch vorhanden.

Während Amazon in den USA keine CloudPets-Plüschtiere mehr anbietet, sind diese über die deutsche Amazon-Webseite bislang noch verfügbar. Ob Amazon auch außerhalb der USA reagieren wird, ist bislang unklar.

Der Beitrag Nach Sicherheitsprüfung von Mozilla: Amazon und weitere Händler stoppen Verkauf von CloudPets-Plüschtieren erschien zuerst auf soeren-hentzschel.at.

Mit dem Ubuntu LTS Server 18.04 wurde eine neue Langzeitversion der bekannten Distribution veröffentlicht.

Das Release wurde mit einem neuen Installer mit dem Namen Subiquity versehen und es wurden viele weitere Änderungen und Neuerungen gemacht. Die kompletten Release Notes zum Ubuntu Server 18.04 LTS gibt es hier.

Zusätzlich steht Ubuntu Server nun in einer Live ubuntu-18.04-live-server-amd64.iso und einer alternativen Version ubuntu-18.04-server-amd64.iso zur Verfügung. Der Standarddownload auf der Canonical Seite verweist auf das "live" Image. 

Doch worin unterscheiden sich die Versionen und warum hat man überhaupt zwei Server im Programm?

Der wesentliche Unterschied dieser Servervarianten besteht in den mitgelieferten Paketen und der damit verbundenen Ausrichtung. Wobei die live Variante auf Cloud Installationen ausgerichtet ist und die alternative Variante auf Standard Installationen. 

ubuntu-18.04-live-server-amd64

Die Cloud Variante beinhaltet beispielsweise das Paket cloud-init und den openssh-server. Beide werden mitausgeliefert und sind nach der Installation aktiv.

Das Paket cloud-init ist auf Anbieter wie DigitalOcean, Azure und Co Installationen spezialisiert (siehe Screenshot) , es läuft im Hintergrund und bezieht diverse Systemkonfigurationen über die Cloud.

Diverse Einstellungen lassen sich unter sudo /etc/cloud/cloud.cfg einsehen.

Eine interaktive Konfiguration ist ebenfalls möglich.

sudo dpkg-reconfigure cloud-init

Über cloud-config würden sich theoretisch wichtige Konfigurationen setzen lassen.

Die Notation ist in YAML gehalten, hier ein Beispiel:

#cloud-config
users:
  - name: Dr.Cloud
    ssh-authorized-keys:
      - ssh-rsa AAAAxxxxxx
    sudo: ['ALL=(ALL) NOPASSWD:ALL']
    groups: adm
    shell: /bin/bash
    write_files:
  - path: /etc/ssh/sshd_config
    content: |
         Port 22
         Protocol 2
         HostKey /etc/ssh/ssh_host_rsa_key
         HostKey /etc/ssh/ssh_host_ed25519_key
         PermitRootLogin no
         PubkeyAuthentication yes
         KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
         …

Zusätzlich werden bei der live Installation noch andere Partitionen angelegt und weitere Änderungen gemacht, welche ich hier nicht im Detail erwähnen möchte.

Wichtig sollte sein, dass Einstellungen wie Hostname oder feste IPs via Cloud Konfiguration gesetzt werden und sich klassisch via hostnamectl  nicht dauerhaft ändern lassen, ohne die Cloudabfrage zu deaktivieren oder anzupassen.

ubuntu-18.04-server-amd64

Die alternative Variante verhält sich etwas anders, sowohl bei der Installation, als auch bei der Konfiguration.

Canonical schreibt dazu:

The next generation Subiquity server installer, brings the comfortable live session and speedy install of Ubuntu Desktop to server users at last.

N.B., If you require LVM, RAID, multipath, vlans, bonds, or the ability to re-using existing partitions, you will want to continue to use the alternate installer which can be downloaded from http://cdimage.ubuntu.com/releases/18.04/release/

Neben klassischem LVM ist im Vergleich zur live Version beim Standardinstaller eine Language Pack language-pack-en vorinstalliert.

Für Fernwartungen muss der SSH Server manuell installiert werden.

Eine Konfiguration des Hostnamens wird auf dem bekannten Weg via hostnamectl  vorgenommen. Wie oben bereits erwähnt, würde die live Version diesen Eintrag wieder überschreiben.

Allerdings hat sich durch netplan die IP Konfiguration ebenfalls geändert und ist nun unter /etc/netplan/01-netcfg.yaml zu finden und wie der Name erkennen lässt, im YAML Format gehalten.

Fazit

Für eine normale Serverinstallation ist die Standardvariante ausreichend, denn das cloud-init Paket und einen SSH Server sollte jeder im Bedarfsfall selbst nachinstallieren können. 

Durch gängige Automatisierung bietet sich ein Cloud Initialisierung natürlich ebenfalls an, sollte die Infrastruktur dafür schon vorhanden sein.

Es ist mir allerdings ein Rätsel, warum Canonical dies auf der Downloadseite nicht klar unterscheidet und nur kurz im Text erwähnt, anstatt gleich zwei Downloadvarianten anzubieten. So werden sich die meisten erst einmal die gepushte Cloudvariante laden, um sich danach noch einmal zu belesen bzw. das cloud-init Paket wieder entfernen oder eine andere Variante laden.
Sicher gut als Lerneffekt, aber wenig zielführend.

Unter dem Namen Test Pilot betreibt Mozilla eine Möglichkeit für Firefox-Nutzer, potentielle neue Funktionen vorab zu testen und Feedback zu geben. Mit Firefox Color und Side View hat Mozilla nun zwei neue Experimente gestartet.

Über testpilot.firefox.com können Firefox-Nutzer mögliche Neuerungen vorab testen, indem entsprechende Erweiterungen installiert werden. Ab sofort stehen mit Firefox Color und Side View zwei neue Experimente zum Testen bereit.

Firefox Color

Die Theming-API von Firefox erlaubt optische Anpassungen der Firefox-Oberfläche. Doch was ist noch besser als verfügbare Themes zu durchforsten und sich davon eines auszusuchen? Die Oberfläche von Firefox selbst anzupassen. Das ist mit Mozillas neuem Experiment Firefox Color möglich.

Firefox Color kommt mit 24 vorkonfigurierten Themes, deren Farben und Textur der Anwender ganz einfach und nach Belieben selbst verändern kann.

Praktisch: mit jeder Änderung ändert sich auch die URL. Wer mit seinem Theme zufrieden ist, kann dieses ganz einfach an andere Nutzer weitergeben, indem die URL geteilt wird. Auch können erstellte Themes lokal gespeichert und zu einem späteren Zeitpunkt wieder geladen werden.

Side View

Side View erlaubt das parellele Betrachten einer zweiten Webseite innerhalb der Firefox-Sidebar. Die Seite, welche in der Sidebar geladen werden soll, kann entweder über die Schaltfläche in der Symbolleiste ausgewählt werden oder über einen entsprechenden Kontextmenü-Eintrag eines Links. Standardmäßig wird dabei die mobile Version einer Webseite geladen, sofern vorhanden. Über die Schaltfläche kann allerdings auch die Desktop-Version angefordert werden.

Anwendungsfall für Side View ist das Multitasking. So kann Side View beispielsweise genutzt werden, um seinen Twitter-Feed immer parallel geöffnet zu haben oder Videos zu schauen, während man etwas anderes macht.

Der Beitrag Test Pilot: Mozilla startet Firefox Color und Side View erschien zuerst auf soeren-hentzschel.at.

Der folgende Artikel wird meine Reihe Grundlagen Server Absicherung um einen weiteren Artikel erweitern. In diesem Artikel werde ich mich auf die Konfiguration von SSH und rkhunter konzentrieren.

SSH

Vorraussetung

Um die SSH Konfiguration umsetzen und nutzen zu können und vor allem damit man weiter Zugriff auf den Server hat, müssen die folgenden Vorraussetzung erst umgetzt werden.

Benutzer anlegen

Auf dem Server legen wir einen Arbeitsnutzer an, wir nennen ihn einfach mal "workuser"

adduser workuser

Vergebt ein sicheres Passwort, der Rest ist egal wie es befüllt wird. Jetzt erzeugen wir auf dem Client einen SSH Key, wenn ihr noch keinen habt.

ssh-keygen -t ed25519

ed25519 ist ein neuer Algorithmus, der sicher ist als der alte RSA Standard. Als nächstes wird der SSH Public Key auf den Server kopiert.

ssh-copy-id workuser@example.org

Mit der Option -i könnt ihr den genauen Schlüssel angeben. Jetzt testen wir die Konfiguration

ssh workuser@example.org

Wenn ihr jetzt nach dem Passwort gefragt werdet, dann stimmt was nicht. Beachtet auch hier könnt ihr mit der Option -i den Key angeben.

SSH Koonfiguration

Den SSH Server konfigurieren wir in der Datei /etc/ssh/sshd_config, dazu löschen wir alle Zeilen raus und fügen die folgende ein:

Protocol 2
Port 3458
LogLevel Verbose

PermitRootLogin no
MaxAuthTries 2
MaxSessions 2
IgnoreRhosts yes

PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no

UsePAM yes

AllowAgentForwarding no
AllowTcpForwarding no
X11Forwarding no
PrintMotd no
TCPKeepAlive no
Compression no
ClientAliveCountMax 2
UseDNS no

AcceptEnv LANG LC_*
Subsystem	sftp	/usr/lib/openssh/sftp-server

Die Konfiguration wird von Lynis als "sicher" anerkannt. Was wird genau gemacht? Ich erwähne nur die wichtigsten Punkte.

• Das Protocol wird auf Version 2 beschränkt

• Der Standardport wird angepasst

  • Achtung: Der ssh Befehlt sieht jetzt so aus: ssh workuser@example.org -p 3458 bei scp sieht wie folgt aus scp -P 3458 workuser@example.org:/srv/test.html .

• Root SSH Login wird unterbunden

• Passwort Login wird unterbunden, nur Key Login möglich

  Mit dieser Konfiguration haben wir ein min. Maß an Sicherheit für unseren SSH Zugriff gewährleistet. Ich habe bewusst dem Nutzer workuser keine sudo Rechte gegeben, so das bei einem unerlaubten Zugriff, der Angreifer keine Adminrechte hat.

rkhunter

rkhunter ist ein Rookit Hunter der nach bekannten Rootkits, Hintertüren und bekannten Exploits auf dem Server sucht. Dazu werden von den wichtigen lokalen Dateien MD5 Hashes angelegt und verglichen.

Installation

Leider gibt es in der aktuellen Debian Version einen Bug, der dazu führt das sich rkhunter nicht updaten lässt. Daher installieren wir das Paket direkt von der Webseite.

Wir laden die aktuelle Version herrunter

wget https://netix.dl.sourceforge.net/project/rkhunter/rkhunter/1.4.6/rkhunter-1.4.6.tar.gz

Entpacken

tar -xvzf rkhunter-1.4.6.tar.gz

Wechselten in den Ordner und führen folgenden Befehl als root aus

./installer.sh --layout /usr/local --install
rkhunter --propupd --update

Jetzt haben wir die aktuelle Version installiert.

Scannen

Mit dem folgenden Befehl führen wir einen Stillen Scan durch, wo nur uns die Fehler angezeigt werden.

rkhunter -c --rwo

Jetzt sollten eine Menge Fehlermeldung ausgegeben werden, das liegt daran dass jede Distribution natürlich ein wenig ihre Datei anpasst. Damit diese Fehler nicht jedesmal angezeigt werde, bzw. uns per Mail zugeschickt werden, werden wir eine Whitelist erstellen. Dazu legen wir die folgenden Datei an, /etc/rkhunter.conf.local und fügenden folgenden Inhalt hinzu

SCRIPTWHITELIST=/usr/sbin/adduser
SCRIPTWHITELIST=/usr/bin/ldd
SCRIPTWHITELIST=/bin/egrep
SCRIPTWHITELIST=/bin/fgrep
SCRIPTWHITELIST=/bin/which

Ein erneuter Scan sollte keine Fehler mehr anzeigen.

Einstellungen

Jetzt werden wir noch die Default Einstellungen von rkhunter bearbeiten, die in der Datei /etc/default/rkhunter sich befinden.

# Defaults for rkhunter automatic tasks
# sourced by /etc/cron.*/rkhunter and /etc/apt/apt.conf.d/90rkhunter
#
# This is a POSIX shell fragment
#

# Set this to yes to enable rkhunter daily runs
# (default: false)
CRON_DAILY_RUN="yes"

# Set this to yes to enable rkhunter weekly database updates
# (default: false)
CRON_DB_UPDATE="yes"

# Set this to yes to enable reports of weekly database updates
# (default: false)
DB_UPDATE_EMAIL="yes"

# Set this to the email address where reports and run output should be sent
# (default: root)
REPORT_EMAIL="info@example.org"

# Set this to yes to enable automatic database updates
# (default: false)
APT_AUTOGEN="yes"

# Nicenesses range from -20 (most favorable scheduling) to 19 (least favorable)
# (default: 0)
NICE="0"

# Should daily check be run when running on battery
# powermgmt-base is required to detect if running on battery or on AC power
# (default: false)
RUN_CHECK_ON_BATTERY="false"

Die oben stehende Konfiguration ist schon angepasst, ihr könnt diese kopieren müsst nur noch die REPORT_EMAIL anpassen. Jetzt wird die Datenbank automatisch geupdatet und wir werden automatisch darüber benachrichtigt.

Cronjob

Als letztes legen wir noch einen Cronjob an, damit alles funktioniert /etc/crontab:

10 3    * * *   root    /usr/bin/rkhunter --cronjob 

Lynis

Als letztes führen wird jetzt nochmal den Lynis check aus

lynis audit system

Der Hardening Index sollte jetzt deutlich besser sein.

Kurz angemerkt: es wurde schon am Wochenende gemunkelt, jetzt ist es in trockenen Tüchern: der US-Softwarekonzern kauft GitHub, einen bekannten Anbieter für das Hosting von Code-Repositories mittels Git-SCM, für sage und schreibe 7,5 Milliarden US-Dollar. Starkes Stück.

Über GitHub werden viele Open Source-Projekte gehostet, zumal die zugrunde liegende Software Git als Open Source-Software für die Entwicklung des Linux-Kernels entwickelt wurde. GitHub hat seit längerem eine ähnliche Bedeutung wie Sourceforge.net bisher.

GitHub soll unabhängig weiterarbeiten, so der Blogbeitrag vom Portal zu dem Thema. Neuer GitHub-CEO wird Nat Friedman, Xamarin-Gründer (bekannt für Mono).

Wer mehr dazu lesen möchte: GitHub Blog, Microsoft Blog, Heise online

Für meinen Websever nutze ich ein kleines Backupscript was ich euch hier mal zeigen möchte. Da ich meinen Server bei Servercow habe, bekomme ich kostenlos 150GB einer Sambafreigabe zur Verfügung gestellt, wo ich meine Backups auslagere.

Hier mal das Script

#!/bin/bash

date=$(date +%Y%m%H%M)

cd /opt/backup/

###
# delete all files older than 10 days
###

delete_files() {
    find /backups/KS1/* -mtime +10 -exec rm {} \;
    return 0
}

###
# Backup important files
###
do_backup() {
    tar -cvzf tmp/gitRepoBackup.tar.gz /srv/git/
    tar -cvzf tmp/sitesBackup.tar.gz /var/www/html/
    tar -cvzf tmp/etcBackup.tar.gz /etc/

    ###
    # do prosody backup
    ###

    /usr/sbin/service prosody stop
    tar -cvzf tmp/prosodyBackup.tar.gz /var/lib/prosody/
    /usr/sbin/service prosody start
    
    ###
    # Create main archive
    ###

    tar -cvzf /backups/KS1/KS1-Backup-$date.tar.gz tmp/*

    ###
    # Remove all old files
    ###
    rm -rf tmp/*

    return 0
}
###
# Mail admin about backupsystem
###

report() {
    [ "$1" = "ok" ] && /usr/sbin/ssmtp -t < mail/mail.eml
    [ "$1" != "ok" ] && echo $1 >> mail/errmail.eml && /usr/sbin/ssmtp -t < mail/errmail.eml
    return 0
}

###
# do backup
###

delete_files && do_backup && report ok || report err

1. Löschen aller Backups älter als 10 Tage
2. Dann tar ich alle Dateien aus den wichtigen Ordner in einem tmp Ordner
3. Dann werden die einzelnen tars in einem Gesamtarchiv zusammen gefasst
4. Wenn alles gut war eine Mail als Erfolgsmeldung an mich
5. Wenn nicht Fehlermeldung an mich

Ordnerstruktur

mkdir -p backup/{tmp,mail}

In dem Ordner mail, sind zwei Dateien enthalten:

cat errmail.eml

From: KS1 Server < root@example.org >
To: info@example.org
Subject: !!! BACKUP ERROR !!!
MIME-Version: 1.0

cat mail.eml

From: KS1 Server < root@example.org >
To: info@example.org
Subject: Server Backup Done
MIME-Version: 1.0

The backup system has done his work.
All files have successfully backuped

Das Script direkt in den Backup Ordnerlegen. Dann noch ein kleiner Cronjob:

 0 */4 * * * /bin/bash /opt/backup/backup.sh

Jetzt wird alle 4 Stunden ein Backup gemacht.

Für meinen Websever nutze ich ein kleines Backupscript was ich euch hier mal zeigen möchte. Da ich meinen Server bei Servercow habe, bekomme ich kostenlos 150GB einer Sambafreigabe zur Verfügung gestellt, wo ich meine Backups auslagere.

Hier mal das Script

#!/bin/bash

date=$(date +%Y%m%H%M)

cd /opt/backup/

###
# delete all files older than 10 days
###

delete_files() {
    find /backups/KS1/* -mtime +10 -exec rm {} \;
    return 0
}

###
# Backup important files
###
do_backup() {
    tar -cvzf tmp/gitRepoBackup.tar.gz /srv/git/
    tar -cvzf tmp/sitesBackup.tar.gz /var/www/html/
    tar -cvzf tmp/etcBackup.tar.gz /etc/

    ###
    # do prosody backup
    ###

    /usr/sbin/service prosody stop
    tar -cvzf tmp/prosodyBackup.tar.gz /var/lib/prosody/
    /usr/sbin/service prosody start
    
    ###
    # Create main archive
    ###

    tar -cvzf /backups/KS1/KS1-Backup-$date.tar.gz tmp/*

    ###
    # Remove all old files
    ###
    rm -rf tmp/*

    return 0
}
###
# Mail admin about backupsystem
###

report() {
    [ "$1" = "ok" ] && /usr/sbin/ssmtp -t < mail/mail.eml
    [ "$1" != "ok" ] && echo $1 >> mail/errmail.eml && /usr/sbin/ssmtp -t < mail/errmail.eml
    return 0
}

###
# do backup
###

delete_files && do_backup && report ok || report err

1. Löschen aller Backups älter als 10 Tage
2. Dann tar ich alle Dateien aus den wichtigen Ordner in einem tmp Ordner
3. Dann werden die einzelnen tars in einem Gesamtarchiv zusammen gefasst
4. Wenn alles gut war eine Mail als Erfolgsmeldung an mich
5. Wenn nicht Fehlermeldung an mich

Ordnerstruktur

mkdir -p backup/{tmp,mail}

In dem Ordner mail, sind zwei Dateien enthalten:

cat errmail.eml

From: KS1 Server < root@example.org >
To: info@example.org
Subject: !!! BACKUP ERROR !!!
MIME-Version: 1.0

cat mail.eml

From: KS1 Server < root@example.org >
To: info@example.org
Subject: Server Backup Done
MIME-Version: 1.0

The backup system has done his work.
All files have successfully backuped

Das Script direkt in den Backup Ordnerlegen. Dann noch ein kleiner Cronjob:

 0 */4 * * * /bin/bash /opt/backup/backup.sh

Jetzt wird alle 4 Stunden ein Backup gemacht.

Kurz angemerkt: es wurde schon am Wochenende gemunkelt, jetzt ist es in trockenen Tüchern: der US-Softwarekonzern kauft GitHub, einen bekannten Anbieter für das Hosting von Code-Repositories mittels Git-SCM, für sage und schreibe 7,5 Milliarden US-Dollar. Starkes Stück.

Über GitHub werden viele Open Source-Projekte gehostet, zumal die zugrunde liegende Software Git als Open Source-Software für die Entwicklung des Linux-Kernels entwickelt wurde. GitHub hat seit längerem eine ähnliche Bedeutung wie Sourceforge.net bisher.

GitHub soll unabhängig weiterarbeiten, so der Blogbeitrag vom Portal zu dem Thema. Neuer GitHub-CEO wird Nat Friedman, Xamarin-Gründer (bekannt für Mono).

Wer mehr dazu lesen möchte: GitHub Blog, Microsoft Blog, Heise online

Ich habe als Anhang zum Artikel PhantomJS: Hyperlinks einer Website auflisten; mit Unterstützung für JavaScript und Frames noch Lösungen mit Selenium in Perl und Python angefügt.

PS: Es sollten nun auch alle Frames durchlaufen werden, das funktionierte Gestern nicht und es war ein Logik-Fehler.
PPS: Noch spiele ich damit etwas :-) und vielleicht tue ich das mal nach GitHub… Mehr Blogeinträge wird es über Updates aber wohl nicht geben und auch diesen werde ich später wieder löschen.

In dieser neuen Serie (nach Mutt) werde ich über die Grundlagen der Server Absicherung schreiben. Ich möchte darauf hinweisen, dass diese Serie jediglich als Grundorientierung dient. Zusätzlich ist darauf zu achten, sich immer im “Saft” zu befinden, da sich fast täglich neue Gefahren entwicklen, auf die der Admin achten sollte.

Als letztes möchte ich darauf hinweisen, dass alle hier aufgelisteten Empfehlungen auf persönlicher Erfahrung beruhen.

Betriebssystem

Im folgenden gehe ich davon aus, dass wir von einem Linux Server sprechen. Ich persönlich arbeite nicht mit Windows Servern und kann daher kein Wissen über diese Infrastruktur teilen.

Debian / Ubuntu

Debian empfiehlt sich sehr als Betriebsystem für einen Server. Debian ist weit verbreitet und wird von vielen Menschen als Serverunterbau verwendet. Aufgrund der einzelen Release Channels (stable, testing, unstable) ist schon ein bisschen “Sicherheit” gewährleistet. Natürlich ist klar, dass nur der Channel stable verwendet werden sollte.

Dazu kann ich folgende /etc/apt/sources.list empfehlen:

deb http://deb.debian.org/debian/ stable main contrib non-free
deb-src http://deb.debian.org/debian/ stable main contrib non-free

deb http://deb.debian.org/debian/ stable-updates main contrib non-free
deb-src http://deb.debian.org/debian/ stable-updates main contrib non-free

deb http://deb.debian.org/debian-security stable/updates main
deb-src http://deb.debian.org/debian-security stable/updates main

deb http://ftp.debian.org/debian stretch-backports main
deb-src http://ftp.debian.org/debian stretch-backports main

Wichtig ist das System immer auf den aktuellen Stand zu halten um bekannte Sicherheitslücken und Fehler in Software schnellst möglich zu schließen. Ich bin kein Freund von automatischen Updates, da ich selber gerne weiß was mein System macht.

Für die unter euch die gerne einen solchen Dienst nutzen wollen, empfehle euch euch das Debian Wiki.

Eine weitere Möglichkeit, die benutze ich persönlich auch, ist es sich über neue Paket per Mail informieren zu lassen. Dazu benötigt man das Paket apticron. Im Thomas Krenn Wiki ist sehr gut beschrieben, wie diese konfiguriert wird, daher gehe ich nicht weiter darauf ein.

Mail Benachrichtigung

Für die Mail Benachrichtigungen nutze ich statt mail das Programm ssmtp. Einfach zu installieren mit dem Befehl

apt install ssmtp

Die Konfiguration der Datei /etc/ssmtp/ssmtp.conf sollte dann so aussehen

#Alias für root
root=root@example.de
#Server Setup
mailhub=mail.example.de:587
AuthUser=test@example.de #mailadresse
AuthPass=Password
UseSTARTTLS=YES
TLS_CA_File=/etc/ssl/certs/ca-certificates.crt

hostname=example.de #hostname

Mit dem Befehl ssmtp -vt < mail.eml ist es möglich die Konfiguration zu testem. Die Datei mail.eml hat folgenden Inhalt

From: MyPBX < root@example.de >
To: harry < root@example.de >
Subject: test
MIME-Version: 1.0

Lynis

Lynis ist ein Secuirty Tool, was den Server mit einem “Health Scan” überprüft und dann auf Fehlerhafte oder gar nicht vorhanden Konfiguration hinweist. Das Tool ist leider bei Debian veraltet darum bietet sich an die eigne Repository hinzuzufügen. Dafür muss als erstes aber ein Paket installiert werden:

apt install apt-transport-https

Dann wird der PGP Schlüssel installiert

 wget -O - https://packages.cisofy.com/keys/cisofy-software-public.key | apt-key add -

Jetzt die Liste hinzufügen

echo "deb https://packages.cisofy.com/community/lynis/deb/ stable main" | tee /etc/apt/sources.list.d/cisofy-lynis.list

Jetzt updaten und installieren

apt update && apt install lynis

Mit dem Befehl lynis update info kann man den aktuellen Stand der Software prüfen

root@vps73846:~# lynis update info

 == Lynis ==

  Version            : 2.6.4
  Status             : Up-to-date
  Release date       : 2018-05-02
  Update location    : https://cisofy.com/lynis/


2007-2018, CISOfy - https://cisofy.com/lynis/

Als nächstes überprüfen wir das System lynis audit system auch Dockerfiles können geprüft werden mit lynis audit dockerfile

Die Ausgabe sieht dann wie folgt aus

....
================================================================================

  Lynis security scan details:

  Hardening index : 77 [###############     ]
  Tests performed : 218
  Plugins enabled : 0

  Components:
  - Firewall               [V]
  - Malware scanner        [V]

  Lynis Modules:
  - Compliance Status      [?]
  - Security Audit         [V]
  - Vulnerability Scan     [V]

  Files:
  - Test and debug information      : /var/log/lynis.log
  - Report data                     : /var/log/lynis-report.dat

================================================================================
....

An dem Hardening Index ist zu erkennen, dass noch einiges zutun ist. In den folgenden Artikel werde ich auf die Konfigurationen eingehen, so dass dieser Score noch deutlich steigen wird.

Kurz angemerkt: die Abmahnwelle ist angelaufen. Und auch die Kanzlei WBS hat auf YouTube bereits ein Video zu dem Thema veröffentlicht.

Folgenlos zieht dies an diesem Blog nicht vorbei, es gibt einige Änderungen. Zum einen ist die Kommentarfunktion nun seit einiger Zeit deaktiviert. Leserbriefe und Kommentare können gerne weiterhin gem. meiner Datenschutzerklärung an info@v-gar.de gesandt werden, ich freue mich über jeden (konstruktiven) Kommentar auf diesem Weg.

Die zweite Änderung ist etwas tiefgreifender. Im Abmahnärger geht es auch darum, dass der Datenschutzerklärung eingewilligt werden soll, bevor Daten zu Google über Google Fonts übertragen werden. Bei WordPress, dem bei mir eingesetzten Blogsystem, von dem ich demnächst weg migrieren werde, ist das schon etwas schwieriger in der Umsetzung. Daher nun die “Datenschutzerklärungs-Dampframme” oder diplomatischer, der “Privacy Consent Checker”.

Hierbei handelt es sich um ein vor mir auf GitHub open source veröffentlichtes PHP-Script, das sich insbesondere für WordPress eignet. Die Arbeitsweise ist dreckig und tut einem Softwareentwickler in der Seele weh, aber es funktioniert. Kurz zusammengefasst: wenn kein Lese-Cookie erkannt wird, wird auf jeder Seite des Blogs eine HTML-Seite mit der Datenschutzerklärung und Möglichkeit zur Kenntnisnahme angezeigt. Erst nach einer Lesebestätigung (und dem Setzen des Cookies) wird WordPress geladen. Vorteil: man kann vorher sogar schon das Matomo-Opt-Out machen. Außerdem wird die Datenschutzerklärung gezeigt, *bevor* Google Fonts geladen wird.

Umgesetzt wird dies durch Einbinden des Scripts in der index.php (das ist der besondere dreckige Part, weil ich keine Hooks nutze/nutzen kann und WordPresss das wohl bei jedem Update überschreiben wird). Dank URL-Rewriting wird diese ja jedes Mal diese bootstrap-artige index.php aufgerufen und ich kriege es global auf dem Blog umgesetzt.

Web Crawler und Feed-Parser sind von dieser Aktion nicht betroffen und dürften ungestört die Seite lesen können.

Wie gesagt, Code ist auf GitHub. Über Mitarbeit und Hilfe bei der Übersetzung in andere Sprachen würde ich mich sehr freuen. Das Script entstand sehr kurzfristig und hat demnach noch etwas Potential. Der Einsatz des Scripts erfolgt auf eigene Gefahr, es kann keine Haftung übernommen werden.

Abschließend gesagt: ich hoffe, dass sich diese Unklarheiten/Grauzonen bzgl. der Umsetzung der DSGVO zeitnah klären werden und sehe dieses Script nur als temporäre Lösung!

Ich freue mich über (E-Mail) Feedback!

Seit kurzem gibt es eine Suchmaschine für öffentliche XMPP¹ MUCs², also Gruppenchats, namens Christopher Muclumbus. Wenn ihr die MUCs auf eurem XMPP-Server indizieren lassen wollt müsst ihr einfach christopher.muclumbus@dreckshal.de in einen MUC auf eurem Server einladen. Der Bot sucht dann selbstständig nach weiteren MUCs auf diesem Server.

Dieser Artikel ist auf Wunsch von intux entstanden.

Im folgenden Artikel möchte ich darauf eingehen, wie man Prosody mit Let’s Encrypt nutzen kann, ohne Zertifikate zu kopieren, Script zu schreiben oder die Rechte auf die Zertifikate zu ändern, damit Prosody sie lesen und nutzen kann.

Vorraussetzungen

Im Artikel gehe ich davon aus, dass ihr Prosody bereits installiert und eingerichtet habt. Zusätzlich gehe ich davon aus, dass ihr mit LE bereits für die entsprechende Domain Zertifikate angefordert habe und zwar für:

• example.de
• conference.example.de

Das lässt sich sehr schön mit der DNS Überprüfung von LE lösen.

Die Zertifikate sollten in dem Ordner

/etc/letsencrypt/live/example.de/

liegen und ihr nutzt den certbot für die Erstellung eurer Zertifikate.

Prosody SSL Konfiguration

Ich werde nur ganz kurz anschneiden, wie eine “sichere” SSL Konfiguration für die Verwendung mit Prosody aussehen sollte:

c2s_require_encryption = true;
s2s_require_encryption = true;
s2s_secure_auth = true;

ssl = {
    protocol = "tlsv1_2"; 
    ciphers = "EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:EDH+aRSA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED:!AES128:!CAMELLIA128";
    options = { "no_sslv2", "no_sslv3", "no_ticket", "no_compression", "cipher_server_preference", "single_dh_use", "single_ecdh_use" };
    dhparam = "/etc/prosody/dhparam.pem";
}

Bitte keine Angaben in die Datei wo das Zertifikate liegt, wenn ihr diese bereits habt, könnt ihr diese löschen.

Die Datei /etc/prosody/dhparam.pem wird mit dem folgenden Befehl erstellt:

openssl dhparam -dsaparam -out /etc/prosody/dhparam.pem 4096

Achtung: Das dauert sehr lange, ich empfehle es mit screen zu machen.

Prosody & Let’s Encrypt

So jetzt kommen wir zum eigentlichen Teil, wichtig hier, dass ihr min. Version 0.10 habt:

root@vps73846:/etc/prosody# apt-cache policy prosody
prosody:
  Installed: 0.10.1-1~stretch1
  Candidate: 0.10.1-1~stretch1
  Version table:
 *** 0.10.1-1~stretch1 500

Um die aktuelle Version unter Debian Stable (Stretch) zu bekommen, solltet ihr die Prosody Repo nutzen.

So jetzt führen wir einfach den folgenden Befehl aus:

prosodyctl --root cert import /etc/letsencrypt/live

Wichtig, nur auf den live Ordner, nicht im example.de Ordner.

Prosody erkennt automatisch die richtigen Zertifikate und konfiguriert sich dementsprechend. Das war es eigentlich auch schon. Aber nur fast.

Das Problem, die Zertifikate müssen nach jedem neu erstellen wieder eingelesen werden. Dazu nutzen wir die Möglichkeit der globalen Konfigurationsdatei von Let’s Encrypt, /etc/letsencrypt/cli.ini

Der Inhalt sollte so aussehen, ja ihr müsste die Datei erst anlegen

# Global config for letsencrypt runs
#
# Note that these options apply automatically to all use of Certbot for
# obtaining or renewing certificates, so options specific to a single
# certificate on a system with several certificates should not be placed
# here.

renew-hook = prosodyctl --root cert import /etc/letsencrypt/live
post-hook = prosodyctl --root cert import /etc/letsencrypt/live

So das wars. Jetzt haben wir Prosody mit den aktuellen LE Zertifikaten ausgerüstet und auch dafür gesorgt, das es immer die aktuellen Zertifikate bekommt.

In dieser neuen Serie (nach Mutt) werde ich über die Grundlagen der Server Absicherung schreiben. Ich möchte darauf hinweisen, dass diese Serie jediglich als Grundorientierung dient. Zusätzlich ist darauf zu achten, sich immer im "Saft" zu befinden, da sich fast täglich neue Gefahren entwicklen, auf die der Admin achten sollte.

Als letztes möchte ich darauf hinweisen, dass alle hier aufgelisteten Empfehlungen auf persönlicher Erfahrung beruhen.

Betriebssystem

Im folgenden gehe ich davon aus, dass wir von einem Linux Server sprechen. Ich persönlich arbeite nicht mit Windows Servern und kann daher kein Wissen über diese Infrastruktur teilen.

## Debian / Ubuntu

Dazu kann ich folgende /etc/apt/sources.list empfehlen:

deb http://deb.debian.org/debian/ stable main contrib non-free
deb-src http://deb.debian.org/debian/ stable main contrib non-free

deb http://deb.debian.org/debian/ stable-updates main contrib non-free
deb-src http://deb.debian.org/debian/ stable-updates main contrib non-free

deb http://deb.debian.org/debian-security stable/updates main
deb-src http://deb.debian.org/debian-security stable/updates main

deb http://ftp.debian.org/debian stretch-backports main
deb-src http://ftp.debian.org/debian stretch-backports main

Wichtig ist das System immer auf den aktuellen Stand zu halten um bekannte Sicherheitslücken und Fehler in Software schnellst möglich zu schließen. Ich bin kein Freund von automatischen Updates, da ich selber gerne weiß was mein System macht.

Für die unter euch die gerne einen solchen Dienst nutzen wollen, empfehle euch euch das Debian Wiki.

Eine weitere Möglichkeit, die benutze ich persönlich auch, ist es sich über neue Paket per Mail informieren zu lassen. Dazu benötigt man das Paket apticron. Im Thomas Krenn Wiki ist sehr gut beschrieben, wie diese konfiguriert wird, daher gehe ich nicht weiter darauf ein.

Mail Benachrichtigung

Für die Mail Benachrichtigungen nutze ich statt mail das Programm ssmtp. Einfach zu installieren mit dem Befehl

apt install ssmtp

Die Konfiguration der Datei /etc/ssmtp/ssmtp.conf sollte dann so aussehen

#Alias für root
root=root@example.de
#Server Setup
mailhub=mail.example.de:587
AuthUser=test@example.de #mailadresse
AuthPass=Password
UseSTARTTLS=YES
TLS_CA_File=/etc/ssl/certs/ca-certificates.crt

hostname=example.de #hostname

Mit dem Befehl ssmtp -vt < mail.eml ist es möglich die Konfiguration zu testem. Die Datei mail.eml hat folgenden Inhalt

From: MyPBX < root@example.de >
To: harry < root@example.de >
Subject: test
MIME-Version: 1.0

Lynis

Lynis ist ein Secuirty Tool, was den Server mit einem "Health Scan" überprüft und dann auf Fehlerhafte oder gar nicht vorhanden Konfiguration hinweist. Das Tool ist leider bei Debian veraltet darum bietet sich an die eigne Repository hinzuzufügen. Dafür muss als erstes aber ein Paket installiert werden:

apt install apt-transport-https

Dann wird der PGP Schlüssel installiert

 wget -O - https://packages.cisofy.com/keys/cisofy-software-public.key | apt-key add -

Jetzt die Liste hinzufügen

echo "deb https://packages.cisofy.com/community/lynis/deb/ stable main" | tee /etc/apt/sources.list.d/cisofy-lynis.list

Jetzt updaten und installieren

apt update && apt install lynis

Mit dem Befehl lynis update info kann man den aktuellen Stand der Software prüfen

root@vps73846:~# lynis update info

 == Lynis ==

  Version            : 2.6.4
  Status             : Up-to-date
  Release date       : 2018-05-02
  Update location    : https://cisofy.com/lynis/


2007-2018, CISOfy - https://cisofy.com/lynis/

Als nächstes überprüfen wir das System lynis audit system auch Dockerfiles können geprüft werden mit lynis audit dockerfile

Die Ausgabe sieht dann wie folgt aus

....
================================================================================

  Lynis security scan details:

  Hardening index : 77 [###############     ]
  Tests performed : 218
  Plugins enabled : 0

  Components:
  - Firewall               [V]
  - Malware scanner        [V]

  Lynis Modules:
  - Compliance Status      [?]
  - Security Audit         [V]
  - Vulnerability Scan     [V]

  Files:
  - Test and debug information      : /var/log/lynis.log
  - Report data                     : /var/log/lynis-report.dat

================================================================================
....

An dem Hardening Index ist zu erkennen, dass noch einiges zutun ist. In den folgenden Artikel werde ich auf die Konfigurationen eingehen, so dass dieser Score noch deutlich steigen wird.

Dieser Artikel ist auf Wunsch von intux entstanden.

Im folgenden Artikel möchte ich darauf eingehen, wie man Prosody mit Let's Encrypt nutzen kann, ohne Zertifikate zu kopieren, Script zu schreiben oder die Rechte auf die Zertifikate zu ändern, damit Prosody sie lesen und nutzen kann.

Vorraussetzungen

Im Artikel gehe ich davon aus, dass ihr Prosody bereits installiert und eingerichtet habt. Zusätzlich gehe ich davon aus, dass ihr mit LE bereits für die entsprechende Domain Zertifikate angefordert habe und zwar für:

• example.org
• conference.example.org

Das lässt sich sehr schön mit der DNS Überprüfung von LE lösen.

Die Zertifikate sollten in dem Ordner

/etc/letsencrypt/live/example.org/

liegen und ihr nutzt den certbot für die Erstellung eurer Zertifikate.

Prosody SSL Konfiguration

Ich werde nur ganz kurz anschneiden, wie eine "sichere" SSL Konfiguration für die Verwendung mit Prosody aussehen sollte:

c2s_require_encryption = true;
s2s_require_encryption = true;
s2s_secure_auth = true;

ssl = {
    protocol = "tlsv1_2"; 
    ciphers = "EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:EDH+aRSA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED:!AES128:!CAMELLIA128";
    options = { "no_sslv2", "no_sslv3", "no_ticket", "no_compression", "cipher_server_preference", "single_dh_use", "single_ecdh_use" };
    dhparam = "/etc/prosody/dhparam.pem";
}

Bitte keine Angaben in die Datei wo das Zertifikate liegt, wenn ihr diese bereits habt, könnt ihr diese löschen.

Die Datei /etc/prosody/dhparam.pem wird mit dem folgenden Befehl erstellt:

openssl dhparam -dsaparam -out /etc/prosody/dhparam.pem 4096

Achtung: Das dauert sehr lange, ich empfehle es mit screen zu machen.

Prosody & Let's Encrypt

So jetzt kommen wir zum eigentlichen Teil, wichtig hier, dass ihr min. Version 0.10 habt:

root@vps73846:/etc/prosody# apt-cache policy prosody
prosody:
  Installed: 0.10.1-1~stretch1
  Candidate: 0.10.1-1~stretch1
  Version table:
 *** 0.10.1-1~stretch1 500

Um die aktuelle Version unter Debian Stable (Stretch) zu bekommen, solltet ihr die Prosody Repo nutzen.

So jetzt führen wir einfach den folgenden Befehl aus:

prosodyctl --root cert import /etc/letsencrypt/live

Wichtig, nur auf den live Ordner, nicht im example.org Ordner.

Prosody erkennt automatisch die richtigen Zertifikate und konfiguriert sich dementsprechend. Das war es eigentlich auch schon. Aber nur fast.

Das Problem, die Zertifikate müssen nach jedem neu erstellen wieder eingelesen werden. Dazu nutzen wir die Möglichkeit der globalen Konfigurationsdatei von Let's Encrypt, /etc/letsencrypt/cli.ini

Der Inhalt sollte so aussehen, ja ihr müsste die Datei erst anlegen

# Global config for letsencrypt runs
#
# Note that these options apply automatically to all use of Certbot for
# obtaining or renewing certificates, so options specific to a single
# certificate on a system with several certificates should not be placed
# here.

renew-hook = prosodyctl --root cert import /etc/letsencrypt/live
post-hook = prosodyctl --root cert import /etc/letsencrypt/live

So das wars. Jetzt haben wir Prosody mit den aktuellen LE Zertifikaten ausgerüstet und auch dafür gesorgt, das es immer die aktuellen Zertifikate bekommt.

Ich bin kein großer Fan von Klickibunti-Oberflächen wie Plesk, ISPconfig, froxlor und Co.
In meinen Augen erhöhen Lösungen wie die genannten nicht nur die Angriffsfläche eines Systems, sie bringen meist auch Dinge mit, die ich gar nicht benötige. Ich persönlich bevorzuge ein möglichst einfaches, aber dennoch sicheres Setup für Webserver.

Wer ein wenig in diesem Blog herumgestöbert hat oder schon länger mitliest, weiß dass ich vor einiger Zeit für genau diesen Fall mal ein kleines Bash-Script auf Github veröffentlicht habe, welches auf den Namen SLEMP hört.

Genau dieses habe ich nun mal wieder angefasst, umgeschrieben und um Unterstützung für Subdomains erweitert.

Was macht SLEMP?

Unterstützt werden nach wie vor minimale Installationen von CentOS 7.x und Debian 9.

– Installation von NGINX und MariaDB aus Entwickler-Repository
– PHP 7.0, 7.1 und 7.2 können einzeln, auf Wunsch aber auch parallel installiert werden. Für CentOS greife ich dabei auf  Remi’s RPM repository zurück, unter Debian nutze ich das Repository von deb.sury.org.
– Absicherung und 301-Weiterleitung von HTTP auf HTTPS mittels Let’s Encrypt-Zertifikat
– Auf Wunsch wird eine MariaDB (Installation aus Entwickler-Repository) mit Benutzer und zufälligen Passwort eingerichtet

Als nächstes plane ich nun das Script um eine Installations-Option für WordPress und Nextcloud zu erweitern, jeweils mit optimierten NGINX-Konfigurationen für das jeweilige System. Im weiteren Verlauf möchte ich als Installations-Option noch Apache ergänzen – dann würde das Script aber einen neuen Namen benötigen. ?

Wer sich an dem Script beteiligen möchte, darf das gerne auf Github tun, es ist nicht perfekt, tut aber, was es soll. Wer Fehler findet, kann diese ebenfalls gerne auf Github melden. Danke! ?

Ich bin kein großer Fan von Klickibunti-Oberflächen wie Plesk, ISPconfig, froxlor und Co.
In meinen Augen erhöhen Lösungen wie die genannten nicht nur die Angriffsfläche eines Systems, sie bringen meist auch Dinge mit, die ich gar nicht benötige. Ich persönlich bevorzuge ein möglichst einfaches, aber dennoch sicheres Setup für Webserver.

Wer ein wenig in diesem Blog herumgestöbert hat oder schon länger mitliest, weiß dass ich vor einiger Zeit für genau diesen Fall mal ein kleines Bash-Script auf Github veröffentlicht habe, welches auf den Namen SLEMP hört.

Genau dieses habe ich nun mal wieder angefasst, umgeschrieben und um Unterstützung für Subdomains erweitert.

Was macht SLEMP?

Unterstützt werden nach wie vor minimale Installationen von CentOS 7.x und Debian 9.

- Installation von NGINX und MariaDB aus Entwickler-Repository
- PHP 7.0, 7.1 und 7.2 können einzeln, auf Wunsch aber auch parallel installiert werden. Für CentOS greife ich dabei auf  Remi's RPM repository zurück, unter Debian nutze ich das Repository von deb.sury.org.
- Absicherung und 301-Weiterleitung von HTTP auf HTTPS mittels Let's Encrypt-Zertifikat
- Auf Wunsch wird eine MariaDB (Installation aus Entwickler-Repository) mit Benutzer und zufälligen Passwort eingerichtet

Als nächstes plane ich nun das Script um eine Installations-Option für Wordpress und Nextcloud zu erweitern, jeweils mit optimierten NGINX-Konfigurationen für das jeweilige System. Im weiteren Verlauf möchte ich als Installations-Option noch Apache ergänzen - dann würde das Script aber einen neuen Namen benötigen. :-)

Wer sich an dem Script beteiligen möchte, darf das gerne auf Github tun, es ist nicht perfekt, tut aber, was es soll. Wer Fehler findet, kann diese ebenfalls gerne auf Github melden. Danke! :-)