Begonnen habe ich mit OpenVPN und habe es mit SSL verschlüsselt und auf Port 443 gelegt. Doch interessanter weise wollte keine Verbindung zu Stande kommen. Das Problem lag darin, dass die Firewall bereits blockte, bevor mein Client überhaupt einen SSL-Tunnel aufbauen konnte.
Die Lösung dafür also, ich brauche eine Lösung, welche ich als normale Webseite ansurfen und dann vom Server aus einen SSL-Tunnel aufbauen kann.
Dank dem Macher von IT Blögg bin ich auf SSLExplorer, oder besser gesagt das Folgeprojekt daraus auf Adito SSL VPN gestossen.
Die Installation dazu ist denkbar einfach. Ein bisschen Javacode, einmal kompilieren und noch hier und da ein Klick und schon läuft alles! Doch von vorne:

Installiert habe ich Adito nach folgender Anleitung hier. Die Installation geht relativ sauber und problemlos.

Doch nun kommt der kompliziertere Teil. Dank Adito kann ich jeglichen Traffic von meiner lokalen Maschine an eine beliebige IP und einen beliebigen Port im Netz weiterleiten. Also habe ich mir auf pfSense OpenVPN konfiguriert. Anleitungen dazu gibt es unzählige, mir hat dieses Video hier sehr geholfen:

Einzig eine kleine Unterscheidung musste ich vornehmen. Zum einen hier:

Und hier, da Adito bei mir nur TCP akzeptieren wollte:

Nun darf natürlich die Firewall nicht vergessen gehen:

So nun läuft OpenVPN und Adito, also gehts ans verknüpfen. In Adito richte ich mir unter “SSL Tunnels” einen neuen Tunnel ein. “Source Interface” ist hier 127.0.0.1, der “Source Port” ist ein beliebiger Port, bei mir zum Beispiel 12345. “Destination Host” und “Destination Port” sind die IP und Port unter welchem der OpenVPN Server verfügbar ist:

Nun aber muss man die Konfiguration vom OpenVPN Client noch ein bisschen tunen, welche man sich dank dem Client Export Utility problemlos und fix fertig herunterladen kann:

dev tun
persist-tun
persist-key
proto tcp
cipher BF-CBC
tls-client
client
resolv-retry infinite
remote 127.0.0.1 12345
tls-remote vpn server Cert
auth-user-pass
pkcs12 vpn-server.p12
tls-auth vpn-server-tls.key 1
comp-lzo

Schliesslich soll der Traffic ja auch über den SSL Tunnel laufen.

Und schon ist alles konfiguriert und es kann verbunden werden!

Tue Sep 06 14:16:00 2011 [vpn_server_Cert] Peer Connection Initiated with 127.0.0.1:12345

Ich möchte nicht übertreiben, aber ich behaupte einfach mal, das ganze funktioniert hinter jeder Firmenfirewall, ausser eure Firma hat etwas gegen verschlüsselte Seiten oder euren Server explizit ausgesperrt!

Und das Einrichten ist auch gänzlich einfach.
Auf der Seite von Prowl muss ich mich registrieren und die passende App aus dem Store herunterladen.
Nun lade ich das Perl-Script von der Seite auf meine Server:

wget http://www.prowlapp.com/static/prowl.pl

Hier muss man daran denken, dass das Script für den Benutzer zugänglich sein muss, unter welchem auch das Nagios läuft!

Nun müssen noch die passenden Pakete installiert werden:

aptitude install libwww-perl libcrypt-ssleay-perl

Wenn nun alles funktioniert hat, so kann die erste Nachricht versandt werden:

./prowl.pl -apikey="ENTER_APIKEY" -application="Nagios" -event="Notification" -notification="Dies ist ein Test"

Klinget es auf dem Handy, so kann man das ganze noch in Nagios integrieren. Dazu wird ein neuer Kontakt angelegt unter /usr/local/nagios/etc/objects/contacts.cfg:

define contact {
        contact_name                    patrick_iphone
        alias                           Patrick
        service_notification_period     24x7
        host_notification_period        24x7
        service_notification_options    w,u,c,r,f,s
        host_notification_options       d,u,r,f,s
        service_notification_commands   notify-service-by-prowl
        host_notification_commands      notify-host-by-prowl
        _prowl_apikey                   ENTER_APIKEY
}

Dann muss noch die Gruppe ergänzt werden:

define contactgroup{
        contactgroup_name       admins
        alias                   Nagios Administrators
        members                 nagiosadmin, patrick_iphone
        }

Nun kann unter /usr/local/nagios/etc/objects/commands.cfg das oder die passenden Kommandos zugefügt werden:

# PROWL
define command {
        command_name    notify-host-by-prowl
        command_line    /usr/bin/perl -w /home/nagios/prowl.pl -apikey="$_CONTACTPROWL_APIKEY$" -priority=1 -application="$HOSTNAME$" -event="$HOSTSTATE$" -notification="$HOSTOUTPUT$"
}

define command {
        command_name    notify-service-by-prowl
        command_line    /usr/bin/perl -w /home/nagios/prowl.pl -apikey="$_CONTACTPROWL_APIKEY$" -priority=1 -application="$HOSTNAME$ $SERVICEDESC$" -event="$SERVICESTATE$" -notification="$SERVICEOUTPUT$"
}

Nun noch Nagios neu starten und schon werden alle Ausfälle oder sonstige Erinnerungen ans iPhone übermittelt.
Die API erlaubt es aktuell 1000 Mitteilungen pro Stunde zu versenden. Bezahlen tut man nur für die iPhone App, das Versenden von Mitteilungen ist gratis.

Vielen Dank an Julian für die Idee!

Alles was man braucht ist ein gerootetes Galaxy Tab. Weiter muss das folgende installiert werden:

• Busybox
• Superuser
• AndroidVNC
• Terminal Emulator

Und natürlich noch das wichtigste: die Core-Dateien von hier

Zum kopieren wird das SDK und die darin enthaltene Datei adb verwendet. Bei su muss das Tab entsperrt sein und die Anfrage auf dem Display berechtigt werden:

cd C:/sdk/plattform-tools
adb.exe shell
su
cd /sdcard/
mkdir ubuntu
exit

Nun könnten die Daten rüberkopiert werden. Jedoch, aus welchen Gründen auch immer, versucht das Skript bootlinux das Image als ext4 zu mounten, was das Tab dummerweise gar nicht unterstützt… Also muss das zuerst noch angepasst werden:

#modprobe ext4
mount -o remount,rw -t yaffs2 /dev/block/mtdblock4 /system
export kit=/sdcard/ubuntu
export bin=/system/bin
if [ ! -d /data/local/ubuntu ]
then
mkdir /data/local/ubuntu
fi
export mnt=/data/local/ubuntu
export PATH=$bin:/usr/bin:/usr/sbin:/bin:$PATH
export TERM=linux
export HOME=/root
mknod /dev/loop5 b 7 0
losetup /dev/block/loop5 /sdcard/ubuntu/ubuntu.img
mount -t ext2 /dev/block/loop5 /data/local/ubuntu
#mount -o loop,noatime -t ext4 $kit/ubuntu.img $mnt
mount -t devpts devpts $mnt/dev/pts
mount -t proc proc $mnt/proc
mount -t sysfs sysfs $mnt/sys
sysctl -w net.ipv4.ip_forward=1
echo "Setting /etc/resolv.conf to Google Open DNS 8.8.8.8 and 8.8.4.4"
echo "nameserver 8.8.8.8" > $mnt/etc/resolv.conf
echo "nameserver 8.8.4.4" >> $mnt/etc/resolv.conf
echo "Setting localhost on /etc/hosts "
echo "127.0.0.1 localhost" > $mnt/etc/hosts
echo "Created by KellyLewis3985 and BThomas22x! "
echo "Brought to you by Team Viper! "
echo " "
chroot $mnt /bin/bash

#After exit command is executed clear it all up
echo " "

echo "Shutting down Ubuntu"
umount $mnt/dev/pts
umount $mnt/proc
umount $mnt/sys
umount $mnt

Nun können die Dateien rüberkopiert werden. Und keine Panik, das Image dauert etwas länger :

adb.exe push bootlinux /sdcard/ubuntu
adb.exe push fsrw /sdcard/ubuntu
adb.exe push mountonly /sdcard/ubuntu
adb.exe push ubuntu.sh /sdcard/ubuntu
adb.exe push unionfs /sdcard/ubuntu
adb.exe push ubuntu.img /sdcard/ubuntu

Nun kommt nochmal adb.exe shell zum Einsatz:

cd /sdcard/ubuntu
sh ./ubuntu.sh
bootlinux

Und schon läuft Ubuntu auf dem Tab. Ich habe mir noch Openssh-server installiert, damit ich immer wieder darauf zugreifen kann:

apt-get install openssh-server
/etc/init.d/ssh restart

Und erstaunlicherweise wird das Tab nicht merklich langsamer

Wer nun will, der kann sich noch einen VNC-Server einrichten, damit er das GUI benützen kann, der muss diesen auf dem Linux zuerst einrichten:

rm -rf /tmp/.X*
export USER=root
vncserver -geometry 1280x800

Danach kann über AndroidVNC verbunden werden:

Der Nickname ist “root”, das Passwort “ubuntu” und das alles unter “localhost” über Port 5901:

Vielleicht gibt es bald eine Lösung mit Dualboot, das wär cool Denn die Netbook-Edition stell ich mir noch ganz angenehm vor auf dem Tablet… Oder was denkt ihr? Würdet ihr bei Android bleiben, wenn es eine passende Ubuntu-Version gäbe?

Das könnte dich auch interessieren:

1. Ubuntu Cola Ubuntu ist die erste Cola in der Schweiz, welche mit...
2. Android und das Galaxy Tab Seit nun ca. einem Monat bin ich in Besitz eines...
3. K.O. für Samsung Galaxy Tab Das Galaxy Tab wurde standardmässig mit FAT formatiert, wobei Dateien,...
4. Der Alptraum für jeden Computer Heute ist mein Teensy++ 2.0 endlich aus der USA rübergeflogen...

Ganz cool dabei:

Ubuntu ist die erste Cola in der Schweiz, welche mit der Fair Trade Handelsmarke gekennzeichnet wurde. Die Cola zischt mit Fair Trade Rohrzucker aus der Kasinthula Genossenschaft in Malawi und aus der Kaleya Genossenschaft in Sambia.
Das bedeutet ganz einfach, dass Sie jedes Mal, wenn Sie eine Ubuntu Cola trinken, direkt an der Fair Trade Bewegung teilnehmen – Sie wirken aktiv mit und spenden gleichzeitig an langfristigen und wahren Entwicklungsmöglichkeiten für Afrikanische Gemeinschaften.

Wie es schmeckt, konnte ich noch nicht probieren, mal schauen ob es an Coca Cola rankommt
Wer nun mehr dazu wissen will, findet hier weitere Informationen.

Wie sieht es denn mit dir aus?

Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.

Falls du bereits die neuste Version verwendest, wie bist du vorgegangen?

Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.

Und wie hat alles geklappt?

Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.

Und wie gefällt dir das neue Ubuntu so? Oder was würdest du dir noch wünschen?

Nun ist aber schon einige Zeit vergangen und es ist mal an der Zeit um eine Bilanz zu ziehen.
Wie sieht es denn bei euch so aus?

Und interessant wäre auch noch wieso?

Dazu verwendet man am einfachsten htpasswd:

1

sudo htpasswd -c /etc/hobbit/hobbitpasswd admin

Nun gibt man zwei Mal das gewünschte Passwort ein, und schon ist die Arbeit getan.
Nun kann man auf seinem Hobbitserver das WebGUI aufrufen und unter Administration > enable/disable zuerst den Server, und dann den gewünschten Server oder auch gleich alles deaktivieren. Einloggen kann man sich mit dem Benutzernamen admin und dem eben gewählten Passwort.

Weiter kann man noch einen Grund vermerken und je nach Dauer zwischen automatischem oder manuellem reaktivieren der Überwachung wählen.

Ganz praktisch ist auch der letzte Punkt, mit welchem man das Deaktivieren der Überwachung auf die Minute genau 5 Jahre im voraus planen kann

Für mich ist das insofern ein Problem, da ich nicht immer vorhersagen kann, welche IP Adresse ich gerade haben werde, wenn ich den Status meiner Server abfragen will.
Also habe ich mit allem Möglichen versucht, mir Zugriff zu verschaffen. Leider lässt sich weder Regex, noch ein ganzer IP-Range definieren.

Eine Möglichkeit, trotzdem von überall Zugriff zu erhalten, wäre gewesen, einfach eine ältere Version von Hobbit zu verwenden, wo dieses “Feature” noch nicht implementiert ist! Doch das ist auch nicht die beste Lösung.
Leider wollte auch das Internet nichts sinnvolles ausspucken; anscheinend bin ich der Einzige mit diesem Problem…

Schlussendlich, beim ziellosen durchstöbern der Hobbit-Konfigurationsfiles bin ich auf die Datei hobbit im Ordner /etc/apache2/conf.d/ gestossen!
Darin gibt es drei Mal folgenden Eintrag:

1

Allow from localhost ::1/128

Diese gilt es nur abzuändern in:

1

Allow from all

und dann Apache neustarten:

2

sudo /etc/init.d/apache2 restart

und schon ist dieses Problem aus der Welt geschaffen.
Von jetzt an komme ich von überall auf meinen Hobbitserver, egal welche IP ich habe

Und da ich mit Xymon (siehe früherer Artikel) den ClamAV Daemon überwachen kann, werden meine eigenen Server nun auch mit dem ausgestattet.

Die Installation von ClamAV ist dank den Paketquellen äußerst simpel:

1

sudo apt-get install clamav clamav-daemon

Danach kann man die Konfiguration des Daemons starten:

2

sudo dpkg-reconfigure clamav-base

Hier wird man schön durch die einzelnen Schritte geführt. Meistens waren die Standardeinstellungen schon ausreichend, dies liegt aber ganz im Ermessen des Admins:

3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

Automatische Verwaltung der Konfigurationsdatei: JA
Socket-Typ: UNIX
Lokaler UNIX Socket: STANDARD
Grosszügier Umgang mit übrig geblibenen UNIX-Sockets: NEIN
eMail-Überprüfung: JA
Archiv-Überprüfung: JA
Maximale Grösse: 50
Maximale Verzeichnistiefe: 0
Symbolischen Links folgen: JA
Normalen Links folgen: JA
Zeitbeschränkung: 0
Anzahl Threads: 12
Anzahl wartende Verbidungungen: 15
Nutzung von Syslog: JA
Protokolldatei: STANDARD
Zeitangaben mitprotokollieren: JA
Zeitspanne für Selbsttest: 3600
Benutzer für Daemon: clamav
Daemon-Gruppe: root
Finish :)

Der Daemon kümmert sich nun darum, dass die Virendatenbank immer aktuell bleibt.

Leider aber ist ClamAV ein sogenannter OnDemand-Scanner, d.h. der Suchvorgang muss gestartet werden, und es wird nicht, wie üblich jede Datei vor dem Verwenden gescant.

Dem kann man jedoch mit einem Cronjob entgegenkommen, und da meine Server nur einem minimalen Risiko ausgesetzt sind, reicht dies auch vollkommen aus. Für einen Server mit High-Availability-Anwendungen sollte man sich einen “richtigen” Scanner zulegen.

Also rufe ich die Cronjobs von Root auf:

23

sudo crontab -e

Da lege ich dann einen neuen Eintrag an:

24

00 01 * * 0 sudo clamscan -ri --quiet --bell --scan-mail --phishing-sigs --phishing-scan-urls --heuristic-scan-precedence --algorithmic-detection --scan-pdf --exclude-dir=^/proc\ / #Scan Root rekursiv, show only infected files

Damit wird jeden Sonntag morgen um Punkt 01:00 Uhr ein Scan ausgelöst, welcher das gesamte Root-Verzeichnis rekursiv durchscannt.

Weiter Informationen zu Zeitangaben für Cronjobs findet man im uu.de-Wiki.

Zum Abschluss würde es mich nun aber doch noch interessieren, wie und ob ihr eure Server den schützt?

Nur leichter einzurichten bedeutet alles andere als schlechter! Wenn ich mich Entscheiden müsste zwischen Xymon (ehemals Hobbit) und Nagios, so würde ich für mich persönlich Xymon nehmen, da mich Nagios mit seinen zahlreichen Funktionen direkt überfordert.

Xymon ist mit den Funktionen nicht ganz so umfänglich, deckt aber die wichtigsten ab. So lassen sich mit Xymon Serverkomponenten wie Harddisks, CPU, Memory, Prozesse, aber auch Dienste wie FTP, SSH, SMTP, POP und vieles mehr überwachen.

Doch wenn man so tief ins System eines Servers eingreifen will, dann braucht man meistens auch einen Agent, welcher die ganzen Daten ausliest.

Dieser Agent ist für Debian-basierte Systeme in den Paketquellen verfügbar und kann wie folgt installiert werden:

1

sudo apt-get install xymon

Während der Installation wird man nach der IP des Datacollectors gefragt, welcher das Webfrontend und damit die ganzen Daten verwaltet.

Nun muss man zusätzlich auch noch Apache installieren, da, aus welchen Gründen auch immer, dieses Paket nicht als Abhängigkeit eingerichtet wurde:

2

sudo apt-get install apache2

Jetzt gilt es noch die Daten aus /etc/hobbit/web über den Browser verfügbar zu machen. Dazu kann man einen Softlink von /var/www zum Ordner mit den Xymon-Webfrontend-Daten:

3

sudo ln -s /etc/hobbit/web /var/www/hobbit

Wenn man nun die IP des Datacollectors im Browser aufruft, so wird dieser bereits automatisch überwacht. Es müssen nun also noch weitere Server zugefügt werden.

Dazu editiert man die Datei /etc/hobbit/bb-host:

4

sudo vim /etc/hobbit/bb-host

Bei mir sieht die Datei so aus:

5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

# Master configuration file for Hobbit
#
# This file defines several things:
#
# 1) By adding hosts to this file, you define hosts that are monitored by Hobbit
# 2) By adding "page", "subpage", "group" definitions, you define the layout
#    of the Hobbit webpages, and how hosts are divided among the various webpages
#    that Hobbit generates.
# 3) Several other definitions can be done for each host, see the bb-hosts(5)
#    man-page.
#
# You need to define at least the Hobbit server itself here.
 
#0.0.0.0    .default.    # NOPROPRED:+apt,+libs
 
#group Servers
127.0.0.1    unix
192.168.1.1    router
192.168.1.4    iLO
192.168.1.5    VMware Server
192.168.1.6    Webserver
192.168.1.7    SVN Server
192.168.1.8    Monitoring Server
192.168.1.9    Reverse Proxy
192.168.1.10    DNS Server
192.168.1.11    LTSP Server
 
#group Dialup
#0.0.0.0    notebook.bla.net # noconn dialup

Hier definiert man unter #group Servers zuerst die IP, dann den Namen für die Beschreibung.

In der Datei /etc/hobbit/bb-services kann man Services definieren wie SSH, FTP, SMTP und vieles mehr. Die da angegebenen Standards sind für mich total ausreichend. Besonders interessant für mich, ist die Möglichkeit den ClamAV Daemon zu überwachen.

Wie sich aber die Services auch im Webfrontend anzeigen lassen, habe ich bis jetzt noch nicht herausgefunden.

Weiter gibt es noch die Möglichkeit, bei Fehlern Benachrichtigungen per Mail oder SMS zu versenden. Dazu kann man für jeden Service in der Datei /etc/hobbit/hobbit-alerts.cfg einen eigenen Verantwortlichen, die Alarmierungszeit, Mailadressen und vieles mehr definieren.

Danach zeigt einem das Webfrontend auf einen Blick für jeden Server genau an, welche Server, wo Probleme hat. Unterschieden wird dabei mit den Farben Rot, Violett, Gelb, Grün und Weiss den Zustand des Servers und diverse Symbole, welche angeben, ob ein Server erst seid kurzem oder schon länger Probleme hat.

Dazu werden automatisch Graphen mit Trends und anderen Informationen generiert. Und zu guter Letzt kann man auch noch Reports von Services und Funktionen über bestimmte Zeiträume erstellen.

Nun gilt es noch herauszufinden, wie sich Services überwachen lassen. Wer mir dazu also weiterhelfen kann, vielen Dank