Firewalls

1.0 Inhaltsverzeichnis

1.0 Inhaltsverzeichnis

2.0 Einführung

3.0 Hardware-Firewalls

3.1 Einführung

3.2 BIGfire Firewall

3.2a Einführung

3.2b Die Installation

3.2c Die Konfiguration

3.2d Die Log-Files

4.0 Unix-Firewalls

4.1 Einführung

4.2 Die Konfiguration

4.3 Die Log-Files

5.0 Desktop-Firewalls

5.1 Einführung

5.2 Black ICE Defender

5.3 Conseal PC Firewall

5.4 Conseal Private Desktop 2.04

5.5 E-Safe Protect 2.1

5.6 Guard Dog 2.0.5

5.7 Lockdown

5.8 Secure-4-U 4.1

5.9 Secure Desktop 1.1

5.10 Surfin Shield 4.6

5.11 Zone-Alarm

2.0 Einführung

Die Gefahren für einen Computer, die bei der Implementierung in ein Netzwerk durch das öffentliche Erreichen erschlossen werden, wachsen speziell im Falle des Internets exponentiell, mit jedem Eintritt eines neuen Anwenders in das Gefilde des Internets. Denn es gilt, das jeder Benutzer des Internets ein potentieller Gegner ist, der mir bzw. meinem Computer-System etwas anhaben will. Dies können zum einen unerlaubte Zugriffe oder gar das Löschen und Manipulieren auf schützenswerten oder geheimen Daten, sowie das Sabotieren wichtiger EDV-Anlagen sein. Als Hauptaufgabe einer Firewall kann der primäre Schutz vor Hacker-Angriffen in Form der Filterung von Datenpaketen, Überwachung von Anwendungen, Blockade unerwünschter Protokolle, Beschränkung möglicher Verbindungen auf bestimmte IP-Adressen und Ports, Abschirmung von Nodes im Netzwerk und Protokollierung sein. Es gibt verschiedene Arten von Firewalls: Zum einen sind es die High-Tech-Geräte auf Hardware-Basis, wie zum Beispiel die "BIGFire" von Biodata, normale, auf Unix-basierende Systeme, oder Desktop-Firewalls

für Windows-Systeme.

3.0 Hardware-Firewalls

3.1 Einführung

In diesem Abschnitt dreht sich alles um professionelle Geräte, die speziell für den Einsatz als Firewall ausgelegt sind.

Solche werden oft Hardware- oder Standalone-Firewalls genannt. Das entscheidende Pro für solch kostspielige Geräte ist in

einem theoretisch von Fehlern verschonten Betriebssystem zu suchen, welches praktisch keine Fehlkonigurationen zulassen

sollte. Diese sicherheitsrelevanten und administrativen Vorteile schlagen leider im Preise zu Buche, so dass fünfstellige

Beträge für ein ausgereiftes Modell von einer vertrauenswürdigen Firma keine Seltenheit sind.

3.2 BIGfire Firewall

Die wirtschaftlich sehr erfolgreiche Firma "Biodata Information Technology" (http://www.biodata.de/), welche unter anderem

auch das ISDN-Verschlüsselungs-Gerät "Babylon" vertreibt, ist zuständig für die Etablierung der standalone Firewall mit dem

Namen "BIGfire Firewall", welche es auch in der speziellen Plus-Ausführung gibt.

3.2a Einführung

Diese rund 10 kg schwere Hardware-Firewall kommt mit einer hervorragenden und ausgereiften Menüführung daher und lässt sich

daher auch mühelos als simple Firewall mit Paket-Filter oder Application-Gateway einsetzen.

Als Top-Vorteile treten aus dem Schatten die 192-Bit-Hardware-Verschlüsselung mit Triple-DES (Data Encryption Standart),

RADIUS-Athentisierung (Remote Authentication Dial-In User) und SNMP-Unterstützung (Simple Network Management Protocol).

Auf der Vorderseite pranken 8 LEDs um die Gunst des Administrators: Durch jene wird der Traffic, Fehler und Filterungen

für Augenblicke sichtbar gemacht. Direkt neben diesen Leuchtdioden befinden sich zwei Tasten: Mit der oberen kann man

manuell in Notfällen den Datenverkehr zwischen dem internen und dem externen Netz unterbrechen. Mit der anderen

wird ein Reset im Falle eines Fehlers - wie zum Beispiel einem Stromausfall - möglich gemacht. Desweiteren findet

sich auch eine Konfigurationsbuchse mit der die Einstellungen mittels Terminal oder PC (zum Beispiel "Telix")

vorgenommen werden können. Das spezielle Konfigurationskabel gehört natürlich zum Lieferumfang. Die Rückwand warten zwei

Buchsen für den Anschluss eines externen Interfaces und eines internen Interfaces auf, welche den Zusammenschluss

autosense 10 MBit/100 Mbit über Twited Pair ermöglichen. An der Buchse für das externe Interface ist auch die Möglichkeit

des Anschlusses des Administrationsinterfaces möglich. Eine gelbe LED kennzeichnet den Betrieb mit 100 MBit,

wobei die grüne LED einen aktiven Link symbolisiert. Eine weitere Anschlussmöglichkeit besteht für einen optionalen

externen Signalgeber. Die Spannungsversorgung erfolgt international zwischen 115 und 230 Volt. zugleich ist noch eine

weitere Buchse für eine optionale Spannungsversorgung durch eine andere Firewall enthalten.

3.2b Die Installation

Die Installation gestaltet sich nicht sonderlich aufwendiger als die Implementation eines Unix-Rechners mit zwei

lauffähigen Netzwerkkarten in ein heterogenes Netzwerk. Zuerst muss den beiden Netzwerkinterfaces eine gültige

IP-Adresse zugeteilt werden. Auch das Admin-Interface bekommt seine eigene IP-Adresse, damit bestimmte Pakete

unter gewissen Umständen ein rerouting über jenes machen (müssen). Dieser ganze Vorgang findet mittels Einwahl

mit einem Terminal statt, wobei die verschiedenen Einstellungen rein auf einer Kommandozeile vorgenommen werden müssen.

Das Dicke Handbuch leistet sehr gute Dienste, wenn es um die kryptischen Eingaben zur Grundkonfiguration geht.

3.2c Die Konfiguration

Die Konfiguration kann wahlweise mit der Einwahl mittels Terminal auf Kommandozeilen-Ebene oder mit einer grafischen

Oberfläche unter Windows vorgenommen werden. Das GUI ist sehr gut aufbereitet, und lässt dem ausführenden Administrator

freie Hand, wenn es um die bestimmten Filterregeln geht. Leider wird im Handbuch nicht explizit auf mögliche Filterungen

hingewiesen, die zur heutigen Zeit am besten angewendet werden sollen. Trotzdem oder gerade aus diesem Grund ist wohl die

Konfiguration und Wartung einer solch ausgeklügelten Hardware-Firewall das grösste Problem des Sicherheitsaspektes:

Oft weiss man einfach nicht genau, welche Filterregeln sinnvoll sind, und welche den Netzwerkverkehr oder wichtige

Dienste blocken würden.

3.2d Die Log-Files

Die Log-Files bieten alles, was es durch Analyse braucht. Sie können sogar an einen Host weitergeleitet werden, welcher einem die Suche nach möglichen Fehler-Quellen erleichtert.

4.0 Unix-Firewalls

4.1 Einführung

Jedes Unix-Betriebssystem bietet softwaremässig Konfigurationsmöglichkeiten für den Betrieb als Firewall-Element. Am besten eignet sich der Einsatz einer solchen als Gateway in einem Netzwerk, wobei das Nutzen von zwei Netzwerkkarten Pflicht ist. Die Kosteneinsparnis, die beim Nutzen bzw. der Implementierung einer Unix-Firewall in ein Netzwerk gewonnen werden kann, rechtfertigt leider nicht den erhöhten Aufwand, der bei der Installation, Konfiguration und Wartung an den Administrator gestellt werden. Da eine falsche Konfiguration mitunter der grösste Schwachpunkt einer Firewall ist, müssen bei Unix-Firewalls die diversen Sicherheitslöcher im Betriebssystem selber als grösstes Manko angesehen werden. Erreicht nun zum Beispiel ein Eindringling auf einer solchen Firewall eine Shell mit Root-Rechten dank Sendmail, ist es um das gesamte Netz geschehen. Damit dies nicht einfach ausgenutzt werden können, sollte jeder Dienst, der nicht unbedingt notwendig ist, auf der Unix-Firewall deaktiviert oder gar nicht installiert werden. Normalerweise mussen nur bestimmte Ports durch die Firewall hindurchgelassen werden. Ist dies nun zum Beispiel Port 80 (HTTP) und 21 (FTP), so empfielt sich die Installation eines Proxy-Servers, da dadruch auf IP-Masquerading verzichtet werden kann. Die Gefahr bei IP-Masquerading besteht darin,

dass grundsätzlich alle Ports weitergeleitet werden. Oft kommt man jedoch um IP-Masquerading nicht herum, doch dann sollte man sich unbedingt tiefer mit der Materie der Filter-Regeln befassen und ab und an ein Auge auf die Log-Files seiner Firewall werfen.

4.2 Die Konfiguration

Nach der Installation aller Firewall-Pakete muss logischerweise die Konfiguration dieses Dienstes vorgenommen und die Filter-Regeln definiert werden. Bei der Linux-Distribution von SuSE (http://www.suse.de/) wurde bis zur Version 6.2 der Firewall-Dienst in der Datei /etc/rc.config konfiguriert. Ab der Version 6.3 wurde ein separates Konfigurations-File namens

/etc/rc.firewall angelegt. Im folgenden nun eine mögliche, als ziemlich sicher anzusehende Konfiguration auf einem meiner

Rechner, der als Gateway und Proxy-Server mit WWWOffle unter SuSE Linux 6.3 läuft:

# Copyright (c) 1999 SuSE GmbH Nuernberg, Germany. All rights reserved.

#

# Author: Marc Heuse <marc@suse.de>, 1999

#

# /etc/rc.firewall

#

# for use with /usr/sbin/SuSEfirewall version 1.2

#

# ------------------------------------------------------------------------

#

# PLEASE NOTE THE FOLLOWING:

#

# Just by configuring these settings and using the SuSEfirewall you are

# not secure per se! There is *not* such a thing you install and hence you

# are safed from all (security) hazards.

#

# To ensure your security, you must also:

#

# * Secure all services you are offering to untrusted networks (internet)

# You can do this by using software which has been designed with

# security in mind (like postfix, apop3d, ssh), setting these up without

# misconfiguration and praying, that they have got really no holes.

# /usr/bin/chroot and privilege drop can help in most circumstances to

# reduce the risk.

# * Do not run untrusted software. (philosophical question, can you trust

# SuSE or any other software distributor?)

# * Harden your server(s) with the harden_suse package/script

# * Recompile your kernel with the openwall-linux kernel patch

# (former secure-linux patch, from Solar Designer)

# * Check the security of your server(s) regulary

# * If you are using this server as a firewall/bastion host to the internet

# for an internal network, try to run proxy services for everything and

# disable routing on this machine.

#

# Good luck!

#

# Yours,

# SuSE Security Team

#

# ------------------------------------------------------------------------

#

# Configuration HELP:

#

# All types have to set option 1): START_FW to "yes" ;-)

#

# If you are a end-user who is NOT connected to two networks you just have to

# reconfigure (all other settings are OK): 2), and maybe 10), 11), 13) and 15).

#

# If this server is a firewall, which should act like a proxy (no direct

# routing between both networks), or you are end end-user connected to the

# internet and to a internal network, you have to setup your proxys and

# reconfigure (all other settings are OK): 2), 3) and maybe 9), 10), 11),

# 12), 13) and 15).

#

# If this server is a firewall, and should do routing/masquerading between

# the untrusted and the trusted network, you have to reconfigure (all other

# settings are OK): 2), 3), 4), 6), and maybe 5), 9), 10), 11), 12), 13),

# 14) and 15).

#

# If you know what you are doing, you may also change 7), 8), 16), 17) and

# the expert options 18), 19) at the far end, but you should NOT.

#

# To get programs like traceroutes to your firewall to work is a bit tricky,

# you have to set the following options to "yes" : 13 (UDP only), 17 and 18.

#

# ------------------------------------------------------------------------

#

# 1.)

# Should the Firewall be started?

# This setting is done in /etc/rc.config

#

# 2.)

# Which is the interface that points to the internet?

# Enter all the network devices here which are untrusted.

#

# Choice: any number of devices, seperated by a space

# e.g. "eth0", "ippp0 ippp1"

#

FW_DEV_WORLD="eth0"

#

# 3.)

# Which is the interface that points to the internal network?

# Enter all the network devices here which are trusted.

# If you are not connected to a trusted network (e.g. you have just a

# dialup) leave this empty.

#

# Choice: leave empty or any number of devices, seperated by a space

# e.g. "tr0", "eth0 eth1" or ""

#

FW_DEV_INT="eth1"

#

# 4.)

# Should routing between the internet and the internal network be activated?

# REQUIRES: FW_DEV_INT

# You need only set this to yes, if you either want to masquerade internal

# machines or you want to allow access to internal machines (not a good

idea).

#

# Choice: "yes" or "no", defaults to "no"

#

FW_ROUTE="no"

#

# 5.)

# Do you want to masquerade internal networks to the outside?

# REQUIRES: FW_DEV_INT, FW_ROUTE

# "Masquerading" means that all your internal machines which use services

on

# the internet seem to come from your firewall.

# Please note that it is more secure to communicate via proxies to the

# internet than masquerading

#

# Choice: "yes" or "no", defaults to "no"

#

FW_MASQUERADE="no"

#

# 6.)

# Which internal computers/networks are allowed to access the internet?

# REQUIRES: FW_DEV_INT, FW_ROUTE, FW_MASQUERADE

#

# Choice: leave empty or any number of computers and/or networks,

seperated by

# a space, if you want to allow the whole internal network, set this to "0/0"

# e.g. "10.0.0.0/8", "10.0.0.1 10.0.0.10 10.10.10.0/24", "0/0" or ""

#

FW_LOCALNETS="192.168.0.0/24"

#

# 7.)

# Do you want to enable additional kernel TCP/IP security features?

# If set to yes, some obscure kernel options are set.

# (icmp_ignore_bogus_error_responses, icmp_echoreply_rate,

# icmp_destunreach_rate, icmp_paramprob_rate, icmp_timeexeed_rate,

# ip_local_port_range, log_martians, mc_forwarding, mc_forwarding,

# rp_filter)

# Tip: Set this to "no" until you have verified that you have got a

# configuration which works for you. Then set this to "yes" and keep it

# if everything still works. (It should!) ;-)

#

# Choice: "yes" or "no", defaults to "yes"

#

FW_KERNEL_SECURITY="yes"

#

# 8.)

# Do you want to autoprotect all global running services?

# If set to "yes", all network access to services TCP and UDP on this

machine

# which are not bound to a special IP address will be prevented (except to

# those which you explicitly allow, see below: FW_*_SERVICES_*)

# Example: "0.0.0.0:23" would be protected, but "10.0.0.1:53" not.

#

# Choice: "yes" or "no", defaults to "yes"

#

FW_AUTOPROTECT_GLOBAL_SERVICES="yes"

#

# 9.)

# Do you want to protect the firewall from the internal network?

# REQUIRES: FW_DEV_INT

# If you set this to "yes", internal machines may only access services on

# the machine you explicitly allow. They will be also affected from the

# FW_AUTOPROTECT_GLOBAL_SERVICES option.

#

# Choice: "yes" or "no", defaults to "yes"

#

FW_PROTECT_FROM_INTERNAL="yes"

#

# 10.)

# Which services should be accessible from the internet (untrusted network)?

# Enter all ports or known portnames below, seperated by a space.

# TCP services (e.g. SMTP, WWW) must be set in

FW_TCP_SERVICES_EXTERNAL, and

# UDP services (e.g. syslog) must be set in

FW_UDP_SERVICES_EXTERNAL.

#

# Choice: leave empty or any number of ports, known portnames and port

ranges

# seperated by a space. Port ranges are written like this, from 1 to 10: "1:10"

# e.g. "", "smtp", "123 514", "3200:3299", "ftp 22 telnet 512:514"

#

FW_TCP_SERVICES_EXTERNAL="ftp www" # Common: smtp www domain

FW_UDP_SERVICES_EXTERNAL="" # Common: domain

#

# 11.)

# Which services should be accessible from trusted hosts on the internet?

# Define trusted networks on the internet, and the TCP and/or UDP services

# they are allowed to use.

#

# Choice: leave FW_TRUSTED_HOSTS empty or any number of computers and/or

# networks, seperated by a space. e.g. "172.20.1.1", "172.20.0.0/16"

# leave FW_*_SERVICES_TRUSTED empty or any number of ports, known portnames

# and port ranges seperated by a space. e.g. "25", "ssh", "1:65535", "1 3:5"

#

FW_TRUSTED_HOSTS="207.154.76.253"

FW_TCP_SERVICES_TRUSTED="ssh" # Common: ssh

FW_UDP_SERVICES_TRUSTED="" # Common: syslog time ntp

#

# 12.)

# Which services should be accessible from the internal network?

# REQUIRES: FW_DEV_INT, FW_PROTECT_FROM_INTERNAL

# Enter all ports or known portnames below, seperated by a space.

# TCP services (e.g. SMTP, WWW) must be set in

FW_TCP_SERVICES_EXTERNAL, and

# UDP services (e.g. syslog) must be set in

FW_UDP_SERVICES_EXTERNAL.

#

# Choice: leave empty or any number of ports, known portnames and port ranges

# seperated by a space. Port ranges are written like this, from 1 to 10: "1:10"

# e.g. "", "smtp", "123 514", "3200:3299", "ftp 22 telnet 512:514"

#

FW_TCP_SERVICES_INTERNAL="ftp telnet smtp www 139" # Common: ssh smtp domain www

FW_UDP_SERVICES_INTERNAL="" # Common: domain

#

# 13.)

# How is access allowed to high (unpriviliged [above 1023]) ports?

# You may either allow everyone from anyport access to your highports ("yes"),

# disallow anyone ("no"), anyone who comes from a defined port (portnumber or

# known portname) [note that this is easy to circumvent!], or just your

# defined nameservers ("dns").

# Note that if you want to use normal (active) ftp, you have to set the TCP

# option to ftp-data. If you use passive ftp, you don't need that.

# Note that you can't use rpc requests (e.g. rpcinfo, showmount) as root

# from a firewall using this script.

#

# Choice: "yes", "no", "dns", portnumber or known portname, defaults to "no"

#

FW_TCP_ALLOW_INCOMING_HIGHPORTS="no" # Common: "ftp-data" (sadly!)

FW_UDP_ALLOW_INCOMING_HIGHPORTS="no" # Common: "dns"

#

# 14.)

# Which services accessed from the internet should be allowed to the

# internal network?

# REQUIRES: FW_ROUTE

# With this option you may allow access to e.g. your mailserver. The

# internal machines must have valid, non-private, IP addresses which were

# assigned to you by your ISP. This opens a direct link to your network!!!!

#

# Choice: leave empty (good choice!) or use the following explained syntax

# of forwarding rules, seperated each by a space.

# A forwarding rule consists of 1) source IP/net, 2) destination IP and

# 3) destination port, seperated by a comma (","), e.g. "4.0.0.0/8,1.1.1.1,22"

# "4.4.4.4/12,10.10.10.10,22 12.12.12.12/12,10.10.10.10,22"

#

FW_FORWARD_TCP="" # Beware to use this!

FW_FORWARD_UDP="" # Beware to use this!

#

# 15.)

# Which accesses to services should be redirected to a localport on the

# firewall machine?

# This can be used to force all in