Betreibt man einen Server, so wird man mit der Zeit feststellen, das man nicht der einzige ist, der gerne Zugriff auf den Server hätte. Um zu häufige Loginversuche abzublocken gibt es Fail2ban. Dieses Programmpaket durchsucht die entsprechenden Logs und blockiert böswillige Versuche in das System einzubrechen. Damit gehört Fail2ban zu den Intrusion Prevention Systemen. Die Installation auf einem Ubuntu-Server geht dabei leicht von der Hand:
apt-get install fail2ban
Anschließend kann mit der Konfiguration begonnen werden:
nano /etc/fail2ban/jail.conf
In den ersten Einstellungen unter „[DEFAULT]“ findet man die Zeit (in Sekunden) welche angibt wie lange ein Angreifer geblockt werden soll. Standardmäßig sind dies 10 Minuten respektive 600 Sekunden. Im Bereich „[JAILS]“ kann Fail2ban nun für bestimmte Dienste aktiviert werden, indem der Wert bei „enabled“ auf „true“ gesetzt wird. Selbstverständlich ist es auch möglich eigene Jails zu definieren. Alle vorgefertigten Filterregeln findet man unter „/etc/fail2ban/filter.d“. Die Überwachung des SSH Dienstes ist dabei standardmäßig aktiviert. Nach der Anpassung der Konfiguration, sollte der Dienst mittels
service fail2ban restart
neugestartet werden. Das Log in welchem alle Fail2ban Aktionen verzeichnet sind, ist unter „/var/log/fail2ban.log“ zu finden.
Vor einiger Zeit beschrieb ich wie man einen Mailserver unter Ubuntu mittels Postfix und Dovecot aufsetzt. Der dort installierte Server ist, in der Lage Mails zu senden und zu empfangen. Allerdings enthält er keinerlei Maßnahmen zum Schutz vor unerwünschten Mails. An dieser Stelle setzt Postgrey, eine Greylisting Implementierung für Postfix, an. Beim Greylisting werden Mails von einem unbekannten Sender erst einmal mit einem temporären Fehler beantwortet. RFC konforme Mailserver senden die Mail nach einer Verzögerung nochmal. Beim Spamversendern ist dies meist nicht der Fall, womit der Spam nicht im System auftaucht. Die Installation ist dabei relativ einfach:
apt-get install postgrey
Nach der Installation muss die „/etc/postfix/main.cf“ Datei angepasst werden. Der Zeile „smtpd_recipient_restrictions“ wird dabei der Wert „check_policy_service inet:127.0.0.1:10023“ hinzugefügt. Nachdem der Service mittels:
service postfix restart
neugestartet wurde, ist das Greylisting aktiv. In der Logdatei „/var/log/mail.log“ findet man, sobald man eine Mail von einem unbekanntem Sender bekommt folgende Zeile:
Oct 10 10:32:39 service postfix/smtpd[22287]: NOQUEUE: reject: RCPT from mail.example.org[178.19.71.5]: 450 4.2.0 <>: Recipient address rejected: Greylisted, see http://postgrey.schweikert.ch/help/example.com.html; from=<mail.example.org> to=<> proto=ESMTP helo=<mail.example.org>
Wenn die Mail erneut empfangen wird und die Greylistingzeit vorbei ist, wird Postgrey die Mail annehmen. Möchte man die Greylistingzeit ändern, so muss die Datei „/etc/default/postgrey“ bearbeitet werden. Für eine Verzögerung von 60 Sekunden könnte das ganze dann wie folgt aussehen:
POSTGREY_OPTS="--inet=127.0.0.1:10023 --delay=60"
Natürlich muss der Service für diese Änderung neugestartet werden.
Möchte man sich auf einem Linux-Server per SSH Schlüssel anmelden, so kopiert man im ersten Schritt seinen Schlüssel auf den entfernten Server:
ssh-copy-id -i ~/.ssh/id_rsa.pub
Anschließend kann man sich mittels:
ssh
ohne Passworteingabe auf den Rechner einloggen. Sollte dies nicht der Fall sein, gibt es ein Problem. So kann es passieren das man trotz SSH-Schlüssel ein Passwort eingeben soll. Um die Ursache zu diagnostizieren hilft es „ssh“ im Verbose-Modus zu benutzen:
ssh -v
Im diesem Modus werden viele Debuginformationen ausgegeben, welche helfen können das Problem einzugrenzen. Das man Passwörter trotz eines SSH Schlüssels eingeben muss, liegt manchmal an falsch konfigurierten Dateirechten im „.ssh“ Ordner auf dem entfernten Rechner. Die einfachste Möglichkeit ist es hier den Ordner komplett zu entfernen, damit er vom System nochmal angelegt wird. Dazu muss der Schlüssel natürlich mittels „ssh-copy-id“ wieder auf dem Rechner angebracht werden. Alternativ ist es auch möglich die Rechte für diesen Ordner neu zu setzen:
Wenn der Verbose-Modus nicht die gewünschten Ergebnisse bringt, so sollte sich die Logdatei /var/log/auth.log“ angeschaut werden. Dort kann man dann z.B. solche Meldungen bewundern:
Sep 21 01:47:35 service sshd[34221]: Authentication refused: bad ownership or modes for directory /home/seeseekey
In diesem Fall lag es nicht nur am „.ssh“ Verzeichnis, sondern auch an dem Homeverzeichnis des Nutzers. Ein:
chmod 700 /home/seeseekey/
wirkt in einem solchen Fall wahre Wunder. Danach sollte auch die Authentifikation per SSH-Schlüssel wieder funktionieren.
Wenn man sich einem unsicheren Netz bewegt, z.B. in einem freien WLAN empfielt es sich ein VPN zu nutzen. Dafür gibt es die unterschiedlichsten VPN-Dienste, welche dies gegen einen monatlichen Obolus anbieten. Besitzt man einen eigenen Server, so kann man sich mittels OpenVPN einen solchen Dienst selber aufsetzen. Im ersten Schritt wird OpenVPN installiert:
apt-get install openvpn
Aus den Beispieldateien wird das Skript „easy-rsa2“ zum Erstellen der Zertifikate an den entsprechenden Ort kopiert:
Damit ist die Certificaty Authority (CA) erstellt. Nun geht es an die Erstellung der Schlüssel für den Server:
sudo -E ./build-key-server server
Beim Common Name, gibt man die Domain ein unter welcher der VPN Server später erreichbar sein soll (z.B. vpn.example.org). Nach der Erstellung wird man im „keys“ Verzeichnis die Dateien „server.crt“, „server.csr“ und „server.key“ finden. Für den Diffie-Hellman Schlüsselaustausch müssen entsprechende Paramater erzeugt werden:
sudo -E ./build-dh
Nun fehlen nur noch die Zertifikate für die entsprechenden Nutzer. Ein Nutzer wird dabei mittels:
sudo -E ./build-key nutzerOderClientName
erstellt. Damit sind alle benötigten Zertifikate und Schlüssel erstellt, so das nun die restliche Konfiguration des Servers vorgenommen werden kann. Als Basis wird dabei die mitgelieferte Beispieldatei genutzt:
Neben F-Zero und dessen Ablegern, wird es schwierig weitere vernünftige Science Fiction Racer zu finden. Das Spiel Quantum Rush möchte dies ändern. Es handelt sich dabei um keinen reinen Racer wie bei F-Zero, sondern die Gleiter verfügen auch über Waffensysteme ähnlich Extreme G. Ein Einspielermodus ist leider nicht vorgesehen, allerdings soll man über das Netz mit anderen Spielen um die Wette fahren können.
Quantum Rush
Entwickelt wird das ganze vom Berliner GameArt Studio und soll zuerst als Windows Version erscheinen. Da Quantum Rush mittels Unity3D entwickelt wird, sind auch Versionen für Mac, Linux, XBox, PlayStation, Android und iOS geplant. Vielleicht springt auch noch eine Version für die OUYA heraus.
Das Projekt sucht dabei noch Unterstützer auf Kickstarter welche die Entwicklung finanzieren. Ziel sind dabei $100,000 und im Moment sind noch 18 Tage Zeit um die restlichen knapp $95.000 aufzutreiben.