Tag: Debian

Posted on

Iceweasel ESR für Debian Squeeze und Wheezy – Kein Support mehr für 3.6

Eine kurze Erinnerung an alle, die Iceweasel alias Firefox mit Debian verwenden. Mike Hommey, Paketverwalter für Iceweasel und Firefox-Entwickler, hat gestern in seinem Blog noch einmal daran erinnert, dass Iceweasel 10 ESR in den Backports für Debian Squeeze zur Verfügung steht. Die ehemals unterstützte Version 3.6 erhält keine Updates mehr und sollte nicht mehr benutzt werden.
Weiterhin wird zwar Iceweasel 3.5.16 wie gewohnt bis 2014 unterstützt, er empfiehlt aber ein Upgrade auf Iceweasel 10 zu machen. Dieser Empfehlung möchte ich mich hier anschließen. Man bemerkt deutlich die verbesserte Leistung des neueren Iceweasel-Browsers. Außerdem stehen deutlich mehr Funktionen und aktuellere Addons zur Verfügung.

Update 07.06.2012: Heute wurde auf der Debian-Mailingliste "debian-security-announce" offiziell empfohlen von Iceweasel 3.5 auf Iceweasel 10 ESR zu wechseln.
Ich gehe davon aus, dass Iceweasel 10 uns in der nächsten stabilen Veröffentlichung von Debian erhalten bleibt und entweder separat durch Mike Hommey weitergepflegt wird oder durch die nächste ESR-Version, Iceweasel 17, wie bisher durch einen Backport ersetzt wird.
Unter dem Begriff ESR oder Extended Support Release verbreitet Mozilla ein Langzeit-Release, dass vor allem Unternehmen und Öffentlichen Einrichtungen zu Gute kommen soll, die an einer stabilen und langfristig gepflegten Version interessiert sind und nicht die Möglichkeiten haben den normalen "Rapid-Release"-Zyklus zu supporten.
Die aktuellste Version von Iceweasel befindet sich zur Zeit in Experimental. Auf mozilla.debian.net werden nach wie vor die Wege beschrieben, wie man an die gewünschte Version für den jeweiligen Debian-Zweig gelangen kann.
Ansonsten kann ich noch meine Artikel zu Debians Backports oder Iceweasel 6 empfehlen, die das Prinzip ebenfalls erklären.
Wer immer den Überblick über das Versionswirrwarr behalten möchte, kann sich z.B. auch apt-show-versions installieren. Hat man zuvor alle Quellen/Zweige in der /etc/apt/sources.list eingetragen, für die man sich interessiert, genügt

apt-show-versions -a iceweasel


um eine Übersicht über alle verfügbaren Paketversionen zu erhalten.

Posted on

vnstat und vnstati: Volumen des Netzwerkverkehrs übersichtlich visualisieren

Im Zeitalter von Flat-Angeboten rangierten bei mir Programme zum Überwachen des Datenverkehrs bisher eher auf den hinteren Plätzen. Seitdem ich aber einen vServer mein Eigen nenne, interessiert mich das tägliche Volumen an ein- und ausströmenden Bits und Bytes umso mehr.
Gut, ich denke die meisten VPS-Anbieter bieten schon eine Art von Netzwerkmonitor an, da sie selbst daran interessiert sind, dass der Kunde die vereinbarte Trafficgrenze nicht überschreitet. So macht das mein Anbieter auch und stellt mir sogar eine grafische Übersicht und Charts zur Verfügung, wann und wie viel Datenverkehr durch die Leitungen fließt.
Der Nachteil des Ganzen ist, ich muss mich erst einmal in das Kundenmenü einloggen und kann nicht eben so die Daten auch auf meiner Projektseite darstellen.
Wie immer gibt es mehrere Alternativen. Ich dachte zuerst an RRDtool und MRTG oder ntop. Beide sahen sehr vielversprechend aus, doch sie boten mir zu viele Funktionen, wenn man das so pauschal umschreiben kann. Ich hingegen wollte etwas schlichtes und einfaches. Eine Ausgabe auf der Konsole, vielleicht noch ein paar nette Graphen dabei, die die Datenmenge visualisieren.
Womit ich bei vnstat gelandet war und ein charmantes Werkzeug gefunden hatte.
Vnstat hat ein Init-Skript und startet als Daemon. Im Hintergrund überwacht er dann das vorher definierte Interface und sammelt die mitgezählte Datenmenge in einer Datenbank. Keine Sorge, vnstat ist äußerst genügsam. 1 MB RAM solltet ihr aber einplanen.
Zuerst muss das Interface in /etc/vnstat.conf definiert werden, welches standardmäßig überwacht werden soll. Danach wird die Datenbank erstellt bzw. erneuert. Z.B. für eth0:

vnstat -u -i eth0


Macht man das nicht, erscheint diese Fehlermeldung.

Starting vnStat daemon: vnstatdZero database found, exiting.

Die restlichen Optionen in der Konfigurationsdatei sind gut dokumentiert. Dort lässt sich vor allem das Erscheinungsbild der Ausgabe festlegen.

Bedienung

Die Bedienung von vnstat ist unkompliziert.

vnstat -s

                     rx      /      tx      /     total    /   estimated
 eth0:
       May '12    911.31 MiB  /    1.45 GiB  /    2.34 GiB
       Jun '12    470.22 MiB  /  773.50 MiB  /    1.21 GiB  /   18.40 GiB
     yesterday    287.79 MiB  /  468.17 MiB  /  755.96 MiB
         today    182.42 MiB  /  305.33 MiB  /  487.75 MiB  /     496 MiB

vnstat -h

 eth0                                                                     23:35
  ^      t
  |      t
  |      t                                                           t
  |      t                                                           t
  |      t        t                                                  t
  |      t        t                                                  t
  |     rt        t                                                  t
  |   t rt        t                                t                 t
  |  rt rt  t     t                               rt              t  t r   t
  |  rt rt rt     t                      rt       rt rt          rt rt rt rt
 -+--------------------------------------------------------------------------->
  |  00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23
 h  rx (KiB)   tx (KiB)      h  rx (KiB)   tx (KiB)      h  rx (KiB)   tx (KiB)
00      14016      23119    08       1331       1338    16       9086       9262
01      30605      63348    09       2884       1561    17       3132       2485
02      10203      18235    10       3578       2039    18       5605       2448
03       2365       1848    11       6236       6186    19       5697       6172
04       2930      42386    12       8270       6724    20      12474      14342
05       1437       1210    13       5878       4099    21      11467      55362
06       1680       1886    14       5107       2972    22      17298      11634
07       1554       1231    15      13417      19035    23      12446      16185

vnstat -d

eth0 / daily

         day         rx      |     tx      |    total    |   avg. rate
     ------------------------+-------------+-------------+---------------
      05/28/12    159.61 MiB |  263.27 MiB |  422.88 MiB |   40.09 kbit/s
      05/29/12    215.86 MiB |  382.90 MiB |  598.75 MiB |   56.77 kbit/s
      05/30/12    227.47 MiB |  315.93 MiB |  543.41 MiB |   51.52 kbit/s
      05/31/12    308.36 MiB |  520.59 MiB |  828.96 MiB |   78.60 kbit/s
      06/01/12    287.79 MiB |  468.17 MiB |  755.96 MiB |   71.68 kbit/s
      06/02/12    184.27 MiB |  307.72 MiB |  492.00 MiB |   47.47 kbit/s
     ------------------------+-------------+-------------+---------------
     estimated       187 MiB |     312 MiB |     499 MiB |

Abgerundet wird das Ganze noch durch vnstat -m und vnstat -t, eine monatliche Anzeige und die Übersicht der 10 verkehrsreichsten Tage.

vnstat als tägliche Zusammenfassung per E-Mail erhalten

Man kann z.B. einen Cron-Job definieren, der täglich um 23:59 die Zusammenfassung per Mail an den Superuser schickt.

59 23   * * *   apo             /usr/bin/vnstat -s | mail -s "vsrv52135: Daily traffic eth0" root@localhost

vnstati

Praktischerweise gibt es noch vnstati, dass die Statistiken in schöne, übersichtliche Graphen transformieren kann.

Ich habe mir ein simples Skript geschrieben, dass jeden Tag um Mitternacht die Graphen produziert und in ein Verzeichnis des Webservers kopiert.

#!/bin/sh
# Visualisierter Netzwerkverkehr mit Vnstat
# Ausgabe der Dateien in das Webserververzeichnis stats/traffic
set -e
Target="/home/linuxiuvat/linuxiuvat.de/stats/traffic/graph/"
# stündlich
/usr/bin/vnstati -h -o ${Target}vnstat_hourly.png
# täglich
/usr/bin/vnstati -d -o ${Target}vnstat_daily.png
# monatlich
/usr/bin/vnstati -m -o ${Target}vnstat_monthly.png
# Top10
/usr/bin/vnstati -t -o ${Target}vnstat_top10.png
# Zusammenfassung
/usr/bin/vnstati -s -o ${Target}vnstat_summary.png

Anschließend lässt sich die visualisierte Datenmenge unter http://linuxiuvat.de/stats/traffic/ anschauen.

Posted on

apt-clone: Backup in verbesserter Debian-Manier

Eher durch Zufall bin ich erneut auf apt-clone gestoßen, nachdem ich nach Programmen mit vorangestelltem "apt-" gesucht hatte. Vor einem Jahr wurde dieses schicke Skript auf linuxundich.de vorgestellt, als apt-clone noch dabei war in Debian aufgenommen zu werden.
Apt-clone ist im Prinzip der verbesserte "The Debian Way" beim Backup machen.
Es übernimmt automatisch das Sichern des Paketstatus, speichert den Schlüsselring und kann sogar nicht mehr herunterladbare Pakete oder Drittprogramme mit dpkg-repack wieder in neue Pakete verschnüren. Ziemlich praktisch, wenn man seine Druckertreiber gelöscht hat und diese nun neu gepackt werden.

Backup machen

apt-clone clone /home/apo --with-dpkg-repack

Wiederherstellen

apt-clone restore apt-clone-state-rechnername.tar.gz


Die Syntax ist ziemlich übersichtlich. Mit apt-clone clone wird ein Backup gemacht und in meinem Home-Verzeichnis gespeichert und zusätzlich nicht mehr verfügbare Pakete neu gepackt. Nach kurzer Zeit landet alles in einer Tar-Datei und kann mit apt-clone restore wiederhergestellt werden. Das wars.
Sicher ein Vorteil, wenn man den aktuellen Paketzustand des Rechners dauerhaft klonen möchte. Zusätzlich muss dennoch /etc und /home gesichert werden, was aber in den meisten Fällen ausreichend ist um ein Debian-basiertes System zu sichern und wieder ruhig schlafen zu können :).

Posted on

Debian Administrator's Handbook und ein neuer Link für das Blogroll

Ok, nach den letzten Posts denke ich, war es an der Zeit Raphaël Hertzogs Blog auch mal dauerhaft in meinem Blog als Link und Blogroll zu verankern. Normalerweise braucht man so etwas wahrscheinlich nicht noch einmal extra ankündigen, aber da das Hinzufügen eines Blogrolls in diesem Blog durchschnittlich alle zwei Jahre passiert, musste ich doch ein paar Worte drüber verlieren.

Bevor ich hier einen Permalink verewige habe ich in der Regel mehrere Stunden und eher Tage mit dem Lesen des Blogs verbracht und kenne das Blog seit mehreren Monaten. Das Thema muss selbstverständlich passen. Ob danach noch regelmäßig Artikel erscheinen spielt keine Rolle, sofern die Seite weiterhin online ist. Das ausschlaggebende Argument ist, das Lesen des Blogs hat mich dazu gebracht mich so stark mit den dortigen Themen zu beschäftigen, dass man schon sagen kann: Es hat mein Leben verändert!
Pathos, Pathos, mag sein. Bei KMandla oder Urukrama stimmt das aber.
Raphaël Hertzogs Blog ist nicht nur informativ, es gibt Menschen, die für Debian arbeiten ein Gesicht. Wer schon immer mal wissen wollte, wer sich hinter dem Namen des Paketverwalters eines Debianpakets verbirgt, erfährt hier viel Wissenswertes.
Insbesondere interessiert mich aber die Sicht eines Debianentwicklers, der seit seinem 18. Lebensjahr dabei ist und so wichtige Werkzeuge wie dpkg mitentwickelt und auch dokumentiert, wie man selbst zu Debian beitragen kann.
Außerdem fällt er auf der Mailingliste debian-devel immer mit technischen und sachkundigen Posts auf, was man nicht von allen Teilnehmern der Liste behaupten kann.
Dann wäre da noch sein Buch Debian Administrator's Handbook, dass in Zusammenarbeit mit Roland Mas erschienen ist. Ich denke, es ist ein großartiger Beitrag zu Debian GNU/Linux, da es unter einer freien Lizenz steht und für jeden online oder zum Download bereitsteht und ein wirklich gutes Nachschlagewerk zu vielen Themen rund um Debian ist.
So viel zu meinen wichtigsten Gründen. Mag sein, dass ich zu kritisch bin und mehr Permalinks setzen sollte. Ich versuche das mit Links zu speziellen Artikeln in einzelnen Posts, die zum Thema passen und interessant sind, wieder wett zu machen. Vielleicht ist am Ende ja zumindest ein wenig tröstend, dass ich alle gleich schlecht behandele.

Posted on

Aufräumtipps Teil III: Debsums – Geänderte oder kaputte Dateien mit Debian und Ubuntu finden

Debians Paketsystem kann mehr als nur Software installieren. Tatsächlich ist jedes Paket nach einem sehr präzisen Schema aufgebaut, dass es ermöglicht zusätzliche Informationen zu speichern. Eine (beinahe) unverwechselbare Eigenart jedes Pakets ist die Md5-Prüfsumme. Beinahe deswegen, weil es mittlerweile möglich ist verschiedene Dateien zu erzeugen, die den gleichen Hashwert besitzen.
Zum Auffinden von geänderten Dateien gibt es das Paket debsums. Ruft man es einfach mit

debsums


auf, ist die Ausgabe sehr wortreich und zeigt mit OK oder FAILED an, ob eine Datei eines installierten Debianpakets manipuliert wurde oder nicht. Ausgeschlossen von dieser Anzeige sind grundsätzlich Konfigurationsdateien. Mit der Option -a, --all werden diese in die Überprüfung miteinbezogen. Gibt man hingegen -e, oder --config an werden nur geänderte Konfigurationsdateien angezeigt.
Die interessanteste Option aber ist -c oder --changed, mit der sich nur die veränderten Dateien anzeigen lassen. Ich hatte vor einigen Wochen die Installationsbeschreibung für meinen neuen Drucker niedergeschrieben und dabei auch dokumentiert, dass ich /lib/udev/rules.d/60-libsane.rules ändern musste.
Ein paar Wochen später wunderte ich mich, warum der Scanner nicht mehr richtig funktionieren wollte. Ich hatte leider vergessen, dass die Regeln durch ein Upgrade von udev überschrieben wurden und somit meine Veränderungen verloren gingen. (Ich muss das im alten Beitrag noch ergänzen. 🙂 )
Mit

debsums --changed


sieht man dann sofort, welche Dateien des Pakets geändert worden sind und kann ggf. Vorsichtsmaßnahmen ergreifen. Nicht jedes Debianpaket bietet eine Md5-Prüfsumme an. Wie Eingangs schon erwähnt besteht auch die Möglichkeit identische Prüfsummen für zwei verschiedene Dateien oder Pakete zu erzeugen, weswegen man sich nicht blind auf debsums bei einem Sicherheitsaudit des eigenen Rechners verlassen sollte. Es gibt auch Software wie z.B Tiger, die eine solche Funktion schon integriert hat.
Insgesamt ist debsums ein sehr nützliches Werkzeug, wenn man schnell wissen möchte, was sich gegenüber dem Originalpaket geändert hat oder wenn man fremde Rechner übernimmt und einen schnellen Überblick über die Veränderungen haben möchte.
Dieser Tipp stammt ebenfalls aus dem englischen Blog von Raphaël Hertzog.

Posted on

Aufräumtipps Teil II: Automatisch installierte Pakete mit Debian und Ubuntu entfernen

Hier ist ein weiterer Artikel zum Thema Aufräumen mit Debian und Ubuntu, der sich an den letzten Artikel nahtlos anschließt. Raphaël Hertzog hat in seinem englischen Blog daraus eine kleine Serie gemacht, die ich so interessant fand, dass ich sie in Deutsch hier festhalten wollte.
In diesem Fall geht es um automatisch installierte Pakete und wie man sie wieder loswerden kann.
Jeder kennt das sicherlich bei Debian und Ubuntu, wenn man apt-get oder aptitude benutzt und folgende Ausgabe im Terminal zu sehen ist.

apt-get install claws-mail
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
Statusinformationen werden eingelesen... Fertig
Die folgenden zusätzlichen Pakete werden installiert:
claws-mail-i18n libcompfaceg1 libetpan15 libpisock9
Vorgeschlagene Pakete:
claws-mail-doc gedit kwrite mousepad nedit claws-mail-tools jpilot pilot-link kpilot gnome-pilot evolution sylpheed
Die folgenden NEUEN Pakete werden installiert:
claws-mail claws-mail-i18n libcompfaceg1 libetpan15 libpisock9
0 aktualisiert, 5 neu installiert, 0 zu entfernen und 2 nicht aktualisiert.
Es müssen 4.356 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 11,3 MB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren [J/n]?

Die "folgenden zusätzlichen Pakete" sind die automatisch installierten Pakete, die man zwar nicht explizit installieren wollte, die aber notwendig sind, damit das ursprüngliche Programm, claws-mail, reibungslos funktioniert.
Aptitude stellt für diese Pakete ein Extrafeld zur Verfügung.

Mit aptitude show claws-mail-i18n findet man z.B.

Automatically installed: yes

Je nachdem welches Frontend man bevorzugt, kann man entweder mit

apt-mark showauto

oder

aptitude search ~M


automatisch installierte Pakete finden. Während aptitude diese zusätzlich installierten Pakete mit aptitude remove claws-mail oder aptitude purge claws-mail entfernen würde, benachrichtigt apt-get einem nur über diese Möglichkeit. Tatsächlich muss man noch apt-get autoremove ausführen, damit apt-get diese automatisch installierten Pakete wieder entfernt.
Der Trick mit diesem Feature ist der folgende. Man kann zum einen Software als automatisch installiert markieren.

apt-mark markauto cmus

oder

aptitude markauto cmus

Damit erkennt der Paketmanager, dass diese Pakete nicht mehr gebraucht werden, sofern kein weiteres Paket mehr davon abhängt. Auf meinem System würde der letzte Befehl z.B. sofort zur Deinstallation von cmus führen.
Häufiger hingegen kommt es vor, dass plötzlich ganze Desktopumgebungen deinstalliert werden sollen, wenn man nur daran interessiert ist Teile der Gnome-Desktopumgebung zu entfernen.
Der "Trick" besteht auch hier darin, dem Paketmanager zu signalisieren, was man behalten möchte und was nicht. Stellt man fest, dass Metapakete oder wichtige Software wie gnome-session oder gnome-shell entfernt werden sollen, kann man mit

apt-mark unmarkauto gnome-session gnome-shell oder
aptitude unmarkauto gnome-session gnome-shell


dem System deutlich machen, dass man diese Pakete behalten möchte. Mit dieser Methode lässt sich gezielt automatisch installierte Software entfernen, ohne dass die ganze Distribution dadurch in Mitleidenschaft gezogen wird.
Zusammen mit den weiteren Hilfsmittel ist das eine gute Ausgangsbasis sein Debian minimal und sauber zu halten.

Posted on

Logcheck: Überwachung von Logdateien mit Regulären Ausdrücken

Letzte Woche hatte ich Logwatch vorgestellt, dass bei mir auf dem Server seinen Dienst als Beobachter von Logdateien verrichtet. Wie so oft bei Linux gibt es natürlich eine Reihe von Alternativen. Darunter habe ich mir später Logcheck genauer angeschaut.
Der größte Unterschied nach der Installation ist das Benachrichtigungsintervall, das standardmäßig eine Stunde beträgt. Die ganze Konfiguration befindet sich in /etc/logcheck. In der Datei logcheck.conf wird das allgemeine Verhalten festgelegt. In logcheck.logfiles definiert man hingegen die zu überwachenden Logdateien. Für einen Server sollte

REPORTLEVEL="server"

eingestellt sein. Für einen reinen Desktop-PC genügt hingegen "workstation" und für sicherheitskritische Systeme kann es auch "paranoid" sein.
Logcheck funktioniert nach einem simplen Prinzip. Je nach REPORTLEVEL werden die Regeln in /etc/logcheck/cracking.d/ und /etc/logcheck/violations.d/ abgearbeitet und auf die vorher definierten Logdateien angewendet. Treffen die dort formulierten Bedingungen zu wird entweder ein ATTACK- oder SECURITY-Alarm ausgelöst. In den entsprechenden Ignore-Ordnern für Paranoid, Server und Workstation befinden sich hingegen Regeln als Reguläre Ausdrücke, die "normale" Einträge herausfiltern.
Alles was weder unter ATTACK noch SECURITY fällt ist dann ein sogenanntes SYSTEM-Ereignis, was z.B. auch der Download einer Datei vom FTP-Server sein kann.
Voreingestellt werden /var/log/syslog und /var/log/auth.log überwacht. Um z.B. die Logdateien des vsftpd-Servers zu überprüfen, trägt man in /etc/logcheck/logcheck.logfiles den Pfad zur Logdatei

/var/log/vsftpd.log

ein. Schon nach kurzer Zeit erhält man Meldungen wie

Sun May 27 22:06:24 2012 [pid 2] CONNECT: Client "123.123.123.123"

Danach findet jedoch kein Download statt, dennoch wird eine E-Mail-Benachrichtigung verschickt. Diese Art von Meldungen lassen sich in /etc/logcheck/ignore.d.server/vsftpd als Regulärer Ausdruck definieren. Daraufhin wird das Vorkommnis während der stündlichen Auswertung ignoriert.
Regel

^w{3} w{3} [ :[:digit:]]{11} [ :0-9]{4} [pid [0-9]+] CONNECT: Client "[0-9]+.[0-9]+.[0-9]+.[0-9]+"$

Dieser Reguläre Ausdruck nach dem POSIX-Standard passt genau auf die Zeile der Logdatei. Da ich ihn selbst geschrieben habe, verstehe ich zwar was damit gemeint ist. Wenn man hingegen vor fremden Regulären Ausdrücken steht, muss man sich oft erst einmal in die Materie einarbeiten und einige Knoten lösen.
Mir hat definitiv die schon vorhandene Konfiguration bei Logcheck geholfen. Weiterhin kann ich auch den englischen Wikipedia-Artikel zum Thema Regular Expressions empfehlen. Ferner gibt es unter dem Suchbegriff "regexp tester" zahllose Seiten, die in Javascript, Flash oder Java eine Plattform anbieten um eigene Ausdrücke zu testen. Keine davon hat mich aber auf den ersten Blick vollkommen begeistert.
Ich denke am einfachsten ist es, man schreibt den Regulären Ausdruck in eine Datei und testet ihn mit egrep -f, z.B.

egrep -f meine_regeln /var/log/vsftpd.log


Wird im Terminal eine Ausgabe angezeigt stimmt alles. Oft fange ich dabei erst einmal grob an, indem ich Sonderzeichen wie Punkte oder eckige Klammern escape und danach dann Wort für Wort und Zahl für Zahl alles ersetze. Ziel ist es die unerwünschten Zeilen so genau wie möglich mit Regulären Ausdrücken einzugrenzen.
Logcheck erfordert etwas Einarbeitungszeit, damit es sehr gut funktioniert. Gibt es nichts zu melden oder funktionieren die Ignore-Regeln bleibt Logcheck leise und meldet sich nur noch, wenn es wirklich was zu sagen gibt.

Posted on

vsftpd und OpenArena: Konfiguration eines sicheren FTP-Servers mit ausschließlich anonymen Zugang

Vor kurzem ergab sich die Gelegenheit einen FTP-Server aufzusetzen. Für ein anderes Vorhaben abseits von linuxiuvat.de brauchte ich zuerst nur einen OpenVPN-Server, da aber noch ausreichend Leistung zur Verfügung stand, installierte ich zusätzlich noch vsftpd.

Der FTP-Server eignet sich ideal, um PAK3-Dateien von meinem OpenArena-Server herunterladen zu können. Falls der Spiel-Client nicht kompatibel sein sollte, wird der Client automatisch beim Verbinden zum FTP-Server umgeleitet und lädt von dort Patches, Karten, Texturen und neue Sounds herunter.

Installation und Konfiguration

Vsftpd ist stark konfigurierbar und beherrscht noch viele weitere Optionen, die mit man vsftpd.conf einsehbar sind. Ein sicherer anonymer Zugang zum Herunterladen ohne Berechtigungen zum Dateiupload, lässt sich mit wenigen Handgriffen so verwirklichen.

aptitude install vsftpd
dpkg-reconfigure vsftpd


Mit Hilfe von DebConf wird der FTP-Benutzer und das FTP-Wurzelverzeichnis festgelegt.

    1. Den Systembenutzer "ftp" für vsftpd einrichten.

    1. Das FTP-Wurzelverzeichnis definieren, aus dem der anonyme Benutzer nicht wechseln kann.

Die Standardeinstellungen kann man hier problemlos beibehalten.
Die weitere Konfiguration befindet sich in /etc/vsftpd.conf. Im Prinzip halten sich auch hier die Veränderungen in Grenzen. An dieser Stelle dokumentiere ich nur die Veränderungen zur Standardinstallation mit Debian Squeeze.

nopriv_user=ftpsecure

Vsftpd verwendet einen weiteren unpriviliegerten und vollkommen isolierten Systembenutzer. In der Standardeinstellung ist das "nobody". Da dieser auch für andere Dienste oft verwendet wird, empfiehlt es sich aus Sicherheitsgründen noch einen weiteren, einzigartigen Systembenutzer anzulegen, z.B. ftpsecure.

adduser --system --no-create-home --disabled-login ftpsecure


Der FTP-Server wird zwar mit Root-Rechten gestartet, sobald aber eine Verbindung mit dem Client hergestellt wird, startet der Kindprozess mit den unpriviliegerten Rechten von ftpsecure und ftp.

# Die Dateiberechtigungen sollen für den anonymen Benutzer immer mit ftp:ftp angezeigt werden
hide_ids=YES
# Das FTP-Wurzelverzeichnis lässt sich mit dieser Variable ändern, wenn man
# nicht auf die DebConf-Methode zurückgreifen möchte.
# anon_root=/home/ftpsecure
# Maximale Anzahl an erlaubten gleichzeitigen Verbindungen. Entspricht bei
# mir der maximal möglichen Anzahl von Spielern auf dem OpenArena-Server.
max_clients=16
# Wieviele Verbindungen pro IP sind erlaubt
max_per_ip=4

Die gesamte vsftpd.conf sieht in meinem Fall so aus.

listen=YES
anonymous_enable=YES
dirmessage_enable=YES
use_localtime=YES
xferlog_enable=YES
connect_from_port_20=YES
nopriv_user=ftpsecure
ftpd_banner=Welcome to another FTP service.
secure_chroot_dir=/var/run/vsftpd/empty
pam_service_name=vsftpd
rsa_cert_file=/etc/ssl/private/vsftpd.pem
hide_ids=YES
max_clients=16
max_per_ip=4

Abschließend lässt sich mit mount --bind das Datenverzeichnis von OpenArena noch einmal im FTP-Wurzelverzeichnis im Unterordner /oa/baseoa nur lesbar einhängen. Um die Veränderung dauerhaft zu behalten, kann der Vorgang auch in /etc/fstab festgeschrieben werden.

/usr/share/games/openarena/baseoa       /srv/ftp/oa/baseoa      none     ro,bind        0       0

Nach diesem Schema lassen sich weitere Verzeichnisse nur lesbar im FTP-Wurzelverzeichnis einhängen.

Einstellungen für OpenArena

In der server.cfg von OpenArena kann man festlegen, ob der Download von Dateien erlaubt ist oder nicht.

sets sv_allowdownload 1

Ist das Herunterladen wie in diesem Fall mit 1 gestattet, wird mit sv_dlURL bestimmt, von welchem Web- oder FTP-Server der Client die Dateien beziehen soll, sofern sich seine Version von der des Servers unterscheidet. Der Vorgang ist auch als Fast Download bekannt und ein Feature, dass nach der Veröffentlichung des Quellcodes von Quake3 hinzugefügt worden ist.

sv_dlURL "ftp://123.123.123.123/oa"

Dabei kann man den letzten Schrägstrich nach dem Verzeichnis "oa" weglassen, da er automatisch durch den OpenArena-Server gesetzt wird. Im Verzeichnis "oa" auf dem FTP-Server muss das Unterverzeichnis baseoa erstellt werden, welches wiederum die PAK3-Dateien zum Spielen enthält.
Gibt man keine URL zum Herunterladen an, liefert der OpenArena-Server die Dateien nach der alten Quake3-Methode selbst aus, was sehr lange dauern kann. In neueren Versionen der ioquake3-Engine gibt es die Möglichkeit eine neue Variable zu definieren, welche die Download-Geschwindigkeit erhöht. Folgender Wert setzt diese auf 100 Kb/s pro Client fest.

sv_dlRate "100"

Wichtig
Wer bei Debian und Ubuntu einzelne Custom Maps zum Download anbieten möchte, muss diese bei OpenArena 0.8.8 im versteckten Verzeichnis /var/games/openarena/.openarena/baseoa ablegen, wo sich auch die server.cfg befinden kann, wenn man sich nicht für /etc/openarena-server/ entschieden hat. Auf dem FTP-Server hingegen verändert sich nichts und alle PAK3-Dateien liegen weiterhin im Verzeichnis baseoa.

Posted on

Logwatch der Loganalysierer: Ein Beispiel mit Lighttpd

Zum Thema Monitoring, Serverüberwachung und Intrusion Detection System (IDS) habe ich mir in den letzten Wochen ein paar Gedanken gemacht und neue Software ausprobiert. Ich habe das Thema noch nicht abgeschlossen und teste von Zeit zu Zeit noch das ein oder andere Programm an, was mir bei dieser Aufgabe für meinen Server helfen könnte. Heute stelle ich Logwatch näher vor.

Zur Zeit benutze ich Monit zur Überwachung von Prozessen wie Lighttpd oder den Spieleservern. Es kam in der Vergangenheit bei OpenArena z.B vor, dass der Server wegen eines unbekannten Fehlers unregelmäßig gecrasht ist. Dank Monit wird der Server automatisch neugestartet.
Für den langfristigen Trendverlauf bei Systemressourcen oder Benutzung der Spieleserver verwende ich Munin, womit die Werte grafisch anschaulich aufbereitet werden.
Die Mehrzahl der Daten wird natürlich in Logdateien gespeichert. Da die Menge an Informationen manuell nicht in annehmbarer Zeit zu überprüfen ist, braucht es einen Loganalysierer, der die Daten für Menschen lesbar aufbereitet und im Idealfall nur die "wichtigen" Informationen herausfiltert.
Ein bekannter Loganalysierer heißt Logwatch, den ich am längsten kenne und seit Anfang an für den Server benutze. Speziell für Berichte über die Vorgänge mit der Firewall gibt es aber auch noch FwLogwatch. Ebenfalls angeschaut habe ich mir Logcheck, Swatch und Tenshi. Snort steht auf jeden Fall noch auf der Todo-Liste und mit Tiger als Auditor habe ich auch schon gute Erfahrungen gemacht.

Logwatch

aptitude install logwatch

Ein großer Pluspunkt von Logwatch ist, dass es direkt nach der Installation einfach funktioniert und täglich eine Zusammenfassung als Textmail an Root und die externe Adresse schickt, sofern man zuvor einen Mailserver eingerichtet hat.
Logwatch ist in der Standardeinstellung auf einen niedrigen Detaillevel eingestellt. Die Werte reichen von 0 (low) über 5 (medium) bis 10 (high). Grundsätzlich werden die Logs der letzten 24 Stunden analysiert, wozu der Cronjob in /etc/cron.daily/00logwatch aufgerufen wird. Diese Zeitsteuerung lässt sich wie schon beschrieben über das Verschieben von 00logwatch in den entsprechenden Cron-Ordner oder durch die Bearbeitung der Crontabs ändern.
Die Reichweite der Loganalyse kann auch per Option direkt an Logwatch übergeben werden. Weitere Hinweise dazu finden sich mit logwatch --range Help.

Konfigurationsbeispiel mit Lighttpd

Für einen tiefergehenden Einblick in die Materie empfehle ich einen Blick in Howto-Customize-Logwatch.gz und Readme.Debian in /usr/share/doc/logwatch/ zu werfen. Das Konzept der Konfiguration ist dort ausführlich beschrieben.
Prinzipiell finden sich in den Unterverzeichnissen logfiles und services in /usr/share/logwatch/default.conf die Regeln, welche Logdateien analysiert werden sollen und Parameter, die den Output näher bestimmen. Die tatsächliche Arbeit verrichten aber die Skripte in /usr/share/logwatch/scripts.
Die zentrale Konfigurationsdatei ist logwatch.conf und befindet sich zusammen mit ignore.conf in /usr/share/logwatch/default.conf. Schon rein aus formalen Gründen habe ich aber alle Dateien dort unangetastet gelassen, da Debian selbst die Werte im Verzeichnis /usr/share/logwatch/dist.conf/ überschreibt und jede individuelle Einstellungen wie gewohnt in /etc/logwatch/ festgelegt wird.
Die Unterverzeichnisse in /etc/logwatch/ spiegeln die Verzeichnisstruktur in /usr/share/logwatch wider. Man muss also nur die modifizierten Dateien für Logfiles und Services dort ablegen.
In meinem Fall habe ich den Service http angepasst, der standardmäßig auf die Analyse von Apache ausgerichtet ist. Mit wenigen Handgriffen funktioniert er aber auch für Lighttpd.

Kopieren

/usr/share/logwatch/default.conf/logfiles/http.conf --> /etc/logwatch/conf/logfiles/
/usr/share/logwatch/default.conf/services/http.conf --> /etc/logwatch/conf/services/

Anpassen

Meine http.conf für logfiles.
Meine http.conf für services.
Die Logdateien für meinen Lighttpd-Webserver liegen immer in /var/log/lighttpd/linuxiuvat.de/. Mit

LogFile = lighttpd/linuxiuvat.de/*access.log.1

wird der relative Pfad zu /var/log und meinen Logdateien festgelegt, wobei es noch drei weitere Zeilen in dieser Form gibt, die auf die anderen Logdateien verweisen.
Die zweite http.conf Datei ist der sogenannte Filter oder Service, der auf die Logdateien angewendet wird. Ich habe den Titel auf "Lighttpd" gesetzt und den Detaillevel auf 10 erhöht. Dadurch wird der Standard von 0 überschrieben und die Ausgabe von Lighttpd deutlich "lauter". Der Rest beschränkt sich darauf Parameter auszukommentieren, die nützlich sein können, z.B.

$HTTP_USER_DISPLAY = "$field{http_rc} >= 400"

womit alle HTTP-Fehlermeldungen >= 400 angezeigt werden.

override.conf

In /etc/logwatch/conf kann man die Datei override.conf anlegen, womit sich die globalen Einstellungen aus logwatch.conf überschreiben lassen. Ich brauchte z.B. nicht den Output des Service Iptables.

logwatch: Service = "-iptables"

Mit dem Schlüsselbegriff logwatch: wird die Veränderung eingeleitet, danach folgt der Name der Variable und der Wert. Weitere Ideen, was sich manipulieren lässt, finden sich in logwatch.conf.

Fazit

Das Kopieren und Editieren der Konfiguration ist bei Logwatch erst einmal Gewöhnungssache. Der Vorteil liegt darin, dass die Originaldateien unangetastet bleiben und man alles ordentlich dort hat, wo es hingehört, in /etc. Wer viele Veränderungen vornehmen muss und diese auf mehrere Server anwendet, sollte besser über eine Neukompilierung des Pakets nachdenken.
Mir gefällt Logwatch sehr gut, da es bisher die anderen Methoden gut ergänzt. Logwatch ist ein Teil der Lösung aber eben nicht alles. Für mich ist eine tägliche E-Mail-Benachrichtigung ausreichend. Außerdem ist die Standardkonfiguration sehr gut. Wer noch mehr Kontrolle und andere Voreinstellungen bevorzugt, sollte sich Logcheck anschauen. Dort wird man anfangs sogar stündlich informiert und kann durch Reguläre Ausdrücke festlegen, was man sehen möchte oder eben nicht.

Posted on

Blockorientierte Geräte und der Mythos mit dd

Den interessanten Thread zu Wheezy und dem Umgang mit begrenztem Platz auf Installations-CDs habe ich noch eine Weile weiterverfolgt. In den Kommentaren zu meinem letzten Beitrag gab es gemischte Stimmen, aber ich denke, die meisten waren sich einig, Daten-CDs stellen immer mehr eine Randerscheinung dar. Audio-CDs behalten noch eine Weile ihren nostalgischen Wert als "Musik zum Anfassen" und manchmal hat man sie einfach noch im Schrank, weil die 50er-CD-Spindel einfach nicht kleiner werden möchte.

Mir geht es ähnlich, die meisten CD-Rohlinge im meinem Schrank habe ich mal als Geschenk erhalten. Als Endnutzer bin ich von dem Thema nicht akut betroffen, ich verwende fast immer die Netzinstallation, installiere eine Basisinstallation und baue von dort mir mein eigenes Wunschsystem zusammen.
Der Thread spaltete sich danach ein wenig auf und verzweigte sich in verschiedene Richtungen. Plötzlich wurde auch das Thema angesprochen, wie Debian Benutzern die Installation von USB-Sticks vermittelt.

dd - suboptimale Performance

dd if=debian.img of=/dev/sdX

Bevor ich nun mit Korrekturmails überzogen werde, das ist nicht der Weg den Debian beschreibt. Ich persönliche hatte aber jahrelang im Hinterkopf: dd ist das sinnvollste Kommando für blockorientierte Geräte und ist eben auch für USB-Sticks gedacht.
Debian schlägt z.B vor

cat - Alternative und schneller

cat debian.img > /dev/sdX

Der Cat-Befehl vollbringt die gleiche Aufgabe, funktioniert aber auf den meisten Systemen effizienter als dd. Das ist aber nur der Fall, wenn man vergessen hat bs= als Option bei dd anzuführen.

dd - der bessere Weg

Für das Schreiben auf blockorientierte Geräte wurde eine Größe von 4 MB für die Option bs empfohlen. Jeder Eingabeblock wird dabei durch die Option oflag=sync zur maximalen Größe von 4 MB mit Nullen aufgefüllt, sollte er kleiner sein.
dd if=debian.img of=/dev/sdX bs=4M oflag=sync

cp - auch das ist möglich

Früher habe ich gelernt, dass man dd für Abbilder benutzt, das GNU-Kommando cp hingegen nur für das Kopieren von Dateien auf eingehängten Datenträgern. Man lernt bekanntlich nie aus, aber cp kann ebenfalls Abbilder auf blockorientierte Geräte schreiben.

cp debian.img /dev/sdX


Ein weiterer interessanter Tipp war anstelle von /dev/sdX z.B. in /dev/disk/by-id/ nach dem USB-Stick zu schauen und diese Datei zu benutzen, wenn man sicherer auf das eigene USB-Gerät verweisen möchte.
Am Ende erfüllen alle Kommandos ihren Zweck. Bei dd werde ich in Zukunft noch mehr auf die Option bs achten und in den alten Artikeln, wo ich darauf nicht hingewiesen habe, das nun nachholen.