Sicherheitsuntersuchung des Squid Proxy Servers. Sicherungsmaßnahmen

Transkript

1 Sicherheitsuntersuchung des Squid Proxy Servers Sicherungsmaßnahmen

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 Maßnahmen zur sicheren Kompilierung, Installation, Konfiguration und Administration des Squid Sicherheitsmaßnahmen für das Betriebssystem des Squid Systems Sicherheitsmaßnahmen bei der Installation des Squid Sicherheitsmaßnahmen für den Betrieb des Squid Monitoring des Squid Wartung des Squid 11 3 Zusätzliche empfehlenswerte Sicherungsmaßnahmen Zusätzliche Maßnahmen zum Schutz des Squid Zusätzliche Maßnahmen zum Schutz des lokalen Netzwerkes 13 4 Sicherheitsrichtlinien und Checklisten 16 5 Literaturverzeichnis 21 Bundesamt für Sicherheit in der Informationstechnik 3

4 Bundesamt für Sicherheit in der Informationstechnik 4

5 1 Einleitung Dieses Dokument beschreibt Sicherheitsmaßnahmen die bei dem Betriebs eines Squid Proxy Servers ergriffen werden können. Diese Maßnahmen lassen sich unterteilen in Sicherheitsmaßnahmen für das Betriebssystem des Squid Systems (siehe Kapitel 2.1), Sicherheitsmaßnahmen bei der Installation des Squid (siehe Kapitel 2.2), Sicherheitsmaßnahmen für den Betrieb des Squid (siehe Kapitel 2.3), Zusätzliche Maßnahmen zum Schutz des Squid (siehe Kapitel 3.1) und Zusätzliche Maßnahmen zum Schutz des lokalen Netzwerkes (siehe Kapitel 3.2). Kapitel 4 enthält eine Checkliste für die Überprüfung der Sicherheit von Installationen von realen Squid Systemen. 2 Maßnahmen zur sicheren Kompilierung, Installation, Konfiguration und Administration des Squid Die Maßnahmen für den Aufbau und Betrieb eines Squid Proxy Servers lassen sich in drei Bereiche gliedern; dies sind Maßnahmen für das Betriebssystem des Squid Systems, Maßnahmen bei der Installation des Squid Dienstes und Maßnahmen bei dem Betrieb des Squid Systems. 2.1 Sicherheitsmaßnahmen für das Betriebssystem des Squid Systems Im Folgenden werden die für den Betrieb eines Squid-Systems spezifischen Maßnahmen zur Konfiguration des Systems erläutert: Das System sollte keine weiteren Netzwerkdienste neben den für den Proxy Dienst notwendigen Diensten anbieten. Ein Ausnahme hierfür ist der SSH Dienst, der als Schnittstelle für den Zugriff der Administratoren des Squid eingerichtet werden sollte. Die SSH Zugriffe sollten netzseitig eingeschränkt werden. Nur Administratoren des Squid sollten sich an dem System unter personifizierten Accounts anmelden können. Es sollten nur die für den Betrieb des Proxy Systems notwendigen Softwarekomponenten auf dem Squid System installiert werden. Im Einsatzszenario Regulärer Proxy sollte das Squid System nicht aus dem Internet erreichbar sein. Bei dem Betrieb des Regulären Proxy in einer DMZ kann dieser Schutz durch eine entsprechend konfigurierte Firewall erreicht werden. Bei dem Betrieb des Regulären Proxy auf der Firewall kann durch die lokale Firewall ein entsprechender Schutz erreicht werden (z.b. mit Hilfe von iptables unter Linux). Die Einsatzszenarien sind in dem Dokument [1] beschrieben. Der Kernel sollte nur die notwendigen Module beinhalten. 2.2 Sicherheitsmaßnahmen bei der Installation des Squid Bei der Installation des Squid sollten nur die für das Einsatzszenario notwendigen Dienste des Squid konfiguriert werden. Bei Squid (Version 2.5 Stable7) ist der Default-Wert, dass alle zusätzlichen Dienste des Squid separat konfiguriert werden müssen. Die Konfiguration und Installation kann daher gemäß der Beschreibung des Dokumentes (siehe Kapitel 5 [2]) erfolgen. Dabei sind die folgenden Punkte zu berücksichtigen: Bundesamt für Sicherheit in der Informationstechnik 5

6 SNMP sollte nur aktiviert werden, wenn eine Überwachung des Squid über SNMP gewünscht wird (Squid unterstützt nur SNMP Version 1) und nur die eingesetzten Authentisierungsmethoden sollten aktiviert werden. In dieser Standardkonfiguration bietet Squid auf Port 3130 den ICP Dienst (Intenet Caching Protokoll) an. Dieser kann durch die Konfigurationseinstellung icp_port 0 abgestellt werden. Falls der SNMP Dienst eingesetzt wird kann über den Parameter snmp_incoming_address die IP Adresse des Squid spezifiziert werden, die SNMP Anfragen entgegennimmt. (Diese Einstellung wird bei der Öffnung des Sockets dem Betriebssysten übergeben.) SNMP Zugriffe sollten nur auf ausgesuchte IP Adressen erlaubt werden: snmp_incoming_address <IP Adressen> Im Einsatzszenario Regulärer Proxy auf der Firewall sollte der Zugriff auf den HTTP Port aus dem Internet nicht möglich sein. Squid bietet hierzu die Möglichkeit bei der Öffnung des TCP Sockets die lokale IP Adresse, bei der die HTTP Anfragen angenommen werden, über den Parameter http_port einzuschränken: http_port [IP Adresse:]port Die Maßnahme alleine ist nicht ausreichend. Es muss zusätzlich sichergestellt werden, dass die konfigurierte IP Adresse aus dem Internet nicht erreichbar ist. Dazu ist das Routing und das Regelwerk der lokalen Firewall (Port Forwarding etc.) entsprechend zu konfigurieren. Der Squid Dienst sollte mit einem Basisschutz über entsprechende ACLs gesichert werden. In der Standardkonfiguration sind schon ACLs vorhanden, die diesen Schutz sicherstellen: Die administrative Zugriffe werden nur von dem lokalen Host erlaubt (Cache Manager). Die CONNECT Methode wird auf den HTTPS und NNTPS Port eingeschränkt. (Anmerkung: die CONNECT Methode birgt viele Risiken für das lokale Netz (z.b. Tunneln von beliebigen Netzverkehr). Diese Methode ist aber die einzige Möglichkeit, HTTPS Seiten über einen Proxy Server zu leiten. Es ist daher zu klären, ob der Zugriff auf HTTPS Seiten gewünscht wird.) Der Squid greift nur auf Server Dienste zu, die auf einen über die ACL Safe_ports definierten Port horchen. (Der Zugriff auf Port 25/SMTP sollte unbedingt verboten werden, da die Unterschiede zwischen dem HTTP Protokoll und SMTP Protokoll nur gering sind. Der Proxy Server kann daher in diesem Fall als Mail Relay verwendet werden. Dies ist in der Regel nicht erwünscht.). Das Regelwerk ist so zu ergänzen, dass lokale Benutzer auf den Proxy Dienst zugreifen können (ggf. nach erfolgter Proxy Authentisierung). Diese ACLs sind im Einzelnen: #Recommended minimum configuation: acl all src / acl manager proto cache_object acl localhost src / acl to_localhost dst /8 acl SSL_ports port acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port # https, snews acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http Bundesamt für Sicherheit in der Informationstechnik 6

7 acl Safe_ports port 591 acl Safe_ports port 777 acl CONNECT method CONNECT # filemaker # multiling http # TAG: http_access # Allowing or Denying access based on defined access lists # # Access to the HTTP port: # http_access allow deny [!]aclname... # # NOTE on default values: # # If there are no "access" lines present, the default is to deny # the request. # # If none of the "access" lines cause a match, the default is the # opposite of the last line in the list. If the last line was # deny, the default is allow. Conversely, if the last line # is allow, the default will be deny. For these reasons, it is a # good idea to have an "deny all" or "allow all" entry at the end # of your access lists to avoid potential confusion. # #Default: # http_access deny all # #Recommended minimum configuration: # # Only allow cachemgr access from localhosts http_access allow manager localhost http_access deny manager # Deny requests to unknown ports http_access deny!safe_ports # Deny CONNECT to other than SSL ports http_access deny CONNECT!SSL_ports # # We strongly recommend the following be uncommented to protect innocent # web applications running on the proxy server who think the only # one who can access services on "localhost" is a local user #http_access deny to_localhost # # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS # Example rule allowing access from your local networks. Adapt # to list your (internal) IP networks from where browsing should # be allowed #acl our_networks src / /24 #http_access allow our_networks # And finally deny all other access to this proxy http_access deny all Zusätzlich zu diesen ACLs sollten ggf. der Zugriff auf die HTTP Methode PURGE sowie auf die SNMP Schnittstelle auf den lokalen Host eingeschränkt werden. Diese ACLs sind vor den benutzerspezifischen Zugriffsregeln in der Konfigurationsdatei squid.conf einzufügen: # allow purge from localhost acl PURGE method PURGE http_access allow localhost PURGE http_access deny PURGE Bundesamt für Sicherheit in der Informationstechnik 7

8 # snmp acl SNMP snmp_community <community> snmp_access allow localhost SNMP 2.3 Sicherheitsmaßnahmen für den Betrieb des Squid Monitoring des Squid Die Hauptaufgabe der Überwachung des Squid ist es sicherzustellen, dass die Leistung des Squid erwartungsgemäß ist. Dies erfordert es, Aussagen darüber zu treffen, ob Squid ausreichende Systemressourcen zur Verfügung gestellt bekommt (Hauptspeicher, Bandbreite, Plattenplatz, Dateideskriptoren etc.), ob die Ursache einer langsamen Internetverbindung bei dem Squid zu suchen ist, ob jemand den Squid Dienst missbraucht oder ob ein Angreifer versucht in den Proxy einzubrechen. Squid stellt zur Beantwortung dieser Fragen Informationen an drei unterschiedlichen Stellen zur Verfügung: cache.log Meldungen, im Cache Manager und optional in einer SNMP MIB. cache.log Meldungen Squid schreibt eine Vielzahl von unterschiedlichen Meldungen während seiner Laufzeit in die Protokolldatei /usr/local/squid/logs/cache.log. Die meisten dieser Meldungen betreffen ungewöhliche Ereignisse. Diese Datei ist ein guter Ausgangspunkt für die Untersuchung von Problemen des Squid. Der Umfang der Protokollierung lässt sich über den Konfigurationsparameter debug_options selektiv für die einzelnen Squid Programmkomponenten einstellen. Bei Problemen in einzelnen Programmkompontenten (z.b. Authentisierung) lässt sich der Debug Level dieser Komponente erhöhen und durch die Auswertung der Protokolldatei cache.log lässt sich das Problem eingrenzen. Die Programmkomponenten sind dazu in Sektionen eingeteilt. Diese Einteilung kann u.a. in Tabelle 16-1 im Buch Squid The Definitive Guide nachgeschlagen werden (siehe Kapitel 5 [3]). Als Beispiel wird im Folgenden die Möglichkeit aufgezeigt, wie ACL Listen überprüft werden können. In der Datei /usr/local/squid/etc/squid.conf wird für das Debug Level von Sektion 33 (client_side.c) auf 2 erhöht: debug_options ALL,1 33,2 Anschließend wird Squid diese Änderung mitgeteilt (bzw. neu gestartet) bash# squid -k reconfigure Anschließend enthält die Datei cache.log für jede Anfrage einen Eintrag, warum diese von Squid akzeptiert oder abgelehnt wurde. Weiterhin enthält cache.log auch für diese Anfrage den Namen der letzten prozessierten ACL, die zu dieser Entscheidung geführt hat. Falls dies nicht ausreicht kann zusätzlich die Protokollierung der Verarbeitung der ACLs eingeschaltet werden. Dazu kann das Debug Level von Sektion 28 (acl.c) auf 9 erhöht werden Bundesamt für Sicherheit in der Informationstechnik 8

9 debug_options ALL,1 33,2 28,9 Squid ist diese Änderung der Konfiguration mitzuteilen (s.o.). Diese Einstellung erzeugt eine große Anzahl von Einträgen in der Protokolldatei cache.log. Es gibt auch eine einfach Möglichkeit während des Betriebes von Squid, die maximale Protokollierung einzuschalten: bash# squid -k debug Dieses bewirkt, dass jedes debug() Kommando des Quellcodes in der Datei cache.log protokolliert wird. Wird das gleiche Kommando wiederholt, so wird die in der Squid Konfigurationsdatei eingestellte Protokollierung wieder hergestellt. Der Cache Manager Der Cache Manager von Squid ist ein Interface, um Informationen über verschiedene Komponenten des Squid zu bekommen. Er wird über normale HTTP Anfragen mit dem Pseudoprotokoll cache_object angesprochen. Ein typischer URL den Cache Manager anzusprechen lautet : cache_object://<ip Adresse des Squid>:3128/info Der Cache Manager kann prinzipiell von einem entfernten Rechner über das HTTP Protokoll angesprochen werden. Da er aber teilweise sensitive Daten bereitstellt und das HTTP Protokoll keine Sicherheitsfunktionen bereitstellt, wurde in der Konfigurationseinstellung des Squid (siehe Kapitel 2.2) empfohlen, den Zugriff auf den Cache Manager nur von dem Squid System selbst zuzulassen. Squid bietet zwei Möglichkeiten an, den Cache Manager anzusprechen. Dies sind squidclient und ein CGI Programm cachemgr.cgi. Squidclient ist ein einfaches HTTP Client Programm, das Squid spezifische Merkmale aufweist. Ein Merkmal ist die Möglichkeit, auf Seiten des Cache Managers zugreifen zu können: bash# squidclient cache_object://localhost/info oder kürzer: bash# squidclient mgr:info (Anmerkung: squidclient spricht per Default den Rechner localhost auf Port 3128 an. Ein anderes System kann mittels der Option -h <IP Adresse> und ein anderer Port mittels der Option -p <Port Nummer> angesprochen werden. ) Der Cache Manager gibt unformatierten Text aus. Das CGI Programm cachemgr.cgi erfordert die Installation eines Web Servers, der dieses Programm ausführen kann. Dieses Skript spricht den Cache Manager über seine HTTP Schnittstelle an. Daher ist es empfehlenswert bei dem Einsatz von cachemgr.cgi auf dem Squid System einen eigenständigen Web Server zu installieren. Dieser Web Server seinerseits sollte daher nur lokal ansprechbar sein (z.b. bei dem Einsatz eines Apache Servers über die Einstellung Listen :80 in der Datei httpd.conf). Der Zugriff auf den Cache Manager mittels Browser ist dann ebenfalls nur lokal möglich. Eine entfernte Darstellung kann dennoch durch geeignete Konfiguration des SSH Dienstes (X11 Forwarding) erreicht werden. Das Skript bereitet die Informationen des Cache Manager graphisch auf. Eine Übersicht der über den Cache Manager zur Verfügung stehenden Seiten ist in der Tabelle 14-1 des Buches (siehe Kapitel 5 [3]) zu finden. Der Cache Manager stellt eine Vielzahl von sensitiven Informationen zur Verfügung und sollte daher vor unbefugten Zugriffen geschützt werden. Durch Zugriffsrechte kann erreicht werden, dass der Cache Manager nur lokal ansprechbar ist. (Diese Maßnahme setzt allerdings voraus, dass sich nur Administratoren auf dem Squid System anmelden können): Bundesamt für Sicherheit in der Informationstechnik 9

10 acl manager proto cache_object acl localhost src / http_access allow manager localhost http_access deny manager Als zusätzliche Maßnahme können unterschiedliche Passworte auf die Seiten des Cache Managers über die Konfigurationsparameter cachemgr_passwd gesetzt werden. Besonders sensitive Seiten des Cache Managers (shutdown, offline_toggle, config), sind nur erreichbar, wenn ein Passwort auf diese Seiten gesetzt wird: cachemgr_passwd <secret> config shutdown offline_toggle Nicht benötigte Seiten des Cache Managers können auch abgeschaltet werden. Dazu ist als Passwort disable für diese Seiten zu setzen: cachemgr_passwd disable netdb Die Squid SNMP MIB Squid verfügt über einen SNMP Agenten, der durch unterschiedliche SNMP Client Werkzeuge angesprochen werden kann. Es können über den Agenten einige Statistiken bezüglich des Betriebszustandes von Squid abgerufen werden. Allerdings stehen nicht alle relevanten Informationen von Squid zur Verfügung. Eine Nutzung des SNMP Dienstes kann daher nur eingeschränkt empfohlen werden. Weiterhin unterstützt der SNMP Agent nur SNMP in der Version 1. SNMP in der Version 1 ist für administrative Aufgaben aus Sicherheitssicht wie das HTTP Protokoll zu bewerten. Die einzige Sicherheitsmaßnahme von SNMP V 1 besteht darin, dass bei der Kommunikation mit dem SNMP Agenten ein Community Name als Passwort erforderlich ist. Dieser wird aber über das Netzwerk im Klartext übertragen. In der Konfigurationseinstellung des Squid (siehe Kapitel Fehler! Verweisquelle konnte nicht gefunden werden.) wurde daher empfohlen, den Zugriff auf den SNMP Agenten des Squid ebenso wie die Zugriffe auf den Cache Manager nur von dem Squid System selbst zuzulassen. Der Konfigurationsparameter -enable-snmp sollte daher, solange die Nutzung von SNMP vermieden werden kann, nicht gesetzt sein. Die Squid MIB liegt innerhalb des globalen MIB Baumes unter iso.org.dod.internet.private.enterprises.nlanr.squid (bzw ). Der Squid SNMP MIB Baum wird in dem Quell Code von Squid in der Datei src/mib.txt mitgeliefert. Dieser MIB Baum sollte in das verwendetet SNMP Überwachungswerkzeug integriert werden. Ein einfaches öffentlich zur Verfügung stehendes Werkzeug ist NET-SNMP ( Die MIB Bäume dieses Werkzeuges ist bei Standardinstallationen unter den Verzweichnis /usr/share/snmp/mibs (Debian Release 3) abglegt. Die Squid MIB ist in dieses Verzeichnis zu kopieren: bash# cp squid-2.5.stable7/src/mib \ /usr/share/snmp/mibs/squid-mib.txt Anschließend ist es mit snmpget möglich, auf die Squid MIB zuzugreifen (falls SNMP in Squid konfiguriert wurde). bash# snmpget -v 1 -c <community> \ -m SQUID-MIB localhost:3401 cacheversionid Hierbei ist als SNMP-Community der Name anzugegeben, der in der Squid Konfigurationsdatei über die ACL snmp_community und snmp_access eingestellt wurde:. acl SNMP snmp_community <community> snmp_access allow localhost SNMP Bundesamt für Sicherheit in der Informationstechnik 10

11 Squid verwendet per Default den UPD Port 3401 für SNMP. Dies kann über den Konfigurationsparameter snmp_port verändert werden. snmp_port Wartung des Squid Die Wartungsarbeiten umfassen Softwareaktualisierungen (z.b. aufgrund von bekannt gewordenen Sicherheitsschwächen) und Konfigurationsänderungen (z.b. aufgrund von neuen Anforderungen). Alle Wartungsarbeiten sollten protokolliert werden. Squid stellt für diese Aufgabe keine eigenen Möglichkeiten zur Verfügung. Die vorgenommen Änderung sollten daher in einem Systemhandbuch dokumentiert werden. Softwareaktualisierungen Der Prozess, wie die Administratoren des Squid die Informationen über notwendige Softwareaktualisierungen des Squid verfolgen, ist zu definieren. Eine gute, derzeit öffentlich zugängliche Informationsquelle sind u.a. und diverse Mailing Listen (u.a. Full Disclosure, Securityfocus oder kommerzielle Dienste wie dcert ). In der Regel kann davon ausgegangen werden, dass die Squid Entwickler zeitnah Softwareaktualisierungen auf der Squid Web Seite bereitstellen. Unter dem URL sind die verfügbaren Squid Versionen ermittelbar. Folgt man dem entsprechenden Verweis auf dieser Seite gelangt man zu der Web Seite der jeweils aktuellen Squid Version (derzeit 2.5). Weiterhin ist auf dieser Seite ein Verweis auf Informationen zu den verfügbaren Patches vorhanden. Im Systemhandbuch des Squid ist im Rahmen von Softwareaktualisierungen mindestens zu protokollieren: der Zeitpunkt, wann die Administratoren über die notwendige Softwareaktualisierung des Squid informiert wurden alle Maßnahmen, die daraus resultierend getroffen wurden. Hierbei ist zu protokollieren wer die einzelnen Maßnahmen veranlasst hat, wer diese durchgeführt hat und wer informiert wurde. Zu protokollieren sind auch die dazugehörigen Zeiten. (Anmerkung: Eine mögliche Aktion kann auch sein, dass eine Überprüfung ergeben hat, dass die von der Sicherheitsschwäche betroffene Sofwarekomponente des Squid nicht eingesetzt wird und daher eine Softwareaktualisierung nicht notwendig ist.) Konfigurationsänderungen In den meisten Einsatzumgebungen sind Konfigurationsänderungen des Squid nur selten erforderlich. Eine Ausnahme hiervon sind Einsatzumgebungen, bei denen der Squid ein umfangreiches ACL Regelwerk mit benutzerspezifischen Zugriffsregeln auf Web Ressourcen hat. In diesem Fall ist ein Prozess zu definieren, bei dem die Administratoren des Squid über Personalveränderungen informiert werden. Dieser Prozess muss dabei definieren, welche Änderungen des ACL Regelwerkes mit der Personalveränderung (Einstellung, Ausscheiden von Mitarbeitern, veränderter Aufgabenbereich) verbunden sind. Für den laufenden Betrieb sind in diesem Zusammenhang zwei Konfigurationsänderungen zu erwähnen, die in der Regel nur temporär durchgeführt werden. Diese sind offline Betrieb: in diesem Betriebsmodus werden alle Inhalte zunächst aus dem Cache des Squid geholt. Inhalte, die nicht im Cache zu finden sind, werden von entfernten Systemen geholt. (Dieser Betriebsmodus kann sinnvoll sein, wenn die Verbindung in das Internet sehr langsam oder sogar ausgefallen ist.) Eingestellt wird dieser Modus über den Konfigurationseinstellung offline_mode on. Falls ein Passwort auf die Cache Manager Seite offline_toggle Bundesamt für Sicherheit in der Informationstechnik 11

12 gesetzt ist, kann dieser Betriebsmodus über den Cache Manager ein- bzw. wieder ausgestellt werden: bash# squidclient Achtung: das Passwort wird hier in der URL übergeben und daher in den Squid Protokolldateien gespeichert. Wenn dieser Betriebsmodus eingestellt wird, sollten die Nutzer des Squid Dienstes darüber informiert werden, dass ggf. nicht aktuelle Web Inhalte ausgeliefert werden. Erhöhung des Debugging Levels: zu Diagnosezwecken kann es erforderlich sein den Debugging Level zu erhöhen (siehe Kapitel 0). Zu berücksichtigen ist hierbei, dass ggf. in der Protokolldatei cache.log sensitive Informationen gespeichert werden (z.b. Proxy Authentisierungsinformationen im Falle des Einsatzes einer Basic Authentisierungsmethode.) Es ist daher zu klären, wie mit diesen Informationen umgegangen wird. Dazu muss fesgelegt werden, wer diese Dateien einsehen darf, wie lange diese Daten gespeichert werden. Die Einsichtnahme muss protokolliert werden. Im Systemhandbuch des Squid ist im Rahmen von Konfigurationsänderungen mindestens zu protokollieren: der Zeitpunkt der Konfigurationsänderung und der Administrator, der die Änderung durchgeführt hat. Eine sinnvolle Ergänzung hierzu ist die Sicherung aller produktiven Squid Konfigurationsdateien. Es muss dabei möglich sein zu ermitteln, wann die jeweiligen Konfigurationsdateien gültig waren. 3 Zusätzliche empfehlenswerte Sicherungsmaßnahmen Es lassen sich hier Maßnahmen, die dem Schutz des Squid Systems dienen, und Maßnahmen, die dem Schutz des lokalen Netzwerks dienen, unterscheiden. Hierbei sind allerdings die Grenzen fließend. So erhält man beispielsweise durch die Auswertung von Protokollen sowohl Hinweise auf Sicherheitsprobleme des Squid als auch Hinweise auf mögliche Sicherheitsprobleme des lokalen Netzes. 3.1 Zusätzliche Maßnahmen zum Schutz des Squid Einsatz von Intrusion Detection Systemen Neben einer Firewall kann ein Intrusion Detection bzw. Intrusion Prevention System (IDS/IPS) einen weiteren Schutz des Squid gewährleisten. Im Einsatzszenario Regulärer Proxy wird der Squid in der Regel nur von lokalen Benutzern angesprochen. Angriffe gegen den Squid sind in diesem Einsatzszenario daher unwahrscheinlicher. Zusätzlich sind die Daten, die auf dem Squid gespeichert sind, auch öffentlich zugänglich (abgesehen von den Protokolldateien). IDS/IPS Systeme werden daher in der Regel für einen erweiterten Schutz von Regulären Proxy Servern nicht betrieben. Im Einsatzszenario Reverse Proxy arbeitet das Squid System als Web Server und kann somit Ziel von entfernten Angreifern (Hacker) sein. Hier bietet es sich an, IDS/IPS Systeme, die zum Schutz des Web Auftritts eingesetzt werden, auch zum Schutz des Squid einzusetzen. (In diesem Szenario stellt der Squid einen zentralen Teil des Web Auftritts dar. Die Sensitivität der Daten, die auf dem Squid verarbeitet werden, hängt entscheidend von dem Web Auftritt ab.) Bundesamt für Sicherheit in der Informationstechnik 12

13 3.2 Zusätzliche Maßnahmen zum Schutz des lokalen Netzwerkes Auswertung von Protokolldateien mittels externer Programme Die Protokolldateien des Squid wachsen in der Regel schnell. Weiterhin ist die Form, in der die darin enthaltenen Daten gespeichert werden, nicht lesefreundlich. Für die Auswertung der Protokolldateien werden daher in der Regel Auswertungsprogramme eingesetzt, um die darin enthaltenen relevanten Informationen für die Administration des Squid zugänglich zu machen. Es stehen eine Reihe von öffentlichen Programmen zur Auswertung von Squid Protokolldateien zur Verfügung. Im Folgenden werden zwei dieser Programme kurz vorgestellt: Calamaris Version 2 (V2.59); bzw. in einer Beta Version (V3-beta) mit erweiterte Funktionalität ( Calamaris kann die folgenden Berichte erzeugen: 1. Zusammenfassung 2. Spitzenlast-Bericht 3. Request-Methoden-Bericht (ICP_QUERY, GET, HEAD,...) 4. Status-Bericht über einkommende UDP-Requests 5. Status-Bericht über einkommende TCP-Requests 6. Status-Bericht über ausgehende Verbindungen 7. Status-Bericht für Neighbor-Caches 8. Bericht über angefragte Second- oder Third-Level-Domains 9. Bericht über angefragte Top-Level-Domains 10. Protokoll-Bericht (http, gopher, ftp,...) 11. Bericht über angefragte Content-Types 12. Bericht über angefragte Datei-Extensionen 13. Bericht über einkommende UDP-Anfragen per Host 14. Bericht über einkommende TCP-Anfragen per Host 15. Bericht über die Verteilung der angefragten Objekte nach Größe 16. Bericht über die Performance in definierten Zeitschritten. 17. Bericht über die Verteilung der Laufzeiten. (nur V3-beta-Version) 18. Bericht über die Verteilung der HTTP-Fehlercodes. (nur V3-beta-Version) 19. Erweiterter Bericht über die Datei-Extensionen. (nur V3-beta-Version) 20. Mehr Informationen in allen weiteren Berichten. (nur V3-beta-Version) Weitere Eigenschaften von Calamaris Caching der erfassten Daten HTML-Output Grafiken (nur V3-beta-Version) Kommandozeilen-Optionen Konfigurationsdatei (nur V3-beta-Version) GNU Public License Webalizer ist ein freies Werkzeug zur Auswertung von Protokolldateien von Web Servern. Es erzeugt detaillierte Berichte in HTML-Format, die mit einem Standard Web Browser angesehen werden können. Webalizer verfügt auch über die Möglichkeit, Squid Protokolldateien auszuwerten. Allerdings können die Squid spezifischen Informationen in den Protokoll von Webalizer nicht aufbereitet werden. Die Software kann von bezogen werden. Gegenwärtig ist die Version aktuell. Die folgende Abbildung zeigt ein Beispiel eines Berichtes von den Protokolldateien eines Web Servers: Bundesamt für Sicherheit in der Informationstechnik 13

14 Abbildung 1: Beispiel eines Webalizer Berichtes von den Protokolldateien eines Web Servers Einbindung von externen Filterprogrammen Externe Filterprogramme stellen eine interessante Möglichkeit zur Erweiterung der Squid Funktionalität dar. Im Folgenden werden zwei dieser Programme kurz vorgestellt: SquidGuard Squid bietet die Möglichkeit an, Filterungen an ein externes Programm auszulagern. Dazu dient die Redirector Schnittstelle. Ein Redirector ist ein Programm, das eine von Squid übergebene URI in eine andere umwandelt und diese an Squid zurückgibt. Anstatt der ursprünglichen URI fordert Squid die durch das externe Programm zurückgegebene URI an. SquidGuard wird unter der Gnu Public License (GPL) veröffentlicht. Die wesentlichen Eigenschaften von SquidGuard sind: hohe Konfigurierbarkeit; es ist möglich verschiedene Regeln für verschiedene Gruppen von Client Systemen und Benutzern tageszeitabhängig zu definieren, Ersetzen von URI, Bundesamt für Sicherheit in der Informationstechnik 14

15 Erzeugung von an die Anfrage angepassten Fehlermeldungen, Unterstützung 301/302/303/307 HTTP Redirect Meldungen, Selektive Protokollierung. Allerdings muss darauf hingewiesen werden, dass SquidGuard keinen Schutz vor aktiven Inhalten (z.b. ActiveX, Java und Javascript) bietet. Auf der SquidGuard Web Seite befindet sich auch eine Blacklist von unterschiedlich kategorisierten Web Sites (Werbung, Aggressiv, Audio-Video, Pornographie, Spiele, Hacking, Gewalt, Warez). Squid-vscan Patch Eine weitere Möglichkeit, Squid zu erweitern, bietet das OpenAntiVirus-Projekt mit Squid-vscan ( bzw. Squid-vscan steht als Patch für Squid zur Verfügung, der Squid um einem Virenscanner erweitert. Squid-vscan gibt es derzeit für Squid 2.5 Stable6 die Entwicklung hängt hinter der aktuellen Version des Squid leider etwas hinterher. Mit Squid-vscan kann Squid auf alle Web Inhalte filtern (neben Viren auch Java, JavaScript und ActiveX). Dies bedeutet eine viel höhere Last auf dem Squid System als ohne diese Filterung. Dies ist bei der Auslegung der Hardware des Squid Systems zu berücksichtigen. (Anmerkung: Schädliche Inhalte, die verschlüsselt über den Proxy übermittelt werden z.b. über HTTPS, können natürlich nicht von Squid-vscan gefiltert werden. Daher kann eine Filterung auf dem Proxy die lokalen Maßnahmen an den Client Systemen keinesfalls ersetzen.) Bundesamt für Sicherheit in der Informationstechnik 15

16 4 Sicherheitsrichtlinien und Checklisten Die nachfolgende Checkliste führt die Prüfpunkte auf, deren Soll-Ergebnis im Rahmen einer Sicherheitsanalyse von Squid erfüllt heißen sollte. Die Prüfliste umfasst nur die Squid spezifischen Punkte. Alle anderen betriebssystemspezifischen Punkte (u.a. Backup/Recovery, Zugriff auf den Root Account, entfernte Administration) werden in der Checkliste nicht berücksichtigt. Einzelne Punkte, die nicht zutreffen, können im Feld Bemerkung gekennzeichnet werden. Sofern sich die Prüfergebnisse belegen lassen, sollten entsprechende Referenzen ebenfalls im Feld Bemerkung eingetragen werden. Prüfvorgabe Erfüllt Nicht Erfüllt Organisatorische Maßnahmen Es muss eine Betriebsvereinbarung über die Protokollierung von Zugriffen auf den Squid sowie ggf. über die Auswertung der Squid Protokolldateien bestehen. Die in der Betriebsvereinbarung getroffenen Regelungen über die Protokollierung sind auf Einhaltung zu überprüfen (Umfang der Protokollierung, ggf. Anonymisierung der Protokollierung, Backup/Archivierung von Protokollen etc.) Es muss einen Prozess geben, bei dem Administratoren des Squid auf veröffentlichte Sicherheitsschwächen von Squid hingewiesen werden. Dieser Prozess muss auch die erforderlichen Maßnahmen definieren. (Einspielen von Patches, Abstellen des Dienstes etc.) Systemzugang/Betriebssystem Administrative Zugriffe (PURGE Methode, Zugriff auf den Cache Manager, SNMP dürfen nur lokal möglich sein). Die Konfigurationsdatei (squid.conf) ist nach den entsprechenden Einträgen zu beurteilen: acl PURGE method PURGE http_access allow localhost PURGE http_access deny PURGE acl SNMP snmp_community <community> snmp_access allow localhost SNMP snmp_access deny SNMP acl manager proto cache_object http_access allow localhost manager http_access deny manager (Anmerkung: Die HTTP Methode PURGE, sowie der Zugriff über SNMP sind verboten, wenn in der Konfigurationsdatei nichts eingestellt ist.) Bemerkung Bundesamt für Sicherheit in der Informationstechnik 16

17 Prüfvorgabe Erfüllt Nicht Erfüllt Das System hat nur die für den Squid notwendigen Dienste anzubieten (dies ist im wesentlichen der HTTP Dienst und ggf. die Dienste, die innerhalb von Cache Hierarchien benötigt werden). Weiterhin ist es sinnvoll für die entfernte Administration den SSH Dienst zuzulassen. Zur Überprüfung kann der Befehl bash# netstat -an - protocol=inet durchgeführt werden. Die Administratoren sollten zu den hier gemeldeten offenen Ports die entsprechenden Anwendung bzw. Anwendungskomponenten benennen können. Diese sind zu protokollieren. Anmerkung: Squid benötigt einen TCP Port für HTTP Anfragen (Default Wert 3128) und einen UDP Port für DNS Anfragen (diese Port Nummer ist variabel). Mit dem Befehl bash# lsof -n -p <PID des Squid> egrep UDP TCP grep -v ESTABLISHED können die von Squid geöffneten Sockets angezeigt werden. In einer typischen Installation sollte die Ausgabe dieser Befehls anlog der folgenden aussehen: squid root 9u IPv UDP *:32780 squid root 10u IPv TCP :3128 (LISTEN) squid root 12u IPv UDP :3401 Über den ersten Socket laufen die DNS Anfragen. Der zweite Socket ist für die HTTP Kommunikation mit den HTTP Clients zuständig. Der Socket nimmt nur Anfragen auf die IP Adresse an. (Diese Enschränkung ist im Szenario Regulärer Proxy auf einer Firewall wichtig.) Der letzte Socket stellt den SNMP Dienst zur Verfügung und ist nur auf der IP Adresse ansprechbar. Der Port 3130 UDP (ICP Version 2) ist in einer Standardinstallation aktiv. Dieser sollte über den Konfigruationseinstellung icp_port 0 abgestellt werden. Nur Administratoren sollten über einen Zugang zum Betriebssystem des Squid verfügen. (Überprüfung der Dateien /etc/nsswitch.conf nach konfigurierten Systemzugängen (Einträge passwd und shadow) sowie der dazugehörigen Konfigurationsdateien (z.b. /etc/passwd und /etc/shadow bei der Konfigurationseinstellung files ). Die Anmeldung der Administratoren sollte immer über personalisierte Accounts erfolgen. Sicherheitsprotokollierung Protokollierungsdaten, für die keine dokumentierte Zweckbindung existiert, sollten nicht entstehen und auch nicht gespeichert werden. Unterstützung kryptographischer Verfahren (nur Reverse Proxy) Bemerkung Bundesamt für Sicherheit in der Informationstechnik 17

18 Prüfvorgabe Erfüllt Nicht Erfüllt Der Squid sollte nur ausreichend starke Verschlüsselungsmethoden unterstützen (SSLv2 sollte deaktiviert werden Überprüfung der Einstellung des Parameters https_port). Der private Schlüssel des SSL Zertifikates ist vor Unbefugten durch entsprechende UNIX Rechte zu schützen. (Nur Administratoren und der Squid Prozess dürfen Zugriffsrechte auf die Datei haben. In dem Protokoll kann ggf. der Pfad der Datei und die Dateirechte aufgenommen werden.) Konfiguration des Squid Eingesetzte Version / Eingespielte Patches (Vergleich mit den verfügbaren Versionen/Patches auf den Web Seiten) bzw. und Überprüfung der Rechte, mit denen die Squid Prozesse (und die konfigurierten Hilfsprogramme) laufen. Ausführen des Befehls ps auwx in einer Shell. Notieren der Benutzer-IDs mit denen die Squid Prozesse (squid, unlinkd, Hilfsprogramme) laufen. Überprüfung der Einstellung der Parameter cache_effective_user und cache_effective_group in der Squid Konfigurationsdatei. Überprüfung der Rechte des Squid Benutzers (keine Login Rechte: kein gültiges Passwort (z.b. *LOCKED* im entsprechenden Feld der Passwortdatei und keine Login- Shell, Überprüfung der Zugriffsrechte auf die Protokolldateien des Squid und des Squid Caches (nur der Squid Benutzer sollte Schreib- und Leserechte auf diese Dateien haben.) Der Squid Dienst sollte in einer chroot Umgebung laufen. Überprüfung der Umgebungsvariablen der Squid Prozesse im /proc Dateisystem. Der Eintrag /root sollte auf das chroot Verzeichnis zeigen. Bemerkung Bundesamt für Sicherheit in der Informationstechnik 18

19 Prüfvorgabe Erfüllt Nicht Erfüllt Zugriffsrechte auf den Squid (nur Regulärer Proxy) Falls gemäß Betriebsvorgaben eine Proxy Authentisierung erforderlich ist, ist dies zu überprüfen (ggf. mit einem Client System). Die CONNECT Methode sollte nur auf eingeschränkte Ports erlaubt sein (i.e. 443 (HTTPS) und 563 (NNTPS)). Bemerkung acl SSL_ports port acl CONNECT method CONNECT http_access deny CONNECT!SSL_ports Anmerkung: die CONNECT Methode ist gefährlich, da sich hierüber mit einfachen Mitteln beliebiger Netzverkehr tunneln lässt. Der Squid sollte sich nur an ungefährliche Ports verbinden können. in der Standardeinstellung gilt: acl Safe_ports port 80 acl Safe_ports port 21 acl Safe_ports port acl Safe_ports port 70 acl Safe_ports port 210 acl Safe_ports port acl Safe_ports port 280 acl Safe_ports port 488 acl Safe_ports port 591 acl Safe_ports port 777 http_access deny!safe_ports Anmerkung: Insbesondere ist es gefährlich, wenn der Squid Verbindungen auf Port 25 weiterleitet, da der Squid dann ggf. zum Versenden von Nachrichten missbraucht werden kann (SPAM). Zugriffsrechte auf den Squid (nur Regulärer Proxy) Fortsetzung: Der Squid sollte auf seinem HTTP Port nur Verbindungen von vertrauenswürdigen Netzen akzeptieren. Andernfalls könnte ein externer Angreifer das Squid System für Angriffe gegen interne Systeme missbrauchen. acl All src /0 acl MyNetwork src <IP Adressbereich> http_access allow MyNetwork http_access deny All Anmerkung: die Access Regeln können bei produktiven Squid Systemen umfangreich ausfallen. Für die Bewertung des ACL Regelwerkes aus Sicherheitssicht ist daher ein entspechendes Wissen erforderlich. Bundesamt für Sicherheit in der Informationstechnik 19

20 Prüfvorgabe Erfüllt Nicht Erfüllt Proxy Authentisierung (nur Regulärer Proxy): Eine Proxy Authentisierung ist aus Sicherheitssicht nicht erforderlich, wenn alle Benutzer den Proxy nutzen dürfen und keine benutzerspezifischen Zugriffsregeln auf Internet Ressourcen definiert sind (in diesem Fall ist Erfüllt anzukreuzen). Andernfalls sollte eine Einschränkung des Zugriffs durch die Konfiguration der Proxy Authentisierung erfolgen. Aus Sicherheitssicht sollte als Authentisierungsmethode Digest oder NTLM verwendet werden, wobei Digest nach der Überzeugen der meisten Sicherheitsexperten als sicherer einzustufen ist. In der Praxis treten allerdings hierbei die folgenden Probleme auf: NTLM: Hierbei handelt es sich um ein properitäres Protokoll von Microsoft und wird daher nicht von allen gängigen Browsern unterstützt. (Aktuelle Versionen von Firefox (1.0) und Mozilla (ab 1.4 Beta) unterstützen NTLM; Opera unterstützt NTLM nicht). Digest: Im Lieferumfang von Squid steht als Authentisierungsdatenbank nur eine Passwortdatei zur Verfügung. Ein Management der Proxy Benutzer ist dadurch erschwert. Aus Sicherheitssicht sind die Standardeinstellungen bei den Proxy Authentisierungsparametern empfehlenswert. NTLM: auth_param ntlm children 5 auth_param ntlm max_challenge_reuses 0 auth_param ntlm max_challenge_lifetime 2 minutes auth_param ntlm use_ntlm_negotiate off Bemerkung Digest: auth_param digest children 5 auth_param digest nonce_garbage_interval 5 minutes auth_param digest nonce_max_duration 30 minutes Bundesamt für Sicherheit in der Informationstechnik 20

21 5 Literaturverzeichnis [1]: Sicherheitsuntersuchung des Squid Proxy Servers, Feinkonzept, 2004 [2]: Sicherheitsuntersuchung des Squid Proxy Servers, Analyse des Squid Proxy Servers, 2005 [3]: Duane Wessels, Squid The Definitive Guide, 2004 Bundesamt für Sicherheit in der Informationstechnik 21