Inhalt

10. Konfiguration der Internet-Dienste

Voraussetzung für diesen Abschnitt des Dokumentes ist, daß die Internet-Verbindung über die Dial-On-Demand Wählverbindung und das Routing bereits funktioniert. Jetzt sollen je nach Bedarf weitere Internetdienste eingerichtet werden.

10.1 DNS-Cache

Die Hintergrundinformationen zum DNS-Cache sind in Abschnitt IP-Nummern Auflösung zu finden. Um einen DNS-Cache einzurichten, geht man so vor:

  1. Paket bind installieren.
  2. Dann editiere man /etc/named.boot: 

    cache . root.cache
options query-log
forwarders 192.76.144.66
slave
    Bei forwarders werden ein oder mehrere IP-Nummern der Nameserver eingetragen. Die Option slave steuert das Verhalten, wenn der Nameserver selbst noch keine Antwort hat. Ohne die Option müßte jetzt der eigene Nameserver die Anfrage auflösen, was recht aufwendig sein kann. Mit dieser empfohlenen Option wird dem Forwarder gesagt, daß er die Anfrage auflösen soll. Bei der nächsten Anfrage hat er diese dann im Cache.

    Zur Diagnose ist zu empfehlen, noch die Zeile options query-log einzufügen; es werden dann über Syslog, also in /var/log/messages, alle Anfragen an den Nameserver protokolliert. Dadurch lassen sich einfach die »Übeltäter« im lokalen Netz finden. Beispiel: 

    named[232]: XX /192.168.1.2/www.suse.de/A
    Der Rechner 192.168.1.2 fragt nach dem A-Record für www.suse.de.
  3. Wir benutzen uns selbst als Nameserver.

    Trage als Nameserver die lokale IP-Nummer ein (192.168.1.1), siehe Abschnitt Konfiguration der Namensauflösung.

  4. Nun muß der eigene Nameserver gestartet werden.
  5. Nun sollte getestet werden, ob alles funktioniert: 
    nslookup www.suse.de

    Als Ergebnis wird eine Verbindung aufgebaut, in messages wird die Anfrage protokolliert und die IP-Nummer wird aufgelöst.

    Eine Wiederholung der Anfrage, wenn die Verbindung nicht besteht, darf keine Verbindung aufbauen, die Anfrage muß sofort beantwortet werden.

10.2 Squid

Squid ist ein WWW- und FTP-Proxy. Der Vorteil eines Proxies liegt nicht nur darin, Anfragen für mehrere Benutzer zu cachen, sondern auch darin, daß die Clientrechner im lokalen Netz nicht unbedingt echten Internetzugriff über Masquerading haben müssen, was die Übersicht und die Sicherheit erhöht.

Squid hat eine Vielzahl von Optionen und Features. Die mitgelieferte Beispielkonfiguration in /etc/squid.conf ist sehr gut dokumentiert und funktioniert zunächst einmal ohne Änderung.

Starten von Squid

Bei SuSE wird über die rc.config-Variable START_SQUID gesteuert, ob Squid gleich beim Systemstart hochgefahren werden soll (über /sbin/init.d/squid).

Manuell kann man squid z.B. durch 

/usr/sbin/squid -sYD >> /var/squid/squid.out 2>&1 &
starten.

Vor dem ersten Start muß das Cache-Directory initialisiert werden; dies sollte als Benutzer squid geschehen. Als root kann man einfach folgendes aufrufen: 

su squid -c "/usr/sbin/squid -z"

Clients anpassen

Die WWW-Browser müssen konfiguriert werden, damit Sie den Proxy ansprechen. Bei Netscape gibt es die Maske Options/Network Preferences, Proxies/Manual Proxy Configuration. In der Maske gibt man jeweils für FTP und HTTP-Proxy die IP-Nummer des IZG im lokalen Netz ein und als Portnummer 3128 oder was in /etc/squid.conf definiert ist.

Zusätzlich sollte man noch im Feld No Proxy for eintragen, für welche Domains nicht über den Proxy gegangen, sondern direkt auf den WWW-Server zugegriffen werden soll, z.B.: localhost isdnworkshop.de.

10.3 Fetchmail

Das Programm fetchmail (Paket pop) eignet sich dazu, Mails über das POP3-Protokoll vom Provider abzuholen.

Das Abholen kann auch als normaler User durchgeführt werden, wir holen hier die Mails als root ab, dadurch läßt sich der Vorgang besser automatisieren. Nach dem Abholen werden die Mails dem lokalen Sendmail übergeben und zugestellt.

Der Mailserver sei mail.provider.de. Es gibt zwei Benutzer asterix und obelix, die auf dem lokalen Rechner eva und maria heissen. Als Paßwörter werden auf dem Mailserver adam und josef benutzt.

Mehr Informationen findet man hier:

http://www.suse.de/Support/sdb/fetchmail.html

Übung: Auf dem Server liegen Mails für jede Workstation bereit. Richte fetchmail so ein, daß bei jedem Verbindungsaufbau Mails abgeholt werden. Prüfe die lokale Zustellung.

10.4 Sendmail

Über Sendmail kann man dicke Bücher schreiben, siehe Abschnitt Sendmail.

Das SuSE Paket sendmail ist für diese Zwecke hier bestens gerüstet. Besonders wichtig ist hier zum einem, daß die Absenderadresse richtig gesetzt wird, denn die lokale Domain könnte ja zur E-Mail-Adresse beim Provider unterschiedlich sein. Zum anderen sollen lokale E-Mails sofort zugestellt werden, Mails, die über die Wählleitung verschickt werden müssen, sollen dagegen in eine Warteschlange gestellt werden, ohne daß eine Verbindung aufgebaut wird.

Wie immer gibt es mehrere Wege:

Nun kann mal folgende Übungen machen:

10.5 News

Online News kann man schon jetzt sehr einfach lesen. Als News-Server gibt man den entsprechenden Server des ISPs an. Dazu muß man für die meisten News-Reader die Variable NNTPSERVER setzen: 

export NNTPSERVER='klaus.franken.de'
Dies sollte man systemweit in der /etc/profile setzen.

Wünschenswert ist natürlich, News offline zu lesen und entweder bei Bedarf zu holen bzw. zu verschicken oder dieses per Cron-Job z.B. jede Nacht durchführen zu lassen.

Die Installation eines eigenen News-Servers ist recht aufwendig, es bieten sich CNews oder INN an. Siehe dazu auch das News HOWTO.

Ein eigener News-Server ist aber eigentlich nur dann notwendig, wenn man auf diesem selber Newsgruppen einrichten möchte. Will man das nicht, sind CNews und INN vollkommen überdimensioniert; deshalb möchte ich hier zwei andere Möglichkeiten vorstellen.

Zwei Pakete bieten sich an: Leafnode und slrn. Beide sind einfach einzurichten und zu warten und reichen für ein mittleres Newsaufkommen vollkommen aus.

slrn ist eigentlich ein eigener textorientierter, sehr flexibler und schneller News-Reader und bietet ein eigenes Programm slrnpull, das die News abholt und in ein eigenes Spool-Verzeichnis stellt, auf welches direkt von slrn zugegriffen werden kann. Es existieren allerdings auch einige Einschränkungen: es kann kein anderes News-Programm darauf zugreifen; es kann nicht über Netzwerk auf die News zugegriffen werden, da kein lokaler News-Server läuft. Eventuell geht das jedoch über NFS.

Leafnode stellt dagegen einen eigenen News-Server zur Verfügung, braucht aber insgesamt mehr Ressourcen. Der Trick bei Leafnode ist der, daß sich der Server quasi selbst konfiguriert: wird von einem Client auf eine Gruppe zugegriffen, wird diese automatisch abonniert und ist beim nächsten Abgleich vorhanden; wird dagegen längere Zeit nicht mehr auf eine Gruppe zugegriffen, wird diese automatisch gelöscht. Man kann Leafnode also in einem kleineren Netz mit mehreren Lesern trotzdem nahezu unbeaufsichtigt laufen lassen.

Beide Programme arbeiten sehr gut in dieser Dial-On-Demand-Umgebung. Zugriffe auf den News-Server beim Provider werden nur auf Wunsch, nie aber automatisch ausgeführt.

slrn installieren und konfigurieren

Die getestete Version ist 0.9.5.2 von folgendem Server:

space.mit.edu:/pub/davis/slrn

Es wird die slang-Bibliothek ab Version 1.0.3 benötigt. Bei SuSE 5.2 ist noch die Version 0.99.38 dabei. Zu bekommen ist die Bibliothek unter

space.mit.edu:/pub/davis/slang

Beim Kompilieren darf nicht vergessen werden, auch make slrnpull einzugeben. Die Binaries werden z.B. nach /usr/local/bin kopiert oder es wird folgendes ausgeführt: 

install -m 755 -o root -g root src/objs/slrn \
        /usr/local/bin
install -m 755 -o root -g root src/objs/slrnpull \
        /usr/local/bin
install -d /usr/doc/packages/slrn -m 755 \
        -o root -g root
install -m 644 -o root -g root doc/* \
        /usr/doc/packages/slrn
install -m 644 -o root -g root COPYRIGHT \
        /usr/doc/packages/slrn
install -m 644 -o root -g root COPYING \
        /usr/doc/packages/slrn
install -m 644 -o root -g root README \
        /usr/doc/packages/slrn
install -m 644 -o root -g root changes.txt \
        /usr/doc/packages/slrn
install -m 644 -o root -g root doc/slrn.1 \
        /usr/local/man/man1
install -d /usr/doc/packages/slrn/slrnpull \
        -m 755 -o root -g root
install -m 644 -o root -g root slrnpull/* \
        /usr/doc/packages/slrn/slrnpull

Dann wird das Spool-Verzeichnis angelegt und die Config-Datei erstellt: 

mkdir /var/spool/slrnpull
cd /var/spool/slrnpull
cp /src/slrn/slrnpull/slrnpull.conf .

In slrnpull.conf könnte z.B. folgendes stehen: 

default                0   14
de.alt.comm.isdn4linux

Jetzt muß noch der News-Reader auf diesen Spool-Pfad konfiguriert werden. Dazu fügt man folgendes in ~/.slrnrc ein bzw. paßt die Datei entsprechend an: 

%%% Spool
set spool_inn_root   "/var/spool/slrnpull"
set spool_root       "/var/spool/slrnpull/news"
set spool_nov_root   "/var/spool/slrnpull/news"
set use_slrnpull 1
set read_active 1
set server_object    "spool"
hostname "klaus.franken.de"
set username "kfr"

Das Abholen und Verschicken eigener News und das Löschen alter Artikel geschieht mit einem einzigen Kommando, das als root ausgeführt wird: 

slrnpull -d /var/spool/slrnpull -h news.franken.de

Beim ersten Mal dauert das natürlich sehr lange und sollte daher manuell ausgeführt werden. Im Betrieb kann man das über einen Croneintrag oder in /etc/ppp/ip-up bei jedem Verbindungsaufbau durchführen lassen.

Beim manuellen Start gibt slrnpull Meldungen auf der Console aus; wird es im Hintergrund gestartet, loggt es nach /var/spool/slrnpull/log. Aber Achtung, diese Datei kann groß werden.

Leafnode installieren und konfigurieren

Leafnode (Version 1.4) gibt es auf

ftp.troll.no:/pub/freebies/

Die mitgelieferten Dateien README und INSTALL beschreiben die Installation sehr gut.

Im folgenden Beispiel werden die Binaries leafnode, fetch und texpire nach /usr/local/bin installiert; der Makefile muß dafür angepaßt werden.

Zunächst wird der NNTP-Server leafnode in der /etc/inetd.conf durch folgende Zeile aktiviert: 

nntp  stream  tcp  nowait  news  /usr/sbin/tcpd  /usr/local/bin/leafnode
Danach muß 
killall -1 inetd
ausgeführt werden. Als nächstes muß ein User und eine Gruppe news angelegt werden, z.B. durch folgenden Eintrag in /etc/passwd: 
news:x:9:13::/var/spool/news:/bin/bash
Alle Arbeiten müssen dann als User news ausgeführt werden.

Im Verzeichnis /usr/lib/leafnode wurde bei der Installation eine Beispiel-Datei angelegt, die man kopieren und anpassen muß: 

su - news
cd /usr/lib/leafnode
cp config.example config

Die Datei ist kommentiert, hier arbeiten folgende Einträge: 

server = news.franken.de
expire = 20
maxcount = 1000

Jetzt muß man dafür sorgen, daß das Programm texpire regelmässig aufgerufen wird, ansonsten werden alte News nicht wieder gelöscht; hier arbeitet folgender Crontab-Eintrag vom Benutzer root jede Nacht um 5:42 und löscht die alten Artikel: 

42  5 * * * su news -c texpire

Durch das Kommando fetch oder besser fetch -v wird nun der Newsserver initialisiert, aber es sind keine Gruppen verfügbar.

In dem man jetzt einmalig durch einen News-Reader auf diesen Newsserver und auf die interessanten Gruppen zugreift, die natürlich alle mit der Anzahl 0 angezeigt werden, werden die Gruppen abonniert. Beim nächsten Aufruf von fetch werden dann die Artikel geholt. Auch hier kann man fetch via Crontab regelmässig oder durch einen Eintrag in /etc/ppp/ip-up aufrufen.

Ein Problem ist allerdings, daß man keinen direkten Einfluß darauf hat, welche Gruppen abonniert werden. Es sei denn, daß man vor dem Aufruf von fetch das Verzeichnis /home/opt/spool/news/interesting.groups »aufräumt«.

Die Ausgabe von fetch sollte beachtet werden; abgelehnte eigene Postings werden nirgends abgespeichert, sondern einfach gelöscht.

10.6 Firewall

Firewalls sind ein heikles Thema. Der Autor übernimmt keine Garantie für die Richtigkeit der hier gemachten Angaben. Wer ein wirklich sicheres System benötigt, sollte zumindest das Firewall HOWTO lesen oder einen Experten dafür beauftragen. Über Firewalls kann man dicke Bücher schreiben, siehe Abschnitt Firewall.

Die einfachste aber wirkungsvolle Methode ist die Benutzung eines Paketfilters. Diese Methode wird direkt vom Linux-Kernel unterstützt und über das Kommando ipfwadm (IP-FireWall ADMinistration) konfiguriert.

Was ist ein Paketfilter?

Jedes IP-Paket, das vom Kernel behandelt wird, wird nach einer Regelliste untersucht und entweder akzeptiert oder abgelehnt.

Es werden drei verschiedene Listen geführt:

  1. Incoming (Schalter -I): einkommende Pakete
  2. Outgoing (Schalter -O): ausgehende Pakete
  3. Forwarding (Schalter -F): durchgehende Pakete

Wie gibt man eine Firewall-Regel an?

Der ipfwadm-Aufruf setzt sich zusammen aus:

Wann?

Incoming (-I), Outgoing (-O) oder Forwarding (-F)

Wohin?

Man kann neue Regeln an den Anfang der Liste (-i) oder an das Ende der Liste (-a) setzen. Die Regeln werden immer von vorne nach hinten interpretiert, bei der ersten passenden Regel wird nicht weitergesucht.

Was tun?

Soll das Paket akzeptiert werden (accept), oder abgewiesen (deny) werden?

Protokoll?

Mögliche Protokolle sind tcp, udp, icmp oder alles (all).

Quell-IP?

Angabe des Source-IP-Nummern-Bereiches (-S), z.B. -S 192.168.42.0/24

Ziel-IP?

Angabe des Ziel-IP-Nummern Bereiches (-D)

Port?

Meist wird direkt hinter der Ziel-IP-Nummer noch der Ziel-Port mit angegeben, dies kann der numerische Wert oder das Alias, wie in /etc/services definiert, sein.

Wo?

Mit dem Schalter -W kann die Regel auf ein Netzdevice beschränkt werden.

Weiterhin gibt es folgende wichtige Optionen:

Was für Regeln brauche ich mindestens?

Eines der größten Sicherheitslöcher ist das sogenannte Spoofing. Darunter versteht man, daß ein eigentlich fremder Rechner behauptet, eine IP-Nummer aus dem eigenen, sicheren Netz zu haben. Daher müssen als erstes Regeln definiert werden, die verhindern, daß eigene IP-Nummern aus dem unsicheren Netz hereinkommen können.

Als nächstes sollte man alle Zugriffe von außen verbieten und nur bei Bedarf die benötigten Dienste wie Mail oder WWW freischalten.

Ein einfacher Firewall

Das lokale Ethernet ist auf 192.168.42.0 konfiguriert. Wir erwarten IP-Nummern aus dem Bereich 193.110.3.0/24 zugewiesen zu bekommen, wobei der PtP-Partner nicht aus diesem Bereich ist, da ansonsten seine Pakete auch abgewiesen werden würden. 

# Spoofing verhindern:
/sbin/ipfwadm -I -a deny -o -P all -S 192.168.42.0/24 \ 
              -D 192.168.42.0/24 -W ippp0
/sbin/ipfwadm -I -a deny -o -P all -S 192.168.42.0/24 \
              -D 193.110.3.0/24 -W ippp0
/sbin/ipfwadm -I -a deny -o -P all -S 193.110.3.0/24 \
              -D 192.168.42.0/24 -W ippp0
/sbin/ipfwadm -I -a deny -o -P all -S 193.110.3.0/24 \
              -D 193.110.3.0/24 -W ippp0


# Zugriffe von überall auf den Mail-Server (Port 25) 
# erlauben:
/sbin/ipfwadm -I -a accept -P tcp -S 0/0 \
              -D 192.168.42.1 25 -W ippp0

# Zugriffe von überall auf den DNS-Server (Port 53) 
# erlauben:
/sbin/ipfwadm -I -a accept -P tcp -S 0/0 \
              -D 192.168.42.1 53 -W ippp0

# sonst alles verbieten (getrennt für Protokoll tcp 
# und udp)
/sbin/ipfwadm -I -a deny -o -P tcp -S 0/0 \
              -D 192.168.42.0/24 1:1023 -W ippp0 
/sbin/ipfwadm -I -a deny -o -P tcp -S 0/0 \
              -D 193.110.3.0/24 1:1023 -W ippp0

/sbin/ipfwadm -I -a deny -o -P udp -S 0/0 \
              -D 192.168.42.0/24 1:1023 -W ippp0
/sbin/ipfwadm -I -a deny -o -P udp -S 0/0 \
              -D 193.110.3.0/24 1:1023 -W ippp0

Bei SuSE läßt sich obiges Beispiel auch in der /etc/rc.config einstellen: 

FW_START="yes"
FW_LOCALNETS="192.168.42.0/24 193.110.3.0/24"
FW_MAILSERVER="192.168.42.1"
FW_DNSSERVER="192.168.42.1"
FW_WORLD_DEV="ippp0"
FW_LOG_ACCEPT="no"
FW_LOG_DENY="yes"
FW_TCP_LOCKED_PORTS="1:1023"
FW_UDP_LOCKED_PORTS="1:1023"
Siehe auch /usr/doc/packages/firewall.

10.7 Masquerading

Masquerading, auch Network Address Translation genannt, braucht man dann, wenn man ein internes Netz mit privaten IP-Nummern hat, vom ISP aber nur eine offizielle IP-Nummer bekommt und dieses vielleicht sogar dynamisch geschieht. Die IP-Pakete werden beim Rausschicken auf der Internetleitung umgeschrieben und mit der eigenen offiziellen IP-Nummer versehen. Umgekehrt wird eine Tabelle der offenen Verbindungen gehalten, damit einkommende Pakete wieder dem ursprünglichen Absender zugestellt werden können.

Hat man sich mit dem Firewall bzw. Paketfilter via ipfwadm vertraut gemacht, ist Masquerading fast trivial, denn es findet an derselben Stelle statt und wird fast genauso konfiguriert, es wird lediglich der Schalter -m dazugegeben.

Sollen z.B. Pakete aus dem internen Netzwerk (192.168.42.0/24), die zum Provider (Device ippp0) verschickt werden, mit der jeweils gültigen IP-Nummer maskiert werden, geht man so vor: Es wird einer Forwarding-Rule der Schalter -m mitgegeben: 

/sbin/ipfwadm -F -a accept -P all -S 192.168.42.0/24 \
              -D 0/0 -m -W ippp0

Bei manchen Internet-Diensten wie z.B. FTP wird nicht nur ein Socket geöffnet, sondern auch ein zweiter für die Datenübertragung, die der Server zum Client aufbaut. Da der Client aber selbst aufgrund seiner privaten IP-Nummer nicht erreichbar ist und der Server die Verbindung zum falschen Rechner (IZG) aufbaut, klappt diese Methode ohne weiteres Wissen über die speziellen Eigenheiten des entsprechenden Protokolls nicht. Abhilfe dafür schaffen spezielle Routinen, die auch dafür remaskieren können. Diese werden durch Kernel-Module geladen: 

/sbin/insmod ip_masq_cuseeme
/sbin/insmod ip_masq_ftp
/sbin/insmod ip_masq_irc
/sbin/insmod ip_masq_quake
/sbin/insmod ip_masq_raudio
/sbin/insmod ip_masq_vdolive

Bei SuSE läßt sich obiges Beispiel auch in der /etc/rc.config einstellen: 

MSQ_START="yes"
MSQ_NETWORKS="192.168.42.0/24"
MSQ_DEV="ippp0"
MSQ_MODULES="ip_masq_cuseeme ip_masq_ftp ip_masq_irc \
             ip_masq_quake ip_masq_raudio ip_masq_vdolive"
Siehe auch /usr/doc/packages/firewall.

10.8 Accounting

Auf das Accounting wollen wir hier nicht weiter eingehen. Informationen hierzu finden sich in der Manual Page von ipfwadm unter dem Stichwort -A.

10.9 Samba

Samba ist ein File- und Druckerserver für das unter Windows benutzte SMB-Protokoll. Das Thema gehört also gar nicht hier her? Doch, denn Samba kann in unserem Fall Probleme machen.

Beim SMB-Protokoll wird sehr viel mit Broadcasts gearbeitet; die Rechner schicken sich ständig, auch wenn eigentlich keine Aktionen ausgeführt werden, Nachrichten zu. Der Samba-Server wird meist so ausgeliefert, daß dieser alle verwendendbaren Netzdevices benutzt und dorthin Nachrichten schickt, also auch an das ippp0-Device. Das führt dann dazu, daß ständig Verbindungen zum Provider aufgebaut werden.

Lösen kann man das Problem so:

  1. Starte Samba nur, wenn Du es auch brauchst.

    Bei SuSE wird Samba schon aktiviert, wenn das Paket installiert ist. Setze daher in /etc/rc.config: START_SMB="no".

  2. Wenn Du es brauchst, sage Samba, welche Devices benutzt werden dürfen. In der /etc/smb.conf setze z.B. im global-Abschnitt: 
    interfaces = 192.168.2.1/24
    Mehr Infos gibt es hier:
    http://www.suse.de/Support/sdb/isdn_samba.html

Inhalt