Kommentar / Teilnehmer:
01 – Morten
02 – Matthias
03 – Tobias
04 – Dieter R.
05 – Micha
06 – Harry
07 – Holger
08 – Lukas
09 – Rolf
10 – Michael
11 – Silvan
12 – Sven
13 – alexander
14 – Jochen
15 – matthias
16 – Marco
17 – Toni
18 – Sabrina
19 – Jarek
20 – bim21
21 – Renate Wecker
22 – Michael T
23 – petra
24 – Bärbel
25 – Lars
26 – Kai
27 – Trollfjord
28 – Anita
29 – Christina
30 – Holger
31 – Jörg
32 – Yto
33 – Maspe
34 – Josip
35 – flaus10
36 – Jerome
37 – Nadine
38 – Jan
39 – Andrea
40 – Kevin
41 – Rolli
42 – Astrid
43 – Alina
44 – R.S.
45 – Conny
46 – Marlon
47 – Mathias
48 – karin
49 – Denise B.
50 – Stefanie

Herzlichen Glüchwunsch an Micha, Holger, flaus10, Jan & Alina.
Ihr bekommt von mir in Kürze eine Mail mit den Lizenzschlüsseln an die von euch angegebene E-Mail Adresse.

Ein Beispiel ist der SSLExplorer, eine Open Source SSL VPN Lösung. 3SP Ltd. hat die Entwicklung der unter der GPGL stehenden Community Edition Anfang 2008 eingestellt und Updates, Bugfixes etc. nur noch für die kostenpflichtige Enterprise Edition bereitgestellt. Um den SSLExplorer unter Debian / Ubuntu zu installieren, benötigt man zwingend die ältere Java Version 1.5.x. Da im aktuellen Stable Repository Java in der Version 1.6.x enthalten ist, würde nach einem aptitude upgrade die aktuelle Version installiert werden. Um das zu verhindern, kann man als root mit folgenden Befehl das Update für ein bestimmtes Paket zurückhalten (funktioniert nur bei Debian basierten Distributionen):

Paket-Aktuallisierung sperren

echo <Paket> hold | dpkg --set-selections

Sperre aufheben und Updates wieder freigeben

echo <Paket> install | dpkg --set-selections

List mit gesperrten Paketen anzeigen

dpkg --get-selections | grep hold

Wichtigsten Änderungen / Neuerungen in der der Version 2012
- Aktuallisierte und verbesserte Scan-Engine
- Die Cloud Erkennungsengine Deepguard ist jetzt in der Version 4 enthalten
- Online-Security: Browserschutz kann jetzt Benutzer bezogen konfiguriert werden

Weitere Informationen gibt es auf der offiziellen Homepage, eine sehr ausführliche Vorstellung der Internet Security 2012 findet man bei Mike im Blog.

Verlosung
Ich habe fünf Lizenzen für die aktuelle Version 2012 zum Verlosen bekommen. Die Lizenzen laufen ein Jahr und können jeweils auf drei Computern installiert werden. Wenn ihr eine Lizenz gewinnen wollt, dann schreibt einfach einen “Will haben”-Kommentar unter diesen Artikel. Die Verlosung läuft bis 14.01.2012 23:59 Uhr. Ich werde anschließend fünf glückliche Gewinner per random.org ziehen und per Mail kontaktieren. Bitte achtet darauf, dass ihr eine gültige E-Mail Adresse angebt.

Unter /etc/xdg/autostart liegen verschiedene .desktop Konfigurations Dateien, in denen die automatisch zu startenden Programme definiert sind.
Die genaue Funktionsweise und Syntax ist hier beschrieben. Falls ein Programm den sauberen Start von Gnome verhindert, könnte man die .desktop Konfigdatei entfernen und somit den Autostart verhinden.

Sowohl bei Linux Mint als auch bei Ubuntu wird eine grafische Oberfläche zur Konfiguration der Autostart Programme mitgeliefert. Bei Linux Mint kann man das Einstellungsfenster via Alt+F2 (öffnet das Befehlsfenster) und dann “gnome-session-properties” eingeben oder im Menü nach “Startup Applications” suchen. Standardmäßig werden hier die meißten Programme und Dienste ausgeblendet, entweder man konfiguriert den Autostart via Kommandozeile oder man ändert in den oben erwähnten .desktop Files die Zeile NoDisplay=true in NoDisplay=false, anschließend werden alle Einträge im “Startup Applications Preferences” Fenster angezeigt.

Folgende Zeile ändert in allen .desktop Files den Wert NoDisplay=true in false.

sudo sed -i 's/NoDisplay=true/NoDisplay=false/g' /etc/xdg/autostart/*.desktop

Durch das Entfernen nicht benötigter Einträge im Autostart Menü lässt sich der Systemstart je nach Hardware deutliche beschleunigen. Vor einer Änderung bei den “Startup Application Settings” macht es Sinn, den gesamten /etc/xdg/autostart Ordner zu sichern.

Weiterführende Informationen zur Autostartfunktion findet man im Ubuntuusers Wiki

Screenshot: Anzeige aller Autostart Programme in Linux Mint

Archiv (PPA) aktivieren und System updaten

sudo apt-add-repository ppa:ubuntu-mozilla-security/ppa
sudo aptitude update
sudo apttiude upgrade

Nach dem upgrade wird der Firefox automatisch aktualisert.

Foto Von Stuck in Customs – CC BY-NC-SA 2.0

I. Voraussetzungen:

Eine detaillierte Anforderungsliste findet man bei: drupalcenter.de, unter Debian bzw. Ubuntu müssen noch folgende Pakete installiert werden: PHP 5.3.x, MySQL, Apache. Unter Debian führt man diesen Befehl als Root aus und bei Ubuntu setzt man wie gewohnt ein sudo vor den eigentlichen Befehl.

aptitude install php5 php5-gd php5-mysql mysql-server apache2

II. Datenbank vorbereiten:

Als Datenbankname verwende ich Drupal7DB, der Benutzer lautet: drupaluser und das Passwort lautet in diesem Beispiel: geheimesPW

mysql -p
Enter password:

mysql> create database Drupal7DB;
Query OK, 1 row affected (0.00 sec)

mysql> CREATE USER 'drupaluser'@'localhost' IDENTIFIED BY 'geheimesPW';
Query OK, 0 rows affected (0.00 sec)

mysql> GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER ON Drupal7DB.* TO drupaluser@localhost;
Query OK, 0 rows affected (0.00 sec)
mysql> QUIT
Bye

III. Drupal Download und Installationsvorbereitungen

Drupal von der offiziellen Seite downloaden und entpacken:

wget http://ftp.drupal.org/files/projects/drupal-7.8.tar.gz
tar xvzf drupal-7.8.tar.gz

Die Drupal Dateien nach /var/www/drupal verschieben:

mv drupal-7.8/ /var/www/drupal

Berechtigungen setzen: Die Drupal Dateien im Verzeichnis /var/www/drupal müssen alle dem Benutzer, unter dem der Apache läuft (bei Debian und Ubuntu ist das standardmäßig www-data) gehören.

cd /var/www/
chown -R www-data.www-data /var/www/drupal/

Folgende Berechtigungen müssen vor der Installation noch gesetzt werden:

chmod -R 650 /var/www/drupal/sites/default
cd /var/www/drupal/sites/default
cp ./default.settings.php settings.php
chmod 650 settings.php

IV. Drupal Installation
Im Browser http://SERVERNAME/drupal aufrufen und den Installationsassistenten starten

1. Select an installation profile

2. Choose Language

Standardmäßig ist nur Englisch verfügbar, weitere Sprachdateien findet man auf der offiziellen Drupal Seite: localize.drupal.org

3. Database configuration

Hier gibt man die zuvor definierten Werte ein, bei den "Advanced Options" kann man eine alternativen Datenbankadresse und Port definieren, falls die Datenbank nicht auf dem selben Server läuft wie der Apache bzw. der Datenbankport vom Standard MySQL Port 3306 abweicht. Wenn die selbe Datenbank für mehrere Anwendungen benutzt wird, sollte man unbedingt einen Präfix benutzen!

4. Installing Drupal

Drupal legt jetzt die Datenbankstruktur an und schreibt die Einstellungen in die settings.php Datei.

5. Configure Site

Jetzt muss man noch allgemeine Informationen wie z.B. Name, Kontaktdaten, Admin-Benutzer und Ländereinstellungen definieren.

V. Installation abschließen

chmod 440 -R /var/www/drupal/sites/default/

Drupal Security
Das Modul Security Review ist eine gute Möglichkeit um u.a. die Berechtigungen der gesamten Drupal Installation zu überprüfen.

Lieferumfang
Zum Lieferumfang gehören neben der Lampe, passende Batterien und eine Tragebox aus Hartplastik, die man auch am Gürtel befestigen kann. Die Box eignet sich hervoragend zum Transport der Stirnlampe und liegt gut in der Hand, so dass die H4 als “normale” Taschenlampe genutzt werden kann, dazu muss die Lampe lediglich in die Box gesteckt werden.

Tragekomfort
Der Tragekomfort der Stirnlampe ist auf Grund des geringen Gewichts von 85 Gramm sehr gut. Man spürt die Lampe bereits nach kurzer Zeit nicht mehr und trotzdem verrutscht die Lampe bei leichten Erschütterungen, wie sie zum Beispiel beim Joggen entstehen, nicht. Der Gurt kann schnell und einfach mit einer Schnalle an die Größe des Kopfes angepasst werden. Beim Joggen hat mich die Lampe in keinster Weise gestört.

Leuchtkraft / Ausleuchtung
Im Gegensatz zur LED Lenser H14 ist die hier vorgestellte H4 Stirnlampe nicht fokussier- und schwenkbar, was aber auf Grund der gleichmäßigen Ausleuchtung des Blickfeldes kein Problem darstellt. Die vom Hersteller angebenen 20 Meter Leuchtweite sind mit frischen Batterien realistisch.

Persönliches Fazit
Die LED Lampe ist trotz des geringen Preises von c.a. 30€ sehr hochwertig verarbeitet und auch die Qualität lässt, wie bei LED Lenser üblich, keine Wünsche offen. Ich benützte die LED Lenser H4 hauptsächlich zum Joggen und empfinde den Tragekomfort auch nach einer Stunde noch als sehr angenehm, was sicher auf das sehr geringe Gewicht und den Tragegurt zurückzuführen ist. Die mitgelieferte Plastikbox macht auf mich einen eher billigen Eindruck und auch das Einsetzen der Lampe in die Box hat sich als nicht ganz so einfach erwiesen. Ich persönlich würde die Lampe nicht als Taschenlampenersatz bezeichnen, da sie von der Leuchtleistung natürlich nicht an die “normalen” Taschenlampen von LED Lenser heranreicht.

Verlosung
Im Zuge dieses Testberichtes ermöglichen Zweibrüder Optoelectronics mir unter meinen Bloglesern ein Exemplar der hier beschriebenen Lampe zu verlosen. Wenn ihr die LED Lenser H4 gewinnen möchtet, hinterlasst hier einfach einen Kommentar bis einschließlich 11.11.2011, in dem ihr schreibt für was ihr die Lampe einsetzen würdet. Ich werde den Gewinner dann per E-Mail kontaktieren. Bitte achtet darauf, dass eure E-Mail-Adresse auch gültig ist.

Weitere Informationen findet ihr auf der offiziellen Facebook Seite von LED LENSER oder im Forum.

Dies ist eine von Hallimash vermittelte Kampagne

Installation via aptitude
Unter Debian und Ubuntu kann Fail2Ban aus den Paketquellen installiert werden. Ich verwende in diesem Beispiel den Paketmanager aptitude, unter Debian führt man diesen Befehl als Root aus und unter Ubuntu setzt man wie gewohnt ein sudo vorne dran. Fail2Ban wird als Daemon installiert und nach der Installation automatisch gestartet, zusätzlich wird auch der fail2ban-client installiert.

aptitude install fail2ban

Standard Konfiguration
Nach erfolgreicher Installation findet man im Ordner/etc/fail2ban/ die Konfigurationsdateien. Die Konfiguration ist auf verschiedene Dateien und Ordner aufgeteilt: fail2ban.conf, jail.conf, action.d & filter.d. In der Datei /etc/fail2ban/fail2ban.conf werden allgemeine Programmeinstellungen gesetzt, in der jail.conf werden die sogenannten “jails” definiert, im Ordner action.d findet man verschiedene Scripte die bei bestimmten Ereignissen ausgeführt werden und im Ordner filter.d sind die regulären Ausdrücke gespeichert, die benötigt werden um z.B. Einbrüche bzw. Einbruchsversuche in Logfiles zu erkennen.

Um die Konfiguration anzupassen sollte man eine Kopie der beiden .conf Dateien machen und diese als .local im selben Ordner abspeichern. Bei einem Neustart werden zuerst die .conf und anschließend die .local Datein eingelesen, wobei die Einstellungen aus der .local priorisiert werden. In den .local Dateien werden nur die Anpassungen gespeichert und nicht die gesammte Konfiguration. Neben der fail2ban.conf & jail.conf sollten jetzt noch eine fail2ban.local und eine jail.local im Konfigverzeichnis zu finden sein.

/etc/fail2ban/fail2ban.conf

Das Loglevel ist standardmäßig auf 3 (1 = ERROR, 2 = WARN, 3 = INFO, 4 = DEBUG) gesetzt, logtarget gibt den absoluten Pfad zur Logdatei an und zusätzlich kann hier der Socket-Pfad definiert werden.

/etc/fail2ban/jail.conf

Die Default Einstellungen können alle in den einzelnen jail-Definitionen überschrieben werden. Mit ignoreip kann man bestimmte Host wie z.B. DNS-Server vor Fail2ban “schützen”, bantime definiert die Zeit, die ein Host gesperrt wird und maxretry gibt die Anzahl der Fehlversuche an, die von einer IP-Adresse kommen können bis diese gesperrt wird.

Um sich im Falle eines Alarms per Mail benachrichtigen zu lassen, muss man bei destemail eine gültige E-Mail Adresse angeben und bei mta einen konfigurierten Mail Transfer Agent definieren.

In diesem Abschnitt wird ein sogenannter jail definiert: in eckigen Klammern steht der Name, mit enabled = true wird der jail aktiviert, port = ssh gibt den zu überprüfenden Dienst / Service an, mit filter = sshd wird der auszuführende Filer (/etc/fail2ban/filter.d/) bestimmt, logpath = /var/log/auth.log ist die Logdatei in der nach den regulären Ausdrücken, die im entsprechenden Filter definiert sind gesucht wird, maxretry = 6 siehe oben.

Fail2ban Konfiguration anpassen
Wie bereits oben beschrieben, sollte man Konfigurationsanpassungen aus verschiedenen Gründen in eine separate Datei (jail.local) auslagern. Die in der .local Konfig gespeicherten Werte werden priorisiert. Bis auf den ssh-jail sind alle anderen standardmäßig deaktiviert, um sie zu aktivieren kopiert man den enstprechenden Bereich einfach in die jail.local und aktiviert den jail mit enabled = true.

Beispiel: Server gegen SSH-DDoS Attacken absichern

/etc/fail2ban/jail.local

Der Unterschied zum anderen ssh-jail ist der eingesetzte Filter, der gezielt auf SSH-DDOS Angriffe ausgelegt ist. Mit einem Neustart des Fail2Ban Servers, /etc/init.d/fail2ban restart wird die Konfiguration eingelesen und kann anschließend mit Hilfe des automatisch installierten fail2ban-client überprüft werden:

root@r-o-f:~# fail2ban-client status
Status
|- Number of jail:      2
`- Jail list:           ssh-ddos, ssh

Test
Zum Testen habe ich einfach mit eine kleine SSH-DDos Attacke gemacht, in dem ich ein paar mal mit falschen Zugangsdaten versucht habe mich anzumelden. Das Ergebnis kann man anschließend u.a. in dem Fail2ban-Logfile (/var/log/fail2ban.log) oder via neuer automatisch generierter iptables Regel sehen:

/var/log/fail2ban.log
IP-Adresse gesperrt:

Nach Ablauf der Sperrzeit (siehe bantime) wird die IP wieder von der Blacklist genommen.

iptables

Links
Fail2ban: http://www.fail2ban.org
Deutsche FAQ: http://www.fail2ban.org/wiki/index.php/FAQ_german
Blogeintrag bei Netz 10: http://netz10.de/2011/02/16/fail2ban/

Vorkehrungen
Um Nmap kompilieren und installieren zu können wird bei einem frisch installierten Debian Squeeze noch ein C Compilier z.B. g++ benötigt, optional auch noch bzip2 wenn man das Standard Bzip2 Paket nimmt.

Installation
Download und Validierung des heruntergeladenen Paketes habe ich in einem früheren Blogpost bereits ausgiebig beschrieben: Nmap 5.00 Installation

root@r-o-f:~# bzip2 -cd nmap-5.51.tar.bz2 | tar xvf -
root@r-o-f:~# cd nmap-5.51
r-o-f:~/nmap-5.51# ./configure
root@r-o-f:~/nmap-5.00# make
root@r-o-f:~/nmap-5.00# make install

Nach erfolgreiche Installation kann man anschließend mit nmap –version die Version überprüfen.

root@r-o-f:~# nmap --version

Nmap version 5.51 ( http://nmap.org )

configure: WARNING: Failed to find openssl/ssl.h so OpenSSL will not be used.
Wenn beim Kompilieren die Fehlermeldung kommt, dann fehlen die OpenSSL Header, entweder man kompiliert Nmap ohne SSL-Unterstützung oder man installiert das erforderliche Paket nach:

root@r-o-f:~# aptitude install libssl-dev

Fehlermeldung: Failed to find openssl/ssl.h so OpenSSL will not be used

checking openssl/ssl.h usability... no
checking openssl/ssl.h presence... no
checking for openssl/ssl.h... no
configure: WARNING: Failed to find openssl/ssl.h so OpenSSL will not be used.
        If it is installed you can try the --with-openssl=DIR argument