OpenVZ ist eine Virtualisierungstechnik für Linux. Damit lassen sich mehrere so genannte Virtual Private Server einrichten, die alle den Kernel und die Hardware des Host-Systems nutzen. Das Konzept ähnelt also anderen Techniken wie FreeBSD Jails und Solaris Zones. Auch als Gastsystem unterstützt OpenVZ ausschließlich Linux. Durch eine detaillierte Ressourcenaufteilung soll es möglich sein, sehr viele virtuelle Maschinen parallel auf einem physischen Computer zu betreiben, die alle streng voneinander isoliert sind. [golem.de]

Installieren kann man OpenVZ auf viele Linux basierten Betriebssysteme direkt aus den Paketquellen; im folgenden habe ich als Beispiel ein Debian (32bit) auf meinem DL380 G3 verwendet.

Zuerst müssen die passenden Kernel und Pakete installiert werden:

1

apt-get install linux-image-openvz-686 vzctl vzquota cstream

Leider ist das Tool vzdump nicht mehr in den Paketquellen enthalten, ist aber essentiell um eine virtuelle Maschine im laufenden Betrieb zu sichern:

1
2
3

cd /tmp/
wget http://download.openvz.org/contrib/utils/vzdump/vzdump_1.2-4_all.deb
dpkg -i vzdump_1.2-4_all.deb

Danach müssen in der Datei /etc/sysctl.conf folgende Punkte ergänzt werden:

1
2
3
4
5

net.ipv4.conf.default.proxy_arp = 0
net.ipv4.conf.default.forwarding=1
kernel.sysrq = 1
net.ipv4.conf.default.send_redirects = 1
net.ipv4.conf.eth0.proxy_arp=1

Nach dieser Anpassung darf nicht vergessen worden, die Konfiguration neu einzulesen:

1

sysctl -p

Nun muss der Server neugestartet werden, damit der OpenVZ-Kernel auch verwendet wird.

Nun ist OpenVZ soweit eingerichtet und die ersten “virtuellen” Maschinen können eingerichtet werden.
Hier zeigt sich aber auch schon die erste Schwäche von dieser Virtualisierungslösung, denn entgegen anderen Methoden lassen sich mit OpenVZ nur genau das Betriebssystem mit dem Kernel für Guests verwenden, welcher auch der Host benutzt.

Nun da alles eingerichtet ist, können die ersten Templates heruntergeladen werden.
Dazu müssen zuerst die Paketquellen angepasst werden:

1

echo "deb http://download.openvz.org/debian-systs lenny openvz" >> /etc/apt/sources.list

Das der neue Eintrag problemlos funktioniert, muss noch der passende Schlüssel nachgeladen werden:

1
2

wget -q http://download.openvz.org/debian-systs/dso_archiv_signing_key.asc -O- | apt-key add -
apt-get update

Nun sollten auch die passenden Templates in den Paketquellen gelistet werden:

1

apt-cache search openvz | grep vzctl

Damit ein Guest mit diesem Template eingerichtet werden kann, muss er vorher natürlich noch heruntergeladen und installiert werden:

1

apt-get install vzctl-ostmpl-debian-4.0-i386-minimal vzctl-ostmpl-debian-5.0-i386-minimal

Nun kann auch schon mit dem Einrichten des ersten Guests begonnen werden.

Die dazu zur Verfügung stehenden Templates sind unter /var/lib/vz/template/cache/ gelistet.
Hier zeigt sich nun ein Vorteil von OpenVZ gegenüber den alternativen Virtualisierungslösungen. Das einrichten eines neuen Guest dauert hier gerade mal ein paar Sekunden, während bei ESX oder Xen normalerweise stets die gesamte Installation durchlaufen werden muss. Das eintippen eines einfachen Befehls reicht schon aus:

1

vzctl create 1 --ostemplate debian-5.0-i386-minimal --config vps.basic

Erhält man danach eine Ausgabe, wie die folgende, so war die Aktion erfolgreich:

1
2
3

Creating VE private area (debian-5.0-i386-minimal)
Performing postcreate actions
VE private area was created

Nun hat man die Möglichkeit direkt Einstellungen für einen Guest vorzunehmen:

1
2
3
4
5
6
7
8
9
10
11

#Beim Booten aufstarten
vzctl set 1 --onboot yes --save
 
#Hostname setzen
vzctl set 1 --hostname tux1.linux.ch --save
 
#IP Adresse setzen
vzctl set 1 --ipadd 192.168.0.1 --save
 
#DNS Server setzen
vzctl set 1 --nameserver 145.253.2.75 --nameserver 213.191.92.86 --save

Alle nun gemachten Einstellungen werden in der Datei /etc/vz/conf/1.conf gespeichert.

Nun kann der Guest das erste mal gestartet und gleichzeitig auch noch das Rootpasswort angepasst werden:

1
2

vzctl start 1
vzctl exec 1 passwd

Will man den Guest direkt auf der Kommandozeile ansprechen, so kann dies entweder per SSH oder direkt über den Host passieren. Dazu kann folgendes Kommando verwendet werden:

1

vzctl enter 1

Eine List mit allen virtuellen Maschinen erhält man mit dem Befehl vzlist:

1

vzlist -a

Weitere Informationen bekommt man durch die Manpages:

1

man vzctl

oder dem offiziellen Wiki

Was ich bisher noch nicht finden konnte ist eine Möglichkeit mit vzctl set 1 … den Guest zu einer dynamischen IP Adresse zu zwingen.

Insgesamt ist es eine gute Möglichkeit um schnell und unkompliziert zu virtualisieren, jedoch wer viele Ansprüche hat und nicht immer das selbe Betriebssystem / die selbe Distribution verwendet, wird nie seinen Spass an OpenVZ haben.

Natürlich lässt sich alles problemlos auch auf andere Distributionen und Architekturen portieren, wobei die Namen, besonders für die Templates, angepasst werden müssen.

Auch wenn NIS als älter und unsicherer gilt als LDAP, hat es für mich ein klarer Vorteil: es ändert sich nicht immer komplett!
Wer schon mal ein LDAP auf einem Ubuntu Server 8.04 und 8.10 installiert hat, kann nachvollziehen was ich meine. So und damit genug, ich will hier nicht über LDAP herziehen, sondern NIS vorstellen

Ich habe mir also mit NIS und NFS innert wenigen Minuten eine zentrale Benutzerverwaltung mit zentralem Homeverzeichnis eingerichtet. Und wie das geht, folgt hier:

Ich habe mit dem NIS Server begonnen und dazu die Pakete für NFS und NIS aus den Paketquellen installiert.

1

apt-get install nfs-kernel-server nis

Während der Installation, nachdem man einen Namen für die Domäne eingegeben hat, versucht apt automatisch den NIS Daemon zu starten, was auf Grund mangelnden Einstellungen aber nie funktionieren wird. Also zurück lehnen, und auf den Fehler warten

Nun beginnt die Konfiguration. In der Datei /etc/default/nis wird die NIS-Installation von Client zum Server umgebogen:

1
2
3
4

# Are we a NIS server and if so what kind (values: false, slave, master)?
NISSERVER=true
# Are we a NIS client?
NISCLIENT=false

Dann geben wir in der Datei /etc/exports unser Homeverzeichnis frei:

1

/home	*(rw,async,no_subtree_check)

Wer es gern sicherer hat, kann den Stern durch einen Computernamen oder eine IP mit Subnet ersetzen, wodurch dann nur der Zugriff von diesen Maschinen aus gestattet ist.

Nun kann man den Daemon neu starten:

1

/etc/init.d/nis restart

Und zum Abschluss muss man noch die Maps generieren lassen. Dazu ruft man folgenden Befehl auf:

1

/usr/lib/yp/ypinit -m

Nun ist der NIS Server soweit fertig. Es können nun normal User hinzugefügt werden, die bereits bestehenden werden im NIS aufgenommen.
Wichtig jedoch, nach einer Änderung an einem User oder einer Gruppe, also Änderungen, welche die passwd, group, shadow oder gshadow datei verändern, folgender Befehl ausgeführt wird, um die Maps zu erneuern:

1
2

cd /var/yp/
make

Nun noch alle benötigten Daemons neu starten:

1
2
3

/etc/init.d/portmap restart
/etc/init.d/nfs-kernel-server restart
/etc/init.d/nis restart

Und zum Schluss die Verwendung des NIS Servers starten:

1
2

ypbind
ypserv

Ein Aufruf von ypwhich sollte nun den Namen oder die IP des NIS Masterserver und ypdomainname den Namen der NIS Domäne ausgeben.

Nun muss der Client, welcher NIS verwenden soll, noch vorbereitet werden!
Auch hier wird das Paket NIS aus den Paketquellen installiert:

1

apt-get install nis nfs-common

Im Gegensatz zu vorher sollte sich hier der NIS Daemon nach Eingabe der selben Domäne erfolgreich starten, da der NIS Server über Broadcast-Pakete gesucht wird.

Trotzdem sollte der NIS Server noch fest in die Datei /etc/yp.conf eingetragen werden:

1

ypserver nismaster.ch

Nun müssen noch die passwd, group, shadow und gshadow angepasst werden und jeweils folgenden Zusatz als letzte Zeile haben:
/etc/passwd:

1

+::::::

/etc/group:

2

+:::

/etc/shadow:

3

+::::::::

/etc/gshadow:

4

+:::

Nachdem der Client nun die Userinformationen vom NIS Server verwenden kann, muss noch das Homeverzeichnis konfiguriert werden.
Dazu wird die Datei /etc/fstab mit folgender Zeile ergänzt:

1

nismaster.ch:/home  /home  nfs  rsize=8192,wsize=8192,hard,intr  0  0

Nun sollte auch hier noch der NIS Daemon neugestartet werden:

1

/etc/init.d/nis restart

Wird nun ypwhich und ypdomainname ausgeführt, so sollten deren Ausgaben mit denen vom Server übereinstimmen.
Wenn nun der Client nun gestartet wird, so sollte beim Start zuerst das home-Verzeichnis vom Server gemountet werden und danach eine Verbindung zum NIS Server mit der konfigurieren Domäne hergestellt werden, worauf man sich dann mit jedem auf dem Server zugefügten Benutzer auch auf dem Client einloggen kann.

Doch interessanter als das Protokoll ist was man damit machen kann
Ist in einem Netzwerk ARP freigegeben (was auch häufig der Fall ist), so kann man dies in Kombination mit einem Switch zu einer Man-in-the-Middle-Attacke verwenden.

Doch von vorne! Es gibt zwei “Probleme”:
Problem 1…
Der Client führt eine Cache, wo er eine IP- einer MAC-Adresse zuordnet. Dies wird verwendet, dass nicht vor dem Versenden eines Datenpaketes jedes mal zuerst noch eine neue Abfrage der MAC-Adresse gemacht werden muss.
Dieser Cache kann aber von einem anderen Client mit den nötigen Mitteln verändert werden. D.h. ich als Angreifer kann den Cache des Opfers so verändern, dass der IP-Adresse eines z.B. gerade eben besuchten Servers nicht mehr die tatsächliche MAC-Adresse des Servers, sondern eine beliebige zugeordnet wird.

Das alleine wäre ja noch nicht so schlimm, wäre da nicht noch Problem 2…
Hier kommt dann der Switch ins Spiel. Ein Switch hat gegenüber einem Hub einen grossen Unterschied. Ein Hub sendet den Traffic von einem Port einfach an alle anderen aktiven Ports, in der Hoffnung, dass nur derjenige den Traffic liest, welcher ihn auch angefragt hat.
Der Switch hingegen; damit der Traffic nicht jedes mal an alle Ports versandt werden muss, führt eine Zuordnungsliste, wo festgelegt wird, welches Gerät (anhand der MAC-Adresse) an welchem Port angeschlossen ist.

Auch Problem 2 wäre alleine kein Problem, doch zusammen!!
Ein Angreifer manipuliert den Cache eines Clients nun so, das die IP-Adresse des Server nicht mehr der MAC-Adresse des Server, sondern der des Angreifers zugeordnet ist.
Da der Client davon nichts mitbekommt, nimmt er die MAC-Adresse des Angreifers aus seinem Cache, in der Meinung es wäre die Adresse des Servers und schickt diese mit seinem Datenpaket zum Switch.
Der Switch nun liest die MAC-Adresse aus und erkennt die MAC-Adresse des Angreifers. Beim Vergleich mit seiner Zuordnungsliste wird das ganze Paket nun nicht mehr an den Switchport des Servers, sondern an den des Angreifers versandt.
Macht der Angreifer das gleiche nun auch noch mit dem Server, so kann er jeden Traffic zwischen einem Client und einem Server mitlesen und beliebig manipulieren.

Man sagt ja, in der Theorie ist es meistens einfacher, als in der Praxis. Das Problem von ARP Spoofing ist aber, dass dies hier nicht stimmt!!
Mit nur wenigen Klicks und einem Paket aus den Ubuntu Paketquellen lässt sich mittels ARP Spoofing eine komplette Man-in-the-Middle-Attacke durchführen.
Wie genau – das soll jeder alleine herausfinden, doch das Paket dsniff könnte helfen

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

In IPv4 sind Adressen, wie sie jeder technisch versiertere User täglich braucht. Sie bestehen aus 32 Bit und werden in 4er Blöcke zu je 8 Bit unterteilt.

Diese 8 Bit sind dann auch der Grund wieso jedes der 4 Blöcke nur eine Zahl von 0 bis 255 beinhalten kann.

Doch in diesen insgesamt 32 Bit liegt auch das Problem. Dadurch lassen sich gerade mal 4’294’967’296 IP Adressen abbilden und diese sind auch bald schon alle Verbraucht…

Laut Schätzungen werden im Jahre 2010 die letzten IPv4 Adressen vergeben und dann ein Jahr später schlussendlich IPv6 Adressen verteilt.

IPv6, gerne auch Internet Protocol next Generation genannt, besteht aus 128 Bit Adressen und kann damit etwa 340 Sextillionen Adressen verwalten. Dadurch muss nicht mehr mit öffentlichen und privaten Adressen gearbeitet werden, sondern jedes Gerät könnte seine eigene feste IP haben, wodurch DHCP Dienste im Grunde genommen überflüssig werden.

Eine IPv6 Adresse kann etwa wie folgt aussehen

1

2001:0db8:85a3:08d3:1319:8a2e:0370:7347.

Ich mache mir jedoch ein bisschen Sorgen, wie man sich so eine IP merken soll. Denn wie oft kam es bei Arbeiten im Netzwerk vor, dass man kurz eine IP Adresse merken oder aufschreiben muss. Bei 32 Bit war das ja einfach, doch bei 128 Bit…?

Weiter frage ich mich, wie lange es dauern wird, bis auch der Bereich von IPv6 Adressen zu klein wird… Und was dann? Kommt dann IPv8 mit 1024 Bit und IP Adressen im 100 stelligen Bereich? Und wie sieht dann IPv10 erst aus?

Wo führt das nur hin…

Alle zu überwachenden Servern und Netzwerkkomponenten werden in der Datei /etc/hobbit/bb-hosts eingetragen.

Ein Eintrag ist dabei immer gleich aufgebaut:

1

172.16.10.2		voodoo.hswn.dk		# ssh ntp dns bbd apache

Zuerst steht die IP, welche zum überwachen verwendet wird.
Danach folgt der Name, unter welchem alle Stati auf der Seite schlussendlich aufgeführt werden.
Am Schluss, entgegen jeder Logik, stehen auskommentiert die zu überwachenden Funktionen und Dienste.
Im Falle unseres Beispieles sieht das wie folgt aus:

Nun kann man mit Xymon die gängigsten Funktionen und Services überwachen. Jeder Service, den man überwachen will, muss wie obig schon aufgeführt, nach der Raute eingetragen werden.

Die gebräuchlichsten Funktionen sind dabei die folgenden:

1
2
3
4
5
6
7
8
9
10
11
12
13

ssh:		Überwacht den SSH Zugriff
ntp:		Überwacht das NTP (Network Time Protokoll)
dns:		Überwacht DNS Funktionen des Servers
bbd:		Überwacht den Xymon Daemon
apache:		Überwacht die Apacheserver-Funktionen
dialup:		Überwacht den Dialup Zugriff
noconn:		Deaktiviert die Überwachung per Ping
smtp:		Überwacht die SMTP Funktion eines Mailservers
pop3:		Überwacht die POP3 Funktion eines Mailservers
imap:		Überwacht die IMAP Funktion eines Mailservers
clamd:		Überwacht den ClamAV-Daemon
dnsreg:		Überwacht den DNS Eintrag auf dessen Gültigkeit
[URL]:		Überwacht den HTTP(S) Zugriff auf die angegebene URL

Alle bisherigen Einstellungen haben sich mit den Funktionen, welche man überwachen will beschäftigt.
Besonders in geschäftlicher Umgebung, wo man sehr viele Server hat, ist es interessant, dass man auch den Look & Feel des Webinterfaces mitbestimmen kann.

So kann man seine gesamte zu überwachenden Komponenten in Server und Services unterteilen:

1
2
3
4
5
6

page servers Systems
172.16.10.2		voodoo.hswn.dk		# ssh ntp dns bbd apache
[weitere....]
page services Services
172.16.10.2		mail.hswn.dk		# smtp pop3 imap clamd
[weitere...]

Dies hat zur folge, dass man beim Aufrufen des Webinterfaces nicht von hunderten von Servern erschlagen wird, sondern das man zwei Punkte ‘Systems’ und ‘Services’ zur Auswahl hat:

Da die Seite Services wirklich nur für Services gedacht ist, fehlen da auch Überwachungspunkte wie CPU, Disk etc. Diese werden in der Kategorie Servers automatisch zugefügt, und überwachen z.B. die Auslastung der CPU oder freien Speicher der Festplatte.
Dies ist nicht etwa ein Bug, sondern tun bei der Überwachung eines Service einfach nichts zur Sache und wurden absichtlich weggelassen.

Zur weiteren Strukturierung kann man nun auch noch Server und Services innerhalb einer Seite weiter zusammenfassen und gruppieren:

1
2
3
4
5
6

group-compress <font size="+1">Mail</font>
172.16.10.2		mail.hswn.dk		# smtp pop3 imap clamd
[weitere...]
group-compress <font size="+1">Web</font>
172.16.10.2		www.hswn.dk		# http://www.hswn.dk/ apache
[weitere...]

Dies wiederum zeigt sich im Webinterface wiefolgt:

So nun eine komplette Konfigurationsdatei kann etwa so aussehen:

1
2
3
4
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
34
35
36
37
38
39
40
41
42
43
44
45

# 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.		# bbd
 
page servers Systems
group-compress <font size="+1">Servers</font>
172.16.10.2     	voodoo.hswn.dk		# ssh ntp dns bbd apache
 
172.16.10.5		miro.hswn.dk		# ssh http://miro.hswn.dk/
 
172.16.10.4		dali.hswn.dk		# ssh dialup
 
group-compress <font size="+1">Test systems</font>
0.0.0.0			osiris.hswn.dk		# dialup
0.0.0.0			localhost		# ssh
 
page services Services
group-compress <font size="+1">Network</font>
147.29.31.155		adsl.hswn.dk		# noconn
 
group-compress <font size="+1">Mail</font>
172.16.10.2     	mail.hswn.dk		# smtp pop3 imap clamd
 
group-compress <font size="+1">Web</font>
172.16.10.2     	www.hswn.dk		# http://www.hswn.dk/ apache
172.16.10.2     	webmail.hswn.dk		# https://webmail.hswn.dk/src/login.php
 
group-compress <font size="+1">News</font>
172.16.10.2     	news.hswn.dk		# nntp
 
group <font size="+1">Domains</font>
0.0.0.0			hswn.dk			# noconn dnsreg
0.0.0.0			storner.dk		# noconn dnsreg
0.0.0.0			storner.com		# noconn dnsreg

Wie das ganze nun schlussendlich aussieht, findet man auf der offiziellen Seite von Xymon.
Auf dieser Seite findet man auch die Konfigurationsdatei, welche ich obig verwendet habe. Wer also nicht meine vereinfachte Version will, kann hier die Originale finden.

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

Für mich war das eine Premiere, da ich bisher nur unter Windows das vergnügen hatte, und da ist es wirklich keine grosse Sache.

Umso erstaunter war ich, wie kompliziert das eigentlich unter Linux ist…

Doch war ich irgendwie zu faul (oder einfach vom WindowsGUI verwöhnt), alle Dateien einzeln zu editieren und konfigurieren, also habe ich auf Webmin zurückgegriffen.

Webmin erlaubt es, viele Einstellungen in Bereichen wie Netzwerkverwaltung, Useradministration, Servereinstellungen und vieles mehr direkt über ein GUI im Browser zu konfigurieren.

Zuerst muss man sich also das aktuelle Paket von Sourceforge holen:

wget http://downloads.sourceforge.net/project/webadmin/webmin/1.390/webmin_1.390_all.deb

Danach kann man die Installation starten:

sudo dpkg -i webmin_*

Da aber noch einige Pakete fehlen, wird die Installation vorerst fehlschlagen. Also gilt es dies noch zu berichtigen:

sudo apt-get install -f

Und nun ist Webmin auch schon installiert unter unter https://127.0.0.1:10000 verfügbar.

Jetzt kann also die Installation losgehen. Dazu ruft man Webmin auf und loggt sich mit einem User ein, welcher sudo-Rechte besitzt.
Dann wählt man unter “Server” den Punkt “BIND DNS Server”.

Nun muss man zuerst mal eine neue Zone erstellen. Hierfür wählt man den Punkt “Create master zone”. Will man, wie in meinem Fall Namen zu IPs auflösen, so muss man eine Forward Lookup Zone erstellen.

Unter “Domain name / Network” vergibt man den Namen für die Zone. Dieser wird auch gleich der Name der Top Level Domain sein (zB. lokal, ch oder com).
Nun muss man noch unter “Email address” eine eMail-Adresse eingeben. Der Rest kann man auf den Standardeinstellungen belassen.

Jetzt kann man endlich die ersten Namen einer IP zuordnen. Dazu definiert man alle Namen und IPs unter dem Punkt “Address (0)”.

Wenn man will, kann man unter “Reverse Address (0)” nochmal die selbigen Informationen zuordnen.

Nachdem man seine Änderungen abgespeichert hat, kann man die Einstellungen testen.
Dazu logge ich mich per SSH ein und führe eine Abfrage an den DNS Server aus:

dig @127.0.0.1 name.domain

Eine Antwort sollte etwa so aussehen:

; <<>> DiG 9.4.2-P2 <<>> @127.0.0.1 name.domain
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18355
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;name.domain. IN A

;; ANSWER SECTION:
name.domain. 38400 IN A 192.168.0.1

;; AUTHORITY SECTION:
domain. 38400 IN NS SL004.

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Nov 29 01:52:00 2009
;; MSG SIZE rcvd: 62

Nun muss man nur noch den einzelnen Hosts den DNS hinzufügen. Da bei mir alle Clients ihre IPs per DHCP beziehen, musste ich den DNS nur da eintragen, und abwarten.

Und von nun an, muss ich mir keine mühsamen IP-Adressen mehr merken
Vielen Dank an Roman für die Tipps zu Webmin.