  Firewalling und Proxy Server
  Jrgen Steiner (js@barbar.augusta.de)
  v0.1, 18. Mrz 1997

  Dieses Dokument wurde entwickelt, um die Grundlagen von Firewall-
  Systemen zu vermitteln und bietet einige Details zur Konfiguration von
  Filter- und Proxy-Firewalls auf einem PC-System, basierend auf Linux.

  1.  Einfhrung

  Das original FIREWALL-HOWTO wurde von David Rudder geschrieben und von
  Mark Grennan erweitert. Diese erweiterte Version wurde von mir ins
  Deutsche bersetzt.

  Firewall-Systeme haben einen groen Erfolg als das Ultimative in
  Internet-Sicherheit gewonnen. Wie die meisten Dinge die Erfolg haben,
  ist mit dem Erfolg auch ein falsches Verstndnis gekommen. Dieses
  Dokument wird die Grundlagen vermitteln, was Firewall und Proxy-Server
  sind und wie sie konfiguriert werden. Es werden auch Anwendungen
  auerhalb des Sicherheitsbereiches vorgestellt.

  1.1.  Feedback

  Ich bitte mir jede Ungenauigkeit in diesem HOWTO zu berichten.
  Jeglicher Feedback ist willkommen.

  meine eMail-Adresse ist: js@barbar.augusta.de

  1.2.  Disclaimer

  Ich bin nicht verantwortlich fr Folgen die durch die Anwendung dieses
  HOWTOs enstehen.

  Dieses Dokument ist als eine Einfhrung in die Funktion von Firewall
  und Proxy-Servern gedacht. Ich bin kein Experte fr Sicherheitsfragen
  und mchte hier auch keine ultimative Anleitung fr den Betrieb von
  Firewall und Proxy-Servern bieten.

  1.3.  Copyright

  Dieses Dokument ist urheberrechtlich geschtzt. Das Copyright fr die
  englische Firewall HOWTO, auf der dieses Dokument basiert, liegt bei
  Mark Grennan. Das Copyright fr die deutsche Version liegt bei Jrgen
  Steiner.

  Das Dokument darf gem der GNU General Public License verbreitet
  werden. Insbesondere bedeutet dieses, da der Text sowohl ber
  elektronische wie auch physikalische Medien ohne die Zahlung von
  Lizenzgebhren verbreitet werden darf, solange dieser Copyright
  Hinweis nicht entfernt wird. Eine kommerzielle Verbreitung ist erlaubt
  und ausdrcklich erwnscht. Bei einer Publikation in Papierform ist
  das Deutsche Linux HOWTO Projekt hierber zu zu informieren.

  1.4.  Die Grnde fr die Entstehung dieses HOWTO's

  Es gab eine Menge Diskussionen auf comp.os.linux.* in letzter Zeit
  ber Firewalls. Und Informationen darber einen Firewall zu
  administrieren, waren sehr drftig. Dieses HowTo soll den
  Wissenshungrigen zielgerecht an das Thema heranfhren.

  2.  Allgemeine Einfhrung

  2.1.  Vorbereitende Lektre als Empfehlung

    Das NET-2 HOWTO

    Das Ethernet HOWTO

    Das Mehrere Ethernetkarten mini HOWTO

    Networking with Linux

    Das PPP HOWTO

    TCP/IP Network Administrator's Guide by O'Reilly and Associates

    Die Dokumentation zum TIS Firewall Toolkit

  Die Trusted Information System's (TIS) Website hat eine groe Sammlung
  an Informationen, Dokumentationen und Programmen um ein sicheres
  Linux-System aufzubauen: http://www.tis.com/

  3.  Beschreibung des Firewalls

  Ein Firewall in Computern ist eine logische Vorrichtung, die ein
  privates Netz vor dem ffentlichen Teil (Internet) schtzt.

  Funktionsprinzip:

  Ein Computer mit installierter Routing-Software und 2 Schnittstellen
  (z.B. serielle Schnittstellen, Ethernet, Token Ring, usw.). Das
  Internet ist mit einer Schnittstelle verbunden, das zu schtzende
  private Netz mit der anderen Schnittstelle. Jetzt, haben Sie zwei
  verschiedene Netze, die sich einen Computer teilen.

  Der Firewall-Computer, von jetzt an "Firewall" genannt, kann beide
  Seiten erreichen, das geschtzte private Netz und das Internet.
  Niemand aus dem geschtzten Netz kann das Internet erreichen, und aus
  dem Internet kann niemand in das geschtzte Netz.

  Damit jemand das Internet vom geschtzten Netz aus erreichen kann, mu
  er eine Telnet-Verbindung zum Firewall aufbauen und das Internet von
  dort aus benutzen.  Entsprechend, um eine Verbindung vom Internet aus
  in das geschtzte Netz zu bekommen, mu man auch durch den Firewall
  gehen.

  Dieses stellt eine ausgezeichnete Sicherheit gegen Angriffe aus dem
  Internet dar. Falls jemand einen Angriff gegen das geschtzte Netz
  machen will, mu er zuerst durch den Firewall gehen. Ein 2-stufiger
  Zugang zum gesicherten Netz ist resistent gegen Angriffe. Falls
  jemand das geschtzte Netz ber eine gemeinere Methode angreifen will,
  wie z.B. Mail-Bombe oder den berchtigten "Internet Wurm", werden sie
  nicht in der Lage sein das geschtzte Netz zu erreichen. Dies ist ein
  ausgezeichneter Schutz.

  4.  Nachteile eines Firewall

  Das grte Problem eines Firewalls ist, da er den Zugang zum Internet
  von der Innenseite kommend stark hemmt.  Grundstzlich reduziert er
  den Gebrauch des Internets dahingehend, als ob man nur einen "Dialup
  Shell Zugang" haben wrde.  Sich in den Firewall einloggen zu mssen
  um vollen Internet-Zugang zu haben ist eine starke Beeinschrnkung.

  Programme wie Netscape, die eine direkte Internet-Verbindung
  bentigen, werden hinter einem Firewall nicht arbeiten.  Die Antwort
  zu diesem Problem hat ein Proxy-Server. Proxy-Server erlauben ein
  direktes Erreichen des Internets hinter einem Firewall.

  Um die Mglichkeit, von einem Computer im geschtzten Netz mit
  Netscape im Web zu lesen, anbieten zu knnen, setzt man einen Proxy-
  Server auf den Firewall auf. Der Proxy-Server wrde so konfiguriert
  werden, da ein Computer vom eigentlichen Port 80 des Firewalls zum
  Port 1080 des Proxy verbunden wird, um alle Verbindungen zu den
  richtigen Adressen umzuleiten.

  Der groe Vorteil von Proxy-Servern ist die absolute Sicherheit, wenn
  sie korrekt konfiguriert sind. Sie werden niemanden erlauben sie zu
  umgehen.  Der Proxy-Server ist vor allem eine Sicherheitsvorrichtung.
  Seine Benutzung fr einen Internet-Zugang mit begrenzten IP-Adressen
  wird viele Nachteile haben.

  Ein Proxy-Server bietet Zugang von innerhalb des geschtztes Netzes
  zur Auenseite, aber die Innenseite wird vllig unerreichbar fr die
  Auenseite bleiben. Dieses bedeutet keine Server-, Talk- oder Archie-
  Verbindungen, oder direkte Emails zu den Computern im geschtzten
  Netz.  Diese Nachteile knnen gering erscheinen, aber bedenken sie:
  Es liegt ein Dokument auf Ihrem Computer innerhalb eines per Firewall
  geschtztem Netzes.

  FTP verursacht ein anderes Problem mit einem Proxy-Server. Beim
  Absenden des "ls"-Befehls , ffnet der FTP-Server einen Port auf der
  Kundenmaschine und bermittelt die Information. Ein Proxy-Server wird
  das nicht erlauben, somit arbeitet FTP nicht zuverlssig.  Proxy-
  Server arbeiten langsam.  Wegen dem greren Protokollaufwandes werden
  fast alle anderen Mittel, um einen Internet-Zuganges zu bekommen,
  schneller sein.

  Grundstzlich, falls Sie ausreichend IP Adressen haben und ihnen macht
  die Sicherheit keine Sorgen, wird kein Firewall und/oder Proxy-Server
  benutzt.  Falls Sie zu wenig IP Adressen haben und ihnen macht die
  Sicherheit keine Sorgen, wird man eher einen IP-Emulator benutzen wie
  Term, Slirp oder TIA.  Diese Pakete arbeiten schneller, erlauben
  bessere Verbindungen, und stellen ein hochwertigen Zugang vom Internet
  zum geschtzten Netz bereit.

  Proxy-Server sind gut fr jene Netzwerke mit vielen Hosts, welche
  einen transparenten Internetzugang wollen. Sie bentigen nur eine
  kleine Konfiguration und wenig Verwaltungsarbeit im laufenden Betrieb.

  5.  Funktion und Prinzip eines Firewalls

  5.1.  Firewall Varianten

  Es gibt zwei Arten von Firewalls.

  1. IP oder Filter Firewalls - die alles sperren bis auf ausgewhlten
     Netzwerkverkehr

  2. Proxy-Server - die einem die Netzwerkverbindung bernehmen

  5.1.1.  IP Filter Firewalls

  Ein IP Filter Firewall arbeitet auf Paket-Ebene, er ist so
  konstruiert, da er den Datenstrom kontrolliert auf Grund von
  Ursprung, Ziel, Port und Paket-Typ-Information die in jedem Daten-
  Paket enthalten sind.

  Diese Art des Firewalls ist sehr sicher, aber es mangelt an einer
  brauchbaren Protokollierung. Er verbietet den Zugang zum privaten
  Netzwerk aber es wird nicht protokolliert wer auf das private Netzwerk
  zugreifen will oder wer vom privaten Netz Zugriff ins Internet haben
  will.

  Filter Firewalls sind absolute Filter. Gibt man einem von auen den
  Zugriff auf das private Netz hat automatisch jeder Zugriff darauf.

  In Linux ist packet-filtering-software seit Kernel 1.2.13 enthalten

  5.1.2.  Proxy Server

  Proxy Server erlauben indirekten Zugang zum Internet durch den
  Firewall.  Als Beispiel zur Funktion startet man einen Telnet zu einem
  System um von dort aus einen Telnet zu einem anderen zu starten. Nur
  mit einem Proxy-Server kann man diesen Vorgang automatisieren. Wenn
  man mit einer Client-Software einen connect zum Proxy-Server macht,
  startet der automatisch seine Client(Proxy)-Software und reicht die
  Daten durch.

  Weil Proxy-Server ihre Kommunikation duplizieren, knnen sie alles
  mitprotokollieren was sie tun.

  Der groe Vorteil von Proxy-Server ist, sofern sie korrekt
  konfiguriert sind, da sie absolut sicher sind. Sie erlauben keinem
  ein Durchkommen.  Sie haben keine direkten IP-Routen.

  6.  Firewall Konfiguration

  6.1.  Bentigte Hardware

  In diesem Beispiel ist der Computer ein 486-DX66 mit 16 MB RAM und
  einer 500 MB Linux Partition. Dieses System hat zwei Netzwerkkarten.
  Eine ist an das private LAN angeschlossen. Die Andere ist an ein LAN
  angeschlossen, das wir die "Demilitarisierte Zone" (DMZ) nennen
  wollen. An die DMZ ist ein Router angeschlossen mit Verbindung zum
  Internet.

  Das ist eine bliche Standardkonfiguration fr ein Bro. Man kann auch
  nur eine Netzwerkkarte und dafr ein Modem mit PPP nehmen. Hauptsache
  der Firewall hat zwei IP-Netzwerk-Adressen.

  Es gibt ein paar Leute mit kleinen LANs zuhause mit zwei oder drei
  Computern.  Manche knnten in Erwgung ziehen alle Modems an eine
  Linux-Box (vielleicht ein verstaubter 386er) zu stecken um sie ans
  Internet anzubinden, vielleicht sogar mit Load-Balancing. Der
  Datendurchsatz von nur einer Person wrde sich mit dieser
  Konfiguration glatt verdoppeln.

  7.  Firewall Software

  7.1.  Verfgbare Pakete

  Wenn man nur einen Filter Firewall will, reicht Linux mit dem
  Standard-Netzwerk-Paket. Das "IP Firewall Administration Tool" kann
  mglicherweise nicht bei allen Linux-Distributionen dabei sein.

  IPFWADM ist zu holen bei: http://www.xos.nl/linux/ipfwadm/

  Um einen Proxy-Server zu installieren bentigt man eines der beiden
  Packages:

  1. SOCKS

  2. TIS Firewall Toolkit (FWTK)

  7.2.  Der TIS Firewall Toolkit vs. SOCKS

  Trusted Information System (http://www.tis.com) verffentlichte eine
  Kollektion von Programmen, die einem das "Firewalling" erleichtern.
  Die Programme haben grundstzlich die selbe Funktion wie das "SOCKS"
  Paket, haben aber eine unterschiedliche Strategie im Programmaufbau.
  SOCKS bedient mit nur einem Programm alle Internet-Transportaufgaben,
  wobei TIS fr jedes Utility, welches den Firewall bentzen mchte, ein
  eigenes Programm anbietet.

  Um die beiden zu vergleichen, nehmen wir als Beispiel eine WWW- und
  eine Telnet-Verbindung. Mit SOCKS mu man nur eine Konfigurationsdatei
  anpassen und hat nur einen Dmon. Durch diese Datei und dem Dmon hat
  man die Mglichkeit fr WWW und Telnet geschaffen, ebenso fr alle
  anderen Dienste die nicht gesperrt sind.

  Mit dem TIS-Toolkit startet man fr WWW und Telnet jeweils einen
  eigenen Dmon mit seiner eigenen Konfigurationsdatei. Jeder weitere
  Internetdienst ist solange nicht mglich bis er explizit freigegeben
  wird. Wird ein Dmon fr einen bestimmten Dienst nicht angeboten (z.B.
  TALK) gibt es einen "plug-in"  daemon, er ist aber dann weder
  flexibel, noch einfach zu konfigurieren wie die anderen Utilities.

  Das klingt vielleicht einfach, macht aber einen groen Unterschied.
  SOCKS erlaubt einem nachlssiger zu sein. Mit einem nachlssig
  installiertem SOCKS-Server kann ein Anwender aus dem LAN mehr Zugriff
  zum Internet erreichen als eigentlich beabsichtigt. Mit dem TIS-
  Toolkit haben die Anwender im LAN nur den Zugriff, den der System-
  Administrator erlaubt.

  SOCKS ist einfacher zu konfigurieren, einfacher zu kompilieren und
  erlaubt grere Flexibilitt. Das TIS-Toolkit ist weitaus sicherer
  wenn man die Anwender im geschtzten LAN regulieren will. Beide bieten
  absoluten Schutz vor der Auenwelt.

  Eine Mglichkeit der Installation und Konfiguration beider Systeme
  wird in diesem HOWTO beschrieben.

  8.  Vorbereitung des Linux Systems

  8.1.  Kompilieren des Kernels

  Beste Voraussetzung ist eine saubere Linuxinstallation.(Die Beispiele
  hier sind auf einer RedHat 3.0.3 Distibution entstanden). Je weniger
  Software man installiert hat, desto weniger Schlupflcher,
  Hintertrchen und/oder Fehler bilden die Grundlage fr
  Sicherheitsprobleme in Ihrem System.  Idealerweise installiert man nur
  die unbedingt ntigte Software.

  Als Kernel verwendet man einen bekannt Stabilen, wie z.B 2.0.14 (auf
  den sich die folgende Konfiguration absttzt).

  1. Under General setup

     a. Turn Networking Support ON

  2. Under Networking Options

     a. Turn Network firewalls ON

     b. Turn TCP/IP Networking ON

     c. Turn IP forwarding/gatewaying OFF (UNLESS you wish to use IP
        filtering)

     d. Turn IP Firewalling ON

     e. Turn IP firewall packet loggin ON (this is not required but it
        is a good idea)

     f. Turn IP: masquerading OFF (I am not covering this subject here.)

     g. Turn IP: accounting ON

     h. Turn IP: tunneling OFF

     i. Turn IP: aliasing OFF

     j. Turn IP: PC/TCP compatibility mode OFF

     k. Turn IP: Reverse ARP OFF

     l. Turn Drop source routed frames ON

  3. Under Network device support

     a. Turn Network device support ON

     b. Turn Dummy net driver support ON

     c. Turn Ethernet (10 or 100Mbit) ON

     d. Select your network card

  Nun kann man den Kernel neu kompilieren und installieren und Linux neu
  starten.  Die Netzwerkkarte sollte in den Boot-Meldungen erscheinen.
  Wenn nicht, nochmal einen Blick in die entsprechende HOWTOs werfen.

  8.2.  Konfiguration von zwei Netzwerkkarten

  Sind zwei Netzwerkkarten im Computer, kann man einen Zusatzeintrag in
  /etc/lilo.conf machen, der die IO-Adressen und die IRQ's der beiden
  Karten bekannt gibt.

  z.B.

      append="ether=12,0x300,eth0 ether=15,0x340,eth1"

  8.3.  Konfiguration der Netzwerkadressen

  Dies ist der interessante Teil, weil es ein paar Entscheidungen zu
  machen gilt.  Nachdem erwnscht ist, da aus dem Internet kein Zugriff
  auf irgendeinen Teil des LAN stattfindet, braucht man auch keine
  offiziellen Adressen fr das LAN . Es gibt ein paar Adressen nur fr
  den Gebrauch in privaten Netzwerken. Weil immer mehr Adressen
  gebraucht werden und diese private Adressen nicht geroutet werden,
  sind sie eine gute Wahl.

  Einer dieser Adressbereiche ist 192.168.2.x , der auch hier in diesem
  Beispiel bentzt wird.

  Der Beispiel-Proxy-Server hier ist ein Bestandteil in beiden
  Netzwerken und kann somit Daten von und ins private Netzwerk
  bergeben.

              199.1.2.10   __________    192.168.2.1
        _  __  _        \ |          | /           _______________
       | \/  \/ |        \| Firewall |/           |               |
      / Internet \--------|  System  |------------| Workstation/s |
      \_/\_/\_/\_/        |__________|            |_______________|

  Will man einen "Filter Firewall" bentzen, kann man diese Adressen
  beibehalten.  Man mu allerdings IP-Masquerading bentzen um dies zu
  ermglichen. Mit diesem Zusatz wird der Firewall die Pakete weiter
  transportieren und dabei in "Offizielle " "IP-Adressen umsetzen um sie
  ins Internet zu schicken.

  Die Netzwerkkarte zum Internet mu die offizielle IP-Adresse bekommen
  und die Karte zum LAN bekommt die 192.168.2.1 zugewiesen. Das wird die
  Proxy/Gateway-Adresse. Alle anderen Systeme im geschtzten LAN knnen
  Adressen aus dem Bereich 192.168.2.xxx bekommen (192.168.2.2 bis
  192.168.2.254).

  Bei RedHat kann man, um das Netzwerk beim starten von Linux zu
  konfigurieren, eine Datei in /etc/sysconfig/network-scripts
  hinzufgen.  Diese Datei wird beim starten gelesen und konfiguriert
  das Netzwerk und die Routing-Tabelle.

  Ein Beispiel fr ifcfg-eth1:

      #!/bin/sh
      #>>>Device type: ethernet
      #>>>Variable declarations:
      DEVICE=eth1
      IPADDR=192.168.2.1
      NETMASK=255.255.255.0
      NETWORK=192.168.2.0
      BROADCAST=192.168.2.255
      GATEWAY=199.1.2.10
      ONBOOT=yes
      #>>>End variable declarations

  Man kann auch das Script dazu verwenden um per Modem automatisch eine
  Verbindung zum Provider aufzubauen. Als Beispiel kann das ipup-ppp
  Skript dienen.

  Bei Benutzung eines Modems fr die Internetverbindung kann die IP-
  Adresse zum Internet vom Provider dynamisch beim Connect bermittelt
  werden.

  8.4.  Testen des Netzwerkes

  begonnen wird mit der Kontrolle von "ifconfig" und "route". Bei zwei
  Netzwerkkarten kann ifconfig so aussehen:

    #ifconfig
    lo        Link encap:Local Loopback
              inet addr:127.0.0.0  Bcast:127.255.255.255  Mask:255.0.0.0
              UP BROADCAST LOOPBACK RUNNING  MTU:3584  Metric:1
              RX packets:1620 errors:0 dropped:0 overruns:0
              TX packets:1620 errors:0 dropped:0 overruns:0

    eth0      Link encap:10Mbps Ethernet  HWaddr 00:00:09:85:AC:55
              inet addr:199.1.2.10 Bcast:199.1.2.255  Mask:255.255.255.0
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:0 errors:0 dropped:0 overruns:0
              TX packets:0 errors:0 dropped:0 overruns:0
              Interrupt:12 Base address:0x310

    eth1      Link encap:10Mbps Ethernet  HWaddr 00:00:09:80:1E:D7
              inet addr:192.168.2.1  Bcast:192.168.2.255  Mask:255.255.255.0
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:0 errors:0 dropped:0 overruns:0
              TX packets:0 errors:0 dropped:0 overruns:0
              Interrupt:15 Base address:0x350

  Und die Tabelle von route:

    #route -n
    Kernel routing table
    Destination     Gateway         Genmask         Flags MSS    Window Use Iface
    199.1.2.0       *               255.255.255.0   U     1500   0       15 eth0
    192.168.2.0     *               255.255.255.0   U     1500   0        0 eth1
    127.0.0.0       *               255.0.0.0       U     3584   0        2 lo
    default         199.1.2.10      *               UG    1500   0       72 eth0

  Zur Erinnerung: 199.1.2.0 ist die Internetseite des Firewalls und
  192.168.2.0 ist die private Seite.

  Nun kann versucht werden vom Firewall einen ping zum Internet zu
  starten.  Ein guter Testpunkt wre ns.nic.de. Es ist eigentlich ein
  guter Test, hat sich aber als nicht sehr zuverlssig herausgestellt.
  Falls der ping nicht funktioniert, einfach mal eine Adresse des
  Providers versuchen. Falls auch das nicht funktioniert, dann ist die
  IP-Verbindung nicht richtig konfiguriert und mu mit Hilfe des NET-2
  HOWTOs berichtigt werden.

  Als nchstes versucht man einen ping vom Firewall zu einem System
  innerhalb des geschtzten Netzwerkes. Falls dies auch nicht klappt,
  dann wiederum mit Hilfe des NET-2 HOWTOs das LAN neu konfigurieren.

  Dann versucht man von einem System innerhalb des LAN's eine Adresse
  auerhalb des Firewalls anzupingen. (Dies sollte keine der
  192.168.2.xxx IP-Adressen sein)  Wenn das funktioniert, hat man IP-
  Forwarding nicht gesperrt. Man sollte sichergehen, da dies gewnscht
  ist. Ist es freigegeben, sollte man sich den IP-Filtering Absatz in
  diesem Dokument nher ansehen.

  Am Besten versucht man jetzt eine Internetadresse von einem Rechner im
  LAN anzupingen. Idealerweise nimmt man die Adresse die schon beim Test
  am Firewall funktioniert hat (ns.nic.de). Nur zur Erinnerung, bei
  gesperrten IP-Forwarding funktioniert der Test nicht, nur wenn IP-
  Forwarding freigegeben ist.

  Wenn IP-Forwarding freigegeben ist und "Offizielle IP-Adressen" (keine
  192.168.2.*) verwendet werden, kann man das Internet nicht direkt
  anpingen, sondern nur die Internetseite des Firewalls. *

  Hat man als Adressen fr das geschtzte LAN 192.168.2.* gewhlt,
  knnen auch keine Datenpakete geroutet werden. Ausser IP-Masquerading
  ist installiert, dann ist der Test wiederum mglich.

  Jetzt ist das Basis-System installiert.

  8.5.  IP-Filter Konfiguration (IPFWADM)

  Um zu beginnen soll IP-Forwarding im Kernel konfiguriert sein und das
  System sollte in der Lage sein, alle Pakete weiter zu schicken. Die
  Routing-Tabellen sollten passen und man soll in der Lage sein, vom LAN
  aus alle Zielsysteme im Internet zu erreichen und zurck.

  Da hier ein Firewall gebaut werden soll, ist es notwenig jeglichen
  freien Zugang zu sperren.

  Es ist ntzlich ein paar Shell-Scripte zu schreiben die beim booten
  die Firewall-forwarding Regeln und das Accounting festlegen.

  Das IP-Forwarding im Kernel leitet unkonfiguriert alles weiter. Aus
  diesem Grund soll das Boot-Script beim Systemstart jeglichen Zugriff
  verbieten und jegliche ipfw-Regeln vom letzten Start lschen. Ein
  Beispiel-Script soll dies erklren:

    #
    # setup IP packet Accounting and Forwarding
    #
    #   Forwarding
    #
    # By default DENY all services
    ipfwadm -F -p deny
    # Flush all commands
    ipfwadm -F -f
    ipfwadm -I -f
    ipfwadm -O -f

  Das ist jetzt der ultimative Firewall. Keine Daten kommen jetzt durch.
  Um jetzt ein paar Internet-Dienste durchzulassen hier ein paar
  Beispiele:

    # Forward email to your server
    ipfwadm -F -a accept -b -P tcp -S 0.0.0.0/0 1024:65535 -D 192.1.2.10 25

    # Forward email connections to outside email servers
    ipfwadm -F -a accept -b -P tcp -S 196.1.2.10 25 -D 0.0.0.0/0 1024:65535

    # Forward Web connections to your Web Server
    /sbin/ipfwadm -F -a accept -b -P tcp -S 0.0.0.0/0 1024:65535 -D 196.1.2.11 80

    # Forward Web connections to outside Web Server
    /sbin/ipfwadm -F -a accept -b -P tcp -S 196.1.2.* 80 -D 0.0.0.0/0 1024:65535

    # Forward DNS traffic
    /sbin/ipfwadm -F -a accept -b -P udp -S 0.0.0.0/0 53 -D 196.1.2.0/24

  Um eine bersicht des Datenverkehrs zu erhalten, der durch den
  Firewall geht, hier ein Beispiel:

    # Flush the current accounting rules
    ipfwadm -A -f
    # Accounting
    /sbin/ipfwadm -A -f
    /sbin/ipfwadm -A out -i -S 196.1.2.0/24 -D 0.0.0.0/0
    /sbin/ipfwadm -A out -i -S 0.0.0.0/0 -D 196.1.2.0/24
    /sbin/ipfwadm -A in -i -S 196.1.2.0/24 -D 0.0.0.0/0
    /sbin/ipfwadm -A in -i -S 0.0.0.0/0 -D 196.1.2.0/24

  Wenn das gewnschte ein Firewall-Filter war, dann ist hier das Ende.

  9.  Installation des TIS Proxy Servers

  9.1.  Beschaffung der Software

  Der TIS Firewall Tool Kit (FWTK) ist erhltlich bei ftp.tis.com

  Der FWTK wird von TIS in einem versteckten Verzeichnis auf ihrem
  Server bereitgehalten. TIS verlangt, da eine  E-Mail an fwtk-
  request@tis.com gesandt wird mit dem einzigen Wort SEND im Mailbody.
  Ein Subject wird nicht bentigt. TIS schickt eine E-Mail zurck mit
  dem Pfad zu dem Verzeichnis, wo man den FWTK herunter laden kann. Das
  Verzeichnis ist fr ca. 12h zugnglich.

  Zur Zeit ist die Version 2.0 beta vom FWTK aktuell, welche in diesem
  Beispiel hier auch verwendet wird. Wenn die endgltige Version
  verffentlicht wird, gibt es auch eine neuere Version von diesem
  HOWTO.

  Um den FWTK zu installieren mu man unter /usr/src ein Verzeichnis mit
  fwtk-2.0 anlegen. Danach das Archiv fwtk-2.0.tar.gz dort hin kopieren
  und mit tar auspacken.

  Der FWTK erlaubt keine SSL Web Dokumente aber es ist ein Zusatzmodul
  von Jean-Christophe Touvet entwickelt worden. Erhltlich unter

       ftp.edelweb.fr:/pub/contrib/fwtk/ssl-gw.tar.Z

  Touvet gibt aber keine Unterstzung zu dem Modul.

  Es gibt aber eine modifizierte Version von Eric Wedel das Zugriff zu
  Netscape's "Secure News Server" erlaubt. Erhltlich unter

       mdi.meridian-data.com:/pub/tis.fwtl/ssl-gw/ssl-gw2.tar.Z

  In diesem Beispiel wird Eric Wedel's Version verwendet.

  Um es zu installieren, einfach im /usr/src/fwtk-2.0 Verzeichnis einen
  Ordner ssl-gw anlegen und die Dateien dort hinkopieren. Es braucht
  dann noch einige nderungen damit es mit dem FWTK kompiliert.

  Die erste nderung ist in der ssl-gw.c Datei, dort fehlt noch ein
  Include:

    #if defined(__linux)
    #include        <sys/ioctl.h>
    #endif

  Zweitens fehlt noch ein Makefile. Man kann eines von den anderen
  Gateway-Verzeichnissen kopieren und den original Gateway-Namen mit dem
  des ssl-gw berschreiben.

  9.2.  Kompilieren des TIS FWTK

  Die Version 2.0 des FWTK kompiliert viel einfacher als die lteren
  Versionen.  Es mssen aber noch einige nderungen gemacht werden bis
  die Beta-Version sauber kompiliert.

  Zu Beginn mu im /usr/src/fwtk/fwtk Verzeichnis das
  Makefile.config.linux ber das originale Makefile.config kopiert
  werden.

  NICHT FIXMAKE BENTZEN. In der Anleitung steht es zwar, es zerstrt
  aber die Makefile's in jedem Verzeichnis.

  Das sed-Skript fgt ein '.' und '' zu der include-Zeile in jedem
  Makefile hinzu.  Dieses sed-Skript funktioniert:

    sed 's/^include[        ]*\([^  ].*\)/include \1/' $name .proto > $name

  Im Makefile.config mssen noch zwei nderungen gemacht werden.

  Der Autor nahm sein Home-Verzeichnis als Source-Verzeichnis. Hier wird
  aber in /usr/src gearbeitet. Aus diesem Grund mu die FWTKSRCDIR
  Variable umgesetzt werden.

    FWTKSRCDIR=/usr/src/fwtk/fwtk

  Weiterhin bentzen einige Linux-Systeme die gdbm Datenbank. Im
  Makefile.config steht dbm und mu in diesem Fall auch umgesetzt
  werden:

    DBMLIB=-lgdbm

  Die letzte nderung ist im x-gw.  Der Fehler in der BETA-Version ist
  in der socket.c. Um ihn zu beheben mssen folgende Zeilen gelscht
  werden:

    #ifdef SCM_RIGHTS  /* 4.3BSD Reno and later */
                         + sizeof(un_name->sun_len) + 1
    #endif

  Wenn das ssl-gw bentzt wird, mu man das Verzeichnis mit ins Makefile
  aufnehmen:

    DIRS=   smap smapd netacl plug-gw ftp-gw tn-gw rlogin-gw http-gw x-gw ssl-gw

  Jetzt kann man make starten.

  9.3.  Installation des TIS FWTK

  Jetzt beginnt der Spa erst richtig! Man mu jedem System mitteilen,
  da es die neuen Dienste nutzen soll und es mssen Tabellen erstellt
  werden, um dies zu kontrollieren.

  Nun ein Beispiel fr Einstellungen die erprobt sind.  Danach noch
  Beschreibungen der Probleme die dabei auftreten knnen und wie man sie
  beseitigt.

  Es gibt drei Dateien die die Kontrolltabellen enthalten:

    /etc/services

    Die Information fr das System welcher Dienst auf welchem Port
     liegt

    /etc/inetd.conf

    Teilt dem inetd mit welches Programm zu starten ist wenn eine

    Verbindung an einem Port ansteht

    /usr/local/etc/netperm-table

    Teilt den FWTK Diensten mit, wem welcher Dienst erlaubt wird oder
     nicht.

  Um die Funktion des FWTK zu gewhrleisten mssen diese Dateien von
  Grund auf neu erstellt werden. Ein falsche Einstellung in den drei
  Dateien kann das Netzwerk unerreichbar machen.

  9.3.1.  Die netperm-table Datei

  Diese Datei regelt wer Zugriff auf die Dienste des TIS FWTK hat. Man
  soll auch den Datenverkehr zu beiden Seiten des Firewalls im Auge
  behalten. Der Authentifizierungsabschnitt der netperm-table zeigt wo
  die Datenbank zu finden ist und wer Zugriff darauf hat.

    #
    # Proxy configuration table
    #
    # Authentication server and client rules
    authsrv:      database /usr/local/etc/fw-authdb
    authsrv:      permit-hosts localhost
    authsrv:      badsleep 1200
    authsrv:      nobogus true
    # Client Applications using the Authentication server
    *:            authserver 127.0.0.1 114

  Mit der permit-hosts Zeile kann es Probleme beim sperren des Zugriffs
  auf diesen Dienst geben. Eine mgliche Lsung des Problems wre
  folgende Zeile: authsrv: permit-hosts *

  Um die Datenbank zu initialisieren mu man als root das Script
  "administrative user record" zu ertellen.

  In der FWTK-Dokumentation ist beschrieben wie man neue User und Groups
  hinzufgt.

  Ein Beispiel der Vorgehensweise:

      #
      # authsrv
      authsrv# list
      authsrv# adduser admin "Auth DB admin"
      ok - user added initially disabled
      authsrv# ena admin
      enabled
      authsrv# proto admin pass
      changed
      authsrv# pass admin "plugh"
      Password changed.
      authsrv# superwiz admin
      set wizard
      authsrv# list
      Report for users in database
      user   group  longname           ok?    proto   last
      ------ ------ ------------------ -----  ------  -----
      admin         Auth DB admin      ena    passw   never
      authsrv# display admin
      Report for user admin (Auth DB admin)
      Authentication protocol: password
      Flags: WIZARD
      authsrv# ^D
      EOT
      #

  Die telnet-gateway (tn-gw) controls sind in einer Reihenfolge und der
  Erste ist zu konfigurieren.

  Im folgenden Beispiel ist es den Systemen im LAN erlaubt ohne
  Authentifikation den Firewall zu passieren.  (permit-hosts 19961.2.*
  -passok)

  Einem anderem System (196.1.2.202) wird der Zugang direkt zum Firewall
  gestattet ohne gleich durchgereicht zu werden. Die netacl-in.telnetd
  Zeile erlaubt dies.

  Der Telnet timeout sollte kurz gehalten werden.

    # telnet gateway rules:
    tn-gw:                denial-msg      /usr/local/etc/tn-deny.txt
    tn-gw:                welcome-msg     /usr/local/etc/tn-welcome.txt
    tn-gw:                help-msg        /usr/local/etc/tn-help.txt
    tn-gw:                timeout 90
    tn-gw:                permit-hosts 196.1.2.* -passok -xok
    tn-gw:                permit-hosts * -auth
    # Only the Administrator can telnet directly to the Firewall via Port 24
    netacl-in.telnetd: permit-hosts 196.1.2.202 -exec /usr/sbin/in.telnetd

  Die r-commands arbeiten in der selben Weise wie der telnet.

    # rlogin gateway rules:
    rlogin-gw:    denial-msg      /usr/local/etc/rlogin-deny.txt
    rlogin-gw:    welcome-msg     /usr/local/etc/rlogin-welcome.txt
    rlogin-gw:    help-msg        /usr/local/etc/rlogin-help.txt
    rlogin-gw:    timeout 90
    rlogin-gw:    permit-hosts 196.1.2.* -passok -xok
    rlogin-gw:    permit-hosts * -auth -xok
    # Only the Administrator can telnet directly to the Firewall via Port
    netacl-rlogind: permit-hosts 196.1.2.202 -exec /usr/libexec/rlogind -a

  Es sollte niemand Zugriff direkt auf den Firewall haben, wie es bei
  FTP der Fall ist. Somit darf kein FTP-Server auf dem Firewall
  installiert sein.

  Die permit-hosts Zeile erlaubt jedem im LAN den freien Zugriff ins
  Internet und alle anderen mssen sich authentisieren.  In den controls
  ist logging von jeder Datei, welche gesendet oder empfangen wird,
  integriert (-log { retr stor }).

  Der ftp timeout reguliert wie lange es dauert bis eine schlechte
  Verbindung beendet wird oder wie lange eine Verbindung ohne Aktivitt
  gehalten wird.

    # ftp gateway rules:
    ftp-gw:               denial-msg      /usr/local/etc/ftp-deny.txt
    ftp-gw:               welcome-msg     /usr/local/etc/ftp-welcome.txt
    ftp-gw:               help-msg        /usr/local/etc/ftp-help.txt
    ftp-gw:               timeout 300
    ftp-gw:               permit-hosts 196.1.2.* -log { retr stor }
    ftp-gw:               permit-hosts * -authall -log { retr stor }

  FTP-Verbindungen mittels Web, Gopher oder Browser werden durch den
  http-gw umgesetzt. Die ersten beiden Zeilen im folgenden Beispiel
  erzeugen einen Ordner in dem die ftp-Dateien und Web-Dokumente, die
  den Firewall passieren, gespeichert werden. Der Datei- und Ordner-
  Zugriff sollte nur root gestattet sein.

  Die Web-Verbindung sollte kurz gehalten werden. Dies steuert, wie
  lange der Anwender bei einer schlechten Verbindung warten mu.

    # www and gopher gateway rules:
    http-gw:      userid          root
    http-gw:      directory       /jail
    http-gw:      timeout 90
    http-gw:      default-httpd   www.afs.net
    http-gw:      hosts           196.1.2.* -log { read write ftp }
    http-gw:      deny-hosts      *

  Der ssl-gw ist ein Gateway der alles durchlt, aus diesem Grund wird
  zur Vorsicht geraten. Im folgenden Beispiel wird jedem Anwender
  innerhalb des LANs erlaubt eine Vebindung zu allen Servern auerhalb
  erlaubt auer zu den Adressen 127.0.0.* und 192.1.1.* und auch nur auf
  den Ports 443 und 563. Diese Ports sind bekannte SSL-Ports.

    # ssl gateway rules:
    ssl-gw:         timeout 300
    ssl-gw:         hosts           196.1.2.* -dest { !127.0.0.* !192.1.1.* *:443:563 }
    ssl-gw:         deny-hosts      *

  Im folgendem Beispiel ist die Bentzung des plug-gw beschrieben um
  Verbindungen zu einem News-Server zu erlauben. In diesem Beispiel ist
  jedem Anwender im LAN nur die Verbindung zu einem System erlaubt und
  auch nur zum News-Port.

  Die zweite Zeile erlaubt dem Newsserver die Daten zurck zum LAN
  passieren zu lassen.

  Da die meisten News-Clients die Verbindung whrend dem News-Lesens
  bestehen lassen ist ein lngerer timeout fr den Newsserver zu whlen.

    # NetNews Pluged gateway
    plug-gw:        timeout 3600
    plug-gw: port nntp 196.1.2.* -plug-to 199.5.175.22 -port nntp
    plug-gw: port nntp 199.5.175.22 -plug-to 196.1.2.* -port nntp

  Der finger-gateway ist sehr einfach. Jeder Anwender innerhalb des LANs
  mu sich in den Firewall einloggen um den dortigen finger zu
  verwenden. Jeder andere bekommt einfach eine Meldung.

    # Enable finger service
    netacl-fingerd: permit-hosts 196.1.2.* -exec /usr/libexec/fingerd
    netacl-fingerd: permit-hosts * -exec /bin/cat /usr/local/etc/finger.txt

  9.3.2.  Die inetd.conf Datei

  Das folgende Beispiel ist eine komplette /etc/inetd.conf Datei.  Alle
  unbentigten Dienste sind auskommentiert. Es ist aus dem Grund
  komplett um zu zeigen was nicht bentigt wird und wie die neuen
  Dienste eingefgt werden.

    #echo stream  tcp  nowait  root       internal
    #echo dgram   udp  wait    root       internal
    #discard      stream  tcp  nowait  root       internal
    #discard      dgram   udp  wait    root       internal
    #daytime      stream  tcp  nowait  root       internal
    #daytime      dgram   udp  wait    root       internal
    #chargen      stream  tcp  nowait  root       internal
    #chargen      dgram   udp  wait    root       internal
    # FTP firewall gateway
    ftp-gw      stream  tcp  nowait.400  root  /usr/local/etc/ftp-gw ftp-gw
    # Telnet firewall gateway
    telnet        stream  tcp  nowait      root  /usr/local/etc/tn-gw /usr/local/etc/tn-gw
    # local telnet services
    telnet-a    stream  tcp  nowait      root  /usr/local/etc/netacl in.telnetd
    # Gopher firewall gateway
    gopher        stream  tcp  nowait.400  root /usr/local/etc/http-gw /usr/local/etc/http-gw
    # WWW firewall gateway
    http  stream  tcp  nowait.400  root  /usr/local/etc/http-gw /usr/local/etc/http-gw
    # SSL firewall gateway
    ssl-gw  stream  tcp     nowait  root /usr/local/etc/ssl-gw ssl-gw
    # NetNews firewall proxy (using plug-gw)
    nntp    stream  tcp     nowait  root    /usr/local/etc/plug-gw plug-gw nntp
    #nntp stream  tcp     nowait  root    /usr/sbin/tcpd  in.nntpd
    # SMTP (email) firewall gateway
    #smtp stream  tcp     nowait  root    /usr/local/etc/smap smap
    #
    # Shell, login, exec and talk are BSD protocols.
    #
    #shell        stream  tcp     nowait  root    /usr/sbin/tcpd in.rshd
    #login        stream  tcp     nowait  root    /usr/sbin/tcpd in.rlogind
    #exec stream  tcp     nowait  root    /usr/sbin/tcpd  in.rexecd
    #talk dgram   udp     wait    root    /usr/sbin/tcpd  in.talkd
    #ntalk        dgram   udp     wait    root    /usr/sbin/tcpd in.ntalkd
    #dtalk        stream  tcp     waut    nobody  /usr/sbin/tcpd in.dtalkd
    #
    # Pop and imap mail services et al
    #
    #pop-2   stream  tcp  nowait  root  /usr/sbin/tcpd    ipop2d
    #pop-3   stream  tcp  nowait  root  /usr/sbin/tcpd    ipop3d
    #imap    stream  tcp  nowait  root  /usr/sbin/tcpd    imapd
    #
    # The Internet UUCP service.
    #
    #uucp    stream  tcp  nowait  uucp  /usr/sbin/tcpd /usr/lib/uucp/uucico -l
    #
    # Tftp service is provided primarily for booting.  Most sites
    # run this only on machines acting as "boot servers." Do not uncomment
    # this unless you *need* it.
    #
    #tftp dgram   udp     wait    root    /usr/sbin/tcpd  in.tftpd
    #bootps       dgram   udp     wait    root    /usr/sbin/tcpd bootpd
    #
    # Finger, systat and netstat give out user information which may be
    # valuable to potential "system crackers."  Many sites choose to disable
    # some or all of these services to improve security.
    #
    # cfinger is for GNU finger, which is currently not in use in RHS Linux
    #
    finger        stream  tcp  nowait  root   /usr/sbin/tcpd in.fingerd
    #cfinger      stream  tcp  nowait  root   /usr/sbin/tcpd in.cfingerd
    #systat       stream  tcp  nowait  guest  /usr/sbin/tcpd  /bin/ps -auwwx
    #netstat      stream  tcp  nowait  guest  /usr/sbin/tcpd /bin/netstat -f inet
    #
    # Time service is used for clock syncronization.
    #
    #time stream  tcp  nowait  root  /usr/sbin/tcpd  in.timed
    #time dgram   udp  wait    root  /usr/sbin/tcpd  in.timed
    #
    # Authentication
    #
    auth          stream  tcp  wait    root  /usr/sbin/tcpd  in.identd -w -t120
    authsrv       stream  tcp  nowait  root  /usr/local/etc/authsrv authsrv
    #
    # End of inetd.conf

  9.3.3.  Die /etc/services Datei

  Hier ist aller Anfang. Ein Client baut die Verbindung zu einem
  Firewall immer zu einem bekannten Port auf (unterhalb 1024), zum
  Beispiel der telnet auf Port 23. Der inet-Dmon bemerkt die Verbindung
  und sucht den Dienst in der /etc/services Datei.  Danach startet er
  das Programm, welches in der /etc/inetd.conf Datei dem Dienst
  zugewiesen ist.

  Einige der Dienste, die hier erstellt werden, sind blicherweise nicht
  in der /etc/services Datei. Somit kann man einigen davon einen Port
  eigener Wahl zuweisen. Zum Beispiel kann man den telnet-Port vom
  Administrator (telnet-a) dem Port 24 zuweisen. Man kann ihn aber auch
  dem Port 2323 zuweisen, je nach Belieben. Damit sich der Administrator
  direkt zum Firewall verbinden kann mu er einen telnet zum Port 24,
  und nicht zum Port 23, starten und wenn die netperm-table richtig
  aufgesetzt ist kann man dies nur von einem Systems innerhalb des
  geschtzten Netzwerkes tun.

    telnet-a        24/tcp
    ftp-gw          21/tcp             # this named changed
    auth            113/tcp   ident    # User Verification
    ssl-gw          443/tcp

  10.  Der SOCKS Proxy Server

  10.1.  Installation des Proxy Servers

  Der SOCKS Proxy Server ist hier erhltlich:

       sunsite.unc.edu:/pub/Linux/system/Network/misc/socks-linux-src.tgz

  Im selben Verzeichnis ist auch eine Beispiel-Konfigurationsdatei mit
  folgendem Namen "socks-conf".  Mit gzip und tar das Archiv auspacken
  und den Anweisungen im README folgen. Manche hatten Probleme beim
  kompilieren, einfach aufpassen ob die Makefiles passen.

  Unbedingt zu beachten ist, da der Proxy Server in der /etc/inet.d
  Datei eingetragen wird:

    socks  stream  tcp  nowait  nobody  /usr/local/etc/sockd  sockd

  Damit wird der Server bei Anforderung gestartet.

  10.2.  Konfiguration des Proxy Servers

  Das SOCKS Programm bentigt zwei verschiedene Konfigurationsdateien.
  Eine um den Zugriff zu erlauben (access file) und eine um die
  Anforderungen zum betreffenden Proxy Server zu leiten (routing file).
  Die Access Datei soll im Server installiert sein und die Routing Datei
  auf jedem Unix-Rechner.  DOS-Rechner und MacIntosh-Rechner machen ihr
  eigenes Routing.

  10.2.1.  Die Access Datei

  Mit SOCKS 4.2 Beta wird die Access Datei  "sockd.conf" genannt.  Diese
  Datei soll 2 Zeilen enthalten, eine Erlaubnis- (permit) und eine
  Ablehnungs- (deny) Zeile.

  Jede Zeile hat drei Eintrge.

    Den Bezeichner            (identifier, permit/deny)

    Die IP Adresse            (address)

    Den Adressen Modifizierer (modifier)

  Der Bezeichner ist entweder permit oder deny. Man soll beides haben,
  eine permit- und eine deny-Zeile.

  Die IP-Adresse enthlt eine 4 Byte Adresse in typischer IP-Notation,
  z.B. 192.168.2.0.

  Der Adress-Modifizierer ist ebenso eine typische 4 Byte IP-Adresse.
  Sie arbeitet wie eine Netzmaske. Gehen wir davon aus, da diese Zahl
  32 Bit (Einsen und Nullen) entspricht. Ist das Bit eine Eins mu das
  entsprechende Bit der zu prfenden Adresse zum entsprechenden Bit des
  IP-Adre-Feldes passen.

  Wenn zum Beispiel die Zeile so lautet:

      permit 192.168.2.23 255.255.255.255

  werden nur die IP-Adressen zugelassen, bei denen jedes einzelne Bit
  passen mu. Bei 192.168.2.23 eben nur 192.168.2.23.

  Bei folgender Zeile

      permit 192.168.2.0 255.255.255.0

  wird jede Nummer innerhalb der Gruppe von 192.168.2.0 bis
  192.168.2.255 zugelassen, eben eines kompletten Klasse-C Bereiches.

  Folgende Zeile sollte man niemals zulassen:

      permit 192.168.2.0 0.0.0.0

  Damit bekommt ohne Rcksicht jeder die Zulassung.

  Aus diesem Grund wird nur jede Adresse durchgelassen die eine
  Erlaubnis hat, der Rest wird einfach abgewiesen. Damit jeder im
  Bereich 192.168.2.xxx zugelassen wird sind folgende Zeilen passend:

      permit 192.168.2.0 255.255.255.0
      deny 0.0.0.0 0.0.0.0

  Wenn man das erste "0.0.0.0" in der deny-Zeile betrachtet ist zu
  beachten, da bei einem Modifizierer von 0.0.0.0 die IP-Adresse nicht
  mehr wichtig ist. In diesem Fall ist 0.0.0.0 der Standard, da es
  einfacher zu tippen ist.

  Es ist auch mehr als eine Zeile mit den beiden Mglichkeiten erlaubt.

  Speziellen Anwendern kann der Zugriff erlaubt oder auch abgelehnt
  werden.  Dies geschieht mit der ident Authentifizierung. Nicht alle
  Systeme untersttzen ident, unter anderem Trumpet Winsock. Aus diesem
  Grund wird hier nicht nher darauf eingegangen. Die Dokumentation zu
  SOCKS bietet hier selbst gute Untersttzung.

  10.2.2.  Die Routing Datei

  Die Routing Datei in SOCKS wird leider "socks.conf" genannt.  Warum
  wird sie "leider" so genannt? Sie unterscheidet sich kaum im Namen von
  der Access Datei und ist somit schnell verwechselt.

  Die Aufgabe der Routing Datei ist den SOCKS-Clients mitzuteilen wann
  SOCKS zu bentzen ist und wann nicht. Zum Beispiel wird bei einer
  Verbindung von 192.168.2.3 zu 192.168.2.1 der SOCKS Firewall nicht
  bentzt, es wird direkt ber Ethernet verbunden. Der Loopback,
  127.0.0.1, wird automatisch definiert. Auerdem bentigt man SOCKS bei
  einer Verbindung zu sich selber auch nicht. Es gibt drei Eintrge:

    deny

    direct

    sockd

  Mit deny wird SOCKS mitgeteilt wann eine Anforderung abgewiesen wird.
  Dieser Eintrag hat die selben drei Felder wie in sockd.conf:
  identifier, address und modifier. Da dies auch von sockd.conf, der
  Access-Datei, verwaltet wird, kann das modifier Feld 0.0.0.0 bleiben.
  Um sich selbst davon auszuschlieen irgendeinen Rechner zu erreichen,
  kann man es hier tun.

  Der direct Eintrag nennt die Adressen die SOCKS nicht bentigen. Das
  sind alle Adressen die ohne den Proxy Server erreicht werden knnen.

  Im folgenden Beispiel

      direct 192.168.2.0 255.255.255.0

  kann jeder direkt den anderen rechner im geschtzten Netzwerk
  erreichen.
  Der folgende sockd - Eintrag zeigt dem Computer welcher Host den SOCKS
  Server Dmon installiert hat:

    sockd @=<serverlist> <IP address> <modifier>

  Zu beachten ist der @= Eintrag. Dies erlaubt die IP-Adressen einer
  Liste von Proxy-Servern einzutragen. In diesem Beispiel wird aber nur
  ein Proxy-Server verwendet. Man kann aber mehrere haben um die Last zu
  verteilen oder eine Sicherheits-Redundanz zu haben.

  Das IP-Adre und modifier Feld hat die selbe Form wie im vorigen
  Beispiel.  Es mssen die Adressen bekannt gemacht werden die durch den
  Proxy-Server drfen.

  10.2.3.  DNS hinterhalb des Firewalls

  Einen Domain Name Service hinterhalb des Firewalls zu installieren ist
  eine einfache Aufgabe.  Man mu lediglich den DNS auf dem Firewall-
  Computer installieren und alle Rechner hinterhalb des Firewalls diesen
  DNS benutzen lassen.

  10.3.  Arbeiten mit einem Proxy Server

  10.3.1.  Unix

  Damit die Applikationen mit dem Proxy-Server arbeiten, mssen sie
  "SOCKSifiziert" werden.  Man bentigt zwei verschiedene telnet, einen
  fr direkte Kommunikation und einen fr die Kommunikation mit dem
  Proxy-Server.  Socks enthlt eine Anleitung wie man ein Programm
  SOCKSifiziert und ein paar fertigen SOCKSifizierten Programmen. Wenn
  man eine SOCKSifizierte Version eines Programmes verwendet um
  innerhalb des LANs eine Verbindung aufzubauen, lenkt SOCKS automatisch
  zur Version fr direkte Kommunikation um.  Aus diesem Grund werden
  alle Programm im Netzwerk umbenannt und durch SOCKSifizierte Versionen
  ersetzt. "Finger" wird zu "finger.orig", "telnet" wird zu
  "telnet.orig", usw.  Diese nderungen mssen in die include/socks.h
  eingetragen werden.

  Manche Programmen fhren das Routing und die SOCKSifizierung selber
  durch, wie z.B. NetScape. Man kann mit NetScape einen Proxy-Server
  verwenden indem man die IP-Adresse des Servers in dem entsprechenden
  Feld der Netzwerkeinstellungen eintrgt (in diesem Beispiel
  192.168.2.1). Jede Applikation bentigt eine gewisse Umstellung,
  unabhngig davon wie es mit einen Proxy Server funktioniert.

  10.3.2.  MS Windows mit Trumpet Winsock

  Trumpet Winsock hat schon eingebaute Proxy-Server Mglichkeiten. Im
  "setup" Men gibt man die IP-Adresse des Servers ein, ebenso alle
  Adressen der Rechner, die man direkt erreichen kann. Trumpet leitet
  dann alle Pakete weiter.

  10.3.3.  Konfiguration des Proxy Servers zur Untersttzung von UDP-
  Paketen

  Das SOCKS-Paket arbeitet nur mit TCP-Paketen, nicht mit UDP-Paketen.
  Das schrnkt ein klein wenig den Nutzen ein. Viele ntzliche
  Programme, wie talk und archie, bentzen UDP. Es gibt ein Paket das
  von Tom Fitzgerald (fitz@wang.com) entwickelt wurde, um wie ein Proxy
  Server fr UDP-Pakete zu funktionieren, genannt UDPrelay. Leider ist
  es zur Zeit nicht kompatibel zu Linux.

  10.4.  Nachteile mit Proxy Servern

  Ein Proxy Server ist vor allem eine Sicherheits Einheit. Die
  Benutzung, um den Internetzugang mit limitierten IP-Adressen zu
  erweitern, hat viele Nachteile. Ein Proxy Server bietet guten Zugriff
  von innerhalb des geschtzten Netzwerkes nach auen und lt das LAN
  fr Anwender von Auen komplett unerreichbar sein. Das bedeutet keine
  Server, Archie, Talk Verbindungen oder direktes Mailing zu den inneren
  Computern. Diese Nachteile knnen schwerwiegend sein, aber man soll
  folgendes beachten:

    Sie bearbeiten gerade einen Bericht auf einem Computer innerhalb
     des geschtzten Netzwerkes. Zuhause kommt der Wunsch auf, den
     Bericht nochmals zu berarbeiten. Sie haben aber keinen Zugriff auf
     Ihren Brocomputer, da er hinter einer Firewall ist. Sie versuchen
     eine Verbindung zum Firewall aufzubauen, aber es wurde versumt
     Ihnen einen Zugang zum Firewall einzurichten.

    Ihre Tochter geht zur Uni. Sie wollen ihr eine E-Mail schicken.
     Sie haben wirklich private Themen mit ihr zu besprechen und wollen
     die Antwort direkt auf Ihren Computer gesendet haben. Sie vertrauen
     dem System-Administrator aber es ist eben private Mail.

    Die fehlende Mglichkeit UDP zu bentzen, zeigt einen groen
     Nachteil von Proxy-Servern auf. Der Einsatz von UDP wird aber wohl
     bald mglich sein.

  FTP bereitet ein weiteres Problem mit einem Proxy-Server. Bei Empfang
  oder Verwendung von ls ffnet der FTP-Server einen Socket auf dem
  Client-Rechner und reicht die Informationen durch. Ein Proxy-Server
  wird das nicht erlauben, darum wird FTP nicht sonderlich gut
  funktionieren.

  Aufgrund des greren Overheads arbeiten Proxy-Server relativ langsam.
  Die Allgemeinheit ist der Meinung da sich das zuknftig ndert.

  Grundstzlich, wenn man IP-Adressen hat und die Sicherheit ist nicht
  das wichtigste, dann sollte man Proxy-Server und Firewalls nicht
  verwenden.  Wenn keine ausreichende Anzahl an IP-Adressen vorhanden
  ist und die Sicherheit immer noch keine groe Rolle spielt, dann ist
  ein IP-Emulator, wie Term, Slirp oder TIA, eine interessante Wahl.

  Term ist erhltlich bei: sunsite.unc.edu und Slirp bei:
  blitzen.canberra.edu.au:/pub/slirp.  TIA gibts bei marketplace.com.

  Diese Pakete arbeiten schneller, erlauben bessere Verbindungen und
  bieten einen besseren Zugriff vom Internet ins private Netzwerk.
  Proxy-Server sind gut fr Netzwerke mit vielen Computern die einen
  einfachen Zugriff zum Internet haben wollen mit nur einer einmaligen
  Konfiguration und mit wenig Arbeit im laufenden Betrieb.

  11.  Erweiterte Konfigurationen

  Das nchste Beispiel zeigt eine erweiterte Konfiguration die vielen
  gengen wird und einige Fragen klrt.

  11.1.  Ein grosses Netzwerk mit Sicherheit als Schwerpunkt

  Als Beispiel sei angenommen ein Netzwerk mit 50 Computern und ein
  Subnetz von 32 IP-Adressen (5 Bits). Bentigt werden unterschiedliche
  Zugangsstufen und Teile des Netzwerkes sollen vom Rest geschtzt sein.

  Die Stufen wren:

  1. Die externe Zugangsstufe. Diese Stufe bekommt jeder zu sehen.

  2. Mitarbeiter. Dies ist die Stufe fr alle die aus der externen Stufe
     aufgestiegen sind.

  3. Experten. Hier werden die wichtigsten Daten verwaltet.

  11.1.1.  Die Netzwerk Konfiguration

  Die IP-Adressen sind folgendermaen eingeordnet:

    Die Adresse 192.168.2.255 (Broadcast Adresse) ist unbentzbar.

    23 der 32 IP-Adressen werden 23 Computern mit Zugriff zum Internet
     zugewiesen.

    Eine Adresse wird dem Linux-Computer zugewiesen.

    Eine Adresse wird einem weiteren Linux-Computer im Netzwerk
     zugewiesen.

    2 Adressen bekommt der Router

    4 Adressen bleiben brig und werden fr zuknftige Aufgaben
     reserviert.

    Die geschtzten Netzwerke bekommen beide die Adressen 192.168.2.xxx

  Es werden auer dem externen ffentlichen noch 2 separate Netzwerke
  gebildet, jedes in verschiedenen Rumen.  Sie werden mit Ethernet
  verbunden.

  Diese Netzwerke werden jeweils an einen Linux-Computer mit eigener IP-
  Adresse angebunden.

  Ein Daten-Server wird mit beiden Netzwerke vebunden, damit einige aus
  der restlichen Mitarbeiter-Gruppe Zugriff auf die wichtigen Daten
  haben. Der Daten-Server hat die IP-Adressen 192.168.2.17 fr das
  Mitarbeiter-Netzwerk und 192.168.2.23 fr das Experten-Netzwerk. Er
  hat 2 IP-Adressen weil er 2 Ethernetkarten hat, eine jeweils fr das
  Mitarbeiter- und das Experten-Netzwerk.  IP-Forwarding ist
  ausgeschaltet.

  IP-Forwarding ist auch an den Linux-Computern ausgeschaltet. Der
  Router wird keine IP-Pakete fr 192.168.2.xxx weiterleiten, solange
  ihm das nicht erlaubt wird, somit kann niemand aus dem Internet rein.
  Der Grund fr das Ausschalten von IP-Forwarding besteht darin, da
  keine Daten-Pakete aus dem Mitarbeiter-Netzwerk in das Experten-
  Netzwerk geraten und ebenso umgekehrt.

  Der Daten-Server kann so konfiguriert werden um beide Netzwerke mit
  unterschiedlichen Daten zu bedienen. Mit symbolischen Verweisen kann
  man allgemeine Daten beiden Netzwerken zugnglich machen.

  11.1.2.  Die Proxy-Konfiguration

  Alle 3 Stufen wnschen eine berwachung des Netzwerkes ber eventuelle
  falsche Absichten. Das externe ffentliche Netzwerk wird direkt mit
  dem Internet verbunden somit gibt es hier keine Probleme mit dem
  Proxy-Server.  Die Experten- und Mitarbeiter-Netzwerke sind hinter dem
  Firewall, somit ist es wichtig hier einen Proxy-Server zu
  installieren.

  Beide Netzwerke werden ungefhr gleich konfiguriert. Beide bekommen
  die selbe IP-Adresse zugewiesen um es ein hier ein wenig interessanter
  zu machen.

  1. Keiner kann den Daten-Server fr den Internet-Zugnang bentzen.
     Dies schtzt den Daten-Server vor Viren und anderen blen Dingen
     und ist somit sehr wichtig.

  2. Den Mitarbeitern wird kein Zugriff aufs World Wide Web gestattet.

  Die sockd.conf Datei im Mitarbeiter-Linux-Computer hat folgenden
  Eintrag:

      deny 192.168.2.17 255.255.255.255

  Der Experten-Computer folgenden:

      deny 192.168.2.23 255.255.255.255

  Der Mitarbeiter-Linux-Computer hat noch diesen Eintrag:

      deny 0.0.0.0 0.0.0.0 eq 80

  Dies verbietet den Zugriff aller Computer auf den Port gleich (eq) 80,
  dem http Port. Es erlaubt jeden anderen Dienst, nur eben nicht den
  Web-Zugriff.

  Die Datei auf beiden Computern hat noch jenen Eintrag:

      permit 192.168.2.0 255.255.255.0

  damit allen Computern aus dem 192.168.2.xxx Netzwerk erlaubt wird den
  Proxy-Server zu bentzen auer den schon Abgewiesenen (den Daten-
  Server und der Web-Zugriff aus dem Mitarbeiter-Netzwerk).

  Die Mitarbeiter sockd.conf sieht demnach so aus:

      deny 192.168.2.17 255.255.255.255
      deny 0.0.0.0 0.0.0.0 eq 80
      permit 192.168.2.0 255.255.255.0

  und die Experten sockd.conf so:

      deny 192.168.2.23 255.255.255.255
      permit 192.168.2.0 255.255.255.0

  Dies sollte alles korrekt konfigurieren. Jedes Netzwerk sollte
  entsprechend dem Ma an Wichtigkeit isoliert sein.

