Bits, Bytes and my 5 cents » OS

Lync speichert Standort nicht

Patrick — Fri, 27 Jan 2012 09:04:25 +0000

Bei uns der Firma setzen wir seit kurzem Lync als Kommunikationsmittel ein. Eigentlich eine ganz coole Software, mit vielen Funktionen und Goodies. Unter anderem wäre da auch eine Funktion, welche den Standort anzeigen kann. Einmal definiert, sollte Lync erkennen können, wo ich mich gerade befinde und zeigt das auch sogleich an. Praktisch ist diese Funktion vor allem deshalb, weil bei uns in der Firma aus dem Büro, beim Kunde vor Ort oder auch von zu Hause aus gearbeitet werden kann. Somit entfällt das lästige Nachfragen, wo sich eine bestimmte Person gerade befindet.
Doch das gilt natürlich nur, wenn es denn auch funktionieren würde!

Aus mir zuerst unbekannten Gründen, war es mir nie möglich, einen Standort einzugeben. Ich konnte zwar etwas eintippen, jedoch hat Lync das nicht gespeichert. Mehr zufällig als gewollt, habe ich dann aber entdeckt, dass das Problem nur besteht, solange mein Virenschutz, Kaspersky aktiv ist.

Also habe ich mal alles, von Datei-Anti-Virus, bis Zugriffskontrolle deaktiviert und Eines nach dem Anderen wieder aktiviert, wodurch ich das Problem auf den Web-Anti-Virus eingrenzen konnte. Genau! Auch ich hätte gedacht, es läge an der Firewall, aber manche Wege sind unergründlich…
Also habe ich zuerst einmal in dessen Einstellungen die benötigten Adressen zugefügt:

Ausserdem habe ich Kaspersky klar gemacht, dass ich der Applikation vertrauen möchte, indem ich unter Schutz > Vertrauenswürdige Zonen den Communicator eingetragen habe:

Und siehe da, von da an konnte auch ich meinen Standort teilen:

Lizenz Server für abgeschottete Netzwerke

Patrick — Thu, 19 Jan 2012 06:00:44 +0000

Ein Lizenzserver ist unter Windows eine ganz einfache Sache. Unter Windows 2008 sogar noch einfacher als unter 2003 und trotzdem kann er viel Arbeit abnehmen. So hilft er zum Beispiel wenn man aus Gründen, welche auch ich nicht verstehe, noch Vista einsetzt, und zwar in einer komplett abgeschotteten Umgebung.
Dies würde heissen, da die Maschinen selbst kein Internet haben, dass jede Maschine per Telefon aktiviert werden müsste. Dies braucht nicht nur Zeit, sondern auch Nerven, da das Aktivieren via Telefon alles andere als Produktiv ist!

Also bietet sich ein Lizenzserver an. Dieser wird mit Internetverbindung hochgezogen, KMS aktiviert und von Microsoft validiert und dann in die geschützte Umgebung verschoben. Die Vista Maschinen aktivieren ihren Schlüssel von nun an nur noch über den Lizenzserver. So braucht keine der Maschinen, weder Client noch Server im laufenden Betrieb je wieder eine Internetverbindung.

Installiert ist das ganz einfach. Unter Windows 2003 lädt man sich den Key Management Service 1.1 für Server 2003 passend zur Architektur herunter und installiert diesen.
Danach wird ein Volumekey von Microsoft benötigt für Windows 2003 oder Windows 2008 mit der Option Vista als KMS zu aktivieren. Ist auch dieser aufgetrieben, so kann über das Kommando slmgr die ganze Installation durchgeführt werden. Zuerst wird der Key eingepflegt:

slmgr /ipk xxxxx-xxxxx-xxxxx-xxxxx-xxxxx

Und dann noch bei Microsoft validiert:

slmgr /ato

Sind beide Vorgänge erfolgreich, so kann die Maschine in die geschützte Umgebung verschoben werden. Idealerweise läuft auf der selben Maschine auch gleich noch ein AD / DNS, dann werden auch gleich noch die passenden DNS-Einträge generiert.

Auf allen Vista Maschinen kann nun der folgende Key eingetragen werden:

Windows Vista Business – YFKBB-PQJJV-G996G-VWGXY-2V3X8
Windows Vista Business N – HMBQG-8H2RH-C77VX-27R82-VMQBT
Windows Vista Enterprise – VKK3X-68KWM-X2YGT-QR4M6-4BWMV
Windows Vista Enterprise N – VTC42-BM838-43QHV-84HX6-XJXKV

Dies sind nur Standardkeys, welche dem Lizenzserver zur Erkennung dienen.

Auf dem Lizenzserver wiederrum kann man nun mit slmgr wiederrum sehen, wie viel Requests man schon bekommen hat:

slmgr /dli

Sobald der Count die Zahl 25 erreicht hat, also sobald 25 Maschinen sich aktivieren wollen, werden die Maschinen validiert. Vorher, und fragt mich jetzt ja nicht nach dem Sinn dahinter, gibt der Lizenzserver immer einen Fehler zurück. Wer also weniger als 25 Maschinen hat, der muss noch ein paar Virtuelle Maschinen oder ähnliches dazu aktivieren.

Das könnte dich auch interessieren:

Windows session credentials cannot be used to log into this server Ist der ESX-Server ans AD angebunden, so liegt es ja...
Syslog Server für ESXi Nach dem ich entdeckt hatte, dass der ESX so intelligent...

Apache mit LDAP durch XAMPP

Patrick — Wed, 11 Jan 2012 21:26:42 +0000

XAMPP ist ja eine ganz einfache Variante, wenn man schnell etwas testen muss in PHP, Apache oder MySQL. Und so habe ich auch wieder zu XAMPP gegriffen, als ich ein PHP Script mit dem LDAP Modul von PHP testen musste.
Doch irgendwie will das nicht ganz so klappen. Nachdem ich XAMPP von der Webseite heruntergeladen und entpackt hatte, musste ich erstmal das LDAP Plugin laden. Dazu gilt es in der PHP.ini den passenden Eintrag einzukommentieren. Die Datei kann über das Kontrollpanel geöffnet werden:

Danach muss der folgende Eintrag einkommentiert werden:

;extension=php_ldap.dll

Versucht man danach den Apache zu starten, so wird sich dieser gleich wieder mit einer Fehlermeldung verabschieden. Reklamiert wird, dass die Datei libsasl.dll nicht gefunden werden konnte. Doch ein simples Kopieren kann hier Abhilfe schaffen. So muss die Datei libsasl.dll aus dem Ordner php in den Ordner apache/bin kopiert werden, worauf der Service auch sogleich erfolgreich gestartet werden kann:

Das könnte dich auch interessieren:

Mehr Sicherheit durch mod_security Mod_Security ist eine Software Firewall, welche kontrolliert, welche Eingaben auf...
Mehr Sicherheit durch OpenVPN Sicherheit wird ein immer wichtigeres Thema in der IT. Klar...

Asus’ Ultrabook UX31: keine CD / DVD, kein LAN, kein Linux

Patrick — Fri, 06 Jan 2012 09:51:53 +0000

Ultrabooks sollen ja die neue Generation von Computern darstellen. Schnell, klein und dünn sollen sie sein und ein Pendant zu all den computerähnlichen Tablets und Smartphones werden.
Persönlich gefällt mir die Idee der Ultrabooks sehr gut. Ich war schon immer ein Fan von kleinen, dünnen und leichten Notebooks. Doch ein Macbook Air, für mich das Vorbild eines leichten und dünnen Notebooks, wollte ich mir nie gönnen, da für mich die Preis- / Leistung nicht stimmt. Und da kommen Ultrabooks doch irgendwie sehr gelegen!
Doch da fragt man sich doch gleich, wenn die Dinger schon so dünn sind, auf was muss man denn verzichten? Irgendwo muss man ja Platz gespart haben.

Nun meistens spart man bei der Grafik. Anstatt einer Grafikkarte, gibt es nur noch integrierte Grafik, doch dies ist ja bereits bei vielen aktuellen Laptops der Fall.
Weiter verzichtet man auf ein optisches Laufwerk. Doch was, wenn man mal eine CD hat? Sind CD / DVD bei Notebooks überhaupt noch zeitgemäss?

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

Als ich mich dann so im Markt der Ultrabooks umgeschaut habe, gefiel mir ein bestimmtes Teil ganz besonders: Das Asus Ultrabook UX31!
Sieht echt schick aus, ist dünn und leicht und hat trotzdem Power. Doch wo ist da der LAN-Anschluss verbaut? Genau, nirgends! LAN gibt es nur noch über USB, ganz wie es beim Air der Fall ist. Oder aber Internet via WLAN. Und da stellt sich mir wieder die Frage, versucht man hier das kabel-gebundene Netzwerk ein für alle mal durch die drahtlose Variante zu ersetzen? Ist es überhaupt noch nötig, dass künftige Notebooks LAN-Anschlüsse haben?

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

Was ich persönlich sehr schade finde, zu Beginn der Netbooks hat sich Linux ja einigermassen etablieren können, wurde dann aber mit steigender Leistung der Dinger durch Windows ersetzt. Da die Ultrabooks schon mit genügend Leistung ausgeliefert werden, gehört Windows bereits zum Standard!
Natürlich besteht immer noch die Möglichkeit Linux selbstständig zu installieren, doch mit voller Unterstützung kann man leider nicht rechnen, vie Golem.de bereits testete:

Weder der Bereitschaftsmodus (S3 oder Suspend-To-RAM) noch der Ruhezustand (S4 oder Suspend-To-Disk) funktionierte mit Ubuntu 11.10 samt Kernel 3.0.0.12 korrekt.

In meinen Augen sehr schade, dass Asus es hier verpasst hat, auf den “Linux-Zug” aufzuspringen, denn so finde ich leider keinen Kaufgrund! Auf das Andere hätte ich noch verzichten können…

Das könnte dich auch interessieren:

LVM für Linux einrichten LVM ist eine andere Art von Festplatten Management, ähnlich einem...
Backup und Restore mit Linux Von den bisher vorgestellten Themen in LPIC 201 ist das...
Linux von Acer verbannt Da der Acer Aspire One von einer Kollegin nicht mehr...

host_name ändern in Nagios: Bug?

Patrick — Tue, 20 Dec 2011 07:00:48 +0000

In Nagios ist es nicht so einfach, wenn ein Server umbenannt wird…
Ein Neuling in Nagios wird intuitiv in die Konfigurationsdatei XYZ.cfg gehen und darin den neuen Namen unter “host_name” eintragen. Dann noch ein Reload des Daemons und… nichts hat sich geändert! Noch immer erscheint der alte Name in der Webseite.
Nochmals ein Blick in die Konfigurationsdatei; da ist alles richtig eingetragen. Die Seite wird nochmals neu geladen und weil immer noch der alte Name da steht, beginnt man an der eigenen Sehkraft zu zweifeln!

Die alteingesessenen Nagios-Admins kennen das Problem: Es ist keines, es ist ein Feature – so habe ich mich von der Community belehren lassen!

Es hängt zusammen mit einer Statusdatei, welche Nagios anlegt, damit nach einem Neustart des Daemons nicht immer alle Checks ohne Daten dastehen und erst alles wieder aufgebaut werden muss. Deshalb wird darin der letzte Zustand gespeichert und dann auch abgerufen.
Wieso dabei auch der Hostname gespeichert und aus dieser Datei anstelle der Konfigurationsdatei ausgelesen wird, kann ich mir leider nicht erklären. Aber eben: Das ist ein Feature, kein Bug!

Die Lösung des Problems liegt darin, dass der Name nicht nur in der offiziellen Konfigurationsdatei, sondern auch in der Statusdatei unter var/retention.dat angepasst wird. Bevor das geschieht, muss aber der Nagios-Daemon gestoppt werden.

Also (der Pfad der Nagios-Installation bitte anpassen):

/etc/init.d/nagios stop
vi /usr/local/nagios/var/retention.dat
/etc/init.d/nagios start

Verzweifelt nicht an euer Sehkraft, es ist wirklich so

Das könnte dich auch interessieren:

Unbekannte Systeme in Nagios Die Nagios Status Map ist ja eine ganz feine Sache,...
Notification von Nagios ans iPhone Auf der Suche nach einer Lösung, wie ich die Notifications...
Windows Updates prüfen mit Nagios Um unserer Server optimal überwachen zu können, habe ich eine...
Nagios als Inventory-Lösung Heute bin ich über ein interessantes Script gestossen, welches aus...
NRPE Module installieren Aktuell arbeite ich an einer Lösung, um mittels Nagios zu...

SSH von ESXi absichern

Patrick — Fri, 02 Dec 2011 07:30:18 +0000

Vor kurzem habe ich ja bereits über Syslog geschrieben. Jeder der schon mal einen Server in den weiten des Internets betrieben hat (damit meine ich nicht zu Hause im eigenen Netzwerk), der weiss, wie schnell es geht, bis die ersten Bots und Kiddies mit endlosen Versuchen probieren, das SSH-Passwort zu knacken.
Für Linux-Distributionen wie Ubuntu, Debian, RedHat oder was auch immer gibt es unzählige Tools und Applikationen, welche helfen entweder den SSH-Zugriff zu verstecken, oder aber zu verteidigen.

Beides gibt es leider nicht bei meinem ESXi Server. Noch nicht mal eine anständige iptable oder hosts.deny sind vorhanden, geschweige denn von einer Firewall, wie es bei ESX Standard ist.

Um jedoch mal zu sehen, wie viele Personen versuchen, mein SSH zu knacken, habe ich ein einfaches kleines Script für Nagios geschrieben.

Ich weiss es kann noch viel optimiert werden dabei, doch es erfüllt seinen Zweck:

#!/bin/bash

# ####################################################################
# Check Syslog /var/log/SPLVS002.log for Brute Force Attacks via SSH
# by Patrick Schmid
# Version 1.0
######################################################################

export STATE_OK=0
export STATE_WARNING=1

time=`date +%H.%M.%S |cut -d'.' -f1`
time=`echo $time|sed 's/^0*//'`
time2=$(( $time - 1))
time3=$(( $time - 2))

if [ $time -lt 10 ]; then
        time=0$time
fi

if [ $time2 -lt 10 ]; then
        time2=0$time2
fi

if [ $time3 -lt 10 ]; then
        time3=0$time3
fi

compare=`tail -300 /var/log/SPLVS002.log |grep "from" |grep "root" |grep "attempt" | cut -d' ' -f3`
compare=`echo $compare | cut -d' ' -f1`

if [ $compare -lt 10  ]; then
        attackers=`tail -300 /var/log/SPLVS002.log |grep "from" |grep "root" |grep "attempt" | cut -d' ' -f4,14 |cut -d':' -f1,2,3 |sed -e 's/://' | tee -a |sed -e 's/://' |tee -a |grep "^$time\|^$time2\|^$time3" |cut -d' ' -f2 |sort |uniq`
        computers=`tail -300 /var/log/SPLVS002.log |grep "from" |grep "root" |grep "attempt" | cut -d' ' -f4,14 |cut -d':' -f1,2,3 |sed -e 's/://' | tee -a |sed -e 's/://' |tee -a |grep "^$time\|^$time2\|^$time3" |cut -d' ' -f2 |sort |uniq |wc -l`
        attemps=`tail -300 /var/log/SPLVS002.log |grep "from" |grep "root" |grep "attempt" | cut -d' ' -f4,14 |cut -d':' -f1,2,3 |sed -e 's/://' | tee -a |sed -e 's/://' |tee -a |grep "^$time\|^$time2\|^$time3" |cut -d' ' -f2 |sort |wc -l`
else
        attackers=`tail -300 /var/log/SPLVS002.log |grep "from" |grep "root" |grep "attempt" | cut -d' ' -f3,13 |cut -d':' -f1,2,3 |sed -e 's/://' | tee -a |sed -e 's/://' |tee -a |grep "^$time\|^$time2\|^$time3" |cut -d' ' -f2 |sort |uniq`
        computers=`tail -300 /var/log/SPLVS002.log |grep "from" |grep "root" |grep "attempt" | cut -d' ' -f3,13 |cut -d':' -f1,2,3 |sed -e 's/://' | tee -a |sed -e 's/://' |tee -a |grep "^$time\|^$time2\|^$time3" |cut -d' ' -f2 |sort |uniq |wc -l`
        attemps=`tail -300 /var/log/SPLVS002.log |grep "from" |grep "root" |grep "attempt" | cut -d' ' -f3,13 |cut -d':' -f1,2,3 |sed -e 's/://' | tee -a |sed -e 's/://' |tee -a |grep "^$time\|^$time2\|^$time3" |cut -d' ' -f2 |sort |wc -l`
fi

[ "$attackers" ] && echo -e "$attemps attemps from $computers attackers\n$attackers"
[ "$attackers" ] || echo "No Attack running"

[ "$attackers" ] && exit $STATE_WARNING
[ "$attackers" ] || exit $STATE_OK

Und schon sieht man in Nagios selbst, was so abgeht:

So dann weiter im Konzept! Es gibt zwar keine Möglichkeit, Angreifer aussperren oder ähnliches, jedoch aber kann man verhindern, dass das Passwort erraten werden kann, indem man das Login mit einem zusätzlichen Zertifikat schützt. Wie das geht, lest ihr in den folgenden Zeilen!

Zuerst wird ein Key generiert, mit ssh-keygen.
Nun kann der Public-Key kopiert werden, denn dieser muss auf den ESX wie folgt eingefügt werden:

mkdir /.ssh
touch /.ssh/authorized_keys
chmod 0600 -R /.ssh
echo "ssh-rsa KEY_HIER_EINFÜGEN" >> /.ssh/authorized_keys

Nun kann man das Login schon mal prüfen. Hier sollte man bereits mit dem Key einloggen können.

Jetzt wird das ganze noch abgesichert, damit es auch einen Reboot übersteht. Einfach den obigen Part in die Datei /etc/rc.local einfügen und abspeichern.
Und zu guter Letzt wird noch das Login ohne Zertifikat deaktiviert. Dazu wird in der Datei /etc/inetd.conf den beiden Punkten “ssh” der Parameter -s angefügt:

ssh      stream   tcp   nowait   root   /sbin/dropbearmulti   dropbear ++min=0,swap,group=shell -s -i -K60
ssh      stream   tcp6  nowait   root   /sbin/dropbearmulti   dropbear ++min=0,swap,group=shell -s -i -K60

Von nun an ist ein Login nur noch mit Zertifikat möglich, wodurch auch die lästigen Bots ausgebremst werden.

Das könnte dich auch interessieren:

Syslog Server für ESXi Nach dem ich entdeckt hatte, dass der ESX so intelligent...
ESXi sichern auf FTP Vor einiger Zeit hatte ich die Aufgabe ein Backup-Konzept für...
Vmware Image für ESXi aufbereiten Für eine Analyse gab es diese Woche eine Installation von...
DNS-320 mit fun_plug zu SSH Ganz cool an meinem NAS DNS-320 ist die Funktion des...
NAT konfigurieren unter ESX(i) NAT ist so eine Sache. Unter Vmware Workstation sehr einfach...

Syslog Server für ESXi

Patrick — Thu, 01 Dec 2011 14:30:10 +0000

Nach dem ich entdeckt hatte, dass der ESX so intelligent ist und seine Logs standardmässig auf einer RAM-Disk speichert, musste natürlich eine andere Lösung her. Kann ja nicht sein, dass die Logs nach einem Ausfall einfach nicht mehr vorhanden sind.
Somit habe ich mich für eine zentrale Logspeicherung mit Syslog entschieden.

Da ich sowas noch nie eingerichtet hatte, war ich mir nicht ganz sicher, was auf mich zu kommen würde. Nun aber kann ich sagen, schreckt nicht davor zurück! Das Einrichten geht schnell und einfach und der Gewinn daraus ist enorm.

Auf meinem Ubuntu Server habe ich mich für syslog-ng entschieden, welches problemlos über die Paketquellen installiert werden kann:

apt-get install syslog-ng

Nun muss die Konfiguration unter /etc/syslog-ng/syslog-ng.conf angepasst werden.
Eingefügt habe ich die folgenden Punkte für jeweils einen ESX und einen normalen Ubuntu-Server:

source s_udp
{
        udp(port(514));
};

destination d_server1 {
        file("/var/log/server1.log");
};

filter f_server1 {
        host("192.168.1.45");
};

log {
        source(s_udp);
        filter(f_server1);
        destination(d_server1);
};

destination d_server2 {
        file ("/var/log/server2.log");
};

filter f_server2 {
        host("192.168.1.23");
};

log {
        source(s_udp);
        filter(f_server2);
        destination(d_server2);
};

Somit sei es den beiden Hosts mit der Adresse 192.168.1.23 und 192.168.1.45 über den Port UDP/514 erlaubt, Daten an den Syslog-Server zu senden, welche jeweils unter /var/log/server1.log und server2.log abgelegt werden.

Noch neustarten und gut ist:

/etc/init.d/syslog-ng restart

Nun geht es weiter auf den zu überwachenden Servern!
Hier fügt man folgende Zeile in die Konfiguration unter /etc/syslog.conf ein:

*.* @192.168.1.25

192.168.1.25 ist dabei natürlich die IP des Syslog-Servers. Aktuell wird hier alles geloggt, was so auf der Maschine abgeht. Wer das ganze noch genauer spezifizieren will, der findet entsprechende Parameter bei Google.
Auch hier ist noch ein Neustart nötig und schon sind die entsprechenden Infos auf dem Syslog-Server ersichtlich:

/etc/init.d/sysklogd restart

Auf dem ESX Server kann der Syslog-Server über den vSpehre-Client gesetzt werden. Einfach unter “Configuration” > “Advanced Settings” > “Syslog” > “remote” IP und Port eintragen.

Und nun dürft ihr auch schon all die Kiddies und Bots bewundern, welche versuchen euer SSH-Passwort zu knacken

Nov 30 12:17:17 server1 sshd[11775]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=180.227.218.245  user=root
Nov 30 12:17:19 server1 sshd[11775]: Failed password for root from 180.227.218.245 port 34035 ssh2
Nov 30 12:17:22 server1 sshd[11777]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=180.227.218.245  user=root
Nov 30 12:17:23 server1 sshd[11777]: Failed password for root from 180.227.218.245 port 34311 ssh2
Nov 30 12:17:26 server1 sshd[11779]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=180.227.218.245  user=root
Nov 30 12:17:28 server1 sshd[11779]: Failed password for root from 180.227.218.245 port 34525 ssh2
Nov 30 12:17:30 server1 sshd[11784]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=180.227.218.245  user=root
Nov 30 12:17:33 server1 sshd[11784]: Failed password for root from 180.227.218.245 port 34770 ssh2
Nov 30 12:17:35 server1 sshd[11795]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=180.227.218.245  user=root
Nov 30 12:17:37 server1 sshd[11795]: Failed password for root from 180.227.218.245 port 35037 ssh2
Nov 30 12:17:39 server1 sshd[11800]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=180.227.218.245  user=root
Nov 30 12:17:42 server1 sshd[11800]: Failed password for root from 180.227.218.245 port 35313 ssh2
Nov 30 12:17:44 server1 sshd[11805]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=180.227.218.245  user=root
Nov 30 12:17:47 server1 sshd[11805]: Failed password for root from 180.227.218.245 port 35591 ssh2
Nov 30 12:17:49 server1 sshd[11807]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=180.227.218.245  user=root
Nov 30 12:17:51 server1 sshd[11807]: Failed password for root from 180.227.218.245 port 35809 ssh2
Nov 30 12:17:54 server1 sshd[11842]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=180.227.218.245  user=root
Nov 30 12:17:56 server1 sshd[11842]: Failed password for root from 180.227.218.245 port 36091 ssh2
Nov 30 12:17:58 server1 sshd[11848]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=180.227.218.245  user=root
Nov 30 12:18:00 server1 sshd[11848]: Failed password for root from 180.227.218.245 port 36361 ssh2
Nov 30 12:18:02 server1 sshd[11850]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=180.227.218.245  user=root

Wer auch dem Abhelfen will, der soll sich mal das Tool denyhosts ansehen! Ansonsten ein sicheres Passwort, Zertifikate oder was ihr gerade lustig seid. Ideen gibts genug!

Das könnte dich auch interessieren:

ESXi sichern auf FTP Vor einiger Zeit hatte ich die Aufgabe ein Backup-Konzept für...
Vmware Image für ESXi aufbereiten Für eine Analyse gab es diese Woche eine Installation von...
Windows session credentials cannot be used to log into this server Ist der ESX-Server ans AD angebunden, so liegt es ja...
DNS-320 mit fun_plug zu SSH Ganz cool an meinem NAS DNS-320 ist die Funktion des...
NAT konfigurieren unter ESX(i) NAT ist so eine Sache. Unter Vmware Workstation sehr einfach...

ESXi sichern auf FTP

Patrick — Tue, 08 Nov 2011 10:37:34 +0000

Vor einiger Zeit hatte ich die Aufgabe ein Backup-Konzept für einen ESXi-Server umzusetzen. Zur Verfügung dazu stand mir der Server selbst und Speicherplatz, welcher via FTP angesprochen werden kann.
In Verbindung mit ESX(i) habe ich zum Sichern der virtuellen Maschinen natürlich auf ghettoVCB zurückgegriffen, ein simples Script aus der Community rund um Vmware und ESXi:

This script performs backups of virtual machines residing on ESX(i) 3.5/4.x+/5.x servers using methodology similar to VMware’s VCB tool. The script takes snapshots of live running virtual machines, backs up the master VMDK(s) and then upon completion, deletes the snapshot until the next backup. The only caveat is that it utilizes resources available to the Service Console of the ESX server or Busybox Console (Tech Support Mode) of the ESXi server running the backups as opposed to following the traditional method of offloading virtual machine backups through a VCB proxy.

Das Script entspricht also einer freien Variante des VCB Tools von Vmware. Gesichert wird, indem das Script zuerst einen Snapshot der entsprechenden Maschine auslöst und diesen dann weg kopiert und wieder löscht. Somit wird die zu sichernde Maschine weder in ihrer Performance noch im Betrieb gestört oder beeinträchtigt. Hier zeigt sich auch schon der unschlagbare Vorteil von einem Backup auf der Ebene vom Virtualisierungsserver!

Eingerichtet ist das ganze relativ schnell und unkompliziert, die entsprechenden Dateien gibt es von github. Als einzige aus dem Archiv wird die Datei ghettoVCB.sh benötigt, welche auch auf den ESX kopiert werden muss. Hier gilt zu beachten, die Datei sollte auf dem datastore abgelegt werden, da alle anderen Dateien nach einem Reboot nicht mehr verfügbar sind… Und fragt mich ja nicht nach dem Sinn dahinter!

Konfiguriert wird das ganze über die ersten paar Zeilen der Datei. Hier kann zum Beispiel eingestellt werden, wohin gesichert wird, wie viele Sicherungen behalten werden, ob die VM’s dafür heruntergefahren werden sollen und noch ganz viel mehr. Schaut euch dazu am besten mal unter diesem Link den Punkt “Configurations” an, da wird alles verständlich erklärt. Meine Konfiguration sieht so aus:

# directory that all VM backups should go (e.g. /vmfs/volumes/SAN_LUN1/mybackupdir)
VM_BACKUP_VOLUME=/vmfs/volumes/datastore1/backup/

# Format output of VMDK backup
# zeroedthick
# 2gbsparse
# thin
# eagerzeroedthick
DISK_BACKUP_FORMAT=thin

# Number of backups for a given VM before deleting
VM_BACKUP_ROTATION_COUNT=1

# Shutdown guestOS prior to running backups and power them back on afterwards
# This feature assumes VMware Tools are installed, else they will not power down and loop forever
# 1=on, 0 =off
POWER_VM_DOWN_BEFORE_BACKUP=0

# enable shutdown code 1=on, 0 = off
ENABLE_HARD_POWER_OFF=0

# if the above flag "ENABLE_HARD_POWER_OFF "is set to 1, then will look at this flag which is the # of iterations
# the script will wait before executing a hard power off, this will be a multiple of 60seconds
# (e.g) = 3, which means this will wait up to 180seconds (3min) before it just powers off the VM
ITER_TO_WAIT_SHUTDOWN=3

# Number of iterations the script will wait before giving up on powering down the VM and ignoring it for backup
# this will be a multiple of 60 (e.g) = 5, which means this will wait up to 300secs (5min) before it gives up
POWER_DOWN_TIMEOUT=5

# enable compression with gzip+tar 1=on, 0=off
ENABLE_COMPRESSION=0

############################
####### NEW PARAMS #########
############################

# Disk adapter type: buslogic, lsilogic or ide
ADAPTER_FORMAT=buslogic

# Include VMs memory when taking snapshot
VM_SNAPSHOT_MEMORY=1

# Quiesce VM when taking snapshot (requires VMware Tools to be installed)
VM_SNAPSHOT_QUIESCE=0

##########################################################
# NON-PERSISTENT NFS-BACKUP ONLY
#
# ENABLE NON PERSISTENT NFS BACKUP 1=on, 0=off

ENABLE_NON_PERSISTENT_NFS=0

# umount NFS datastore after backup is complete 1=yes, 0=no
UNMOUNT_NFS=0

# IP Address of NFS Server
NFS_SERVER=172.51.0.192

# Path of exported folder residing on NFS Server (e.g. /some/mount/point )
NFS_MOUNT=/upload

# Non-persistent NFS datastore display name of choice
NFS_LOCAL_NAME=backup

# Name of backup directory for VMs residing on the NFS volume
NFS_VM_BACKUP_DIR=mybackups

############################
######### EMAIL ############
############################

# Email debug 1=yes, 0=no
EMAIL_DEBUG=0

# Email log 1=yes, 0=no
EMAIL_LOG=0

# Email SMTP server
EMAIL_SERVER=auroa.primp-industries.com

# Email SMTP server port
EMAIL_SERVER_PORT=25

# Email FROM
EMAIL_FROM=root@ghettoVCB

# Email RCPT
EMAIL_TO=auroa@primp-industries.com

Ist das Backup konfiguriert, so habe ich mir noch eine weitere Datei angelegt, welche die Namen aller Maschinen enthält, welche ich gerne sichern möchte. Einfach pro Zeile der Name einer VM und gut ist’s:

./backup # cat maschines_to_backup.txt
MACHINE1
MACHINE2
MACHINE5
MACHINE7

Nun kann man das Backup theoretisch schon starten. Einfach den folgenden Befehl verwenden:

./ghettoVCB.sh -f maschines_to_backup.txt

Doch was ist ein Backup schon, wenn man es manuell anschieben muss… Ausserdem sollte das Backup ja irgendwann auch noch auf den FTP verschoben werden. Also weiter im Programm.
Leider ist die FTP-Funktionalität vom ESXi sehr stark eingeschränkt. So etwas ähnliches wie rekursives Hochladen gibt es nicht. Auch das Erstellen von Ordnern auf dem ESXi ist so nicht möglich! Diese beiden Punkte und die Tatsache, dass ein Backupvolumen von über 50GB in einem komprimierten Archiv nur noch knapp 15GB gross ist, haben mich dazu bewegt zuerst alles mit tar zu packen und dann hochzuladen. Ich weiss: Schande auf mein Haupt, die ersten Stimmen werden schon laut werden, dass ein Backup niemals gepackt werden darf. Aber, da immer das letzte Backup noch auf dem ESXi selbst liegen bleibt, gibt es noch eine zusätzliche Sicherheit und ich konnte mich zu dem Schritt überwinden.
Also entstand noch ein weiteres, recht skurriles Skript. Aber es tut seinen Zweck:

/vmfs/volumes/datastore1/backup/ghettoVCB.sh -f /vmfs/volumes/datastore1/backup/maschines_to_backup.txt >> /vmfs/volumes/datastore1/backup/log/`date +"%d"-"%m"-"%y"`.log
date=$(`echo date +%F`).tar.gz
tar -cvz -f /vmfs/volumes/datastore1/backup/$date /vmfs/volumes/datastore1/backup/*
ftpput -u USER -p PASSWORD -P FTP_SERVER_IP /$date /vmfs/volumes/datastore1/backup/$date
rm /vmfs/volumes/datastore1/backup/$date

Das Script löst zuerst das Backup aus und schreibt auch gleich ein Log dazu. Danach wird alles in ein Archiv mit dem aktuellen Datum gepackt und via FTP hochgeladen. Ja, ich weiss, FTP ist nicht wirklich das beste Protokoll dazu. Es ist zwar schnell, jedoch bricht die Verbindung einmal ab, kann diese nicht wieder aufgenommen werden, sondern muss neu beginnen. Jedoch ist FTP der einzigste Zugriffsweg, den ich habe.

Nun, damit auch noch alles automatisch abläuft, wird das Backup in den Crontab integriert. Dazu fügen wir eine weitere Zeile an:

./backup # cat /var/spool/cron/crontabs/root
#syntax : minute hour day month dayofweek command
01 01 * * * /sbin/tmpwatch.sh
01 * * * * /sbin/auto-backup.sh #first minute of every hour (run every hour)
00 22 * * * /vmfs/volumes/datastore1/backup/daily.sh

Nun muss noch ein bisschen nacharbeit geleistet werden, damit alles reibungslos abläuft:

kill $(cat /var/run/crond.pid)
crond

Damit das Konzept auch noch einen Reboot überlebt, muss noch die /etc/rc.local ergänzt werden:

/bin/kill $(cat /var/run/crond.pid)
echo "00 22 * * * /vmfs/volumes/datastore1/backup/daily.sh" >> /var/spool/cron/crontabs/root
crond

Und somit wäre eine einfache und schnelle Backuplösung für die freie Version von Vmware’s ESX implementiert.
Muss eine Maschine innert einem Backupzyklus wiederhergestellt werden, so geschieht dies direkt ab dem ESXi selbst, da das letzte Backup da immer zwischengespeichert ist. Ansonsten kann ein beliebiger Zeitpunkt vom FTP heruntergeladen, entpackt und gestartet werden. Und mit der passenden Software kann auch das Disk-Format von Vmware geöffnet und so einzelne Dateien wiederhergestellt werden.

Das könnte dich auch interessieren:

Vmware Image für ESXi aufbereiten Für eine Analyse gab es diese Woche eine Installation von...

Windows session credentials cannot be used to log into this server

Patrick — Mon, 07 Nov 2011 10:24:18 +0000

Ist der ESX-Server ans AD angebunden, so liegt es ja auf der Hand, dass man die Option “Use Windows session credentials” aktiviert um eine Art Single Sign-On zu haben:

Interessanterweise aber will das Login so nicht funktionieren. Stets wird ein Fehler ausgegeben:

Interessant ist aber die Tatsache, sobald die Domäne ENCODINGIT\compr00t samt Passwort von Hand eingegeben wird, funktioniert das Login problemlos! Naja ganz unbekannt scheint das Problem nicht zu sein, denn in der VMware Knowledgebase konnte ich noch einen Artikel dazu ausgraben.

Dieser schiebt das Problem erst mal auf die IP-Adresse. Es wird beschrieben, das, solange der ESX-Server über die IP anstelle des Namens angesprochen wird, ein Reverse Lookup dafür eingerichtet werden muss. Klingt logisch… oder doch nicht?
Nun ja, also habe ich halt einen PTR eingerichtet, worauf ich die IP-Adresse auch zum Namen auflösen konnte, was mir ein NSLOOKUP bestätigte. Doch das Login wollte immer noch nicht klappen. Auch über den Hostnamen will das ganze nicht klappen, obwohl der A-Record problemlos aufgelöst und gepingt werden kann… Die Fehlermeldung ist neu die folgende:

Besonders amüsiert mich daran die Tatsache, dass die Maschine von welcher aus ich mich einlogge auch dem AD angebunden ist. Also kann mein Benutzername / Passwort gar nicht falsch sein!!

Wie es scheint gibt es neben mir noch genau 3 Andere, welche das gleiche Problem haben und so habe ich auch noch meinen Senf dazu gegeben:

Und nun hoffe auf eine Lösung…

Das könnte dich auch interessieren:

Paketquellen für Windows Die Lösung heisst Ninite und gibt es eigentlich schon seit...
Windows Updates prüfen mit Nagios Um unserer Server optimal überwachen zu können, habe ich eine...

SSL VPN gegen asoziale Firewalls

Patrick — Tue, 06 Sep 2011 13:35:35 +0000

Was tut man, wenn man hinter einer Firewall sitzt, die nur die Ports 80 und 443 geöffnet hat und trotzdem zum Beispiel mit vSphere über Port 902 eine Konsole öffnen, oder aber via Port 8080 auf eine Webseite zugreifen sollte. Genau, die Lösung ist VPN… Doch kein normales VPN!

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!