linuxiuvat – gambaru.de

Januar 3, 2013

Linux iuvat – Spieleserver mit Debian: 2012 in schicken Graphen

Ich denke, es hat sich ausgezahlt Munin und Qstat vergangenes Jahr zu installieren. Hier sind noch ein paar Charts, die die Auslastung der einzelnen Spieleserver über das Jahr repräsentieren. Die Graphen lesen sich so:
Die Y-Achse visualisiert die Anzahl der Spieler bzw. Bots, die zu einem Zeitpunkt X auf dem Server spielen. Die Werte wurden alle 5 Minuten mit QStat ermittelt und dann mit Hilfe von Munin in einen Graph umgewandelt. Es kann durchaus vorgekommen sein, dass 10 Spieler auf dem Server gespielt haben, jedoch diesen in dem Moment verlassen haben als der Wert mit Munin und QStat registriert wurde. Auf das Jahr verteilt sollte diese Unschärfe jedoch kleiner ausgefallen sein.

OpenArena

Mein Favorit. Die Serverkonfiguration machte hier am meisten Spaß und der Server wird rege genutzt. Standardmäßig wird Deathmatch, also "Jeder-gegen-Jeden", angeboten. Der Mapcycle besteht aus 60 Karten, wobei die populärsten bzw. am besten spielbaren Karten öfter aufgerufen und immer wieder einige größere oder unbekanntere Maps eingestreut werden. Jeden Mittwoch ändert sich automatisch die Konfiguration, InstantGib ist an der Reihe. An jedem ersten Sonntag in Monat gibt es dann noch einen besonderen Spielmodus, der sich "Ketchup Vampire" nennt. Der merkwürdige Name stammt von der Tatsache her, dass man in diesem Modus pro zugefügtem Schadenspunkt 0.33333 Lebenspunkte erhält ("vampire mode") und es für bessere Spieler umso schwieriger wird Frags zu erzielen, je größer die Differenz in Frags zu den nachfolgenden Spielern ist ("catch up").

Der Jahreschart zeigt ziemlich eindrucksvoll, dass der Server täglich besucht wird und im Vergleich zu den anderen Spieleservern auch die höchste Auslastung hat. Auffallend sind die Spitzen bei kontinuierlich 3-4 zu jeder Tageszeit, was für OpenArena ziemlich viel ist. Bis auf eine Ausnahme war dieser Ausschlag jeweils auf das Abschalten eines "konkurrierenden" Deathmatch-Servers zurückzuführen, der praktisch alle DM-Spieler in Europa bündelt. Der Wert stellt also so etwas wie die theoretisch mögliche Auslastung dar. Als ich von 0.8.5 auf 0.8.8 im Mai wechselte, brach die Spielerzahl ein wenig ein, besserte sich dann aber wieder, nachdem ich den FTP-Server eingerichtet hatte, von wo aus man automatisch die neuen Daten beziehen kann. Im Sommer keine Überraschungen: Weniger Spieler, dafür mehr Sonne und Luft. Gut so.
Das Phänomen kennt jeder Onlinespieler. Es gibt einen Server A auf dem 5 Spieler spielen und einen Server B mit 0 Spielern. Welchen Server wird Spieler A beitreten? Natürlich joint jeder A. So bleibt der eine Server immer recht gut besucht und wenn sich dort einige Stammspieler regelmäßig einfinden, bleibt das auch so. Jeder neue Server muss hingegen erst um diese Stammspieler durch gute Pings und ein abwechslungsreiches Programm werben und ich denke, dies hat bei meinem Server von Anfang an ganz gut geklappt und an manchen Tagen kann man stundenlang ohne Unterbrechung menschliche Spieler "fraggen".

Red Eclipse

Red Eclipse ist ein ziemlich neues Spiel für Debian und Ubuntu. Genauso wie Sauerbraten basiert es auf der Cube-Engine und ist dementsprechend äußerst anspruchslos an die Hardware. Jedoch unterscheiden sich Gameplay und Design deutlich vom Ogre-Spiel. Das Ganze ist eher futuristisch gehalten. Munition oder das Sammeln von Items steht gar nicht im Vordergrund. Hier geht es mehr um Bewegung. Faszinierend sind die zahlreichen Gamemodi und Einstellungsmöglichkeiten.
Die Community ist noch recht klein, wächst aber stetig. Wenn am frühen Morgen nur wenige Spieler online sein sollten, kann man immer noch auf ein Spiel gegen Bots zurückgreifen.

Als ich es zu gut meinte und selbst Servervariablen für alle freigegeben hatte, dauerte es keine zwei Tage bis mir Monit mitteilte, dass die Prozessorauslastung konstant bei über 75% lag. Als ich dem Server beitrat, war auch sofort klar warum. Die Werte waren so unnatürlich hoch, dass einzelne Gewehrsalven praktisch die Stärke von Erdbeben hatten und das ganze Spiel nur noch unnatürlich hin- und hervibrierte. Reich ihnen den kleinen Finger und sie reißen dir den Arm aus.
Nun läuft der Server ohne diese Freiheiten, aber immer noch mit der Möglichkeit über 100 Karten auszuwählen, darunter auch die von Sauerbraten. Die Anzahl der Spieler zog kurioserweise erst mit der Veröffentlichung der neuen Version 1.3.1 an, weil ich nicht wechselte bzw. nicht wechseln konnte. Debian ist im Freeze, weswegen Version 1.2 immer noch spielbestimmend ist. Da mein Server der einzige in Europa ist, der noch 1.2 benutzt bündelte das ein paar Spieler und ich hatte ja auch von der OpenArena-Geschichte gelernt. 🙂
Ich werde bis mindestens April daran festhalten, dann gibt es wohl auch einen Backport für Red Eclipse, zumindest erwähnte das der Maintainer mir gegenüber im IRC.

Sauerbraten

Das Spiel erinnert mich immer an alte LAN-Zeiten als man zum Krafttraining nicht ins Fitnessstudio gehen musste, sondern seinen Vorbis-Big-Tower und den Oschi von Röhrenmonitor durch die Gegend schleppen musste. Das war die Zeit als man auch noch solche BNC-Stecker zum Zocken brauchte, aaach ja.
Um wieder zum Spiel zurückzukommen, Sauerbraten macht eine Menge Laune. Das Spiel war sehr einfach als Server aufzusetzen und ist genauso einfach zu bedienen. Hier gab es schon eine umfangreichere Anleitung. Der Server ist absolut anspruchslos. Selbst bei einem vollen Server mit 16 aktiven Spielern, geht die CPU-Anzeige in htop nicht über 1% auf dem kleinsten vServer. Der Speicherverbrauch liegt ebenfalls bei unter 1% bei 256 MB RAM absolut. Einfach WOW.
Da der Client die ganze Arbeit übernimmt und der Ping nicht so die Rolle spielt, ermöglicht das auch Spielern aus Amerika problemlos in Deutschland zu zocken. Man sieht deswegen auch des öfteren in tiefster Nacht noch Ausschläge auf dem Graphen. Die Auslastung des Servers ist schwer vorherzusagen, da er absolut offen ist und vom "Master" auch wieder geschlossen werden kann. So kann es sein, dass 2 Spieler über Stunden den Server für sich beanspruchen und zu einer anderen Zeit sich ein Dutzend Leute zum Coop-Edit einfinden. Genauso war er aber gedacht. Der Aufwand den öffentlichen Server zu administrieren geht gegen Null.

Teeworlds

In Teeworlds steckt eine Menge Liebe. Das kann man nicht nur an den witzigen Tees erkennen, sondern auch an dem actionreichen Gameplay, dass den Spaß des klassischen 3D-Egoshooters in die zweidimensionale Welt transportiert hat. Die Serverkonfiguration ist ähnlich einfach wie bei Sauerbraten, der Server ein Vorbild an Effizienz.
Um den Spielern ähnliche Freiheiten wie bei Sauerbraten zu bieten, habe ich Karten und Spielmodi zur Abstimmung freigegeben und eigene Optionen in die Config eingebaut. Jeder hat also die Wahl Deathmatch, Capture the Flag oder Team Deathmatch zu spielen und zwischen allen offiziellen Karten zu wählen. Passend zum Spielmodus werden dann neue Variablen gesetzt.
Leider zeigte diese Wahl bis vor kurzem kaum Wirkung, der Server blieb weitestgehend leer. Das liegt vor allem daran, dass es mittlerweile an die 1000 Teeworld-Server gibt und meiner da eben nur einer unter vielen ist. Vergangenen Monat entdeckte dann scheinbar eine anonyme Gruppe von Leuten den Server und lastete diesen ordentlich aus. Deswegen hält Teeworlds auch den Tagesrekord. 🙂

Ich denke Teeworlds macht auf jeder LAN-Party eine Menge Spaß und ist von mir eine echte Empfehlung, wenn man Lust auf einen Ego-Shooter der anderen Art hat. Aber Vorsicht: Wenn du Probleme mit dem "Hooken" hast, wirst du auch schon mal als Noob beschimpft. 😯

Juli 25, 2012

Gegen die Feuerwand: Mal wieder DRDoS-Attacke auf OpenArena-Server

Seit ein paar Tagen wird mein OpenArena-Server erneut mit einer sogenannten DRDoS-Attacke überzogen. Der oder die Angreifer senden dabei gefälschte IP-Pakete mit Hilfe von Spoofing an den Server, damit dieser wiederum Statusanfragen an Webserver und ähnliche Dienste weiterleitet, deren Kapazitäten irgendwann nicht mehr ausreichen, um die gerechtfertigten Anfragen zu beantworten.
Mit iftop sieht das im Moment so aus:

Ich bin mir nicht sicher, ob das Ganze überhaupt durchdacht worden ist, momentan rauscht einfach alles in die Firewall. Es wird nicht einmal geprüft, ob der Server verwundbar ist, sondern einfach stur immer die gleichen Anfragen geschickt. Dass die Attacke somit sehr ineffizient ist, scheint niemanden zu stören.
Ich bin mit dem Server einen Port weitergezogen, um irgendeine negative Auswirkung auf das Spielerlebnis auszuschließen. Die beim letzten Mal erstellten Firewallregeln und der gepatchte Server haben zuvor ihr Übriges getan.
Da zwar sehr viele Anfragen hereinkommen, jedoch keine beantwortet wird, kann man diesen Umstand wunderbar mit vnstat beobachten. Normalerweise ist der Wert des TX-Graphen (grau) größer als der RX-Graph (grün).
Vnstat-stündlicher-Netzwerkverkehr
Vnstat-täglicher-Netzwerkverkehr
Letztes Mal hat es knapp zwei Wochen gedauert bis der Spuk vorbei war. Mal schaun wie lange es dieses Mal dauert.

Juli 20, 2012September 27, 2019

Fwlogwatch: Ein Firewall-Loganalysierer und Sicherheitswerkzeug

Eine der ersten Amtshandlungen auf dem neuen vServer war es, eine Firewall aufzusetzen. Das stellte sich Dank ufw als gar nicht so schwierig heraus. Ich experimentierte dann mit verschiedenen Logleveln und stellte schnell fest, dass ich ohne einen Loganalysierer für die Firewall schnell den Überblick verlieren würde.
Ich installierte daraufhin Fwlogwatch, ein Sicherheitswerkzeug, dass schon seit einem Jahrzehnt als Freie Software vorliegt. An dieser Stelle wollte ich es kurz vorstellen, da ich nicht wirklich viele Erfahrungsberichte dazu gefunden habe, die sich mit Fwlogwatch auseinander gesetzt haben. Mit Sicherheit gibt es noch andere Loganalysierer für Firewalls. Welche kennt und benutzt ihr davon und wie geht ihr generell mit dieser Thematik um?

Installation und Konfiguration

aptitude install fwlogwatch

Fwlogwatch kann sowohl per Konfigurationsdatei als auch über die Kommandozeile konfiguriert werden. Nur die Optionen, die nicht ausdrücklich in fwlogwatch.config definiert wurden, können per Kommandozeilenparameter geändert werden. Im Folgenden konzentriere ich mich auf die Beschreibung der Konfigurationsdatei.
Bei Debian und Ubuntu ist es am sinnvollsten zuerst die Standardeinstellungen mit

dpkg-reconfigure fwlogwatch

festzuschreiben. Die Einstellungen befinden sich danach in /etc/default/fwlogwatch. Die Screenshots zeigen die sechs Möglichkeiten, die zur Auswahl stehen. Ich habe mich dafür entschieden Fwlogwatch als Daemon im Echtzeitmodus zu starten und zusätzlich einmal täglich eine E-Mail-Benachrichtigung mit der Auswertung der vergangenen 24 Stunden zu erhalten. Auf das automatische Anlegen von Firewall-Regeln habe ich verzichtet.

Die zentrale Konfigurationsdatei existiert in /etc/fwlogwatch/fwlogwatch.config. Die Datei ist sehr gut in Englisch dokumentiert. Hier ist ein Auszug mit den für mich wichtigsten Einstellungen.

# Input-Datei
input = /var/log/messages
# Wir analysieren eine Netfilter-Firewall
parser = n
# Angezeigt werden: Quell-IP, Protokoll und Zielport.
src_ip = on
protocol = on
dst_port = on
# Diese Quelle soll ausgeschlossen werden
exclude_src_host = 123.123.123.123
# Sortierungsreihenfolge
sort_order = Sacd
# Anzeige der Paketgröße
data_amount = yes
# nur die letzten 24 Stunden anzeigen
recent = 24h
# Fwlogwatch soll als Benutzer nobody laufen
run_as = nobody
# Im Echtzeitmodus soll benachrichtigt werden
notify = yes

Einmal am Tag erhält man danach eine E-Mail, die alle Vorkommnisse in der vorher festgelegten Sortierreihenfolge auflistet. Dieser ältere Artikel für die Slackware-Distribution erklärt anhand einiger Beispiele wie man Fwlogwatch von der Kommandozeile bedient und verschiedene Sortierverfahren nutzen kann, um Muster in einem Angriff zu erkennen.

Jul 18 06:58:29 to - - [9948935.724847] [UFW BLOCK]  1 tcp packet (44 bytes) from xxx.xxx.xxx.xxx port 22
Jul 18 07:05:27 to - - [9949353.404245] [UFW BLOCK]  1 tcp packet (48 bytes) from xxx.xxx.xxx.xxx port 5900
Jul 18 07:30:49 to - - [9950876.155902] [UFW BLOCK]  1 udp packet (23 bytes) from xxx.xxx.xxx.xxx port 27970

Echtzeitmodus

Für den Echtzeitmodus existiert noch ein zusätzliches Webinterface, welches ebenfalls in fwlogwatch.config aktiviert wird. Das Statuspasswort muss verschlüsselt sein und lässt sich mit htpasswd -nb admin meingeheimesPasswort erzeugen. Man kann sich dann z.B. über einen SSH-Tunnel mit dem Webinterface verbinden.
ssh -p 44444 -L 8888:127.0.0.1:888 meinserver

server_status = yes
listen_port = 888
status_user = admin
status_password = Xjswdw/we3 #Beispiel für ein verschlüsseltes Passwort

Fwlogwatch-Status

Zum Schluss

Fwlogwatch bietet in /usr/share/doc/examples/ noch zwei CGI-Skripte, mit denen eine Zusammenfassung im HTML-Format auf einem Webserver präsentiert werden kann. Auch lassen sich alle täglichen Berichte per HTML-Mail verschicken, wenn man das möchte. Wurde notify=yes in der Konfigurationsdatei gesetzt wird zusätzlich eine Alarmnachricht versandt, wenn ein Schwellenwert an Verbindungen pro Zeitintervall überschritten wurde. Der Inhalt der Mail orientiert sich an den Angaben in /etc/fwlogwatch/fwlw_notify. Außerdem lassen sich auch automatisch neue Firewall-Regeln anlegen, wozu das Skript /etc/fwlogwatch/fwlw_respond berücksichtigt wird und externe CERT-Stellen mit vorgefertigten Templates alarmieren.
Ich persönlich finde die vielfältigen Sortierungsmöglichkeiten von Fwlogwatch nützlich, womit sich tatsächlich überhaupt erst eine Übersicht in die Analyse der Firewall-Logdateien bringen lässt. Ich stelle mir nur hin- und wieder die Frage, wie ich am besten auf die Tatsache reagiere, dass mein Server permanent gescant wird.

Juli 12, 2012November 19, 2019

Lecker – Cube 2: Sauerbraten

Es ist angerichtet. Anstatt kulinarischer Spezialitäten gibt es heute jedoch das native Linuxspiel Cube 2: Sauerbraten. Zugegeben für all die, wo Deutsch als Muttersprache haben tun, klingt dieser Name für einen waschechten Ego-Shooter erst einmal seltsam in den Ohren. Scheinbar aber nicht für den Erschaffer des Spiels, Wouter „Aardappel“ van Oortmerssen. Wen sollte das bei seinem Spitznamen, "Kartoffel", auch wundern.
In diesem Beitrag stelle ich Cube 2: Sauerbraten vor, das seit mehr als vier Monaten zu meinem Spieleprojekt gehört. Ich beschreibe hier die wichtigsten Spielmerkmale, natürlich gibt es auch Bilder und Links und eine auf den Punkt gebrachte Anleitung, wie man selbst einen dedizierten und offenen Sauerbraten-Server mit Debian und Ubuntu aufsetzen kann.
Und was den Namen anbelangt...einfach Englisch aussprechen: Sourrrrbrrrääten. Perfekter Name für einen Ego-Shooter. 🙂

Warum Sauerbraten?

Nachdem ich mir ein paar Kriterien für in Frage kommende Spiele ausgedacht hatte, punktete Sauerbraten auf jeden Fall mit seinen außerordentlich geringen Hardwareanforderungen sowohl beim Client als auch beim Server.
Das Spiel ist schnell, wirklich schnell, genauso wie in den guten alten Zeiten. Neben 20 verschiedenen Spielmodi existieren auch noch mehr als 150 offizielle Karten, 7 Waffen, ein toller Soundtrack und ein bemerkenswertes Feature, neue Karten mit mehreren Spielern gleichzeitig online zu erschaffen. Von all den Spielen auf dem Server ist es jedoch am "unfreisten". Richard Stallman wird es vermutlich nie spielen. Die Spielengine und damit der Server ist zwar unter einer freien Lizenz verfügbar, große Teile der Mediendateien jedoch nicht.
Dennoch glaube ich, dass Sauerbraten eine Chance verdient hat, da das Spiel nicht nur die Möglichkeit bietet neue freie Inhalte zu schaffen, sondern auch schon Projekte wie Red Eclipse inspiriert hat, deren Medieninhalte unter freien Lizenzen stehen.

Der Sauerbraten-Client

aptitude install sauerbraten
Die Spielanforderungen von Sauerbraten sind moderat. Eine 1-GHz-CPU, 256MB RAM und eine Geforce 4 MX sollten es mindestens sein. Wer jemals einen Ego-Shooter gespielt hat, kennt das grundlegende Prinzip. So lässt sich auch Sauerbraten mit den W-A-S-D-Tasten steuern, mit Space springt der eigene Avatar, mit der linken Maustaste wird geschossen und mit kreisenden Mausbewegungen das Sichtfeld geändert.
Danach sind noch erwähnenswert:
R - Sollte man trotz aller Versuche in einer Ecke zu campen über die Flagge gestolpert sein, dann kann man sie mit einem Druck auf R wieder fallenlassen. 😉
T - öffnet den Chat. Auf einem öffentlichen Server ohne AUTH kann man mit der Eingabe von /setmaster 1 Masterrechte erlangen. Dazu gleich mehr.
E - Startet den Bearbeitungsmodus, in dem es möglich ist, innerhalb des Coop-Edit-Modus mit mehreren Mitspielern gleichzeitig eine Karte zu verändern oder neuzugestalten! Auf ogros.org gibt es eine nette Übersicht zu einer (englischen) Videoanleitung zum Thema.
Mehr ist wirklich nicht notwendig, um in das Spiel einsteigen zu können.

Serverbrowser und das Menü

Das Spielmenü und insbesondere der Serverbrowser könnten übersichtlicher gestaltet sein. Es gibt jedoch die Möglichkeit ein eigenes zu erstellen, wie dieser Artikel auf ogros.org beschreibt. Da die Voreinstellungen gut sind und man intuitiv in das Spiel findet, muss man sich hier nicht lange aufhalten. Unter Keys lassen sich die Tastenbelegungen ändern.

Cube Server Lister

Ich hatte den Cube Server Lister schon an anderer Stelle erwähnt. Wer sich mit dem normalen Serverbrowser nicht anfreunden kann, sollte sich die Zeit nehmen und der Anleitung folgen, wie man sich ein eigenes CSL-Debianpaket erstellen kann. Mit diesem Hilfsprogramm, dass unter der GPL veröffentlicht worden ist, lassen sich Details zu allen Cube-2-Servern anzeigen und mit einem Doppelklick auf den Servernamen des jeweiligen Spiels tritt man einem Spiel bei.

Spielmodi

Sauerbraten bietet ein Wiki mit einem Multiplayer Guide und eine umfangreiche Dokumentation.
Im Mehrspielermodus gehört man entweder dem guten oder dem bösen Team an. Mit leisen Zwischentönen halten wir uns natürlich nicht auf. Unabhängig davon gilt: Die roten Spieler sind immer die Gegner und mit den blauen spielt man in einem Team zusammen.
In Sauerbraten gibt es sieben verschiedene Waffen: Doppelläufige Schrotflinte, Minigun, Gewehr, Raketenwerfer, Granaten, Pistole, Fäuste/Kettensäge. Dazu lassen sich in den meisten Modi Gesundheit, Rüstung und Munition aufsammeln.
Das Spiel bietet zur Zeit 20 verschiedene Spielmöglichkeiten und in der aktuellen Entwicklerversion stehen schon weitere parat. Neben dem klassischen Free For All (FFA) und InstaGib, wo es einfach nur um "Jeder gegen Jeden" geht, gibt es natürlich auch noch Fahnenraub (alias Capture the Flag). Mir persönlich gefällt "Regen Capture" ziemlich gut, wo man auf einer relativ großen Karte verschiedene Punkte kontrollieren muss. An einer eroberten Station erhält man Waffen, Leben und Punkte. Dieser Modus ist auch mit sehr vielen Spielern noch interessant und sehr dynamisch.
Der Screenshot zeigt eine Szene aus einem Spiel mit dem Modus "Regen Capture". Außerdem erkennt man an der Servernachricht, dass der Server gepatcht wurde.

Coop-Edit-Modus

Auf meinem offenen Server wird sehr oft der Coop-Edit-Modus genutzt. Hier lassen sich gemeinsam mit anderen Spielern bestehende Karten modifizieren oder komplett neue erstellen. Die oben erwähnte Anleitung zum Kartenbau oder ein Blick auf die Wiki-Seite Mapping and Editing ist ein guter Start in die Materie. Das Wichtigste: Wenn ihr einem Server beitretet, auf dem an einer neuen Karte gearbeitet wird, einfach /getmap in den Chat schreiben und ihr seht den aktuellen Stand vor euch. Hier sind ein paar Screenshots von einer Coop-Edit-Sitzung auf dem Server.
In Natenoms Blog findet ihr unter anderem ein cooles Video zu einer selbst erstellten Karte, die eine in sich geschlossene kleine Stadt darstellt. Da steckt sicher eine Menge Arbeit drin.

Musik

Sauerbratens instrumentaler Metalsoundtrack stammt von Marc A. Pullen, lässt sich auf last.fm herunterladen und befindet sich selbstverständlich auch im OGG-Format in /usr/share/games/sauerbraten/fanatic/.

Der Sauerbraten-Server

Aufgrund des besonderen Client-Server-Modells ist der Sauerbraten-Server sehr leichtgewichtig. Der Speicherverbrauch liegt bei 2-3 MB RAM auf einem 64bit-System und auch die CPU-Anzeige von htop habe ich selbst bei einem vollen Server noch nie über 1% springen sehen. Im Gegensatz zu vielen anderen Mehrspieler-Spielen ist es bei Sauerbraten nicht notwendig, dass Server und Client sich permanent über Treffer und Aktionen austauschen, was es erlaubt die wesentlichen Funktionen des Servers auf ein Minimum zu beschränken. Dadurch bleibt das Spiel selbst bei hohen Pings noch spielbar. Auf der anderen Seite macht es Sauerbraten gegenüber Cheatversuchen auch verwundbarer, was durch die Open-Source-Natur des Spiels noch begünstigt wird.

Die Authentifizierung

Sauerbraten begegnet diesem Problem mit einer ungewöhnlichen, aber nachvollziehbaren Entscheidung. Da selbst die populärsten proprietären Spiele mit einem Stab von bezahlten Entwicklern keinen vollkommenen Schutz gegen jede Art von Manipulationsversuch bieten können, haben die Entwickler die Verantwortung und Kontrolle an die Spielgemeinschaft zurückgegeben. Auf jedem Server kann ein Spieler sogenannter "Master" werden und Verstöße mit einem Bann vom Server bestrafen. Die Funktion wird entweder über das Spielmenü oder durch Eingabe von /setmaster 1 im Chat (Taste t) aufgerufen.
Sauerbraten-Server kennen im Wesentlichen zwei Arten von Autorisation: Mit Auth-Schlüssel und ohne.

Auth-Schlüssel. Durch den Hauptentwickler des Spiels werden sogenannte Auth-Schlüssel vergeben, mit denen vertrauenswürdige Spieler auf jedem Server mit Auth-Status Master werden können.
Öffentliche Server. Jeder kann dem Server beitreten. Diejenige, welche zuerst /setmaster 1 in den Chat eingibt, erhält den Master-Status.

Von diesen beiden Formen der Registrierung ist der Administrator des Server mit seinem Admin-Passwort jedoch nicht betroffen. Er kann jederzeit mit /setmaster und der anschließenden Eingabe des Admin-Passworts selbst dann zum Master werden, wenn diese Rechte schon an einen anderen Spieler vergeben worden sind.
Für mein Projekt habe ich mich für einen öffentlichen Sauerbraten-Server entschieden, auf dem jeder Master werden kann. Zusätzlich ist es möglich den Server so zu sperren, dass zwar weiterhin Spieler beitreten können, diese aber nur zuschauen und den Chat mitlesen dürfen. (L=Locked)

Installation und Konfiguration

aptitude install sauerbraten-server
Zur Inbetriebnahme des Servers ist es sinnvoll einen unprivilegierten Benutzer mit adduser anzulegen, z.B. sauerbraten. In dessen Home-Verzeichnis wird die zentrale Konfigurationsdatei server-init.cfg erstellt. Die verfügbaren Einstellungsmöglichkeiten sind überschaubar, was es einfach macht sich zurechtzufinden. Es ist sinnvoll die Shell des Benutzer auf /bin/false zu setzen.
chsh sauerbraten -s /bin/false
Das Programm lässt sich am besten in einer Screen-Sitzung starten. Hierzu erstellt man eine ausführbare Datei start.sh mit folgendem Inhalt.

#!/bin/sh
while true
do
/usr/games/sauerbraten-server -q/home/sauerbraten
echo "server abgestuerzt am `date`" > letzter_crash.txt
done

Den Server kann man danach auf diese Weise starten:
su sauerbraten -s /bin/dash -c "screen -m -d -S ffa_sauer sh start.sh"
Sollte es tatsächlich zu einem Absturz kommen, sorgt die While-Schleife automatisch für den Neustart und für einen kurzen Vermerk in der Datei "letzter_crash.txt". Sauerbraten läuft sehr stabil. Bei einer Uptime von > 30 Tagen kam es jedoch auch schon zum Crash. Die oben genannte Konfiguration sorgt dann dafür, dass der Server nur wenige Sekunden nicht erreichbar ist.
Schließlich lässt er sich auch über eine Cron-Reboot-Aktion bei einem Neustart hochfahren. In /etc/crontab steht deswegen
@reboot sauerbraten screen -d -m -S ffa_sauer sh /home/sauerbraten/start.sh
Der Port des Servers lässt sich ändern. Wer eine Firewall betreibt muss den Standardport 28785 und 28786 freigeben. Spielt man im LAN gilt das auch für Port 28784. Allgemein gesprochen: Gebt immer Port und Port+1 frei und im LAN zusätzlich noch 28784.

Modifikationen

Ich betreibe den Server, so wie ihn Debian und auch Ubuntu ausliefern, ohne jede Form von Modifikation. Es gibt verschiedene Projekte, die die Standardfunktionen erweitert haben, jedoch weiterhin kompatibel zum Original sind. Neue Merkmale sind unter anderem veränderte Statistikanzeigen im Spiel, neue Kontrollmöglichkeiten durch den Admin und Integration mit IRC. Maßgeblich sind das die Projekte XSBS und Hopmod. Ebenfalls erwähnenswert ist Bandnudel, ein Skript um Statistiken für den Server zu erstellen. Da ich diese Modifikationen nicht benutze, seid ihr hier auf euch allein gestellt.
Des Weiteren bietet der gesamte Webauftritt des Ogros-Clans einen guten Überblick, was man mit selbst erstellen Servermodifikationen erreichen kann. Leider werden diese im Gegensatz zum Cube-Server-Lister, der ebenfalls von dort stammt, nicht frei zur Verfügung gestellt.

Screenshots

Hier sind ein paar Screenshots. Viele weitere gibt es hier.

Tiger: Hilft bei Sicherheitsüberprüfung und Einbrucherkennung auf dem Server

Es sollte anspruchslos an die Ressourcen sein, nicht noch ein Daemon, der wertvollen Arbeitsspeicher in Besitz nimmt. Es sollte standardmäßig lautlos sein und nur Alarm geben, wenn es etwas Verdächtiges zu melden gibt und ganz klar, es musste ein nützliches Werkzeug sein, welches vor einer Vielzahl von Sicherheitsproblemen warnen konnte und regelmäßig das System auf Unregelmäßigkeiten überprüft.
So habe ich Tiger gefunden. Wie alle Programme in diesem Bereich ist auch Tiger nur ein Mosaikstein, um den Server etwas sicherer zu machen. Mich hat das modulare Design und die einfache Konfiguration überzeugt. Die meisten Module sind in purem Shell-Skript geschrieben und greifen ausschließlich auf UNIX-Werkzeuge zurück, um z.B. Datei- und Benutzerrechte zu überprüfen, unbenutzte Accounts anzuzeigen oder verdächtige Prozesse zu melden.
Des Weiteren existieren noch systemspezifische Programme, die im Fall von Debian die Md5-Summe von installierten Paketen überprüfen. Bei Veränderungen wird per Mail gewarnt. Neben Tiger werden noch John "the Ripper", chkrootkit und ab Wheezy auch Tripwire oder Aide als empfohlene Pakete installiert.
John versucht die Passwörter der Benutzer zu knacken und meldet schwache an den Admin oder direkt an den Benutzer. Chkrootkit testet auf typische Veränderungen, die von Rootkits verursacht werden und Tripwire bzw. Aide melden ebenfalls, ob wichtige Systemdateien verändert worden sind, nachdem zuvor in einer Datenbank der Ursprungszustand definiert worden ist.

Bedienung

aptitude install tiger

cronrc. Die Skripte und Module laufen zu festgelegten Zeiten und werden durch Cron gesteuert. Die Konfigurationsdatei hierfür ist /etc/tiger/cronrc. Ich habe hier lediglich die Ausführung des Moduls "check_system" auf 3.00 Uhr geändert, weil zu dieser Zeit die wenigsten Leute auf dem Server spielen, um dadurch beeinträchtigt werden zu können. Check_System ist CPU-intensiv und überprüft unter anderem mit deb_checkmd5sums die Integrität aller installierten Pakete.
tigerrc. In /etc/tiger/tigerrc lässt sich wiederum festlegen, welche Checks ausgeführt werden sollen und welche nicht, wenn man Tiger manuell mit dem Befehl tiger aufruft. Dazu setzt man hinter dem betreffenden Modul entweder ein Y für Ja oder ein N für Nein. Die Datei ist sehr gut dokumentiert und ziemlich selbsterklärend.
tiger.ignore. In /etc/tiger/tiger.ignore kann Output eingetragen werden, der durch Tiger ignoriert werden soll.

Am Anfang wird Tiger mehrere Mails mit Warnungen verschicken, danach nur noch, wenn sich etwas geändert hat. Jede Warnung enthält einen typischen Code, z.B. [cron005w]. Das mitgelieferte Programm tigexp liefert dann die Erkenntnis, um was für ein Problem es sich handelt.
tigexp cron005w
Bei Debian ist es Standard, dass jeder Benutzer einen Cronjob anlegen darf. Das Verhalten kann man unterbinden, indem die Datei /etc/cron.allow angelegt und root eingetragen wird, wodurch schließlich nur noch der Admin diese Aufgaben erstellen darf.
Es gibt einige Warnungen, die gar nicht bedrohlich sind. Tiger regt jedoch an darüber nachzudenken. Insgesamt finde ich, dass das gesamte Paket eine interessante und nützliche Ergänzung für den Spieleserver ist.

Juni 20, 2012September 27, 2019

Der Fünf-Cent-pro-Tag-vServer

Im Februar hatte ich mich für das Mieten eines vServers entschieden und im März festgehalten, was mich an einem solchen virtuellen Rechner für mein Spieleprojekt interessierte. Als ich ein paar Wochen zuvor auf der Debian-Devel-Mailingliste auf das Thema OpenVZ- und XEN-vServer gestoßen bin, wusste ich zwar, inwiefern sich die einzelnen Virtualisierungstechnologien unterscheiden, kannte aber das Wettbewerberfeld der VPS-Abieter kaum.
Inzwischen weiß ich mehr und bin zwischenzeitlich ebenso Kunde bei NbIserv geworden und miete dort den VS-Prepaid-Server.

Wenn man die Angebote scannt laufen einem die drei gängigsten freien Virtualisierungstechniken OpenVZ, XEN und KVM regelmäßig über den Weg. Des öfteren findet sich leider auch gar keine Angabe auf der Webseite des Anbieters oder sie ist zumindest gut versteckt.
Ich empfehle bei der Suche nach dem passenden vServer weder den obligatorischen Testseiten noch einem Bericht zu vertrauen. Das klingt übertrieben vorsichtig, aber meiner Meinung nach ist es bei kaum einem anderen Produkt einfacher sich selbst einen ersten Eindruck zu verschaffen. Anfragen zum Testen des vServers wurden bisher bei mir immer positiv beantwortet und selbstverständlich steht euch natürlich auch ein Widerrufsrecht zu, wenn der Server nach den ersten Tagen nicht gefallen sollte.
Einige interessante Ideen zu Testmethoden für vServer habe ich auf Virtualist.de gefunden, einer Seite, die sich ebenfalls vServer-Tests widmet. Zwar gilt auch hier das, was ich ein paar Zeilen zuvor geschrieben habe, ich verlinke sie trotzdem, weil ich bei zwei dort gelisteten Anbietern mittlerweile selbst zufriedener Kunde bin und die Seite ein guter Einstieg ist, wenn man erst einmal nur eine Liste mit Anbietern haben möchte. Den Rest überlasse ich eurer Bewertung.

NbIServ

Dort bin ich auf NbIServ gestoßen, ein Unternehmen aus dem Raum Gera in Thüringen. Der Anbieter wirbt mit einem sogenannten Prepaid-Server. Die Kosten belaufen sich auf 5 Cent pro Tag. Sollte das Guthaben 30 Tage lang unter 0,01 Euro liegen wird der Server gelöscht und der Vertrag beendet. Eine Mindestvertragslaufzeit gibt es nicht. Als Kennwerte liefert der Server 128MB RAM und 2 GB Speicherplatz. Bei den Werten kann man sich die Virtualisierungslösung denken, es ist natürlich OpenVZ. Besonders für dieses Preisniveau ist auch das Anlegen eines Snapshots für Backupzwecke, das problemlos vom FTP-Server heruntergeladen werden kann.
Die Bestellung ist unkompliziert. Typisches Onlineformular und danach den Vertrag plus Kopie des Personalausweises per E-Mail an den Anbieter schicken. Die Bereitstellung des Servers erfolgte innerhalb weniger Stunden.

Das Benutzerszenario

Ich wollte schon länger einen SSH bzw. OpenVPN-Server im Netz haben, zu dem ich mich aus unsicheren Netzen verbinden kann. Außerdem gefiel mir die Idee einem eigenen Mumble/Murmur-Server zur Verfügung zu haben, wofür NbIServ sogar ein spezielles Abbild anbietet. Da von den Ressourcen weiterhin Luft war konnte ich mir auch den schon erwähnten vsftpd-Server für OpenArena leisten. Von der Bandbreite stehen mindestens 100 Mbit laut Produktbeschreibung bereit und 1 TB Traffic sind inklusive. Den Traffic erreiche ich natürlich nicht einmal annähernd, die Bandbreite schwankt nach Tageszeit, war für mein Szenario bisher aber immer ausreichend.
Den Support habe ich bisher als vorbildlich und schnell erlebt. Die "langsamste" Reaktionszeit war drei Stunden. Das Ticket wurde mit Priorität "gering" um Mitternacht abgeschickt und um 3.00 Uhr beantwortet. 😉 Mir wurde ebenso prompt beim Aktivieren des TUN-Device für OpenVPN geholfen. Der einzige Makel, der mir bisher aufgefallen ist, war ein teilweise hoher Serverload zwischen 1-6 Uhr, wo ich die Vermutung hatte, dass die automatischen Backups der Mitkunden dafür verantwortlich waren. Der Support hat den vServer auf einen anderen Master umgezogen, seitdem läuft der Server vollkommen stabil.

oVZManager

NbIServ benutzt den oVZManager als webgestützte Administrationshilfe. Ich finde, er ist übersichtlich strukturiert und bietet alle wichtigen Optionen, die man als Kunde wirklich braucht. Server stoppen und starten, neue Images einspielen, Kontostand abfragen, Traffic überwachen und es gibt sogar die Möglichkeit einen Backupsnapshot anzulegen. Momentan findet ein Upgrade auf Version 2.0 statt.

Was mir in der 128-MB-OpenVZ-Klasse bisher aufgefallen ist

- Aptitude weigert sich manchmal eine Installation durchzuführen: FATAL -> Failed to fork.

Das Problem ist im Wiki von openvz.org gut erklärt und bedeutet nichts anderes, als dass dem Container bzw. der Applikation nicht genug Ressourcen, in meinem Fall privvmpages, zur Verfügung stehen. Am einfachsten umgeht man das Problem, indem man apt-get in diesem Fall zum Paketmanagement benutzt.

- Monit Fehlermeldung

'localhost' statistic error -- memory usage gathering failed
May 24 16:58:49 hostname monit[1077]: system statistic error -- cannot get real memory buffers amount

Ein bekannter Bug in Monit, der in Debian Wheezy gefixt worden ist. Ein Upgrade hilft. Außerdem habe ich extrem hohe CPU-Wait-Werte mit Monit gemessen, die so nicht stimmen können. Dem Bug bin ich aber bisher nicht weiter nachgegangen.

- Allgemeine Ressourcenknappheit und Einschränkungen

128 MB RAM ist natürlich nicht üppig. Man muss/sollte seine Ansprüche dementsprechend anpassen. Mit meinem Benutzerszenario komme ich jedoch auf ca. 600 MB belegten Festplattenspeicher und eine Auslastung von 44 MB RAM bei einem 64bit Debian. Zum Monitoring, für einen Voice-Server oder einen kleinen Webserver reicht das. OpenVZ virtualisiert auf Betriebssystemebene. Man teilt sich den Kernel mit allen anderen Gästen und man hat in der Regel als Kunde keinen Einfluss auf geladene Kernelmodule. Eine freundliche Anfrage beim Support hilft hier oft weiter.

Warum der lange Text?

Hey, das ist ein Blog. 🙂 Ich bin nun seit einem Monat Kunde bei NbIServ und werde mir das Angebot längerfristig anschauen. Wenn sich etwas dramatisch ändert, werde ich auch darüber schreiben. Die Quintessenz des Ganzen ist: Es gibt Angebote für kleine Aufgaben, die nicht unbedingt viel Geld kosten müssen und sie lassen sich spielend leicht testen. Im Prinzip ist es bei dem Produkt "vServer" egal, was man irgendwo liest, solange es möglich ist die "Ware" vorher zu prüfen. Ihr kauft hier kein neues Auto und selbst bei Mindestvertragszeiten von einigen Monaten kann man sich in der Preiskategorie auch einen "Fehlschlag" erlauben. Ich denke 5 Cent pro Tag ist fair.

Noch ein Kandidat

Einen weiteren Blick habe ich auf nhost und dessen Angebot "vServer S" geworfen. Ich halte mich kurz. Das Produkt ist ähnlich zu dem von NbIServ, mich überzeugte aber die Leistung nicht. Zwar steht z.B. 2 TB Traffic nominell zur Verfügung, aber schon beim Einloggen verhielt sich das System weniger reaktionsfreudig. Auch der Festplatten-Benchmark bonnie++ zeigte z.B. schlechtere Werte als bei NbIServ an. Außerdem gab es hier keine Backupmöglichkeit und die Vertragslaufzeit beträgt 12 Monate, obwohl mich das in dieser Preiskategorie nicht abschreckt.
Der Support war freundlich und antwortete schnell. Nhost ist scheinbar noch ein junges Unternehmen, deswegen würde ich auch hier einen eigenen Testserver anfordern und mir die Sache selbst anschauen. Die Bereitstellung über den Support war problemlos möglich.

Serverway und der Spieleserver

Nicht unerwähnt lassen möchte ich an dieser Stelle noch serverway.de, wo mein Spieleprojekt gehostet wird. Ich bin mit dem Anbieter bisher sehr zufrieden. Trotzdem ich das kleinste vServer-Angebot mit XEN benutze ist die Leistung für alle dort laufenden Spieleserver im grünen Bereich. Interessant ist auch, dass Serverway KVM-vServer anbietet, bei denen man Betriebssysteme wie FreeBSD und Linuxkernel beliebig installieren kann. Ich hoffe, die Leistung bleibt einfach so.

Juni 2, 2012September 27, 2019

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.

Mai 29, 2012Oktober 6, 2019

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.

Mai 29, 2012Oktober 6, 2019

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.

Mai 20, 2012Oktober 6, 2019

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.