Sicherheitsuntersuchung des Squid Proxy Servers. Feinkonzept

Transkript

1 Feinkonzept

2 Bundesamt für Sicherheit in der Informationstechnik Postfach Bonn Internet: Bundesamt für Sicherheit in der Informationstechnik 2005

3 Inhaltsverzeichnis 1. Einleitung 5 2. Einsatzszenarien Einsatz als regulärer Proxy Einsatz als regulärer Proxy in einer DMZ Einsatz als regulärer Proxy auf der Firewall Einsatz als Reverse Proxy Server 9 3. Sicherheitsziele Bedrohungen des Squid Proxy Servers Mögliche Schwachstellen von Squid Sicherheitsanforderungen Identifizierung und Authentisierung Zugriffskontrolle Sicherheitsprotokollierung Unverfälschtheit Zuverlässigkeit der Dienstleistung Übertragungssicherheit Verschlüsselung Funktionen zur Wahrung der Datenintegrität Datenschutzrechtliche Anforderungen Minimale Rechtevergabe Sicherheitsfunktionen von Squid Identifizierung und Authentisierung HTTP Basic Authentisierung HTTP Digest Authentisierung NTLM Authentisierung Zugriffskontrolle Access Control Listen ACLs mit IP Adressen ACLs mit DNS Namen ACLs mit Protokolleingeschaften ACLs mit Benutzerinformationenen (Identifizierung bzw. Authentisierung) ACLs mit Inhaltsinformationen Sonstige ACLs Externe ACLs Access Control Regeln Sonstige Konfigurationen die ACLs verwenden 25 Bundesamt für Sicherheit in der Informationstechnik 3

4 7.3 Sicherheitsprotokollierung Unverfälschtheit Zuverlässigkeit der Dienstleistung Übertragungssicherheit Verschlüsselung Datenintegrität Datenschutz Minimale Rechtevergabe Testplan Funktionale Tests der Sicherheitsfunktionen von Squid Penetrationstests Quellcode Analysen 38 Bundesamt für Sicherheit in der Informationstechnik 4

5 Titel des Dokuments 1 Einleitung Squid ist ein Open Source Web Cache Proxy-Server. Proxy bedeutet in der deutschen Sprache Bevollmächtigter oder Stellvertreter. Ein Proxy-Server dient folglich dazu, an Stelle des Client die entsprechende Anfrage an einen Server zu stellen. Der Proxy-Server nimmt die Antwort vom Server entgegen und leitet diese an den anfragenden Client weiter. Neben dieser Stellvertreteraufgabe bietet der Squid eine Cache-Funktionalität. Der Squid holt das angeforderte Objekt vom Web Server, liefert es an den Client aus und behält eine Kopie des Objekts in einem Zwischenspeicher, der auch kurz Cache genannt wird. Der Proxy-Server kann bei einer Anfrage eines zuvor gespeicherten Objektes dieses Objekt aus seinem Zwischenspeicher ausliefern und muss nicht den entfernten Web Server befragen. Squid unterstützt die Protokolle HTTP, HTTPS, FTP (über HTTP), Gopher und WAIS. Er ist sowohl für kleine Installationen (5-10 Nutzer) wie auch für große Proxy-Verbünde in WAN Netzen mit einer sehr großen Nutzerzahl geeignet. Squid wird weiterhin bei einer Vielzahl von Internet Service Providern (ISP) als transparenter Proxy eingesetzt. Dabei wird der Netzverkehr unbemerkt vom Benutzer über einen Squid Proxy Server gelenkt und nimmt ebenfalls Proxy und Cache Funktionalität war. Weiterhin ist Squid als Reverse Proxy" zum Schutz und zur Beschleunigung von Web Servern einsetzbar. Bundesamt für Sicherheit in der Informationstechnik 5

6 2 Einsatzszenarien In diesem Kapitel werden typische Beispiele für Einsatzumgebungen des Squid Proxy Servers beschrieben. Die hier beschriebenen Einsatzumgebungen stellen die Grundlage für die Sicherheitsuntersuchung des Squid Proxy Servers dar. Sie werden auch bei der Erstellung der im Rahmen des Projektes zu erstellenden Check-Listen berücksichtigt. Die Auswahl der Einsatzumgebungen richtet sich vornehmlich an die Anbindung von kleineren und mittleren Behördennetzen an das Internet. Die im Rahmen der Studie erstellten Check-Listen sollen die Betreiber der kleineren und mittleren Behördennetzen unterstützen, einen adäquaten Sicherheitsstand ihrer Squid Proxy-Installation sicherzustellen. 2.1 Einsatz als regulärer Proxy Bei der Sicherheitsuntersuchung wird der Einsatz als regulärer Proxy Server in den Szenarien Installation auf einem eigenständigem Server in einer demilitarisierten Zone der Firewall und Installation direkt auf der Firewall betrachtet. Auf die Betrachtung des Szenario Installation auf einem eigenständigen Server im LAN sowie innerhalb von Cache Hierarchien wird in Absprache mit dem BSI verzichtet Einsatz als regulärer Proxy in einer DMZ Ein Beispiel einer typischen Einsatzumgebung ist in der Abbildung 1 dargestellt. Der Proxy-Cache- Server wird dabei in einer Firewall-DMZ des Internet-Übergangs installiert. An der Firewall werden einerseits Client-Zugriffe aus dem internen Netz auf den entsprechenden Service-Port des Squid erlaubt. Andererseits werden an der Firewall die Zugriffe vom Squid ins Internet erlaubt. Zusätzlich können weitere Services in Verbindung mit dem Squid Proxy-Cache-Server, wie z.b. HTTP Antivirus-Filter oder URL-Filter auf dedizierten Server Systemen in der DMZ platziert werden. Der Vorteil dieser Realisierungsvariante liegt in dem zusätzlichen Schutz des Proxy-Cache-Server durch die Firewall gegen bestimme Bedrohung, wie z.b. Denial of Service-Angriffe, sowie in dem Schutz offener Ports weiterer Dienste, die von dem Betriebssystems des Squid Systems angeboten werden. Die zusätzlichen Schutzmechanismen einer Firewall sind nicht Gegenstand dieser Untersuchung und werden im Folgenden nicht weiter betrachtet. Bundesamt für Sicherheit in der Informationstechnik 6

7 Titel des Dokuments Auth.-Server Management- LAN Content Security Server Client ProxyCache WebServer DMZ Intranet Internet Router Firewall Router Abbildung 1: Realisierung Squid Proxy-Cache in der DMZ der Firewall Die folgende Tabelle gibt einen Überblick über möglichen Aufgaben, die von dem Squid Proxy Server in diesem Szenario wahrgenommen werden können. Weiterhin ist in dieser Tabelle vermerkt, welche Aufgaben im Rahmen der Sicherheitsuntersuchung betrachtet werden: Aufgabe/Funktion von Squid Proxy Funktionalität für HTTP, FTP (über HTTP), SSL, Gopher und WAIS Cache Funktionalität für HTTP, FTP (über HTTP), Gopher und WAIS SNMP Unterstützung Caching von DNS Anfragen Bandbreitensteuerung Untersuchungsumfang Untersucht wird HTTP, und FTP (über HTTP) Anmerkung: HTTPS wird im Szenario Regulärer Proxy von Squid transparent weitergereicht (auf der Seite des Clients mittels der HTTP Methode CONNECT) Untersucht wird HTTP und FTP (über HTTP) Wird untersucht Wird untersucht Wird nicht untersucht Bundesamt für Sicherheit in der Informationstechnik 7

8 Aufgabe/Funktion von Squid Zugriffskontrolle über Access Listen Authentisierung Schnittstellen für externe Programme und Bibliotheken (Libraries). Protokollierung. Untersuchungsumfang Der Detaillierungsgrad der Untersuchung ist im Testplan (siehe Kapitel 8.1) festgelegt. Betrachtet werden u.a. die Filterung auf Quelle und Ziel (IP Adressen, Domainen Namen, Port Nummern) auf das Protokoll (cache_object), auf die HTTP Methode (CONNECT und PURGE), auf die Proxy Authentisierung, auf reguläre Ausdrücke von URLs und auf übermittelte Mime Typen. Der Detaillierungsgrad der Untersuchung ist im Testplan (siehe Kapitel 8.1) festgelegt. Die Implementation der Schnittstellen werden betrachtet. Wird untersucht. Tabelle 1: Übersicht über die im Einsatzszenario "DMZ" zu untersuchenden Squid Komponenten Einsatz als regulärer Proxy auf der Firewall Eine weitere typische Realisierung innerhalb kleiner Netze ist es, den Squid Proxy-Cache-Server direkt auf der Firewall zu betreiben. Bei dieser Art der Realisierung besteht ein erhöhtes Bedrohungspotential gegenüber dem Betrieb innerhalb einer DMZ. Bei Problemen des Squid Proxy Servers wird in diesem Fall unmittelbar die Firewall beeinträchtigt. Dies kann daher auch zu einer Beeinträchtigung des gesamten über die Firewall abgewickelten Netzwerkverkehrs führen (z.b. VPN Verbindungen). Weiterhin bietet die Firewall einen zusätzlichen Dienst an, der einen weiteren Angriffspunkt darstellt. Bei einem erfolgreichen Angriff gegen den Squid Server ist in diesem Szenario die Sicherheit des internen Netzwerkes betroffen. WebServer Intranet Internet Router Firewall und ProxyCache Router Abbildung 2: Realisierung Squid Proxy-Cache auf der Firewall Die Aufgaben, die von dem Squid Proxy Server in diesem Szenario wahrgenommen werden, unterscheidet sich nicht von dem Szenario bei dem der Squid Proxy in der DMZ lokalisiert ist. Es wird Bundesamt für Sicherheit in der Informationstechnik 8

9 Titel des Dokuments daher hier keine weitere Unterscheidung vorgenommen. (Bei der Erstellung des Testplans wurde diese Einschätzung bestätigt. Die Konfigurationsunterschiede der Squid Installation iwerden bei der Erstellung der Check Listen in Projektphase 3 dargestellt.) 2.2 Einsatz als Reverse Proxy Server In diesem Szenario wird von dem Betreiber eines Web Auftritts ein Squid Proxy-Server zur Unterstützung des Web Auftritts betrieben. Der Reverse Proxy-Server hat dabei typischerweise die Aufgabe, die Skalierbarkeit, die Verfügbarkeit und die Performanz des Web Auftritts zu verbessern. Weiterhin bietet der Squid Proxy-Server die Möglichkeit, externe Programme zur Überprüfung von den an die Web Anwendung übermittelten Inhalte einzubinden. Proxy Server WebServer Intranet Internet Router Abbildung 3: Realisierung Squid als Reverse Proxy-Server Die folgende Tabelle gibt einen Überblick über möglichen Aufgaben, die von dem Squid Reverse Proxy Server in diesem Szenario wahrgenommen werden können. Weiterhin ist in dieser Tabelle vermerkt, welche Aufgaben im Rahmen der Sicherheitsuntersuchung betrachtet werden: Aufgabe/Funktion von Squid Reverse Proxy Funktionalität für HTTP, FTP (über HTTP), SSL, Gopher und WAIS SNMP Unterstützung Caching von DNS Anfragen Zugriffskontrolle über Access Listen Authentisierung Schnittstellen für externe Programme und Bibliotheken (Libraries). Protokollierung. Untersuchungsumfang Untersucht wird HTTP, HTTPS (die Schnittstelle zur Verschlüsselung bzw. Prüfung der Authentizität mit OpenSSL) und FTP (über HTTP). In diesen Funktionen besteht im Vergleich zum Szenario Regulärer Proxy kein Unterschied. Daher werden diese Funktionen nicht nochmals untersucht. Tabelle 2: Übersicht über die im Einsatzszenario "Reverse Proxy" zu untersuchenden Squid Komponenten Aus der Tabelle ergibt sich, dass der wesentliche Unterschied zwischen Proxy Server und Reverse Proxy Server bei der Sicherheitsuntersuchung in der Unterstützung von SSL zur verschlüsselten HTTPS Kommunikation besteht. Alle anderen Komponenten sind nach derzeitiger Einschätzung äquivalent zu dem Einsatzszenario Proxy Server. (In der Konfiguration und in den zu erstellenden Check Listen gibt es natürlich Unterschiede, die im Rahmen von Phase 3 des Projektes dargestellt werden.) Bundesamt für Sicherheit in der Informationstechnik 9

10 3 Sicherheitsziele In diesem Anschnitt werden die übergeordneten Sicherheitsziele aufgeführt, die bei dem Betrieb von Squid erreicht werden sollen. Sie dienen dazu, um die Bedrohungen zu bestimmen, die diese Sicherheitsziele gefährden. Sicherheitsziele für beide Einsatzszenarien (regulärer Proxy und Reverse Proxy) SZ 1: SZ 2: Durch den Einsatz von Squid darf nicht gegen Gesetze verstoßen werden. (u.a. Strafrecht, Urheberrecht und Bundesdatenschutzgesetz). Der Squid darf die Vertraulichkeit und Integrität der über ihn übermittelten Daten nicht gefährden. (Dieses Sicherheitsziel hat für die beiden Einsatzszenarien eine unterschiedliche Bedeutung. So kann die Kommunikation zwischen Browser und Reverse Proxy über SSL abgesichert werden (Verschlüsselung und Sicherstellung der Authentizität der Kommunikationspartner).) Weitere Sicherheitsziele für das Einsatzszenario regulärer Proxy SZ 3: SZ 4: SZ 5: SZ 6: Der Squid sollte einen zuverlässigen Zugang zu Informationen aus dem Internet gewährleisten, die die Benutzer zur Erledigung ihrer Arbeit benötigen. Dies betrifft sowohl die Verfügbarkeit des Dienstes wie auch die Aktualität der ausgelieferten Daten. Das interne Netzwerk soll vor Eindringlingen geschützt werden. Informationen des internen Netzwerkes sollen nicht nach außen gelangen (z.b. lokale IP Adressen). Schädlicher Inhalt soll aus dem internen Netzwerk ferngehalten werden Weitere Sicherheitsziele für das Einsatzszenario Reverse Proxy SZ 7: SZ 8: Die Web Server sollen vor Eindringlingen geschützt werden. Die Zuverlässigkeit der Web Anwendungen soll gewährleistet werden. Bundesamt für Sicherheit in der Informationstechnik 10

11 Titel des Dokuments 4 Bedrohungen des Squid Proxy Servers Die Bedrohungen lassen sich in Anlehnung an des BSI Grundschutzhandbuch in fünf Gefährungskategorien. Diese sind höhere Gewalt, organisatorischen Mängel, menschliches Fehlverhalten, technisches Versagen und vorsätzliche Handlungen. Im Rahmen dieser Sicherheitsuntersuchung werden die Bedrohungen betrachtet, die auf das Produkt Squid Proxy Server zurückzuführen sind. Diese sind im wesentlichen in den beiden Gefähdungskategorien technisches Versagen (des Produkts Squid) und vorsätzliche Handlungen (Angreifer) zuzuordnen. Die Bedrohungen der im Rahmen dieser Untersuchung berücksichtigten Einsatzszenarien von Squid (regulärer Proxy und Reverse Proxy) unterscheiden sich nur in einzelnen Punkten. Daher werden diese Unterschiede bei den einzelnen Bedrohungen vermerkt. Im Folgenden wird eine Unterscheidung der Bedrohungen bezüglich der Grundbedrohungen Verlust der Vertraulichkeit, Verlust der Integrität und Verlust der Verfügbarkeit vorgenommen. Hierbei bedeuten Verlust der Vertraulichkeit: Vertraulichkeit ist gegeben, wenn die Information nur den dazu Befugten zugänglich ist und weder unbefugt noch ungewollt offenbart wird; Verlust der Integrität: Integrität ist definiert als die Unversehrtheit, Korrektheit, Widerspruchsfreiheit und Vollständigkeit der Informationen und schließt ein, dass diese Informationen nur von den Befugten in zulässiger Weise modifiziert werden können; Verlust der Verfügbarkeit: Verfügbarkeit ist definiert als die Bereitstellung der Funktion eines Systems innerhalb einer vorgegebenen Zeit. Zusätzlich wird als weitere Kategorie der Verstoß gegen Gesetze hinzugenommen. Verlust der Vertraulichkeit B 1: Ein Unbefugter bekommt Zugriff auf vertrauliche Informationen, wie z.b. die Konfiguration des Squid oder interne IP Adressen. B 2: Ein Unbefugter bekommt Zugriff auf vertrauliche (verschlüsselte) Daten eines Benutzers, die zwischen Browser und Reverse Proxy Server Daten übermittelt werden. B 3: Ein Unbefugter bekommt Zugriff auf vom Squid System gespeicherte Daten. Verlust der Integrität B 4: Das Squid System wird kompromittiert. B 5: Ein Unbefugter modifiziert die zwischen Browser und Reverse Proxy Server übermittelten Daten eines Benutzers. B 6: Ein Unbefugter missbraucht das Squid System für Angriffe gegen interne oder fremde Systeme. Bundesamt für Sicherheit in der Informationstechnik 11

12 B 7: Ein Benutzer baut nicht vorgesehene Netzverbindungen auf. B 8: Ein Benutzer greift auf für ihn nicht vorgesehene Web Ressourcen zu. B 9: Ein Benutzer erhält administrativen Zugriff auf das Squid System. B 10: Das Squid-System liefert veraltete Informationen aus. Verlust der Verfügbarkeit B 11: Die Ressourcen des Squid Systems werden verbraucht und das System liefert seine Antworten nicht mehr in einer akzeptablen Zeit (Denial of Service). Verstoß gegen Gesetzte B 12: Das Squid System nimmt durch entsprechendes Benutzerverhalten in seinen Cache-Speicher Daten auf, die gegen Gesetzte verstoßen (z.b. rechtsradikale, urheberrechtlich geschützte oder pornographische Inhalte). Gegenüberstellung von Sicherheitszielen und Bedrohungen Die folgende Tabelle stellt zusammen, welche der aufgeführten Bedrohungen welche Sicherheitsziele gefährden: SZ1 SZ 2 SZ 3 SZ 4 SZ 5 SZ 6 SZ 7 SZ 8 B 1 X X B 2 X B 3 X B 4 X X X B 5 X B 6 X B 7 X X B 8 X X B 9 X X B 10 X B 11 X B 12 X Tabelle 3: Gegenüberstellung, welche Bedrohung welche Sicherheitsziele gefährden Bundesamt für Sicherheit in der Informationstechnik 12

13 Titel des Dokuments 5 Mögliche Schwachstellen von Squid Mögliche Schwachstellen von Squid können ihre Ursache in der Implementierung, in der Komplexität der Konfiguration und in der Architektur haben. Typische Implementationsschwächen sind z.b. Speicherlecks, Pufferüberlaufschwächen, Format String Schwächen und versteckte Hintertüren. Typische Konfigurationsfehler sind z.b. unzureichendes Einspielen von Patches, Vergabe von zu vielen Benutzerrechten, unzureichendes Passwort Management und unzureichendes oder ungeeignetes Logging. Typische Architekturfehler sind z.b. Race Condition Schwachstellen, schlecht abgesicherte administrative Zugänge und das Fehlen eines definierten sicheren Fehlerzustandes. Im Rahmen dieser Untersuchung werden Teile des Quellcodes von Squid analysiert. Dies ist geeignet, Schwachstellen, die auf Implemenationsfehler oder Architekturfehler zurückzuführen sind, aufzudecken. Zur Vermeidung von Konfigurationsfehlern sind organisatorische Maßnahmen erforderlich. Im Rahmen dieses Projektes werden hierfür Check Listen erarbeitet. Die dazu notwendigen organisatorischen Maßnahmen werden aber nicht beschrieben. Im Folgenden werden mögliche Schwachstellen von Squid aufgeführt. (Diese Liste ist zum gegenwärtigen Zeitpunkt des Projekts als vorläufig anzusehen und wird im Laufe des Projektes ggf. konkretisiert und erweitert. ) Vul 1: Versagen der Sicherheitsmechanismen von Squid Falls es in der Implementierung der Sicherheitsmechanismen von Squid wie z.b. die Zugriffskontrolle über Access Control Listen und Access Regeln oder in der Authentisierung über Hilfsprogramme Schwachstellen gibt, so können diese Sicherheitsmechanismen möglicherweise umgangen werden. Vul 2: Unzureichende Überprüfungen Squid verarbeitet Daten, die aus nicht vertrauenswürdigen Quellen stammen. Ein Angreifer kann versuchen durch nicht protokollkonforme Kommunikation mit den von Squid bereitgestellten Diensten, ungewollte Aktionen hervorzurufen. Beispiele für unerwartete Datenwerte können u.a. in den folgenden Informationen übermittelt werden: HTTP Header Informationen, die von einem HTTP Client kommen (u.a. die Werte der HTTP Header Felder Pragma und Authorization ) HTTP Header Informationen, die von einem Web Server kommen (u.a. die Werte der HTTP Header Felder Last-Modified, Expire und Cache-Control ) Benutzernamen von Ident Erwiderungen von Client Systemen, DNS Erwiderungen von externen DNS Servern, SSL Anfragen vom Browser (z.b. ASN Strukturen - nur im Einsatzszenario Reverse Proxy relevant) und SNMP Management Anfragen. Vul 3: Unzureichendes Ressourcenmanagement Squid benötigt unterschiedliche System Ressourcen (RAM, Plattenplatz, Filedescriptoren etc.). Durch entsprechende Anfragen/Erwiderungen lassen sich möglicherweise die System Ressourcen aufbrauchen, so dass Squid nicht mehr in Bundesamt für Sicherheit in der Informationstechnik 13

14 einer angemessenen Zeit antwortet. (Denial-of-Service). Weiterhin werden beim Start eine vordefinierte Anzahl von Hilfsprogrammen gestartet (z.b. für die Authentisierung oder für externe URL Filterung). Durch entsprechende Anfragen kann es möglich sein, sämtliche Hilfsprogramme zu beschäftigen, so dass Squid eine Authentisierung bzw. eine externe URL Filterung nicht mehr durchführen kann (Denial-of-Service). Vul 4: Verletzung der Datenschutzbestimmungen. Squid speichert personenbezogenen Daten. Dies können u.a. Benutzernamen und/oder IP Adressen des Benutzerrechner sein. Vul 5: Verletzung von Gesetzten Squid speichert Kopien von Inhalten. Dies könnten bei entsprechender Konfiguration und entsprechendem Benutzerverhalten auch urheberrechtlich geschützte Daten, rechtsradikale Inhalte oder pornographische Inhalte sein. Die folgende Tabelle stellt zusammen, welche der aufgeführten möglichen Schwachstellen welche Bedrohung begünstigt: B1 B2 B3 B4 B5 B6 B7 B8 B9 B10 B11 B12 Vul 1 X X X X X X X Vul 2 X X X X Vul 3 Vul 4 Vul 5 X Tabelle 4: Aufstellung, welche der aufgeführten möglichen Schwachstellen welche Bedrohungen begünstigen X X Bundesamt für Sicherheit in der Informationstechnik 14

15 Titel des Dokuments 6 Sicherheitsanforderungen Die Sicherheitsanforderungen an den Squid Proxy Server ergeben sich aus den möglichen Einsatzszenarien und den Sicherheitszielen, die bei diesen Einsatzszenarien zugrunde gelegt werden, sowie den Bedrohungen, die die Erreichung der Sicherheitsziele gefährden. In den folgenden Kapiteln werden die Sicherheitsanforderungen an Squid in Anlehnung an die Anforderungen der Common Criteria, Teil 2, dargestellt. Dabei werden die generischen Oberbegriffe der ITSEC als Leitschnur verwendet. 6.1 Identifizierung und Authentisierung Neben den für die eigentliche Funktion des Squid vorgesehenen Benutzerzugriffen, stellt der Squid auch Zugriffe für Administration zur Verfügung. Dies sind z.b. der Zugriff über SNMP und über HTTP auf den Cache Manager. Weitere administrative Zugriffe sind über das Betriebssystem oder durch Zusatzprogramme (z.b. einen zusätzlichen Web Server) möglich. Die Bedrohungen über diese zusätzlichen Schnittstellen werden nicht weiter betrachtet, da sie nicht Bestandteil von Squid sind. Die Sicherheitsanforderungen an die Identifizierung und Authentisierung sind für Benutzer des Systems und für Administratoren unterschiedlich: SA 1 Administrative Zugriffe auf den Squid dürfen nur nach erfolgter Authentisierung möglich sein. Im Einsatzszenario Proxy Cache kann die Internet Richtlinie der Einheit (Firma, Behörde etc) besagen, dass der Zugriff auf das Internet benutzerabhängig reglementiert ist. (Z.B. Einschränkung der privaten Nutzung des Internets). SA 2 Es ist erforderlich, dass Squid im Einsatzszenario regulärer Proxy Benutzer identifizieren und/oder authentisieren kann. (Da hierbei das Ziel nicht der Schutz von Daten oder Anwendungen ist, sind die Sicherheitsanforderungen an die Identifizierung und Authentisierung der Benutzer in der Regel gering und eine Übertragung dieser Daten im Klartext ist daher meist ausreichend.) Ein Reverse Proxy hat als Aufgaben die über ihn ansprechbaren Web Anwendungen zu beschleunigen und für die Skalierbarkeit sowie für den Schutz dieser Anwendungen zu sorgen. Eine Identifizierung und Authentisierung der Benutzer am Squid ist daher in der Regel nicht erforderlich. 6.2 Zugriffskontrolle Im Einsatzszenario Regulärer Proxy kann die Internet Richtlinie der Einheit (Firma, Behörde etc.) besagen, dass der Zugriff auf das Internet benutzerabhängig reglementiert ist. (Z.B. Einschränkung der privaten Nutzung des Internets). SA 3 Es ist erforderlich, dass Squid im Einsatzszenario Regulärer Proxy die Zugriffe der Benutzer auf die Web Ressourcen filtern können. (Da hierbei der Fokus nicht der Schutz von Daten oder Anwendungen ist, sind die Sicherheitsanforderungen an die Zugriffskontrolle gering. Eine Umgehung der Restriktion führt nicht zu einem Sicherheitsproblem.) Im Einsatzszenario Reverse Proxy ist das Squid System eine Teilkomponente des Firewall Netzes zum Schutz der Web Anwendungen. Er hat daher die Aufgabe zur Abwehr von Angriffen beizutragen. SA 4 Es ist erforderlich, dass Squid im Einsatzszenario Reverse Proxy die Zugriffe aus dem Internet filtern kann. SA 5 Es ist erforderlich, dass der Reverse Proxy nicht Anfragen für fremde Web Server entgegennimmt. (In diesem Fall könnte der Reverse Proxy für Angriffe gegen fremde Systeme missbraucht werden.) Bundesamt für Sicherheit in der Informationstechnik 15

16 6.3 Sicherheitsprotokollierung Für den sichern Betrieb von Squid ist es erforderlich, dass Squid umfangreiche Überwachungsmöglichkeiten bereitstellt, sofern dies nicht bereits über das Betriebssystem möglich ist. SA 6 Es ist erforderlich, die Performanz von Squid überwachen zu können. Dazu ist es u.a. erforderlich, dass Squid Statistiken über die Verarbeitungszeiten von Anfragen, Statistiken über die Nutzung seines Caches, Statistiken über die Rate, mit der auf Platte ausgelagerte Speicherbereiche von Squid benötigt werden (Page Fault) und Statistiken über die benötigten Systemressourcen (Speicher, Filedesciptoren, Netzwerkverbindungen etc) führt. SA 7 Jede für den Betrieb von Squid benötigte Funktion muss überwacht werden können. Dies sind Statistiken über die von den einzelnen Datenbanken benötigte Speicherbereiche, um die Squid Konfiguration optimieren zu können, Statistiken über die Auslastung externer Hilfsprogramme (Authentisierung, externe DNS Auflösung, andere externe Programme wie z.b. Inhaltsfilter, Virenfilter o.ä.), um die Ursachen von Performanzeinbusen von Squid erkennen zu können. SA 8 Es ist erforderlich, Einbruchsversuche in Squid erkennen zu können. SA 9 Es ist erforderlich, Missbrauchsversuche von Squid erkennen zu können. 6.4 Unverfälschtheit SA 10 Der Squid darf keine veralteten Objekte ausliefern. SA 11 Die SSL Kommunikation zwischen Browser und Squid Reverse Proxy darf nicht modifiziert werden können. 6.5 Zuverlässigkeit der Dienstleistung SA 12 Der Squid muss Sicherheitsmechanismen zur Gewährleistung der Verfügbarkeit bereitstellen. (z.b. Clustering, Monitoring (s.o.)). SA 13 Der Administrator des Squid muss es möglich sein, im Cache-Speicher aufgenommen Inhalte zu entfernen (z.b. Seiten von Defaced Web Servern...). SA 14 Nicht mehr aktuelle Inhalte, die Squid aus seinem Cache-Speicher ausliefert, müssen vor einer konfigurierbaren Zeit noch aktuell gewesen sein (Es kann akzeptabel sein, dass Squid Inhalte, die keine explizite Verfallszeit haben, ausliefert, wenn diese erst seit ein paar Stunden oder Tagen veraltet sind.). 6.6 Übertragungssicherheit Es werden keine Sicherheitsanforderungen an Squid zur Übertragungssicherheit gefordert. 6.7 Verschlüsselung SA 15 Die SSL Kommunikation zwischen Browser und Squid Reverse Proxy darf von Unautorisierten nicht entschlüsselt werden können. Bundesamt für Sicherheit in der Informationstechnik 16

17 Titel des Dokuments 6.8 Funktionen zur Wahrung der Datenintegrität Es werden keine Sicherheitsanforderungen an Squid zur Datenintegrität gestellt. 6.9 Datenschutzrechtliche Anforderungen SA 16 Der Protokollierungsumfang des Squid muss den datenschutzrechtlichen Anforderungen entsprechen können Minimale Rechtevergabe SA 17 Es muss möglich sein, dass der Squid Dienst mit minimalen Rechten läuft. (Die Kompromittierung des Squid Dienstes darf nicht unmittelbar zu einer Komprimittierung des gesamten Squid Systems führen. Bundesamt für Sicherheit in der Informationstechnik 17

18 7 Sicherheitsfunktionen von Squid Dieses Kapitel beschreibt die Sicherheitsfunktionen, die Squid zur Verfügung stellt. 7.1 Identifizierung und Authentisierung Authentisierung für Administratoren: Squid stellt zwei Schnittstellen für Administratoren, den Cache Manager und SNMP, zur Verfügung. Cache Manager: Die einzelnen Komponenten des Cache Manager lassen sich durch ein Passwort schützen. Dieses wird unverschlüsselt über das Netzwerk gesendet. In der Squid Dokumentation wird daher als Konfigurationseinstellung empfohlen, dass der Cache Manager über geeignete ACLs nicht von entfernten Systemen ansprechbar sein sollte. In diesem Fall ist eine Authentisierung über das Betriebssystem erforderlich. Dabei muss aber sichergestellt werden, dass nur Administratoren sich an dem System anmelden können. SNMP Schnittstelle: Squid unterstützt SNMP in der Version 1. Der Community String wird in dieser Version im Klartext übertragen. In der Squid Dokumentation wird daher als Konfigurationseinstellung empfohlen, dass der SNMP Dienst über geeignete ACLs nicht von entfernten Systemen ansprechbar sein sollte. I Weitere Tätigkeiten des Administrators für Manipulationen des Cache Inhaltes (z.b. Entfernen von Inhalten aus dem Cache) können mit Squid spezifischen Erweiterungen des HTTP Protokolls durchgeführt werden (siehe Kapitel 7.4). In der Squid Dokumnetation wird ebenfalls empfohlen, dass diese Protokollerweiterungen mittels entsprechender ACLs auf lokale Zugriffe eingeschränkt werden. Weitere Tätigkeiten der Administratoren (z.b. Analyse der Protokolldateien, Änderungen der Konfiguration) können nur lokal durchgeführt werden. Die Administratoren müssen sich dazu am Betriebssystem des Squid Systems anmelden. Zusammenfassend lässt sich feststellen: eine aus Sicherheitssicht ausreichende Authentisierung für administrative Zugriffe ist nur im Zusammenspiel von Authentisierung am Betriebssystem und ACLs von Squid gegeben. Authentisierung für Benutzer: Die Authentisierung der Benutzer überlässt Squid externen Hilfsprogrammen. Die im Umfang von Squid bereitgestellten Hilfsprogramme lassen sich dabei in drei Gruppen einteilen: HTTP Basic (RFC 2617) Authentisierung: die Authentisierungsinformationen werden unverschlüsselt (base64 kodiert) gesendent (d.h. durch Man in the Middle Angriffe (MiM) kann ein Angreifer das Passwort eines Benutzers erhalten) HTTP Digest (RFC 2617) Authentisierung: Challenge Response Verfahren, das Verfahren ist anfällig gegen Replay Angriffe (in der Praxis muss sich der Angreifer aber in eine MiM Position bringen), NTLM Authentisierung (Properitäres Protokoll von Microsoft, Challenge Response Verfahren (reverse engineered). Nach Abbruch der TCP Verbindung ist eine erneuter Handshake erforderlich.) Squid startet dazu eine konfigurierbare Anzahl dieser Hilfsprogramme. Bei einem HTTP Zugriff, der eine Authenitisieung am Proxy Server erfordert (dies ist über ACLs steuerbar siehe Kapitel 7.2), wird vom HTTP Client die entsprechende Authentisierungsinformation übertragen. Der Squid übermittelt die notwendige Informationen an eines der externen Hilfsprogramme. Dieses Programm wertet die Informationen aus und teilt das Resultat der Benutzerverifizierung (in der Regel "OK" oder "ERR") Squid mit. Die Kommunikation zwsichen den Squid und den externen Hilfsprogrammen wird über Standard In und Out abgewickelt. Bundesamt für Sicherheit in der Informationstechnik 18

19 Titel des Dokuments HTTP Basic Authentisierung Die externen HTTP Basic Authentisierungshilfsprogramme lesen von stdin Paare von Benutzernamen und zugehörigem Passwort. Bei erfolgreicher Authentisierung schreiben die Hilfsprogramme OK sonst ERR auf stdout. Squid speichert intern die Resultate der Authentisierungen. Über einen Parameter (credentialsttl) lässt sich steuern, wie lange zwischengespeicherte Authentisierungsinformationen gültig sind. (Squid bekommt möglicherweise in dieser Zeitspanne Änderungen in der Authentisierungsdatenbank nicht mit!) Squid liefert die folgenden HTTP Basic Authentisierungshilfsprogramme mit. NSCA Dieses Hilfsprogramm liest die gültigen Benutzer/Passwort Kombinationen aus einer Datei, die vergleichbar mit der Unix Passwortdatei ist. LDAP Dieses Hilfsprogramm liest die gültigen Benutzer/Passwort Kombinationen von einem LDAP Server. Als weitere externe Softwarekomponente wird hierfür OpenLDAP benötigt. MSNT Dieses Hilfsprogramm übermittelt über das SMB Protokoll die Authentisierungsinformationen an bis zu fünf NT Domainen Contoller und wertet die Antworten für die Authentisierung aus. Multi Domainen MSNT Dieses Hilfsprogramm arbeitet analog wie das MSNT Hilfsprogramm, jedoch muss der Benutzer in der Authentisierung zusätzlich den Domänennamen angeben. Als weitere externe Softwarekomponenten werden Perl und das Perl Modul Authen::SMB benötigt. PAM Dieses Hilfsprogramm verwendet das Pluggable Authentication Modul (PAM) des Betriebssystems. Dies kann nur verwendet werden, wenn das Betriebssystem dieses unterstützt. SASL SASL steht für Simple Authentication and Security Layer und ist ein Vorschlag für ein IETF Standard (RFC 2222). Die SASL Authentifizierung ist ähnlich wie PAM und kann eine Reihe von verschiedenen Authentisierungsdatenbanken abfragen. Als weitere externe Softwarekomponente wird die Cyrus SASL Bibliothek benötigt. SMB Dieses Hilfsprogramm ist ein weiteres Programm, dass die Authentisierung über eine Microsoft Windows Datenbank durchführt. Es benötigt als weitere Softwarekomponente Samba. YP Dieses Hilfsprogramm führt die Authentisierung über eine NIS Domaine durch. getpwnam Dieses Hilfsprogramm führt die Authentisierung über die Unix Routine getwpnam() durch. Je nach Konfiguration des Betriebssystems ist die Authentisierungsquelle eine andere (u.a. die lokale Passwortdatei, NIS Domaine, PAM). Bundesamt für Sicherheit in der Informationstechnik 19

20 winbind Dieses Hilfsprogramm ist ein Client Programm für den winbindd Dienst von Samba. Es wird hier eine Authentisierung über den von einem Samba Server zur Verfügung gestellten Samba Dienst durchgeführt HTTP Digest Authentisierung Die externen HTTP Digest Authentisierungshilfsprogramme lesen von stdin Benutzernamen und Realm Namen. Bei erfolgreicher Authentisierung schreiben die Hilfsprogramme einen MD5 Hash- Wert sonst ERR auf stdout. Der MD5 Wert wird dabei aus den Informationen Benutzername, Realm und Passwort gebildet. Squid speichert die zu der Authentisierungen gehörigen gültigen MD5 Werte. Nicht alle Browser une Squid liefert dabei ein Authentisierungshilfsprogramm mit, dass die gültigen Benutzer/Passwort Kombinationen aus einer Datei liest NTLM Authentisierung NTLM steht für NT Lan Manager und ist ein proprietäres Authentisierungsprotokoll von Microsoft. Das Protokoll wurde von einer Vielzahl von Gruppen reverse-engineered. NTLM verwendet einen Dreiwege-Handshake, um die Verbindung zu authentisieren. Bei einem Abbruch der Verbindung ist ein erneuter Handshake erforderlich. SMB Dieses Hilfsprogramm ist gleichartig zu dem NTLM HTTP Basic Authentisierungsprogramm. winbind Dieses Hilfsprogramm ist gleichartig zu dem winbind HTTP Basic Authentisierungs-programm. 7.2 Zugriffskontrolle Squid bietet umfangreiche Möglichkeiten, über Access Control Listen (ACLs) und Access Control Regeln den Zugriff auf die von Squid bereitgestellten Dienste zu reglementieren. Die Zugriffskontrollregeln von Squid sind ein wesentlicher und aus Sicherheitssicht wichtiger Bestandteil von Squid. Die Zugriffskontrollregeln haben u.a. die Aufgabe, den Zugriff auf Web Ressourcen zu reglementieren, das Umschreiben von Web Anfragen zu regeln, den Zugriff auf administrative Schnittstellen einzuschränken, das Zusammenspiel von Proxy Servern in einer Proxy Hierarchie festzulegen und verschiedene Quality of Service zu unterstützen. Die Zugriffskontrolle besteht aus zwei verschiedenen Komponenten, den Access Control Listen und den Access Control Regeln. Die Access Control Listen dienen dazu verschiedene Aspekte des Client Zugriffs zu definieren. Dies sind u.a. IP Adressen, Domain Namen, Anfrage Methoden und Benutzername. Diese ACLs können in den Access Control Regeln auf die einzelnen Squid Dienste oder auf einzelne Squid Arbeitsabläufe angewandt werden.im Folgenden werden zunächst die unterschiedlichen Typen der Access Control Listen von Squid beschrieben. Anschließend werden die Access Control Regeln von Squid behandelt. Bundesamt für Sicherheit in der Informationstechnik 20