Zuerst habe ich versucht, dieses Überbleibsel der Windows-Welt direkt in VI selbst zu ersetzen:

1

%s/\^M//g

Dies funktionierte leider nicht, wäre ja auch zu schön gewesen.
VI sucht mit diesem Kommando nach den Zeichen ^ und M. Leider ist der Zeilenumbruch aber nur abgebildet als ^M, nicht aber auch als solches abgespeichert, wodurch VI nie etwas finden wird.

Die Lösung schlussendlich war zwar nicht ganz so komfortabel wie direkt per VI, hat aber ihren Zweck voll und ganz erfüllt:

1

perl -p -e 's/\r$//' < windowsdatei > linuxdatei

Natürlich funktioniert das ganze auch für alle Verräter der Linuxwelt (kein Flame, nur Spass)

1

perl -p -e 's/\n/\r\n/' < linudatei > windowsdatei

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

Frisch fröhlich habe ich mit der Installation des Paketes begonnen:

1

rpm -i ICAClient-11.0-1.i386.rpm

Dummerweise besteht ein Abhängigkeitsproblem, also gleich mal yum durchrennen lassen:

2

yum install ICAClient-11.0-1.i386.rpm

Doch dummerweise findet auch yum das benötigte Paket libXm.so.3 nicht…

Nach ein bisschen googeln habe ich dann herausgefunden, dass man unbedingt openmotif installieren muss. Doch auch das scheint nirgends in den Paketquellen vorhanden zu sein??
Also lade ich mir das Paket halt manuell herunter und installiere es:

3

yum localinstall --nogpgcheck openmotif-2.3.1-1.RHEL3.0.i386.rpm

Soweit so gut, also gleich nochmal versucht den Receiver zu installieren.

Doch noch immer scheint libXm.so.3 nicht vorhanden zu sein… Nach weiterer Suchzeit auf Google habe ich noch ein weiteres benötigtes Paket gefunden:

4

yum install libXaw

Doch damit wurde libXm.so.6 und nicht wie benötigt libXm.so.3 installiert. Also muss man noch ein bisschen bescheissen:

5

ln -s /usr/lib/libXm.so.6 /usr/lib/libXm.so.3

Auch bin ich oft über die Aussage gestolpert, dass möglichweise ein paar Fonts rumzicken könnten:

6
7
8

cd /usr/share/fonts/cjkuni-uming/
mv fonts.dir fonts.dir.disabled
mv fonts.scale fonts.scale.disabled

und dann war es endlich soweit:

9

yum install ICAClient-11.0-1.i386.rpm

Jetzt konnte ich den Receiver endlich installieren.
Doch damit noch nicht genug, man sollte die Applikation ja auch starten können… Und genau daran haperte es noch!
Als Ausgabe erhielt ich immer:

10

/usr/lib/ICAClient/wfcmgr: Zeile 197: Vereinbarung: Kommando nicht gefunden.

Doch nach ein bisschen Überlegen und Nachdenken war das ein kleineres Problem. Denn wenn man den Fehler so liest, so habe ich gleich an ein Problem mit der Eula gedacht. Also mal recherchieren, wie man das Anzeigen der Lizenz umgehen kann

11

touch ~/.ICAClient/.eula_accepted

Und von nun an kann ich auch unter Fedora alle Citrix Applikationen gebrauchen:

12

/usr/lib/ICAClient/wfcmgr -icaroot /usr/lib/ICAClient

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.

Ich habe vor längerer Zeit mal Nagios, ein sehr komplexes Überwachungstool, aufgesetzt, aber aus Zeitmangel habe ich mich nie wirklich mit der raffinierten, aber doch sehr komplizierten Konfiguration beschäftigt.

Nun aber ist mir das ganze wieder in die Hände gefallen und ich habe mich mal aufgemacht und wollte Nagios nicht nur zum laufen bringen, sondern auch richtig konfigurieren und überwachen lassen.

Im uu.de-Wiki, welches sonst meistens meine erste Anlaufstelle für so Fragen ist, gibt es leider nur ein unfertiger Artikel. (Wenn ich die Zeit finde, werde ich mich da dann mal ran machen) Also habe ich mir meine Informationen selbst zusammengesucht.

Die Installation von Nagios ist relativ einfach. Nagios2 gibt es sogar in den Paketquellen, Nagios3 lässt sich problemlos selbst kompilieren.

Für mich reicht aber Nagios2 voll und ganz und somit habe ich mittels der Paketverwaltung mal die Pakete installiert:

sudo apt-get install apache2, nagios2, nagios2-common, nagios-plugins

Für die Installation war es das eigentlich schon! Doch ganz so einfach ist es dann doch wieder nicht.
Unter http://localhost/nagios2 ist jetzt schon die Weboberfläche zu sehen. Jedoch fehlt noch die gesamte Konfiguration, also weiter im Konzept.

Da mein Webinterface natürlich nicht für jeden Zugänglich sein soll, habe ich mir noch ein Passwortschutz angelegt:

htpasswd -bc /etc/nagios2/htpasswd.users

Nun gilt es noch den Apache neu zu starteten, damit die Änderung auch wirksam werden:

sudo /etc/init.d/apache2 restart

Nun sollte man bereits beim Aufrufen von Nagios, immer noch unter http://localhost/nagios2, nach einem Benutzernamen und einem Passwort gefragt werden.

Nun geht es los mit der Konfiguration.
Dabei sollte ich vielleicht noch ein paar Worte über das Konzept verlieren.
Wenn man den Aufbau mal verstanden hat ist es eigentlich gar nicht mehr so kompliziert

Für meine Server habe ich ein neuer Ordner angelegt:

sudo mkdir /etc/nagios2/meinnetzwerk/
cd /etc/nagios2/meinnetzwerk/

Darin werden nun alle Dateien angelegt.
Die wichtigsten Dateien, auf welche Nagios zurückgreift, sind hosts.cfg, templates.cfg, services.cfg und hostgroups.cfg.

Besonders die templates.cfg spielt in grösseren Netzwerken mit vielen Servern eine besondere Rolle. Doch dazu später.

Wir beginnen erstmal mit dem formellen Teil. Die Datei contacts.cfg birgt den Namen und die eMail-Adresse des Systemadministrators.
Dazu erstellen wir die Datei erst neu:

sudo touch contacts.cfg

Diese füllen wir mit folgendem Inhalt:

define contact{
contact_name administrator
alias DEIN-NAME
service_notification_period 24×7
host_notification_period 24×7
service_notification_options w,u,c,r
host_notification_options d,r
service_notification_commands notify-by-email
host_notification_commands host-notify-by-email
email DEINE@EMAIL.ADRESSE
}

define contactgroup{
contactgroup_name admins
alias Nagios Administrators
members administrator
}

Nun können wir unsere ersten Server hinzufügen.
Diese werden in der hosts.cfg aufgelistet. Doch einfach die IP-Adressen einzutragen wäre natürlich viel zu einfach

define host{
host_name SERVERNAME
alias BESCHREIBUNG
address IP.ADRESSE.HIER.EINGEBEN
use generic-host
}

Hier muss für jeden Host ein neuer “define host{}” angelegt werden.

Bis auf use sind eigentlich alle Punkte selbst erklärend. Und damit kommen wir auch schon zum gut durchdachten Konzept von Nagios.
Wir könnten jede einzelne Option wie Prüfintervalle, verwendete Kommandos, Benachrichtigungen, Maximale Überprüfungen etc für jeden Host einzelne definieren. Das wären dann pro Host alleine schon 40 Zeilen.
Nun kann man sich mal überlegen, was passiert wenn ich 20 oder sogar 100 Server eintragen und überwachen will – die Komplexität steigt und es wird schnell mal unübersichtlich.

Darum kann man mittels use eine Art Link zu einem Eintrag in der Datei templates.cfg legen.

Darin kann man Profile definieren, wo alles aufgeführt ist, was bei mehreren Servern gleich ist:

define host{
name generic-host ; The name of this host template
notifications_enabled 1 ; Host notifications are enabled
event_handler_enabled 1 ; Host event handler is enabled
flap_detection_enabled 1 ; Flap detection is enabled
failure_prediction_enabled 1 ; Failure prediction is enabled
process_perf_data 1 ; Process performance data
retain_status_information 1 ; Retain status information across program restarts
retain_nonstatus_information 1 ; Retain non-status information across program restarts
check_period 24×7 ; By default, Linux hosts are checked round the clock
check_interval 5 ; Actively check the host every 5 minutes
retry_interval 1 ; Schedule host check retries at 1 minute intervals
max_check_attempts 3 ; Check each Linux host 10 times (max)
check_command check-host-alive ; Default command to check Linux hosts
notification_period 24×7 ; Linux admins hate to be woken up, so we only notify during the day
notification_interval 30 ; Resend notifications every 2 hours
notification_options d,u,r ; Only send notifications for specific host states
contact_groups nagios-admins ; Notifications get sent to the admins by default
register 0 ; DONT REGISTER THIS DEFINITION – ITS NOT A REAL HOST, JUST A TEMPLATE!
}

Dabei ist wichtig, dass unter Name in der templates.cfg und unter use in der hosts.cfg der selbe Name steht.

Natürlich kann man nicht nur Server, sondern auch einzelne Services überwachen lassen. Diese werden in der Datei services.cfg eingetragen:

define service{
use generic-service
service_description HTTP
check_command check_http!80
host_name webserver01
}

Im Gegensatz zu einem Host verwendet man hier natürlich am Anfang define service. Weiter ist hier der Punkt check_command aus dem Template entfernt worden, da dieser bei einem Service je nach Art variiert. Im Beispiel wird überprüft ob eine HTTP Verbindung auf Port 80 aufgebaut werden kann.

Auch in der templates.cfg sieht es ähnlich aus:

define service{
name generic-service ; The ‘name’ of this service template
active_checks_enabled 1 ; Active service checks are enabled
passive_checks_enabled 1 ; Passive service checks are enabled/accepted
parallelize_check 1 ; Active service checks should be parallelized (disabling this can lead to major performance problems)
obsess_over_service 1 ; We should obsess over this service (if necessary)
check_freshness 0 ; Default is to NOT check service ‘freshness’
notifications_enabled 1 ; Service notifications are enabled
event_handler_enabled 1 ; Service event handler is enabled
flap_detection_enabled 1 ; Flap detection is enabled
failure_prediction_enabled 1 ; Failure prediction is enabled
process_perf_data 0 ; Process performance data
retain_status_information 1 ; Retain status information across program restarts
retain_nonstatus_information 1 ; Retain non-status information across program restarts
is_volatile 0 ; The service is not volatile
check_period 24×7 ; The service can be checked at any time of the day
max_check_attempts 3 ; Re-check the service up to 3 times in order to determine its final (hard) state
normal_check_interval 5 ; Check the service every 10 minutes under normal conditions
retry_check_interval 1 ; Re-check the service every two minutes until a hard state can be determined
contact_groups nagios-admins ; Notifications get sent out to everyone in the ‘admins’ group
notification_options c,r ; Send notifications about warning, unknown, critical, and recovery events
notification_interval 20 ; Re-notify about service problems every hour
notification_period 24×7 ; Notifications can be sent out at any time
register 0 ; DONT REGISTER THIS DEFINITION – ITS NOT A REAL SERVICE, JUST A TEMPLATE!
}

Was noch wichtig zu erwähnen ist, dass Konfiguration in der hosts.cfg denen in templates.cfg vorgezogen werden!

Und damit noch lange nicht genug
Auch inner der templates.cfg-Datei werden keine redundanten Einträge benötigt:

define service{
name service1 ; The name of this
…allgemeine settings…
}

define service{
name service2
use service1
…spezifischere settings…
}

Ich kann also innerhalb der templates auch mittels use auf einen schon vordefinierten Eintrag verweisen.

In der Datei hostgroups.cfg kann man Einstellungen anhand vom Typ eines Servers vornehmen. Intressant wird dies aber erst wenn man mehrere gleiche Server, mit gleichen Aufgaben oder Services betreibt.
Da dies bei mir aber nicht der Fall ist, habe ich mich damit nicht weiter beschäftigt.

Nun fehlt uns noch eine Datei: die timeperiods.cfg.
Diese ist in der Standardkonfiguration bereits in Ordnung und kann einfach kopiert werden:

sudo cp /etc/nagios2/conf.d/timeperiods_nagios2.cfg /etc/nagios2/meinnetzwerk/timeperiods.cfg

Nun haben wir mal eine Grundkonfiguration erstellt und können das Ergebnis anschauen. Doch dazu müssen wir Nagios erst mal noch mitteilen, dass wir nun einen eigenen Ordner, nämlich /meinnetzwerk/ verwenden!
Dazu öffnen wir die Datei /etc/nagios2/nagios.cfg mit einem Editor und ergänzen diese mit folgendem Eintrag:

cfg_dir=/etc/nagios2/meinnetzwerk

Bevor wir nun unseren Deamon neustarten, prüfen wir noch unsere Konfiguration.
Dazu beinhaltet der Befehl nagios2 den Schalter -v:

nagios2 -v /etc/nagios2/heimnetzwerk/hosts.cfg
nagios2 -v /etc/nagios2/heimnetzwerk/services.cfg
nagios2 -v /etc/nagios2/heimnetzwerk/templates.cfg

Erhält man hier keinen Fehler, so kann man nagios2 neustarten:

sudo /etc/init.d/nagios2 restart

Nun weden in der Weboberfläche bereits die ersten Server und Services aufgeführt und dargestellt.
Wenn man das aber tatsächlich einsetzen will, so sollte man die Konfiguration noch extrem verfeinern und auf seine Bedürfnisse abstimmen!

Was ich bis jetzt noch nicht hingekriegt habe, ist das überwachen von Prozessen, Ressourcen wie CPU, RAM, Diskspace und anderen spezifischen, lokalen Vorgängen.

Dies sollte aber kein grosses Problem mehr sein, dazu aber in einem anderen Beitrag mehr!

Die Installation war dank einer hervorragenden Anleitung im UU.de-Wiki überhaupt kein Problem. Jedoch, da mein svn nicht öffentlich jedem zugänglich sein soll, habe ich in der /etc/apache2/mods-enabled/dav_svn.conf einen fixen User eingetragen:

<Location /svn>
    DAV svn
    SVNPath /var/local/svn
    AuthType Basic
    AuthName "svn"
    AuthUserFile /etc/apache2/dav_svn.passwd
    Require user compr00t
</Location>

Nach der Installation dann ist mir aufgefallen, das Subversion den ganzen Traffic per http transportiert, was mir nicht so wirklich zusagen wollte.

Also habe ich meinen Apache2 auf Port 443 verschoben, so dass alles per SSL gesichert wird.

Das “Umkonfigurieren” ist eigentlich überhaupt kein Problem, wenn man weiss wie Doch leider hatte ich nur eine wage Ahnung, weshalb sich das ganze über mehrere Stunden in die Länge zog.

Ich versuche hier nochmals wiederzugeben, was ich so alles rumgebastelt habe

Als erstes habe ich einen neuen Virtualhost angelegt unter /etc/apache2/sites-available/ mit dem Namen ssl und mit folgendem Inhalt gefüllt:

<VirtualHost *:443>
    ServerAdmin webmaster@example.com
    DocumentRoot /var/www/svn/
    SSLEngine on
    SSLCertificateFile /etc/apache2/ssl/apache.pem
</VirtualHost>

Nun wird der neue Virtualhost aktiviert und der alte deaktiviert

sudo a2ensite ssl
sudo a2dissite default

Danach wird Port 443 aktiviert. Dazu überschreibt man die Datei /etc/apache2/ports.conf mit folgendem Eintrag:

Listen 443

Jetzt fehlt noch ein Zertifikat für die gesicherte Verbindung. Dazu muss das Packet openssl installiert sein:

sudo apt-get install openssl

Nun kann man sein Zertifikat erstellen:

mkdir -p /etc/apache2/ssl
openssl req -new -x509 -days 365 -nodes -out /etc/apache2/ssl/apache.pem\
-keyout /etc/apache2/ssl/apache.pem

Jetzt muss nur noch das Module ssl aktiviert werden:

sudo a2enmod ssl

Jetzt gilt es noch den Apache neuzustarten:

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

Und wenn beim restart kein fail als Antwort rauskommt, so sollte ab sofort die Weboberfläche nun über https://localhost/svn verfügbar sein.

Ich hoffe mal, ich habe nichts vergessen

Als nächstes ist nun geplant, die etwas zu schlichte Weboberfläche von Subversion durch Websvn zu ersetzten.

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]

Doch als ich mich mittels dem openssh-client und dem Befehl “ssh user@meinserver.ch” einloggen wollte erhielt ich einen Fehler:

shell request failed on channel 0

Also habe ich auch gleich versucht mich mittels Putty zu verbinden, um eine zweite Meinung einzuholen, weil ich erst dachte, mein Router hätte mich blockiert…

Doch komischerweise hatte Putty überhaupt keine Probleme!!

Als nächstes dachte ich mir, ob es vielleicht an der Version liegen kann, da, wie mir mal zu Ohren gekommen ist, iLO 1 nur SSH1 funktionieren soll. Doch leider wollte auch dies nicht funktionieren.

Also habe ich mich nochmals mittels “SSH” versucht zu verbinden, nur dass ich mir diesmal die Debug Informationen anzeigen liess:

ssh -v user@meinserver.ch

Abgebrochen wurde die Verbindung sobald der openssh-client versuchte, meine Sprache zu übertragen:

debug1: Sending env LANG = de_CH.UTF-8

Nach längerem hin und her, und mehreren gescheiterten Versuchen habe ich dann mit “unset LANG” meine Sprache “gelöschen”. Und man glaubt es kaum, ich konnte mich auch mit dem openssh-client verbinden.

Dummerweise muss ich das nun jedes mal machen, bevor ich mich verbinden kann.

Wenn also jemand eine Lösung hat, immer her damit

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

Einer der besten Tipps ist der SSH-Zugriff. Dieser ist zwar nicht offiziell unterstützt, ist aber eine in ESXi integrierte Funktion, es sind also keine weiteren Installationen nötig.

Um SSH zu aktivieren muss man zuerst in eine Konsole wechseln. Dies geht wie unter Linux mit ALT + F1. Im Gegensatz zu einem normalen Linux ist hier nur eine Konsole aktiv und nicht alle 6.

Nun folgt der schwierigste Part

Man muss blind und ohne Rückmeldung das Wort “unsupported” und das eigene Passwort eintippen.

Ab nun hat man eine normale Konsole:

~ #

Nun muss man in der inetd.conf SSH aktivieren. Dazu öffnet man diese in einem Editor,

vi /etc/inetd.conf

suchen den Eintrag

#ssh

und entfernt die Rauten wodurch bei der Zeile der Kommentar entfällt. Nun heisst es den physikalischen Server neustarten und man kann von nun an per SSH zugreifen.

Nun kann man sich per SSH alle VM’s ausgeben lassen,

vim-cmd vmsvc/getallvms

einzelne VM’s starten

vim-cmd vmsvc/power.on ID

oder den aktuellen Status abfragen.

vim-cmd vmsvc/power.getstate ID

Es gibt sicher noch unzählige mehr, aber ich denke das sind mal die wichtigsten

Einen weiteren Tipp, ist die Möglichkeit mehrere VMs automatisch mit dem Serverstart zu starten. Für mich ist diese Funktion sehr nützlich da ich meinen Server per WOL boote, wenn ich ihn brauche.