So, now it’s 13:00 pm CET. The webserver for Xsyon are currently in maintenance to patch up for headstart. 11 hours to go and I’m very excited. I haven’t played the game a lot since I bought it (which was yesterday), because I don’t want to start stuff just before final wipe. Although, I’ve figured out how some crafting things work, so I can at least start playing it and don’t need to figure out UI when Prelude starts (that’s how the headstart’s called I guess).

Since I don’t want big pictures on my main page, just click read more to view them.

• By zaxtor99
  You can get part 2-4 in Related Videos, uploaded from same guy obviously.
• By Alex Taldren

It’s going to start on March 1st “officially”, but you can enter the “final” world from tomorrow (Friday 18.02.) when you preorder it now, which I just did. I already downloaded Beta Client and started trying things out. Obviously, I won’t play much for today, since they will wipe everything tomorrow evening, but it’s a chance to get in hang with UI and stuff.

Unfortunately they’ve got some Server issues at the moment. As I just got the game, I don’t know if it’s usual, but for today, server just crashed like 5 times between 1:00-3:00 AM CET. Hopefully, release will be different.

I’ll post more stuff about this game after some days trying out features..

Currently, some very very old versions are for free, though, you need to buy the game to get access to newer versions – 9,95€ for the moment, but price will raise as soon beta starts.

Here are some videos which convinced me to buy:
http://www.youtube.com/watch?v=4ev8UW1qa1Q&feature=search
http://www.youtube.com/watch?v=oB6KADe7_WM&feature=related
http://www.youtube.com/watch?v=bs-3f0HqxG4&feature=related
http://www.youtube.com/watch?v=wFg67iiw4UE&feature=related

More Informations:
-> http://minecraft.net/ – Official website
-> http://www.minecraftforum.net/ – Official forums
-> #minecraft at irc.esper.net

Here are some screenshots of the fortress I’m currently building:

When I’m connecting from Germany to my Linode in New Jersey, it’s actually faster than connecting to my old server in Frankfurt, Germany . Especially in european primetime.

Yesterday, my page had some problems, because I forgot to acticate mod_rewrite *shame*. Now, everything should work correctly again.

Maybe I’ll test it a few times until it runs out. If I’ve got enough time to check it out, I might write a small review about it.

Use this link, to view only english articles:
http://mkasu.org/blog/category/english/

http://www.huschi.net/archiv/webmin-absichern.html

Besonders den Punkt wo es um SSL Tunneling geht.

vServer Security Guide

Da es hier keinen vernünftigen Artikel zur Absicherung eines Servers bzw. Serversicherheit im Allgemeinen gibt, dachte ich, das könnte ich mal kurz ändern.

1. Vorwort/Disclaimer

Immer wieder hört man Geschichten von übernommenen Rootservern, vServern und den entsprechenden Folgen. Falsche Absicherung kann eine Menge Traffic verursachen (beispielsweise durch Spambots, die deinen falsch abgesicherten Server als Mailserver zum verschicken ihres Spams nutzen) oder auch Klagen den Briefkasten bringen (durch illegale Daten, die von Hackern auf fremde Server hochgeladen werden zur Verbreitung).

Um einigen Linux Administratoren einen Denkanstoß oder eine Hilfe (für Neulinge in dem Bereich) zu geben, schreibe ich diesen Guide. Vorsicht: Er erhebt keinen Anspruch auf Vollständigkeit. Auch ich bin eher der Hobby-Linuxadministrator und es gibt wohl eine Menge Administratoren mit mehr Erfahrungen.

Bitte bedenkt: Um Sicherheit sollte man sich kümmern, **bevor** etwas passiert.

Mein Guide basiert aus der Sicht einer Ubuntu 10.04 Neuinstallation, lässt sich aber im Grunde auch auf jedes andere System übertragen.

2. Passwörter

Obwohl du im späteren Verlauf lernst, wie man sich mit einer Schlüsseldatei mit SSH verbinden kann, ist eine richtige Passwortwahl trotzdem das A&O bei einer wirkungsvollen Serversicherheit.

Einfach um ein paar Tipps zu geben:

• Verwende keine Namen, Wörter oder Geburtsdaten, das ist bei deinem Kreditkarten PIN genauso schlecht wie bei deinem Server. Grund: Bruteforce (d.h. Durchprobieren)-Attacken verwenden meist beim ersten Durchlauf Wörterbuchabfragen, wodurch man beim Passwort “baum” relativ schnell gehackt werden dürfte.
• Möglichst 10-12 Stellen lange Passwörter
• Wenn möglich, 1-2 Zahlen und 1-2 Sonderzeichen.
• Ein guter Anhaltspunkt ist das Programm pwgen. Ich empfehle “pwgen -y 10″. Allerdings muss man sich solche generierten Passwörter auch merken, Passwörter NIEMALS aufschreiben.
• Als sicher und gut zu merken gelten so genannte Passphrases, bei der man sich einen ganzen Satz ausdenkt und nur feste Fragmente davon hernimmt. z.B: (Mal in einem Video auf der Cebit gesehen) “Die Gabi hat Brust-Größe 75c” -> “DGhBG75c” .

3. SSH

SSH ist der erste Schnittpunkt, mit dem man in Berührung kommt, wenn man sich mit dem Server verbindet. Dementsprechend ist es der erste Anhaltspunkt wo Sicherheit wichtig ist.

Eine kleinere Sache, die das Hintergrundrauschen in den Logfiles verhindert, ist Security by Obscurity, also der ändern des Ports. Standardmäßig ist SSH auf Port 22 und daher spammen viele Bruteforce Scripts IPs mit Port 22 durch. Um dies zu verhindern, kannst du den Port deines SSH Servers umlegen. Öffne dazu /etc/ssh/sshd_config und ändere den Port auf beispielsweise 2022.
Im gleichen Zusammenhang kann man kurz schauen, ob der Server für das neuste Protokoll ausgelegt ist oder noch aufs ältere eingestellt ist und dies beheben.

Port 22
ändern zu:
Port 2022
 
Protocol 1
ändern zu:
Protocol 2

3.1 Kein Root

Um es seinem Hacker nicht unglaublich einfach zu machen, werden wir aufhören auf einem Root Account zu arbeiten. Dafür erstellen wir mit

adduser name
oder:
useradd -m name
passwd name

einen neuen Benutzer. Dies wird der Benutzer sein, mit dem wir uns in Zukunft einloggen. Um mit dem trotzdem als Administrator arbeiten zu können, installiert man nun das Paket sudo, falls eh nicht schon im System installiert ist.

apt-get install sudo

nun braucht man den User nur mehr zur Gruppe sudo hinzufügen.

adduser name sudo

Achte darauf “name” durch den Namen deines Benutzers zu ersetzen. Mit “sudo” kann man als normaler Nutzer Befehle mit root-Rechten ausführen. Dafür muss man dem Befehl ein “sudo” voranstellen. Danach muss man sein **eigenes** Passwort eintragen (nicht das des Root-Benutzers). Auch kannst du unterschiedlichen Leuten root Zugriff geben, ohne das diejenigen das Root-Passwort benötigen.
Ein weiterer Vorteil von sudo: sudo protokolliert automatisch alle benutzten Befehle unter /var/log/auth.log. Wenn also was seltsames auf deinem vServer passiert, lohnt sich ein Blick in die auth.log um eventuelle Fremdzugriffe zu identifizieren.

Wenn du dich nun per SSH unter deinem neu erstellten Benutzer einloggen kannst und per sudo Befehle mit Rootrechten (z.B. ”sudo ifconfig”) ausführen kannst, kannst du nun die Einstellungen deines SSH Servers verändern, dass er kein root-Login mehr erlaubt (wenn du dies machst ohne zu testen ob dein neuer Benutzer funktioniert, kannst du dich leicht aussperren und musst mit Rescue Konsole arbeiten, also pass auf).

Editiere dazu die Datei /etc/ssh/sshd_config wie folgt:

PermitRootLogin yes
ändern in:
PermitRootLogin no
 
wenn du dabei bist, ändere auch:
PermitEmptyPasswords yes
in:
PermitEmptyPasswords no
leere Passwörter widerstreben jeden Sinn von Systemsicherheit.

(und anschliessendes /etc/init.d/ssh restart)

3.2 Authentifikation mit Public / Private Key

Der Auth mit einem Pub/Priv Key erhöht die Sicherheit ungemein. Nach richtiger Konfiguration kann man sich nicht mehr mit einem einfachen Passwort in den Server einloggen sondern benötigt einen aufwendig verschlüsselten Schlüssel der Gegenstück zu einem zweiten Schlüssel auf dem Server ist (kann man mir bis hier hin folgen?). Dieser Schlüssel, den man braucht, um eine SSH Verbindung herzustellen, ist dir, und nur dir, verfügbar, in Form einer Datei. Ohne diese Datei ist Zugriff auf den Server nicht möglich (von Rescue Konsole mal abgesehen). Durch diese Methode der Authentifikation wird der Server abgesichert gegen Bruteforce-Attacken (d.h. man kann das Passwort nicht mehr “durchprobieren”).

Ändere deine /etc/ssh/sshd_config wie folgt:

PubkeyAuthentication no
in:
PubkeyAuthentication yes

(und anschliessendes /etc/init.d/ssh restart)

Benutze nun den Befehl “ssh-keygen -t dsa”. Wahlweise auf deinem privaten Linuxsystem oder auf dem Server (spielt im Grunde keine Rolle).  Die Passphrase, die du eingeben musst, ist ein neues Passwort, was deinen private Key verschlüsselt. Nimm etwas woran du dich gut erinnern kannst, du musst es bei öfters mal eingeben.

Du erhälst anschliessend zwei Dateien. ~/.ssh/id_dsa und ~/.ssh/id_dsa.pub. Die Datei mit .pub ist dein Public Key. Dieser Schlüssel muss auf dem Server verbleiben.
Kopiere die Datei id_dsa.pub nach ~/.ssh/authorized_keys. Wenn du mehrere Benutzer hast, kannst du im Grunde für alle den gleichen Public Key benutzen: kopiere dafür jeweils die id_dsa.pub in den Ordner ~/.ssh/authorized_keys der Benutzer (Die Tilde ~ ist das unter Unix übliche Zeichen für das Home Verzeichnis der Benutzer).

Der Private Key, auf dem Computer wo ssh-keygen ausgeführt wurde unter ~/.ssh/id_dsa zu finden, ist Gegenstück zu deinem Public Key. Dieser Key wird benutzt, um dich auf deinem Server einzuloggen. Sichere den Key irgendwo ab, sorge dafür das niemand ausser dir Zugriff drauf hat.

Um dich nun auf den Server einzuloggen, musst du nur deinen SSH Client darauf einstellen, den Private Key zu benutzen. Unter Putty macht man dies beispielsweise unter Connection -> SSH -> Auth -> “Private Key file for authentification:”. Beim SSH Client unter Linux oder OSX muss die Datei unter ~/.ssh/id_dsa liegen, wie sie ssh-keygen beim
Ausführen auch platziert. Dies musst du auf allen Computern machen, wo du dich mit dem Server verbinden willst!

Versuche nun dich mit dem Server zu verbinden. Wenn eine Passwortabfrage kommt, versuche es mit deinem bei der Ausführung des Befehls ssh-keygen festgelegtem Passphrase. Wenn die Verbindung mit dem Server über die Authentifikation mit dem Private Key funktioniert (achte darauf, dass dein SSH Client explizit erwähnt, den Private Key zu benutzen), kannst du SSHd so konfigurieren,
dass er Passwort-Authentification nicht mehr annimmt und fortan nur noch private Keys benutzt (ansonsten wäre die ganze Arbeit ja für die Katz gewesen, wenn man trotzdem noch Bruteforcen könnte ).

Ändere dazu in der sshd_config einfach folgende Variable

PasswordAuthentication yes
in:
PasswordAuthentication no

4. LAMP Umgebung

Da eine LAMP Umgebung wohl einer der häufigsten Zwecke eines vServers ist, hier einige Tipps die man beim Einrichten einer LAMP Umgebung beachten sollte.

4.1 PHP

PHP gibt in Standardeinstellung Daten von sich Preis, die eventuell Hacker benutzen können, um Sicherheitslücken ausfindig zu machen.
Editiere deine php.ini, unter Ubuntu zu finden unter /etc/php5/apache2/php.ini wie folgt:

disable_functions = exec,system,shell_exec,passthru
register_globals = Off
expose_php = Off
magic_quotes_gpc = On

4.2 MySQL

Du solltest umbedingt den Zugriff auf deine MySQL Datenbank von aussen sperren. Meisten benutzt man die MySQL Datenbank so oder so nur “von innen”, sprich von einem PHP Skript heraus “localhost” aufgerufen. Für solch einen Verwendungszweck muss der Server nicht von aussen an ansprechbar sein, es ist sogar ein erhöhtes Sicherheitsrisiko wenn er es wäre.

Um dies zu tun, öffne /etc/mysql/my.cnf und füge folgende Zeile hinzu:

bind-address = 127.0.0.1

Benutze gute Passwörter (siehe Kategorie “Passwörter”) für deinen MySQL Root Account. Wenn möglich, erstelle für verschiedene Webseiten die du laufen hast unterschiedliche MySQL Benutzer mit anderen Passwörtern.

5. Tipps

Ein paar Abschluss Tipps, um dir noch ein paar Sachen auf den Weg zu geben:

• Möglichst wenige Dienste auf einmal laufen lassen. Jeder zusätzliche Dienst kann eine zusätzliche Sicherheitslücke an den Tag legen. In dem Sinne solltest du auch so wenig Software wie möglich installiert haben.
• Führe regelmäßig (am besten Täglich) Sicherheitsupdates durch. Falls dir das nicht möglich ist, versuche RSS Feeds zur Sicherheit deiner Distribution (jede größere Distribution hat Sicherheitsmailinglists auf der Sicherheitsupdates angekündigt werden) zu abonnieren und so auf dem laufenden zu bleiben.
• Führe unterschiedliche Dienste als unterschiedliche User aus. Die Distributionen machen dies automatisch, bei Paketen die über die Paketverwaltung installiert wurden. Wenn du allerdings selbstständig Dinge installierst, beispielsweise ein Gameserver, füge einen neuen Benutzer (z.b. “gameserver”) hinzu und lasse den Prozess über diesen Benutzer laufen. So verhinderst du Root-Zugriff für den Fall das der Gameserver eine Sicherheitslücke aufweist.
• Ich rate allgemein von FTP Servern ab und rate dazu, Dateizugriff über SFTP zu machen. SFTP läuft auf dem SSH Protokoll und ist mit einem SFTP Clienten erreichbar wenn SSHd auf dem Server läuft. FTP öffnet nur einen weiteren sicherheitsanfälligen Dienst.
• Postfix oder allgemein Mailserver Sicherheit ist noch eine ganz andere Geschichte. Wenn du so etwas vor hast, informier dich bitte selbst über Sicherheit. Ich hab leider von dem Thema Mailserver zu wenig Ahnung, um den Guide entsprechend zu erweitern. Mailserversicherheit steht im Mittelpunkt wenn es um Spambots geht. Falsch eingerichtete Mailserver werden schnell zur Kostenfalle wegen übermäßig genutzten Traffics.
  Tipp: Überlege, ob Google Apps für dich nicht eine Alternative darstellt.
• Teste mit “netstat -tulpen” welche Ports offen sind auf deinem Server. Überlege, ob jeder Dienst sein muss, oder ob du nicht benötigte Dienste herunterfahren kannst.

6. Schlusswort

So, das ist alles was mir gerade dazu einfällt. Ich werden den Guide bei Zeiten noch erweitern. Änderungsvorschläge oder Kommentare bitte an marc@mkasu.org. Falls sich jemand zu Mailserversicherheit auskennt (oder was anderem), darf er gerne selbst hand anlegen und den Guide erweitern.

Weltweit protestieren Piratenparteien am AdACTADay gegen das geheim ausgehandelte Handelsabkommen “Anti-Counterfeiting Trade Agreement” (ACTA). Die neunte Verhandlungsrunde findet vom 28. Juni bis 2. Juli in Luzern, Schweiz, statt. Diesen Termin nehmen die internationalen Piratenparteien zum Anlaß, weltweit gegen das Abkommen zu protestieren.

Die Piratenpartei Deutschland fordert die Offenlegung der Verhandlungsunterlagen sowie eine kritische Überprüfung des bisherigen Vertragsentwurfs. Dieser hatte zahlreiche Bedenken aufgeworfen, vor allem in Bezug auf eine freiheitliche Nutzung des Internets. Die Piratenpartei fordert außerdem, die üblichen parlamentarischen Kontrollstrukturen einzubinden, die die Verhandlungspartner bis dato gezielt umgangen hatten.

Mit der weltweiten Protestaktion, unter anderem in Australien, Österreich, Deutschland, Mexiko und der Schweiz, wollen die Piratenparteien über das im Geheimen verhandelte Abkommen informieren. Die Regierungen der verhandelnden Staaten müssen in die Verantwortung genommen werden, sich gegen das Vertragswerk in seiner derzeitigen Form zu stellen.

Zusätzlich zur zentralen Veranstaltung am 28. Juni in Luzern finden in vielen Städten begleitende Aktionen statt, unter anderem in Berlin, Düsseldorf, Wien und München. Weitere Informationen zu einzelnen Terminen in Ihrer Nähe sind hier zu finden:

http://blog.koordination-international.de/2010/06/24/gemeinsam-gegen-acta/

http://wiki.piratenpartei.de/AdActaDay#Ideen-Sammlung

Zitat http://www.stopp-acta.info/deutsch/acta-blog/acta-international/internationaler+adactaday.html

Ihr wisst nicht was ACTA ist?

Informiert euch jetzt im Piratenwiki und tut etwas, bevor es zu spät ist.

http://mo.mkasu.org