Normale Ansicht

Firefox - Cookie-Dialog-Blocker aktivieren

22. November 2023 um 12:21

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

22. Oktober 2023 um 16:00

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

24. August 2010 um 06:58

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

03. August 2010 um 07:39

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

19. Januar 2023 um 17:24

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

 

Kooperationen um AG KRITIS erweitert

23. Oktober 2021 um 20:39

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.

Studie: Schwachstellen in Open-Source-Software bleiben in der Regel vier Jahre unentdeckt

03. Dezember 2020 um 06:39

Patches stehen in der Regel innerhalb von vier Wochen zur Verfügung. Zudem sind nur 17 Prozent der registrierten Sicherheitslücken als "schädlich" einzustufen. GitHub sieht Open-Source-Software als "kritische Infrastruktur" an.

WordPress Sicherheit erhöhen: Schritt für Schritt

Von:Benni
25. Januar 2018 um 19:23

Die Sicherheit einer Webseite ist ein sehr wichtiges Thema. Man muss sich stets darum kümmern, auch wenn es lästig sein kann. Wer seine Webseite mit WordPress betriebt hat es auf der einen Seite sehr einfach, auf der anderen Seite aber auch wieder schwierig.

Die Sicherheitsvorteile, die WordPress mit sich bringt

WordPress ist sehr weit verbreitet. Millionen von Webseite laufen über diese Software. Die Entwicklung findet in einer sehr aktiven Community statt. Darin sind viele Sicherheitsexperten, die sich um das Beheben von Sicherheitslücken kümmern. Da diese Software so stark entwickelt wird, bleiben Sicherheitslücken nicht lange offen sondern werden zeitnah geschlossen.

Durch die Popularität von WordPress wird es für Angreifer aber auch wieder attraktiv, die Software zu knacken. Denn hat man einmal eine Lücke gefunden, kann man sie bei vielen Webseiten verwenden. Und schon sind wir beim typischen Katz-und-Maus-Spiel zwischen Hackern und Sicherheitsexperten.

Die Sicherheit von WordPress erhöhen

Mit den folgenden Artikeln habe ich Möglichkeiten gezeigt, wie man typische Eintrittstore von WordPress ausfindig macht und wie man wieder schließen kann. Die Goldene Regel der Sicherheit für jegliche Software lautet: Updates installieren, Updates installieren und Updates installieren. Alles weitere habe ich in einzelnen Artikeln zusammengefasst.

WordPress sichern mit .htaccess

htaccess mit FTP hochladen Mit der Datei .htaccess auf dem Webserver kann man WordPress serverseitig absichern. Die Angreifer möchten mit ihren Botnetzen das Passwort der Benutzer erraten. Wenn wir unsere Anmeldeseite von WordPress einfach hinter die abschließbare Tür unseres Servers packen, erhöhen wir die Eintrittshürde für Angreifer erheblich. Wie das geht und wie man das ganz genau Installiert, habe ich in einer Schritt-für-Schritt-Anleitung zusammengefasst.

WordPress: xmlrpc.php deaktivieren

xmlrpc in WordPress deaktivierenBei Softwareentwicklern und auch bei Angreifern ist die xmlrpc.php von WordPress sehr beliebt. Sie ist eine Schnittstelle für die Entwickler, worüber sie auf viele Funktionen von WordPress zurückgreifen können. Für Hacker ist das ein gefundenes fressen, denn sie können die Datei verwenden, um massenhaft Passwortanfragen zu stellen. In dieser Anleitung erkläre ich, warum die xmlrpc.php so gefährlich ist und wie man sie deaktivieren kann.

WordPress Sicherheitslücken finden mit wpscan

Die Goldene Regel der Sicherheit lautet Updates, Updates, Updates. Doch manchmal verliert man den Überblick über die Software, die in WordPress so eingebunden wird. Dazu zählen natürlich die Plugins, aber auch die Themes von WordPress. Man kann nicht nur im Backend von WordPress erkennen, welche Softwareversion die Plugins haben. Auch über das Frontend bzw. Schnittstellen vom Server kann man die Softwareversionen, und damit den Sicherheitsstatus, erkennen. Was man mit dem Programm wpscan so alles sieht und wie man es verwendet, wird in dieser Anleitung erklärt.

The post WordPress Sicherheit erhöhen: Schritt für Schritt first appeared on bejonet.

WordPress xmlrpc.php deaktivieren

Von:Benni
24. Januar 2017 um 18:24

WordPress ist ein weit verbreitetes Content-Management-System. Eine sehr große Anzahl an Webseiten weltweit werden damit erstellt. Früher war es rein für Blogs gedacht, doch der weite Umfang der Funktionen, die einfache Handhabbarkeit und die Vielzahl an Erweiterungen hat dazu geführt, dass auch vollwertige Webseiten auf WordPress aufbauen.

Viele der Administratoren sind Laien und lassen sich von der Einfachheit der Software überzeugen. Leider werden so auch oft Updates vernachlässigt und sich auch sonst sehr wenig um die Sicherheit gekümmert. Diese Faktoren – starke Verbreitung, laienhafte Admins, Vielzahl an Plugins – macht WordPress auch attraktiv für Angreifer.

Bruteforce-Angriffe sind bei WordPress-Admins sehr bekannt. Unbekannte versuchen, häufig mit osteuropäischen IPs, durch plumpes Raten die Passwörter zu erhalten. Dabei setzen sie Bots ein, die selbstständig lange Listen an Passwortvorschlägen abarbeiten und so hoffen, das richtige Passwort zu erraten. Der Schutz der wp-login.php über .htaccess ist zumindest der erste Schritt, dieses Verfahren einzudämmen. Doch es gibt noch ein weiteres, sehr großes Fenster, über das Angreifer Eintritt suchen: die xmlrpc.php.

Angreifern von WordPress keine Chance geben

Was ist die xmlrpc.php?

Unter XML-RPC (Extensible Markup Language Remote Procedure Call) versteht man eine Schnittstelle zwischen einem System (hier WordPress) und externen Funktionen. Sie kümmert sich beispielsweise um Pingbacks, also ein- und ausgehende Mitteilungen von anderen Webseiten. Außerdem greifen verschiedene Plugins (wie beispielsweise Jetpack) oder Apps darauf zu. Es ist sozusagen die Schnittstelle zur Außenwelt.

Das wird uns Betreibern nur dann zum Verhängnis, wenn jemand versucht sie zu missbrauchen. Denn abgesehen von den gewollten Funktionen kann man diese Schnittstelle auch für Bruteforce Methoden verwenden. Hier können Angreifer gleich eine Vielzahl an Passwörtern ausprobieren, um das richtige zu erraten.

Seit WordPress 3.5 ist die Datei standardmäßig aktiviert. Vorher musste man im Admin-Panel  die Funktion aktivieren.

Warum sollte man die xmlrpc.php deaktiveren?

Die xmlrpc.php hat die primäre Funktion, WordPress zu vernetzen und Funktionen von außerhalb des Admin-Panels zu verwenden. Etliche Plugins brauchen diese Funktion, doch lange nicht jeder Benutzer verwendet solche Erweiterungen. Gerade wer WordPress eher als statische Seite verwendet, kann in der Regel auf die Funktionen der xmlrpc.php verzichten. In diesem Fall bietet sie Angreifern eine potentielle Zielscheibe und macht damit die Seite unsicher.

xmlrpc in WordPress deaktivieren

So deaktiviert man die xmlrpc.php in WordPress

Es gibt zwei Wege, wie man die Datei sinnvoll deaktiviert. Der erste davon beschreibt, wie man die Funktion „von innen heraus“ deaktiviert. Dazu editiert man die functions.php des aktuellen Themes und fügt dort folgenden Codeschnipsel hinzu.

/* Disable XMLRPC */
add_filter( 'xmlrpc_enabled', '__return_false' );

Die zweite Variante verhindert den Zugriff auf die Datei grundsätzlich. Hierzu ergänzt man die .htaccess-Datei, die man schon zur Beschränkung der wp-login.php verwendet hat, um folgende Textzeilen.

<Files xmlrpc.php>
 Order Deny,Allow
 Deny from all
 </Files>

Jetzt ist intern die Dateifunktion deaktiviert und auch von außen kann niemand mehr darauf zugreifen. Um seinen Erfolg zu überprüfen, kann man mit wpscan seine WordPress-Installation auf Sicherheitslücken überprüfen und so sehen, ob die xmlrpc.php noch zugänglich ist.

Weitere Schutzmaßnahmen

Die wichtigsten Schutzmaßnahmen für WordPress sind die gleichen wie für jede andere Anwendung auch: Verwendet sichere Passwörter und haltet die Software auf dem neuesten Stand, vor allem wenn sicherheitsrelevate Updates erschienen sind.

The post WordPress xmlrpc.php deaktivieren first appeared on bejonet.

❌