ramonzx6/rapid-reset-checkEin Go-CLI, das HTTPS-Endpunkte erfasst, die über ALPN HTTP/2 aushandeln, um Systeme zu identifizieren, die eine Überprüfung der Mitigation für CVE-2023-44487 benötigen. Nicht-exploitative, zertifikatsverifizierte TLS-Prüfungen mit sicheren Standardeinstellungen.
rapid-reset-check ist ein kleines Go-CLI-Tool zur schnellen Inventarisierung von HTTPS-Endpunkten, die HTTP/2 bereitstellen und daher eine Überprüfung der Maßnahmen zu CVE-2023-44487 benötigen.
Der Scanner ist bewusst nicht-exploitativ. Er löst jedes Ziel auf, öffnet eine zertifikatgeprüfte TLS-Verbindung, bietet h2 und http/1.1 über ALPN an, zeichnet auf, was der Gegenüber auswählt, und schließt die Verbindung. Er sendet keine HTTP-Anfrage, kein HTTP/2-Connection-Preface, keinen Stream, keinen RST_STREAM-Frame und keinen Flood-Traffic.
[!IMPORTANT] Das Aushandeln von
h2ist eine Beobachtung der Exposition, kein Beweis dafür, dass ein Dienst verwundbar oder nicht gepatcht ist. Ein entfernter Handshake kann die Rapid-Reset-Grenzen, den Patchstand, den vorgelagerten Ursprung oder die DDoS-Schutzmaßnahmen einer HTTP/2-Implementierung nicht verifizieren.
CVE-2023-44487 ist eine Denial-of-Service-Technik, die das schnelle Erstellen und Abbrechen von HTTP/2-Streams missbraucht. Der Versuch, die Bedingung gegen einen Live-Dienst nachzuweisen, würde selbst potenziell störenden Datenverkehr erfordern. Dieses Tool beantwortet stattdessen die sichere erste Frage:
HTTP/2 über TLS wird über den h2-ALPN-Bezeichner angekündigt, der in RFC 9113 definiert ist. Google empfiehlt, jeden HTTP/2-fähigen Server, Proxy und Load Balancer im Anforderungspfad zu überprüfen oder zu patchen; siehe die CVE-2023-44487-Anleitung von Google.
Go ist nicht erforderlich, um das Tool auszuführen. Laden Sie das Archiv für Ihre Plattform von der neuesten GitHub-Version herunter:
| Plattform | Release-Asset |
|---|---|
| Linux x86-64 | rapid-reset-check_<version>_linux_amd64.tar.gz |
| Linux ARM64 | rapid-reset-check_<version>_linux_arm64.tar.gz |
| macOS Intel | rapid-reset-check_<version>_darwin_amd64.tar.gz |
| macOS Apple Silicon | rapid-reset-check_<version>_darwin_arm64.tar.gz |
| Windows x86-64 | rapid-reset-check_<version>_windows_amd64.zip |
| Windows ARM64 | rapid-reset-check_<version>_windows_arm64.zip |
Entpacken Sie das Archiv und führen Sie dann rapid-reset-check --version aus. Unter Windows heißt die ausführbare Datei rapid-reset-check.exe.
Jede Version enthält SHA256SUMS. Unter Linux überprüfen Sie ein heruntergeladenes Archiv aus demselben Verzeichnis mit:
sha256sum --ignore-missing --check SHA256SUMS
Unter macOS vergleichen Sie shasum -a 256 <archive> mit der entsprechenden Zeile in SHA256SUMS. Veröffentlichte öffentliche Release-Archive erhalten außerdem eine GitHub-Artefaktattestierung, die mit der GitHub-CLI überprüft werden kann:
gh attestation verify <archive> --repo ramonzx6/http-script-json
Es ist keine Installation von Node.js, cURL, nghttp2 oder WHOIS erforderlich.
go test ./...
go build -o rapid-reset-check ./cmd/rapid-reset-check
Quellcode-Builds melden dev bei --version; Release-Builds erhalten ihre Version aus dem Release-Tag.
Scannen Sie nur Endpunkte, die Ihnen gehören oder deren Bewertung Sie autorisiert sind.
Einen oder mehrere öffentliche Endpunkte scannen:
./rapid-reset-check example.com api.example.com:8443
Nackte Hostnamen werden auf HTTPS über Port 443 normalisiert. Nur-Autoritäts-HTTPS-URLs werden ebenfalls akzeptiert:
./rapid-reset-check https://example.com https://api.example.com:8443
Die JSON-Zielliste des Repositorys scannen:
./rapid-reset-check --input json/urls.json
Standardeingabe für die Automatisierung verwenden:
printf '["example.com", "api.example.com"]' | ./rapid-reset-check --input -
Führen Sie ./rapid-reset-check --help aus, um alle Grenzen und Ausgabeoptionen anzuzeigen.
--input akzeptiert das ursprüngliche JSON-Array-Format:
[
"example.com",
"api.example.com:8443",
"https://www.example.net"
]
Die Objektformen {"urls": [...]} und {"targets": [...]} werden ebenfalls unterstützt. Positionale Ziele und --input schließen sich bewusst gegenseitig aus. Doppelte normalisierte Endpunkte werden nur einmal gescannt, und jeder Lauf ist auf 4.096 Eingabeziele begrenzt.
Nur HTTPS-Endpunkte sind im Rahmen. Anmeldedaten, Nicht-Root-Pfade, Abfragen, Fragmente, nicht unterstützte Schemata, fehlerhafte Ports und mehrdeutige Hostnamen werden abgelehnt und nicht stillschweigend umgeschrieben.
| Bewertung | Bedeutung |
|---|---|
h2_observed_review_required | Mindestens ein verifizierter TLS-Gegenüber hat h2 ausgewählt. Überprüfen Sie jede HTTP/2-Komponente in diesem Pfad; dies ist kein Schwachstellenurteil. |
h2_not_observed_on_tested_path | Jede ausgewählte Adresse hat einen verifizierten Handshake abgeschlossen, ohne h2 auszuwählen. Dies ist eine punktuelle Pfadbeobachtung, keine Sicherheitsgarantie. |
indeterminate | Ein DNS-, Verbindungs-, Timeout-, TLS-, Zertifikats- oder Adresslimitproblem verhinderte eine vollständige Beobachtung. |
not_scanned_policy | Die aufgelösten Adressen wurden von der Netzwerksicherheitsrichtlinie des Scanners ausgeschlossen. |
invalid_target | Die Eingabe war fehlerhaft oder außerhalb des unterstützten HTTPS-Autoritätsbereichs. |
Der Bericht enthält jede versuchte aufgelöste Adresse, ausgehandeltes ALPN, TLS-Version und -Cipher, begrenzte Daten zu Zertifikatsidentität/-gültigkeit, Zeitmessung, Richtlinienentscheidungen, Anzahl ausgelassener Adressen, ein explizites Vollständigkeitskennzeichen und eine Zusammenfassung. Er erfasst keine Antwortkörper, Antwort-Header, Cookies oder rohe Zertifikate.
--ca-file, um eine private CA hinzuzufügen; es gibt keinen unsicheren Verifizierungsmodus.--allow-private nur für interne Endpunkte, deren Bewertung Sie autorisiert sind.Beispieloptionen:
./rapid-reset-check \
--format json \
--timeout 5s \
--concurrency 4 \
--max-addresses 8 \
example.com > report.json
Für einen autorisierten Endpunkt mit privater PKI:
./rapid-reset-check \
--allow-private \
--ca-file ./internal-root-ca.pem \
service.internal:8443
Exitcode 0 bedeutet, dass jedes Ziel eine vollständige ALPN-Beobachtung ergeben hat. Exitcode 1 bedeutet, dass mindestens ein Ziel ungültig, durch Richtlinien blockiert oder unbestimmt war; der Bericht wird trotzdem geschrieben. CLI-Nutzungs- und Konfigurationsfehler geben 2 zurück. Das Beobachten von h2 ändert für sich genommen nicht den Exitcode, da es ein Inventarsignal und kein Schwachstellenurteil ist.
Für jedes h2_observed_review_required-Ergebnis:
Ergebnisse gelten für den jeweiligen Hostnamen, die DNS-Antworten, den Netzwerkpfad, den TLS-Endpunkt und den Scanzeitpunkt. CDNs, Anycast, Split-Horizon-DNS, Lastverteilung, alternative Ports und ungetestete Adressen können zu anderen Ergebnissen führen. Der Scanner:
h2c), QUIC/HTTP/3, Weiterleitungen, hinter einem Edge verborgene Ursprünge oder Nicht-HTTPS-Dienste;Server-Headern oder CDN-Fingerprints ab;gofmt -w ./cmd ./internal
go vet ./...
go test ./...
go test -race ./...
go build ./...
Die Testsuite verwendet lokale TLS-Fixtures und scannt keine öffentlichen Dienste.
Release Please verwaltet Release-Versionen und vX.Y.Z-Tags anhand von Conventional-Commit-Nachrichten. Normale Entwicklung erfordert nicht das Erstellen oder Pushen von Tags:
main gemergte Commits veranlassen Release Please, einen Release-PR mit den Versions- und Changelog-Änderungen zu öffnen oder zu aktualisieren.Verwenden Sie fix: für Patch-Änderungen, feat: für Nebenversionsänderungen und ein Breaking-Change-Kennzeichen (!) oder eine BREAKING CHANGE:-Fußzeile für Hauptversionsänderungen. Maintainer müssen einmalig Settings > Actions > General > Workflow permissions > Allow GitHub Actions to create and approve pull requests aktivieren, damit Release Please seinen PR verwalten kann.
Wenn die Veröffentlichung der Assets fehlschlägt, nachdem Release Please einen Tag erstellt hat, bleibt das Release ein Entwurf. Führen Sie den Release-Workflow nach der Behebung des Fehlers manuell mit diesem vorhandenen vX.Y.Z-Tag erneut aus. Erstellen oder pushen Sie keinen Ersatztag.