PCI-DSS-Scan: Warum Scanner veraltete Versionen melden
Verlangt dein Zahlungsdienstleister einen PCI-DSS Payment Card Industry Data Security Standard — Sicherheitsstandard der Kreditkartenbranche für alle Systeme, die Kartenzahlungen verarbeiten. -Scan, meldet der Bericht fast immer „veraltete” Software — meist zu Unrecht. Die Enterprise-Linux-Systeme auf unseren Servern erhalten Sicherheits-Fixes per Backporting: Der Fix ist eingespielt, die Versionsnummer bleibt alt. Dieser Artikel zeigt, wie du das dem Scan-Anbieter nachweist — und wie ein Scan bei rack::SPEED abläuft.
Warum meldet der Scanner veraltete Versionen?
Abschnitt betitelt „Warum meldet der Scanner veraltete Versionen?“Enterprise-Linux-Distributionen wie AlmaLinux und CloudLinux spielen Sicherheits-Fixes per Backporting Der Distributor portiert den Sicherheits-Fix einer neuen Version in die ausgelieferte stabile Version zurück — ohne Versionssprung. ein. Statt auf die neueste Hauptversion zu springen, wird nur der Fix in die stabile Paketversion übernommen. Das hält Server stabil: keine Breaking Changes, kein Konfigurationsbruch, keine neuen Funktionen, die Compliance-Vorgaben verletzen könnten.
Die Kehrseite: Die Versionsnummer verrät den Patch-Stand nicht. Ein Scanner, der nur Versions-Strings vergleicht, hält ein vollständig gepatchtes OpenSSH 8.7 für verwundbar — ein klassischer False Positive. Red Hat erklärt das Prinzip ausführlich in der Backporting-Dokumentation; sie ist auch der übliche Nachweis gegenüber Scan-Anbietern.
Was PCI DSS 4.0 grundsätzlich von Shop-Betreibern verlangt, fasst unser Blog-Beitrag PCI DSS 4.0 — was du jetzt wissen musst zusammen.
Fix nachweisen: der Errata-Abgleich
Abschnitt betitelt „Fix nachweisen: der Errata-Abgleich“So prüfst du ein Finding und entkräftest es beim Scan-Anbieter:
- Such die CVE Common Vulnerabilities and Exposures — standardisierte Kennung für bekannt gewordene Sicherheitslücken, z. B. CVE-2024-6387. -Nummer des Findings im Scan-Bericht heraus.
- Ruf errata.almalinux.org auf und such nach der CVE-Nummer.
- Lies aus dem Errata-Eintrag die Paketversion ab, die den Fix enthält — z. B.
openssh-server-8.7p1-38.el9_4.1. - Vergleich mit der installierten Version, per SSH:
rpm -q openssh-server. Gleich oder neuer heißt: Der Fix ist drin. - Reich den Errata-Link beim Scan-Anbieter als False-Positive-Nachweis ein (Dispute-Verfahren).
Nicht jedes CVE braucht einen Fix: Manche Lücken betreffen die Enterprise-Pakete gar nicht („not affected”), andere stuft der Distributor als geringes Risiko ein und patcht bewusst nicht. Beides dokumentiert die CVE-Datenbank von Red Hat — auch das ist ein gültiger Nachweis.
So läuft ein PCI-DSS-Scan bei rack::SPEED ab
Abschnitt betitelt „So läuft ein PCI-DSS-Scan bei rack::SPEED ab“- Kündige den Scan per Ticket im Kundencenter an — mit Scan-Anbieter und Zeitraum.
- Wir schalten die IP-Bereiche des Scanners befristet in Firewall und IDS Intrusion Detection System — erkennt Angriffsmuster im Traffic und sperrt auffällige Quellen automatisch. frei. Ohne Freischaltung blockt die automatische Abwehr den Scan.
- Starte den Scan im Portal deines Anbieters.
- Geh den Bericht mit uns durch: Echte Findings beheben wir serverseitig, für False Positives bekommst du die Nachweise.
Wenn etwas schiefläuft
Abschnitt betitelt „Wenn etwas schiefläuft“Der Scan bricht ab oder meldet „scan interference”
Abschnitt betitelt „Der Scan bricht ab oder meldet „scan interference”“Die automatische Abwehr des Servers hat den Scanner als Angreifer eingestuft und gesperrt — aus ihrer Sicht völlig korrekt.
Lösung: Scan per Ticket ankündigen und die Freischaltung abwarten. Danach den Scan im Anbieter-Portal neu starten.
Der Scanner meldet veraltetes OpenSSH oder OpenSSL trotz aktueller Updates
Abschnitt betitelt „Der Scanner meldet veraltetes OpenSSH oder OpenSSL trotz aktueller Updates“Der Klassiker: Der Scanner vergleicht nur Versionsnummern und übersieht das Backporting.
Lösung: Errata-Abgleich wie oben beschrieben und den Nachweis im Dispute-Verfahren einreichen. Auf Wunsch stellen wir die Stellungnahme zusammen.
Der Fragebogen bemängelt Fernzugriff per SSH
Abschnitt betitelt „Der Fragebogen bemängelt Fernzugriff per SSH“PCI-DSS fragt, ob Remote-Zugriff nötig ist und wie er abgesichert wird — das ist kein Finding, sondern eine Begründungspflicht.
Lösung: Notwendigkeit begründen (Deployment, Administration) und die Schutzmaßnahmen nennen: Key-Authentifizierung statt Passwort, Protokollierung, automatischer Brute-Force-Schutz. Eine Formulierungshilfe bekommst du per Ticket.
Der Bericht listet weitere Server-Findings
Abschnitt betitelt „Der Bericht listet weitere Server-Findings“Einzelne Findings betreffen die Server-Konfiguration selbst — etwa erlaubte Alt-Protokolle oder erreichbare Standard-Dienste.
Lösung: Schick uns den Bericht per Ticket. Wir bewerten jedes Finding und passen die Server-Konfiguration an, wo es nötig ist.
Verwandte Artikel
Abschnitt betitelt „Verwandte Artikel“- WAF: Die Schutzschilde deiner Website — der Sicherheits-Stack, der auch Scanner blockt.
- Imunify: Malware-Prüfung im Panel — laufende Malware-Scans auf dem Server.
- IP gesperrt: kein Zugriff auf dein Projekt — wenn die automatische Abwehr zuschlägt.
- HTTPS erzwingen: HTTP auf HTTPS umleiten — Grundvoraussetzung für jeden Compliance-Scan.
Du kommst nicht weiter?
Abschnitt betitelt „Du kommst nicht weiter?“Steht ein Scan an oder liegt ein Bericht mit Findings vor? Eröffne ein Ticket im Kundencenter — nenn Scan-Anbieter, Zeitraum und häng den Bericht an. Den Rest klären wir gemeinsam.