Dienstag, 9. April 2013
[*]

MES01: Wir klicken uns einen Server

, 08:08

Dieser Artikel gehört zur Serie Mein eigener Server.

Hardware wählen

Aus naheliegenden Gründen brauchen wir für die weiteren Kapitel einen Server. Die gibt es bei ganz vielen Hostern und mit sehr unterschiedlichen Leistungsdaten zu sehr unterschiedlichen Preisen zu mieten. Ich gebe hier immer nur Beispiele, Ihr könnt das alles auch anders machen oder woanders Mieten, und das wird dann meistens auch nicht besser oder schlechter sein.

Für unseren Zweck mieten wir mal bei Hetzner einen Virtuellen Server „vServer VQ 12„. Der stellt einen ganz guten Kompromiss aus Kosten und Leistung dar. Der Virtuelle Server ist so etwas wie ein Anteil an einem größeren Server. Wir bekommen 1 GB RAM und 40 GB Plattenplatz zugeteilt, das sollte erstmal reichen.

Für ein großes Blog oder viel Mail oder eine große Menge Dateiablage müssten wir entsprechend höher zielen. Ich persönlich habe z.B. einen „dedizierten“ Server, der einiges mehr leistet und mir allein zur Verfügung steht — benutze den aber auch mit mehreren Leuten und noch einigen Projekten.

Darüberhinaus gibt es noch die sogenannten Managed Server, bei denen der Dienstleister einige der hier beschriebenen Tätigkeiten übernimmt. Das ist aber mit Einschränkungen bei der Softwareinstallation verbunden, und außerdem will er dann auch Geld dafür. Schließlich ist es auch noch möglich, nur Platz in einem Serverschrank zu mieten und dort eigene Hardware hineinzustellen. All das ist nichts für uns.

Software wählen

Als Betriebssystem bestellen wir Debian Linux — Minimal und ohne Plesk, ihr sollt ja schließlich lernen, was da im Hintergrund passiert.

Bestellformular

Nach der Bestellung dauert es einige Zeit (bei virtuellen Servern nur wenige Minuten bis Stunden), dann kommt eine Mail:

Der Server ist fertig.

Die erste Verbindung

Um jetzt irgendwas mit dem Server machen zu können, brauchen ein Terminalprogramm und einen ssh-Client. ssh ist ein Protokoll, mit dem verschlüsselt Tastatureingaben zum Server hin und die Textausgabe zum Client zurück übertragen werden (mehr dazu später). Das klingt erst einmal nach reinem Befehle tippen, aber schon seit der Zeit der Textterminals gibt es auch ausgeklügelte Benutzerinterfaces, die darauf basieren. Das werden wir später noch sehen.

Die Macuser unter Euch müssen nichts installieren, für die Windowsbenutzer empfehle ich PuTTY.

Log geht’s, wir verbinden uns jetzt zum ersten mal zu unserer nagelneuen Außenstelle: auf dem Mac öffnet das Programm „Terminal“ und gebt ein ssh root@[die Adresse aus der Mail], unter Windows öffnet PuTTY und verbindet Euch zu der Adresse aus der Mail:

PuTTY-Startfenster

Jeder der ssh-Clients wird beim ersten Kontakt zum neuen Server eine Sicherheitsfrage nach dem „RSA-Fingerabdruck“ stellen. Im Moment haben wir keinen Grund anzunehmen, dass es sich nicht um den richtigen Server handelt, drum sagen wir einfach ja. Es passiert jetzt etwa folgendes (keine Sorge wenn das Passwort beim Tippen nicht zu sehen ist, auch nicht als ******, das gehört so):

Mac:~ dentaku$ ssh root@78.47.144.44
The authenticity of host '78.47.144.44 (78.47.144.44)' can't be established.
RSA key fingerprint is 6e:8a:dc:13:63:6c:03:8e:5a:45:cb:3e:13:99:36:f6.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '78.47.144.44' (RSA) to the list of known hosts.
root@78.47.144.44's password:
Linux Debian-60-squeeze-64-minimal 2.6.32-5-amd64 #1 SMP Mon Feb 25 00:26:11 UTC 2013 x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root@Debian-60-squeeze-64-minimal ~ #

So, jetzt seid Ihr auf einem Unix-System. Herzlich Willkommen! Ändert erstmal das Passwort durch Eingeben des Befehls passwd (mit der Return-Taste abschicken und den Anweisungen folgen, es sind wieder keine ****** für das Passwort zu sehen, gewöhnt Euch dran).

root@Debian-60-squeeze-64-minimal ~ # passwd
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
root@Debian-60-squeeze-64-minimal ~ #

Im nächsten Kapitel folgt eine ausführliche Rundtour durch Unix bzw. Linux. Für heute verlassen wir den Server mit dem Befehl exit.

Mittwoch, 24. Juni 2009
[*]

ssh-Begrenzung – diesmal aber wirklich

, 15:27

Hier hatte ich schonmal versucht, mit iptables und dem recent-Modul, die lästigen ssh-Scanner vom tatsächlichen sshd fernzuhalten. Leider hat das nie wirklich toll geklappt (die „Angreifer“ wurden zwar ausgesperrt, es gelang aber nie, die Sperre automatisch aufzuheben).

Nach zwei bis drei erfolgreichen DoS-Attacken auf unser Firmennetz habe ich mir die Liste der iptables-Module nochmal genauer durchgesehen, ob da nicht was passendes dabei ist — und siehe da; das hashlimit-Modul kann eine Regel auf eine Höchstzahl von Treffern pro Zeiteinheit beschränken. Das liest sich dann so:

# 
# keep established connections open
# 
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
# 
# enable ssh:
# 
# throttle to 2 (3) connections per minute for outsourcing and internet
iptables -N ssh
iptables -A ssh -m hashlimit --hashlimit 2/minute --hashlimit-burst 3 \
         --hashlimit-mode srcip --hashlimit-name ssh --j ACCEPT
iptables -A ssh -j LOG --log-level info --log-prefix "SSH scan blocked: "
iptables -A ssh -j REJECT
iptables -A INPUT -p tcp --destination-port 22 --syn -j ssh
iptables -A FORWARD -p tcp --destination-port 22 --syn -j ssh

Das syn-Paket (also der Verbindungsaufbau) wird höchstens zweimal pro Minute durchgelassen, bestehende Verbindungen sind erlaubt. So funktioniert es.

Dienstag, 13. Mai 2008
[*]

Kein ssh für Dich, Du hattest schon genug

, 10:50

Ich benutze logcheck. Das warnt mich bei ungewöhnlichen Aktivitäten in den Logs der Server. Leider kommt es dabei häufig vor, daß man die eigentlichen Fehler garnicht finden kann, weil man sich durch endlose Wüsten von fehlgeschlagenen ssh-Logins blättern muß:

... failed password for invalid user ...

Das nervt. Haben die Scriptkiddies nichts besseres zu tun als Shellaccounts mit schlechten Paßwörtern zu suchen? Nach ein wenig herumsichen bin ich aber hier (wenn auch nicht im Artikel sondern in den Kommentaren) auf eine einfache Lösung gestoßen:

iptables -N ssh
iptables -A ssh -m state --state ESTABLISHED -j ACCEPT
iptables -A ssh -m recent --update --seconds 300 --hitcount 5 -j REJECT
iptables -A ssh -m recent --set -j ACCEPT
iptables -A INPUT -p tcp --destination-port 22 -j ssh
iptables -A FORWARD -p tcp --destination-port 22 -j ssh

Jetzt kann jeder Client pro 5 Minuten nur noch 5 ssh-Verbindungen öffnen, was in der Regel reichen sollte (man kann das ja auch noch etwas tunen…), danach wird die Verbindung verweigert. Test:

dentaku@charon:~$ ssh trenger@svn.advanced-solutions.de uname -a
Linux kampenwand 2.6.15 #1 SMP Thu Jun 8 18:38:40 CEST 2006 i686 GNU/Linux
dentaku@charon:~$ ssh trenger@svn.advanced-solutions.de uname -a
Linux kampenwand 2.6.15 #1 SMP Thu Jun 8 18:38:40 CEST 2006 i686 GNU/Linux
dentaku@charon:~$ ssh trenger@svn.advanced-solutions.de uname -a
Linux kampenwand 2.6.15 #1 SMP Thu Jun 8 18:38:40 CEST 2006 i686 GNU/Linux
dentaku@charon:~$ ssh trenger@svn.advanced-solutions.de uname -a
Linux kampenwand 2.6.15 #1 SMP Thu Jun 8 18:38:40 CEST 2006 i686 GNU/Linux
dentaku@charon:~$ ssh trenger@svn.advanced-solutions.de uname -a
Linux kampenwand 2.6.15 #1 SMP Thu Jun 8 18:38:40 CEST 2006 i686 GNU/Linux
dentaku@charon:~$ ssh trenger@svn.advanced-solutions.de uname -a
ssh: connect to host svn.advanced-solutions.de port 22: Connection refused
dentaku@charon:~$
Mittwoch, 5. März 2008
[*]

Subversion mit svn+ssh-Protokoll und Eclipse

, 13:45

Diese Anleitung muß ich für ein paar Kollegen im Moment sowieso schreiben, und vielleicht interessiert das ja noch irgendjemanden. Bevor ich also wieder so ein unkommunikatives Word-Dokument rumschicke:

1. Subclipse

Im Gegensatz zu CVS wird der Nachfolger Subversion von Eclipse (noch?) nicht direkt unterstützt — dabei hat Subversion viele Vorteile (z.B. atomare Transaktionen und Versionierung über Verschiebungen und Umbenennungen hinweg). Zuerst müssen wir das deshalb in Form eines Plugins nachrüsten: Subclipse gibt es bei tigris.org, und eine Installationsanleitung ist auch dort.

So, jetzt kann man in Eclipse die „SVN Repository Exploring perspective“ öffnen und dort die Adresse seines Repositories eintragen.

Add SVN Repository

Auf UNIXoiden Betriebssystemen wie Linux, Solaris und MacOS X kann man den folgenden Schritt überspringen. Dort ist ssh in der Regel installiert, im Pfad und kann als Tunnel gestartet werden ohne Fensterchen aufzumachen.

2. ssh-Tunnel aufbauen

Subversion unterstützt einen Haufen unterschiedlicher Protokolle. Neben dem direkten Dateizugriff auf das Repository und einem eigenen Protokoll für lokale Aufrufe unterstützt es WebDAV über http(s) durch ein Apache-Modul und kann über verschiedene Remote-Shell-Protokoll tunneln. Wenn man die Repositories (so wie wir) auf einem UNIX-Server lagert und keine Lust hat, sich mit dem svnDAV-Apache-Modul und seiner zweiten Benutzerverwaltung herumzuschlagen, dann ist das svn+ssh-Protokoll eine günstige Wahl. Leider kommt Windows ohne ssh-Client (im Repository Explorer sieht man unklare Fehlermeldungen wie „Das Verzeichnis ist nicht da.“), deshalb muß Abhilfe geschaffen werden. mehr…