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!

Als erstes setzt man über das GUI von Nvidia eine fixe Auflösung und Frequenz, welche der Bildschirm unterstützen kann.

Somit hat man mal wieder eine saubere und funktionierende xorg.conf-Datei, was in meine Fall wichtig war, da der Kunde schon viel selbst probiert hat.

Gehen wir mal davon aus, die Auflösung soll 1680×1050 mit einer Frequenz von 60 Herz sein.
Wir gebrauchen das Tool gtf um eine Modline für diese Auflösung generieren zu lassen:

1

gtf 1680 1050 60

Als Ausgabe erhalten wir folgendes:

1
2

# 1680x1050 @ 60.00 Hz (GTF) hsync: 65.22 kHz; pclk: 147.14 MHz
Modeline "1680x1050_60.00"  147.14  1680 1784 1968 2256  1050 1051 1054 1087  -HSync +Vsync

Dies fügen wir nun in unsere X11-Konfigurationsdatei ein unter /etc/X11/xorg.conf in der Sektion Monitor:

1
2
3
4
5
6
7
8
9
10

Section "Monitor"
    # HorizSync source: xconfig, VertRefresh source: xconfig
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "CRT-1"
    HorizSync       30.0 - 83.0
    VertRefresh     56.0 - 75.0
    Option         "DPMS"
    Modeline "1680x1050_60.00"  147.14  1680 1784 1968 2256  1050 1051 1054 1087 -HSync +Vsync
EndSection

Nun ist unser Bildschirm soweit, dass er die Auflösung unterstützen kann, jetzt soll er diese aber auch noch verwenden. Also ändern wir unter der Sektion Screen noch die aktuelle Auflösung:

1
2
3
4
5
6
7
8
9
10
11

Section "Screen"
    Identifier     "Screen0"
    Device         "Videocard0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option         "TwinView" "0"
    Option         "metamodes" "1680x1050_60 +0+0"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

Nun nur noch den X-Server neustarten und die neue Auflösung bewundern.

Doch noch ein paar Worte zu meinem Vorgehen:
Eigentlich wollte ich die Kommunikation von Script zu Server via dem virtuellen Device /dev/tcp abwickeln. Schon relativ früh zeigte sicher aber; das ist so nicht lösbar!
Das Problem dabei ist, dass sobald irgendetwas auf den Device umgeleitet wird, wird die TCP-Verbindung neu aufgebaut und nach dem Senden auch gleich wieder getrennt. Geplant ist aber, dass die Verbindung nur einmal hergestellt und dann natürlich auch gehalten wird…

Somit musste ich kurzerhand umdisponieren und bin auf eine andere Möglichkeit mittels Netcat ausgewichen. Dabei wird, wie hier schon zu lesen war, mittels der Option -e nach dem Verbinden ein Script gestartet. Die Kommunikation verläuft dabei über die Standard-Ein- und -Ausgabe. Jegliche Teile der Verbindung werden von Netcat geregelt, wodurch ich mich voll und ganz auf die KI konzentrieren kann.

Doch nun zum Wichtigsten: Die Strategie!
Ich habe in ein paar kurzen, manuellen Spielen ein paar Taktiken ausprobiert. Zur Zeit umgesetzt sind:

1. Liege ich im Rückstand, muss ich risikofreudiger werden.
2. Liege ich weit vorne, kann ich sicherer spielen.
3. Speichert mein Gegner selten, kann ich sicherer spielen

Doch irgendwie reicht mir das noch nicht aus für meinen Bot.
Wenn also jemand noch weitere Ideen hat, dann immer her damit Jeder Input ist willkommen!

Die Vorgaben dabei sind ganz einfach; der Bot muss schlussendlich mit einem Make-File gestartet werden können und auf einem Ubuntu 10.04 Rechner laufen. Insofern kann die Programmiersprache also fast frei gewählt werden. Der Spielablauf wird dabei vom Server wettbewerb.linux-magazin.de über ein für menschen-lesbares TCP-Protokoll gesteuert.

Das ganze Spiel an sich ist relativ einfach gehalten. Ein Bot kann solange Würfeln, wie er keine 6 wirft oder das Spiel nicht speichert. Alle Punkte werden dabei immer zusammengezählt.
Sobald jedoch eine 6 geworfen wird, so werden alle Punkte bis zum letzten Save wieder abgezogen, und der Spielzug ist beendet.
Es gilt also, seinem Bot soviel Intelligenz einzuhauchen, damit dieser das optimale Mittelmass zwischen “Roll” (würfeln) und “Save” (speichern) findet.

Meinen Bot habe ich in Bash-Script begonnen und bin bislang damit ganz gut gefahren, da es sich über ein virtuelles Device ohne viel Programmieraufwand problemlos via TCP mit einem beliebigen Server kommunizieren lässt:

1

echo "alea iacta est" > /dev/tcp/$server/$port

Wer es noch einfacher will, und sich überhaupt nicht um jegliche Kommunikation zwischen Server und Bot bemühen will, der kann sein Script via Netcat starten und alle Kommandos über die Standard-Ein- und Ausgabe verwalten:

1

nc -e bot.sh wettbewerb.linux-magazin.de 3333

Auch wer auf etwas komplexeres Zurückgreifen will, der findet auf der offiziellen Webseite bereits Beispiele in PHP und Ruby, welche man nur noch mit Intelligenz füllen muss.

Ein weiteres sehr gutes PHP-Beispiel gibt es auch auf blog.oncode.info, dank welcher Seite ich überhaupt auf den Wettbewerb aufmerksam geworden bin.

Noch bis zum 12. September ist das Spiel für jedermann und jedefrau geöffnet! Mögen die Würfel entscheiden

Nun das ist so meine Geschichte.

Und nun zu euch!
Folgend kannst du die Distributionen auswählen, die du regelmässig verwendest. Interessant wäre auch noch, wieso ausgerechnet diese?

Sollte ich eine vergessen habe, sorry

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?

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

Zu den besten Neuerungen aus meiner Sicht zählt klar die verbesserte Bootzeit! Auch wurden neue Benachrichtigungen für Updates etc eingeführt.

Weiter ist der Kernel 2.6.28.8, Gnome 2.26, KDE 4.2.1, OpenOffice 3.0.1 und ein angeblich optisch aufgebesserter Loginscreen vorhanden.

Doch sind das genug Gründe für einen Wechsel?

Ich für meinen Teil, werde wechseln

Einer Firma hilft ein solcher Test zum Bestätigen, dass das eigenen Netzwerk (fast) sicher ist oder um eben Sicherheitslücken aufzudecken.

Jedoch hat nicht jeder das Wissen oder das Geld um einen solchen Test durchzuführen, doch Sicherheit sollte jeder geniessen können. Um dieses Problem auszuhebeln gibt es fix fertige Scanner, welche ein komplettes Netzwerk auf die neusten Exploits prüfen.

Welche Lücken gibt es?

Einer der besten dieser Scanner ist Nessus. Dieser ist in einer gratis Version verfügbar. Der Scanner erhält nach einer Gratis-Registrierung alle 24 Stunden die neusten Exploits und Sicherheitslücken und kann diese bei einem neuen Scan auch gleich einsetzen.

Nessus gibt es als Server und als Client. Man hat somit auch die Möglichkeit Nessus auf einem Server zu installieren und sich dann mit dem Client darauf einzuloggen.

Für die Installation habe ich ein kleines Script erstellt, welches alle Vorgänge beinahe automatisch durchführt. Oder man führt die folgenden Schritte aus:

Zuerst müssen wir Nessus installieren:

sudo apt-get install nessus nessusd

Nun müssen wir einen User hinzufügen:

sudo nessus-adduser

Hier muss man einen Usernamen eingeben, mit welchem man sich auf dem Nessus-Server einloggt. Bei Authentication kann man einfach ENTER drücken. Nach der Eingabe des Passwortes werden die Regeln definiert. Hier kann man getrost die Standardeinstellungen stehen lassen und nach einer kurzen Wartezeit mit Strg + D die Konfiguration abschliessen.
Damit man immer die aktuellen Exploits erhält, muss man sich gratis registrieren. Dies kann man hier machen: http://www.nessus.org/plugins/index.php?view=register

nessus-fetch --register $code

Nun kann man seine Plugins updaten:

sudo nessus-update-plugins

und schlussendlich den Server starten:

sudo /etc/init.d/nessusd start

Nun fügen wir noch einen Eintrag hinzu, damit der Server beim Starten des PC automatisch auch startet:

sudo update-rc.d nessusd defaults

Nun können wir Nessus starten. Das starten dauert ein bisschen, da neben dem laden aller Plugins auch noch die neusten runtergeladen werden:

nessus

Nun haben wir Nessus installiert. Doch nach einem Scan wissen wir erst, wo es eine Lücke gibt, nicht aber wie man sie ausnutzt.

Dazu haben wir das Metasploit Framework.

Die Exploits

Leider ist Metasploit nicht auf den Packetservern verfügbar. Deshalb muss man sich die Installation von hier besorgen.

Zur Installation kann man wieder mein Script verwenden oder folgende Anleitung verwenden.

Zuerst brauchen wir das aktuelle Framework. Dieses ist gepackt in einem Archiv also müssen wir zuerst entpacken:

tar -xzf framework-*

Da Metasploit auf Ruby basiert, brauchen wir noch den passenden Ruby-Hintergrund:

sudo apt-get install ruby libruby libgtk2-ruby libglade2-ruby libopenssl-ruby -y sqlite3*

Nun erstellen wir einen Ordner:

sudo mkdir /opt/metasploit

Und verschieben unsere Daten in den Ordner:

sudo mv framework-X.X/* /opt/metasploit/

Das Framework selbst gibt es als GUI, Webservice oder Konsole. Aufgerufen werden diese mit folgenden Befehlen:

/opt/metasploit/msfgui
/opt/metasploit/msfweb
sudo /opt/metasploit/msfconsole

Der Server ist dann unter der URL http://localhost:55555 verfügbar. Es ist jedoch empfohlen, die Konsole zu verwenden, da nur da alle Funktionen verfügbar sind.

Wie es nun weiter geht, dass muss jeder selbst raus finden, da sogenannte “Hack-Anleitungen” (ob für gute oder schlechte Zwecke) illegal sind. Ich weiss nicht einmal, ob es erlaubt ist die folgenden zwei Links zu posten:

Tutorial Part 1: http://www.ethicalhacker.net/content/view/227/24/
Tutorial Part 2: http://www.ethicalhacker.net/content/view/238/24/

Alles was ich möchte, ist eine Software oder ein Dienst für einen Linux (Ubuntu)-Server, der mir, im Falle eines Ausfalls, eine eMail schickt. Und für das eine komplexe Software wie Nagios zu installieren, finde ich sinnlos.

Also habe ich mir selbst überlegt, wie ich das lösen könnte. Ich habe mir dazu die Software postfix und mailx geladen und installiert.

Postfix ist eine Mail-Software für Linux und mailx brauche ich, um über die Konsole eMails mittels Postfix zu versenden.

Installation

Die Installation ist schnell gemacht, jedoch ist es von Vorteil, wenn man sich ein bisschen auskennt, da die Konfiguration viele Möglichkeiten offen lässt.

Notification – der Mailaccount

Befor man mit der Konfiguration beginnt, muss man im Besitz eines geeigneten Mail-Accounts sein. Geeignet darum, da es Mail-Anbieter wie gmail gibt, welche die eMails von postfix nicht akzeptieren wollen. Ich habe mir dazu einen GMX-Account gemacht, von welchen ich dann meine Notifications erhalte.

Die Konfiguration

Zuerst muss man die passenden Module laden. Dies wären mailx, libsasl2-modules und schliesslich postfix. Nach dem installieren beginnt gleich die Konfiguration von postfix. Dies erfolgt anhand verschiedenen Fragen.

Die Konfiguration habe ich Anhand der Wiki-Anleitung im uu.de gemacht. Da diese Anleitung natürlich sehr allgemein gehalten, gehe ich folgend auf wichtige Schritte der Konfiguration ein.

• Als Einstatzzweck habe ich Satellite System gewählt, da mein Mailserver mich nur informieren und selbst keine Mails empfangen soll.
• Als Local Network trägt man localhost ein, damit nur der lokale Computer das Recht hat eMails über postfix zu senden.
• Unter SMTP relay Host trägt man den Mail-Server (mail.gmx.net) des Anbieters ein.
• Unter Where should mail for root go? sollte man die eMail-Adresse eintragen, welche im Fall eines Ausfalls informiert werden soll.

Bei mir war es der Fall, dass nicht alle Fragen bei der ersten Konfiguration aufgetaucht sind. Also habe ich mit dem Befehl sudo dpkg-reconfigure postfix die Konfiguration nochmal aufgerufen. Nun waren alle Fragen vorhanden.

Passwort für den SMTP-Server setzen

Nun setzen wir noch das Passwort, damit wir uns beim Mail-Server von GMX identifizieren können.

Dazu rufen wir folgende Datei auf:

/etc/postfix/main.cf

dieser Datei fügt man folgende Zeilen hinzu:

smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_password
sender_canonical_maps = hash:/etc/postfix/sender_canonical

Nun wird noch eine Datenbank generiert, in welcher postfix das Passwort nachschlagen kann:

Wir erstellen also mit folgendem Befehl eine neue Datei:

sudo touch /etc/postfix/sasl_password

In diese schreiben wir das Passwort nach folgendem Muster:

mail.gmx.net mail.gmx.net:passwort

Bis jetzt ist das aber erst eine Textdatei und noch keine Datenbank. Also generieren wir rasch eine Datenbank:

sudo postmap /etc/postfix/sasl_password

und starten noch postfix neu:

sudo /etc/init.d/postfix restart

Absender setzen

Damit GMX nun glaubt, dass man wirklich ein richtiger Mailserver ist muss man noch eine Absenderadresse stetzen.

Dies klingt wahrscheindlich komplizierter als es ist. Wir erstellen einfach eine Datei /etc/postfix/sender_canonical und schreiben da den Absender nach folgendem Muster rein:

benutzer email.adresse@gmx.net

Nun heisst es nochmal eine Datenbank erzeugen und den Server wieder neustarten:

sudo postmap /etc/postfix/sender_canonical
sudo /etc/init.d/postfix restart

Und schon ist postfix bereit! War doch ganz einfach

Das Starten

Nun muss man nur noch einen Cron-Job generieren, der zum Beispiel alle fünf Minuten den oder die gewünschten Server pingen. Wenn der Server nun nicht erreichbar sein sollte, so kann man über das Terminal mit

mail -s "testbetreff" email@addresse.de < textdatei.txt

ein eMail an eine beliebige Person senden.

Bei mir pingt ein Cron-Job alle 5 Minuten meine Server mit folgendem Befehl:

ping -c 1 compr00t.5x.to > /dev/null

Zum Schluss

Das ganze läuft nun so auf einem Linux-Server und meldet mir immer alle 5 Minuten, wenn ein von mir überwachter Computer amok läuft!