home | gallery | blog | contact Diese Website ist allenfalls für Leute interessant, die mich kennen.
This Website is solely of interest to people who know me, if at all.
Daniels Homepage

stuff i tinker with
Mitsubishi AMiTY Laptop
Verschlüsselte Dateisysteme
Palm Pilot Potpourri
VPS mit Debian
TechniSat TechniPlayer
Openmoko Freerunner
GTD mit TiddlyWiki
bastelkram
 
last change
14. September 2014
letzte Änderung
 

Linux Debian Sarge Etch VPS OpenVZ Virtuozzo

VPS-Umrüstung nach Debian 3.1 "Sarge" (und "Etch")

Diese Anleitung habe ich geschrieben, damit ich in einem Jahr noch weiss, was alles zu tun ist, falls ich meinen VPS wieder umstellen will oder muss. Da VPS-Hosting recht beliebt zu sein scheint (immerhin kriegt man einen "eigenen Server" mit root-Rechten für unter 10 Euro im Monat), hoffe ich, dass diese Anleitung auch anderen VPS-Betreibern nützlich ist.
Die Auswahl der Server-Software ist überlegt, aber insofern subjektiv, als dass sie meinem persönlichen Geschmack und meinem konkreten Anwendungsfall entspricht. So habe ich z.B. Postfix als MTA auch deshalb gewählt, weil es der MTA ist, mit dem ich mich am besten auskenne. qmail oder sendmail würden es natürlich auch tun. Ausserdem brauche ich z.B. keine Datenbank - wer ein Wiki oder ein Forum betreiben will, benötigt in der Regel ein MySQL. Andererseits kann man, ausgehend von dem mit dieser Anleitung aufgesetzen System, praktisch jeden gewünschten Dienst nachrüsten.

Achja: Normalerweise würde man natürlich Informationen, wie sie in der nachfolgenden Anleitung enthalten sind, über das eigene Server-System eher nicht so freizügig preisgeben. "Security through obscurity" ist zwar verpönt, aber das Silbertablett sollte es nun auch nicht gerade sein...

History

20. Jul 2008:  Mein Debian-VPS hatte eine Uptime von mehr als einem Jahr, als ich mich vorgestern entschloss, auf Debian 4.0 "Etch" "upzugraden" (was ein Wort). Für "Sarge" gibt es nun auch schon seit mehreren Monaten keine Updates mehr und ich war ob des schlechten Wetters in Bastellaune. Das "Gastgeber"-System meines VPS läuft noch mit Kernel 2.4, den "Etch" offiziell nicht unterstützt. In der Praxis ist es jedoch so, dass das "Etch"-Basissystem mit Kernel 2.4 läuft und "nur" einige bestimme Anwendungen (z.B. Squid) nicht laufen.
Ich bin wie folgt vorgegangen:

  1. Backup wie unten beschrieben.
  2. apt-get dist-upgrade
    
  3. /etc/apt/sources.list so ändern, dass überall auf die Quellen für "Etch" anstatt "Sarge" verwiesen wird ("sarge" durch "etch" ersetzen).
  4. apt-get update
    apt-get install apt
    apt-get update
    apt-get dist-upgrade
    
    Ich habe alle Fragen zu den neuen Paketen mit der voreingestellten Antwort bestätigt und insbesondere bei den Konfigurationsdateien der für meinen VPS wichtigen Dienste die "alte" Konfiguration übernommen.
  5. Mit aptitude -i noch nicht aufgelöste Paket-Abhängigkeiten auflösen und ggf. Pakete nachinstallieren.
  6. Reboot per "Virtuozzo"
Ich war bass erstaunt, als mein VPS nach dem Reboot voll funktionsfähig hochkam, ohne dass ich nur eine einzige Konfigurationsdatei hätte anfassen müssen. Auch wenn da sicherlich eine gehörige Portion Glück im Spiel war: Meinen Respekt den Debian-Entwicklern. Ich habe nochmal anhand meiner Anleitung unten alles durchgesehen - es geht. Es waren wirklich nur kosmetische Kleinigkeiten zu ändern (beim saslauthd hat sich das Bootskript ziemlich geändert, das muss ich bei Gelegenheit nochmal "schönmachen"). Von den alten Paketen (z.B. Postfix, Apache) sind teilweise noch die Konfigurationsdateien übrig geblieben (und werden als noch installiertes Paket, Status "rc" gelistet). Ansonsten ist die alte Konfigurationsdatei da und der Installer hat die Default-Konfiguration als .dpkg-dist dabeigeschrieben.
Mein neu installiertes VPS ist natürlich ein Kompromiss: Ich muss damit rechnen, dass ein neuer Dienst, den ich vielleicht mal installieren möchte, nicht funktioniert. Ausserdem sind z.B. die falschen Kernel-Headers installiert, d.h. es wird Schwierigkeiten mit selbstkompilierten oder gar entwickelten Sachen geben. Da mein VPS aber eher zum Basteln da ist, kann ich mit sowas leben. Im Ernstfall kann ich meinen Hoster immer noch beauftragen, meinen VPS auf ein neueres System umzuziehen.
Liste der installierten Pakete (Etch)

26. Aug 2007:  Kleinere Korrekturen und Ergänzungen (Mail syslog Bsp., Postfix SSL certs file perm., saslauthd pid-file).

19. Aug 2007:  Erste "vollständige" Version (d.h. inetwa so, wie ich mir den Text vor einem Monat vorgestellt habe ;-) Etwas machen und etwas dokumentieren sind doch zwei Paar Schuhe...
Fehler gefunden? Besser hingekriegt? -> daniel(-at-)bischof.org

15. Jul 2007:  Erste Version.


Ausgangssituation

VPS mit OpenVZ/Virtuozzo bei einem kommerziellen Anbieter. Das installierte Linux ist veraltet und soll komplett ersetzt werden. Die Administration erfolgt per "Plesk". Der VPS ist Primary DNS für die eigene Domain, Mail- und Webserver. Der Domainname sei "meinvps.de", der Hostname "knurzel.meinvps.de" und die IP-Adresse 11.22.33.44 (für die u.g. Beispielkonfigurationen).

Ziel

Installation von Debian "Sarge" (einziges Linux, das auf dem "Gastgeber"-System mit Kernel 2.4 läuft und für das es noch Updates gibt - besser wäre natürlich das neueste Debian stable, derzeit "Etch"). Der umgerüstete VPS soll die gleichen Aufgaben erfüllen wie vorher, jedoch soweit wie möglich abgespeckt werden (kein "Plesk", alle nicht benötigten Dienste verschwinden). Die Administration erfolgt per ssh-Zugang vom heimischen DSL und mit den üblichen Unix-Tools, insbesondere dem vi-Texteditor.

Vorbereitung

  • Abstellen von Mail-Umleitungen nach meinvps.de

    Ich habe ein paar Mailadressen, die ich nach meinvps.de umleite. Damit ich die Mails für diese Adressen auch ohne funktionierenden knurzel.meinvps.de lesen kann, hebe ich die Umleitungen temporär auf, bis alles wieder sauber läuft. Überhaupt ist jetzt der richtige Zeitpunkt, darüber nachzudenken, was passiert, wenn knurzel.meinvps.de nicht läuft?

  • Backup der wichtigen Daten vom alten VPS

    Ein

    tar -cvzf oldknurzel.tar.gz /etc /root /var/lib/named /home
    
    reicht bei mir. Evtl. muss man noch an das DocumentRoot des Webservers denken, einen MySQL-Dump machen, /var/spool/mail sichern, usw. usf. Je nachdem, was man vorher betrieben hat.

Debian-Installation

Im Zuge des nachfolgend beschriebenen Vorgehens wird mittels des Virtuozzo "Repair Mode" ein temporäres "Reparatur-VPS" erzeugt, auf dem man sich mittels ssh einloggen kann. Das Root-Filesystem des zu erneuernden VPS ist unter /repair gemountet. Man löscht alle Dateien darin und installiert mittels debootstrap ein neues Debian, an dem man ein noch ein paar Kleinigkeiten konfigurieren muss, bevor man den "Repair Mode" verlässt und das neue, frisch installierte System starten kann (um danach die benötigten Dienste zu konfigurieren).
  • "Virtuozzo Power Panel" -> "Repair Mode" starten

    https://11.22.33.44:4643/
    Login als "root", Menuepunkt "Repair Mode". Der Browser bleibt offen, bis die Installation des neuen Debian "Sarge" abgeschlossen ist (s.u.).

  • altes root-Filesystem löschen

    Mit

    ssh -l root 11.22.33.44
    
    auf dem temporären VPS einloggen und mit
    rm -rf /repair/*
    
    das alte Linux komplett löschen (Backup haben wir doch gemacht, oder? ;-)
    Im Fall eines ext2/ext3-Filesystems muss man das Verzeichnis lost+found (also /repair/lost+found) stehenlassen oder mit dem Befehl mklost+found neu anlegen. Dieses Verzeichnis wird von den Systemprogrammen für diesen Filesystemtyp benötigt.

  • debootstrap-Paket installieren

    Was genau man für ein Paket braucht, hängt von der Distribution auf dem temporären Reparatur-VPS ab. Bei mir entsprach das Reparatur-VPS meinem alten VPS, also SuSE Linux 9.1. SuSE Linux benutzt RPM als Paket-Manager, also braucht man debootstrap als RPM-Paket.

  • mit debootstrap Debian "Sarge" in /repair installieren
    debootstrap --arch i386 sarge /repair \
    ftp://ftp.hosteurope.de/mirror/ftp.debian.org/debian
    
    Der FTP-Server in dem o.g. Kommando ist ein Beispiel. Es gibt etliche Debian-Mirrors; man sollte den des eigenen Hosters verwenden oder, falls dieser keinen hat, ftp://ftp.de.debian.org/debian

  • erforderliche Änderungen am frisch installierten Debian (fürs erste)

    Man ändert natürlich die Dateien unterhalb von /repair, nicht die des Reparatur-VPS.

    • /repair/etc/hosts
      Lokale IP-Adressen/Hostnamen-Tabelle (muss neu erzeugt werden).
      Meine /etc/hosts

    • /repair/etc/network/interfaces
      In dieser Datei werden die Netzwerkinterfaces des VPS konfiguriert.
      Meine /etc/network/interfaces

    • /repair/etc/fstab
      Filesystem-/Mountpoint-Tabelle.
      Meine /etc/fstab

    • /repair/etc/apt/sources.list
      In dieser Datei werden die Quellen zur Installation von (Update-) Paketen festgelegt (muss neu erzeugt werden).
      Meine /etc/apt/sources.list

    • /repair/etc/inittab
      In der inittab müssen die Einträge zum Starten der gettys für die Konsole auskommentiert werden, also:
      [...]
      # /sbin/getty invocations for the runlevels.
      [...]
      #1:2345:respawn:/sbin/getty 38400 tty1
      #2:23:respawn:/sbin/getty 38400 tty2
      #3:23:respawn:/sbin/getty 38400 tty3
      #4:23:respawn:/sbin/getty 38400 tty4
      #5:23:respawn:/sbin/getty 38400 tty5
      #6:23:respawn:/sbin/getty 38400 tty6
      [...]
      
  • "Change root" in die neue Debian-Installation
    mount -t proc /proc /repair/proc
    mount -t devpts /dev/pts /repair/dev/pts
    chroot /repair /bin/bash
    source /etc/profile
    
  • die Paketlisten der Installationsquellen lokal bekanntmachen und OpenSSH installieren
    apt-get update
    apt-get install locales ssh
    
    Die Fragen für das OpenSSH-Paket kann man alle wie vorgegeben beantworten, beim locales-Paket habe ich "en_US.UTF-8" als Default gewählt.

  • Neustart des VPS

    Neues (starkes!) Passwort für "root" setzen, sshd stoppen, /repair/proc und /repair/dev/pts aushängen:

    passwd
    /etc/init.d/ssh stop
    exit
    
    Jetzt ist man wieder im Rettungs-VPS.
    cd /
    umount /repair/proc
    umount /repair/dev/pts
    
    Im "Virtuozzo Power Panel" den "Repair Mode" mittels "Finish Repair" verlassen und dann unter "Start/Stop VPS" "Restart VPS" wählen.

Wenn alles glattgegangen ist, läuft der VPS jetzt mit Debian "Sarge" und harrt der Konfiguration der benötigten Dienste. Man kann sich als "root" per ssh einloggen. Wenn was schiefgegangen ist, muss man den "Repair Mode" nochmals bemühen und Fehlersuche betreiben. Mit als erstes sollte man jetzt mittels base-config einen "normalen" Benutzer anlegen und die Zeitzone einstellen. Finger weg von "Select and install packages" in base-config! Diese Funktion bügelt gnadenlos Software-Pakete über den bereits installierten Satz von Paketen drüber, deshalb Pakete lieber nach Bedarf mit apt-get installieren (s.u.).

Eine Reihe von Paketen der Standard-Installation sind i.d.R für den VPS-Serverbetrieb nicht erforderlich (1. Zeile) bzw. nicht erwünscht (2. Zeile) und sollten deinstalliert werden:

dpkg -r pppoe pppoeconf ppp pppconfig pcmcia-cs
dpkg -r nfs-common portmap lpr pidentd

Als nützlich erweisen kann sich die Installation der folgenden Pakete: Text-only Webbrowser (1. Zeile), sicheres Löschen von Dateien (2. Zeile), Packer (3. Zeile) und sonstige Tools (4. Zeile).

apt-get install w3m lynx
apt-get install wipe
apt-get install bzip2 unzip zip
apt-get install wget ncftp fileutils

Dienste - DNS

Zum Einsatz kommt ISC BIND Version 9, Debian Paket "bind9" (Server). Gleich mitinstallieren sollte man die DNS-relevanten Pakete "bind9-host" (host-Befehl) und "dnsutils" (dig-Befehl) sowie "whois" mit dem gleichnamigen Befehl zur Abfrage von Domain-Registrys:

apt-get install bind9 bind9-host dnsutils whois

Standardmässig läuft der BIND9-named nicht chrooted - das rüstet man an dieser Stelle nach. Die Rolle des Secondary DNS für meinvps.de übernimmt der Server secondarydns.hoster.de mit der IP 7.8.9.10, der vom Hoster betrieben und von knurzel (Primary DNS) per zone transfer aktuell gehalten wird.

Debian neigt dazu, alles, was man frisch installiert hat, auch gleich zu starten, deshalb befiehlt man ein prophylaktisches

/etc/init.d/bind9 stop
bevor man mit den Konfigurationsänderungen am BIND9-named beginnt.

Erforderliche Änderungen am frisch installierten Debian:

  • Neue Verzeichnisse in /var/lib
    mkdir /var/lib/named
    mkdir /var/lib/named/etc
    mkdir /var/lib/named/dev
    mkdir -p /var/lib/named/var/run/bind/run
    mkdir -p /var/lib/named/var/cache/bind
    chown -R bind.bind /var/lib/named/var/*
    mv /etc/bind /var/lib/named/etc
    chown -R bind.bind /var/lib/named/etc/bind
    ln -s /var/lib/named/etc/bind /etc/bind
    
  • Character special files für die chroot-Umgebung:
    mknod /var/lib/named/dev/null c 1 3
    mknod /var/lib/named/dev/random c 1 8
    chmod 666 /var/lib/named/dev/null /var/lib/named/dev/random
    
  • /etc/default/bind9
    In /etc/default/bind9 chroot-Option für den named eintragen:
    OPTIONS="-u bind -t /var/lib/named"
    
  • /etc/init.d/sysklogd
    In /etc/init.d/sysklogd Log-Option für syslogd eintragen:
    SYSLOGD="-a /var/lib/named/dev/log"
    
  • /var/lib/named/etc/bind/named.conf.local
    Eigene zones für den named eintragen. named.conf schliesst named.conf.local ein.
    Meine /var/lib/named/etc/bind/named.conf.local

  • /var/lib/named/etc/bind/meinvps.de
    Zonefile für meinvps.de (muss neu erzeugt werden). Die IP-Adresse 11.22.33.44 ist unter einer ganzen Reihe verschiedener Namen erreichbar, u.a. dem unvermeidlichen "www". "admin.meinvps.de" ist übrigens kein Hostname, sondern die Mailadresse des DNS-Admins. Bei Änderungen an Zonefiles das Hochsetzen der "Serial Number" nicht vergessen!
    Meine /var/lib/named/etc/bind/meinvps.de

  • /var/lib/named/etc/bind/33.22.11.in-addr.arpa
    Zonefile für die reverse zone 33.22.11.in-addr.arpa (muss neu erzeugt werden).
    Meine /var/lib/named/etc/bind/33.22.11.in-addr.arpa

  • Dauerhaftes Ändern des Hostnamens:
    Das folgende Vorgehen habe ich z.T. den Support-Webseiten meines Hosters entnommen.
    Man erstellt eine Datei /etc/my.resolv.conf mit folgendem Inhalt
    domain meinvps.de
    search meinvps.de
    nameserver 127.0.0.1
    
    und ausserdem ein Skript /etc/init.d/hostname_vps, das bei jedem Neustart des VPS ausgeführt werden muss:
    #!/bin/bash
    HOSTNAME=knurzel.meinvps.de
    echo $HOSTNAME > /etc/HOSTNAME
    echo $HOSTNAME > /etc/hostname
    /bin/hostname $HOSTNAME
    if [ -f /etc/my.resolv.conf ]; then
    cp /etc/my.resolv.conf /etc/resolv.conf;
    fi
    exit 0
    
    (Von den beiden echos ist im Prinzip nur eins erforderlich; das andere schadet aber nichts und macht das Skript auch für andere Linux-Distributionen als Debian tauglich.) Zum automatischen Ausführen muss noch folgende Änderung vorgenommen werden:
    chmod 755 /etc/init.d/hostname_vps
    update-rc.d hostname_vps defaults 09
    /etc/init.d/hostname_vps
    
    Die letzte Zeile führt das Skript einmal "von Hand" aus (es muss ohne irgendwelche Fehlermeldungen durchlaufen). Nach diesen Änderungen heisst der VPS dauerhaft "knurzel.meinvps.de" (anstelle des Namens, den der Hoster vergeben hat) und benutzt den eigenen BIND für DNS-Lookups.

Nach dem Neustart des syslogd und dem Starten des named mit

/etc/init.d/sysklogd restart
/etc/init.d/bind9 start
sollten beruhigende Meldungen in /var/log/syslog zu beobachten sein.

Abschliessender Test: Wenn man mit

host www.irgendwo.de localhost
vernünftige Antworten vom eigenen named bekommt (sowohl für Hostnamen in der eigenen, als auch für solche in fremden Domains wie "irgendwo.de"), läuft alles.

Während alle Einträge für Forward-Zones, die ich auf meinem VPS mache, richtig propagiert werden, funktioniert dies für Reverse-Zones erstmal nicht (bzw. nur lokal), d.h. wenn irgendjemand irgendwo "knurzel.meinvps.de" auflöst, lautet die Antwort korrekt "11.22.33.44". Versucht er hingegen "11.22.33.44" aufzulösen, erhält er als Antwort den von meinem Hoster vergebenen Namen für meinen VPS. Mein BIND ist natürlich nicht "authoritative" für 33.22.11.in-addr.arpa (da gibt es schliesslich noch andere VPS ausser meinem), also darf das eigentlich auch nicht gehen. Mein Hoster bietet jedoch per Kunden-Webinterface eine "Reverse Delegation" an, mit der man auch Reverse-Lookups so geradebiegen kann, dass auf den selbst vergebenen Host- und Domainnamen aufgelöst wird.

Dienste - Mail

Zum Einsatz kommt Postfix-TLS/SASL (Debian-Pakete "postfix" und "postfix-tls") als MTA und pop3/SSL sowie imap/SSL zum Zugriff auf die Mailboxen von knurzel (Debian-Pakete "uw-imapd-ssl" und "ipopd-ssl"). Als Spamfilter wird SpamAssassin benutzt (Debian-Paket "spamassassin"). Die genannten Pakete benötigen eine ganze Reihe weiterer, hier nicht aufgeführter Pakete. apt-get löst diese Abhängigkeiten von allein auf und installiert alles erforderliche. Im Zweifelsfall vgl. die Liste der installierten Pakete weiter unten.

Postfix soll Mail per SMTP (25/tcp) und SMTPS (465/tcp) entgegennehmen, Mail versenden soll nur nach erfolgreicher Authentifizierung durch den saslauthd möglich sein. Mail abholen/lesen soll per pop3/SSL (995/tcp) und imap/SSL (993/tcp) möglich sein.

Erforderliche Änderungen am frisch installierten Debian:

  • Paket "exim" (Debian Standard-MTA) löschen:
    dpkg -P exim
    

  • Alle erforderlichen Pakete für die o.g. Maildienste installieren:
    apt-get install postfix postfix-tls
    apt-get install libsasl2 sasl2-bin libsasl2-modules
    apt-get install ipopd-ssl uw-imapd-ssl
    
    Die bei der Installation zu machenden Angaben sind wie folgt: Postfix wird als "Internet Site" betrieben, Dienste zum Abholen von Mail seien "pop3s" und "imaps" (und zwar nur diese). Der Rest ist egal (wird nachher noch "richtig" konfiguriert).

  • /etc/postfix/sasl/smtpd.conf:
    Die vorhandene Datei /etc/postfix/sasl/smtpd.conf wie folgt abändern:
    pwcheck_method: saslauthd
    mech_list: plain login
    saslauthd_path: /var/spool/postfix/var/run/saslauthd/mux
    autotransition:true
    

  • Zertifikat für Postfix erzeugen:
    mkdir /etc/postfix/ssl
    cd /etc/postfix/ssl
    dd if=/dev/urandom of=/tmp/urandom.file bs=1b count=1k
    openssl genrsa -des3 -rand /tmp/urandom.file -out smtpd.key 1024
    chmod 600 smtpd.key
    openssl req -new -key smtpd.key -out smtpd.csr
    openssl x509 -req -days 750 -in smtpd.csr -signkey smtpd.key \
    -out smtpd.crt
    openssl rsa -in smtpd.key -out smtpd.key.unencrypted
    mv -f smtpd.key.unencrypted smtpd.key
    openssl req -new -x509 -extensions v3_ca -keyout cakey.pem \
    -out cacert.pem -days 750
    rm cakey.pem smtpd.csr
    chmod 400 cacert.pem smtpd.crt smtpd.key
    

  • /etc/postfix/main.cf:
    Die Postfix-Konfigurationsdatei /etc/postfix/main.cf enthält direkt nach der Installation des Postfix-Pakets fast nichts und kann komplett durch meine /etc/postfix/main.cf ersetzt werden.

  • /etc/postfix/master.cf:
    In der Datei /etc/postfix/master.cf darf gegen Ende (unter "only used by postfix-tls" kein Kommentarzeichen ("#") vor der Zeile, die mit "smtps" beginnt, stehen.

  • saslauthd anpassen:
    mkdir -p /var/spool/postfix/var/run/saslauthd
    
    Die Datei /etc/default/saslauthd muss so angepasst werden, dass der saslauthd startet und seinen Socket mux im angegebenen Verzeichnis findet:
    # This needs to be uncommented before saslauthd
    # will be run automatically
    START=yes
    PARAMS="-m /var/spool/postfix/var/run/saslauthd -r"
    # You must specify the authentication mechanisms you wish to use.
    # [...]
    MECHANISMS="pam"
    
  • /etc/init.d/saslauthd:
    Das Skript zum Starten des saslauthd wird so abgeändert, dass das PID-File des saslauthd (da steht die Prozess-ID des aktuell laufenden saslauthd drin) sich nach dem Start unterhalb von /var/spool/postfix befindet:
    PIDFILE="/var/spool/postfix/var/run/${NAME}/saslauthd.pid"
    
    Der Eintrag befindet sich unter den ersten paar Zeilen des Skripts.

  • /etc/pam.d/smtp:
    Damit die Authentifizierung zum Mailversand klappt, braucht man noch eine Datei /etc/pam.d/smtp (muss neu erstellt werden):
    auth required /lib/security/pam_unix_auth.so
    account required /lib/security/pam_unix_acct.so
    password required /lib/security/pam_unix_passwd.so
    session required /lib/security/pam_unix_session.so
    

  • Neustart aller relevanten Dienste:
    /etc/init.d/postfix restart
    /etc/init.d/saslauthd restart
    /etc/init.d/inetd restart
    

Jetzt sollten alle Maildienste laufen; zum Testen kann man in erster Näherung mittels telnet auf Port 25 verbinden ("STARTTLS" und "AUTH" sind wichtig). Weitere Tests: Man schickt von extern eine Mail an einen Benutzer auf knurzel, liest die Mail auf knurzel per imap/SSL, holt die Mail von knurzel per pop3/SSL ab und beantwortet sie anschliessend vom heimischen DSL aus mit mail.meinvps.de als Postausgangs-Server (smtp/TLS). Ob alles klappt, kann man in /var/log/syslog mitverfolgen:

tail -f /var/log/syslog

Hier einige Beispiele.

Spamfilter: Einfachste Möglichkeit ist das Filtern mittels procmail. Man benötigt lediglich das SpamAssassin-Paket und eine passende .procmailrc für den Benutzer, der SpamAssassin einsetzen will. Diese Lösung bietet sich insbesondere dann an, wenn man ohnehin bereits procmail zum Vorsortieren von Mail einsetzt (bei mir ist das der Fall). In $HOME/.spamassassin/user_prefs kann man SpamAssassin feineinstellen. Mit required_score 4 endlagert der untrainierte SpamAssassin bei mir >90% Spam im Spamfolder. "False Positives" hatte ich noch keine.

Dienste - Web

Zum Einsatz kommt Apache 2.0.x und zwar das out-of-the-box-Paket, das bei Debian "Sarge" dabei ist. Ich mache keinerlei Web-Sperenzchen und brauche neben dem Apache (und den Sachen, die direkt dazugehören, wie MPM-prefork, libapr, usw.) nur das PHP-Paket. Bei Debian ist der Web-Content unter /var/www. Das Debian-Paket ist für den Betrieb von mehreren VirtualHosts vorbereitet; brauche ich alles nicht. Ich habe meinen Content nach /var/www kopiert und sonst nur in /etc/apache2/sites-available/default den "RedirectMatch" auskommentiert - passt. Apache-Module, die man nicht braucht, kann man mit a2dismod abschalten.

Sonstiges

  • Liste der installierten Pakete auf meinem VPS (ohne Versionsnummern).

  • Virtuozzo hat bei mir ohne mein Zutun ein Skript /etc/init.d/vzquota angelegt, mit dem an /etc/mtab Änderungen vorgenommen werden. Das hat nach Auskunft meines Hosters seine Richtigkeit.

  • Sichern des ssh-Zugangs mit einer oder mehrerer der folgenden Möglichkeiten (starke Passworte verstehen sich von selbst!):

    • einen anderen als den Standard-TCP Port (22) für sshd verwenden
    • Authentifizieren durch Passworte abschalten (Zugang nur mit Key)
    • Sichern des sshd-Ports mittels Port-Knocking
    • Zahl der Authentifizierungsversuche begrenzen (z.B. nur einmal pro Minute - das macht Brute Force-Attacken unattraktiv)

  • Mit

    nmap localhost
    
    bzw.
    nmap 11.22.33.44
    
    kann man die offenen TCP-Ports des eigenen Systems einfach feststellen. nmap installiert man über das gleichnamige Paket.
    Weitere Details: man nmap.
    Es sollten nur Ports offen sein, die zu Diensten gehören, die man explizit konfiguriert hat. In /etc/services kann man nachsehen, welcher Port (normalerweise) zu welchem Dienst gehört. Werden offene Ports angezeigt, die zu Diensten gehören, die eigentlich nicht laufen sollten (z.B. ident 113/tcp, sunrpc 111/tcp oder pop3/imap ohne SSL), stellt man die Dienste ab. Dazu prüft man, wie die zugehörigen "Daemons" gestartet werden (entweder direkt/"stand-alone" oder per inetd laut Angabe in /etc/inetd.conf). Im Fall von "stand-alone Daemons" erfolgt das Abstellen mittels start/stop-Skript in /etc/init.d (also /etc/init.d/dienst stop) und danach update-rc.d -f dienst remove ("dienst" sei der Name des start/stop-Skripts), im Fall von per inetd gestarteten "Daemons" ändert man /etc/inetd.conf entsprechend (Zeile auskommentieren) und befiehlt ein /etc/init.d/inetd reload.

  • Dienste, bei denen Benutzernamen und -passworte im Klartext übertragen werden, z.B. pop3, imap, ftp, telnet, usw. sind bähbäh. Stattdessen verwendet man die Pendants mit SSL/TLS oder sichere Alternativen, z.B. ssh anstatt telnet.

  • Mit rcconf aus dem gleichnamigen Paket kann man bequem das Starten von Diensten beim Systemstart verwalten.

  • Mit
    ps aux
    
    werden alle laufenden Prozesse angezeigt.

  • Die Verwaltung von Software-Paketen unter Debian erfolgt mittels der Befehle dpkg, apt-get und aptitude. aptitude hat ein ncurses-Frontend zur Paketverwaltung; das ist aber eine reine Usability-Katastrophe.
    Beispiele aus der Praxis (die man-pages verraten den Rest):

    • Updates einspielen
      apt-get update
      apt-get upgrade
      
    • Paket "fitzefatze" aus Installationsquellen installieren
      apt-get install fitzefatze
      
    • Nach einem Paket "fitzefatze" in den Installationsquellen suchen
      aptitude search fitzefatze
      
    • Liste aller lokal installierten Pakete
      dpkg -l
      
    • Liste der Dateien im lokal installierten Paket "fitzefatze"
      dpkg -L fitzefatze
      
    • lokal installiertes Paket "fitzefatze" inkl. Konfigurationsdateien löschen
      dpkg -P fitzefatze
      

Links


Copyright (c) 2007 daniel(-at-)bischof.org - Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 (GFDL).

Fehler gefunden? Besser hingekriegt? -> daniel(-at-)bischof.org




 
links
Humanistische Union
FFII
Deutsche Vereinigung für Datenschutz
BigBrotherAward.de
Heise Telepolis

Heise Newsticker
Linux Today
Linux Weekly News
verweise
 
quote
"Trust the math.
Encryption is your friend."

   Bruce Schneier
zitat