trueten.de

Nur ein kurzer Bookmark für eine ausführliche Anleitung, wie mittels dem pfBlocker NG Plugin Werbung usw. direkt an der Firewall blockiert werden kann. Noch etwas weiter geht dieser Beitrag, der auch beschreibt, wie mittels Zugriffslisten Angriffe oder Scans auf die Firewall blockiert werden können. Zusammen mit Browserplugins wie ublockorigin ergeben sich dann endlich Werbefreie Seiten.

Für kleinere Netze wäre ein derart komplexes Konstrukt Overkill, hier empfiehlt sich piHole, gerade auch in Verbindung mit einem VPN.

Es liegt ja nicht unbedingt nahe, andauernd die Firmware beispielsweise des Unifying-Receivers usw. zu aktualisieren. Angesichts der Angriffsmöglichkeiten sollte mensch das aber auch als Linux User machen. Windows Programme sind dazu nichjt nötig, das geht in 3 Schritten einfacher mit fwupd. Eventuell sogar als cronjob, um zum Thema Faulheit zurückzukehren.

• Die aktuelle Liste der Firmware abrufen: sudo fwupdmgr get-updates

• Die Liste der angeschlossenen Geräte anzeigen: sudo fwupdmgr get-devices

• Firmware aktualisieren: sudo fwupdmgr update

Der Status einer günstigen unterbrechungsfreien Stromversorgung (USV), in dem Fall eine (Green Cell® UPS USV Unterbrechungsfreie Stromversorgung 600VA (360W)) soll mittels Nagios abgefragt werden. Das UPS Modell ist mit dem Network UPS Tools (NUT) Treiber blazer_usb kompatibel. Die USV versorgt einen Clientrechner client.lan, Nagios ist auf einem Server server.lan installiert. Unter debian bzw. seinen Ablegern lässt sich die nötige Software auf dem Clientrechner wie gehabt installieren:

sudo apt install nut

Irgendwelche Abhängigkeiten sollten natürlich aufgelöst werden. Danach editieren wir die Datei /etc/nut/ups.conf und fügen am Ende folgende Definition für die GreenCell UPS ein:

[GreenCell]
        driver = "blazer_usb"
        port = "auto"
        desc = "GreenCell USV 600VA"

Die Datei /etc/nut/nut.conf editiert man dann entsprechend dem Verwendungszweck (Standalone/Netzserver/-client)

# Network UPS Tools: example nut.conf
#
##############################################################################
# General section
##############################################################################
# The MODE determines which part of the NUT is to be started, and which
# configuration files must be modified.
#
# This file try to standardize the various files being found in the field, like
# /etc/default/nut on Debian based systems, /etc/sysconfig/ups on RedHat based
# systems, ... Distribution's init script should source this file to see which
# component(s) has to be started.
#
# The values of MODE can be:
# - none: NUT is not configured, or use the Integrated Power Management, or use
#   some external system to startup NUT components. So nothing is to be started.
# - standalone: This mode address a local only configuration, with 1 UPS 
#   protecting the local system. This implies to start the 3 NUT layers (driver,
#   upsd and upsmon) and the matching configuration files. This mode can also
#   address UPS redundancy.
# - netserver: same as for the standalone configuration, but also need
#   some more network access controls (firewall, tcp-wrappers) and possibly a
#   specific LISTEN directive in upsd.conf.
#   Since this MODE is opened to the network, a special care should be applied
#   to security concerns.
# - netclient: this mode only requires upsmon.
#
# IMPORTANT NOTE:
#  This file is intended to be sourced by shell scripts.
#  You MUST NOT use spaces around the equal sign!

MODE=standalone

Auf dem Server wird Nagios am besten aus den Quellen installiert, viele Plugins und auch das Programmpaket selber liegt meistens in recht hm... veralteten Versionen vor. Ich verweise hier mal auf ein recht aktuelles HowTo. ^^

Sobald Nagios läuft, stricken wir uns einen Befehl zum Ansprechen der UPS zusammen und editieren dazu die Datei /usr/local/nagios/etc/objects/commands.cfg

# UPS Check
#
#
define command {

    command_name check_ups
    command_line    $USER1$/check_ups -H $HOSTADDRESS$ -u GreenCell
}

Wie man unschwer erkennen kann, bezieht sich der Befehl in der vorletzten Zeile auf das in der Datei /etc/nut/ups.conf definierte Gerät. Dieser Befehl kann nun in beliebigen Serverkonfigurationen, die Nagios überwacht, angewendet werden. Wir richten nun aber erst einmal die Nagios Konfiguration des Clients ein, der durch die USV versorgt wird und editieren dazu eine neue Datei, in dem Fall nennen wir sie einfach /usr/local/nagios/etc/servers/client.lan.cfg

(...)
define service {
use                     local-service
host_name               client.lan
service_description     GreenCell UPS
check_command           check_ups!-H client.lan -u GreenCell

Ab diesem Zeitpunkt sollte der Status der UPS abgefragt werden können. Welche Werte genau abgefragt werden können ist natürlich von der jeweiligen UPS abhängig und welche Werte von Belang sind. Wie bei den meisten anderen Nagios Plugins können auch bei check_ups die möglichen Parameter durch einen Aufruf auf den Kommandozeile abgefragt werden. Hier man ein wenig Copy & Paste:

nagiosuser@server.lan:/usr/local/nagios/libexec# ./check_ups -h
check_ups v2.3.3 (nagios-plugins 2.3.3)
Copyright (c) 2000 Tom Shields
Copyright (c) 2004 Alain Richard <alain.richard@equation.fr>
Copyright (c) 2004 Arnaud Quette <arnaud.quette@mgeups.com>
Copyright (c) 2000-2014 Nagios Plugin Development Team
    <devel@nagios-plugins.org>

This plugin tests the UPS service on the specified host. Network UPS Tools
from www.networkupstools.org must be running for this plugin to work.

Usage:
check_ups -H host -u ups [-p port] [-v variable] [-w warn_value] [-c crit_value] [-e] [-to to_sec] [-T]

Options:
 -h, --help
    Print detailed help screen
 -V, --version
    Print version information
 --extra-opts=[section][@file]
    Read options from an ini file. See
    https://www.nagios-plugins.org/doc/extra-opts.html
    for usage and examples.
 -H, --hostname=ADDRESS
    Host name, IP Address, or unix socket (must be an absolute path)
 -p, --port=INTEGER
    Port number (default: 3493)
 -u, --ups=STRING
    Name of UPS
 -T, --temperature
    Output of temperatures in Celsius
 -e, --extended-units
    Allow nonstandard units in performance data (used for voltage and temperatures)
 -v, --variable=STRING
    Valid values for STRING are LINE, TEMP, BATTLEFT, BATTPCT or LOADPCT
 -w, --warning=DOUBLE
    Response time to result in warning status (seconds)
 -c, --critical=DOUBLE
    Response time to result in critical status (seconds)
 -t, --timeout=INTEGER:
    Seconds before connection times out (default: 10)
    Optional ":" can be a state integer (0,1,2,3) or a state STRING

This plugin attempts to determine the status of a UPS (Uninterruptible Power
Supply) on a local or remote host. If the UPS is online or calibrating, the
plugin will return an OK state. If the battery is on it will return a WARNING
state. If the UPS is off or has a low battery the plugin will return a CRITICAL
state.

Notes:
 You may also specify a variable to check (such as temperature, utility voltage,
 battery load, etc.) as well as warning and critical thresholds for the value
 of that variable.  If the remote host has multiple UPS that are being monitored
 you will have to use the --ups option to specify which UPS to check.

 This plugin requires that the UPSD daemon distributed with Russell Kroll's
 Network UPS Tools be installed on the remote host. If you do not have the
 package installed on your system, you can download it from
 http://www.networkupstools.org

Send email to help@nagios-plugins.org if you have questions regarding use
of this software. To submit patches or suggest improvements, send email to
devel@nagios-plugins.org

Eine am Server abgesetzte Anfrage ergibt in unserem Fall:

nagiosuser@server.lan:/usr/local/nagios/libexec# ./check_ups -H prusapi.lan -u GreenCell
UPS OK - Status=Online Utility=230,0V Batt=100,0% Load=4,0% |voltage=230,000000;;;0,000000 battery=100,000000%;;;0,000000;100,000000 load=4,000000%;;;0,000000;100,000000

Nagios verwertet diesen Schnipsel so:

---

Einige Links in diesem Beitrag sind Vorschläge / Einkaufsquellen und sog. Affiliatelinks. Wenn Du etwas über diesen Link kaufst, erhalten wir eine kleine Provision. Der Preis für Dich bleibt derselbe. Vielen Dank für Deine Unterstützung.

Some of the links are suggestions for parts to replicate the thing and affiliate. If you buy something, I get a small commission. The price you pay is the same. Thank you very much.

Ein wenig Nerdkram Folklore mit Pi-hole v5.2.1 Web Interface v5.2.1 FTL v5.3.2 und dem blockierten Werbekram. Bei über 3 Millionen Domains in der Blockliste sind 43% blockiere Anfragen schon krass...

Nach der leider bislang erfolglosen Suche nach Intelligenz, zumindest außerhalb unseres Sonnensystems via SETI haben wir uns mit dem Aufkommen der COVID-19 Pandemie auf die Suche die Suche nach Coronavirus-Medikamenten gemacht. Privatnutzer stellen Forschern die Rechenleistung ihrer PCs für Simulationen zur Verfügung – und das in beträchtlichen Mengen, denn inzwischen summiert sich deren Gesamtleistung auf mehr Rechenleistung, als die schnellsten Supercomputer der Welt einzeln.  Nach einem Systemupgrade unserer Rechner auf Linux Mint 20 war es unmöglich den aktuellen FAHControl zu starten. Das Paket python-gtk2 wurde ohne Ersatzkandidaten aus der Softwareliste gestrichen.


Linux Mint 20 UserInnen sollten diesem Ansatz folgen und einfach das passende Snap Paket installieren:

sudo snap install folding-at-home-fcole90

Wer Snaps unter Linux Mint 20 verwenden will, muss in /etc/apt/preferences.d/nosnap.pref die Blockade deaktivieren.

Zufällig findet sich hier eine Lösung, mit der zumindest bei unseren Systemen eine problemlose Installation möglich ist:

sudo aptitude install python-gobject-2 (Der aptitude Installer sollte installiert sein. Er offeriert eine Lösung, die angenommen werden sollte)

wget http://archive.ubuntu.com/ubuntu/pool/universe/p/pygtk/python-gtk22.24.0-6amd64.deb

sudo dpkg -i python-gtk22.24.0-6amd64.deb

Funktionskontrolle: /usr/bin/FAHControl oder http://127.0.0.1:7396

Quelle war die Lösung hier für Ubuntu 20.04

... linksradikale Serverprojekte beispielsweise durch eine Spende zu supporten.

„Es geht nicht um Privatsphäre, sondern es geht darum, eine Technik sozial beherrschbar zu machen.“ Dieses Datenschutzverständnis von Wilhelm Steinmüller (1934–2013), Datenschutzpionier und langjähriges FIfF-Mitglied, möchten wir, eine Gruppe Wissenschaftlerïnnen und Datenschützerïnnen im Forum InformatikerInnen für Frieden und gesellschaftliche Verantwortung (FIfF) e. V., wieder stark machen.

Seit einigen Wochen kreist die Diskussion um die Eindämmung der Corona-Pandemie zunehmend um den Einsatz technischer Hilfsmittel. Es wird geplant, die Pandemie durch den Einsatz von Tracing-Apps für Smartphones einzudämmen. Diese Systeme sollen automatisiert die zwischenmenschlichen Kontakte aller Nutzerïnnen aufzeichnen und es so erlauben, die Infektionsketten des Virus schnell und effizient nachzuvollziehen, um möglicherweise exponierte Personen frühzeitig warnen und isolieren zu können.  

Wir haben es angesichts der geplanten Corona-Tracing-Systeme mit einem gesellschaftlichen Großexperiment zur digitalen Verhaltenserfassung unter staatlicher Aufsicht in Europa zu tun. Die europäische Datenschutzgrundverordnung (DSGVO) verpflichtet die Betreiberïnnen umfangreicher Datenverarbeitungssysteme (zu denen auch ein Corona-Tracing-System zählen würde) zur Anfertigung einer Datenschutz-Folgenabschätzung (DSFA) im Falle eines hohen Risikos für die Grund- und Freiheitsrechte. Hierbei handelt es sich um eine strukturierte Risikoanalyse, die mögliche grundrechtsrelevante Folgen einer Datenverarbeitung im Vorfeld identifiziert und bewertet.

Wirksamkeit und Folgen entsprechender Apps sind noch nicht absehbar und es ist davon auszugehen, dass innerhalb der EU verschiedene Varianten erprobt und evaluiert werden. Die datenschutz- und somit grundrechtsrelevanten Folgen dieses Unterfangens betreffen potenziell nicht nur Einzelpersonen, sondern die Gesellschaft als Ganze. Aus diesem Grunde ist nicht nur die Anfertigung einer DSFA angezeigt, sondern insbesondere auch ihre Veröffentlichung – und eine öffentliche Diskussion. Da bisher keine der beteiligten Stellen eine allgemein zugängliche DSFA präsentiert hat und selbst die vorgelegten privacy impact assessments unvollständig bleiben, legen wir vom FIfF mit diesem Dokument eigeninitiativ eine solche Datenschutz-Folgenabschätzung als konstruktiven Diskussionsbeitrag vor.

Download der DSFA (Creative-Commons-Lizenz: Namensnennung, CC BY 4.0 Int.): Aktuelle Version 1.1 (PDF, 101 S., 426 kB), alte Versionen unter https://www.fiff.de/dsfa-corona

1. Die in den Diskussionen vielfach betonte Freiwilligkeit der App-Nutzung ist eine Illusion. Es ist vorstellbar und wird auch bereits diskutiert, dass die Nutzung der App als Voraussetzung für die individuelle Lockerung der Ausgangsbeschränkungen gelten könnte. Das Vorzeigen der App könnte als Zugangsbarriere zu öffentlichen oder privaten Gebäuden, Räumen oder Veranstaltungen dienen. Denkbar ist, dass Arbeitgeberïnnen solche Praktiken schnell adaptieren, weil sie mittels freiwillig umgesetzter Schutzmaßnahmen schneller ihre Betriebe wieder öffnen dürfen. Dieses Szenario bedeutet eine implizite Nötigung zur Nutzung der App und bedeutet erhebliche Ungleichbehandlung der Nicht-Nutzerïnnen. Weil nicht jede Person ein Smartphone besitzt, wäre hiermit auch eine Diskriminierung ohnehin schon benachteiligter Gruppen verbunden. Kirsten Bock vom FIfF kommentiert: „Die Einwilligung ist nicht das richtige Regelungsinstrument für die Nutzung der Corona App, weil deren Voraussetzungen nicht erfüllt sind. Der Gesetzgeber ist aufgerufen, dass Nutzungsrisiko der App nicht auf die Bürgerïnnen abzuwälzen, sondern selbst die Voraussetzungen für eine freiwillige, sichere und grundrechtsverträgliche Lösung in einem Gesetz vorzugeben und die Bürgerïnnen so vor Grundrechtsverletzungen - auch durch Dritte - wirksam zu schützen.“ Martin Rost vom FIfF ergänzt prägnant „Von einer Einwilligung geht keine Schutzwirkung für Betroffene aus."

2. Ohne Intervenierbarkeit und enge Zweckbindung ist der Grundrechtsschutz gefährdet. So besteht ein hohes Risiko fälschlich registrierter Expositionsereignisse (falsch positiv), die zu unrecht auferlegter Selbst-Isolation oder Quarantäne zur Folge haben (zum Beispiel Kontaktmessung durch die Wand zwischen zwei Wohnungen). Um dem zu begegnen, bedarf es rechtlicher und faktischer Möglichkeiten zur effektiven Einflussnahme, etwa das Zurückrufen falscher Infektionsmeldungen, die Löschung falsch registrierter Kontaktereignisse zu einer infizierten Person und das Anfechten von infolge der Datenverarbeitung auferlegter Beschränkungen. Eine solche Möglichkeit sieht bisher keines der vorgeschlagenen Systeme vor. „Beim Datenschutz geht es genauso wenig um den Schutz von Daten, wie es beim Sonnenschutz um den Schutz der Sonne geht oder beim Katastrophenschutz um den Schutz von Katastrophen.“ spitzt Jörg Pohle vom FIfF zu.

3. Alle bislang erwähnten Verfahren verarbeiten personenbezogene Gesundheitsdaten. Das Verfahren besteht aus der Verarbeitung von Kontaktdaten auf den Smartphones, der Übermittlung dieser Daten auf einen Server nach der Diagnose einer Infektion und letztendlich deren Verteilung an alle anderen Smartphones zur Prüfung auf einen möglichen Kontakt mit Infizierten. Alle Daten auf einem Smartphone sind personenbezogen, nämlich bezogen auf die Nutzerïn des Gerätes. Weil nur diejenigen Personen Daten übertragen, die als infiziert diagnostiziert wurden, sind die übertragenen Daten zugleich Gesundheitsdaten. Somit unterliegen diese dem Schutz der DSGVO.

4. Anonymität der Nutzerïnnen muss in einem Zusammenspiel rechtlicher, technischer und organisatorischer Maßnahmen erzwungen werden. Nur durch einen mehrdimensionalen Ansatz kann der Personenbezug wirksam und irreversibel von den verarbeiteten Daten abgetrennt werden, so dass danach von anonymen Daten gesprochen werden kann. Allen derzeit vorliegenden Vorschlägen fehlt es an einem solchen expliziten Trennungsvorgang. "Wenn man sich hier nur auf technische Maßnahmen oder allein auf politische Beteuerungen verlässt, besteht ein großes Risiko der nachträglichen De-Anonymisierung." so Rainer Mühlhoff vom FIfF. Wir haben in dieser DSFA rechtliche, technische und organisatorische Anforderungen formuliert, deren Umsetzung in der Praxis eine wirksame und irreversible Trennung sicherstellen kann – nur unter diesen Voraussetzungen dürften die infektionsanzeigenden Daten ohne Personenbezug (iDoP) an alle Apps verbreitet werden.

Wesentliche Voraussetzung für Transparenz bezüglich der Umsetzung aller Datenschutz-Grundsätze nicht nur für Datenschutzaufsichtsbehörden, sondern gerade auch für die Betroffenen und die (Zivil-)Gesellschaft insgesamt ist die quelloffene Entwicklung von Server und Apps nebst allen ihren Komponenten beispielsweise als freie Software. Nur so kann es gelingen, Vertrauen auch bei jenen zu erzeugen, die nicht alle informationstechnischen Details verstehen. Ergriffene Maßnahmen müssen immer aktiv prüfbar gemacht und sauber dokumentiert werden.

Datenschutzanalysen betrachten die gesamte Verarbeitung von Daten, nicht nur die dabei eingesetzten Apps. „Die Grenzen der App sind nicht die Grenzen der Verarbeitung.“ erläutert Christian Ricardo Kühne vom FIfF. In der öffentlichen Diskussion und in den betrachteten App-Projekten wird Datenschutz nach wie vor auf den Schutz der Privatsphäre, also Geheimhaltung gegenüber Betreiberïnnen und Dritten, und auf Aspekte der IT-Sicherheit wie Verschlüsselung reduziert. Mit dieser Verengung der Sichtweise kommen die erheblichen, gesellschaftlich wie politisch fundamentalen Risiken, die wir in dieser Folgeabschätzung aufzeigen, nicht nur nicht in den Blick – sie werden zum Teil sogar verschleiert. „Aus dem Blickwinkel des Datenschutzes gehen die wesentlichen Risiken nicht von Hackerïnnen oder anderen Benutzerïnnen aus, sondern von den Betreiberïnnen des Datenverarbeitungssystems selbst.“ kommentiert abschließend Rainer Rehak, Vorstandsmitglied des FIfF.

Das Forum InformatikerInnen für Frieden und gesellschaftliche Verantwortung (FIfF) e. V. ist ein deutschlandweiter Zusammenschluss von gut 700 Menschen, die sich kritisch mit Auswirkungen des Einsatzes der Informatik und Informationstechnik auf die Gesellschaft auseinandersetzen. Unsere Mitglieder arbeiten überwiegend in informatiknahen Berufen, vom IT-Systemelektroniker bis hin zur Professorin für Theoretische Informatik. Das FIfF wirkt seit 1984 in vielen technischen und nichttechnischen Bereichen der Gesellschaft auf einen gesellschaftlich reflektierten Einsatz von informationstechnischen Systemen zum Wohle der Gesellschaft hin. Zu unseren Aufgaben zählen wir Öffentlichkeitsarbeit, sowie Beratung und das Erarbeiten fachlicher Studien. Zudem gibt das FIfF vierteljährlich die „FIfF-Kommunikation – Zeitschrift für Informatik und Gesellschaft“ heraus und arbeitet mit anderen Friedens- sowie Bürgerrechtsorganisationen zusammen.

Quelle

Gestern erschien das Update unserer Blogsoftware auf die Version 2.3.3. Das Update verlief wie immer problemlos.

This bugfix release Serendipity 2.3.3 will bring you quite some smaller and larger fixes and minor enhancements backported from our master branch:

• Update bundled event_mailer plugin to support forcibly sending mails on published blog entries and add the ability to prepend a mail body. Also fixes missing "keep strip tags" configuration option.


• Media Library: Checkboxes allow you to insert multiple media files in a kind of gallery. Fall back to single-asset view when just one file has been selected. Let checkboxes be selected when clicking on the asset title, and hide the the 'Insert all' button when no assets are selected.


• Media Library: Use the <video> tag for videos in the library and for inserting them into an entry.


• Media Library: Allow plugins to skip HTML block insertion to use their own markup.


• Fix: Media Library: Items that are not images now get the correct link.


• Fix: Media Library: Prevent renaming an asset into an existing file, resulting in deletion of both from disk and database.


• Fix: Media Library: Remember directory from last upload.


• Fix: Media Library: Missing variable initialisation when removing empty folders.


• Fix: Stop generation of default page every time when serving JS (functions_routing.php).


• Fix: Don't allow requesting an archive page that doesn't exist.
  Thanks to @lotharsm!


• Fix: Add valid HTTP referrer when trying to delete a trackback from the frontend.


• Fix: Update bundled plugin plugin_comments to wrap text at word boundaries only, removing spurious whitespace in comment output.


• Fix: Update bundled plugin event_bbcode to get roman numerals working.
  Thanks to Fabien Chabreuil!


• Fix: Force positive limits for number of entries shown on title page and in RSS feed and fix potential SQL error with limit set to 0 in serendipity_fetchEntries().


• Fix: Escape version string in update notifier to avoid potential for XSS.

You can download the release file and unzip it to your installation as usual, or update from within Serendipity using the Serendipity Autoupdate Plugin (serendipity_event_autoupdate).

Seit ein paar Tagen läuft das Blog mit Serendipity 2.3.2 und PHP 7.1.33. Merkwürdigkeiten bitte wie immer per Mail oder XMPP melden.

Auf einem Mailserver hier läuft der Open Source Virenscanner Clamav. Von Haus aus - verglichen mit kommerziellen Virenscannern - nicht mit einer besonders hohen Erkennungsrate gesegnet, lässt sich dieser jedoch mit Virenkennungen von Drittanbietern aufrüsten. Seit einigen Jahren ist für mich dabei der ClamAV Unofficial Signatures Updater von eXtremeSHOK, über den ich bei Alex gestolpert bin, eindeutiger Favorit. Auch wenn die aktuelle Version von 2017 ist, seinen Job macht es stabil und richtig: Die gewählten Virenkennungen lädt es nach wie vor bei diversen Anbietern herunter, es bleibt ClamAV überlassen, diese anzuwenden:

• SaneSecurity 
• SecuriteInfo
• Linux Malware Detect
• Malware Patrol

Bei den Kennungen für yara löst ein Eintrag jedoch Fehler aus:

LibClamAV Error: yyerror(): /var/lib/clamav/maldoc_somerules.yar line 235 undefined identifier "uint32be"
LibClamAV Warning: cliloadyara: failed to parse or load 1 yara rules from file /var/lib/clamav/maldocsomerules.yar, successfully loaded 14 rules.

Nun kann man entweder die betreffende Datei löschen und gut ist es oder einfach den fehlerhaften Eintrag bearbeiten. Ich habe bei mir letzteres getan und erhalte mir somit die Kennungen. Einfach mit einem Editor /var/lib/clamav/maldoc_somerules.yar öffnen, nach uint32be suchen und diese Zeile löschen oder einkommentieren.

Nach dem Abspeichern den Dienst zum erneuten Laden der Virenkennungtsdatenbank veranlassen:

sudo service clamav-daemon reload-database

Das editieren des Eintrags bringt nichts, die fehlerhafte Definition wird mit dem nächsten Update wieder installiert. Wie es aussieht hilft zur Zeit nur der Tipp von Vladki77:

Edit /etc/clamav-unofficial-sigs/master.conf and set:
yararulesproject_enabled="no"
enable_yararules="no"
And delete *.yar and *.yara from /var/lib/clamav/

Sehr schade, sobald sich da (hoffentlich) etwas ändert, vermerke ich das hier.

Alex hat auch zusammengefasst, wie die Erkennungsrate von Spamassassin deutlich erhöht werden kann.