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.
Die Hintergrundinformationen zum DNS-Cache sind in Abschnitt IP-Nummern Auflösung zu finden. Um einen DNS-Cache einzurichten, geht man so vor:
bind installieren.
/etc/named.boot:
cache . root.cache
options query-log
forwarders 192.76.144.66
slave
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
www.suse.de.
Trage
als Nameserver die lokale IP-Nummer ein (192.168.1.1),
siehe Abschnitt
Konfiguration der Namensauflösung.
/etc/rc.config folgendes ein:
START_NAMED=yes
/sbin/init.d/named start/usr/sbin/named
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.
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.
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 &
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"
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.
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.
/root/.fetchmailrc an:
poll mail.provider.de protocol POP3 user asterix
password adam is eva
poll mail.provider.de protocol POP3 user obelix
password josef is maria
fetchmail -v --keep -a
-v führt zu mehr Ausgaben, die Option
--keep sorgt dafür, daß die Mails auf dem Server
zunächst nicht gelöscht werden.
/etc/ppp/ip-up
das Kommando
fetchmail -a >> /var/log/fetchmail
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.
Ü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:
/etc/rc.config konfigurieren:
FROM_HEADER="klaus.franken.de"
SENDMAIL_TYPE="yes"
SENDMAIL_SMARTHOST="mail-n.franken.de"
SENDMAIL_LOCALHOST="localhost franken.b.eunet.de \
glen.home.suse.de klaus.franken.de"
SENDMAIL_RELAY=""
SENDMAIL_ARGS="-bd -om"
SENDMAIL_EXPENSIVE="yes"
SENDMAIL_NOCANONIFY="yes"
Seit Sendmail Version 8 bietet Sendmail ein Makro-Paket,
bei dem die eigentliche Konfigurationsdatei
/etc/sendmail.cf nicht von Hand erstellt
werden muß, sondern über eine Meta-Datei generiert wird.
Das Verzeichnis der Makros ist je nach Distribution
unterschiedlich, üblich ist z.B. /usr/share/sendmail/m4
oder bei SuSE auch /etc/mail.
In der Distribution sollten sich Vorlagen befinden.
Bei SuSE ist eine gut kommentierte
/etc/mail/linux.mc dabei. Bevor man diese
ändert, sollte man in /etc/rc.config mit
SENDMAIL_TYPE="no" das automatische
Generieren abstellen.
Man generiert eine neue Konfigurationsdatei mit:
m4 linux.mc > /etc/sendmail.cf
Weitere Informationen sind in der Datei /etc/mail/README
zu finden.
Bei ausgehenden E-Mails werden abhängig vom lokalen
Benutzernamen die E-Mail-Adressen mit Hilfe der
Datei /etc/mail/genericstable umgeschrieben:
kfr kfr@klaus.franken.de
sandra sandra@klaus.franken.de
sr sandra@klaus.franken.de
Nun kann mal folgende Übungen machen:
root@server.isdnworkshop.de.server.isdnworkshop.de (ws0, ws1, ...).mailq
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'
/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.
Die getestete Version ist 0.9.5.2 von folgendem Server:
space.mit.edu:/pub/davis/slrnEs 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/slangBeim 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 (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
killall -1 inetd
news
angelegt werden, z.B. durch folgenden Eintrag
in /etc/passwd:
news:x:9:13::/var/spool/news:/bin/bash
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.
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.
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:
-I): einkommende Pakete-O): ausgehende Pakete-F): durchgehende Pakete
Der ipfwadm-Aufruf setzt sich zusammen aus:
Incoming (-I), Outgoing (-O) oder
Forwarding (-F)
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.
Soll das Paket akzeptiert werden (accept), oder abgewiesen (deny) werden?
Mögliche Protokolle sind tcp, udp, icmp oder alles (all).
Angabe des Source-IP-Nummern-Bereiches (-S), z.B.
-S 192.168.42.0/24
Angabe des Ziel-IP-Nummern Bereiches (-D)
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.
Mit dem Schalter -W kann die Regel auf ein Netzdevice
beschränkt werden.
Weiterhin gibt es folgende wichtige Optionen:
-f: Setzt das Regelwerk für -I, -O
oder -F zurück.-o: Beim Zutreffen der Regel wird eine Meldung
via syslog in /var/log/messages geschrieben.-m: Masquerading, s.u.-A: Accounting, s.u.-l oder -lne: Listet die Regeln.
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.
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"
/usr/doc/packages/firewall.
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"
/usr/doc/packages/firewall.
Auf das Accounting wollen wir hier nicht weiter eingehen.
Informationen hierzu finden sich in der Manual Page von
ipfwadm unter dem Stichwort -A.
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:
Bei SuSE wird Samba schon aktiviert, wenn das Paket
installiert ist.
Setze daher in /etc/rc.config:
START_SMB="no".
/etc/smb.conf setze z.B. im
global-Abschnitt:
interfaces = 192.168.2.1/24
http://www.suse.de/Support/sdb/isdn_samba.html