Linux Debian Sarge Etch VPS OpenVZ Virtuozzo

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

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"

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

Ziel

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

• "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.

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

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

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

Abschliessender Test: Wenn man mit

host www.irgendwo.de localhost

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

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

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

• OpenVZ/Virtuozzo
• Debian GNU/Linux
• ISC BIND (Nameserver)
• Postfix
• Apache SpamAssassin
• Apache Webserver

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