Prüfen, dass Ihr Proxy nicht für alle offen ist
Prüfen Sie Listener, Regelreihenfolge, Zugangsdaten und tatsächliche Weiterleitung aus erlaubten und abgewiesenen Quellen, bevor Sie einen Forward-Proxy freigeben.
Testen Sie die Zugriffsgrenze, bevor ein neuer Forward-Proxy aus anderen Netzen erreichbar wird. Eine erfolgreiche Anfrage vom Server selbst beweist kaum etwas über die Möglichkeiten eines fremden Clients. Verwenden Sie ein kontrolliertes Ziel, um zu erkennen, ob eine abgewiesene Anfrage tatsächlich weitergeleitet wurde.
Wirksame Listener und Richtlinie prüfen
Untersuchen Sie den lauschenden Prozess und die Adressen, einschließlich IPv6, falls aktiviert. Entfernen Sie unbeabsichtigte zusätzliche Listener oder alte Dienstinstanzen. Beschränken Sie die Netzwerk-Firewall auf Quellen, die den Dienst erreichen sollen.
Prüfen Sie anschließend die tatsächlich geladene Konfiguration einschließlich eingebundener Dateien. Bei Squid 6 kann ein früheres Erlauben eine spätere Beschränkung wirkungslos machen. Bei Tinyproxy 1.11.2 erlaubt das Entfernen aller Allow- und Deny-Zeilen sämtliche Clients. Dante hat getrennte Client- und SOCKS-Regeln; eine zugelassene TCP-Verbindung ist daher nicht die gesamte Richtlinie.
Verwenden Sie die Dokumentation Ihrer installierten Version. Die Direktivenänderungen in Squid 8 sind Anlass zur Versionsprüfung, kein Grund anzunehmen, eine vertraute Konfiguration sei mit derselben Bedeutung akzeptiert worden.
Erlaubte und abgewiesene Fälle testen
Soll der Proxy sowohl eine freigegebene Quelle als auch eine Anmeldung verlangen, prüfen Sie diese Matrix mit eigenen kontrollierten Systemen:
| Quelle | Zugangsdaten | Erforderliches Ergebnis |
|---|---|---|
| Erlaubt | Gültig | Das beabsichtigte Ziel erhält die Anfrage. |
| Erlaubt | Fehlend oder falsch | Das Ziel wird nicht erreicht. |
| Nicht erlaubt | Gültig oder fehlend | Das Ziel wird nicht erreicht. |
Zwei Geräte hinter einem NAT können als dieselbe Quelle erscheinen. Wählen Sie Testorte mit unterschiedlichen Quelladressen am Proxy und bestätigen Sie diese im Log. Verwenden Sie keine unbeteiligten fremden Rechner und scannen Sie keine Dienste anderer Personen.
Eine Firewall-Abweisung kann ganz ohne HTTP-Antwort bleiben; eine Anwendungsabweisung kann einen Fehler zurückgeben. Prüfen Sie in beiden Fällen, dass das kontrollierte Ziel die verbotene Anfrage nicht erhalten hat. Eine Fehlerseite allein könnte sonst mit einer Zielantwort verwechselt werden.
Die vorgesehenen Weiterleitungsarten prüfen
Testen Sie bei einem Webproxy gewöhnliche HTTP-Anfragen und den erlaubten HTTPS-CONNECT-Pfad getrennt. Gehören Zielbeschränkungen zur Richtlinie, testen Sie ein erlaubtes sowie ein kontrolliertes Ziel, das abgewiesen werden soll. Entfernen Sie nicht die Kontrollen, nur damit jeder Test gelingt.
Wiederholen Sie Tests nach Änderungen an Quellbereichen, Zugangsdaten, Listeneradressen, eingebundenen Dateien oder Dienstversionen. Bewahren Sie Testzeit, Konfigurationsversion und Ergebnisse zusammen auf, damit spätere Änderungen an derselben Grenze geprüft werden können.
Dies ist ein Abnahmeverfahren, keine Behauptung, ein Konfigurationsparser oder eine einzige Anfrage könne die Sperrung jedes Netzwerkpfads beweisen.