Erstellen einer Installationsdiskette

Die Installationsdiskette enthält einige wenige Dateien, die vollständig die Hardware und Netzwerkkonfiguration des Firewall beschreiben. Während der Installation wird diese Diskette angefordert. Alle weiteren Dateien sind bereits optional : Die einfachste Vorgehensweise besteht darin, sich die Beispieldaten zu kopieren und diese an seine eigene Bedürfnisse anzupassen, bis eine korrekte Umgebung geschaffen ist. Nicht benötigte Dateien sollten auf der Installationsdiskette gelöscht werden.

Kopieren der Beispieldaten

Windows
Legen Sie die Installations-CD ein und wechseln Sie ins Verzeichnis beispiele auf der CD. Kopieren Sie sich die Dateien auf Diskette, die Sie benötigen.
Linux
andere Betriebssysteme
Übersetzen Sie mtools auf Ihrem Rechner, sofern das Betriebssystem vfat-Disketten (DOS-Disketten mit langen Dateinamen) nicht versteht. Arbeiten Sie mit mcopy um die Dateien zu übertragen.

config.lw2

Diese Datei enthält alle Informationen über den Firewall, soweit nicht Subsysteme sehr umfangreiche Konfigurationseinstellungen in separaten Dateien nötig machen. Als Textdatei wird sie als Unterprozedur in mehreren shell-Skripten eingelesen und besteht aus Zuweisungen der Art: VARIABLENNAME="WERT". Im Folgenden sind diese Variablen beschrieben.

Das schräggestellte N steht dabei für eine einzusetzende Zahl, die Bedeutung ergibt sich aus dem Zusammenhang.
 
 

Allgemein    
FQHOSTNAME mail.linuxwall.de Der volle Name des Rechners, wie er im Internet bekannt sein soll. Er besteht aus Hostnamen (z.B. mail) und dem Domänenteil (z.B. linuxwall.de).
MAILHOSTNAME mail.linuxwall.com Nur wenn der Name des Mail-Servers unterschiedlich ist, muß diese Variable angegeben werden. Mit diesem Namen identifiziert sich das SMTP-Programm.
POSTMASTER "fb@xyz.sg" Benutzer, an den Bounce-Meldungen oder andere unzustellbare Mails geschickt werden soll. Eine Mail an diesen Benutzer bedeutet häufig eine LinuxWall-Fehlkonfiguration, die nur unangenehm, aber i.d.R. nicht sicherheitskritisch ist.
APACHE_ADMIN admin@linuxwall.de Der Administrator, an den Fehler des Apache-Proxies als Mail geschickt werden soll.
MAIL_LOGFILES "lwclog@linuxwall.de fb@xyz.sg" Die Benutzer, an die die komprimierten Log-Files (bei reboot, sowie 5 Uhr morgens) geschickt werden sollen.
KEEP_FILES 3 Die Anzahl der Tage, die die Log-Dateien auf LinuxWall gespeichert bleiben sollen. Default ist unlimitiert.
MAIL_VIRUS_ALERT "lwclog@linuxwall.de fb@xyz.sg" Die Benutzer, an die im Falle eines Virus sofort eine Meldung geschickt werden soll.
DNS "145.253.2.11 145.253.2.75" Die Nameserver, die LinuxWall benutzen soll. Bis zu drei Nameserver können angegeben werden.
NAMED_START "yes" optional : der interne DNS-BIND-Server soll gestartet werden. Separate Dokumentation "DNS".
BROKEN_DNS "yes" DNS-Anfragen kommen mit Quell-und Zielport 53, Quellport ist nicht im Bereich >1023. Nötig bei Anfragen von alten Bind-Versionen an andere Nameserver
SSHD_START "yes" optional : der interne ssh-Dämon soll gestartet werden. Wichtig z.B. für die Fernwartung von LinuxWall.
NTP_SERVER "ntp2.ptb.de" Der/die NTP-Server, die LinuxWall benutzen soll. Sie werden durch Leerzeichen getrennt.
BROKEN_NTP "yes" wenn NTP-Anfragen mit Quellport 1024:65535, nicht nur mit 123 bei der Interpretaion der Makros zugelassen werden sollen.
SYSLOG_HOSTS "tux.company.net 10.64.15.4" syslogd-Meldungen sollen zusätzlich an diese Rechner gesendet werden.
CRON-Einstellungen   alle Einträge haben genau fünf Felder, ansonsten wird der Fehler auf syslog gemeldet und der default-Wert benutzt
CRON_IPACCOUNTING "0 * * * *" In welchem Intervall werden die Zähler der Regeln ausgelesen (default "*/15 * * * *") ? Diese Variable sollte nicht verändert werden, sonst funktionieren die automatischen Auswertefunktionen der Alarmzentrale nicht mehr korrekt.
CRON_LOGFILES "5 16 * * *" Wann werden die Logfiles versandt ("2 5 * * *") ? Hier sollte nur Minute/Stunde verändert werden.
CRON_CRYPTUPD "0 * * * *" Wann wird der automatisierte Update/Virenschutz ausgeführt  ("0 */3 * * *") ?
CRON_FETCHMAIL "10 6-22 * * 1-6" Optional, nur wenn fetchmail.rc vorhanden ist : Wie oft wird Mail abgeholt  ("50 7-20 * * 1-5") ?
VPN-Einstellungen    
VPNADDR "212.121.2.2" VPN-Gatewayadresse. Die eigene Adresse des VPN-Endpunktes, in den meisten Fällen ist dies die externe Adresse von LinuxWall
VPNROUTER "212.121.2.1" Optionale Router-Adresse. Oft stellt der ISP einen Router für die Verbindung ins Internet. Dessen Adresse stellt man hier ein.
VPNLAN "10.0.61.0/24 235.9.8.17/28" LAN-Segmente auf dieser Seite (auch DMZ), die über VPN zur Verfügung gestellt werden sollen. Die Einträge sind durch Leerzeichen getrennt.
VPNCONNECTIONS "ffm:freeswan:194.3.34.2:10.3.0.0/24:194.2.34.1" VPN-Verbindungen (andere Seite), durch Leerzeichen getrennt, Parameter der Verbindungen werden durch ':' getrennt. Siehe auch VPN
RP_FILTER_OFF "eth1" Das Interface, auf welchem die Überprüfung auf IP-Spoofing ausgestellt werden muss. Meist das Interface, welches zum Internet weist.
Schnittstellen    
INTERFACES "_1 _2 _3 _4" Die Aufzählung der Netzwerkschnittstellen, es werden alle physikalischen (z.B. Ethernet) und virtuellen (z.B. Tunnel) Schnittstellen aufgezählt.
MODNAME_N ne Der Modulname des Netzwerkkartentreibers, der geladen werden muß (ne ist eine NE2000-kompatible Karte), die Tabelle für die Modulnamen finden Sie hier.
IFNAME_N eth0 Der Schnittstellenname, wie er vom Linux-Kern verwendet wird. Die Tabelle der Schnittstellentypen finden Sie hier.
OPTION_N "io=0x300,0x320 irq=5,9" Optionen, meistens nur für ISA-Karten nötig. Im Beispiel gibt es zwei Netzwerkkarten, die auf 0x300 und 0x320 liegen, sie haben Interrupt 5 und 9. Die Optionen müssen nur bei der ersten verwendeten Netzwerkkarte angegeben werden. Jede Karte hat andere Optionen. Die Dokumentation darüber finden Sie z.B. in den SuSE-Handbüchern.
IFCFG_N_ADDR 10.0.2.2 IP-Adresse dieser Schnittstelle. Bei dynamischer IP-Zuweisung kann ein beliebiger Wert, z.B. 0.0.0.1, aber nicht 0.0.0.0 eingetragen werden. Bei Tunneln, die mit dynamisch zugewiesenen IP-Adressen korrespondieren, wird die feste Adresse eines internen Interfaces eingestellt.
IFCFG_N_MASK 255.255.255.0 Netzwerkmaske für diese Schnittstelle. Bei Punkt-zu-Punkt-Verbindungen sollte hier 255.255.255.255 eingetragen werden. Bei tunlN-Schnittstellen sollte die Maske nicht 255.255.255.255 sein, sondern z.B. 255.255.255.252
IFCFG_4_REMOTEIP 212.222.212.222 Bei Punkt-zu-Punkt-Verbindungen (tunlN) wird diese Adresse benötigt, ansonsten nicht ausgewertet. Ist die Adresse der Gegenstelle wegen dynamischer IP-Adressierung nicht bekannt, wird 0.0.0.0 angegeben.
ISDN-Parameter   Diese Parameter werden nur bei ISDN-Schnittstellen benötigt und ausgewertet
IFCFG_N_VERBOSE 1 Die Geschwätzigkeit von ipppd wird damit geregelt. Sie sollte auf einem kleinen Wert eingestellt werden, bei zuverlässigen Verbindungen kann dann auch 0 eingestellt werden.
IFCFG_N_EAZ 06947885616 Die MSN dieser Schnittstelle.
IFCFG_N_DIALMODE "auto" Die Anwahl soll automatisch erfolgen, die Variable sollte immer diesen Wert haben.
IFCFG_N_DIALMAX 5 Anzahl von Wahl-Wiederholungsversuchen
IFCFG_N_HUPTIMEOUT 90 Nach dieser Anzahl von Sekunden ohne Aktivität soll die Verbindung abgebaut werden.
IFCFG_N_OUT 010700192070 Die zu wählende Nummer des Providers, Amtsholungs-Präfixe (z.B. zusätzliche 0) müssen ebenfalls angegeben werden.
IFCFG_N_USER "arcor" Der Benutzername, mit dem man sich gegenüber dem Provider identifiziert. Dieser Benutzername wird automatisch sowohl in chap-secrets als auch pap-secrets eingetragen, so daß LinuxWall flexibel auf die Authentisierungsanforderungen des Providers reagieren kann.
IFCFG_N_SECRET "internet" Das zugehörige Paßwort zum Benutzer.
Routen   Manuelle Einstellungen zu Routen
ROUTES "_1 _2 _3 _4" Wie bei den Schnittstellen, zählt diese Variable die nachfolgenden Routing-Einträge auf.
ROUTE_N "212.222.212.222 dev ippp0" Die Syntax ist wie beim route-Kommando anzugeben, allerdings ohne führendes "route add" oder "route delete". Bei Tunnels muß das erntfernte Netz als Route angegeben werden und die Gegenstelle über die "normale Schnittstelle" als separate Route spezifiziert werden. Man kann bei dynamisch zugewiesenen IP-Adressen statt der Gateway-Adresse auch die Schnittstelle angeben und wird dadurch adreßunabhängig.
Inhaltsprüfung   Manuelle Einstellungen zum Virencheck
UPDATE_LINUXWALL_SOPHOS "yes" Es soll ein täglicher automatisierter Update des Virenscanners durchgeführt werden. Default ist "no". 
HTTP_VIRUS_CHECK "no" Wenn auf "no" gesetzt, wird bei HTTP-Zugriffen (Web) kein Virencheck vorgenommen, egal, welche Virenscanner vorhanden sind. Wenn es auf "-S" gesetzt ist, wird der schnellere SAVI-Scan verwendet. Default ist "yes".
HTTP_PASS_HEADER "yes" Wenn auf "yes" gesetzt, bewirkt dies, daß HTTP-Header (z.B. bei HTTP-Downloads) durchgelassen werden, auch wenn das Dokument selbst noch nicht überprüft wurde. Dadurch kommt es unter Windows wieder zu den "fliegenden Fenstern" (Fortschrittsanzeige für den Benutzer), die sonst nicht erscheinen. Default ist "no".
HTTP_CHECK_KEYWORDS "yes" Wenn auf "yes" gesetzt, bewirkt das eine Prüfung mit dem Schmuddelfilter mit Hilfe der Konfigurationsdatei "content.rules". Separate Dokumentation. Default ist "no".
HTTP_PRINT_URL "no" Wenn auf "no" gesetzt, wird die URL und die Parameter eines HTTP-Zugriffs nur bei Fehlern ins Log geschrieben. Default ist "yes".
HTTP_PROXY "234.45.12.12:8080" IP-Adresse und Port des Proxies, den LinuxWall benutzen soll. Normalerweise wird das Ziel direkt aufgesucht. Diese Einstellung ist für LinuxWalls, die selbst wieder hinter einer Firewall stehen oder für anonymisierte Web-Zugriffe geeignet. Default ist "".
FTP_VIRUS_CHECK "no" Wenn auf "no" gesetzt, wird bei FTP-Zugriffen kein Virencheck vorgenommen, egal, welche Virenscanner vorhanden sind. Default ist "yes".
FTP_PRINT_URL "no" Wenn auf "no" gesetzt, wird die URL und die Parameter eines FTP-Zugriffs nur bei Fehlern ins Log geschrieben. Default ist "yes".
NNTP_VIRUS_CHECK "no" Wenn auf "no" gesetzt, wird bei NNTP-Zugriffen kein Virencheck vorgenommen, egal, welche Virenscanner vorhanden sind. Wenn es auf "-S" gesetzt ist, wird der schnellere SAVI-Scan verwendet. Default ist "yes".
NNTP_PRINT_URL "no" Wenn auf "no" gesetzt, wird die Pseudo-URL und die Parameter eines NNTP-Zugriffs nur bei Fehlern ins Log geschrieben. Default ist "yes".
SMTP_VIRUS_CHECK "no" Wenn auf "no" gesetzt, wird bei SMTP-Zugriffen (Mail) kein Virencheck vorgenommen, egal, welche Virenscanner vorhanden sind. Default ist "yes".
Modulnamen (MODNAME_N)
Modulname Beschreibung
dummy Pseudo-Netzwerkschnittstelle, /dev/null für Netzwerk, gut zum Testen
hisax Siemens-ISDN-Chipsatz, z.B. Teles, AVM A1
ibmtr IBM-Token-Ring Adapter
ne NE2000-kompatible Netzwerkkarten
Schnittstellentypen (IFNAME_N)
Schnittstellentyp Modulname Beschreibung
dummyN dummy Dummy-Netzwerkschnittstellen
ethN ne alle Ethernet-Schnittstellen
ipppN hisax, ISDN-Schnittstellen
trN ibmtr, oltr Token-Ring-Schnittstellen

Makro-Paketfilter-Regeln

Jeder Eintrag enthält die Adresse und Maske der Quelle, die Schnittstelle der Quelle, die Adresse und Maske des Ziels und die Schnittstelle des Ziels.
Der Eintrag "
10.8.0.0/16:eth0:0.0.0.0/0:ippp0" bedeutet "von 10.8.0.0 mit Netzmaske 255.255.0.0 auf Schnittstelle eth0 zu jedem Rechner auf die Schnittstelle ippp0" . Der Eintrag "10.9.8.7:tr0:10.8.0.0/16:eth1" bedeutet "von Rechner 10.9.8.7 auf Schnittstelle tr0 zum Netzwerk 10.8.0.0 mit Netzmaske 255.255.0.0 auf Schnittstelle eth1". Die Rück-Richtung muß separat angegeben werden. Aus diesen Einträgen werden die iptables-Regeln erzeugt (bis zu sechs je Eintrag).

Zusätzlich ist es möglich, als fünftes Element eine weitere IP-Adresse anzugeben, nämlich die nach außen sichtbare Adresse des Firewall. Bei allen Diensten, die mit Proxies im Internet arbeiten (FTP, HTTP, HTTPS, ...), muß dieses fünfte Element angegeben werden, wenn das Ziel das Internet ist. Wird diese Adresse erst mit einem Einwählvorgang vom Provider zugewiesen, muß man "dynamic" stattdessen angeben.

Es wird bei den Paketfilter-Regeln empfohlen, mit Variablen, die vorher gesetzt werden, zu arbeiten. Dies erhöht die Lesbarkeit. Also statt "10.8.0.0/16" die Variable "LAN_1" in den Paketfilter-Regeln zu verwenden mit der vorherigen Zuweisung "LAN_1="10.8.0.0/16"".

Ziel der Paketfilter-Regeln ist es, nur noch erwartete Pakete im Netzwerk zu haben. Unerwartete Pakete sollen zu einer Meldung im syslog führen. Die Auswertung dieser unerwarteten Pakete liefert einen ersten Hinweis auf einen möglichen Angriff.

Alle Pakete, die im Netzwerk vorkommen, aber nicht mit diesen Makro-Regeln beschreibbar sind, können manuell mit den Dateien iptables.pre und iptables.post erfaßt werden.
 

Mailer-Konfiguration

Die Datei smtproutes enthält Zeilen, die jeweils durch einen Doppelpunkt getrennt sind.
Vor dem Doppelpunkt (dieser Teil darf auch leer sein), ist die Domain angegeben, die betroffen ist, also z.B. leckmich.de. Alle Mails, die an Hosts dieser Domain geschickt werden (also z.B. ich@leckmich.de, du@wer.leckmich.de, ...) werden an den Host ausgeliefert, der hinter dem Doppelpunkt steht. Ist dieser Teil leer, so wird die Mail gemäß DNS-MX-Einträgen direkt ans Ziel geschickt.

Die einfachste Konfiguration von smtproutes ist folglich ":", das bedeutet "liefere alle Mails (nach Prüfung auf Viren) direkt aus". Dies ist die Standard-Konfiguration. Alle Clients müssen in diesem Fall auf den Firewall eingestellt werden.

Ein etwas komplexeres Beispiel :

arbell.de:101.64.50.1
central-service.de:101.64.50.1
:relay1.mail.provider.de

Alle Mails an "arbell.de" und "central-service.de" werden an den Rechner "101.64.50.1" weitergeleitet, alle anderen Mails an den Rechner "relay1.mail.psinet.de". Die Rechner "101.64.50.1"  und "relay1.mail.psinet.de" fungieren als sogenannte Mail-Relays. Diese Konfigurationsdatei ist typisch für einen internen Mail-Server und einen externen Mail-Relay. Ist kein externer Mail-Relay vorhanden, so muß die letzte Zeile ":" lauten, "liefere alle anderen Mails direkt aus". Benutzen Sie soweit möglich IP-Adressen statt Namen, so ist eine Mail-Auslieferung auch bei ausgefallenem DNS möglich.
 

iptables.pre und iptables.post
Diese beiden Dateien dienen dazu, alle Pakete, die im Netzwerk vorkommen, aber durch die Makro-Paketfilter-Regeln bisher nicht abgedeckt wurden, in die erforderlichen Kanäle zu lenken (ignorieren, an Proxies übergeben, umleiten, ...). iptables.pre wird - falls vorhanden - direkt nach der Grundkonfiguration des Paketfiltersystems aber noch vor der ersten Makro-Paketfilter-Regel, iptables.post wird nach der letzten Makro-Paketfilter-Regel direkt vor dem Abschluß der Konfiguration aufgerufen. Sie können jedes beliebige Kommando hineinstellen, gedacht sind diese Dateien aber zum Aufruf von iptables-Kommandos und zum Start von Proxies.