Beginnend in der Nacht vom 31.01.2021 zum 01.02.2021 erreichten uns vermehrt Anfragen zu von der DNS RBL spamcop.net abgewiesenen E-Mails.

Die Ursache dafür ist so schlicht wie bemerkenswert: die von vielen Administratoren eingesetzte DNS RBL spamcop.net funktionierte nicht mehr und liefert für alle Mails ein - fälschlicherweise - positives Ergebnis. Wie z. Bsp. Bleepingcomputer in seiner Meldung berichtet, hat es CISCO Systems einfach vergessen, die Domain beim zuständigen Registrar zu verlängern. So etwas sollte nicht passieren. Die DNS RBL spamcop.net wird an vielen Stellen, so. z. Bsp. in den Firewalls der Firma Ironport (welche wiederum zu CISCO Systems gehört) eingesetzt. Die Reichweite und Auswirkung eines solchen - an sich lapidaren - Fehlers ist dementsprechend groß.

Mit Bekanntwerden der Störungsursache haben wir am 01.02.2021 zwischen 11 und 12 Uhr vorsorglich die Verwendung der DNS RBL bl.spamcop.net in allen von uns betriebenen Systemen geprüft und ggf. deaktiviert. Dadurch kann es zeitweise zu vermehrter Zustellung von nicht erkannten SPAM- E-Mails kommen. Sobald sichergestellt ist, dass bl.spamcop.net wieder korrekt funktioniert, werden wir diese wieder aktivieren.

Update:

Am 2.2.2021 - 16:30 Uhr wurde die DNS BL bl.spamcop.net geprüft und auf Test- bzw. Demosystemen zur Kontrolle wieder aktiviert.

Die Funktionsprüfung am 3.2.2021 - 7:30 war erfolgreich.

Am 3.2.2021 - 7:45 Uhr wurde die DNS BL bl.spamcop.net wieder auf allen relevanten Systemen aktivier.

Aufgrund der nicht korrekten Einhaltung von Richtlinien zur Ausstellung entzieht DigiCert TLS-Zertifikaten das Vertrauen.

Die Zertifikate müssen bis 11.07.2020 um 20:00 Uhr MESZ ersetzt werden. Die Information erreichte uns sehr kurzfristig, sodass dringender Handlungsbedarf bei allen Kunden besteht, die EV-Zertifikate einsetzen. Davon betroffen sind Zertifikate folgender Aussteller:

• CertCentral
• Symantec
• Thawte
• GeoTrust

bzw. alle Zertifikate, die von folgenden Root-CAs unterschrieben wurden

• DigiCert Global CA G2
• GeoTrust TLS RSA CA G1
• Secure Site CA
• Thawte TLS RSA CA G1
• Cybertrust Japan Secure Server ECC CA
• DigiCert Global CA G3
• GeoTrust TLS ECC CA G1
• Thawte TLS ECC CA G1
• NCC Group Secure Server CA G3
• Aetna Inc. Secure CA2
• DigiCert SHA2 High Assurance Server CA
• NCC Group Secure Server CA G2
• Plex Devices High Assurance CA2
• TERENA SSL High Assurance CA 3
  
  

Weiterführende Informationen:

• https://www.heise.de/news/Jetzt-handeln-DigiCert-erklaert-zehntausende-TLS-Zertifikate-fuer-ungueltig-4840972.html
• https://knowledge.digicert.com/alerts/DigiCert-ICA-Replacement

Apple, die Mozilla Foundation (FireFox) und Google haben beschlossen, dass ihre Browser für alle ab dem 01.09.2020 ausgestellten Zertifikate nur noch eine maximale Gültigkeitsdauer von einem Jahr (398 Tage, d. h. 1 Jahr + 1 Monat Karenz) akzeptieren. Damit wurde die erst von 5 Jahren auf 3 und dann auf 2 Jahre verkürzte Gültigkeitsdauer von Zertifikaten erneut beschnitten, was letztlich in einem erhöhtem Administrationsaufwand für nicht bspw. per Let's Encrypt automatisierbare Zertifikate mündet.

Begründet wird das immer wieder mit der nicht unumstrittenen Meinung der Browserhersteller, dass Mechanismen zur Gültigkeitsprüfung (wie z. Bsp. CRLs oder OCSP) ungeeignet oder sogar wirkungslos sind.

Da automatisierbare Alternativen wie Let's Encrypt aufgrund der geltenden Standards keine Class 3- oder EV- Zertifikate ausstellen dürfen, bleibt für alle Zertifikate mit Identitätsnachweis nur die jährliche Erneuerung inklsuive des damit verbundenen Aufwands.

Wir empfehlen deshalb, alle Zertifikate die bis Ende des ersten Halbjahres 2021 ablaufen, noch vor dem 01.09.2020 um die dann letzmalig möglichen 2 Jahre zu verlängern.

Mitarbeiter des Streaming- Dienstes NetFlix haben Sicherheitslücken im Netzwerkstack des Linux-Kernels entdeckt, welche sich für DoS- Angriffe ausnutzen lassen.

Die Sicherheitslücke CVE-2019-11477 (TCP SACK Panic), für die alle Linux-Kernel ab einschließlich Version 2.6.29 anfällig sind, wird von RedHat als "wichtig" eingestuft, da sich dadurch aus der Ferne eine Kernel Panic und damit ein Neustart des Systems auslösen lassen. Betroffene Systeme sollten kurzfristig aktualisiert werden.

Ob Ihr System betroffen ist, kann man unter RHEL 6/7 oder CentOS 6/7 mit dem von Red Hat bereitgestellten Script überprüfen. Das Script kann auch über den am Ende des Artikels befindlichen Link heruntergeladen werden.

Für RHEL 6/7 oder CentOS 6/7 liegen mit dem aktuellen Kernel- Versionen bereits Patches vor, die nicht mehr für o.g. Sicherheitslücken anfällig sind:

• RHEL 7 / CentOS 7: Ab Kernel Version 3.10.0-957.21.3.el7
• RHEL 6: Ab Kernel Version 2.6.32-754.15.3.el6
• CentOS 6: Derzeit noch kein aktueller Kernel verfügbar.

Eine von NetFlix als schneller Workaround empfohlene Methode für alle Systeme ist die Kontrolle der SACK-Pakete mittels entsprechender Regeln:

-A INPUT -p tcp -m tcpmss --mss 1:500 -j DROP

Alternativ kann man TCP SACK auch komplett deaktivieren:

echo 0 >  /proc/sys/net/ipv4/tcp_sack

Permanent sind diese Einstellungen per sysctl möglich. Dazu sind in /etc/sysctl.conf folgende Ergänzungen nötig:

net.ipv4.tcp_sack = 0
net.ipv4.tcp_dsack = 0
net.ipv4.tcp_fack = 0

Diese Einstellungen können anschließen mittels sysctl -p aktiviert werden und bleiben auch nach einem Neustart des Systems wirksam.

Nach unserer Einschätzung dürften diese Lücken künftig eher zu Angriffen auf im Internet erreichbare IoT-Geräte ausgenutzt werden, da diese in vielen Fällen keine oder nur verspätete Updates durch die Hersteller erhalten. Serversysteme, die im Internet auch per ICMP oder SSH erreichbar sind, lassen sich mit einfachen DoS-Amplification Angriffen seit jeher überlasten. Wir empfehlen die zeitnahe Aktualisierung des Kernels und den vorsorglichen Einsatz der Filterregeln zur Vermeidung einer "Kernel Panic".

Weiterführende Informationen:

• NetFlix: https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001.md
• Red Hat: https://access.redhat.com/security/vulnerabilities/tcpsack
• Red Hat Test Script: https://access.redhat.com/sites/default/files/cve-2019-11477--2019-06-17-1629.sh
• Ubuntu: https://usn.ubuntu.com/4017-1
• Debian: https://www.debian.org/security/2019/dsa-4465
• SUSE: https://www.suse.com/de-de/support/kb/doc/?id=7023928
• Cloudflare: https://twitter.com/jgrahamc/status/1140724787242819585
• Amazon: https://aws.amazon.com/security/security-bulletins/AWS-2019-005

Mozilla hat es es versäumt, interne Zertifikate für Firefox rechtzeitig zu erneuern. In der Folge werden Add-Ons als ungültig deaktiviert, weil die Zertifikate nicht mehr stimmen:

• https://discourse.mozilla.org/t/fixed-certificate-issue-causing-add-ons-to-be-disabled-or-fail-to-install/39047
• https://blog.mozilla.org/addons/2019/05/04/update-regarding-add-ons-in-firefox

In der Zwischenzeit sollten die von Mozilla angekündigten Updates Firefox 66.0.4 für Desktop und Android sowie Firefox 60.6.2 ESR verfügbar sein, die diesen Fehler beheben. Unabhängig von den Updates gibt es folgende Workarounds für ältere Versionen:

Für alle Nutzer älterer ESR Versionen ist folgendes zu tun, bis die Zertifikate erneuert sind:

• Add-Ons deaktiviert lassen, auf keinen Fall deinstallieren
• Konfiguration öffnen: about:config
• Einstellung ändern: xpinstall.signatures.required = false
• FF neu starten

Für neuere Versionen ist ein inoffizieller Hotfix erhältlich:

• https://storage.googleapis.com/moz-fx-normandy-prod-addons/extensions/hotfix-update-xpi-intermediate%40mozilla.com-1.0.2-signed.xpi

Die Erweiterung kann folgendermassen installiert werden:

• .xpi mit einem anderen Browser runterladen
• In FF über "Erweiterung as Datei installieren" installieren
• FF neu starten

Nach den bereits im Januar veröffentlichen Spectre-Lücken sind jetzt 3 weitere Angriffsvektoren bekannt geworden. Die drei neuen Sicherheitsücken hören auf die Namen:

• Foreshadow (L1 Terminal Fault — SGX) / CVE-2018–3615
• L1 Terminal Fault — OS Kernel, SMM / CVE-2018–3620
• L1 Terminal Fault — Virtual Machines / CVE-2018–3646

Alle Sicherheitslücken ermöglichen, dass Angreifer aus ihren zugewiesenen Speicherbereichen ausbrechen und Daten bzw. Speicherbereiche anderer Prozesse auslesen können, auf die sie eigentlich keinen Zugriff haben sollten. Das ist insbesondere für Serviceprovider kritisch, da hier mehrere VMs von verschiedenen Kunden auf einem physischen Host laufen.

Für die von managedhosting.de betriebene Infrastruktur auf Basis von VMware vSphere hat der Hersteller umfassende Updates zur Schließung der Sicherheitslücke bereitgestellt. Aktuell arbeiten wir bereits an der Aktualisierung der betroffenenen Komponenten. Die Updates der Managed Service Plattformen sowie der vCloud - Director Selfservice Datacenter werden nach jetzigem Stand bis zum 31.08.2018 abgeschlossen sein.

Weiterführenden Informationen finden Sie in der VMware- Wissensdatenbank in folgenden Artikeln:

• https://kb.vmware.com/s/article/54913
• https://kb.vmware.com/s/article/55636
• https://kb.vmware.com/s/article/55767
• https://kb.vmware.com/s/article/55806