Proxy-Server – Grundlagen

Was ist ein Proxy-Server?

Ein Proxy-Server ist ein Vermittler zwischen einem Client (z.B. deinem PC) und dem Internet. Statt dass dein Browser direkt eine Anfrage an www.example.com schickt, sendet er sie zuerst an den Proxy – der Proxy stellt die Anfrage dann im eigenen Namen und leitet die Antwort zurück.

Das klingt zunächst nach einem unnötigen Umweg, bringt aber im Unternehmenskontext erhebliche Vorteile:

• Sichtbarkeit: Der gesamte Web-Traffic läuft durch einen zentralen Punkt und kann geloggt werden.
• Kontrolle: Unerwünschte Websites oder Kategorien lassen sich blockieren.
• Effizienz: Häufig abgerufene Inhalte (z.B. Windows-Updates) werden gecacht und sparen Bandbreite.
• Sicherheit: SSL Inspection ermöglicht das Prüfen von verschlüsseltem HTTPS-Traffic auf Malware.

Proxy-Typen im Überblick

In der Praxis begegnest du vier grundlegenden Typen, die sich in Funktion und Einsatzrichtung unterscheiden:

Forward Proxy – der Klassiker im Unternehmen

Der Forward Proxy ist das, was man im KMU-Umfeld typischerweise meint, wenn man von “dem Proxy” spricht. Er sitzt zwischen den internen Clients und dem Internet:

[PC im Büro] ──→ [Proxy 192.168.1.100:8080] ──→ [www.example.com]

Der Zielserver sieht nur die IP des Proxys, nicht die des einzelnen PCs. Das ermöglicht:

• Zentrales Logging: Wer hat wann welche URL aufgerufen?
• Content Filtering: Kategorien wie “Social Media” oder “Streaming” blockieren
• SSL Inspection: HTTPS entschlüsseln und auf Malware prüfen
• Bandbreitenlimitierung per User oder Gruppe

Reverse Proxy – der Torwächter für Server

Ein Reverse Proxy sitzt vor internen Webservern und nimmt Anfragen aus dem Internet entgegen:

[Browser extern] ──→ [Reverse Proxy / nginx] ──→ [App-Server intern]

Klassische Anwendungsfälle: nginx oder HAProxy als SSL-Termination vor mehreren internen App-Servern, Microsoft Application Proxy für On-Premise-Apps über Azure AD.

Transparenter Proxy

Beim transparenten Proxy ist keine Client-Konfiguration nötig – der Traffic wird auf Netzwerkebene (Firewall/Router) zum Proxy umgeleitet. Der Client weiss davon nichts (daher “transparent”). Viele Firewalls wie die Sophos oder pfSense können diesen Modus aktivieren.

Gängige Proxy-Lösungen

Cloud-Proxy und Secure Web Gateway (SASE)

Klassische Proxys wie Squid laufen als Server, den du selbst patchen, skalieren und absichern musst. Der Trend der letzten Jahre geht in Richtung Cloud-Proxy bzw. Secure Web Gateway (SWG) als Teil einer SASE-Architektur (Secure Access Service Edge) – der Anbieter betreibt die Proxy-Infrastruktur weltweit verteilt in eigenen Rechenzentren (“Points of Presence”), du kaufst nur eine Policy und einen Client.

Die beiden bekanntesten Vertreter:

• Zscaler Internet Access (ZIA): Vollständiger Cloud-Proxy inkl. SSL Inspection, Sandboxing und Data Loss Prevention.
• Cisco Umbrella (SIG): Startet als reiner DNS-Filter (extrem schnell ausgerollt, blockt schon vor dem HTTP-Request), lässt sich zum vollwertigen SWG mit Proxy-Modul ausbauen.

Traffic-Steuerung: Agent vs. PAC-Datei

Damit der Client seinen Traffic überhaupt zum Cloud-Proxy schickt, gibt es zwei grundlegende Wege:

Bei Zscaler Client Connector arbeiten beide Mechanismen sogar zusammen: Eine Forwarding-Profile-PAC entscheidet, ob System- und Browser-Traffic überhaupt zum lokal laufenden Client-Connector-Dienst geleitet wird; eine zweite, interne App-Profile-PAC bestimmt danach, zu welchem Zscaler-Rechenzentrum der Connector den Traffic tunnelt. Für Admins heisst das in der Praxis: Ausnahmen (z.B. für interne Domains) trägst du im Forwarding-Profil ein, nicht im App-Profil.

Für die grundsätzliche Architektur-Einordnung (Zero Trust statt Perimeter-Denken) lohnt sich ein Blick in Zero-Trust-Architektur für KMU und – bei mehreren Standorten – in SD-WAN Grundlagen, da SASE-Lösungen oft mit SD-WAN kombiniert werden, um den Traffic direkt vom Standort zum nächstgelegenen Cloud-PoP zu schicken statt über eine zentrale Firewall.

Proxy in Windows konfigurieren

System-Proxy per netsh (WinHTTP)

WinHTTP ist der Windows-interne HTTP-Stack, den Dienste und viele System-Tools nutzen (z.B. Windows Update, PowerShell Invoke-WebRequest).

# Proxy setzen
netsh winhttp set proxy proxy-server="192.168.1.100:8080" bypass-list="*.firma.ch;10.*;localhost"

# Aktuellen Proxy anzeigen
netsh winhttp show proxy

# Proxy entfernen
netsh winhttp reset proxy

# Proxy aus Internet Explorer / WinINET-Einstellungen übernehmen
netsh winhttp import proxy source=ie

Proxy per Registry (WinINET / Browser)

Der “normale” Browser-Proxy wird über die Internet-Einstellungen gesetzt und liegt in der Registry. Du kannst das per PowerShell für den aktuellen Benutzer setzen:

$regPath = "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings"

# Proxy aktivieren
Set-ItemProperty -Path $regPath -Name ProxyServer -Value "192.168.1.100:8080"
Set-ItemProperty -Path $regPath -Name ProxyEnable  -Value 1

# Ausnahmen setzen (Semikolon-getrennt)
Set-ItemProperty -Path $regPath -Name ProxyOverride -Value "*.firma.ch;10.*;192.168.*;localhost"

# Proxy deaktivieren
Set-ItemProperty -Path $regPath -Name ProxyEnable -Value 0

Proxy per Umgebungsvariable (für CLI-Tools)

Viele Linux-Tools, Python, curl, git und andere nutzen Umgebungsvariablen:

# Für die aktuelle PowerShell-Session
$env:HTTP_PROXY  = "http://192.168.1.100:8080"
$env:HTTPS_PROXY = "http://192.168.1.100:8080"
$env:NO_PROXY    = "localhost,127.0.0.1,*.firma.ch,10.0.0.0/8"

# Dauerhaft (User-Scope)
[System.Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://192.168.1.100:8080", "User")

Automatische Proxy-Konfiguration: PAC-Datei und WPAD

In grösseren Umgebungen willst du den Proxy nicht auf jedem PC manuell setzen. Dafür gibt es zwei Mechanismen:

PAC-Datei (Proxy Auto-Configuration)

Eine PAC-Datei ist ein JavaScript-File, das der Browser ausführt, um zu entscheiden: direkter Aufruf oder via Proxy? Du hinterlegst sie auf einem Webserver und verlinkst sie in den Client-Einstellungen.

Minimales Beispiel (proxy.pac):

function FindProxyForURL(url, host) {
    // Interne Adressen direkt
    if (isInNet(host, "10.0.0.0", "255.0.0.0"))     return "DIRECT";
    if (isInNet(host, "192.168.0.0", "255.255.0.0")) return "DIRECT";
    if (dnsDomainIs(host, ".firma.ch"))               return "DIRECT";

    // Alles andere über Proxy
    return "PROXY 192.168.1.100:8080; DIRECT";
}

Die URL zur PAC-Datei trägst du in den Gruppenrichtlinien oder den Browser-Einstellungen ein:

http://proxy.firma.ch/proxy.pac

WPAD (Web Proxy Auto-Discovery Protocol)

WPAD ermöglicht es, dass Clients die PAC-Datei automatisch finden – ganz ohne manuelle Konfiguration. Der Client sucht per DHCP oder DNS nach dem Standort der PAC-Datei.

DNS-Methode: Lege einen DNS-A-Eintrag wpad.firma.ch an, der auf den Webserver zeigt, der die Datei unter /wpad.dat bereitstellt.

DHCP-Methode: Konfiguriere DHCP Option 252 mit dem Wert http://wpad.firma.ch/wpad.dat.

Proxy per GPO verteilen

Im Active Directory verteilst du die Proxy-Einstellungen am saubersten per Gruppenrichtlinie:

Pfad: Benutzerkonfiguration > Windows-Einstellungen > Internet Explorer-Wartung > Verbindung > Proxyeinstellungen

Oder moderner via Administrative Vorlagen (für Edge/Chrome):

• Chrome: Computerkonfiguration > Administrative Vorlagen > Google > Google Chrome > Proxyeinstellungen
• Edge: Computerkonfiguration > Administrative Vorlagen > Microsoft Edge > Proxyeinstellungen

Für die PAC-Datei:

Automatische Proxykonfiguration: http://proxy.firma.ch/proxy.pac

Details zu Gruppenrichtlinien allgemein findest du in GPO-Grundlagen.

Proxy-Authentifizierung: NTLM, Kerberos und Basic

Sobald ein Proxy verlangt, dass sich Benutzer ausweisen (statt nur die Quell-IP zu prüfen), kommt eine der drei klassischen HTTP-Proxy-Auth-Methoden zum Einsatz. Sie unterscheiden sich stark in Sicherheit und Kompatibilität:

Der 407-Handshake im Detail

1. Client sendet Anfrage ohne Credentials.
2. Proxy antwortet mit Status 407 Proxy Authentication Required und einem Proxy-Authenticate-Header, der die unterstützten Methoden nennt (z.B. Negotiate, NTLM, Basic).
3. Client wählt die stärkste unterstützte Methode und sendet die Anfrage erneut mit Proxy-Authorization-Header.
4. Bei NTLM passiert das dreimal (zwei 407-Antworten, dann Erfolg) – bei Kerberos reicht in der Regel ein Umlauf, weil das Ticket schon vorliegt.

407-Fehler gezielt debuggen

# Ausführlicher HTTP-Dialog inkl. Auth-Handshake
curl -v --proxy http://proxy.firma.ch:8080 https://example.com

# Explizit mit Kerberos/Negotiate authentifizieren
curl -v --proxy-negotiate --proxy-user : --proxy http://proxy.firma.ch:8080 https://example.com

# Vorhandene Kerberos-Tickets des angemeldeten Benutzers prüfen
klist

# Registrierte SPNs für den Proxy-Dienstaccount prüfen (auf einem Domain Controller/Mitgliedsserver)
setspn -L proxysvc

Häufige Ursachen, wenn Kerberos scheitert und der Client (unbemerkt) auf NTLM oder Basic zurückfällt:

• SPN fehlt oder ist doppelt vergeben – setspn -L zeigt, ob HTTP/proxy.firma.ch überhaupt registriert ist.
• Zeitversatz zwischen Client und Domain Controller grösser als die Kerberos-Toleranz (Standard: 5 Minuten) – Kerberos verweigert dann jedes Ticket.
• Dienst läuft unter falschem Konto – der Proxy-Dienst (z.B. Squid-Kerberos-Helper) muss unter dem Konto laufen, dessen SPN registriert ist.
• Nicht-interaktive Prozesse (Scheduled Tasks, Windows-Dienste, Server-Anwendungen) besitzen kein Kerberos-Ticket eines angemeldeten Benutzers – hier brauchst du entweder explizite Proxy-Credentials im Code/Task oder eine Bypass-Regel für den entsprechenden Dienst-Traffic.

Proxy-Authentifizierung in Squid konfigurieren

# /etc/squid/squid.conf – Negotiate/Kerberos (bevorzugt in AD-Umgebungen)
auth_param negotiate program /usr/lib/squid/negotiate_kerberos_auth -s HTTP/proxy.firma.ch@FIRMA.CH
auth_param negotiate children 20
auth_param negotiate keep_alive on

# NTLM als Fallback für Nicht-Domain-Clients
auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp
auth_param ntlm children 20

# Basic gegen LDAP/AD als letzte Stufe
auth_param basic program /usr/lib/squid/basic_ldap_auth -R -b "dc=firma,dc=ch" \
    -D "squidsvc@firma.ch" -w "GeheimesPasswort" -f "(sAMAccountName=%s)" -h dc01.firma.ch
auth_param basic children 10
auth_param basic realm "Proxy-Login Firma AG"

acl authenticated proxy_auth REQUIRED
http_access allow authenticated

Squid probiert die Methoden in der Reihenfolge, in der sie konfiguriert sind – Negotiate zuerst zu listen sorgt dafür, dass domänengebundene Windows-Clients transparent per Kerberos durchkommen, während andere Geräte auf NTLM oder Basic zurückfallen.

SSL Inspection – HTTPS entschlüsseln

Moderner Web-Traffic ist fast ausschliesslich HTTPS. Ohne SSL Inspection sieht der Proxy nur den Ziel-Hostnamen, aber nicht den Inhalt. Für echtes Content Filtering und Malware-Prüfung brauchst du SSL Inspection (auch “SSL Bumping” oder “HTTPS Interception” genannt).

Funktionsweise:

1. Client baut Verbindung zum Proxy auf
2. Proxy baut eine eigene Verbindung zur Zielseite auf
3. Proxy präsentiert dem Client ein dynamisch generiertes Zertifikat, signiert mit der eigenen CA
4. Client muss dieser internen CA vertrauen (Root-Zertifikat in Windows/Browser importieren)

Client ←─ [Proxy-CA-Zertifikat] ─→ Proxy ←─ [Echtes Zertifikat] ─→ Zielserver

Root-Zertifikat auf Windows-Clients verteilen (per GPO):

# Lokal testen: Zertifikat in Trusted Root importieren
Import-Certificate -FilePath "C:\Certs\ProxyCA.cer" `
    -CertStoreLocation Cert:\LocalMachine\Root

Per GPO: Computerkonfiguration > Windows-Einstellungen > Sicherheitseinstellungen > Richtlinien für öffentliche Schlüssel > Vertrauenswürdige Stammzertifizierungsstellen

Bypass-Strategien für Microsoft 365, Teams und Zoom

Cloud-Dienste mit Echtzeit-Anteil (Audio/Video, P2P-Verteilung) vertragen sich schlecht mit einem klassischen Proxy: SSL Inspection fügt Latenz hinzu, zentrale Ausgangs-IPs verhindern die direkteste Netzwerkroute zum nächsten Microsoft- oder Zoom-Rechenzentrum, und viele Medien-Streams laufen ohnehin über UDP, das ein HTTP-Proxy gar nicht vermitteln kann.

Microsoft 365: Optimize / Allow / Default

Microsoft kategorisiert alle M365-Endpunkte in drei Stufen und pflegt sie laufend über eine öffentliche API:

Die aktuelle, maschinenlesbare Liste beziehst du über den Web-Service unter endpoints.office.com/endpoints/worldwide (JSON/CSV, mit Änderungs-Versionierung) – trage die Optimize-Endpunkte als DIRECT in deine PAC-Datei ein oder hinterlege sie als Bypass-Liste im Cloud-Proxy-Agenten. Für Teams-Admin-Themen generell siehe Microsoft Teams Administration.

Zoom

Zoom veröffentlicht ebenfalls feste IP-Bereiche und Domains für seine Medien-Server. Die Empfehlung ist analog zu Teams: *.zoom.us-Domains und die dokumentierten Zoom-IP-Ranges von SSL Inspection ausnehmen und – wo möglich – UDP-Traffic zu diesen Zielen direkt am Perimeter durchlassen, statt ihn zwangsweise über den TCP-Proxy zu zwingen. Wird UDP blockiert, fällt Zoom auf TCP über Port 443 zurück, was spürbar mehr Latenz und Jitter verursacht.

Praktische Umsetzung

// Ausschnitt proxy.pac – M365/Teams-Optimize- und Zoom-Domains direkt
function FindProxyForURL(url, host) {
    if (dnsDomainIs(host, ".teams.microsoft.com"))   return "DIRECT";
    if (dnsDomainIs(host, ".sharepoint.com"))        return "DIRECT";
    if (dnsDomainIs(host, ".outlook.office365.com")) return "DIRECT";
    if (dnsDomainIs(host, ".zoom.us"))               return "DIRECT";

    return "PROXY proxy.firma.ch:8080; DIRECT";
}

Bei Cloud-Proxys (Zscaler, Umbrella) trägst du dieselben Domains als Bypass-/Ausnahmeliste im Forwarding-Profil des Agenten ein, statt eine PAC-Datei zu pflegen.

Proxy-Einstellungen pro Anwendung prüfen und debuggen

Welchen Proxy nutzt gerade mein System?

# WinHTTP-Proxy prüfen
netsh winhttp show proxy

# WinINET-Proxy prüfen (Registry)
Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" |
    Select-Object ProxyServer, ProxyEnable, ProxyOverride, AutoConfigURL

# Umgebungsvariablen prüfen
Get-ChildItem Env: | Where-Object { $_.Name -match "proxy" }

Verbindungstest durch den Proxy

# Testen ob Proxy erreichbar ist
Test-NetConnection -ComputerName 192.168.1.100 -Port 8080

# HTTP-Anfrage mit explizitem Proxy
Invoke-WebRequest -Uri "https://example.com" -Proxy "http://192.168.1.100:8080" -UseBasicParsing

# curl mit Proxy
curl --proxy http://192.168.1.100:8080 https://example.com -I

Häufige Fehlerbilder

Squid – Minimale Konfiguration (Linux)

Squid ist der verbreitetste Open-Source Forward-Proxy. Eine minimale, funktionierende Konfiguration:

# /etc/squid/squid.conf (Ausschnitt)

# Zugriffsregeln
acl localnet src 192.168.0.0/16
acl localnet src 10.0.0.0/8
acl SSL_ports port 443
acl Safe_ports port 80 443 8080

# Erlauben
http_access allow localnet
http_access deny all

# Port und DNS
http_port 8080
dns_nameservers 192.168.1.1

# Caching
cache_mem 256 MB
cache_dir ufs /var/spool/squid 10000 16 256
maximum_object_size 50 MB

# Logging
access_log /var/log/squid/access.log squid

# Konfiguration prüfen und Dienst neu starten
squid -k parse
systemctl restart squid

# Logs live verfolgen
tail -f /var/log/squid/access.log

Caching-Strategien und Windows-Update Delivery Optimization

Refresh-Regeln richtig setzen

Ein Proxy cached nur dann sinnvoll, wenn du ihm sagst, wie lange welcher Inhaltstyp gültig bleibt. Squid steuert das über refresh_pattern:

# /etc/squid/squid.conf – Ausschnitt Caching-Strategie

# Statische Inhalte lange cachen (Bilder, CSS, JS, Windows-Update-Pakete)
refresh_pattern -i \.(gif|png|jpg|jpeg|css|js)$  1440  90%  43200
refresh_pattern -i \.(cab|msu|msp|exe|psf|esd)$  4320  90%  129600

# Dynamische Inhalte kaum cachen
refresh_pattern .   0   20%   4320

Die drei Zahlen sind: Mindest-Alter (Minuten), Prozentsatz des bisherigen Alters als Cache-Toleranz, Maximal-Alter. Grosse, unveränderliche Dateien (Update-Pakete, Treiber) profitieren am meisten von langen Werten – sie werden nur einmal aus dem Internet geladen und danach an alle Clients im Haus aus dem lokalen Cache bedient.

Windows Update Delivery Optimization

Delivery Optimization (DO) ist Microsofts eigener Caching-Mechanismus: Windows-Clients laden Update-Pakete in Teilen (typischerweise 1‑MB-Blöcke per HTTP-Range-Request) und tauschen diese Teile zusätzlich per Peer-to-Peer im lokalen Netz oder über den Windows-Update-CDN aus. Das reduziert den Internet-Traffic zusätzlich zu dem, was ein klassischer Proxy-Cache schon einspart – bringt aber eigene Anforderungen an den Proxy mit:

• Byte-Range-Support ist Pflicht: Der Proxy muss Range-, Content-Range- und Accept-Ranges-Header unverändert durchlassen und HTTP 206 (Partial Content) unterstützen. Blockiert oder verändert der Proxy Range-Requests, lädt der Client die komplette Datei statt einzelner Teile – P2P-Sharing funktioniert dann gar nicht mehr.
• SSL Inspection muss für bestimmte Endpunkte deaktiviert sein: Die DO-Cloud-Dienste unter geo.prod.do.dsp.mp.microsoft.com und array*.prod.do.dsp.mp.microsoft.com nutzen Certificate Pinning. Ersetzt SSL Inspection das Zertifikat, meldet der Client einen Zertifikatsfehler und DO fällt komplett auf CDN-only ohne Peer-Sharing zurück.
• Proxy-Konfiguration über WinINET, nicht netsh: Delivery Optimization nutzt WinHTTPs automatische Proxy-Erkennung mit dem Token des angemeldeten Benutzers. Microsoft empfiehlt ausdrücklich den geräteweiten WinINET-Proxy (per GPO: “Proxyeinstellungen pro Computer statt pro Benutzer festlegen”, oder per Intune Network Proxy CSP) statt netsh winhttp set proxy, weil Letzteres ohne Benutzeranmeldung (NetworkService-Kontext) andere Vorrangregeln hat und zu HTTP_E_STATUS_PROXY_AUTH_REQ-Fehlern führen kann.
• Ausgangs-IP darf sich nicht ändern: DO nutzt die Client-IP für Geo-Lokalisierung und Peer-Matching. Ein Proxy, der die Quell-IP maskiert (was ja sein Normalzustand ist), muss dafür zumindest die DO-Dienst-Calls unverändert durchreichen können.

Für sehr grosse Umgebungen bietet Microsoft mit Microsoft Connected Cache (MCC) eine On-Premise-Cache-Appliance als Ergänzung zu DO – funktional näher an einem klassischen Web-Cache, aber speziell für M365/Windows-Update-Inhalte optimiert.

Proxy-Chaining und Upstream-Proxy

In mehrstufigen Netzwerken (Filialen, Multi-Tenant-Umgebungen, Kombination aus lokalem Proxy und Cloud-SWG) schickst du den Traffic nicht direkt ins Internet, sondern über einen übergeordneten Proxy (Upstream/Parent Proxy). Typisches Szenario: Ein lokaler Squid pro Filiale cached den Traffic lokal, leitet aber alles, was er nicht im Cache hat, an einen zentralen Proxy oder eine Cloud-SWG weiter.

# /etc/squid/squid.conf – Kette zu einem übergeordneten Proxy

# Zentralen Proxy als Parent definieren
cache_peer proxy-zentrale.firma.ch parent 8080 0 no-query default login=PASS

# Alles, was nicht direkt erlaubt ist, über den Parent schicken
never_direct allow all

# Ausnahme: interne Ziele weiterhin lokal auflösen
acl local_dest dstdomain .firma.local
always_direct allow local_dest

Wichtige Optionen von cache_peer:

never_direct allow all zwingt jeglichen Traffic über den Parent; always_direct definiert gezielte Ausnahmen (z.B. interne Ziele), die trotzdem direkt aufgelöst werden sollen.

Proxy-Logs für Incident-Response auswerten

Proxy-Logs sind bei einem Sicherheitsvorfall oft die erste Anlaufstelle, weil sie – anders als reine Firewall-Logs – auch die vollständige URL, den authentifizierten Benutzer und den HTTP-Statuscode enthalten.

Squid Access-Log verstehen

1751871023.123    342 192.168.1.55 TCP_MISS/200 5432 GET http://example.com/update.exe jsmith HIER_DIRECT/93.184.216.34 application/octet-stream

Von links nach rechts: Unix-Timestamp, Antwortzeit in Millisekunden, Client-IP, Squid-Ergebniscode/HTTP-Status, übertragene Bytes, HTTP-Methode, aufgerufene URL, authentifizierter Benutzer (falls Proxy-Auth aktiv), Hierarchie-Code mit Ziel-IP, Content-Type.

Worauf Incident-Response-Analysten achten

• Wiederholte Verbindungen im festen Zeitintervall zu derselben Domain – klassisches Beacon-Verhalten von C2-Malware.
• Häufungen von TCP_DENIED eines einzelnen Clients – deutet auf automatisiertes Durchprobieren blockierter Ziele hin.
• Ungewöhnliche User-Agents oder komplett fehlender User-Agent-Header – viele Skripte/Malware setzen keinen realistischen Browser-Header.
• Grosse ausgehende POST-Requests zu unbekannten Zielen – möglicher Hinweis auf Datenexfiltration.
• Zugriffe auf frisch registrierte oder algorithmisch generierte Domains (DGA) – oft in Kombination mit DNS-Logs auswertbar.

Praktische Auswertung mit Bordmitteln

# Top 20 aufgerufene Domains eines Zeitraums
awk '{print $7}' access.log | awk -F/ '{print $3}' | sort | uniq -c | sort -rn | head -20

# Alle geblockten Zugriffe eines bestimmten Benutzers
grep "TCP_DENIED" access.log | grep "jsmith"

# Zugriffshäufigkeit pro Minute auf eine verdächtige Domain (grobe Beacon-Erkennung)
grep "verdaechtige-domain.tld" access.log | awk '{print substr($1,1,9)}' | sort | uniq -c

# Alle Zugriffe einer IP-Adresse chronologisch exportieren
grep "192.168.1.55" access.log > incident_192-168-1-55.log

Für eine strukturierte Vorgehensweise nach dem Fund solcher Auffälligkeiten – Eindämmung, Beweissicherung, Kommunikation – siehe Incident-Response-Plan für KMU. Werden Proxy-Logs zentral mit Firewall- und Windows-Logs korreliert, landest du im Bereich SIEM/SOC-Grundlagen – bereits ein einfaches Log-Forwarding von Squid an ein SIEM erhöht die Erkennungsrate deutlich, weil sich Proxy-Auffälligkeiten mit Endpoint- und Auth-Events verknüpfen lassen.

Weiterlernen

• Squid Cache Wiki – offizielle Dokumentation
• Squid: cache_peer Konfigurationsdirektive (englisch)
• Squid Wiki: Proxy Authentication (englisch)
• Microsoft: Proxy considerations for Microsoft 365 (englisch)
• Microsoft: Using a proxy with Delivery Optimization (englisch)
• Microsoft: Proxy servers for Teams (englisch)
• Microsoft: WinHTTP Proxykonfiguration (englisch)
• Zscaler: Best Practices for Using PAC Files (englisch)
• 4sysops: Proxy settings via PAC file and GPO (englisch)
• ip-insider.de: Was ist ein Forward Proxy?
• Wikipedia: Proxy Auto-Configuration (PAC)

Verwandte Themen: DNS-Grundlagen · VPN-Grundlagen · IT-Security Grundlagen KMU · Windows Firewall · Wireshark Grundlagen · Zero-Trust-Architektur KMU · SD-WAN Grundlagen · SIEM/SOC-Grundlagen · Incident-Response-Plan KMU · Microsoft Teams Administration

Videos

YouTube