[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ 16 ] [ 17 ] [ 18 ]

Kapitel 11


Anzahl der Absätze: 623

Project-Id-Version: 0 POT-Creation-Date: 2012-05-09T20:00:20 PO-Revision-Date: 2012-05-09T20:00:20 Last-Translator: Automatically generated Language-Team: None MIME-Version: 1.0 Content-Type: application/x-publican; charset=UTF-8 Content-Transfer-Encoding: 8bit


Postfix


Apache


NFS


Samba


Squid


OpenLDAP


Netzwerkdienste: Postfix, Apache, NFS, Samba, Squid, LDAP


Netzwerkdienste sind die Programme, mit denen Benutzer direkt in ihrer täglichen Arbeit interagiert. Sie sind die Spitze des Eisbergs des Informationssystems und genau davon handelt dieses Kapitel; die Teile im Hintergrund, auf denen sie basieren, ist die Infrastruktur, die wir bereits besprochen haben.


Mailserver


Die Falcot Corp. Administratoren wählten Postfix als elektronischen Mailserver wegen seiner Zuverlässigkeit und seiner leichten Konfigurierbarkeit. So erzwingt sein Design, dass jede Aufgabe in einem Prozess mit dem geringst möglichen Satz an Berechtigungen umgesetzt wird, was eine gute Schutzmaßnahme gegen Sicherheitsprobleme ist.


MailElectronisch


Postfix


ALTERNATIVE Der Exim4-Server


Exim


Debian verwendet Exim4 als Standard E-Mail-Server (weshalb die Erstinstallation Exim4 enthält). Die Konfiguration wird durch ein separates Packet bereitgestellt, exim4-config, und wird automatisch aufgrund der Antworten auf eine Anzahl von Debconf-Fragen angepasst, in ähnlicher Weise wie bei den vom Paket postfix gestellten Fragen.


Die Konfiguration kann sich entweder in einer einzelnen Datei (/etc/exim4/exim4.conf.template) befinden oder verteilt über eine Anzahl von Konfigurationsausschnitten, die unter /etc/exim4/conf.d/ gespeichert sind. In beiden Fällen werden die Dateien nicht direkt von Exim4 benutzt, sondern werden in die maßgebliche Datei /etc/exim4/exim4.conf.template aggregiert oder geparst (die in die Datei /var/lib/exim4/config.autogenerated kompiliert wird, wenn Exim4 startet). update-exim4.conf ermöglicht es, einige Markierungen der Konfigurationsausschnitte durch Daten zu ersetzen, die den Antworten auf die Debconf-Fragen entnommen sind.


Die Syntax der Exim4-Konfigurationsdatei hat ihre Besonderheiten und Lernphase; sobald jedoch diese Besonderheiten verstanden worden sind, ist Exim4 ein sehr vollständiger und leistungsstarker E-Mail-Server, wie durch Dutzende von Dokumentationsseiten belegt wird.


Postfix installieren


Das Paket postfix enthält den Kern des SMTP-Daemons. Andere Pakete (wie postfix-ldap und postfix-pgsql) fügen weitere Funktionsfähigkeiten zu Postfix hinzu, einschließlich des Zugangs zu Zuordnungsdatenbanken. Sie sollten sie nur installieren, wenn Sie wissen, dass Sie sie benötigen.


ZURÜCK ZU DEN GRUNDLAGEN SMTP


SMTP


Simple Mail Transfer Protocol


ServerSMTP


SMTP (Simple Mail Transfer Protocol) ist das von Mailservern verwendete Protokoll zum Austausch und zur Zustellung von E-Mails.


Während der Installation des Pakets werden mehrere Debconf-Fragen gestellt. Die Antworten ermöglichen es, eine erste Version der Konfigurationsdatei /etc/postfix/main.cf zu erstellen.


Die erste Frage bezieht sich auf die Art der Einrichtung. Nur zwei der vorgeschlagenen Antworten sind im Falle eines mit dem Internet verbundenen Servers relevant, "Internet site" und "Internet with smarthost". Die erste ist für einen Server angebracht, der eingehende E-Mails empfängt und ausgehende E-Mails direkt an ihre Empfänger verschickt, und ist daher für den Falot Corp. Fall gut geeignet. Die zweite ist für einen Server angebracht, der eingehende E-Mails normal empfängt, aber ausgehende E-Mails über einen zwischengeschalteten SMTP-Server - den "smarthost" - statt direkt an den Server des Empfängers verschickt. Dies ist meistens für Personen mit einer dynamischen IP-Adresse sinnvoll, da viele E-Mail-Server Nachrichten, die direkt von einer derartigen IP-Adresse kommen, zurückweisen. In diesem Fall wird der Smarthost gewöhnlich der SMTP-Server des ISPs sein, der bereits dafür konfiguriert ist, E-Mails zu akzeptieren, die von den Kunden des ISP kommen, und sie in geeigneter Weise weiterzuleiten. Diese Einrichtung (mit einem Smarthost) ist auch für Server relevant, die nicht ständig mit dem Internet verbunden sind, da es so nicht erforderlich ist, eine Warteschlange von nicht zustellbaren Nachrichten zu verwalten, für die später ein neuer Zustellversuch unternommen werden muss.


WÖRTERVERZEICHNIS ISP


ISP, Internet Service Provider


ISP ist die Abkürzung für "Internet Service Provider". Damit ist eine Organisation, in vielen Fällen ein kommerzielles Unternehmen, gemeint, die Internetverbindungen und hiermit zusammenhängende grundlegende Dienste (E-Mail, Nachrichten und so weiter) bereitstellt.


Die zweite Frage bezieht sich auf die vollständige Bezeichnung des Rechners, die zur Erstellung von E-Mail-Adressen aus einem lokalen Benutzernamen verwendet wird; die vollständige Bezeichnung des Rechners wird zu dem Teil hinter dem at-Zeichen ("@"). Im Fall von Falcot sollte die Antwort mail.falcot.com lauten. Dies ist die einzige standardmäßig gestellte Frage, aber die Konfiguierung, zu der sie führt, ist für die Bedürfnisse von Falcot nicht vollständig genug, weshalb die Administratoren dpkg-reconfigure postfix aufrufen, um so weitere Parameter einstellen zu können.


Eine der zusätzlichen Fragen verlangt nach allen Domain-Namen, die mit diesem Rechner in Zusammenhang stehen. Die Standardliste umfasst seine vollständige Bezeichnung sowie einige Synonyme für localhost, jedoch muss die Hauptdomain falcot.com von Hand hinzugefügt werden. Allgemeiner gesagt, sollte diese Frage normalerweise mit allen Domain-Namen beantwortet werden, für die dieser Rechner als MX-Server dienen soll; mit anderen Worten, allen Domain-Namen, für die der DNS angibt, dass dieser Rechner E-Mails akzeptieren wird. Diese Information geht in die Variable mydestination der Hauptkonfigurationsdatei von Postfix, /etc/postfix/main.cf, ein.


ServerMX


MXServer


Rolle des DNS-MX -Eintrags beim Versenden einer E-Mail


EXTRA Die MX-Einträge abfragen


Wenn im DNS kein MX-Eintrag für eine Domain vorliegt, wird der E-Mail-Server versuchen, die Nachrichten an den Host selbst unter Verwendung des passenden A-Eintrags (oder AAAA bei IPv6) zu schicken.


In manchen Fällen kann die Installation auch fragen, welchen Netzwerken es erlaubt sein soll, E-Mails über den Rechner zu verschicken. In seiner Standard-Konfiguration akzeptiert Postfix nur E-Mails, die von diesem Rechner selbst kommen; das lokale Netzwerk wird gewöhnlich hinzugefügt. Die Falcot Corp. Administratoren haben 192.168.0.0/16 zur Standardantwort hinzugefügt. Falls die Frage nicht gestellt wird, ist mynetworks die relevante Variable in der Konfigurationsdatei, wie in unten stehendem Beispiel zu sehen ist.


Lokale E-Mail kann auch durch procmail zugestellt werden. Dieses Programm ermöglicht es Benutzern, ihre ankommende E-Mail nach Regeln, die in der Datei ~/.procmailrc gespeichert sind, zu sortieren.


procmail


E-Mailfiltern


E-Mail filtern


Nach diesem ersten Schritt, erhielten die Administratoren die folgende Konfigurationsdatei; sie wird als Ausgangspunkt verwendet, um im nächsten Abschnitte einige weitere Funktionsmerkmale hinzuzufügen.


Anfängliche /etc/postfix/main.cf Datei


# See /usr/share/postfix/main.cf.dist for a commented, more complete version # Debian specific: Specifying a file name will cause the first # line of that file to be used as the name. The Debian default # is /etc/mailname. #myorigin = /etc/mailname smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU) biff = no # appending .domain is the MUA's job. append_dot_mydomain = no # Uncomment the next line to generate "delayed mail" warnings #delay_warning_time = 4h # TLS parameters smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key smtpd_use_tls=yes smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache # See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for # information on enabling SSL in the smtp client. myhostname = mail.falcot.com alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases myorigin = /etc/mailname mydestination = mail.falcot.com, falcot.com, localhost, localhost.localdomain relayhost = mynetworks = 127.0.0.0/8 192.168.0.0/16 mailbox_command = procmail -a "$EXTENSION" mailbox_size_limit = 0 recipient_delimiter = + inet_interfaces = all inet_protocols = all


SICHERHEIT Schlangenöl SSL-Zertifikate


Die Schlangenöl-Zertifikate sind, wie die Schlangenöl-"Medizin", die früher von gewissenlosen Quacksalbern verkauft wurde, völlig wertlos, da sie in ähnlicher Weise auf allen Debian-Systemen erzeugt werden, die denselben "privaten" Teil enthalten. Sie sollten nur zu Testzwecken benutzt werden, während der Normalbetrieb wirkliche Zertifikate verwenden muss; diese können mit dem unter beschriebenen Verfahren erstellt werden.


Virtuelle Domains konfigurieren


Domainvirtuell


Virtuelle Domain


Der Mailserver kann außer E-Mails, die an die Hauptdomain addressiert sind, auch solche an andere Domains gerichtete entgegennehmen. Diese werden virtuelle Domains genannt. In den meisten Fällen, in denen dies vorkommt, sind die E-Mails nicht eigentlich für die lokalen Benutzer bestimmt. Postfix stellt für die Verwendung virtueller Domains zwei interessante Leistungsmerkmale bereit.


VORSICHT Virtuelle und autorisierte Domains


Auf keine der virtuellen Domains darf in der Variablen mydestination verwiesen werden; diese Variable enthält nur die Namen der direkt dem Rechner und seinen lokalen Benutzern zugeordneten "autorisierten" Domains.


Virtuelle Alias-Domains


Alias


Aliasvirtuelle Domain


Eine virtuelle Alias-Domain enhält nur Aliasse, d. h. Adressen, die nur E-Mails an andere Adressen weiterleiten.


Eine derartige Domain wird durch das Hinzufügen ihres Namens zur Variablen virtual_alias_domains aktiviert und das Eintragen eines Verweises auf eine Adressen-Bezugsdatei in die Variable virtual_alias_maps.


In der Datei /etc/postfix/main.cf hinzuzufügende Anweisungen


virtual_alias_domains = falcotsbrand.tm.fr virtual_alias_maps = hash:/etc/postfix/virtual


Die Datei /etc/postfix/virtual stellt Zuordnungen in einer recht geradlinigen Syntax dar: jede Zeile enthält zwei durch Leerzeichen getrennte Felder; das erste Feld ist der Alias-Name, das zweite eine Liste der E-Mail-Adressen, zu denen er weiterleitet. Die spezielle Syntax @domain.tm.fr deckt alle verbleibenden Aliasse in der Domain ab.


Beispiel der Datei /etc/postfix/virtual


webmaster@falcotsbrand.tm.fr jean@falcot.com contact@falcotsbrand.tm.fr laure@falcot.com, sophie@falcot.com # The alias below is generic and covers all addresses within # the falcotsbrand.tm.fr domain not otherwise covered by this file. # These addresses forward email to the same user name in the # falcot.com domain. @falcotsbrand.tm.fr @falcot.com


Virtuelle Mailbox-Domains


VORSICHT Kombinierte virtuelle Domain?


Postfix erlaubt es nicht, dieselbe Domain sowohl in virtual_alias_domains als auch in virtual_mailbox_domains zu verwenden. Jedoch ist jede Domain in virtual_mailbox_domains stillschweigend auch in virtual_alias_domains einbezogen, wodurch es möglich wird, Aliasse und Postfächer in einer virtuellen Domain zu vermischen.


Postfach, virtuelle Domain


An ein virtuelles Postfach adressierte Nachrichten werden in Postfächern gespeichert, die keinem lokalen Systembenutzer zugeordnet sind.


Um eine virtuelle Postfach-Domain zu aktivieren, ist es erforderlich, diese Domain in der Variablen virtual_mailbox_domains zu benennen und einen Verweis auf eine Mailbox-Bezugsdatei in virtual_mailbox_maps einzutragen. Der Parameter virtual_mailbox_base enthält das Verzeichnis, in dem die Postfächer gespeichert werden.


Der Paramater virtual_uid_maps (beziehungsweise virtual_gid_maps) verweist auf die Datei, die den Bezug enthält zwischen der E-Mail-Adresse und dem Systembenutzer (beziehungsweise der Gruppe), dem das entsprechende Postfach "gehört". Die Syntax, um alle Postfächer, die demselben Benutzer / derselben Gruppe gehören, zu erhalten, ist static:5000.


virtual_mailbox_domains = falcot.org virtual_mailbox_maps = hash:/etc/postfix/vmailbox virtual_mailbox_base = /var/mail/vhosts


Auch die Syntax der Datei /etc/postfix/vmailbox ist recht einfach: zwei durch Leerzeichen getrennte Felder. Das erste Feld ist eine E-Mail-Adresse innerhalb einer der virtuellen Domains, und das zweite ist der Ort des dazugehörigen Postfachs (relativ zum Verzeichnis, das in virtual_mailbox_base angegeben ist). Falls die Bezeichnung des Postfachs mit einem Schrägstrich (/) endet, werden die E-Mails im maildir-Format gespeichert; anderenfalls wird das traditionelle mbox-Format benutzt. Das maildir-Format verwendet ein ganzes Verzeichnis zur Speicherung eines Postfachs, wobei jede individuelle Nachricht in einer eigenen Datei gespeichert wird. Dagegen ist beim mbox-Format das gesamte Postfach in einer einzigen Datei gespeichert, wobei jede Zeile, die mit “From ” beginnt (From gefolgt von einem Leerzeichen), den Beginn einer neuen Nachricht anzeigt.


Die Datei /etc/postfix/vmailbox


# Jeans E-Mail ist als maildir gespeichert mit # einer Datei je E-Mail in einem besonderen Verzeichnis jean@falcot.org falcot.org/jean/ # Sophies E-Mail ist in einer traditionellen "mbox"-Datei gespeichert # mit allen Mails zu einer einzigen Datei verkettet sophie@falcot.org falcot.org/sophie


Einschränkungen beim Empfangen und Senden


Die wachsende Zahl unerwünschter Massen-E-Mails (spams) macht es erforderlich, bei der Entscheidung, welche E-Mails ein Server annehmen sollte, in zunehmendem Maße strikt zu sein. Dieser Abschnitt zeigt einige der in Postfix enthaltenen Strategien.


KULTUR Das Spam-Problem


Spam


Spammer


"Spam" ist der allgemeine Begriff zur Bezeichnung all der unerwünschten kommerziellen E-Mails (auch bekannt als UCE = unsolicited commercial email), die unsere elektronischen Postfächer überfluten; die gewissenlosen Individuen, die sie verschicken, werden Spammer genannt. Sie kümmern sich wenig um die Belästigung, die sie verursachen, da das Verschicken einer E-Mail sehr wenig kostet, und es genügt, dass sich nur ein sehr geringer Prozentsatz der Empfänger von diesen Angeboten angezogen fühlt, damit die Spamming-Aktion mehr Geld einbringt als sie kostet. Der Vorgang ist weitgehend automatisiert, und jede öffentlich gemachte E-Mail-Adresse (zum Beispiel in einem Web-Forum, den Archiven einer Mailingliste oder einem Blog und so weiter) wird von den Robotern des Spammers entdeckt und einem niemals endenden Strom unerwünschter Nachrichten unterworfen.


Alle System-Administratoren versuchen, dieser Belästigung mit Spamfiltern zu begegnen, aber natürlich passen sich die Spammer an und versuchen, diese Filter zu umgehen. Einige mieten sogar Rechnernetzwerke an, die von diversen kriminellen Banden mit einem Wurm infiziert worden sind. Jüngste Statistiken schätzen, dass bis zu 95% aller im Internet umlaufenden E-Mails Spam sind!


IP-basierte Zugangsbeschränkungen


Die Anweisung smtpd_client_restrictions steuert, welchen Rechnern es erlaubt ist, mit dem E-Mail-Server zu kommunizieren.


Beschränkungen aufgrund von Client-Adressen


smtpd_client_restrictions = permit_mynetworks, warn_if_reject reject_unknown_client, check_client_access hash:/etc/postfix/access_clientip, reject_rbl_client sbl-xbl.spamhaus.org, reject_rbl_client list.dsbl.org


Wenn eine Variable, wie in obenstehendem Beispiel, eine Liste von Regeln enthält, werden diese Regeln der Reihe nach von der ersten zur letzten ausgewertet. Jede Regel kann die Nachricht annehmen, zurückweisen oder die Entscheidung der nächstfolgenden Regel überlassen. Daher ist die Reihenfolge wichtig, und das einfache Vertauschen zweier Regeln kann zu einem völlig anderen Verhalten führen.


Die Anweisung permit_mynetworks, die als erste Regel verwendet wurde, akzeptiert alle E-Mails, die von einem Rechner im lokalen Netzwerk (wie in der Konfigurationsvariablen mynetworks festgelegt) kommen.


Die zweite Direktive würde normalerweise alle E-Mails zurückweisen, die von Rechnern ohne vollständig gültige DNS-Konfiguration kommen. Solch eine gültige Konfiguration bedeutet, dass die IP-Adresse einem Namen zugeordnet werden kann, und dass dieser Name wiederum der IP-Adresse zugeordnet ist. Diese Beschränkung ist häufig zu strikt, da manche E-Mail-Server keine umgekehrte DNS für ihre IP-Adresse haben. Dies erklärt, warum die Falcot-Administratoren der Direktive reject_unknown_client den Modifikator warn_if_reject vorangestellt haben: dieser Modifikator wandelt die Zurückweisung in eine einfache Warnung um, die in den Protokollen aufgezeichnet wird. Die Administratoren können dann die Anzahl der Nachrichten im Blick behalten, die zurückgewiesen würden, wenn die Regel tatsächlich durchgesetzt würde und später aufgrund dieser Informationen eine Entscheidung treffen, ob sie die Durchsetzung aktivieren wollen.


TIP access-Tabellen


Die Einschränkungskriterien bestehen unter anderem aus Tabellen, die vom Administrator geändert werden können und Kombinationen aus Absendern, IP-Adressen und erlaubten oder verbotenen Rechnernamen auflisten. Diese Tabellen können aus einer entpackten Kopie der Datei /usr/share/doc/postfix-doc/examples/access.gz erstellt werden. Dieses Modell ist in seinen Kommentaren dokumentiert, was bedeutet, dass jede Tabelle ihre eigene Syntax erläutert.


Die Tabelle /etc/postfix/access_clientip führt IP-Adressen und Netzwerke auf; /etc/postfix/access_helo listet Domain-Namen; /etc/postfix/access_sender enthält E-Mail-Adressen von Absendern. All diese Dateien müssen nach jeder Änderung mit Hilfe des Befehls postmap /etc/postfix/datei in Hash-Tabellen umgewandelt werden (ein Format, das für schnellen Zugriff optimiert ist).


Die dritte Anweisung ermöglicht es dem Administrator eine schwarze Liste und eine Positivliste von E-Mail-Servern aufzustellen, die in der Datei /etc/postfix/access_clientip abgespeichert werden. Server in der Positivliste werden als zuverlässig angesehen, und die von dort kommenden E-Mails durchlaufen daher nicht die anschließenden Filterregeln.


Die beiden letzten Regeln weisen jede Nachricht zurück, die von einem Server kommt, der in einer der angezeigten schwarzen Listen aufgeführt ist. RBL ist die Abkürzung für Remote Black List; es gibt mehrere derartige Listen, aber alle führen sowohl schlecht konfigurierte Server auf, die von Spammern zur Übermittlung ihrer E-Mails benutzt werden, als auch unerwartete Mail-Übermittler, wie von Würmern oder Viren infizierte Rechner.


RBL


Remote Black List


TIP Positivliste und RBLs


Manchmal schließen schwarze Listen seriöse Server ein, die einen Störfall erlitten haben. In diesen Situationen würden alle E-Mails, die von einem dieser Server kommen, zurückgewiesen, es sei denn, der Server ist in einer von /etc/postfix/access_clientip festgelegten Positivliste aufgeführt.


Die Vernunft gebietet es daher, alle seriösen Server, von denen man normalerweise zahlreiche E-Mails erhält, in die Positivliste aufzunehmen.


Die Gültigkeit der Befehle EHLO oder HELO überprüfen


Jeder SMTP-Austausch beginnt mit einem HELO- (oder EHLO-)Befehl, gefolgt vom Namen des sendenden E-Mail-Servers; es kann interessant sein, die Gültigkeit dieses Namens zu überprüfen.


HELO


EHLO


Beschränkungen für den in EHLO genannten Namen


smtpd_helo_restrictions = permit_mynetworks, reject_invalid_hostname, check_helo_access hash:/etc/postfix/access_helo, reject_non_fqdn_hostname, warn_if_reject reject_unknown_hostname


Die erste Anweisung, permit_mynetworks, erlaubt es allen Rechnern des lokalen Netzwerks, sich ungehindert einzuführen. Dies ist wichtig, da einige E-Mail-Programme diesen Teil des SMTP-Protokolls nicht in ausreichendem Maße beachten und sich mit unsinnigen Namen einführen können.


Die Regel reject_invalid_hostname weist E-Mails zurück, wenn die EHLO-Ankündigung einen syntaktisch unkorrekten Rechnernamen aufführt. Die Regel reject_non_fqdn_hostname weist Nachrichten zurück, wenn der angekündigte Rechnername kein vollständig ausgewiesener Domain-Name ist (dies schließt einen Domain-Namen wie auch einen Rechnernamen ein). Die Regel reject_unknown_hostname weist Nachrichten zurück, falls es den angekündigten Name in der DNS nicht gibt. Da diese letzte Regel leider zu viele Zurückweisungen zur Folge hat, haben die Administratoren ihre Wirkung mit Hilfe des Modifikators warn_if_reject bis auf Weiteres in eine einfache Warnung umgewandelt; sie können sich entschließen, diesen Modifikator später zu entfernen, nachdem sie die Ergebnisse dieser Regel überprüft haben.


Die Verwendung von permit_mynetworks als erster Regel hat eine interessante Nebenwirkung: die folgenden Regeln gelten nur für Rechner außerhalb des lokalen Netzwerks. Hierdurch ist es möglich, alle Rechner, die sich als Teil von falcot.com ankündigen, auf die schwarze Liste zu setzen, indem zum Beispiel die Zeile falcot.com ABGELEHNT Sie sind nicht in unserem Netzwerk! zur Datei /etc/postfix/access_helo hinzugefügt wird.


Annahme oder Ablehnung aufgrund des angegebenen Absenders


Jede Nachricht hat einen Absender, der durch den Befehl MAIL FROM des SMTP-Protokolls angegeben wird; auch diese Information kann auf verschiedene Weise überprüft werden.


MAIL FROM


E-Maildfiltern nach Absender


Überprüfung des Absenders


smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/access_sender, reject_unknown_sender_domain, reject_unlisted_sender, reject_non_fqdn_sender


Die Tabelle /etc/postfix/access_sender ordnet einigen Absendern eine besondere Behandlung zu. Dies bedeutet für gewöhnlich, dass einige Absender in eine Positivliste oder eine schwarze Liste aufgenommen werden.


Die Regel reject_unknown_sender_domain verlangt eine gültige Absenderdomain, da sie für eine gültige Adresse benötigt wird. Die Regel reject_unlisted_sender weist lokale Absender zurück, falls die Adresse nicht existiert; hierdurch wird vermieden, dass E-Mails von einer ungültigen Adresse in der falcot.com-Domain verschickt werden, und Nachrichten, die von joe.bloggs@falcot.com ausgehen, werden nur akzeptiert, wenn eine solche Adresse tatsächlich existiert.


Schließlich weist die Regel reject_non_fqdn_sender E-Mails zurück, die vorgeben, von Adressen ohne einen vollständig ausgewiesenen Domain-Namen zu kommen. In der Praxis bedeutet dies, dass E-Mails, die von benutzer@rechner kommen, zurückgewiesen werden: die Adresse muss entweder als benutzer@rechner.beispiel.com oder benutzer@beispiel.com angegeben werden.


Annehmen oder zurückweisen aufgrund des Empfängers


Jede E-Mail hat wenigstens einen Empfänger, der im SMTP-Protokoll mit dem Befehl RCPT TO angegeben wird. Diese Adressen erfordern ebenfalls eine Gültigkeitsprüfung, selbst wenn dies weniger wichtig sein sollte als die Überprüfung des Absenders.


RCPT TO


E-Mailfiltern nach Empfänger


Überprüfung des Empfängers


smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, reject_unlisted_recipient, reject_non_fqdn_recipient


Die grundlegende Regel lautet reject_unauth_destination, und sie verlangt, dass externe Nachrichten an uns adressiert sein müssen; Nachrichten an eine Adresse, die von diesem Server nicht bedient wird, werden zurückgewiesen. Ohne diese Regel wird ein Server zu einem offenen Übermittler, der es Spammern erlaubt, unerwünschte E-Mails zu verschicken; diese Regel ist daher sehr empfehlenswert, und sie wird bevorzugt in der Nähe des Listenanfangs platziert um zu vermeiden, dass andere Regeln die Durchleitung der Nachricht erlauben, bevor ihr Ziel überprüft worden ist.


Die Regel reject_unlisted_recipient weist Nachrichten zurück, die an nicht existierende lokale Benutzer geschickt werden, was Sinn macht. Schließlich weist die Regel reject_non_fqdn_recipient nicht vollständig ausgewiesene Adressen zurück; dies macht es unmöglich, eine E-Mail an jean oder jean@rechner zu schicken, und erfordert stattdessen, die vollständige Adresse zu verwenden, wie jean@rechner.falcot.com or jean@falcot.com.


Beschränkungen in Verbindung mit dem Befehl DATA


SMTPs Befehl DATA wird vor dem Inhalt der Nachricht verschickt. An sich stellt er keine Information bereit, außer anzukündigen, was als nächstes kommt.Dennoch kann er Überprüfungen unterworfen werden.


DATA


Überprüfungen von DATA


smtpd_data_restrictions = reject_unauth_pipelining


Die Anweisung reject_unauth_pipelining veranlasst, dass die Nachricht zurückgewiesen wird, falls die aussendende Partei einen Befehl verschickt, bevor die Antwort auf den vorhergehenden Befehl gesendet worden ist. Dies schützt vor einer häufig von Spam-Robotern benutzten Optimierung, da sie sich keinen Deut um Antworten scheren und sich nur darauf konzentrieren, in möglichst kurzer Zeit möglichst viele E-Mails zu verschicken.


Beschränkungen anwenden


Obwohl die obenstehenden Befehle Informationen in verschiedenen Phasen des SMTP-Austauschs überprüfen, verschickt Postfix die eigentliche Zurückweisung nur als Antwort auf den Befehl RCPT TO.


Dies bedeutet, dass selbst wenn die Nachricht aufgrund eines ungültigen EHLO-Befehls zurückgewiesen wird, Postfix den Absender und den Empfänger kennt, wenn es die Zurückweisung bekanntgibt. Es kann dann eine eindeutigere Nachricht protokollieren, als möglich gewesen wäre, falls die Übertragung gleich zu Anfang abgebrochen worden wäre. Außerdem erwarten manche SMTP-Clients keine Störungen bei den frühen SMTP-Befehlen, und diese Clients werden durch die späte Zurückweisung weniger gestört.


Ein letzter Vorteil dieser Vorgehensweise ist, dass die Regeln im Verlauf der verschiedenen SMTP-Phasen Informationen sammeln können; dies ermöglicht es, feinkörnigere Berechtigungen zu formulieren, wie zum Beispiel eine nicht-lokale Verbindung zurückzuweisen, wenn sie sich als lokaler Absender bezeichnet.


Filtern aufgrund des Nachrichteninhalts


KURZER BLICK Regexp-Tabellen


Die Datei /usr/share/doc/postfix-doc/examples/header_checks.gz enthält zahlreiche erläuternde Kommentare und kann als Ausgangspunkt zur Erstellung der Dateien /etc/postfix/header_checks und /etc/postfix/body_checks verwendet werden.


Das Überprüfungs- und Beschränkungssystem wäre nicht vollständig, ohne eine Möglichkeit, Überprüfungen des Nachrichteninhalts einzusetzen. Postfix unterscheidet die Überprüfungen, die es auf die E-Mail-Kopfzeilen anwendet, von denen die es für den E-Mail-Inhalt gebraucht.


Inhaltsbezogene Filter aktivieren


header_checks = regexp:/etc/postfix/header_checks body_checks = regexp:/etc/postfix/body_checks


E-Mailfiltern nach Inhalt


Beide Dateien enthalten eine Liste regulärer Ausdrücke (gewöhnlich als regexps oder regexes bezeichnet) und damit zusammenhängender Aktionen, die ausgelöst werden, wenn die E-Mail-Kopfzeilen (oder der Inhalt) dem Ausdruck entspricht.


Beispiel einer Datei /etc/postfix/header_checks


/^X-Mailer: GOTO Sarbacane/ REJECT I fight spam (GOTO Sarbacane) /^Subject: *Your email contains VIRUSES/ DISCARD virus notification


ZURÜCK ZU DEN GRUNDLAGEN Regulärer Ausdruck


Der Begriff regulärer Ausdruck (abgekürzt regexp oder regex) bezieht sich auf eine allgemeine Bezeichnung, um eine Beschreibung des Inhalts oder der Struktur einer Zeichenkette zum Ausdruck zu bringen. Bestimmte Sonderzeichen ermöglichen die Festlegung von Alternativen (so trifft zum Beispiel foo|bar entweder für "foo" oder für "bar" zu), von Reihen zugelassener Zeichen (zum Beispiel bedeutet [0-9] eine beliebige Ziffer und . - ein Punkt - einen beliebigen Buchstaben) und von Quantifizierungen (s? trifft entweder auf s oder die Nullkette zu, mit anderen Worten das Ereignis 0 oder 1 von s; s+ trifft auf ein oder mehrere aufeinander folgende s-Zeichen zu und so weiter). Klammern ermöglichen das Gruppieren von Suchergebnissen.


Die genaue Syntax dieser Ausdrücke unterscheidet sich zwischen den Programmen, die sie verwenden, aber die grundlegenden Merkmale sind ähnlich.


Der erste überprüft die Kopfzeile, die die E-Mail-Software nennt; falls GOTO Sarbacane gefunden wird (ein Programm zum Versenden von Massen-E-Mail), wird die Nachricht zurückgewiesen. Der zweite Ausdruck überprüft den Nachrichtenbetreff; falls er eine Virenmeldung nennt, können wir uns entschließen, die Nachricht nicht zurückzuweisen, sondern stattdessen sofort zu löschen.


Die Verwendung dieser Filter ist ein zweischneidiges Schwert, da die Regeln leicht zu allgemein formuliert werden können und als Folge seriöse E-Mails verloren gehen. In diesen Fällen sind nicht nur die Nachrichten verloren, sondern ihre Absender werden zudem unerwünschte (und störende) Fehlermeldungen erhalten.


Greylisting einrichten


greylisting


"Greylisting" ist eine Filtertechnik, der zufolge eine Nachricht zunächst mit einem vorläufigen Fehlercode zurückgewiesen und erst bei einem weiteren Versuch nach einer gewissen Verzögerung angenommen wird. Dieses Filtern ist vor allem gegen Spam wirkungsvoll, der von den vielen mit Würmern und Viren infizierten Rechnern verschickt wird, da diese Programme nur selten als vollständige SMTP-Agenten agieren (mit Überprüfung des Fehlercodes und einem späteren erneuten Zustellversuch für gescheiterte Nachrichten), vor allem weil viele der eingesammelten Adressen in Wirklichkeit ungültig sind und ein erneuter Versuch nur Zeitverschwendung wäre.


Postfix stellt Greylisting nicht von Haus aus zur Verfügung, jedoch gibt es eine Funktion, mit der die Entscheidung, eine bestimmte Nachricht anzunehmen oder zurückzuweisen, an ein externes Programme delegiert werden kann. Das Paket postgrey enthält genau solch ein Programm, das dafür ausgelegt ist, diesen Dienst zur Delegierung der Zugangsrichtlinien anzubinden.


Nachdem postgrey installiert ist, läuft es als Daemon und nimmt an Port 60000 Verbindungen an. Postfix kann dann für seine Verwendung eingestellt werden, indem der Parameter check_policy_service als zusätzliche Bedingung hinzugefügt wird:


smtpd_recipient_restrictions = permit_mynetworks, [...] check_policy_service inet:127.0.0.1:60000


Jedes Mal, wenn Postfix diese Regel in seinem Regelsatz erreicht, verbindet es sich mit dem postgrey-Daemon und schickt ihm Informationen über die entsprechende Nachricht. Postgrey überprüft seinerseits die Dreiergruppe aus IP-Adresse, Absender und Empfänger und sieht in seiner Datenbank nach, ob dieselbe Dreiergruppe vor kurzem gesehen worden ist. Wenn dies der Fall ist, antwortet Postgrey, dass die Nachricht angenommen werden sollte; anderenfalls zeigt die Antwort an, dass die Nachricht vorübergehend zurückgewiesen werden soll, und die Dreiergruppe wird in die Datenbank eingetragen.


Der Hauptnachteil des Greylistings ist, dass seriöse Nachrichten verzögert werden, was nicht immer akzeptabel ist. Es erhöht außerdem die Belastung von Servern, die zahlreiche seriöse E-Mails versenden.


IN DER PRAXIS Unzulänglichkeiten des Greylistings


Theoretisch sollte Greylisting nur die erste Nachricht eines bestimmten Absenders an einen bestimmten Empfänger verzögern, und die typische Verzögerungsdauer liegt dabei im Bereich von Minuten. Die Wirklichkeit kann jedoch etwas anders aussehen. Einige große Internetdienstanbieter verwenden Gruppen von SMTP-Servern, und wenn eine Nachricht zunächst zurückgewiesen wird, kann es sein, dass der Server, der die Übertragung erneut versucht, nicht derselbe wie der ursprüngliche ist. In diesem Fall erhält der zweite Server aufgrund des Greylistings ebenfalls eine vorläufige Fehlermeldung und so weiter; es kann mehrere Stunden dauern, bevor die Übertragung von einem Server versucht wird, der ursprünglich beteiligt war, da SMTP-Server normalerweise nach jedem Fehlschlag die Verzögerungszeit bis zu einem erneuten Versuch erhöhen.


Folglich kann sich die ankommende IP-Adresse selbst für einen einzelnen Absender im Zeitverlauf ändern. Es geht jedoch noch weiter: selbst die Absenderadresse kann wechseln. Zum Beispiel kodieren viele Mailinglisten-Server zusätzliche Informationen in die Absenderadresse, um bestimmte Fehlermeldungen (bounces genannt) verarbeiten zu können. Jede an eine Mailingliste verschickte Nachricht wird dann möglicherweise durch das Greylisting gehen müssen mit der Folge, dass sie (vorübergehend) auf dem Server des Absenders gespeichert werden muss. Bei sehr großen Mailinglisten (mit zehntausenden von Abonnenten) kann dies sehr schnell zu einem Problem werden.


Um diesen Nachteilen entgegen zu wirken, verwaltet Postgrey eine Positivliste solcher Orte, und von ihnen ausgehende Nachrichten werden direkt ohne den Umweg über das Greylisting angenommen. Diese Liste kann leicht an die örtlichen Bedürfnisse angepasst werden, da sie in der Datei /etc/postgrey/whitelist_clients gespeichert ist.


WEITERE SCHRITTE Selektives Greylisting mit whitelister


Den Nachteilen des Greylistings kann dadurch begegnet werden, dass es nur auf die Untergruppe von Clients angewendet wird, die bereits als mögliche Spamquellen angesehen werden (da sie in einer schwarzen Liste des DNS aufgeführt sind). Dieser Dienst wird durch whitelister bereitgestellt, einen weiteren Zugangsrichtlinien-Daemon für Postfix, der als Filter unmittelbar vor Postgrey eingesetzt werden kann. Falls der Client in keiner schwarzen Liste aufgeführt ist, informiert Whitelister Postfix, dass es die Nachricht annehmen soll; anderenfalls ist Whitelisters Antwort, dass es keine Meinung hat, und die Nachricht geht an die nächste Regel des Regelsatzes weiter (die normalerweise der Aufruf von Postgrey sein wird). Whitelister wartet standardmäßig an Port 10000 auf Anfragen.


smtpd_recipient_restrictions = permit_mynetworks, [...] check_policy_service inet:127.0.0.1:10000, check_policy_service inet:127.0.0.1:60000


Da Whitelister niemals eine endgültige Zurückweisung auslöst, ist es angemessen, agressive schwarze Listen des DNS zu verwenden, einschließlich solcher, die alle dynamischen IP-Adressen von Internetdienstanbietern aufführen (wie zum Beispiel dynablock.njabl.org oder dul.dnsbl.sorbs.net). Dies kann mit dem Parameter rbl in der Konfigurationsdatei /etc/whitelister.conf eingestellt werden.


Filter anhand des Empfängers einstellen


In den letzten beiden Abschnitten sind zahlreiche Beschränkungsmöglichkeiten betrachtet worden. Sie alle haben ihren Nutzen bei der Begrenzung der eingehenden Spam-Menge, aber sie haben auch ihre Nachteile. Es wird daher immer üblicher, den Filtersatz anhand des Empfängers einzustellen. Bei Falcot Corp. ist das Greylisting für die meisten Benutzer interessant, es behindert jedoch die Arbeit einiger Benutzer, die bei ihren E-Mails kurze Wartezeiten benötigen (wie zum Beispiel der technische Betreuungsdienst). In ähnlicher Weise hat die Handelsabteilung manchmal Probleme beim Empfang von E-Mails einiger asiatischer Anbieter, die vielleicht in schwarzen Listen aufgeführt sind; diese Abteilung hat um eine ungefilterte Adresse gebeten, so dass sie korrespondieren kann.


Postfix bietet eine derartige Filteranpassung mit dem Konzept einer "restriction class" an. Diese Klassen werden in dem Parameter smtpd_restriction_classes angegeben und in der gleichen Weise wie smtpd_recipient_restrictions festgelegt. Die Anweisung check_recipient_access bezeichnet dann eine Tabelle, die einem bestimmten Empfänger den richtigen Satz von Beschränkungen zuordnet.


Beschränkungsklassen in main.cf festlegen


smtpd_restriction_classes = greylisting, aggressive, permissive greylisting = check_policy_service inet:127.0.0.1:10000, check_policy_service inet:127.0.0.1:60000 aggressive = reject_rbl_client sbl-xbl.spamhaus.org, check_policy_service inet:127.0.0.1:60000 permissive = permit smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, check_recipient_access hash:/etc/postfix/recipient_access


Die Datei /etc/postfix/recipient_access


# Ungefilterte Adressen postmaster@falcot.com permissive support@falcot.com permissive sales-asia@falcot.com permissive # Aggressives Filtern für einige bevorrechtigte Benutzer joe@falcot.com aggressive # Besondere Regel für den Manager der Mailingliste sympa@falcot.com reject_unverified_sender # Standardmäßiges Greylisting falcot.com greylisting


Einen Virenschutz integrieren


Virenschutz


Die zahlreichen als E-Mail-Anhänge umlaufenden Viren erfordern das Einrichten eines Virenschutzes am Eingang des Firmennetzwerks, da einige Benutzer trotz einer Aufklärungskampagne weiterhin Anhänge von offensichtlich fragwürdigen Nachrichten öffnen.


Die Falcot-Administratoren haben clamav als ihren kostenlosen Virenschutz ausgewählt. Das Hauptpaket ist clamav, aber sie haben auch einige Zusatzpakete wie arj, unzoo, unrar und lha installiert, da diese benötigt werden, damit der Virenschutz Anhänge analysieren kann, die in einem dieser Formate komprimiert sind.


clamav


clamav-milter


Die Aufgabe, die Verbindung zwischen dem Virenschutz und dem E-Mail-Server bereitzustellen, fällt dem Programm clamav-milter zu. Ein Milter (kurz für Mailfilter) ist ein speziell für die Verbindung mit E-Mail-Servern ausgelegtes Programm. Ein Milter verwendet eine standardmäßige Programmierschnittstelle (API = application programming interface), die eine deutlich bessere Leistung aufweist als Filter außerhalb der E-Mail-Server. Milter wurden ursprünglich von Sendmail eingeführt, aber Postfix ist dem bald gefolgt.


KURZER BLICK Ein Milter für Spamassassin


spamass-milter


Das Paket spamass-milter stellt einen Milter zur Verfügung, der auf SpamAssassin beruht, dem bekannten Suchprogramm für unerwünschte E-Mails. Er kann dazu benutzt werden, Nachrichten als möglichen Spam zu markieren (indem er eine zusätzliche Kopfzeile hinzufügt) oder die Nachrichten vollständig zurückzuweisen, falls ihr Spam-Grad einen bestimmten Schwellenwert übersteigt.


Nachdem clamav-milter installiert ist, muss die Datei /etc/default/clamav-milter so angepasst werden, dass der Milter dafür eingerichtet ist, an einem TCP-Port anstelle des standardmäßig genannten Sockets zu laufen:


SOCKET=inet:10002@127.0.0.1


Diese neue Konfiguration wird nach dem Befehl /etc/init.d/clamav-milter restart berücksichtigt.


Die standardmäßige ClamAV-Konfiguration passt zu den meisten Situationen, aber einige wichtige Parameter können noch mit dpkg-reconfigure clamav-base angepasst werden. Auf ähnliche Weise ist mit dem Befehl dpkg-reconfigure clamav-milter das Einstellen des Mailfilter-Verhaltens recht detailliert möglich.


Im letzten Schritt wird Postfix angewiesen, den neu konfigurierten Filter zu verwenden. Dies geschieht einfach durch das Hinzufügen der folgenden Anweisung zu /etc/postfix/main.cf:


# Virus check with clamav-milter smtpd_milters = inet:[127.0.0.1]:10002


Falls der Virenschutz Probleme verursacht, kann diese Zeile kommentiert und dann /etc/init.d/postfix reload aufgerufen werden, damit diese Veränderung berücksichtigt wird.


IN DER PRAXIS Den Virenschutz erproben


Sobald der Virenschutz eingerichtet ist, ist es richtig, ihn zu erproben. Dies geschieht am einfachsten dadurch, dass man eine Test-E-Mail mit einem Anhang verschickt, der die Datei eicar.com (oder eicar.com.zip) enthält, die aus dem Internet heruntergeladen werden kann:


Diese Datei ist kein wirkliches Virus, sondern eine Testdatei, die alle auf dem Markt befindlichen Virenschutzprogramme als Virus diagnostizieren, um so die Überprüfung von Installationen zu ermöglichen.


Alle Nachrichten, die von Postfix verarbeitet werden, laufen jetzt durch den Virenschutzfilter.


Authentifiziertes SMTP


Um E-Mails verschicken zu können, ist es erforderlich, dass ein SMTP-Server erreichbar ist; besagter SMTP-Server muss außerdem E-Mails durchleiten. Für Benutzer, die unterwegs sind, würde dies bedeuten, dass die Konfiguration des SMTP-Clients regelmäßig geändert werden muss, da Falcots SMTP-Server Nachrichten abweist, die von IP-Adressen kommen, die offensichtlich nicht zum Unternehmen gehören. Es gibt zwei Lösungen: Entweder installiert ein Benutzer auf Reisen einen SMTP-Server auf seinem Rechner, oder er benutzt weiterhin den Unternehmensserver unter Verwendung einiger Hilfsmittel, mit denen er sich als Angestellter authentifiziert. Die erste Lösung wird nicht empfohlen da der Rechner nicht ununterbrochen verbunden wäre und im Falle von Problemen nicht wiederholt versuchen könnte, Nachrichten zu senden; wir werden uns daher auf die zweite Lösung konzentrieren.


SMTP-Authentifizierung in Postfix ist auf SASL angewiesen. Hierzu ist es erforderlich, die Pakete libsasl2-modules und sasl2-bin zu installieren und dann für jeden Benutzer, der eine Authentifizierung beim SMTP-Server benötigt, ein Passwort in die SASL-Datenbank einzutragen. Dies geschieht mithilfe des Befehls saslpasswd2, der verschiedene Parameter akzeptiert. Die Option -u legt die Authentifizierungs-Domain fest, die mit dem Parameter smtpd_sasl_local_domain in der Postfix-Konfiguration übereinstimmen muss. Die Option -c ermöglicht das Anlegen eines Benutzers und -f gestattet es, die Datei zu bestimmen, die benutzt werden soll, wenn die SASL-Datenbank an einem anderen als dem standardmäßig vorgegebenen Ort (/etc/sasldb2) gespeichert werden soll.


# saslpasswd2 -h `postconf -h myhostname` -f /var/spool/postfix/etc/sasldb2 -c jean [... type jean's password twice ...]


Beachten Sie, dass die SASL-Datenbank im Verzeichnis von Postfix erstellt worden ist. Um Konsistenz sicherzustellen, wandeln wir außerdem /etc/sasldb2 in einen symbolischen Verweis um, der auf die von Postfix verwendete Datenbank weist, und zwar mit dem Befehl ln -sf /var/spool/postfix/etc/sasldb2 /etc/sasldb2.


Nun müssen wir Postfix so einstellen, dass es SASL benutzt. Zunächst muss der Benutzer postfix zur Gruppe sasl hinzugefügt werden, damit er auf die Datenbank des SASL-Kontos zugreifen kann. Einige neue Parameter sind auch erforderlich, um SASL zu aktivieren, und der Parameter smtpd_recipient_restrictions muss so eingestellt werden, dass Benutzer, die bei SASL authentifiziert sind, ungehindert E-Mails versenden können.


SASL in /etc/postfix/main.cf aktivieren


# Enable SASL authentication smtpd_sasl_auth_enable = yes # Define the SASL authentication domain to use smtpd_sasl_local_domain = $myhostname [...] # Adding permit_sasl_authenticated before reject_unauth_destination # allows relaying mail sent by SASL-authenticated users smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, [...]


EXTRA Authentifizierter SMTP-Client


Die meisten E-Mail-Clients können sich bei einem SMTP-Server authentifizieren, bevor sie abgehende Nachrichten verschicken, und die Verwendung dieses Merkmals ist einfach eine Frage der passenden Parametereinstellung. Falls der verwendete Client diese Fähigkeit nicht besitzt, besteht eine Umgehungslösung darin, einen lokalen Postfix-Server zu verwenden und ihn für die Weiterleitung der E-Mails über den entfernten SMTP-Server einzustellen. In diesem Fall wird das lokale Postfix selbst der Client sein, der sich bei SASL authentifiziert. Hier sind die erforderlichen Paramter:


smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd relay_host = [mail.falcot.com]


Die Datei /etc/postfix/sasl_passwd muss den Benutzernamen und das Passwort zur Authentifizierung beim Server smtp.falcot.com enthalten. Hier ist ein Beispiel:


[mail.falcot.com] joe:LyinIsji


Wie bei allen Postfix-Zuordnungen muss diese Datei mit dem Befehl postmap in die Datei /etc/postfix/sasl_passwd.db umgewandelt werden.


Webserver (HTTP)


Die Falcot-Corp.-Administratoren haben sich entschlossen, den Apache HTTP-Server zu verwenden, der in der Version 2.2.16 in Debian Squeeze enthalten ist.


apache


ServerWeb


Web, Server


ServerHTTP


HTTPServer


ALTERNATIVE Andere Webserver


Apache ist lediglich der am besten bekannte (und meistbenutzte) Webserver, aber es gibt andere; sie können bei bestimmten Beanspruchungen bessere Leistungen bieten, dies hat jedoch sein Pendant in der geringeren Anzahl verfügbarer Leistungsmerkmale und Module. Wenn jedoch der in Aussicht stehende Webserver zur Bereitstellung statischer Dateien eingesetzt werden oder als Proxy fungieren soll, sind Alternativen wie nginx und lighttpd eine nähere Untersuchung wert.


nginx


lighttpd


Installation von Apache


Standardmäßig wird beim Installieren des Pakets apache2 auch die Apache-Version apache2-mpm-worker installiert. Das Paket apache2 ist eine leere Hülle, die lediglich dazu dient sicherzustellen, dass eine der Apache-Versionen tatsächlich installiert wird.


Die Unterschiede in den Apache-2-Varianten beziehen sich in erster Linie auf das Regelwerk, das beim Umgang mit der parallelen Verarbeitung zahlreicher Anfragen verwendet wird; dieses Regelwerk wird durch ein MPM (kurz für Multi-Processing Module) umgesetzt. Unter den verfügbaren MPMs verwendet apache2-mpm-worker sogenannte Threads (leichtgewichtige Prozesse), wohingegen apache2-mpm-prefork eine Anzahl zuvor erstellter Prozesse benutzt (dies ist der traditionelle Weg und der einzige, der unter Apache 1.3 verfügbar war). apache2-mpm-event verwendet ebenfalls Threads, die jedoch früher beendet werden, wenn die ankommende Verbindung lediglich durch die HTTP-Funktion keep-alive offen gehalten wird.


Die Falcot-Administratoren installieren auch libapache2-mod-php5, um die Unterstützung für PHP in Apache einzubeziehen. Dies führt dazu, dass apache2-mpm-worker entfernt und apache2-mpm-prefork an seiner Stelle installiert wird, da PHP nur unter diesem speziellen MPM funktioniert.


SICHERHEIT Ausführung unter dem Benutzer www-data


www-data


suexec


Standardmäßig verarbeitet Apache ankommende Anfragen unter der Identität des Benutzers www-data. Dies bedeutet, dass eine Sicherheitslücke in einem CGI-Skript, das von Apache (für eine dynamische Seite) ausgeführt wird, nicht das ganze System gefährden würde, sondern nur die Dateien im Besitz dieses speziellen Benutzers.


Die Benutzung der suexec-Module ermöglicht es, diese Regel zu umgehen, so dass einige CGI-Skripte unter der Identität eines anderen Benutzers ausgeführt werden. Dies wird mit einer Anweisung der Art SuexecUserGroup benutzergruppe in der Apache-Konfiguration eingestellt.


apache2-mpm-itk


Eine weitere Möglichkeit besteht darin, ein speziell hierfür vorgesehenes MPM zu benutzen, wie das von apache2-mpm-itk bereitgestellte. Dieses Modul weist ein etwas abweichendes Verhalten auf: es ermöglicht das "Isolieren" virtueller Hosts, so dass jeder von ihnen als ein anderer Benutzer läuft. Eine Schwachstelle in einer Webseite kann somit keine Dateien gefährden, die dem Benutzer einer anderen Webseite gehören.


SCHNELLER BLICK Liste der Module


Die vollständige Liste der Apache-Standardmodule ist online zu finden.


Apache ist ein modularer Server, und viele Leistungsmerkmale werden durch externe Module umgesetzt, die das Hauptprogramm während der Initialisierung lädt. Die Standardkonfiguration aktiviert nur die gebräuchlichsten Module, aber das Aktivieren neuer Module geschieht einfach mit dem Befehl a2enmod module; der Befehl zum Abschalten eines Moduls lautet a2dismod module. Diese Programme erstellen (oder löschen) in Wirklichkeit nur symbolische Verknüpfungen in der Datei /etc/apache2/mods-enabled/, die auf die tatsächlichen Dateien zeigen (die in /etc/apache2/mods-available/ gespeichert sind).


In seiner Standardkonfiguration nimmt der Webserver an Port 80 Verbindungen an (wie in /etc/apache2/ports.conf konfiguriert), und liefert Seiten aus dem Verzeichnis /var/www/ (wie in /etc/apache2/sites-enabled/000-default konfiguriert).


WEITERE SCHRITTE SSL-Unterstützung hinzufügen


HTTPS


HTTPsicher


Apache 2.2 bringt von vornherein das für sicheres HTTP (HTTPS) erforderliche Modul mit. Man muss es nur durch den Befehl a2enmod ssl aktivieren und danach die erforderlichen Anweisungen zur Konfigurationsdatei hinzufügen. Ein Konfigurationsbeispiel wird in /usr/share/doc/apache2.2-common/examples/apache2/extra/httpd-ssl.conf.gz bereitgestellt.


Virtuelle Hosts konfigurieren


Ein virtueller Host ist eine zusätzliche Identität des Webservers.


virtual host


Apache berücksichtigt zwei verschiedene Arten virtueller Hosts: diejenigen, die auf der IP-Adresse (oder dem Port) basieren, und diejenigen, die sich auf den Domainnamen des Webservers stützen. Bei der ersten Methode muss jeder Seite eine andere IP-Adresse (oder ein anderer Port) zugeordnet werden, während die zweite mit einer einzigen IP-Adresse (und einem einzigen Port) auskommt und die Seiten durch den Hostnamen, der vom HTTP-Client gesendet wird, unterschieden werden (was nur in Version 1.1 des HTTP-Protokolls funktioniert - glücklicherweise ist diese Version alt genug, dass alle Clients sie bereits verwenden).


Die (zunehmende) Knappheit von IPv4-Adressen begünstigt gewöhnlich die zweite Methode; jedoch ist sie komplizierter, wenn der virtuelle Host auch HTTPS bereitstellen muss, da das SSL-Protokoll nicht von jeher virtuelles Hosting auf Namensbasis ermöglicht hat. Nicht alle Browser können mit der SNI-Erweiterung (Server Name Indication), die diese Kombination ermöglicht, umgehen. Wenn mehrere HTTPS-Seiten auf demselben Server laufen müssen, werden sie gewöhnlich dadurch unterschieden, dass sie auf verschiedenen Ports laufen oder unter verschiedenen IP-Adressen (IPv6 ist hier hilfreich).


Die Standardkonfiguration für Apache 2 aktiviert virtuelle Hosts auf Namensbasis (mit der Anweisung NameVirtualHost *:80 in der Datei /etc/apache2/ports.conf). Zusätzlich wird ein voreingestellter virtueller Host in der Datei /etc/apache2/sites-enabled/000-default ausgewiesen; dieser virtuelle Host wird verwendet, wenn es keinen Host gibt, der zur Anfrage des Clients passt.


VORSICHT Erster virtueller Host


Anfragen an unbekannte virtuelle Hosts werden stets vom ersten ausgewiesenen virtuellen Host bedient, weshalb wir hier als erstes www.falcot.com bestimmt haben.


SCHNELLER BLICK Apache unterstützt SNI


Server Name Indication


Ab Debian Squeeze unterstützt der Apache-Server eine SSL-Protokollerweiterung namens Server Name Indication (SNI). Diese Erweiterung ermöglicht es dem Browser, den Hostnamen während des Aufbaus der SSL-Verbindung zu senden, viel früher als die HTTP-Anfrage selbst, die vorher dazu benutzt wurde, den gewünschten virtuellen Host unter denen zu identifizieren, die auf demselben Server (mit derselben IP-Adresse und demselben Port) untergebracht sind.


Vor SNI würde Apache stets das Zertifikat des voreingestellten virtuellen Hosts verwenden. Clients, die auf einen anderen virtuellen Host zugreifen wollten, würden dann Warnmeldungen anzeigen, da das erhaltene Zertifikat nicht zu der Webseite passte, auf die sie zugreifen wollten. Glücklicherweise arbeiten die meisten Browser inzwischen mit SNI; hierzu gehören Microsoft Internet Explorer ab Version 7.0 (ab Vista), Mozilla Firefox ab Version 2.0, Apple Safari ab Version 3.2.1 und alle Versionen von Google Chrome.


Das von Debian bereitgestellte Apache-Paket ist mit Unterstützung für SNI ausgestattet; daher ist keine besondere Konfigurierung erforderlich, abgesehen von der Aktivierung virtuellen Hostings auf Namensbasis an Port 443 (SSL) wie auch des üblichen Ports 80. Dies geschieht einfach durch das Editieren von /etc/apache2/ports.conf, so dass es dann Folgendes enthält:


<IfModule mod_ssl.c> NameVirtualHost *:443 Listen 443 </IfModule>


Man sollte auch darauf achten, dass die Konfiguration des ersten virtuellen Hosts (des standardmäßig verwendeten) TLSv1 aktiviert, da Apache die Parameter dieses ersten virtuellen Hosts verwendet, um sichere Verbindungen aufzubauen, und sie sollten ihnen dies wohl besser erlauben!


Jeder zusätzliche virtuelle Host wird dann in einer unter /etc/apache2/sites-available/ gespeicherten Datei festgelegt. Die Einrichtung einer Website für die Domain falcot.org erfordert daher nur die Erstellung der folgenden Datei und anschließend die Aktivierung des virtuellen Hosts mit dem Befehl a2ensite www.falcot.org.


Die Datei /etc/apache2/sites-available/www.falcot.org


<VirtualHost *:80> ServerName www.falcot.org ServerAlias falcot.org DocumentRoot /srv/www/www.falcot.org </VirtualHost>


Der Apache-Server, so wie er bis jetzt konfiguriert ist, benutzt für alle virtuellen Hosts dieselben Protokolldateien (obwohl dies durch das Hinzufügen von CustomLog-Anweisungen in den Bestimmungen der virtuellen Hosts geändert werden könnte). Es ist daher sehr sinnvoll, das Format dieser Protokolldatei so anzupassen, dass es den Namen des virtuellen Hosts mit einschließt. Dies kann durch die Erstellung einer Datei namens /etc/apache2/conf.d/customlog erreicht werden, die für alle Protokolldateien (mit der LogFormat-Anweisung) ein neues Format festlegt. Außerdem muss die CustomLog-Zeile aus der Datei CustomLog entfernt (oder kommentiert) werden.


Die Datei /etc/apache2/conf.d/customlog


# New log format including (virtual) host name LogFormat "%v %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" vhost # Now let's use this "vhost" format by default CustomLog /var/log/apache2/access.log vhost


Gebräuchliche Anweisungen


Dieser Abschnitt gibt einen kurzen Überblick über einige häufig benutzte Apache Konfigurationsanweisungen. Apache-Anweisungen Anweisungen, Apache


Die Hauptkonfigurationsdatei enthält gewöhnlich mehrere Directory-Blöcke; sie ermöglichen es, unterschiedliches Verhalten des Servers in Abhängigkeit von der zu liefernden Datei festzulegen. Solch ein Block enthält häufig Anweisungen des Typs Options und AllowOverride. Options, Apache-Anweisung


AllowOverride, Apache directive


Verzeichnisblock


<Directory /var/www> Options Includes FollowSymlinks AllowOverride All DirectoryIndex index.php index.html index.htm </Directory>


Die Anweisung DirectoryIndex enthält eine Liste von Dateien, die ausgewählt werden sollen, wenn die Client-Anfrage auf ein Verzeichnis zutrifft. Die in der Liste als erste aufgeführte Datei wird herangezogen und als Antwort gesendet. DirectoryIndex, Apache-Anweisung


Options, Apache-Anweisung Auf die Anweisung Options folgt eine Liste von zu aktivierenden Optionen. Der Wert None deaktiviert alle Optionen; dementsprechend aktiviert All alle außer MultiViews. Unter anderem sind folgende Optionen verfügbar:


ExecCGI zeigt an, dass CGI-Skripte ausgeführt werden können. ExecCGI, Apache-Anweisung


FollowSymlinks informiert den Server, dass symbolischen Verweisen gefolgt werden kann, und dass die Antwort den Inhalt des Ziels solcher Links enthalten soll. FollowSymlinks, Apache-Anweisung


SymlinksIfOwnerMatch weist den Server ebenfalls an, symbolischen Verweisen zu folgen, aber nur, wenn der Verweis und sein Ziel demselben Benutzer gehören. SymlinksIfOwnerMatch, Apache-Anweisung


Includes aktiviert Server Side Includes (abgekürzt SSI). Dies sind in HTML-Seiten eingebettete Anweisungen, die bei jeder Anforderung nebenher ausgeführt werden. Includes, Apache-Anweisung


Indexes weist den Server an, den Inhalt eines Verzeichnisses aufzulisten, falls die von einem Client gesendete HTTP-Anforderung auf ein Verzeichnis ohne Indexdatei weist (d.h. wenn es in diesem Verzeichnis keine der von der Anweisung DirectoryIndex genannten Dateien gibt). Indexes, Apache-Anweisung


MultiViews aktiviert die Inhaltsvereinbarung; diese kann vom Server dazu verwendet werden, eine Webseite in der bevorzugten Sprache anzuzeigen, wie sie im Browser eingestellt ist. MultiViews, Apache-Anweisung


ZURÜCK ZU DEN GRUNDLAGEN Die Datei .htaccess


Die Datei .htaccess enthält Apache-Konfigurationsanweisungen, die jedes Mal vollzogen werden, wenn eine Anforderung ein Element des Verzeichnisses betrifft, in dem sie gespeichert ist. Der Geltungsbereich dieser Anweisungen erstreckt sich auch auf alle darunter befindlichen Unterverzeichnisse.


.htaccess


Die meisten Anweisungen, die in einem Directory-Block auftreten können, gelten auch in einer .htaccess-Datei.


Die Anweisung AllowOverride führt alle Optionen auf, die mithilfe einer .htaccess-Datei aktiviert oder deaktiviert werden können. Eine verbreitete Anwendung dieser Option besteht darin, ExecCGI einzuschränken, so dass der Administrator entscheidet, welchen Benutzern es erlaubt ist, Programme unter der Identität des Webservers (des Benutzers www-data) auszuführen.


Authentifizierung verlangen


Web-Authentifizierung


Unter manchen Umständen muss der Zugang zu Teilen einer Website beschränkt werden, so dass nur berechtigte Benutzer, die einen Benutzernamen und ein Passwort angeben, Zugang zum Inhalt erhalten.


Authentifizierung für die Datei .htaccess verlangen


Require valid-user AuthName "Private directory" AuthType Basic AuthUserFile /etc/apache2/authfiles/htpasswd-private


SICHERHEIT Keine Sicherheit


Das in oben stehendem Beispiel verwendete Authentizierungssystem (Basic) bringt nur geringfügige Sicherheit, da das Passwort als Klartext gesendet wird (es ist nur als base64 kodiert, was eine einfache Kodierungs- aber keine Verschlüsselungsmethode ist). Es sollte auch beachtet werden, dass die mit diesem Verfahren "geschützten" Dokumente ebenfalls als Klartext über das Netzwerk laufen. Falls Sicherheit wichtig ist, sollte die gesamte HTTP-Verbindung mit SSL verschlüsselt sein.


Die Datei /etc/apache2/authfiles/htpasswd-private enthält eine Liste von Benutzern und Passwörtern; sie wird normalerweise mit dem Befehl htpasswd gehandhabt. Der folgende Befehl wird zum Beispiel dazu benutzt, einen Benutzer hinzuzufügen oder sein Passwort zu ändern: htpasswd


# htpasswd /etc/apache2/authfiles/htpasswd-private benutzer Neues Passwort: Neues Passwort nochmals eingeben: Passwort wird hinzugefügt für den Benutzer benutzer


Zugang beschränken


Web-Zugangsbeschränkung


Die Anweisungen Allow from und Deny from steuern die Zugangsbeschränkungen für ein Verzeichnis (und rekursiv auch für seine Unterverzeichnisse). Apache-Anweisungen Anweisungen, Apache Allow from, Apache-Anweisung Deny from, Apache-Anweisung Order, Apache-Anweisung


Die Anweisung Order informiert den Server über die Reihenfolge, in der die Anweisungen Allow from und Deny from angewendet werden; die zuletzt zutreffende erhält Vorrang. Konkret erlaubt Order deny,allow Zugang, falls kein Deny from gilt, oder falls eine Allow from Anweisung zutrifft. Umgekehrt verweigert Order allow,deny den Zugang, falls keine Allow from Anweisung zutrifft (oder falls eine Deny from Anweisung gilt).


Auf die Anweisungen Allow from und Deny from kann eine IP-Adresse folgen, ein Netzwerk (wie zum Beispiel 192.168.0.0/255.255.255.0, 192.168.0.0/24 oder sogar 192.168.0), ein Host- oder Domain-Name oder das Schlüsselwort all, das jeden bezeichnet.


Als Voreinstellung zurückweisen, aber vom lokalen Netzwerk aus erlauben


Order deny,allow Allow from 192.168.0.0/16 Deny from all


Protokoll-Analysatoren


Häufig wird ein Protokoll-Analysator auf einem Web-Server installiert, da er den Administratoren ein genaues Bild der Einsatzmuster des Servers vermittelt.


Die Falcot-Corp.-Administratoren haben AWStats (Advanced Web Statistics) für die Analyse ihrer Apache-Protokolldateien ausgewählt.


AWStats


Webprotokoll-Analysator


ProtokolleWeb, Analysator


Der erste Konfigurierungsschritt besteht darin, die Datei /etc/awstats/awstats.conf zu erstellen. Die Vorlage /usr/share/doc/awstats/examples/awstats.model.conf.gz wird hierfür als Ausgangspunkt empfohlen, und die Falcot-Administratoren lassen sie bis auf die folgenden Parameter unverändert:


LogFile="/var/log/apache2/access.log" LogFormat = "%virtualname %host %other %logname %time1 %methodurl %code %bytesd %refererquot %uaquot" SiteDomain="www.falcot.com" HostAliases="falcot.com REGEX[^.*\.falcot\.com$]" DNSLookup=1 DirData="/var/lib/awstats" DirIcons="/awstats-icon" DirLang="/usr/share/awstats/lang" LoadPlugin="tooltips"


All diese Parameter sind durch Kommentare in der Vorlagendatei dokumentiert. Insbesondere bezeichnen die Parameter LogFile und LogFormat den Ort und das Format der Protokolldatei sowie die Information, die sie enthält; SiteDomain und HostAliases führen die verschiedenen Bezeichnungen auf, unter denen die Haupt-Website bekannt ist.


Für Internet-Präsenzen mit starkem Datenverkehr sollte DNSLookup normalerweise nicht auf 1 gesetzt werden; für kleinere, wie die oben beschriebene Falcot-Site, ermöglicht diese Einstellung jedoch besser lesbare Berichte, die vollständige Rechnernamen enthalten anstelle unverarbeiteter IP-Adressen.


SICHERHEIT Zugang zu Statistiken


AWStats macht seine Statistiken auf der Website standardmäßig ohne Beschränkungen verfügbar, jedoch können Beschränkungen eingerichtet werden, so dass nur einige (wohl interne) IP-Adressen auf sie zugreifen können; die Liste der zugelassenen IP-Adressen muss in dem Parameter AllowAccessFromWebToFollowingIPAddresses festgelegt werden.


AWStats wird auch für andere virtuelle Hosts aktiviert werden; jeder virtuelle Host benötigt seine eigene Konfigurationsdatei, wie zum Beispiel /etc/awstats/awstats.www.falcot.org.conf.


AWStats Konfigurationsdatei für einen virtuellen Host


Include "/etc/awstats/awstats.conf" SiteDomain="www.falcot.org" HostAliases="falcot.org"


Dies wird nur funktionieren, wenn die Datei /etc/awstats/awstats.conf keine Include-Anweisung enthält, da AWStats Einbindungen auf mehreren Ebenen nicht verarbeiten kann; leider enthält die von Debian bereitgestellte Standarddatei solch eine Anweisung.


Damit dieser neue virtuelle Host berücksichtigt wird, muss die Datei /etc/cron.d/awstats angepasst werden, indem ein Aufruf wie der folgende hinzugefügt wird: /usr/lib/cgi-bin/awstats.pl -config=www.falcot.org -update


Die Datei /etc/cron.d/awstats


0,10,20,30,40,50 * * * * www-data [ -x /usr/lib/cgi-bin/awstats.pl -a -f /etc/awstats/awstats.conf -a -r /var/log/apache/access.log ] && /usr/lib/cgi-bin/awstats.pl -config=awstats -update >/dev/null && /usr/lib/cgi-bin/awstats.pl -config=www.falcot.org -update >/dev/null


AWStats verwendet zahlreiche im Verzeichnis /usr/share/awstats/icon/ gespeicherte Piktogramme. Damit diese Symbole auf der Website verfügbar sind, muss die Apache-Konfiguration durch das Hinzufügen folgender Anweisung angepasst werden:


Alias /awstats-icon/ /usr/share/awstats/icon/


Einige Minuten später (und nachdem das Skript einige Male gelaufen ist) sind die Ergebnisse online verfügbar:


VORSICHT Protokolldatei-Rotation


Damit die Statistiken alle Protokolle berücksichtigten, muss AWStats unmittelbar vor dem Rotieren der Apache-Protokolldateien laufen. Dies kann durch das Hinzufügen einer prerotate-Anweisung zur Datei /etc/logrotate.d/apache2 erreicht werden:


/var/log/apache2/*.log { weekly missingok rotate 52 compress delaycompress notifempty create 644 root adm sharedscripts prerotate su - www-data -c "/usr/lib/cgi-bin/awstats.pl -config=awstats -update > /dev/null" su - www-data -c "/usr/lib/cgi-bin/awstats.pl -config=www.falcot.org -update > /dev/null" endscript postrotate if [ -f /var/run/apache2.pid ]; then /etc/init.d/apache2 restart > /dev/null fi endscript }


Beachten Sie auch, dass die von logrotate erzeugten Protokolldateien für jeden lesbar sein müssen, insbesondere für AWStats. In oben stehendem Beispiel wird dies durch die Zeile create 644 root adm gewährleistet.


FTP-Dateiserver


FTP (File Transfer Protocol)


FTP (File Transfer Protocol) ist eines der ersten Internet-Protokolle (RFC 959 ist 1985 veröffentlicht worden!). Es wurde zur Verteilung von Dateien benutzt, sogar schon bevor das Web geboren war (das HTTP-Protokoll wurde 1990 entwickelt und formal in seiner 1.0 Version durch RFC 1945 festgelegt, die 1996 veröffentlicht worden ist).


Dieses Protokoll ermöglicht sowohl das Hoch- als auch das Herunterladen von Dateien; daher wird es noch häufig verwendet, um Aktualisierungen auf einer bei jemandes Internetdienstanbieter untergebrachten Website einzustellen (oder irgendeiner anderen Organisation, die Websites aufnimmt). In diesen Fällen wird ein sicherer Zugriff durch eine Benutzerkennung und ein Passwort vollzogen; nach der erfolgreichen Authentifizierung gewährt der FTP-Server Lese- und Schreibzugriff auf das Benutzerverzeichnis dieses Benutzers.


Andere FTP-Server dienen vor allem dazu, Dateien zum öffentlichen Download zu verbreiten; Debian-Pakete sind hierfür ein gutes Beispiel. Der Inhalt dieser Server wird von anderen, geografisch entfernten Servern bezogen; er wird dann weniger entfernten Benutzern zur Verfügung gestellt. Dies bedeutet, dass Client-Authentifizierung nicht erforderlich ist; daher wird diese Betriebsart als "anonymes FTP" bezeichnet. Um ganz genau zu sein, authentifizieren sich die Clients mit dem Benutzernamen anonymous; das Passwort ist häufig herkömmlicherweise die E-Mail-Adresse des Benutzers, aber der Server ignoriert sie.


In Debian sind zahlreiche FTP-Server verfügbar (ftpd, proftpd, wu-ftpd und so weiter). Die Falcot-Corp.-Administratoren haben vsftpd gewählt, weil sie den FTP-Server nur dazu benutzen, einige Dateien zu verbreiten (einschließlich eines Debian-Paketdepots); da sie keine weitergehenden Leistungsmerkmale benötigen, haben sie sich dafür entschieden, die Sicherheitsaspekte in den Mittelpunkt zu stellen.


vsftpd


Durch das Installieren des Pakets wird ein Systembenutzer namens ftp erstellt. Dieses Konto wird stets für anonyme FTP-Verbindungen verwendet, und sein Benutzerverzeichnis (/home/ftp/) ist der Stamm des Verzeichnisbaums, der den Benutzern, die sich mit diesem Dienst verbinden, zur Verfügung gestellt wird. Die Standardkonfiguration (in /etc/vsftpd.conf) ist sehr restriktiv: sie erlaubt lediglich schreibgeschützten anonymen Zugriff (da die Optionen write_enable und anon_upload_enable deaktiviert sind), und lokale Benutzer können mit ihrem normalen Benutzernamen und Passwort keine Verbindung herstellen und auf ihre eigenen Dateien zugreifen (Option local_enable). Diese Standardkonfiguration ist jedoch für die Anforderungen von Falcot Corp. gut geeignet.


NFS-Dateiserver


NFS (Network File System) ist ein Protokoll, das den Fernzugriff auf ein Dateisystem über ein Netzwerk ermöglicht. Alle Unix-Systeme sind in der Lage, mit diesem Protokoll zu arbeiten; wenn Windows-Systeme beteiligt sind, muss stattdessen Samba eingesetzt werden.


NFS


NetzwerkDateisystem


DateisystemNetzwerk


DateiServer


ServerDatei


NFS ist ein sehr nützliches Instrument, aber man darf seine Unzulänglichkeiten nicht außer Acht lassen, insbesondere wo es um Sicherheitsangelegenheiten geht: alle Daten laufen im Klartext über das Netzwerk (ein sniffer kann sie abfangen); der Server verhängt Zugangsbeschränkungen aufgrund der IP-Adresse eines Benutzers (die vorgetäuscht sein kann); und schließlich kann, wenn einem Client-Rechner Zugriff auf eine falsch konfigurierte NFS-Freigabe gewährt wird, der Root-Benutzer des Clients auf alle Dateien dieser Freigabe zugreifen (selbst auf die, die anderen Benutzern gehören), da der Server dem Benutzernamen vertraut, den er vom Client erhält (dies ist ein historisches Handicap des Protokolls).


DOKUMENTATION NFS-HOWTO


Das NFS-HOWTO ist voller interessanter Informationen einschließlich einiger Methoden zur Leistungsoptimierung. Es beschreibt auch einen Weg, um NFS-Übertragungen mit einem SSH-Tunnel abzusichern; dieses Verfahren schließt jedoch die Verwenung von lockd aus.


NFS absichern


NFSSicherheit


Da NFS der Information vertraut, die es vom Netzwerk erhält, muss unbedingt sichergestellt sein, dass sich nur die Rechner, die es benutzen dürfen, mit den verschiedenen erforderlichen RPC-Servern verbinden können. Die Firewall muss außerdem IP spoofing blockieren, um so einen externen Rechner daran zu hindern, sich als interner auszugeben, und der Zugang zu den passenden Ports muss auf die Rechner beschränkt bleiben, die Zugriff auf NFS-Freigabe haben sollen.


ZURÜCK ZU DEN GRUNDLAGEN RPC


RPC (Remote Procedure Call) ist ein Unix-Standard für entfernte Dienste. NFS ist ein solcher Dienst.


RPC


Remote Procedure Call


RPC-Dienste tragen sich in einem als portmapper bekannten Verzeichnis ein. Ein Client, der eine NFS-Anfrage durchführen möchte, wendet sich zunächst an den portmapper (auf Port 111, entweder TCP oder UDP) und fragt nach dem NFS-Server; die Antwort nennt normalerweise Port 2049 (den Standardport für NFS). Nicht alle RPC-Dienste verwenden notwendigerweise einen festen Port.


Weitere RPC-Dienste können erforderlich sein, damit NFS optimal funktioniert, einschließlich rpc.mountd, rpc.statd und lockd. Jedoch verwenden diese Dienste standardmäßig zufällige Ports (vom portmapper zugewiesen), wodurch es schwierig ist, Datenverkehr, der diese Dienste zum Ziel hat, zu filtern. Die Falcot-Corp.-Administratoren haben die unten beschriebene Problemumgehung gefunden.


rpc.mountd


rpc.statd


lockd


portmapper


Die beiden ersten der oben genannten Dienste werden durch Programme auf Anwendungsebene umgesetzt, gestartet durch /etc/init.d/nfs-kernel-server beziehungsweise /etc/init.d/nfs-common. Sie stellen Konfigurationsoptionen zur festen Einstellung bestimmter Ports bereit; die zur Festlegung dieser Optionen zu ändernden Dateien sind /etc/default/nfs-kernel-server und /etc/default/nfs-common.


nfs-kernel-server


/etc/default/nfs-kernel-server


nfs-common


/etc/default/nfs-common


Die Datei /etc/default/nfs-kernel-server


# Number of servers to start up RPCNFSDCOUNT=8 # Options for rpc.mountd RPCMOUNTDOPTS="-p 2048"


Die Datei /etc/default/nfs-common


# Options for rpc.statd. # Should rpc.statd listen on a specific port? # If so, set this variable to a statd argument like: "--port 1000". STATDOPTS="-p 2046 -o 2047" # Are you _sure_ that your kernel does or does not need a lockd daemon? # If so, set this variable to either "yes" or "no". NEED_LOCKD=


Sobald diese Veränderungen vorgenommen und die Dienste neu gestartet sind, verwendet rpc.mountd Port 2048; rpc.statd wartet an Port 2046 auf Anfragen und benutzt Port 2047 für ausgehende Verbindungen.


Der Dienst lockd wird durch einen Kernel-Thread (einen leichtgewichtigen Prozess) verarbeitet; dieses Leistungsmerkmal ist als Modul in Debian-Kernel eingebaut. Das Modul bietet zwei Optionen, um die dauerhafte Einstellung desselben Ports zu ermöglichen, nlm_udpport und nlm_tcpport. Damit diese Optionen konsequent bemutzt werden, muss eine Datei namens /etc/modprobe.d/lockd wie die folgende vorhanden sein:


Die Datei /etc/modprobe.d/lockd


options lockd nlm_udpport=2045 nlm_tcpport=2045


Sobald diese Parameter eingestellt sind, wird es einfacher, von der Firewall aus den Zugang zum NFS-Dienst in feineingestellter Weise durch das Filtern des Zugangs zu den Ports 111 und 2045 bis 2049 (sowohl UDP als auch TCP) zu kontrollieren.


NFS-Server


Der NFS-Server ist Teil des Linux-Kernels; in den von Debian bereitgestellten Kerneln ist er als Kernel-Modul eingebaut. Falls der NFS-Server beim Hochfahren automatisch anlaufen soll, sollte das Paket nfs-kernel-server installiert werden; es enthält die entsprechenden Start-Skripte.


ALTERNATIVE Der Server nfs-user-server


nfs-user-server ist ein NFS-Server, der als traditioneller Server mit einem Anwendungsprogramm und nicht als Kernel-Modul läuft. Diese Version von NFS ist weitgehend überholt, da der kernelbasierte NFS-Server inzwischen ausgereift und zuverlässig ist.


nfs-user-server


Die Konfigurationsdatei des NFS-Servers, /etc/exports, listet die Verzeichnisse auf, die über das Netzwerk zur Verfügung gestellt werden (exported). Zu jeder NFS-Freigabe wird nur der vorgegebenen Liste von Rechnern Zugang gewährt. Eine feiner eingestellte Zugangskontrolle kann durch einige Optionen erzielt werden. Die Syntax dieser Datei ist recht einfach:


exports


/etc/exports


/freizugebendes/verzeichnis rechner1(option1,option2,...) rechner2(...) ...


Jeder Rechner kann entweder durch seinen DNS-Namen oder seine IP-Adresse bestimmt werden. Ganze Rechnergruppen können auch festgelegt werden, indem entweder eine Syntax wie *.falcot.com oder ein IP-Adressbereich wie 192.168.0.0/255.255.255.0 oder 192.168.0.0/24 verwendet wird.


Verzeichnisse werden schreibgeschützt durch die Standardeinstellung (oder durch die Option ro) bereitgestellt. Die Option rw ermöglicht Schreibzugriff. NFS-Clients nehmen typischerweise über einen Port Verbindung auf, der Administratorrechte erfordert (mit anderen Worten, unterhalb von 1024); diese Einschränkung kann mit der Option insecure aufgehoben werden (die Option secure ist stillschweigend eingestellt, kann aber auch ausdrücklich angegeben werden, wenn dies der Deutlichkeit halber erforderlich ist).


NFSOptionen


Standardmäßig beantwortet der Server eine NFS-Anfrage nur dann, wenn der gegenwärtige Plattenzugriff beendet ist (Option sync); dies kann durch die Option async abgestellt werden. Asynchrones Schreiben erhöht die Leistung ein wenig, es verringert jedoch die Zuverlässigkeit, da die Gefahr eines Datenverlusts besteht, falls der Server zwischen der Annahmebestätigung des Schreibauftrags und dem tatsächlichen Schreibvorgang auf der Festplatte abstürzt. Da der voreingestellte Wert (im Vergleich zur früheren Einstellung von NFS) kürzlich geändert wurde, empfiehlt es sich, ihn ausdrücklich einzustellen.


Um einem NFS-Client keinen Root-Zugriff auf das Dateisystem zu geben, werden alle Anfragen, die von einem Root-Benutzer zu kommen scheinen, vom Server so angesehen, als kämen sie vom Benutzer anonymous. Dieses Verhalten entspricht der Option root_squash und ist standardmäßig aktiviert. Die Option no_root_squash, die dieses Verhalten abstellt, ist gefährlich und sollte nur in überwachten Umgebungen eingesetzt werden. Die Optionen anonuid=uid und anongid=gid ermöglichen es, anstelle von anonymous einen anderen gefälschten Benutzer anzugeben.


Weitere Optionen stehen zur Verfügung; sie sind auf der Handbuchseite exports 5 dokumentiert.


VORSICHT Erste Installation


Das Start-Skript /etc/init.d/nfs-kernel-server startet den Server nur dann, wenn /etc/exports eine oder mehrere gültig NFS-Freigaben auflistet. Daher muss der NFS-Server, sobald diese Datei bei der Erstkonfigurierung dahingehend geändert wurde, dass sie gültige Einträge enthält, mit folgendem Befehl gestartet werden:


# /etc/init.d/nfs-kernel-server start


NFS-Client


clientNFS


NFSClient


Wie bei anderen Dateisystemen, so erfordert auch das Einbinden einer NFS-Freigabe in die Systemhierarchie, dass sie eingehängt wird. Da dieses Dateisystem seine Besonderheiten hat, waren einige Anpassungen in den Syntaxen des Befehls mount und der Datei /etc/fstab erforderlich.


Manuelles Einhängen mit dem Befehl mount


# mount -t nfs -o rw,nosuid arrakis.interne.falcot.com:/srv/shared /shared


NFS-Eintrag in der Datei /etc/fstab


arrakis.interne.falcot.com:/srv/shared /shared nfs rw,nosuid 0 0


Der oben dargestellte Eintrag hängt beim Hochfahren des Systems das NFS-Verzeichnis /srv/shared/ des Servers arrakis in das lokale Verzeichnis /shared/ ein. Schreibzugriff ist erfordert (daher der Parameter rw). Die Option nosuid ist eine Schutzmaßnahme, die jegliches setuid- oder setgit-Bit von Programmen, die auf der Freigabe gespeichert sind, entfernt. Falls die NFS-Freigabe nur zum Speichern von Dokumenten dienen soll, ist noexec eine weitere empfohlene Option, die das Ausführen von auf der Freigabe gespeicherten Programmen verhindert.


Die Handbuchseite nfs 5 beschreibt ausführlich alle Optionen.


Einrichten von Windows-Freigaben mit Samba


Samba ist ein Satz von Programmen, die das SMB-Protokoll (jetzt "CIFS" genannt) auf Linux handhaben. Dieses Protokoll wird von Windows für Netzwerk-Freigaben und Netzwerkdrucker benutzt.


Windows-Freigabe


Samba


SMB


CIFS


Samba kann auch als NT-Domain-Controller agieren. Es ist ein hervorragendes Instrument, um die nahtlose Integration von Linux-Servern und Arbeitsplatzrechnern, die noch unter Windows laufen, zu gewährleisten.


Samba-Server


Das Paket samba enthält die beiden Hauptserver von Samba 3, smbd und nmbd.


smbd


nmbd


PROGRAMM Samba mit SWAT verwalten


SWAT (Samba Web Administration Tool) ist eine Webschnittstelle, die es ermöglicht, den Samba-Dienst zu konfigurieren. Da das Paket swat ihre Konfiguration nicht standardmäßig aktiviert, muss sie manuell mit dem Befehl update-inetd --enable swat aktiviert werden.


SWAT


SWAT kann dann über die URL http://localhost:901 erreicht werden. Für den Zugriff wird das Administratorkonto (und sein übliches Passwort) benutzt. Beachten Sie, dass SWAT die Datei smb.conf in seiner eigenen Ausdrucksweise umformuliert. Daher ist es sinnvoll, vorher eine Sicherungskopie anzulegen, falls Sie dieses Programm nur ausprobieren möchten.


SWAT ist sehr benutzerfreundlich; seine Schnittstelle schließt einen Assistenten ein, der es ermöglicht, die Rolle des Servers durch drei Fragen festzulegen. Alle allgemein gültigen Optionen können dann noch konfiguriert werden, wie auch diejenigen für alle vorhandenen Freigaben, und natürlich können neue Freigaben hinzugefügt werden. Jede Option verfügt über einen Link zu ihrer entsprechenden Dokumentation.


DOKUMENTATION Weitere Schritte


Der Samba-Server ist äußerst gut konfigurierbar und vielseitig, kann sehr viele verschiedene Anwendungsfälle bewältigen und sich an sehr unterschiedliche Anforderungen und Netzwerk-Architekturen anpassen. Dieses Buch bezieht sich nur auf die Verwendung von Samba als Haupt-Domain-Controller, aber es kann auch als einfacher Server in der Domain eingesetzt werden und die Authentifizierung an den Hauptcontroller delegieren (der ein Windows-Server sein könnte).


Domain-Controller


NT-Domain


Die im Paket samba-doc vorhandene Dokumentation ist sehr gut geschrieben. Insbesondere behandelt das Dokument Samba 3 By Example (verfügbar als /usr/share/doc/samba-doc/htmldocs/Samba3-ByExample/index.html) einen konkreten Anwendungsfall, der sich Seite an Seite mit einem wachsenden Unternehmen weiterentwickelt.


PROGRAMM Mit einem Windows-Server authentifizieren


Winbind gibt Systemadministratoren die Möglichkeit, einen Windows-NT-Server als Authentifizierungsserver zu verwenden. Winbind integriert auch sauber mit PAM und NSS. Dies ermöglicht es, Linux-Rechner so einzurichten, dass alle Benutzer einer NT-Domain automatisch ein Konto erhalten.


Winbind


Weitere Informationen sind in der Datei /usr/share/doc/samba-doc/htmldocs/Samba3-HOWTO/winbind.html zu finden.


Mit debconf konfigurieren


Das Paket richtet aufgrund der Antworten auf einige Debconf-Fragen, die während der ursprünglichen Installierung gestellt werden, eine minimale Konfiguration ein; diese Konfigurierungsschritte können später mit dpkg-reconfigure samba-common samba erneut abgespielt werden.


Das erste erforderliche Informationsteilstück ist der Name der Arbeitsgruppe, zu der der Samba-Server gehören wird (in unserem Fall lautet die Anwort FALCOTNET). Eine weitere Frage erkundigt sich danach, ob Passwörter verschlüsselt sein sollen. Die Antwort lautet, dass sie es sein sollten, da dies für die jüngsten Windows-Clients vorgeschrieben ist; außerdem erhöht dies die Sicherheit. Anderenfalls wäre es auch erforderlich, die Samba-Passwörter getrennt von den Unix-Passwörtern zu verwalten.


Das Paket schlägt auch vor, den WINS-Server mithilfe der Information, die vom DHCP-Daemon bereitgestellt wird, zu identifizieren. Die Falcot-Corp.-Administratoren haben diese Option abgelehnt, da sie beabsichtigen, den Samba-Server selbst als WINS-Server zu verwenden.


WINS


Die nächste Frage bezieht sich darauf, ob Server mit inetd oder als selbständige Daemons gestartet werden sollen. Die Verwendung von inetd ist nur sinnvoll, wenn Samba selten benutzt wird; die Falcot-Administratoren haben daher selbständige Daemons ausgewählt.


Schließlich schlägt das Programm vor, eine Datei namens /var/lib/samba/passdb.tdb zum Abspeichern verschlüsselter Passwörter zu erstellen; dieser Option wurde zugestimmt, da diese Methode wesentlich effizienter ist als die übliche Textdatei /etc/samba/smbpasswd.


smbpasswd


/etc/samba/smbpasswd


Manuell konfigurieren


Änderungen in smb.conf


Aufgrund der Erfordernisse bei Falcot müssen weitere Optionen in der Konfigurationsdatei /etc/samba/smb.conf angepasst werden. Die folgenden Auszüge fassen die Änderungen zusammen, die im Abschnitt [global] vorgenommen wurden.


[global] ## Browsing/Identification ### # Change this to the workgroup/NT-domain name your Samba server will part of workgroup = FALCOTNET # server string is the equivalent of the NT Description field server string = %h server (Samba %v) # Windows Internet Name Serving Support Section: # WINS Support - Tells the NMBD component of Samba to enable its WINS Server wins support = yes [...] ####### Authentication ####### # "security = user" is always a good idea. This will require a Unix account # in this server for every user accessing the server. See # /usr/share/doc/samba-doc/htmldocs/Samba3-HOWTO/ServerType.html # in the samba-doc package for details. security = user # You may wish to use password encryption. See the section on # 'encrypt passwords' in the smb.conf(5) manpage before enabling. encrypt passwords = true # If you are using encrypted passwords, Samba will need to know what # password database type you are using. passdb backend = tdbsam guest [...] ########## Printing ########## # If you want to automatically load your printer list rather # than setting them up individually then you'll need this load printers = yes # lpr(ng) printing. You may wish to override the location of the # printcap file ; printing = bsd ; printcap name = /etc/printcap # CUPS printing. See also the cupsaddsmb(8) manpage in the # cups-client package. printing = cups printcap name = cups [...] ######## File sharing ######## # Name mangling options ; preserve case = yes ; short preserve case = yes unix charset=ISO8859-1


Zeigt an, dass Samba für das lokale Netzwerk als ein Netbios-Namensserver (WINS) dienen soll.


Dies ist die Standardeinstellung dieses Parameters; da er jedoch für die Samba-Konfiguration wesentlich ist, wird empfohlen, ihn ausdrücklich einzutragen. Jeder Benutzer muss sich vor dem Zugriff auf eine Freigabe authentifizieren.


Weist Samba an, alle lokalen Drucker, die in der CUPS-Konfiguration enthalten sind, freizugeben. Es ist immer noch möglich, den Zugriff auf diese Drucker durch das Hinzufügen entsprechender Abschnitte einzuschränken.


Gibt das verwendete Drucksystem vor; in unserem Fall CUPS.


Legt den Zeichensatz und die Zeichenkodierung, die für Dateinamen unter Linux verwendet werden, fest. Die Standardeinstellung ist UTF8 (Unicode).


Benutzer hinzufügen


Jeder Samba-Benutzer benötigt ein Konto auf dem Server; als erstes müssen die Unix-Konten erstellt, anschließend der Benutzer in Sambas Datenbank eingetragen werden. Der Unix-Schritt verläuft normal (zum Beispiel unter Verwendung von adduser).


Das Hinzufügen eines bestehenden Benutzers zur Samba-Datenbank erfolgt durch den Befehl smbpasswd -a benutzer; dieser Befehl fragt interaktiv nach dem Passwort.


Ein Benutzer kann mit dem Befehl smbpasswd -x benutzer gelöscht werden. Auch ein Samba-Konto kann zeitweilig deaktiviert werden (mit smbpasswd -d benutzer) und später wieder reaktiviert (mit smbpasswd -e benutzer).


Umstellen auf Domain-Controller


Dieser Abschnitt beschreibt, wie die Falcot-Administratoren darüber hinausgingen, indem sie den Samba-Server in einen Domain-Controller umwandelten, der servergespeicherte Profile bereitstellt (die es Benutzern ermöglichen, ihren Arbeitsplatz aufzusuchen unabhängig von dem Rechner, über den sie sich verbinden).


servergespeicherte Profile


Profile, servergespeichert


Zunächst fügten sie einige zusätzliche Anweisungen zum Abschnitt [global] der Konfigurationsdatei hinzu:


domain logons = yes preferred master = yes logon path = \\%L\profiles\%U logon script = scripts/logon.bat


Aktiviert das Leistungsmerkmal Domain-Controller.


Bezeichnet den Ort der Benutzerverzeichnisse. Diese sind auf einer speziellen Freigabe abgespeichert, wodurch das Aktivieren spezifischer Optionen möglich wird (insbesondere profile acls, eine Bedingung für die Kompatibilität mit Windows 2000, XP und Vista).


Bezeichnet das (nicht-interaktive) Batch-Skript, das bei jedem Sitzungsstart auf dem Windows-Client ausgeführt wird. In diesem Fall ist es /var/lib/samba/netlogon/scripts/logon.bat. Das Skript muss im DOS-Format stehen, bei dem die Zeilen durch ein Wagenrücklauf- und ein Zeilenvorschubzeichen getrennt sind; falls die Datei unter Linux erstellt wurde, kann sie mit dem Befehl unix2dos konvertiert werden.


Die in diesen Skripten am meisten benutzten Anweisungen ermöglichen die automatische Erstellung von Netzlaufwerken und das Synchronisieren der Systemzeit.


Die Datei logon.bat


net time \\ARRAKIS /set /yes net use H: /home net use U: \\ARRAKIS\utils


Es wurden auch zwei zusätzliche Freigaben und die dazugehörigen Verzeichnisse erstellt:


[netlogon] comment = Network Logon Service path = /var/lib/samba/netlogon guest ok = yes writable = no share modes = no [profiles] comment = Profile Share path = /var/lib/samba/profiles read only = No profile acls = Yes


Die Benutzerverzeichnisse aller Benutzer müssen ebenfalls erstellt werden (als /var/lib/samba/profiles/benutzer), und jedes von ihnen muss dem passenden Benutzer gehören.


Samba-Client


Die Client-Merkmale in Samba ermöglichen es einem Linux-Rechner, auf Windows-Freigaben und freigegebene Rechner zuzugreifen. Die hierfür benötigten Programme befinden sich in den Paketen smbfs und smbclient.


smbclient


smbfs


Das Programm smbclient


Das Programm smbclient stellt Anfragen an SMB-Server. Es nimmt die Option -U benutzer entgegen, um sich mit dem Server unter einer bestimmten Identität zu verbinden. smbclient //server/freigabe greift interaktiv auf die Freigabe zu in ähnlicher Weise wie der FTP-Client auf der Befehlszeile. smbclient -L server listet alle auf einem Server verfügbaren (und sichtbaren) Freigaben auf.


Windows-Freigaben einhängen


Der Befehl smbmount ermöglicht es, eine Windows-Freigabe in die Linux-Dateisystemhierarchie einzuhängen.


smbmount


Eine Windows-Freigabe einhängen


smbmount //arrakis/shared /shared -o credentials=/usr/local/etc/smb-credentials


Die Datei /usr/local/etc/smb-credentials (die nicht von Benutzern lesbar sein darf) hat das folgende Format:


username = benutzer password = passwort


Weitere Option können auf der Befehlszeile angegeben werden; sie sind auf der Handbuchseite smbmount 1 vollständig aufgelistet. Insbesondere zwei Optionen können interessant sein: uid und gid ermöglichen es, den Benutzer und die Gruppe der am Einhängepunkt verfügbaren Dateien zu erzwingen, um den Zugriff nicht auf den Administrator zu begrenzen.


Der Befehl smbumount hängt eine SMB-Freigabe aus.


ALTERNATIVE mount für eine Windows-Freigabe verwenden


Der Befehl mount selbst verarbeitet CIFS nicht; bei der Aufforderung, ein Dateisystem unbekannten Typs einzuhängen, versucht er jedoch, die Aufgabe an ein mount.typ zu delegieren. Da das Paket smbfs einen Befehl mount.cifs bereitstellt, wird es dann möglich, eine Windows-Freigabe mit dem üblichen mount-Befehl einzuhängen:


mount -t cifs -o credentials=/usr/local/etc/smb-credentials //server/shared /shared


Dies ermöglicht es auch, einen SMB-Einhängepunkt in der normalen /etc/fstab-Datei zu konfigurieren:


//server/shared /shared cifs credentials=/usr/local/etc/smb-credentials


Auf einem Netzwerkdrucker drucken


CUPS ist eine elegante Lösung, um von einem Linux-Arbeitsplatzrechner aus auf einen von einem Windows-Rechner freigegebenen Drucker zu drucken. Wenn das Paket smbclient installiert ist, ermöglicht CUPS es, freigegebene Windows-Rechner automatisch zu installieren.


druckenNetzwerk


Dies sind die erforderlichen Schritte:


Gehen Sie zur CUPS-Konfigurierungsschnittstelle:


http://localhost:631/admin.


Klicken Sie auf "Hinzufügen" und geben die für diesen Drucker passenden Daten ein.


Wenn Sie das Druckgerät auswählen, nehmen Sie "Windows-Printer via SAMBA".


Die URI, die den Drucker bezeichnet, sieht folgendermaßen aus:


smb://benutzer:passwort@server/drucker.


Voilà, der Drucker ist einsatzbereit!


HTTP/FTP-Proxy


Ein HTTP/FTP-Proxy agiert als Vermittler bei HTTP- und FTP-Verbindungen. Er erfüllt eine zweifache Rolle:


Zwischenspeichern: kürzlich heruntergeladene Dokumente werden lokal kopiert, wodurch wiederholtes Herunterladen vermieden wird.


Filter-Server: falls die Benutzung des Proxy vorgeschrieben ist (und ausgehende Verbindungen gesperrt werden, wenn sie nicht über den Proxy laufen), kann der Proxy bestimmen, ob die Anfrage erlaubt wird oder nicht.


HTTP/FTP-Proxy


Proxy-Cache


Falcot Corp. hat Squid als ihren Proxy-Server ausgewählt.


Squid


Installieren


Das Debian-Paket squid enthält nur den modularen (zwischenspeichernden) Proxy. Das Paket squidguard muss zusätzlich installiert werden, um ihn in einen Filter-Server umzuwandeln. Zusätzlich stellt squid-cgi eine Anfrage- und Verwaltungsschnittstelle für einen Squid-Proxy bereit.


Vor dem Installieren sollte sichergestellt werden, dass das System seinen eigenen vollständigen Namen feststellen kann: der Befehl hostname -f muss einen vollqualifizierten Namen (einschließlich einer Domain) ergeben. Anderenfalls sollte die Datei /etc/hosts so editiert werden, dass sie den vollständigen Namen des Systems (zum Beispiel arrakis.falcot.com) enthält. Der vollständige Rechnername sollte vom Netz-Administrator bestätigt werden, um mögliche Namenskonflikte zu vermeiden.


Einen Cache konfigurieren


Das Aktivieren der Zwischenspeicherung des Servers geschieht einfach dadurch, dass die Konfigurationsdatei /etc/squid/squid.conf editiert und es so Rechnern des lokalen Netzwerk erlaubt wird, Anfragen durch den Rechner zu leiten. Das folgende Beispiel zeigt die von den Falcot-Corp.-Administratoren vorgenommenen Veränderungen:


Die Datei /etc/squid/squid.conf (Auszüge)


# GEBEN SIE HIER IHRE EIGENEN REGELN EIN, UM ZUGRIFF VON ALLEN CLIENTS AUS ZU ERLAUBEN # Beispiel-Regel um Zugriff von Ihren lokalen Netzwerken zu erlauben. Passen # Sie sie an, so dass sie Ihre (internen) Netzwerke auflisten, von denen aus das Browsen # erlaubt sein soll acl our_networks src 192.168.1.0/24 192.168.2.0/24 http_access allow our_networks http_access allow localhost # Und schließlich verweigern Sie alle sonstigen Zugriffe auf diesen Proxy http_access deny all


Einen Filter konfigurieren


squid selbst führt die Filterung nicht durch; dieser Arbeitsgang wird an squidGuard delegiert. Ersteres muss dann konfiguriert werden, um mit letzterem zu interagieren. Hierzu wird folgende Anweisung zur Datei /etc/squid/squid.conf hinzugefügt:


squidGuard


redirect_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf


Das CGI-Programm /usr/lib/cgi-bin/squidGuard.cgi muss ebenfalls installiert werden, wobei die Datei /usr/share/doc/squidguard/examples/squidGuard.cgi.gz als Ausgangspunkt dient. In diesem Skript müssen die Variablen $proxy und $proxymaster angepasst werden (der Name des Proxy und die E-Mail-Adresse des Administrators). Die Variablen $image und $redirect sollten auf bestehende Abbilder zeigen, die die Ablehnung einer Anfrage darstellen.


Der Filter wird mit dem Befehl /etc/init.d/squid reload aktiviert. Da das Paket squidguard jedoch nicht standardmäßig Filterungen durchführt, ist es Aufgabe des Administrators, die Richtlinien festzulegen. Dies kann durch Anpassung der Datei /etc/squid/squidGuard.conf geschehen.


Die aktive Datenbank muss nach jeder Änderung der Konfigurationsdatei squidGuard (oder einer der Domain- beziehungsweise URL-Listen, die sie nennt) mit dem Befehl update-squidguard aktualisiert werden. Die Syntax der Konfigurationsdatei ist auf der folgenden Website dokumentiert:


update-squidguard


ALTERNATIVE DansGuardian


dansguardian


PICS


Das Paket dansguardian stellt eine Alternative zu squidguard dar. Dieses Programm verwaltet nicht einfach eine schwarze Liste verbotener URLs, sondern kann sich das PICS-System (Platform for Internet Content Selection) zu Nutze machen, indem es den Inhalt einer Seite dynamisch analysiert, um zu entscheiden, ob sie zulässig ist.


LDAP-Verzeichnis


LDAP


OpenLDAP


Verzeichnis, LDAP


OpenLDAP ist eine Umsetzung des LDAP-Protokolls; mit anderen Worten, es ist eine Spezialdatenbank zum Speichern von Verzeichnissen. Im gebräuchlichsten Anwendungsfall wird es durch die Verwendung eines LDAP-Servers ermöglicht, die Verwaltung von Benutzerkonten und den zugehörigen Berechtigungen zusammenzufassen. Außerdem lässt sich eine LDAP-Datenbank leicht kopieren, was die Einrichtung mehrerer synchronisierter LDAP-Server ermöglicht. Wenn das Netzwerk und die Benutzerzahl schnell anwachsen, kann so die Arbeitslast zwischen mehreren Servern ausgeglichen werden.


LDAP-Daten sind strukturiert und hierarchisch. Die Struktur wird durch "Schemata" festgelegt, die die Art der Objekte, die die Datenbank speichern kann, zusammen mit einer Liste all ihrer möglichen Attribute beschreiben. Die Syntax, die zum Verweis auf ein bestimmtes Objekt der Datenbank verwendet wird, basiert auf diesen Strukturen, was ihre Komplexität erklärt.


Das Paket slapd enthält den OpenLDAP-Server. Das Paket ldap-utils umfasst Befehlszeilen-Werkzeuge für das Zusammenwirken mit LDAP-Servern.


slapd


Beim Installieren von slapd werden normalerweise einige debconf-Fragen gestellt; diese Konfigurierungsphase kann durch den Befehl dpkg-reconfigure slapd erzwungen werden.


Konfigurierung des OpenLDAP-Servers auslassen? Natürlich nicht, wir wollen diesen Dienst konfigurieren.


DNS-Domain-Name: “falcot.com”.


Name der Organisation: “Falcot Corp”.


Ein Verwaltungspasswort muss eingegeben werden.


Zu verwendendes Datenbank-Backend: "HDB".


Möchten Sie, dass die Datenbank entfernt wird, wenn slapd gelöscht wird? Nein. Es wäre nicht sinnvoll, den Verlust der Datenbank im Falle eines Versehens zu riskieren.


Die alte Datenbank verschieben? Diese Frage wird nur gestellt, wenn die Konfigurierung vorgenommen wird, während eine Datenbank bereits existiert. Antworten Sie nur mit "ja", wenn Sie tatsächlich wieder mit einer leeren Datenbank beginnen möchten, zum Beispiel, wenn Sie dpkg-reconfigure slapd unmittelbar nach der ersten Installierung ausführen.


Das LDAPv2-Protokoll erlauben? Nein, das macht keinen Sinn. Alle Programme, die wir verwenden werden, verstehen das LDAPv3-Protokoll.


ZURÜCK ZU DEN GRUNDLAGEN Das LDIF-Format


Eine LDIF-Datei (LDAP Data Interchange Format) ist eine übertragbare Textdatei, die den Inhalt einer LDAP-Datenbank (oder einen Teil davon) beschreibt; sie kann dann dazu verwendet werden, die Daten auf einem beliebigen anderen LDAP-Server einzuspeisen.


LDIF


Eine minimale Datenbank ist jetzt konfiguriert, wie durch die folgende Anfrage dargelegt:


$ ldapsearch -x -b dc=falcot,dc=com # extended LDIF # # LDAPv3 # base <dc=falcot,dc=com> with scope sub # filter: (objectclass=*) # requesting: ALL # # falcot.com dn: dc=falcot,dc=com objectClass: top objectClass: dcObject objectClass: organization o: Falcot Corp dc: falcot # admin, falcot.com dn: cn=admin,dc=falcot,dc=com objectClass: simpleSecurityObject objectClass: organizationalRole cn: admin description: LDAP administrator # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2


Die Anfrage ergab zwei Objekte: die Organisation selbst und den verwaltenden Benutzer.


Das Verzeichnis ausfüllen


Da eine leere Datenbank nicht sehr nützlich ist, werden wir alle bestehenden Verzeichnisse in sie einspeisen; dies umfasst die Benutzer-, Gruppen-, Dienst- und Host-Datenbanken.


Das Paket migrationtools stellt einen Satz von Skripten bereit, die dazu bestimmt sind, Daten aus den Standard-Unix-Verzeichnissen (/etc/passwd, /etc/group, /etc/services, /etc/hosts und so weiter) zu extrahieren, diese Daten zu konvertieren und sie in die LDAP-Datenbank einzuspeisen.


migrationtools


Nachdem das Paket installiert ist, muss die Datei /etc/migrationtools/migrate_common.ph editiert werden; die Optionen IGNORE_UID_BELOW and IGNORE_GID_BELOW müssen aktiviert werden (es genügt, sie auszukommentieren).


Der tatsächliche Übertragungsvorgang wird durch den Befehl migrate_all_online.sh folgendermaßen ausgeführt:


# cd /usr/share/migrationtools # LDAPADD="/usr/bin/ldapadd -c" ETC_ALIASES=/dev/null ./migrate_all_online.sh


Das Skript migrate_all_online.sh stellt einige Fragen zu der LDAP-Datenbank, auf die die Daten übertragen werden sollen. fasst die Antworten zusammen, die im Anwendungsfall Falcot gegeben wurden.


Antworten auf die vom Skript migrate_all_online.sh gestellten Fragen


Frage


Antwort


X.500 Benennungskontext


dc=falcot,dc=com


Hostname des LDAP-Servers


localhost


Manager-DN


cn=admin,dc=falcot,dc=com


Verbindungslegitimation


das Verwaltungspasswort


Ein DUAConfigProfil anlegen


nein


Wir haben bewusst die Übertragung der Datei /etc/aliases außer Acht gelassen, da das von Debian bereitgestellte Standardschema nicht die Strukturen enthält, die dieses Skript zur Beschreibung der E-Mail-Aliasse verwendet. Falls wir diese Daten in das Verzeichnis integrieren möchten, müsste die Datei /etc/ldap/schema/misc.schema zum Standardschema hinzugefügt werden.


HILFSPROGRAMM Ein LDAP-Verzeichnis durchsuchen


Das Programm luma (im gleichnamigen Paket) ist ein grafisches Hilfsprogramm, das es ermöglicht, eine LDAP-Datenbank zu durchsuchen und zu editieren. Es ist ein interessantes Programm, das einem Administrator einen guten Überblick über die hierarchische Struktur der LDAP-Daten gibt.


luma


Beachten Sie auch die Verwendung der Option -c des Befehls ldapadd; diese Option bestimmt, dass der Verarbeitungsablauf im Falle eines Fehlers nicht abgebrochen wird. Die Verwendung dieser Option ist notwendig, da die Konvertierung der Datei /etc/services häufig einige Fehler hervorruft, die ohne Gefahr ignoriert werden können.


Konten mit LDAP verwalten


Jetzt, da die LDAP-Datenbank einige nützliche Informationen enthält, ist es an der Zeit diese Daten zu nutzen. Dieser Abschnitt richtet sein Augenmerk darauf, wie ein Linux-System so zu konfigurieren ist, dass die verschiedenen Systemverzeichnisse die LDAP-Datenbank benutzen.


NSS konfigurieren


Das NSS-System (Name Service Switch, siehe Seitenleiste ) ist ein modulares System, das dafür ausgelegt ist, Informationen für Systemverzeichnisse festzulegen oder einzuholen. Um LDAP als Datenquelle für NSS verwenden zu können, muss das Paket libnss-ldap installiert werden. Bei seiner Installierung werden einige Fragen gestellt; die Antworten sind in zusammengefasst.


libnss-ldap


Das Paket libnss-ldap konfigurieren


Uniform Resource Identifier des LDAP-Servers


ldap://ldap.falcot.com


Kennzeichnender Name der Suchbasis


Zu verwendende LDAP-Version


3


Benötigt die LDAP-Datenbank eine Anmeldung?


nein


LDAP-Administratorkonto


Passwort des LDAP-Administratorkontos


Die Datei /etc/nsswitch.conf muss nun angepasst werden, um NSS so zu konfigurieren, dass es das neu installierte ldap-Modul benutzt.


Die Datei /etc/nsswitch.conf


# /etc/nsswitch.conf # # Example configuration of GNU Name Service Switch functionality. # If you have the `glibc-doc' and `info' packages installed, try: # `info libc "Name Service Switch"' for information about this file. passwd: ldap compat group: ldap compat shadow: ldap compat hosts: files dns ldap networks: ldap files protocols: ldap db files services: ldap db files ethers: ldap db files rpc: ldap db files netgroup: files


Das ldap-Modul wird normalerweise vor den anderen aufgenommen und wird daher zuerst abgefragt. Eine beachtenswerte Ausnahme stellt der hosts-Dienst dar, da zunächst DNS befragt werden muss (um ldap.falcot.com aufzulösen), bevor mit dem LDAP-Server Verbindung aufgenommen werden kann. Ohne diese Ausnahme, würde eine Anfrage nach einem Hostnamen an den LDAP-Server gerichtet; dies würde eine Namensauflösung für den LDAP-Server auslösen, und so weiter in einer unendlichen Schleife. Was die netgroup-Dienste angeht, so werden sie noch nicht vom LDAP-Modul verarbeitet.


Falls der LDAP-Server als maßgeblich angesehen werden soll (und die lokalen vom Modul files benutzten Dateien ignoriert werden sollen), können die Dienste mit der folgenden Syntax konfiguriert werden:


service: ldap [NOTFOUND=return] files.


Falls der gesuchte Eintrag in der LDAP-Datenbank nicht vorhanden ist, wird die Anfrage die Antwort "nicht vorhanden" ergeben, selbst wenn die Quelle in einer der lokalen Dateien vorkommen sollte; diese lokalen Dateien werden nur benutzt, wenn der LDAP-Service abgeschaltet ist.


PAM konfigurieren


Dieser Abschnitt beschreibt die Konfigurierung von PAM (siehe Seitenleiste ), die es Anwendungen ermöglicht, die gegenüber der LDAP-Datenbank erforderlichen Authentifizierungen durchzuführen.


VORSICHT Defekte Authentifizierung


Die Änderung der von verschiedenen Programmen verwendeten standardmäßigen PAM-Konfiguration ist ein heikler Vorgang. Ein Fehler kann zu einer defekten Authentifizierung führen, die ein Anmelden verhindern könnte. Es ist daher eine gute Vorsichtsmaßnahme, eine Root-Konsole offen zu halten. So können mit geringem Aufwand eventuell auftretende Konfigurierungsfehler behoben und Dienste neu gestartet werden.


Das LDAP-Modul für PAM wird von dem Paket libpam-ldap bereitgestellt. Beim Installieren dieses Pakets werden einige Fragen gestellt, die denen bei libnss-ldap ähnlich sind; einige Konfigurationsparameter (wie zum Beispiel die URI des LDAP-Servers) werden sogar mit dem Paket libnss-ldap gemeinsam benutzt. Die Antworten sind in zusammengefasst.


libpam-ldap


Konfigurierung von libpam-ldap


Dem LDAP-Administrationskonto erlauben, sich wie lokales Root zu verhalten?


Ja. Dies ermöglicht es, den normalen passwd-Befehl zur Änderung von Passwörtern zu verwenden, die in der LDAP-Datenbank gespeichert sind.


Erfordert die LDAP-Datenbank eine Anmeldung?


das Verwaltungspasswort der LDAP-Datenbank


Durch das Installieren von libpam-ldap wird die standardmäßige PAM-Konfiguration, die in den Dateien /etc/pam.d/common-auth, /etc/pam.d/common-password und /etc/pam.d/common-account festgelegt ist, automatisch angepasst. Dieser Vorgang verwendet das spezielle Hilfsprogramm pam-auth-update (vom Paket libpam-runtime bereitgestellt). Dieses Programm kann auch vom Administrator eingesetzt werden, falls er PAM-Module aktivieren oder deaktivieren möchte.


common-auth


/etc/pam.d/common-auth


common-password


/etc/pam.d/common-password


common-account


/etc/pam.d/common-account


LDAP-Datenaustausch absichern


LDAPabgesichert


Standardmäßig überträgt das LDAP-Protokoll im Klartext über das Netzwerk; dies gilt auch für die (verschlüsselten) Passwörter. Da die verschlüsselten Passwörter aus dem Netzwerk entnommen werden können, können sie anfällig für Wörterbuchangriffe sein. Dies kann durch den Einsatz einer zusätzlichen Verschlüsselungsschicht verhindert werden; die Aktivierung dieser Schicht ist das Thema dieses Abschnitts.


Den Server konfigurieren


OpenSSLSchlüssel erzeugen


Schlüsselpaar


Der erste Schritt besteht darin, für den LDAP-Server ein Schlüsselpaar (bestehend aus einem öffentlichen und einem privaten Schlüssel) zu erzeugen. Hierfür ist es erforderlich, das Paket openssl zu installieren. Beim Aufruf von /usr/lib/ssl/misc/CA.pl -newcert werden einige banale Fragen gestellt (Ort, Name der Organisation und so weiter). Als Antwort auf die Frage nach dem gemeinsamen Namen muss der vollständig qualifizierte Hostname des LDAP-Servers angegeben werden; in unserem Fall ldap.falcot.com.


Dieser Befehl erstellt ein Zertifikat in der Datei newcert.pem; der dazugehörige private Schlüssel wird in der Datei newkey.pem abgespeichert.


Nun müssen diese Schlüssel an ihrem standardisierten Ort installiert werden:


# mv newkey.pem /etc/ssl/private/ldap-key.pem # chmod 0600 /etc/ssl/private/ldap-key.pem # mv newcert.pem /etc/ssl/certs/ldap-cert.pem


Dem Daemon slapd muss außerdem mitgeteilt werden, dass er diese Schlüssel für die Verschlüsselung verwenden soll; hierzu muss folgende Anweisung zur Datei /etc/ldap/slapd.conf hinzugefügt werden:


slapd für eine Verschlüsselung konfigurieren


# TLS support TLSCipherSuite HIGH TLSCertificateFile /etc/ssl/certs/ldap-cert.pem TLSCertificateKeyFile /etc/ssl/private/ldap-key.pem


Der letzte Schritt zur Aktivierung der Verschlüsselung besteht darin, die Variable SLAPD_SERVICES in der Datei /etc/default/slapd zu ändern. Wir gehen dabei auf Nummer Sicher und deaktivieren nicht abgesichertes LDAP vollständig.


Die Datei /etc/default/slapd


# Default location of the slapd.conf file SLAPD_CONF= # System account to run the slapd server under. If empty the server # will run as root. SLAPD_USER= # System group to run the slapd server under. If empty the server will # run in the primary group of its user. SLAPD_GROUP= # Path to the pid file of the slapd server. If not set the init.d script # will try to figure it out from $SLAPD_CONF (/etc/ldap/slapd.conf) SLAPD_PIDFILE= # Configure if the slurpd daemon should be started. Possible values: # - yes: Always start slurpd # - no: Never start slurpd # - auto: Start slurpd if a replica option is found in slapd.conf # (default) SLURPD_START=auto # slapd normally serves ldap only on all TCP-ports 389. slapd can also # service requests on TCP-port 636 (ldaps) and requests via unix # sockets. # Example usage: SLAPD_SERVICES="ldaps:/// ldapi:///" # Additional options to pass to slapd and slurpd SLAPD_OPTIONS="" SLURPD_OPTIONS=""


Den Client konfigurieren


Auf der Client-Seite muss die Konfiguration der Module libpam-ldap und libnss-ldap angepasst werden, indem die Anweisung ssl on zu den Konfigurationsdateien /etc/pam_ldap.conf und /etc/libnss-ldap.conf hinzugefügt wird.


Damit LDAP-Clients in der Lage sind, den Server zu authenfizieren, müssen sie seinen öffentlichen Schlüssel kennen. Hierzu muss eine Kopie des Schlüssels (zum Beispiel als /etc/ssl/certs/ldap-cert.pem) installiert werden, und auf den Ort dieser Kopie in der Datei /etc/ldap/ldap.conf verwiesen werden.


Die Datei /etc/ldap/ldap.conf


# # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. BASE dc=falcot,dc=com URI ldaps://ldap.falcot.com #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never TLS_CACERT /etc/ssl/certs/ldap-cert.pem


Dieses Kapitel hat nur einen Bruchteil der verfügbaren Serversoftware dargestellt; jedoch wurden die meisten der üblichen Netzwerkdienste beschrieben. Jetzt ist es Zeit für ein noch technischeres Kapitel: wir werden tiefer in die Einzelheiten einiger Konzepte eindringen, sowie Masseneinsätze und Virtualisierungen beschreiben.