Lese-Ansicht

SSH - Zugangsberechtigungen via Schlüssel einschränken

Bekanntermaßen sind SSH-Verbindungen weitestgehend das Standardverfahren, um Serververbindungen sicher aufzubauen.
Normalerweise kommt in Bezug auf Authentifizierung eine Kombination aus Nutzernamen und Passwort zum Einsatz. Es gibt aber auch Varianten mit Zertifikat oder Schlüssel.
Letzteres sollte nicht nur Standard, sondern heute auch Thema sein. Üblicherweise erhältst du via SSH Vollzugriff (oke vielleicht kein root), es besteht allerdings die Möglichkeit diesen per authorized keys zu regulieren, so kannst du in einem SSH Schlüssel etwa eine IP-Beschränkung hinterlegen, um einen Zugriff weiter einzuschränken.

SSH AuthorizedKeysFile Format

In einem Standardsetup findest du vorhandene Schlüssel unter ~/.ssh/authorized_keys und genau hier möchte ich heute einen genaueren Blick darauf werfen.
Dort liegen die öffentlichen SSH-Schlüssel, die einen bestimmten Aufbau haben, dazu gleich mehr. Auch wird zwischen Version 1 und Version 2 unterschieden, wobei zwei der Standard sein sollte.
Ältere Semester kennen eventuell noch  ~/.ssh/authorized_keys2,  was ursprünglich für den zweiten Protokolltyp vorgesehen war, allerdings seit 2001 deprecated ist und heute maximal noch von böswilligen Akteuren missbraucht wird.
Zurück zu den Schlüsseln, folgende Aufteilung besitzen diese laut Norm:

  • Öffentliche Schlüssel des Protokolls 1 bestehen aus den folgenden durch Leerzeichen getrennten Feldern: Optionen, Bits, Exponent, Modulus, Kommentar.
  • Öffentliche Schlüssel des Protokolls 2 bestehen aus: Optionen, Keytype, base64-kodierter Schlüssel, Kommentar
  • Das Optionsfeld ist optional. Sein Vorhandensein wird dadurch bestimmt, ob die Zeile mit einer Zahl beginnt oder nicht (das Optionsfeld beginnt nie mit einer Zahl).
  • Die Optionen (falls vorhanden) bestehen aus durch Kommata getrennten Optionsangaben.

Im Detail ermöglichen sie, verschiedene Werte mitzugeben und anderen eine IP-Einschränkung.

SSH - Zugangsberechtigungen einschränken

Hier ein erstes Beispiel:

from="192.168.1.?,*.example.com" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDQu9QfY+g0XRVbRTaMPLRN2PVmrRCpaDRaxTHPqggn3 user@example.com

Zur Erklärung: Du kannst in den Optionen Wildcards setzen. Das heißt, im Beispiel oben hätte 192.168.1.1-9 Zugriff, sowie Subdomains von example.com.

Eine weitere Möglichkeit wäre, die Option command zu verwenden, um direkte Befehle zu hinterlegen:
 

command="bash /opt/startworkflow" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDQu9QfY+g0XRVbRTaMPLRN2PVmrRCpaDRaxTHPqggn3 user@example.com

command="/opt/mehrere_befehle.sh" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDQu9QfY+g0XRVbRTaMPLRN2PVmrRCpaDRaxTHPqggn3 user@example.com

Der Nutzer hat hier nur das Recht, das vorgegebene Kommando auszuführen, nicht mehr und nicht weniger

Kontrollieren kannst du solche Kommandos mit der Variable $SSH_ORIGINAL_COMMAND. Diese enthält die ursprüngliche Befehlszeile
sobald ein erzwungener Befehl ausgeführt wird.
Wenn du mehrere Befehle erlauben willst, kommst du nicht drumherum, ein Script zu schreiben, was diese Beschränkungen mehr oder weniger aushebelt.

Ein weiteres Beispiel zeigt die Verwendungen der Kommandos für SSH Tunneling bzw. Port Forwarding:

restrict,port-forwarding,permitopen="localhost:8765" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDQu9QfY+g0XRVbRTaMPLRN2PVmrRCpaDRaxTHPqggn3 user@example.com

Hier wird explizit erlaubt, eine Verbindung auf Port 8765 herzustellen und alles andere bitte bleiben zu lassen. Auch echter Shell-Zugang (no-pty ist in restrict enthalten) wird unterbunden.


     restrict
Enable all restrictions, i.e. disable port, agent and X11 forwarding, as well as disabling PTY allocation and execution of ~/.ssh/rc.  If any future restriction capabilities are added to authorized_keys files they will be included in this set.

 

Du hast nun einen kleinen Einblick in die vielfältigen Konfigurationsmöglichkeiten von SSH-Schlüsseln erhalten. Gerade IP-Beschränkungen oder Limitierung auf Befehle kommen im Alltag vor und sind in diesem Sinne keine neue Methode.
SSH Tunneling ist eigentlich schon wieder ein anderes Kapitel.
Einen Überblick der SSH Befehle findest du bei den Ubuntu Manpages. Viel Spaß.

 

  •  

Firefox - Cookie-Dialog-Blocker aktivieren

Firefox – Cookie-Dialog-Blocker

Vor kurzem ist der neue Firefox 120 erschienen, er bringt eine nützliche Cookiedialog Blockfunktion mit.
Du kennst nervige Pop-ups zur Genüge, diese haben in den vergangenen Jahren das Internet zu einem Klicknet gemacht.

Praktischerweise bringt der neue Firefox eine Funktion mit, um diese automatisch abzulehnen. Heißt, sie werden nicht einfach ausgeblendet, sondern sie werden beantwortet.

Leider ist diese Funktion bisher nur deutschen Nutzer und dem privaten Modus vorbehalten. Das kannst du allerdings einfach über about:config ändern.

firefox-cookie-banner-dialog-aktivieren

Du musst lediglich nach den Variablen cookiebanners.service.mode suchen und die Werte auf 1 setzen.

Sollten Cookie-Banner weiterhin nicht verschwinden, kannst du auch den Wert 2 setzen. Dieser sorgt dafür, dass Cookie Dialoge, die nicht abgelehnt werden können, automatisch akzeptiert werden.

  • 0 Cookie-Banner Blocker deaktiviert
  • 1 Cookie-Banner Blocker lehnt ab, sofern möglich
  • 2 Cookie-Banner Blocker lehnt ab, sofern möglich und akzeptiert den Rest

Kontrollieren kannst du die Funktion in den Privacy Einstellungen about:preferences#privacy.

Natürlich kannst du die neue Surffreude ebenfalls auf Webseiten mit Cookie-Banner testen, so etwas wie chip.de oder dergleichen. Hier hat bei mir das Ablehnen nicht funktioniert, sondern nur Wert 2 mit Ablehnen, wenn möglich, und den Rest akzeptieren.

Fingerabdruck ade

Eine weitere praktische Funktion, um den Fingerabdruck beim Surfen zu reduzieren, bietet der neue Fingerprinting-Schutz in der Canvas API, welcher allerdings auch nur im privaten Modus aktiv ist.

Links ohne Tracking kopieren

Eine ebenfalls hervorragende neue Funktion ist das Kopieren eines Links über das Kontextmenü ohne Trackinginformationen.

firefox-link-ohne-tracking

Alle weiteren Neuerungen von Firefox 120 findest du bei Mozilla.

  •  

Senden der Nachricht fehlgeschlagen

Seit 2016 verwende ich einen OpenPGP-Key, um bei Bedarf meine eMails zu verschlüsseln. Leider hat sich dieses Verfahren nicht so durchgesetzt, wie man es sich erhofft hat. Negativ wirkten sich auch u.a. auch die zahlreichen Attacken auf SKS-Keyserver und die dort hinterlegten öffentlichen Schlüssel aus. Durch die Verwendung des neuen Keyservers auf keys.openpgp.org kam jedoch etwas Ruhe in die ganze Sache. Zur Freude musste ich meinen Key nicht aufgeben, den ich tatsächlich hin und wieder einsetze.

Die eMails, welche ich von meinem Notebook versende, wurden bis letzte Woche mit diesem Key signiert. Das heißt, dass u.a. auch mein öffentlicher Schüssel an jede abgehende Nachricht angehängt wurde. Nun bemerkte ich aber, dass meine eMails, mit dem Hinweis „Senden der Nachricht fehlgeschlagen“, nicht mehr verschickt wurden. Schnell hatte ich herausgefunden, dass der Anhang Probleme machte. Also habe ich als Sofortmaßnahme die digitale Signatur mit OpenPGP abgeschaltet, was natürlich nur eine Übergangslösung darstellen sollte.

Heute konnte ich der Sache auf den Grund gehen und habe mir den Key in Thunderbird näher angesehen. Hier konnte ich jedoch nichts Außergewöhnliches feststellen.

Kein Backup, kein Mitleid

… so hört man es immer von den IT-Profis. Backups meines Schlüsselpaares existierten aber zum Glück. Bevor ich jedoch den Schlüssel in Thunderbird neu eingespielt habe, wurde meinerseits nochmals ein Backup des privaten Schlüssels über das Terminal mit

gpg --export-secret-keys -a user@domain.tld > secret.asc

angelegt. Dieses Backup packte ich nun zu den anderen. Hierbei fiel auf, dass der private Key nur 2,2kB groß war und das letzte Backup bei ca. 35kB lag. Eigentlich hätte doch der aktuelle Key größer sein müssen!?

Kurzerhand wurde also das letzte Backup des privaten Schlüssels in Thunderbird eingespielt und das Problem war tatsächlich gelöst. eMails können nun wieder mit digitaler Signatur versendet werden.

Ansicht Ende-zu-Ende-Verschlüsselung in Thunderbird privater OpenPGP-Schlüssel
Privater OpenPGP-Schlüssel in Thunderbird

Natürlich wurde gleich, mit dem oben erwähnten Befehl, ein aktuelles Backup erzeugt. Der neue private Key hat nun eine Größe von 36,8kB, was beruhigt.

Ende gut, alles gut!

  •  

Facebook Places

Nachdem Facebook Places in den letzten Tagen offiziell gelauncht wurde und somit wahrscheinlich auf den erfolgreichen Zug von Foursquare und Gowalla mit aufspringt, werden schon erste Stimmen laut, was den Datenschutz betrifft. Um Klarheit über die Einstellungen von Facebook Places zu schaffen, haben die Verantwortlichen ein Video dazu veröffentlicht. (Lässt sich leider nicht einbinden) Hier wird in 4 Minuten das Wichtigste zu diesem neuen Service erklärt.

 

  •  

Wichtiges Microsoft Update für LNK Lücke

Bereits Mitte Juli wurde die Sicherheitslücke in den Microsoft LNK Dateien bestätigt. LNK Dateien kennt jeder und benutzt jeder. Eine einfache Verknüpfung auf dem Desktop ist z.B. eine .lnk Datei. Bei der neuen Sicherheitslücke genügt es, auf so eine Datei zu klicken, um sich Schadsoftware einzufangen. Microsoft hat jedoch, wie angekündigt, nun einen Patch veröffentlicht, der diese Lücke schließt. Jeder sollte also den Patch manuell herunterladen oder das MS Update anwerfen, um sein System zu aktualisieren. Auf der Microsoft Seite Security Bulletin MS10-046 findet ihr den passenden Patch für eure Windows Versionen. Der Patch ist für die Systeme Windows XP, Vista, Windows 7 sowie Windows Server 2003 und 2008 zu haben

  •  

Lösung: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead

Was ist apt-key?

Die Man Pages beschreiben apt-key wie folgt:

apt-key is used to manage the list of keys used by apt to authenticate packages. Packages which have been authenticated using these keys will be considered trusted.

apt-key wird verwendet, um die Liste der Schlüssel zu verwalten, die von apt zur Authentifizierung von Paketen verwendet werden. Pakete, die mit diesen Schlüsseln authentifiziert wurden, werden als vertrauenswürdig eingestuft.

Der Vollständigkeit halber hier der Punkt zur "deprecated" Meldung:

update (deprecated)
Update the local keyring with the archive keyring and remove from the local keyring the archive keys which are no longer valid. The archive keyring is shipped in the archive-keyring package of your distribution, e.g. the ubuntu-keyring package in Ubuntu.

Note that a distribution does not need to and in fact should not use this command any longer and instead ship keyring files in the /etc/apt/trusted.gpg.d/ directory directly as this avoids a dependency on gnupg and it is easier to manage keys by simply adding and removing files for maintainers and users alike.

Was bedeutet apt-key is deprecated?

In der Fehlermeldung "apt-key is deprecated. Manage keyring files in trusted.gpg.d" sind zwei Meldungen versteckt:

Bisher wurden Schlüssel in trusted.gpg verwaltet. In Zukunft sollten die Schlüssel einzeln unter trusted.gpg.d verwaltet werden. Der Grund für das Abschaffen des alten Vorgangs ist die schlicht die Sicherheit.

Zusätzlich wird apt-key als veraltet eingestuft. Da es sich hier nur um eine Warnung handelt, kann diese bis jetzt auch einfach ignoriert werden. Im Prinzip möchte sie den Nutzer weg von apt-key hin zu gpg schubsen und genau das möchte ich hier zeigen.

Bei einem apt update wirft ein Ubuntu beispielsweise folgenden Warnungen in Bezug auf nodejs und yarn Repositorys

reading package lists... Done
W: https://deb.nodesource.com/node_16.x/dists/jammy/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details.
W: https://dl.yarnpkg.com/debian/dists/stable/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details.

Lösung -  Schlüssel aus trusted.gpg in trusted.gpg.d umziehen

Die Lösung für die oben aufgeführte Problematik ist das bereits erwähnte Umschichten von trusted.gpg zu trusted.gpg.d.

Zunächst werden die betreffenden Schlüssel aufgelistet:

sudo apt-key list
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
/etc/apt/trusted.gpg
--------------------
pub   rsa4096 2014-06-13 [SC]
      9FD3 B784 BC1C 6FC3 1A8A  0A1C 1655 A0AB 6857 6280
uid           [ unknown] NodeSource <gpg@nodesource.com>
sub   rsa4096 2014-06-13 [E]

pub   rsa4096 2016-10-05 [SC]
      72EC F46A 56B4 AD39 C907  BBB7 1646 B01B 86E5 0310
uid           [ unknown] Yarn Packaging <yarn@dan.cx>
sub   rsa4096 2016-10-05 [E]
sub   rsa4096 2019-01-02 [S] [expires: 2023-01-24]
sub   rsa4096 2019-01-11 [S] [expires: 2023-01-24]


Schlüssel in eine eigene Datei verschieben

Danach die letzten 8 Zeichen der zweiten Zeile unter pub kopieren. In diesem Fall ist das 6857 6280. Das Leerzeichen zwischen den Zahlen muss entfernt werden.
Der zukünftige Name kann beliebig gewählt werden, es liegt allerdings nahe, ihn nach dem installierten Paket bzw. Repository zu benennen:

sudo apt-key export 68576280 | sudo gpg --dearmour -o /etc/apt/trusted.gpg.d/nodejs-key.gpg
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).

sudo apt-key export 86E50310 | sudo gpg --dearmour -o /etc/apt/trusted.gpg.d/yarn-key.gpg
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).

sudo apt-get update

Nun sollten die Warnungen der Vergangenheit angehören.

Neue Schlüssel hinzufügen

Sollte ein neuer Schlüssel hinzugefügt werden, wird in Zukunft nicht mehr mit apt-key gearbeitet, sondern gpg verwendet werden.

Früher

curl -sS https://download.spotify.com/debian/pubkey_5E3C45D7B312C643.gpg | sudo apt-key add -


Heute

curl -sS https://download.spotify.com/debian/pubkey_7A3A762FAFD4A51F.gpg | sudo gpg --dearmor --yes -o /etc/apt/trusted.gpg.d/spotify.gpg

 

  •  

Sicheres Homeoffice und Remote Working

Hybrides Arbeiten ist das Modell der Zukunft. Andrea Wörrlein, Geschäftsführerin von VNC in Berlin und Verwaltungsrätin der VNC AG, in Zug erklärt in einem Gastbeitrag die wichtigsten Merkmale sicherer Anwendungen für den neuen Arbeitsplatz-Mix aus Präsenzarbeit, Homeoffice und mobilem Arbeiten.

  •  

Kooperationen um AG KRITIS erweitert

Do-FOSS bettet sich weiter in bestehende gesellschaftliche Strukturen ein. Nachdem bereits die Free Software Foundation Europe, die FOSS-AG, das Offene Kommunen.NRW Institut (OK.NRW), der ver.di Bezirk Westfalen, die Document Foundation, digitalcourage, die Open Source Business Alliance, Pauluskirche und Kultur und das Klimabündnis Dortmund als Kooperationen aufgeführt sind, erweitern wir unser Wissens- und Handlungsnetzwerk um die AG KRITIS.

Die AG KRITIS ist vollständig unabhängig von Staat oder Wirtschaft und vertritt als Ziel einzig und allein, die Versorgungssicherheit der Bevölkerung zu erhöhen. Die Mitglieder der AG KRITIS sind Fachleute und Expert*innen, die sich täglich mit Kritischen Infrastrukturen (KRITIS) beschäftigen. Die AG KRITIS ist der Auffassung, dass die Ressourcen der Bundesrepublik zur Reaktion auf Großschadenslagen durch Cyber-Vorfälle im Bereich der Kritischen Infrastrukturen nicht ausreichen, um die Auswirkungen der dadurch verursachten Krisen und Katastrophen zu bewältigen. Eine wesentliche politische Position der AG KRITIS lautet, dass im KRITIS-Umfeld eingesetzte Software grundsätzlich quelloffen gestaltet sein soll.

CC0
Soweit im gesetzlichen Rahmen möglich verzichtet der Autor auf alle Urheber- und damit verwandten Rechte an diesem Werk.
Es kann beliebig genutzt, kopiert, verändert und veröffentlicht werden.
Für weitere Informationen zur Lizenz, siehe hier.

The post Kooperationen um AG KRITIS erweitert appeared first on Do-FOSS.

  •  
❌