Archiv für den Monat: August 2010

So war die FrOSCon 2010

Hinterlasse eine Antwort

FrOSCon 2010 Eingang

Einmal im Jahr zieht es alle Technik und Open Source Begeisterte nach St. Augustin zur Free & Open Source Conference. Dieses Jahr hatte sich zudem großer Besuch angekündigt. Kein geringerer als Jon “Maddog” Hall, besuchte die FrOSCon und hielt unter vollem Hörsaal eine Keynote zum Thema “Free and Open Source Software in the Developing World”. Aber auch die anderen Vorträge waren wie immer von bester Qualität und deckten so ziemlich jeden Aspekt der Softwarewelt ab. Sei es Entwicklung, Administration und normales Benutzen von Software.

Folgend ein kleines Tagebuch der FrOSCon aus meiner Sicht:

09:53

Die Bahn kommt. Genau gesagt geht es erstmal von Neuss nach Köln. In Köln Hansaring steigen wir um in die S12 nach St. Augustin. Dann noch ne Runde Straßenbahn und schon folgten wir den weißen Fröschen zur Froscon.

 

12:15

Nach dem obligatorischen Abholen der Tasche mit Werbegeschenken und dem stylischen Froscon T-Shirt ging es mehr oder weniger auch direkt in den Hörsaal 1 um die Keynote von Jon “maddog” Hall zu verfolgen. Im großen und ganzen sehr Interessant sein Vortrag auch wenn manches was er sich an OpenSource Projekten vorstellt doch recht unrealistisch erscheint, da der Markt für so etwas einfach nicht bereit ist.

14:00

Der KDE und amaroK Stand

Nach und nach arbeitet man sich durch die verschiedenen Stände durch und kommt auch ins Gespräch. Interessant fand ich die kommenden Version von amaroK, die in der nächsten oder übernächsten Release eine Virtualisierung enthalten wird. Und die sieht noch nicht mal schlecht aus und kann mit iTunes oder Windows Media Player Pendanten ohne Probleme mithalten.

 

15:15

In einer Vorlesung über Cloudcomputing konnte ich mich über die Risiken dessen informieren. Hier wurde einem vor Augen geführt welch ein Risiko überhaupt im Cloudcomputing steckt. Gerade das Risiko das man seine Daten oder Applikationen nicht selber verwalten kann, birgt eine großes Risiko. Man ist bei externen Anbietern immer davon abhängig, das dieser seinen Service auch nicht einstellt bzw. APIs auf einmal ändert etc.

18:00

Gegen 18 Uhr ging es dann zum “Social Event” um bei super Wetter und Musik eine leckere Grillwurst und Salat zu essen. Geschmacklich und preislich mal wieder top.

20:00

Langsam ging es dann wieder auf den Rückweg. Nach knapp zwei Stunden fahrt war man dann auch wieder Zuhause und froh im Bett zu sein.

Samstag

openSUSE auf der FrOSCon

Am Samstag war ich natürlich auch dort, diesmal aber ehr um mir die Vorlesungen anzuschauen. Dort war ich aber nicht der einzige. Die Gänge waren wesentlich leerer, die Hörsäle dafür voller. Nachdem ich mir einen Vortrag über WINE angehört habe, ging es zu einem wirklich interessanten Vortrag über ZFS, der leider schon nach einer Stunde abgebrochen werden musste, da die Zeit nicht mehr reichte. Der letzte Vortrag den ich mir anschaute war über Gnome 3. Da ich auch den Vortrag vom letzten Jahr kannte war ich hier gespannt auf die Änderung die seitdem eingetreten sind. Im Grunde hat man nicht wesentlich viel neues gesehen. Gnome 3 ist stabiler geworden, man hat an der Gnomeshell viel stabiler gemacht und optisch verbessert. Das neue Bedienkonzept ist etwas ungewöhnlich und man muss sich darauf einlassen um es zu verstehen. Im großen und ganzen nimmt Gnome 3 langsam fahrt auf. Persönlich glaube ich das Gnome versucht die Fehler von KDE nicht zu wiederholen sich dabei aber in zu vielen Kleinigkeiten verläuft.

Alles in allen mal wieder eine schöne Konferenz. Die nächste große Open Source Veranstaltung währe die Open Rhein Ruhr in Bochum im November.

Man sieht sich dort.

ssh Brute Force Angriffe verhindern

1 Antwort

Jeder, der seinen Server per ssh im Internet erreichbar macht, kennt das Problem das Bots immer wieder versuchen mit massenhaften Anfragen Zugriff auf den Server zu bekommen. Um direkt zu verhindern, dass es zu mehreren Anfragen kommen kann, können Sie mehrere Einstellungen vornehmen.

SSH Konfiguration absichern

Bei den meisten Anfragen wird versucht sich als root einzuloggen. Hier ist es dringend empfohlen, keinen root-Zugang per ssh zuzulassen. Sie können sich später als normaler Benutzer per su auch zum root machen. Dies ist weitaus sicherer, da so zwei Passwörter benötigt werden und als normaler User weniger zerstört werden kann, sollte sich jemand Zugang verschaffen. Zudem muss der Angreifer erstmal Ihren Benutzernamen herausfinden. Die meisten Anfragen kommen nicht nur als root sondern auch als typische Dienstenamen wie tomcat, apache etc. Die Einstellungen nehmen Sie in der Datei  /etc/ssh/sshd_config vor. Suchen Sie folgende Einträge und ändern Sie diese wie folgt ab:

PermitRootLogin no

und

AllowUsers detlev

(bzw. die Benutzer die sich einloggen dürfen)

Damit nicht unendlich viele ssh-Sessions auf einmal gestartet werden können nehmen Sie noch folgende Option vor:

MaxStartups 3:30:10

Sie bewirkt, ab den dritten nicht funktionierenden login, dass bei jedem weiteren nicht funktionierenden login die Wahrscheinlichkeit steigt, das die nächste Verbindung abgelehnt wird. Dies ist kein 100%iger Schutz und im Endeffekt auch nicht notwendig wenn wir mit der Absicherung fertig sind.

Sollte eine Option mit einer Raute # ausgeklammert sein, entfernen Sie die Raute einfach.

Nachdem Sie die Einstellugen vorgenommen haben starten Sie ssh neu.

IP Adressen blocken

Um die Attacken zu stoppen, ist es sinnvoll nach einer bestimmen Anzahl von Fehlversuchen die IP des Angreifers für eine bestimmte Zeit zu blocken. Wir sagen mal einfach 10 Minuten sollten reichen. Dabei würde auf der Angreiferseite die Zugriffsversuche einfach in ein timeout laufen. Um dies zu bewerkstelligen benötigen wir das Programm fail2ban. Bei openSUSE installieren Sie es einfach per
sudo zypper install fail2ban
Danach müssen Sie fail2ban noch bei jedem Systemstart mitstarten. Unter yast > System > Systemdienste (Runlevel) können Sie dies einstellen. Bei Runlevel 3 und 5 soll es mitgestartet werden.

Nun starten wir fail2ban als root mittels rcfail2ban start.

Trotzdem müssen wir noch ein paar openSUSE spezifische Änderungen an der Konfiguration durchführen. Die zu editierende Datei lautet /etc/fail2ban/jail.conf.

Die Einstellungen sind eigentlich selbstklärend. Trotzdem poste ich mal die Einstellungen so wie sie für unseren Fall aussehen sollten:

# Fail2Ban configuration file
#
# Author: Cyril Jaquier
#
# $Revision: 747 $
#
# The DEFAULT allows a global definition of the options. They can be override
# in each jail afterwards.
 
[DEFAULT]
 
# "ignoreip" can be an IP address, a CIDR mask or a DNS host. Fail2ban will not
# ban a host which matches an address in this list. Several addresses can be
# defined using space separator.
ignoreip = 127.0.0.1
 
# "bantime" is the number of seconds that a host is banned.
bantime = 600
 
# A host is banned if it has generated "maxretry" during the last "findtime"
# seconds.
findtime = 600
 
# "maxretry" is the number of failures before a host get banned.
 maxretry = 3
 
# "backend" specifies the backend used to get files modification. Available
# options are "gamin", "polling" and "auto". This option can be overridden in
# each jail too (use "gamin" for a jail and "polling" for another).
#
# gamin: requires Gamin (a file alteration monitor) to be installed. If Gamin
# is not installed, Fail2ban will use polling.
# polling: uses a polling algorithm which does not require external libraries.
# auto: will choose Gamin if available and polling otherwise.
backend = auto
 
# This jail corresponds to the standard configuration in Fail2ban 0.6.
# The mail-whois action send a notification e-mail with a whois request
# in the body.
 
[ssh-iptables]
 
enabled = true
filter = sshd
action = iptables[name=SSH, port=ssh, protocol=tcp]
sendmail-whois[name=SSH, dest=detlev@localhost, sender=fail2ban@mail.com]
 logpath = /var/log/messages  maxretry = 3

Nachdem Sie die Einstellungen vorgenommen haben starten Sie fail2ban mittel<

rcfail2ban restart

neu. Nun ist es aktiv und wird nach 3 Fehlversuchen die IP des Angreifers für 10 Minuten blocken.

Interessante Links zu dem Thema

SSH-Daemon (sshd) gegen Attacken sichern > http://www.strassenprogrammierer.de/ssh-daemon-sshd-gegen-attacken-sichern_tipp_363.html
Verhindern von Brute Force Attacken mit Fail2ban auf OpenSUSE 10.3 > http://www.howtoforge.de/howto/verhindern-von-brute-force-attacken-mit-fail2ban-auf-opensuse-103/

Regelmäßiges Backup einer Festplatte mit rsync

2 Antworten

Wie schon in meinem vorherigen Blogpost geschrieben befindet sich in meinem Server zwei 160 GB Festplatten. Hier liegt die Idee nahe eine Festplatte als Sicherungsmedium zu verwenden, dass regelmäßig die andere Festplatte spiegelt.

Leider besitzt mein Mainboard keinen RAID-Controller, so dass ich auf rsync ausweichen muss. rsync kann eine Quelle und ein Ziel synchron halten, allerdings nur in eine Richtung. Wird im Ziel etwas geändert, gelöscht oder angelegt kann dies nicht auf die Quelle zurückgeführt werden. Dies ist in diesem Falle auch nicht wichtig, da an dem Backup eh keine Änderungen vorgenommen werden. Die Backups werden mittels cron automatisiert, so das man sich darum keine Gedanken mehr machen muss und es nicht vergessen kann.

Lassen Sie sich nicht von der länge dieses Artikels abschrecken. Ich habe Ihn nur sehr ausführlich geschrieben damit man die Schritte klar nachvollziehen kann.

Schritt 1: Festplatte vorbereiten

Da wir wie schon erwähnt die zweite Festplatte komplett für die Datensicherung nutzen werden, müssen wir sie dementsprechend einrichten. Dazu habe ich sie mit einem ext4 Dateisystem formatiert und standardmäßig in /backup eingehangen. Dies können Sie ganz einfach mit YaST erledigen. In /backup wird das System später gespiegelt.

Schritt 2: rsync Befehl bauen

Damit rsync später weiß, was es kopieren soll braucht es eine etwas längeren Befehlssatz:

rsync -auv --log-file=/var/log/rsync_backup --delete --exclude=/sys --exclude=/tmp --exclude=/proc --exclude=/mnt --exclude=/dev --exclude=/backup / /backup

Diesen werden wir nun auseinander nehmen, damit sie wissen was genau passiert.

  • rsync der Befehl an sich
  • -auv Hier muss man noch einmal etwas tiefer gehen. Das -a steht eigentlich für mehrere Optionen die in einem zusammengefasst sind. -a umfasst die Optionen r, l, p, t, g und D. Dass heißt, dass rsync alle Unterverzeichnisse mit verabreitet (r), symbolische Links mitkopiert (l), die Rechte der Dateien und Order beibehält (p), die Zeitstempel beibehält (t), die Gruppenrechte beibehält (g) und die Gerätedateien (D). Das -u steht für Update und sorgt dafür das nur neuere Dateien kopiert werden. Das -v steht für verbose und gibt Details auf der Konsole aus was gerade passiert.
  • –log-file=/var/log/rsync_backup Da wir ja einen Server betreiben und das Backup automatisch abläuft können wir leider nicht sehen ob es erfolgreich ist oder ob es Fehlermeldungen gab. Deswegen weisen wir rsync mit diesem Befehl an, einen Log in die Datei /var/log/rsync_backup zu schreiben. Der Pfad und der Name ist frei wählbar. Ist die Datei noch nicht vorhanden wird Sie automatisch angelegt.
  • –delete sorgt dafür das Dateien die auf der Quelle gelöscht wurden auch auf dem Ziel gelöscht werden. Ansonsten würde das Backup mit der Zeit immer voller werden, da Dateien in der Quelle wieder gelöscht werden aber auf dem Ziel verbleiben würden.
  • –exclude=/backup etc. Die exclude Optionen sagen rsync welche Ordner ausgelassen werden sollen. Das der Ordner /backup ausgelassen werden muss ist logisch, das rsync ansonsten nur im Kreis laufen würde. Die Ordner /tmp,  /sys , /proc und /dev sind für ein Update ohne Bedeutung, da diese Dateien vom Betriebssystem dynamisch bei jedem Start von selbst erstellt werden, bzw. bei /tmp es sich um temporäre Dateien handelt. Der Ordner  /mnt muss ausbleiben weil darin externe Medien wie DVDs etc. eingebunden werden die rsync dann auch kopieren würde. Beim nächsten Durchlauf würde diese Dateien wegen der –delete Option zwar wieder gelöscht werden, allerdings ist es ein Zeitaufwand der nicht sein muss.
  • / Das Quellverzeichnis
  • /backup Das Zielverzeichnis.

Nun testen Sie Ihren Befehl nach gründlichen durchschauen durch und lassen Sie das erste Backup durchlaufen. Der Befehl muss als root ausgeführt werden, damit alle Dateien kopiert werden können. (Achtung: Bei falscher Handhabung kommt es zum Datenverlust)

Sicherung automatisieren

Speichern Sie ihrem rsnc Befehl nun als script in dem root Ordner unter /root/bin/ ab. Dazu können Sie vi benutzen. In dem oben genannten Falle sähe das Script so aus:

#! /bin/sh
rsync -auv --log-file=/var/log/rsync_backup --delete --exclude=/sys --exclude=/tmp --exclude=/proc --exclude=/mnt --exclude=/dev --exclude=/backup / /backup
Um das Script anzulegen geben Sie vi rsync_backup ein. Wenn sich vi geöffnet hat drücken Sie i um in den Eingabemodus zu gelangen. Nachdem Sie das Script eingetippt haben drücken Sie Esc und geben dann :wq ein, gefolgt von einem Enter. Das w steht für write und da q für quit. Damit werden die Daten geschrieben und vi beendet.
Geben Sie nun als root folgenden Befehl ein um dem crondeamon einen neuen Task einzuplanen:
crontab -e

Nun öffnet sich der Editor vi. Drücken Sie nun i um in den Eingabemodus zu gelangen und tippen Sie folgendes ein. Was schon vorhanden ist müssen Sie nicht wiederholen:

SHELL=/bin/sh
* 18 * * 0 /root/bin/rsync_backup

Das * 18 * * 0 steht für jeden Sonntag um 18 Uhr soll der Befehl /root/bin/rsync_backup ausgeführt werden. Wie Sie ihr eigenen Zeitplan erstellen können habe ich weiter unten verlinkt. Drücken Sie nun Esc. Tippen Sie nun :wq ein und bestätigen Sie mit Enter.

Interessante Links zu dem Thema

 

Günstiger Atomserver mit openSUSE

Hinterlasse eine Antwort

Fertiger Server auf Standfuß

Das ein kleiner Homeserver praktisch ist, ist nicht erst seit gestern bekannt. Deshalb finden Sie hier eine kleine Anleitung zum selber bauen, da Sie damit wesentlich günstiger wegkommen als einfach einen NAS zu kaufen, der obendrein weniger flexibel ist. Insgesamt kostet Sie dieses System ca. 250€ und ein paar Stunden Zeit zum einrichten. Jeder der schon einmal einen Rechner zusammengebaut hat wird auch mit diesem System keine Probleme haben. Was Sie auf jedenfall brauchen sind Grundkenntnisse in openSUSE und Linux. Ansonsten sollten Sie lieber einen NAS kaufen, oder Windows darauf installieren. Wobei beides irgendwie langweilig ist.

Hardware

  • ANTEC ISK 300 65W
  • ASUS AT4NM10-I mit Atom D410
  • GEIL 1GB DDR800 RAM
  • 2x 2,5″ 160GB Western Digital 24/7 Festplatten
  • 1x Netzwerkkabel

Lieferung

Ich habe mich hier für das Antec Gehäuse wegen seiner kompaktern Bauform und auch wie ich im Nachhinein festgestellt haben super Qualität entschieden. Das Gehäuse ist sehr gut verarbeitet. Es gibt keine scharfen Ränder. Die Schrauben machen einen Eindruck das man sie mehr als einmal hineinschrauben kann. Das Mainboard inkl. Prozessor ist passivgekühlt, so das an Betriebsgeräusch nur der im Gehäuse verbaute Lüfter zu hören ist. Bei mittlerer Drehzahl ist er kaum hörbar.

Einbau

Im Gehäuse selber geht es sehr eng zu, so dass die beigelegten Kabelbinder und Kabelösen sehr gut zu gebrauchen sind. Da das 24polige Mainboardkabel sehr kurz ist, sollte beim Kauf darauf geachtet werden wo sich der Stecker befindet. Das Mainboard musste mit etwas Kraft an die Schnittstellenseite gedrückt werden damit es festgeschraubt werden konnte. Hier auf die Schraubengröße achten, ansonsten lassen sich diese nicht festziehen. Da ich zwei Festplatten verbaut habe bleibt die an der Frontseite des Gehäuses befindliche SATA Schnittstelle ohne Funktion, da nur zwei SATA Schnittstellen am Mainboard vorhanden sind. Dem Mainboard liegt nur ein SATA Kabel bei. Sollten Sie auch zwei Festplatten benutzen brauchen Sie noch ein Kabel zusätzlich. Leider hat Antec keinen Speaker eingebaut. Zum Glück hatte ich noch eines in Reserve, ansonsten muss man einen für etwa 2 bis 3 Euro nachkaufen.

Installation

Innenansicht

Nachdem das System zusammengebaut ist, wurde das System in diesem Falle openSUSE 11.3 mit einer minimalen X Oberfläche installiert. Dazu habe ich ein externes DVD Laufwerk verwendet, da ein Slot-In Laufwerk sehr teuer ist und in einem Server eigentlich auch nie gebraucht wird. Sie können aber auch einen USB Stick verwenden oder ein Laufwerk einbauen.

Nach der Installation lässt es sich per ssh warten (So kann man sich auch zwangsweise mit dem Terminal auseinandersetzen). Mit Updates versorgt es sich der  Server selber per cron. Für die restlichen Systeme die ich unter openSUSE laufen lasse, wird das Updaterepository automatisch auf dem Server gespiegelt, so das die Updates schnell verteilt werden können und nur einmal geladen werden müssen. Natürlich läuft auch ein SMB, Apache und CUPS darauf.

Das System lässt sich mit dem mitgelieferten Ständer auch horizontal Aufstellen so das kaum Platz gebraucht wird.

Interessante Links zu dem Thema

Da ich selber schon viel zu dem Thema recherchiert habe, möchte ich Ihnen ein paar Interessante Links zu dem Thema nicht vorenthalten: