Konfiguration von Bastionsrechnern in einem Grenznetz. an den Beispielen Webserver und Proxy

Transkript

1 Konfiguration von Bastionsrechnern in einem Grenznetz an den Beispielen Webserver und Proxy Konfiguration von Bastionsrechnern in einem Grenznetz... 1 an den Beispielen Webserver und Proxy... 1 Einleitung:... 2 Begriffserklärung... 3 Grenznetz... 3 Bastionsrechner:... 3 Proxy:... 4 Webserver:... 4 Webserver im Grenznetz... 4 Kurze Einführung in Apache... 4 Mögliche Sicherheitseinstellungen in der Apache Konfiguration... 5 Nutzer Authentifikation:... 5 Zugriffskontrolle:... 6 Verzeichnisindizes:... 8 Virtual Hosts:... 9 Der Apache Server im Grenznetz Proxy Server im Grenznetz Konfigurieren des Squid Proxies Grundkonfiguration des Proxies... 12

2 Einleitung: Da heutzutage schon jedes kleinere Netz eine Anbindung zum Internet hat, besteht jederzeit die Möglichkeit diese von außen anzugreifen. Möglichkeiten im groben zusammengefasst: Daten, insbesondere wichtige Firmendaten auslesen aber nicht aktiv etwas verändern -> Spionage Manipulierend(schreibend) auf interne Daten zugreifen, also aktiv verändern. Das setzt natürlich den lesenden Zugriff schon voraus. Manipulation von Systemkomponenten mit dem Ziel Sabotage an der Funktionalität zu betreiben. Das setzt den lesenden und schreibenden Zugriff voraus. Man kann sich gut vorstellen, dass dies für Firmen sehr schädlich sein kann, wenn Daten nach außen gelangen oder gar die Rechnernutzung lahm gelegt wird. Aus diesem Grund ist es notwendig das Firmeneigene Intranet von außen zu schützen ohne dabei den Zugriff von innen nach außen zu stark einzuschränken. Zu diesem Zwecke werden Firewalls eingerichtet, die es dem Angreifer möglichst schwer machen auf die internen Daten zuzugreifen. Einen 100% igen Schutz jedoch bieten sie nicht. Die Konzeption einer Firewall kann je nach Bedarf sehr verschieden ausfallen. Natürlich muss man ein privates kleines Netzwerk mit wenig interessanten Daten nicht so aufwendig schützen wie ein Firmanintranet. Das ist ja schließlich auch mit Kosten verbunden. Für den Heimgebrauch gibt es spezielle Softwarelösungen auf die wir hier aber nicht näher eingehen möchten. Wir betrachten hier die Konzeption eines Grenznetzes indem sich Bastionsrechner befinden. Unsere Beispiele beziehen sich jeweils auf einen Webserver und einen http- Proxy. 2

3 Begriffserklärung Im Folgenden wollen wir zu den benutzten Begriffen einige Erklärungen geben. Grenznetz Um Netze vor anderen Netzen, von denen aus Angriffe zu erwarten sind, zu schützen, gibt es verschiedene Lösungen. Den umfassensten Schutz bietet die Lösung mit einem inneren sowie äußerem Router (Paketfilter auf Schicht 4 TCP/IP) und in diesem Grenznetz einzelne Bastionsrechner die unterschiedliche Dienste anbieten (Filterung auf Applikationsebene). Bastionsrechner: Ein Bastionsrechner ist eine geopferte Maschine, die sich in einem Grenznetz befindet. Auf diesem Rechner befinden sich keine Anwendungen oder Daten. Lediglich die nötigen Dienste um mit einem externen Netz zu kommunizieren werden installiert. Dabei kann ein Rechner viele Dienste, wie z.b. FTP, HTTP, SMTP ect. anbieten, oder jeder Dienst auf einem eigenen Bastionsrechner. Es ist einfacher die Dienste zu konfigurieren, wenn Sie auf verschiedenen Rechnern laufen. Das ist natürlich eine Frage der Finanzierung. Nach einem Angriff können Bastionsrechner neu konfiguriert werden. 3

4 Proxy: Ein Proxy ist ein Dienst, der stellvertretend für jemand anderen Anfragen ausführt. Anfragen von Workstations gehen an den Proxy und der stellt die Anfrage an den Server, wie wenn die Anfrage von ihm käme. Der Angefragte Server sieht nicht die eigentliche Adresse der anfragenden Workstation. Webserver: Als Webserver werden zum einen die kompletten Systeme, zum anderen aber vor allem die Webserversoftware bezeichnet. Die Webserversoftware ist dafür zuständig, Anfragen von Clients (Browser) entgegenzunehmen und Dokumente auszuliefern. Für die Kommunikation zwischen Client und Webserver wird das Protokoll HTTP verwendet. Als Webserversoftware kommt auf den meisten Hosts der Apache Webserver zum Einsatz. Wichtige Kriterien für die Auswahl eines geeigneten Servers sind folgende Punkte: Anzahl der User Aufgabe des Servers (Anbieten von Dokumenten, Datenbankanwendung) welche bestehenden Daten müssen ins Netz integriert werden (Access-DB, Oracle-DB, Word-Dokumente vorhandene Kenntnisse des Webmasters/Netzwerkadministrators Webserver im Grenznetz Am Beispiel des Apache http-servers Kurze Einführung in Apache Der Apache-Webserver hat einen Marktanteil von mehr als 50% und ist dadurch der mit Abstand meistverbreiteste Webserver im Internet. Viele namhafte Firmen und Organisationen benutzen den Apache-Webserver, um ihre Internetpräsenz zu realisieren. Der Apache entstand aus einer Gruppe engagierter Softwareentwickler, die sich zum Ziel gesetzt hatten, einen frei verfügbaren, leistungsfähigen Internetserver zu kreieren. Durch die Breite der Konfigurationsmöglichkeiten und den modularen Aufbau kann der Apache sehr praxosorientiert eingesetzt werden. Er unterstützt bestehende Standards wie Secure Socket Layer (SSL), Authentifizierungsmechanismen zur Absicherung sensibler Bereiche, Common Gateway Interface (CGI), Server Side Includes (SSI) und vieles mehr. Außerdem bietet die Konfiguration per Konfigurationsdateien gegenüber einer grafischen Oberfläche den Vorteil, daß der administrator ständig über die genauen Vorgänge und Einstellungen informiert ist. Auch unter großer Last verhält sich Apache sehr stabil. Durch die Verfügbarkeit des Apache-Quellcodes und eines APIs haben Entwickler die Möglichkeit, die Fähigkeiten des Apaches zu erweitern und ihren Bedürfnissen 4

5 anzupassen. Außerdem bietet die Kenntnis des Quellcodes Schutz vor "versteckten Features" bei sicherheitsrelevanten Anwendungen. Über den Programmkernel hinaus können diverse Module, z.b. Authentifizierungsmechanismen, problemlos integriert werden. Sie können Apache mühelos in Ihr bestehendes Betriebssystemumfeld integrieren, da er für eine Vielzahl von Betriebssystemen verfügbar ist. Mögliche Sicherheitseinstellungen in der Apache Konfiguration Der Apache hat normalerweise 3 Konfigurationsdateien: httpd.conf, access.conf und srm.conf. Diese liegen standardmäßig in dem Verzeichnis [Laufwerk]:\..\apache\httpd\conf. Die Einteilung in httpd.conf, access.conf und srm.conf ist historisch bedingt. Alle Konfigurationsdaten können technisch auch in httpd.conf stehen. Mit der Definition von virtuellen Hosts wird dies zwingend notwendig, da in den VirtualHost Klammern normalerweise Konfigurationsanweisungen aus allen 3 Bereichen stehen. Nutzer Authentifikation: (Das Modul mod_auth wird benötigt) Manchmal sollen nicht alle Dokumente für jeden Nutzer sichtbar sein. Deshalb wird eine NutzerAuthentifikation unterstützt. Im conf Verzeichnis sind dazu eine Password- (passwd) und eine Gruppendatei (group) anzulegen. Die Datei Passworddatei hat die Form: Nutzer:verschlüsseltes Password Nutzer:verschlüsseltes Password Nutzer:verschlüsseltes Password Im Support Verzeichnis befindet sich das Tool htpasswd zum Bearbeiten der Passworddatei: Aufruf: htpasswd [-c] Passworddatei User-ID mit dem Schalter -c wird eine neue Passworddatei erstellt. User-ID gibt den zu bearbeitenden bzw. neuzuerstellenden Nutzer an. Das Passwort wird dann interaktiv abgefragt. Zur Verschlüsselung wird die Systemfunktion crypt() verwendet. Die Gruppendatei hat die Form: Gruppe:Gruppenmitglied Gruppenmitglied... Gruppenmitglied Gruppe:Gruppenmitglied Gruppenmitglied... Gruppenmitglied Gruppe:Gruppenmitglied Gruppenmitglied... Gruppenmitglied Diese Datei kann mit jedem ASCII Editor erstellt werden. Das oben vorgestellte Verfahren zur Nutzerverwaltung ist das einfachste der vom Apache unterstützten Verfahren. Alternative Verfahren sind in der Orginal Dokumentation nachzulesen. Die eingerichteten Nutzer und Gruppen sind unabhängig von den im Betriebssystem eingerichteten Nutzern und Gruppen. Da diese Nutzer für alle Dokumente in dem Teilbaum von DocumentRoot bekannt sein sollen, ist in access.conf zu konfigurieren: <Location / > AuthName Test-System AuthType Basic AuthUserFile /usr/local/etc/httpd/conf/passwd 5

6 AuthGroupFile /usr/local/etc/httpd/conf/group </Location> Bei Bedarf wird in einem Authentifikationsfenster die User-ID und das Password abgefragt. Dabei wird der Wert von AuthName angezeigt. AuthType Basic besagt, daß User-ID und Password unverschlüsselt übertragen werden. Bei Verwendung von HTTP/1.1 (Client + Server) kann auch AuthType Digest angegeben werden. In diesem Fall wird das Password verschlüsselt über die Leitung geschickt. Grundsätzlich können für unterschiedliche Dokumenten-Teilbäume auch separate Password und Gruppendateien eingesetzt werden. Dies sind dann unterschiedliche Anwendungssysteme. Die Namen dieser Systeme sind dann mit AuthName kenntlich zumachen. Bei der Nutzung des BasicVerfahrens und einem Zugriff auf ein geschütztes Dokument entsteht zwischen Browser und Server folgende Kommunikation: Server -> Browser: Status 401 Unauthorized WWW-Authenticate: BASIC realm="test-system" Browser -> Server: Wiederholung der Dokumentanforderung Authorization: User-ID: Password (User-ID und Password sind Base64 codiert, damit nur ASCII Zeichen übertragen werden müssen.) Zugriffskontrolle: (hier wird das Modul mod_access benötigt) Die Konfigurationsanweisungen für die Zugriffskontrolle gehören nach access.conf. Name Wert Default Kontext Bemerkung allow from deny from Order Rechnername IP- Nr Domainname all Rechnername IP- Nr Domainname all deny,allow allow,deny deny,allow Require User-ID Group- ID valid-user <Directory>, <Files>, <Location>,<Limit>,.htaccess <Directory>, <Files>, <Location>,<Limit>,.htaccess <Directory>, <Files>, <Location>,<Limit>,.htaccess <Directory>, <Files>, <Location>,<Limit>, Erlaubt den Zugriff explizit für einen Rechner oder ein Sub- Netz. Verbietet den Zugriff explizit für einen Rechner oder ein Sub- Netz. deny,allow verbietet zuerst und läßt anschließend Ausnahmen zu. allow,deny erlaubt zuerst und schränkt anschließend die Erlaubnis ein. Erlaubt dem angegebenen 6

7 Satisfy All Any All.htaccess <Directory>, <Files>, <Location>,<Limit>,.htaccess Nutzer bzw. Gruppenmitglied den Zugriff. valid-user erlaubt jedem Nutzer aus der Passworddatei den Zugriff. Kombiniert die Kriterien bzgl. des Rechners und des Nutzers. All: beide Kriterien müssen erfüllt sein. Any: mindestens eins der beiden Kriterien muß erfüllt sein. Beispiel 1: Die Dateien des WWW-Verzeichnises /Info dürfen nur von den Rechnern und gelesen werden. <Location /Info > Order deny,allow deny from all allow from allow from </Location > Beispiel 2: Jeder darf die Dateien des WWW-Verzeichnises /Info lesen, nur nicht Rechner der Domain.tfh-wildau.de. <Location /Info > Order allow,deny allow from all deny from.tfh-wildau.de </Location > Beispiel 3: Die Dateien des WWW-Verzeichnises /Info dürfen nur von dem Nutzer meyer und den Mitgliedern der Gruppe service gelesen werden. <Location /Info > require user meyer require group service </Location > Beispiel 4: Die Dateien des WWW-Verzeichnises /Info dürfen nur von Nutzern gelesen werden, die sich authentifiziert haben und an einem Rechner der in der Domane.tfhwildau.de sitzen. <Location /Info > Order deny,allow deny from all 7

8 allow from.tfh-wildau.de require valid-user satisfy All </Location > Beispiel 5: Die Dateien des WWW-Verzeichnises /Info dürfen ohne Authentifikation von den Rechnern der Domaine.tfh-wildau.de gelesen werden. Nur die Mitglieder der Gruppe sevice dürfen von Rechnern außerhalb der Domaine.tfh-wildau.de auf das WWW- Verzeichnis /Info zugreifen. <Location /Info > Order deny,allow deny from all allow from.tfh-wildau.de require group service satisfy Any </Location > Mit der Klammer <Limit Methode >... </Limit> können die Zugriffsrechte auf einzelne Zugriffsmethoden beschränkt werden. In HTTP/1.1 gibt es die Methoden: DELETE, GET, HEAD, OPTIONS, POST, PUT und TRACE. Das folgtende Beispiel 7 erlaubt nur Zugriffe mit der Methode POST nur von der Domane.thf-wildau.de. Alle anderen Zugriffsmethoden sind nicht beschränkt. <Location /Info > <Limit POST > order deny,allow deny from all allow from.tfh-wildau.de </Limit> </Location > Beispiel 7: Das WWW-Dokument /Info/geheim.html darf nur von den Rechnern und gelesen werden. <Location /Info/geheim > Order deny,allow deny from all allow from allow from </Location > Alternativ kann auch konfiguriert werden: <Directory /usr/local/etc/httpd/htdocs/info > <Files geheim.html > Order deny,allow deny from all allow from allow from </Files > </Directory > Verzeichnisindizes: (hier wird das Modul mod_mime benötigt) Wird mit einer URL ein Verzeichnis spezifiziert, so soll oft eine spezielle Datei dieses Verzeichnisses an den Browser geliefert werden. Der Name dieser Datei ist mit der 8

9 Anweisung DirectoryIndex in srm.conf zu konfigurieren. Name Wert Default Kontext Bemerkung DirectoryIndex Dateiname... index.html SK, <VirtualHost>, <Directory>, <Location>, <files>,.htaccess Beispiel: DirectoryIndex index.html index.htm welcome.html welcome.htm Falls eine solche Datei nicht vorhanden ist, soll oft ein Verzeichnisindex erstellt werden. Dies ist eine Übersicht aller in dem Verzeichnis enthaltenen Dateien und Unterverzeichnisse. Eine solche Funktionalität kann jedoch in vielen Fällen zu ernsthaften Sicherheitsproblemen führen.deshalb empfielt es sich, diese Fujnktionalität ersteinmal global auszuschalten und nur für bestimmte Verzeichnisse freizugeben. Beispiel: <Directory / > Options -Indexes </Directory > <Location /Info > Options +Indexes </Location > Nun wird nur noch für die URL /Info/ und deren Unterverzeichnisse ein solcher Verzeichnisindex erstellt. Mit der Anweisung IndexIgnore lassen sich bestimmte Dateien respektive Dateimuster angeben, die nicht im Verzeichnisindex erscheinen sollen. Beispiel: IndexIgnore *.bak IndexIgnore *.o Virtual Hosts: Wenn man davon redet, daß ein WWW-Server Unterstützung für virtuelle Server (Virtual Hosts) bietet, so meint man damit, daß er gleichzeitig unter mehr als einem Hostnamen agieren kann und dabei jeweils ein eigenes Dokumentenverzeichnis, Logfiles usw. verwalten kann. Bei virtuellen Servern ist zwischen IP-basierten virtuellen Servern und namensbasierten virtuellen Servern (ab HTTP/1.1) zu unterschieden. Angenommen es liegt folgende Konfiguration vor: 9

10 Konfigurationsdatei: httpd.conf ServerType standalone Port 80 User www-data Group www-data ServerRoot /ust/local/etc/httpd PidFile logs/httpd.pid ErrorLog logs/error.log AccessConfig /dev/null ResourceConfig conf/srm... #namensbasierter virtueller Server NameVirtualHost <VirtualHost > ServerName host201.lfh.wi-bw.tfh-wildau.de DocumentRoot /usr/local/etc/httpd/virtualhost201 AccessConfig conf/virtualhost201-access.conf... </VirtualHost> <VirtualHost > ServerName alias201.lfh.wi-bw.tfh-wildau.de DocumentRoot /usr/local/etc/httpd/virtualalias201 AccessConfig conf/virtualalias201-access.conf... </VirtualHost> #IP-basierter virtueller Server <VirtualHost > ServerName host202.lfh.wi-bw.tfh-wildau.de DocumentRoot /usr/local/etc/httpd/virtualhost202 AccessConfig conf/virtualhost202-access.conf... </VirtualHost> #Default Server <VirtualHost _default_:*> ServerName host201.lfh.wi-bw.tfh-wildau.de DocumentRoot /usr/local/etc/httpd/virtualhost201 AccessConfig conf/virtualhost201-access.conf... </VirtualHost> Jeder virtuelle Host erbt die Standardkonfiguration und überschreibt nur seine eigenen Einträge. 10

11 Wird nun ein Request an Host 202 gesendet, so wird der Hostname vom NameServer aufgelöst und an den Host mit der IP-Nr gesendet. An diesem Host wird der Request vom Netzwerk-Interface eth0:0 empfangen. Der Apache prüft an welche IP-Nr der Request gesendet wurde und ob es für diese IP-Nummer einen NameVirtualHost Eintrag gibt. Ist dies der Fall, so handelt es sich um einen namensbasierten virtuellen Server. Der Request wird dann entsprechend des HOST Eintrags im HTTP Header dem virtuellen Host zugeordnet. Gibt es zu der IP Nummer keinen NameVirtualHost Eintrag, so handelt es sich um einen IP-basierten virtuellen Server. Der Request wird dem Default Server zugeordnet, falls eine eindeutige Zuordnung sonst nicht möglich ist. Die namensbasierten virtuellen Server müssen vor den ip-basierten virtuellen Servern erklärt sein. Der Apache Server im Grenznetz Installation einer Minimalversion des Betriebssystems Beheben von bekannten Fehlern mit Patches Mit Checklisten die Sicherheit herstellen Systemprotokolle durch einmalbeschreibbares Medium oder serielle Leitung mit zweitem PC sicherstellen Deaktivieren überflüssiger Dienste aktive Dienste:INIT, SWAP, Page, cron, syslogd, inetd Routing deaktivieren Installation und Anpassen der Dienste (TCP Wrapper/s.135 Internet-Firewalls O'Reilly) Neukonfigurieren und Neuerzeugen des Kernels Entfernen aller überflüssigen Programme und diese evtl. durch Dummies, die Alarm schlagen, ersetzen. Absichern mögl. vieler Dateisystem durch Schreibschutz. z.b. durch setzen des Jumpers (write-disable), mit RAM-Disks oder zweiten HDD für SWAP. Sicheren aller Tools auf Band oder Einrichten einer externen, alternativen Boot-Partition für Wartungsarbeiten. Die Tools müssen nach der Arbeit entfernt und die Platte/Band physisch entfernt werden. Den Host während der Wartungsarbeiten vom Netz nehmen. Oder die HDD des Hosts rausnehmen und diese als zusätzliche Platte eines anderen internen Rechners mounten. Dabei sind dann die Tools nach den Arbeiten garantiert nicht auf der Platte und es entsteht kein Sicherheitsrisiko bei versehentlichem Wiederanschließen des Hosts an das Netz 11

12 Proxy Server im Grenznetz Am Beispiel des sqid Proxy Der grundlegende Zwecks eine Proxies ist es, Web-Browsern von Maschinen, innerhalb einer Firewall, Zugang zu Diensten des Internet zu garantieren. Er wartet auf die Anfragen der Clients, sendet diese weiter an die entsprechenden entfernten (remote) Server außerhalb des Grenznetzes, empfängt die Ergebnisse der Anfragen und sendet diese an die Clients zurück. Konfigurieren des Squid Proxies Zuerst muss natürlich ein Squid (Bei SUSE Linux oder unter installiert werden. Dies geschieht mit dem Befehl: $./configure --prefix=/usr/local/squid $ make all # make install Hierbei wird Squid in das Verzeichnis /usr/local/squid installiert. Dort befindet sich dann auch die squid.conf. Grundkonfiguration des Proxies ICP Protokoll: # TAG: icp_port # icp_port 3130 icp_port 0 Das ICP (Internet Cache Protocol) ist für die Kommunikation mit anderen Proxies und ist definiert im RFC2186 und RFC2187. Wenn eine Kommunikation mit anderen Proxies nicht notwendig ist sollte dieses Protokoll im Einzelbetrieb mittels der Portangabe 0 deaktiviert werden. Cache 12

13 Die Cache ist gedacht um Anfragen zu speichern, die bei erneuter Anfrage einen schnelleren Zugriff ermöglichen. Hier kann man mittels Access Control List, Seiten angeben, die nicht gespeichert werden sollen. Hier ein Beispiel für Adressen die ein cgi-bin beinhalten # TAG: no_cache #We recommend you to use the following two lines. acl QUERY urlpath_regex cgi-bin \? no_cache deny QUERY Die Speichergröße, die der Cache vom Arbeitsspeicher verwendet kann mit folgendem Befehl angegeben werden: # TAG: cache_mem (bytes) # cache_mem 8 MB cache_mem 32 MB Die Angabe wo das Cache-Verzeichnis liegt, wie groß die Cache ist, welche Speichermethode und welche Unterverzeichnisstruktur verwendet wird, kann man festlegen mit: # TAG: cache_dir # cache_dir ufs /usr/local/squid/var/cache cache_dir ufs /var/cache/squid Standard für die Speichermethode ist Unix Filesystem. Die Werte sind der Ressourcen des Servers anzupassen. Logfile-Path: Hier wird der Pfad festgelegt, in dem die Log Dateien abgelegt werden. Dies tut man gewöhnlich im /var Verzeichnis # TAG: cache_access_log # cache_access_log /usr/local/squid/var/logs/access.log cache_access_log /var/log/squid/access.log # TAG: cache_log 13

14 # cache_log /usr/local/squid/var/logs/cache.log cache_log /var/log/squid/cache.log # TAG: cache_store_log # cache_store_log /usr/local/squid/var/logs/store.log cache_store_log /var/log/squid/store.log Access-Log Type: access.log enthält Informationen über Zugriffsrechte. Mit diesem Befehl kann man das Format bestimmen # TAG: emulate_httpd_log on off # emulate_httpd_log off emulate_httpd_log on Prozess-ID-Datei: Im Verzeichnis var sollte auch die Prozess-ID Datei des Squids liegen. Der Sqiud muss das Recht haben diese Datei anzulegen # TAG: pid_filename # pid_filename /usr/local/squid/var/logs/squid.pid pid_filename /var/run/squid.pid Logging der IP-Adresse oder Rechner-Namens In den Logfiles wird standardmäßig nur die Adressen des abfragenden Clients gespeichert. Andere Optionen müssen vorher konfiguriert werden # TAG: log_fqdn on off # log_fqdn off Privacy-Einstellung: 14

15 Hier kann eine Netzwerk-Maske definiert werden, die dafür sorgt, das einzelne Logfile Einträge nicht mehr einem Rechner zuordenbar sind. Die hilft die Privatsphäre der Clients zu schützen. Beim Standardwert wird die volle Adresse angezeigt. # TAG: client_netmask # client_netmask

16 16