Also will ich mich mal ans repetieren machen und beginne mit DNS, genauer Bind9 einrichten und konfigurieren. Später folgen dann nach und nach noch all die anderen Themen, wodurch eine Artikelserie daraus werden wird.

Doch zuerst zu DNS! Obwohl eigentlich sollte man es eher als Namensauflösung bezeichnen, denn es werden noch Dienste wie NIS oder Dateien wie /etc/hosts angesprochen.

Aber alles von vorne! Also die einfachste Möglichkeit zum eine IP-Adresse auflösen ist über die Hosts-Datei unter /etc/hosts. Diese könnte in etwa so aussehen:

root@master:/etc# cat /etc/hosts
127.0.0.1	localhost
127.0.1.1	master.encodingit.ch	master

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Jedoch wenn man mehr als nur ein, zwei Computer hat, so ist es relativ mühsam auf jedem diese Datei von Hand zu pflegen. Auch Sun bemerkte dies und entwickelte NIS (darüber habe ich schon mal geschrieben).
Doch als auch das nicht mehr reichte, kam man zu DNS.
Einfach gesagt ist es eine Hosts-Datei, welche an einem zentralen Ort verwaltet werden kann und von jeder Maschine bei Bedarf geladen wird. Komplizierter gesagt: dazu kommen wir noch

Die wichtigsten Dateien für die Namensauflösung auf einem Client wären dabei:

/etc/hosts > verantwortlich für die lokale Namensauflösung.
/etc/resolv.conf > gibt an, welche Nameserver angefragt und welche Domains durchsucht werden sollen.
/etc/nsswitch.conf > definiert die Reihenfolge ob zuerst der DNS, NIS oder die Hosts-Datei bei der Auflösung berücksichtigt werden soll.

Dies war alles auf dem Client – nun aber zu unserem DNS Server. Zuerst mal installieren:

apt-get install bind9

Gestartet wird der Dienst entweder über /usr/sbin/named oder über /etc/init.d/bind9 (unter Debian). Doch nach der Installation läuft er sowieso standardmässig.

Die Konfiguration ist ganz amüsant! LPIC will sich ja nicht auf eine Distribution festlegen, deshalb gibt es bei einem typischen Beispiel wie bind immer wieder Unterschiede.
Unter Debian (unter welchem ich die Installationen gerade durchführe) liegt alles wie gewohnt unter /etc/bind. RedHat oder Suse packen die Konfigurationsdateien aber in /etc/named.conf und die Zonendateien in /var/named. Viel Spass beim Suchen

Unter Debian läuft die Konfiguration von Bind und der Zonen in zwei einzelnen Files ab:

named.conf.options > Darin werden alle Einstellungen definiert, wie sich der DNS-Server zu verhalten hat
named.conf.local > Hier werden all die Einstellungen zu den Zonen definiert

Nun wollen wir aber auch unser erstes Zonen-File anlegen.
Zuerst der Forward Lookup von Domain -> IP. Dazu legen wir eine Datei in das Verzeichnis /etc/bind mit dem Namen unserer Domain:

touch /etc/bind/encodingit.ch

Diese befüllen wir nun mit dem DNS-Syntax, welcher sehr akribisch eingehalten werden muss:

$TTL 2d
@ IN SOA master.encodingit.ch. root.encodingit.ch. (
               2011030401       ; serial
               3h               ; refresh
               1h               ; retry
               1w               ; expiry
               1d )             ; minimum

@              IN NS   master.encodingit.ch.
master          IN A    192.168.1.20

Die Datei ist bei jeder Zone immer gleich aufgebaut. Auf der ersten Zeile wird die Time-To-Life festgelegt, Dann folgen Angaben über den DNS und die Email-Adresse des Admins (mit . anstatt @). Weiter geht es mit einer eindeutigen Nummer, Standardangaben und dann endlich die eigentlichen Lookups.
Zuerst wird ein NS-Record für die Domain angelegt, danach wird der Name über einen A-Record einer IP zugewiesen.

Nun müssen wir noch den Reverse Lookup einrichten. Dazu machen wir wieder eine neue Datei:

touch /etc/bind/1.168.192.in-addr.arpa

Und befüllen auch diese:

$TTL 2d
@ IN SOA master.encodingit.ch. root.encodingit.ch. (
               2011030401       ; serial
               3h               ; refresh
               1h               ; retry
               1w               ; expiry
               1d )             ; minimum

@     IN NS master.encodingit.ch.
20	   IN PTR		master.encodingit.ch.

Nachdem die Zonen nun angelegt sind, muss man den DNS auch noch dazu zwingen, diese zu kennen. Dazu muss die named.conf.local mit einem Eintrag wie dem folgenden ergänzt werden:

zone "encodingit.ch" {
type master;
file "/etc/bind/encodingit.ch";
};

zone "1.168.192.in-addr.arpa" {
type master;
file "/etc/bind/1.168.192.in-addr.arpa";
};

Nun muss noch bind neu gestartet und dann der Client auf den neuen DNS gewechselt werden:

/etc/init.d/bind9 restart
echo "domain encodingit.ch" > /etc/resolv.conf
echo "nameserver 127.0.0.1" >> /etc/resolv.conf

Und schon ist der DNS bereit!

[...] eine Internetgeschwindigkeit von 1,37 Gigabit pro Sekunde erreicht [...] Mit dieser Geschwindigkeit lässt sich beispielsweise ein HD-Film in weniger als 5 Sekunden herunterladen [...]

Ich mag irren, aber hier geht doch etwas nicht ganz auf…

1,37 Gigabit = 0.17125 Gigabyte

Geht man nun von einem sehr komprimierten HD-Film aus mit einer Grösse von etwa 4 Gigabyte so hätte man, um diesen zu übertragen, alleine schon über 20 Sekunden…

4 / 0.17125 = 23.357664234 Sekunden

Besonders lustig daran ist, dass viele IT-Magazine diese News anscheinend von der selben Quelle haben; welche genau das ist, versuche ich noch raus zu bekommen.

Aber eigentlich bin ich der Meinung, dass ein solch grober Schnitzer bei einer Fachzeitschrift nicht passieren darf…

Update 09:17
Wie es scheint, sitzt der Wurm direkt bei Cablecom. So taucht der Fehler schon in der offiziellen Pressemiteilung selbst auf.
Ich warte noch auf eine Stellungnahme von Cablecom!

Update 09:43
Klang heimlich hat man nun den offiziellen Pressetext angepasst. Zum Glück habe ich oben noch eine PDF-Version verlinkt
Eine Stellungnahme habe ich bisher aber immer noch nicht erhalten von Cablecom…

Aber so langsam frage ich mich echt über das Knowhow dieser Firma.
So hat man nun für die Ladezeit eines HD-Filmes einfach die von mir gemeldeten 20 Sekunden eingesetzt.

Das ich aber geschrieben habe “mehr als 20 Sekunden” hat man ignoriert.
So steht nun folgendes auf der Seite:

Mit dieser Geschwindigkeit lässt sich beispielsweise ein HD-Film in weniger als 20 Sekunden herunterladen oder mehr als 100 Lieblings-Songs in weniger als 1 Sekunde.

Stimmt also immer noch nicht!
Hätte der Zuständige beim Korrigieren nun noch seinen Kopf eingesetzt, so wären nämlich noch mehr Ungereimtheiten aufgetaucht!

100 Songs in 1 Sekunde
1 Song à 5 Megabyte

Das macht nach Adam Riese für alle Songs zusammen 500 Megabyte mit einem Durchsatz von 0.17125 Gigabyte / Sekunde eine Dauer von etwa 3 Sekunden…

Irgendwie armselig, wie wenig da mitgedacht wird! Hätte ich 10 Sekunden geschrieben, so würde in der Pressemitteilung nun sehr wahrscheinlich 10 Sekunden stehen…

Update 10:38

Soeben habe ich eine Nachricht von Cablecom erreicht! Vorweg möchte ich sagen, ein “Danke für den Hinweis” hätte gereicht, aber die Erklärungsversuche dieses netten Mitarbeiters machen alles nur noch schlimmer!

Ich zitiere einfach mal und fange beim ersten Satz an.

Wir sind für die Berechnung des Downloads von einer File-Grösse von rund 850Mb ausgegangen

Also den HD-Film mit 850 Megabyte möchte ich sehen…

Wir sind damit wohl etwas tief gelegen

Ach nee??

Wir haben daher neue Erkundigungen eingeholt und dabei den Grossteil der Filme (720p) auf Plattformen bei Dateigrössen zwischen 1 und 4 GB eingestuft

Was auch immer das für Plattformen sein mögen, lassen wir mal aussenvor. Aber HD ist bei mir im Normalfall zwischen 4 – 8 Gigabyte gross…

Ich frage mich gerade, ob ich dem geschätzten Mitarbeiter das wirklich noch erklären soll…

Update 11:05

Mittlerweile hat auch Swiss IT Magazine und Swiss IT Reseller ein kritisches Auge auf ihren Beitrag geworfen und diesen korrigiert.
Dieser Dachverband für viele IT-Fachseiten ist immerhin professionell genug ein Update zu veröffentlichen und nicht die Beiträge heimlich anzupassen!

Update 16.2.2011 16:45

Heise.de kommt wie die alte Fasnacht nach und kopiert den selben Fehler natürlich auch noch:

Letztere soll sich speziell für IP-Videoservices eignen. So wurde im Test denn auch ein kompletter HD-Film in nur fünf Sekunden übertragen.

Doch da kann Abhilfe geschaffen werden!
Um auf einfache Art und Weise die Konfiguration von einer Cisco Netzwerkkomponente zu sichern bietet sich TFTP an. Wer es etwas sicherer mag, der könnte natürlich auch FTP verwenden, jedoch wenn der Server nur für diese eine Funktion verwendet wird, so ist dies nicht zwingend nötig und verursacht nur mehr Aufwand.

Alles was ich dazu brauche ist neben meinen Netzwerkkomponenten ein TFTP-Server, wobei ich mich für Debian entschieden habe. Hierzu könnte aber auch Ubuntu, RedHat oder andere Distributionen verwendet werden. Mit TFTPD32 gibt es sogar eine Version für windowsbasierte Systeme.

Dazu muss zuerst der Server installiert werden:

1

apt-get install tftpd

Nun noch den Ordner für TFTP einstellen und schon fast fertig. Dazu kann in der Datei /etc/inetd.conf der letzte Punkt unter TFTP angepasst werden, auf was auch immer es euch beliebt :

1

tftp  dgram   udp     wait    nobody  /usr/sbin/tcpd  in.tftpd /tftpboot

Danach muss auf den entsprechenden Ordner noch die passenden Zugriffsrechte vergeben werden:

1

chmod -R 777 /usr/sbin/tcpd/

Nun kann auf dem Switch die Konfiguration übertragen werden:

1
2
3
4
5
6
7
8
9

Router#copy running-config tftp:
Address or name of remote host []? 192.168.1.1
Destination filename [Router-confg]? routerconf
 
Writing running-config...!!
[OK - 463 bytes]
 
463 bytes copied in 0.008 secs (57000 bytes/sec)
Router#

Damit aber das nicht immer manuell gemacht werden muss, wird der Befehl zeitgesteuert immer wieder ausgeführt.

Dafür kann Kron verwendet werden, welche seit IOS Version 12.3.1 integriert ist. Leider sind alle IOS im Packet Tracer noch mit älteren Versionen ausgestattet, wodurch dies ohne Hardware nicht so einfach getestet werden kann.

Eingerichtet wird Kron aber wie folgt:

1
2
3

kron policy-list backupconfig
cli copy running-config tftp://172.16.1.9
cli routerconf

Danach muss der Kron getimet werden. Wer das ganze tatsächlich als Ersatz für ein Vergessenes Write Memory einsetzen will, sollte natürlich einen kleineren Zeitabstand wählen:

1
2

kron occurrence week in 7:1:30 recurring
policy-list backupconfig

Nun kann man sich die gespeicherten Kron-Jobs anzeigen lassen:

1

show kron schedule

Wenn nun etwas schief gehen soll oder sonst etwas, so kann eine Konfiguration wieder zurück gespielt werden:

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

Router#copy tftp: running-config
Address or name of remote host []? 192.168.1.1
Source filename []? routerconf
Destination filename [running-config]? 
 
Accessing tftp://192.168.1.1/routerconf...
Loading routerconf from 192.168.1.1: !
[OK - 463 bytes]
 
463 bytes copied in 0.006 secs (77166 bytes/sec)
Router#
%SYS-5-CONFIG_I: Configured from console by console
Router#

Ganz zum Schluss das Festschreiben der Konfiguration nicht vergessen

Ganz nützlich ist diese Funktion auch, wenn man mehrere gleiche oder ähnliche Netzwerkkomponenten mit gleicher oder nur leicht abgeänderter Konfiguration in Betrieb nehmen möchte.
Dazu muss lediglich die Konfiguration weg kopiert, mit einem Texteditor bearbeitet werden und dann auf die passenden Komponenten wieder aufgespielt werden.

Wer es gerne auch ausprobieren möchte, der kann dieses kurz mit dem Cisco Packet Tracer durchspielen:

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.

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.

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.

Dabei wollte ich vorallem den SSH-Zugang besser schützen, mindestens vor automatisierten Bruteforce-Attacken.

Dabei bieten sich mir diverse Möglichkeiten:

• Keyfiles
• PermitRootLogin
• AllowUsers
• Portänderung
• fail2ban
• PortKnocking
• OTP

Als erstes habe ich mal das einloggen vom User “root” verboten. Damit sind bereits 80% aller automatisierten Attacken erfolglos.

PermitRootLogin

Dazu setzt man unter

/etc/ssh/sshd_config

hinter dem Punkt PermitRootLogin ein

no

AllowUsers

Noch besser als das Login als root zu verbieten, ist es, nur bestimmte User zuzulassen.

Dazu muss man in der Datei

/etc/ssh/sshd_config

unter dem Punkt AllowUsers alle Benutzer eingeben, welche Zugriff haben dürfen:

AllowUsers user1 user2 user3

Keyfiles

Keyfiles sind auch noch eine gute Möglichkeit um automatisierte Angriffe abzublocken. Denn, wer die passenden Keyfiles nicht hat, kann sich auch mit dem richtigen Passwort nicht einloggen.

Doch für mich persönlich sind Keyfiles eher unpraktisch, da ich mich oft von verschiedenen Maschinen aus einloggen soll, und meistens da die Keyfiles dann fehlen würden.

Portänderung

Gegen automatisierte Angriffe kann auch eine Umstellung der Ports über welche SSH (22) kommuniziert, helfen.

Das Problem jedoch, mit einem kurzen Scan kann man aufdecken, auf welchem Port SSH nun wirklich läuft.

Ändern kann man den Port unter dem Punkt

Port

in der Konfig von SSH unter

/etc/ssh/sshd_config

fail2ban

Mittels dem Tool fail2ban kann man eine IP Adresse nach einer vordefinierten Anzahl fehlgeschlagener Logins automatisch sperren.

Dies ist besonders praktisch, da ich somit nicht nur ein Mittel gegen automatisierte sondern auch gegen jegliche andere SSH Attacken habe.

Und mitels fail2ban kann man nicht nur den Zugriff auf SSH, sondern auch noch für unzählige andere Dienste wie Appache, DNS, FTP und viele mehr.

fail2ban gibt es auf den Ubuntu Packetservern über

sudo apt-get install fail2ban

Nach der Installation heisst es erst mal Einstellungen bearbeiten. Die Konfig ist unter

/etc/fail2ban/jail.conf

abgelegt.

Um den SSH Zugriff überwachen zu lassen, gilt es folgenden Textschnippsel noch zu ergänzen:

[ssh-iptables]
enabled = true
filter = sshd
action = iptables[name=SSH, port=ssh, protocol=tcp]
logpath = /var/log/auth.log
maxretry = 3

Damit wird jede IP-Adresse, welche sich 3mal mit falschem Passwort einloggen will, automatisch gebannt.

Portknocking

Eine weitere, sehr effektive Massnahme ist das sogenannte Portknocking. Das beschreibt ein Verfahren, bei welchem man zuerst mit dem geheimen Zeichen anklopfen muss, bevor man sich per SSH einloggen kann.

Wird das geheime Zeichen nicht vorweg gesendet, so erscheint der Port 22 nach aussen als geschlossen.

Realisieren lässt sich dies mittels knockd, welches wiederum in den Packetquellen verfügbar ist

sudo apt-get install knockd

Konfiguriert wird das Programm über eine zentrale Datei

/etc/knockd.conf

Um knocked nun auf den SSH Port vorzubereiten, muss man die Datei mit folgenden Eintrag ergänzen:

[openSSH] sequence = 1234,1234,1234 seq_timeout = 5 command =
/sbin/iptables -A INPUT -s %IP% -p tcp –dport 22 -j ACCEPT
tcpflags = syn

[closeSSH]
sequence = 1234,1234,1234
seq_timeout = 5
command = /sbin/iptables -D INPUT -s %IP% -p tcp –dport 22 -j DENY
tcpflags = syn

Will man sich nun per SSH einloggen, so muss man zuerst mittels

knock ip 1234 1234 1234

den Port freischalten. Nach vollbrachter Arbeit wird der Port über selbiges Kommando auch wieder geschlossen.

OTP

OTP ist ein Verfahren, mittels welchem für jedes Login ein neues Passwort generiert wird. Hier bedanke ich mich bei Benjamin für den Gedankenanstoss und die ausführliche Anleitung.

Er beschreibt dabei wie OTP in Kombination mit seinem Android Handy verweden kann. Doch auch iPhone-Benützern wie mir wird mit dem Tool “OTP Generator” von Dragon Technology Ltd geholfen, welches für CHF 3.30 im Appstore verfügbar ist.

Fazit

Für mich ist fail2ban und PermitRootLogin am besten geeignet. Obwohl ich der Meinung bin, das Portknocking wohl das effektivste wäre, weiss ich noch nicht, ob ich mein “Geheimzeichen” auch von anderen Betriebssystemen aus versenden kann. Deshalb ist dieses Verfahren vorerst mal auf Eis gelegt.

OTP ist für mich schon fast wieder übertriebene Sicherheit, und der Aufwand, jedes mal ein neues Passwort zu generieren ist mir einfach zu gross.

Natürlich ist ein offener SSH Port immer ein Sicherheitsrisiko, aber mit den obig aufgezeigten Möglichkeiten, sollte man 95% aller Attacken abwehren können.

Und sonst gilt halt immer noch: Wählt ein sicheres Passwort

[Quellen: 4t2, Horst und FreiesMagazin]

Um auch einzelne Server innerhalb meines Netzwerkes anzusprechen, so habe ich dafür ein Portforwarding eingerichtet. Doch was, wenn ich nun zwei Webserver im Netzwerk habe. Wie kann ich beide ansprechen? Ich kann den Port 80 ja nicht auf mehrere Server weiterleiten.

Die Lösung heisst Reverse Proxy. Dabei kann ich die Anfrage vom Router, über den Proxy auf den passenden Server weiterleiten.

Somit kann ich also als Beispiel einen Webserver und eine Groupware beide auf Port 80 betreiben. Von aussen angesprochen werden Sie dann mittels http://ip.com/webserver/ oder http://ip.com/groupware/. Der Proxy entscheidet und leitet auf den entsprechenden Server weiter.

Die Installation ist auch ganz einfach
Alles was man tun muss, ist ein Paket aus den Paketquellen zu installieren

sudo apt-get install libapache2-mod-proxy-html

Danach muss man noch die folgenden drei Module aktivieren

sudo a2enmod proxy
sudo a2enmod proxy_html
sudo a2enmod proxy_http

und den Webserver neu zustarten.

sudo /etc/init.d/apache2 force-reload

Nun kann man mit der Konfiguration beginnen. Ein Beispiel kann in etwa so aussehen:

<VirtualHost *>
…
ProxyRequests Off

Order deny,allow
Allow from all
ProxyPass /webserver/ http://192.168.1.2:80/
ProxyPassReverse /webserver/ http://192.168.1.2:80/

ProxyPass /groupware/ http://192.168.1.3:80/
ProxyPassReverse /groupware/ http://192.168.1.3:80/
…
</VirtualHost>

Nun gilt es einfach alle Server einzutragen und dann den Webserver nochmals neu zustarten. Nun trägt man ein Portforwarding im Router ein und kann somit beide Server auf Port 80 ansprechen.

Vielen Dank an das Ubuntuusers-Wiki