Monat: Dezember 2011

Hinweis on: Das ist ein Beitrag aus dem ehemaligen Projekt „adminstories.de“. Bitte hier fuer weitere Informationen schauen.Hinweis off

Wir haben mehrere Server im Einsatz. Auf einigen Servern hosten wir auch Dienste fuer Bekannte, die allerdings keinen direkten Zugang (SSH) erhalten. Nun war die Frage, wie diese Benutzer Daten auf den Server kopieren koennen, um beispielsweise die eigene Webseite auf einen aktuellen Stand zu bringen. Da Dirk und ich gerne auf ungesicherte Datenuebertragungen verzichten moechten, haben wir uns hier fuer FTPS entschieden.

Anfaenglich hatten wir uns auf Serverseite fuer ProFTPd entschieden. Die Installation lief auch problemlos. Allerdings konnte spaeter keine Verbindung hergestellt werden. Grund ist ein bekannter Bug, den wir auch in unserer Umgebung nachstellen „konnten“. Also haben vsftpd als Mittel der Wahl ausgewaehlt.

Die Installation ansich kann gewohnt problemlos ueber die Paketquellen erfolgen. Flott ein sudo aptitude install vsftpd libpam-pwdfile und schon kann man an die Konfiguration gehen. Das Paket libpam-pwdfile wird spaeter benoetigt um Benutzer gegen eine Passwortdatei zu authentifizieren. Wir haben diesen Weg gewaehlt, damit wir die Benutzer nicht in die /etc/passwd eintragen muessen. Da wir FTPS nutzen moechten habe ich den Daemon erst mal gestoppt (service vsftpd stop) und ein Zertifikat erstellt.

ramon@server:/srv/www# cd /etc/ssl/private/
ramon@server:/etc/ssl/private# openssl req -x509 -nodes -days 365 -newkey rsa:1024 -keyout vsftpd.pem -out vsftpd.pem

Anschliessend muss die Datei /etc/vsftpd.conf angepasst werden. Hier mal die relevanten Teile inklusive deren Beschreibung aus unserer Konfiguration.

# Uncomment this to enable any form of FTP write command.
write_enable=YES

# You may restrict local users to their home directories. See the FAQ for
# the possible risks in this before using chroot_local_user or
# chroot_list_enable below.
chroot_local_user=YES

# If enabled, virtual users will use the same privileges as local users. By default, virtual
# users will use the same privileges as anonymous users, which tends to be more restrictive
# (especially in terms of write access).
virtual_use_local_privs=YES

# This option is useful is conjunction with virtual users. It is used to automatically
# generate a home directory for each virtual user, based on a template.
user_sub_token=$USER

# This option represents a directory which vsftpd will try to change into after a local
# (i.e. non-anonymous) login. Failure is silently ignored.
local_root=/srv/www/$USER

# If enabled, all user and group information in directory listings will be displayed as
# „ftp“.
hide_ids=YES

# Turn on SSL
ssl_enable=YES

# This option specifies the location of the RSA certificate to use for SSL
# encrypted connections.
rsa_cert_file=/etc/ssl/private/vsftpd.pem

# All non-anonymous logins are forced to use a secure SSL connection in order to
# send and receive data on data connections.
force_local_data_ssl=YES

# All non-anonymous logins are forced to use a secure SSL connection in order to send the password.
force_local_logins_ssl=YES

# Permit TLS v1 protocol connections. TLS v1 connections are preferred
ssl_tlsv1=YES

# Permit SSL v2 protocol connections. TLS v1 connections are preferred
ssl_sslv2=NO

# permit SSL v3 protocol connections. TLS v1 connections are preferred
ssl_sslv3=NO

# If set to yes, all SSL data connections are required to exhibit SSL session reuse (which proves
# that they know the same master secret as the control channel). Although this is a secure default,
# it may break many FTP clients, so you may want to disable it.
require_ssl_reuse=NO

Wie man sehen kann mappen wir die Benutzer auf den Ordner /srv/www/$USER. Das bedeutet natuerlich auch, dass der Ordner vorhanden sein sollte und die Rechte enstprechend gesetzt sind.

Wie oben beschrieben moechten wir die Benutzer nicht im System ansich anlegen sondern in einer eigenen Datei pflegen. Dafuer erstelle ich erst einmal die Datei /etc/vsftpd.passwd und trage auch gleich einen ersten Benutzer ein.

ramon@server:/etc# htpasswd -c /etc/vsftpd.passwd ramon

Soweit, so fast fertig. Nun muessen wir noch konfigurieren, dass eben diese Datei auch genutzt wird um Benutzer zu authentifizieren. Dafuer muss die Datei /etc/pam.d/vsftpd angepasst werden. Folgende Eintraege sind dabei zu machen.

auth required pam_pwdfile.so pwdfile /etc/vsftpd.passwd
account required pam_permit.so

Des Weiteren muss der Eintrag auth required pam_shells.so auskommentiert werden. Jetzt nur noch den Service wieder starten und schon sollte die Anmeldung moeglich sein.

Alles in allem ist die Einrichtung eigentlich einfach. Wie so oft steckt der Teufel aber im Detail. Im Rahmen der Installation hatte ich einige Probleme, die mich etwas Zeit gekostet haben. So ist auf Clientseite die Meldung ssl_getc: SSL_read failed -1 = 0, bzw. **** gnutls_record_recv: A record Paket with illegal version was received kein zwingender Hinweis auf ein Problem mit SSL. Bei mir war es einfach der fehlende Benutzer, der Ausloeser der Meldung war. Nach dem Anlegen der /etc/vsftpd.passwd und der Anpassung der /etc/pam.d/vsftpd funktionierte die Anmeldung noch immer nicht. Dafuer habe ich dann in der /var/log/auth.log den Eintrag bar vsftpd: PAM unable to dlopen(/lib/security/pam_pwdfile.so): /lib/security/pam_pwdfile.so: cannot open shared object file: No such file or directory gefunden. Daher auch die oben angesprochene Installation des Pakets libpam-pwdfile. Bei einem weiteren Versuch hat die Anmeldung noch immer nicht funktioniert, da ich die Datei /etc/pam.d/vsftpd zwar erweitert, den oben angesprochenen auth-Eintrag aber nicht auskommentiert hatte. Man sieht also, da ist Luft fuer Fehler gewesen.

Hinweis on: Das ist ein Beitrag aus dem ehemaligen Projekt „adminstories.de“. Bitte hier fuer weitere Informationen schauen.Hinweis off

Heute ein Folgebeitrag zum Artikel Einrichten eines Syslog Servers. In diesem wurden ja einige Schritte zur Einrichtung eines Syslogservers beschrieben, der eingehende Logs in eine MySQL-Datenbank schreibt. Das ist auch soweit toll, bis auf… Bis auf die Punkte Backup und Logrotation. Im dargestellten Artikel bin ich mit keinem Wort auf einen der beiden Punkte eingegangen. Das moechte ich nun nachholen.

Warum ueberhaupt Backup und Rotation?

Die Logs die ich einsammel enthalten Details, die mir im Fall eines Problems oder Vorfalls helfen koennen benoetigte Informationen auf die Schnelle zentral zu sichten. Wenn das Ereignis, ueber das ich mich informieren moechte, nun zwei Tage zurueck liegt, mir aber am Tag vorher die Daten verloren gegangen sind (Servercrash, etc.), waere das schon doof. Daher also Backup. Und die Rotation soll einfach helfen die anfallenden Datenmengen zu begrenzen. Denn Logs von vor zwei Tagen duerften mal helfen koennen. Aber ab einem bestimmten Alter sind Logs in der Regel nicht mehr interessant. Ich habe den Zeitraum fuer mich mal auf 90 Tage festgelegt.

Die Daten, um die es mir nachfolgend geht, liegen in der Datenbank Syslog in der Tabelle SystemEvents. Um ein „richtiges“ Backup zu haben uebernehme ich taeglich die Daten vom Vortag in eine neue Tabelle, exportiere diese und sicher die dann weg.

Also fangen wir an und erstellen eine Tabelle, die die anfallenden Daten aufnehmen kann.

mysql -u root -p -e „CREATE TABLE Syslog.SystemEventsBackup LIKE Syslog.SystemEvents“ Syslog

Hiermit wird in der Datenbank Syslog die neue Tabelle SystemEventsBackup erstellt, die die gleichen Eigenschaften wie die Tabelle SystemEvents hat. Moechte ich nun die Daten des Vortags sichern, fuege ich diese erst einmal in meine neue Tabelle ein, nachdem ich die vorher geleert habe.

mysql -u root -p -e „TRUNCATE Syslog.SystemEventsBackup“ Syslog
mysql -u root -p -e „INSERT INTO Syslog.SystemEventsBackup SELECT * FROM SystemEvents WHERE datediff( curdate() , ReceivedAt ) =1“ Syslog

Habe ich die Abfrage nun ausgefuehrt kann ich hergehen und die Tabelle via mysqldump exportieren.

root@server:~# mysqldump -u root -p Syslog SystemEventsBackup > test.sql
Enter password:

Prima, die Sicherung klappt schon mal. Nun noch schauen, dass die Eintraege, die aelter als 90 Tage sind, entfernt werden. Fuer einen ersten Versuch schauen wir erst mal, ob die Anfrage korrekt laueft und nehmen alles, was aelter als 10 Tage ist.

mysql -u root -p -e „SELECT * FROM SystemEvents WHERE unix_timestamp(ReceivedAt) < unix_timestamp() – 10*24*60*60“ Syslog

Ist das Resultat wie wir es erwarten koennen wir aus dem SELECT ein DELETE machen. Fuer die mit den schnellen Finger. Hiernach sind die Daten erst mal weg.

mysql -u root -p -e „DELETE FROM SystemEvents WHERE unix_timestamp(ReceivedAt) < unix_timestamp() – 10*24*60*60“ Syslog

Somit haben wir also alles zusammen um uns ein Script zu schreiben, dass uns taeglich eine Sicherung der gestrigen Daten macht und anschliessend alle Daten in der Datenbank loescht, die aelter als 90 Tage sind.

#!/bin/bash

logger -t backrotate.bash -i „Starting backrotate.bash“

TIMESTAMP=$(date „+%Y%m%d-%H%M“)
TARGET_DIRECTORY=“/var/tmp“
DB_PREFIX=“db.“

DB_USERNAME=“username“
DB_PASSWORD=“password“
DB_DATABASE=“Syslog“
DB_TABLE=“SystemEvents“
DB_BAKTABLE=“SystemEventsBackup“
DB_ENTRIES=“`mysql -u $DB_USERNAME -p$DB_PASSWORD -e „SELECT COUNT(*) FROM SystemEvents WHERE unix_timestamp(ReceivedAt) < unix_timestamp() – 90*24*60*60“ Syslog | egrep „[0-9]{1,}“ -o`“ logger -t backrotate.bash -i „creating backupfile“ FILENAME=$TARGET_DIRECTORY/$DB_DATABASE-$TIMESTAMP.sql.bz2 mysql -u $DB_USERNAME -p$DB_PASSWORD -e „TRUNCATE $DB_BAKTABLE“ $DB_DATABASE mysql -u $DB_USERNAME -p$DB_PASSWORD -e „INSERT INTO $DB_DATABASE.$DB_BAKTABLE SELECT * FROM $DB_TABLE WHERE datediff( curdate() , ReceivedAt ) =1“ $DB_DATABASE mysqldump -u $DB_USERNAME -p$DB_PASSWORD $DB_DATABASE $DB_BAKTABLE | bzip2 -9 > $FILENAME

logger -t backrotate.bash -i „backupfile $FILENAME created“
logger -t backrotate.bash -i „deleting $DB_ENTRIES database-entries >90 days“

mysql -u $DB_USERNAME -p$DB_PASSWORD -e „SELECT * FROM $DB_TABLE WHERE unix_timestamp(ReceivedAt) < unix_timestamp() – 90*24*60*60“ $DB_DATABASE

Diejenigen von euch, die schon laenger mitlesen werden zu Recht anmerken, dass ich mich nicht an die eigenen Hinweis halte. Natuerlich mache ich das 🙂 Obiger Job soll ja nur das Geruest sein. In „meiner“ Produktion habe ich das natuerlich entsprechend erweitert. 😉