Bits, Bytes and my 5 cents

Seit dem letzten Update von Hobbit hat auch ein neues Feature Einzug gehalten.
Bei der Installation von Hobbit über die Konsole wird man nach einer oder mehreren IP Adressen gefragt, welche Zugriff auf das Webinterface von Hobbit erhalten sollen.

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

IPv4 steht für Internet Protocol Version 4 und ist unser aktuelles Internet Protokoll.

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…

Vor einiger Zeit habe ich über die Installation von Xymon geschrieben. Heute will ich ein paar Worte zu der eigentlich sehr simplen Konfiguration verlieren.

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.

Erstmal vorweg: Ich will hier keine Grundsatzdiskussion auslösen, ob Linux nun einen Virenschutz braucht oder nicht. Auf allen meinen Servern installiere ich einen Virenschutz, ob dieser nun gebraucht wird oder nicht.

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?