You are currently browsing the archives for the “Security” category.

Nagios Plugin für F-Secure Signature check

4. Januar 2010 // Posted in Linux, Security, amavisd-new, nagios (Tags: , , , , , , ) |  1 Comment

Da ich F-Secure als AV-Programm einsetze habe ich nach einem Nagios-Plugin gesucht, welches die Signaturen auf Aktualität prüft. Leider bin ich nicht fündig geworden. Für Clam-AV gibt es aber einige Plugins. Dieses check_clamav habe ich dann einfach an F-Secure angepaßt.

Die Zeile chomp(my $fsav_ver = `/usr/bin/chroot /var/spool/amavis $fsav_cmd –version`); muß unter Umständen angepaßt werden, da ich F-Secure mit amavisd-new in einem chroot verwende.

#!/usr/bin/perl -w
#
# Copyright (c) 2005-2008 Darren Spruell <phatbuckett@gmail.com>, Modified by Andreas Gegner <kabeldesigner@web.de>
#
# Permission to use, copy, modify, and distribute this software for any
# purpose with or without fee is hereby granted, provided that the above
# copyright notice and this permission notice appear in all copies.
#
# THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
# WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
# MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
# ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
# WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
# ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
# OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
#
################################################################################
# This script is used to compare the version and signature level of the
# currently running f-secure daemon with the current date
#
# In order to use this script, you might need to make the following adjustments:
#  - Set the "use lib" path correctly (where utils.pm is located.)
#  - Set the path to your fsav binary in $fsav_cmd.
#
# This plugin requires the Net::DNS Perl module.
################################################################################

# Plugin directory / home of utils.pm.
use lib "/usr/local/nagios/libexec";
use utils qw(%ERRORS &print_revision &support &usage);
use Getopt::Long qw(:config no_ignore_case bundling);
use File::Basename;
use Net::DNS;

use strict;

# Path to installed fsav binary.
my $fsav_cmd  = "/usr/bin/fsav";

# Leave the rest of this alone:
my $prog_name  = basename $0;
my $prog_ver   = "1.2";

my $warn_val = 1;  # Default - override with -w arg
my $crit_val = 2;  # Default - override with -c arg
my $help_val = 0;  # Off unless -h arg
my $verb_val = 0;  # Off unless -v arg
my $vers_val = 0;  # Off unless -V arg

my ($msg, $rev_word, $rr, $status, $status_print, $sec, $min, $hour, $day, $month, $year, $daylightsavings, $yearOffset, $dayOfWeek, $dayOfYear, $date);

# Gives us a way to print out verbose debug information to the screen when user
# passes in a -v argument.
# print_debug() should receive one parameter: a text string to print out.
sub print_debug() {
my $message = shift;
if ($verb_val == 1) {
print "DEBUG: " . $message . "\n";
}
}

# Looks up and returns the current CVD version information from
# clamav.net.
sub lookup_current() {
#my $res = Net::DNS::Resolver->new;
#my $query = $res->search("current.cvd.clamav.net", "TXT");
#if ($query) {
#    foreach $rr (grep { $_->type eq 'TXT' } $query->answer) {
#        &print_debug("Net::DNS found result: (TXT) " . $rr->txtdata);
#        return $rr->txtdata;
#    }
#} else {
#    warn "query failed: ", $res->errorstring, "\n";
#}
}

# comp_sig_ver() should receive three parameters: remote signature database
# version, local signature database version, and build date of local
# signatures database.
sub comp_sig_ver() {
my $sig_rem   = shift;
my $sig_local = shift;
my $sig_date  = shift;
my $diff = 0;
my $msg = "";

if ($sig_local != $sig_rem) {
$diff = $sig_rem - $sig_local;
$rev_word = ($diff == 1) ? "revision" : "revisions";
if ($diff >= $crit_val) {
&print_debug("Installed daily.cvd is behind clamav.net");
$status = $ERRORS{'CRITICAL'};  # Will exit with CRITICAL status
$status_print = "CRITICAL";
} elsif ($diff >= $warn_val) {
&print_debug("Installed daily.cvd is behind clamav.net");
$status = $ERRORS{'WARNING'};   # Will exit with WARNING status
$status_print = "WARNING";
} else {
&print_debug("Installed daily.cvd is behind clamav.net");
$status = $ERRORS{'OK'};  # Will exit with OK status
$status_print = "OK";
}
$msg  = "fsav " . $status_print . ": daily.cvd " . $sig_local .
" out of date by " . $diff . " " . $rev_word;
} else {
&print_debug("Installed daily.cvd matches latest from clamav.net");
$status = $ERRORS{'OK'};  # Will exit with OK status
$msg    = "ClamAV OK: daily.cvd " . $sig_local . " (" . $sig_date .
") is up to date";
}
return $msg, $status;
}

# Show usage information
sub show_help() {
print <<END;
$prog_name Nagios plugin $prog_ver (c) 2005-2008 Darren Spruell <phatbuckett\@gmail.com>

Perl Check fsav plugin for Nagios

Usage: $prog_name [-w <warn>] [-c <crit>] [-V] [-v] [-h]

-w, --warning=INTEGER
Number of revisions behind current daily.cvd to generate a warning state (Default: 1)
-c, --critical=INTEGER
Number of revisions behind current daily.cvd to generate a critical state (Default: 2)
-V, --version
Output version information for the plugin
-v, --verbose
Enable verbose output
-h, --help
Show this help
END
}

GetOptions (
"w=i" => \$warn_val, "warning=i" => \$warn_val,
"c=i" => \$crit_val, "critical=i" => \$crit_val,
"h" => \$help_val, "help" => \$help_val,
"V" => \$vers_val, "version" => \$vers_val,
"v" => \$verb_val, "verbose" => \$verb_val,
);

if ($help_val != 0) {
&show_help;
exit $ERRORS{'OK'};
}

if ($vers_val != 0) {
&print_revision($prog_name,$prog_ver);
exit $ERRORS{'OK'};
}

# Make sure the binary exists.
if (-x $fsav_cmd) {
&print_debug("Found fsav at $fsav_cmd");
} else {
&print_debug("Can't execute fsav at $fsav_cmd");
die("FATAL: Unable to execute $fsav_cmd");
}

&print_debug("Threshhold values: warning=$warn_val, critical=$crit_val");

#
chomp(my $fsav_ver = `/usr/bin/chroot /var/spool/amavis $fsav_cmd --version`);

#chomp(my $dnstxt_ver = &lookup_current());
($sec, $min, $hour, $day, $month, $yearOffset,$dayOfWeek, $dayOfYear, $daylightsavings) = localtime();
$year = 1900 + $yearOffset;
$date = "$year-$month-$day";
chomp(my $dnstxt_ver = $date;

# Parse what we get from clamd -V and our DNS query
my @fsavresults = split(/\//,$fsav_ver);
my @txtresults   = split(/:/,$dnstxt_ver);

# Get the currently running ClamAV sig level and cvd date out of this
my $local_latest_daily   = $fsavresults[1];
my $local_latest_date    = $fsavresults[2];

&print_debug("Local daily.cvd dated $local_latest_date");
&print_debug("Local daily.cvd version = $local_latest_daily");

# Get the latest ClamAV daily signatures version out of this
my $fsav_latest_daily   = $txtresults[2];
&print_debug("Latest daily.cvd version = $fsav_latest_daily");

my @prog_sig_res = &comp_sig_ver($fsav_latest_daily, $local_latest_daily,
$local_latest_date);

print $prog_sig_res[0] . "\n";
exit $prog_sig_res[1];

was ist besser? Hardware-Raid oder Software-Raid?

19. Juli 2009 // Posted in Datenrettung, Linux, Security, Windows (Tags: , , , , , , ) |  No Comments

Der Artikel über Raid auf wikipedia ist ja sehr interessant. Im Artikel wird aber, meiner Meinung nach, ein Software-Raid besser dargestellt als ein Hardware-Raid. Ich persöhnliche würde z.B. nie auf ein Software-Raid oder Fake-Raid setzen, da ich selbst halt weniger gute Erfahrungen gemacht habe. Falls Software-Raids besser als Hardware-Raid-System sind, warum gibt es dann noch Hardware-Raids? Hierzu würden mich nun eure Meinungen und Erfahrungen interessieren. Wo würdet Ihr welches Raid-System einsetzen und warum?

Gerüchte über Lücke in openssh nicht bestätigt

10. Juli 2009 // Posted in Linux, Security, openssh (Tags: , , , , , , , , , , ) |  No Comments

Die Gerüchte um eine Sicherheitslücken in openssh hab sich nicht bestätigt. Die Einbrüche basieren angeblich auf einer erfolgreichen Brute-Force-Attacke gegen ältere openssh-Server. Brute-Force-Attacken können aber normalerweise relativ einfach abgewehrt werden. Man muß einfach nur einen ungewöhlichen Benutzernamen und ein gutes Passwort oder Zertifikate verwenden.

Um sich auch komplizierte Passwörter zu merken gibt es einen einfachen Trick. Man bildet einfach einen Satz wie z.B. “Linux ist das Beste was mir je passiert ist” und nimmt von jedem Wort den Anfangsbuchstaben. Daraus ergibt sich das Passwort “LidBwmjpi”. Auch wenn SSH-Angriffe inzwischen verteilt über Bot-Netze laufen ist es sehr unwahrscheinlich das dieses Passwort geknackt werden kann. Passwort-geschütze Zertifikate sind noch sicherer. Bei der Verwendung von Zertifikaten kann es aber bei größeren Latenzzeiten (>500ms) zu Problemen kommen.

Wie openssh noch weiter abgesichert werden kann habe ich schon hier beschrieben. Ich empfehle trotzdem jedem ein Update auf die aktuellste openssh-Version 5.2. Falls es keine Packete für die Distribution gibt kann man openssh auch sehr einfach selber bauen.

tar -xf openssh….
cd openssh….
./configure &> conf_log   (in der conf_log-Datei findet man aufgetretene Fehler beim configure-Durchlauf)
oder alternativ
./configure –with-pid-dir=/var/run/my_piddir  (nur notwendig, falls man mehr als einen sshd auf einem PC einsetzt)
make
make install

Falls beim configure-Durchlauf Fehler auftreten fehlen normalerweise einfach ein paar Packete (z.B. gcc,make,openssl-devel). Statt make install kann man die Binaries auch von Hand in die entsprechenden Verzeichnisse kopieren. Unter Umständen muß, z.B. bei einem Update von einer openssh-Version 4.x, die Konfiguration angepaßt werden.

Nagios Plugin Empfehlung (Ablaufdatum eines Zertifikates unter Linux prüfen)

1. Juli 2009 // Posted in Security, apache, nagios, openvpn, postfix (Tags: , , , , , , ) |  No Comments

Verschlüsselungs bzw. sichere Authorisations-Mechanismen werden in Zeiten steigender Internet-Kriminalität  immer wichtiger. Zertifikate spielen hierbei eine sehr wichtige Rolle. Es ist egal ob sie für die Email-Transport-Verschlüsselung, Ldap-TLS/SSL-Verschlüsselung, OpenVPN oder für einfach nur für einen HTTPS-verschlüsselten Webserver benutzt werden. Ist ein Zertifikat abgelaufen, so leidet die Vertrauensstellunge gegenüber dem Dienst oder der Dienst (z.B. Mail-Transport-Verschlüsselung) funktioniet nicht mehr. Wer hat nicht schon einmal Warnung seines Browsers in den Wind geschlagen und eine Seite trotzdem aufgerufen bzw. eine entsprechende Ausnahme hinzugefügt.

Ein gutes Script um abgelaufene Zertifikate zu vermeiden habe ich hier gefunden. Das Script kann per cron oder mit der Option -n gestartet als Nagios-Plugin gestartet werden. Damit sollten abgelaufene Zertifikate der Vergangenheit angehören.

Quelle: prefetch.net

SSH Netzwerklaufwerk unter Windows mit Dokan SSHFS

30. Juni 2009 // Posted in Linux, Security, Windows, openssh (Tags: , , , , ) |  1 Comment

Für Linux gibt es ja schon seit einiger Zeit die Möglichkeit mittels fuse/sshfs ein entferntes Dateisystem sicher per ssh einzubinden und direkt auf dem Remote-Dateisystem zu arbeiten (ohne Umweg über sftp/scp).

Mit Dokan SSHFS kann man auch unter Windows ein Netzlaufwerk über ssh einbinden. Damit kann man sicher Dateien übertragen bzw direkt bearbeiten. Die Idee ist an sich genial und Dokan sshfs ist sicher ein Programm, welches sich jeder Admin mit einem Windows-Client wünschen würde. Nach meiner Erfahrung mit dem Programm gibt es aber ab und zu Probleme bei der Verwendung. Das anzeigen von einem Verzeichnis mit sehr vielen Dateien funktioniert z.B. nicht.

Wenn das Programm irgendwann einen Stand erreicht mit dem man es in einer Produktiv-Umgebung einsetzen kann, dann wird das die Sicherheit im Netzwerk erhöhen (auch wenn es an Samba nie von der Performance her rankommen wird).

wie kann man sicher surfen oder wie schütze ich mich vor Viren(inWindows)?

17. Juni 2009 // Posted in Linux, Security, Virtualisierung, Windows (Tags: , , , , , , ) |  No Comments

Ich höre des öfteren Frage wie: “Kann ich einen Virus entfernen ohne zu formatieren?”. Meine Antwort lautet dann meistens: sicher kann man einen Virus entfernen. Die Frage hier ist nur, wie lange braucht man und läuft das Betriebssystem hinterher noch stabil und vor allem “Kann ich 100prozentig sicher sein das der Virus/Trojaner runter ist?”. Hier habe ich schon erklärt wie man einen Virus “eventuell” entfernen kann.

jetzt möchte ich aber auch mal zeigen, wie man sich vor Viren/Trojanern schützen kann. Als erstes kann ich die Firefox mit der Erweiterung noScript empfehlen. Diese Erweiterung ist NUR für den Browser Firefox. Die Internet Explorer 7 bzw. 8 haben einen integrierten Phishing-Filter. Zu diesem kann ich aber nicht viel sagen, da ich kein Internet Explorer verwende :-)

Firefox hat einen intergierten Phishing-Schutz und warnt hiermit schon beim aufrufen der Webseite den Benutzer vor möglichen Gefahren. Die Erweiterung NoScript blockiert standardmäßig alle aktiven inhalte einer Webseite. Beim aufrufen einer Webseite wird am unteren Rand eine Leiste mit Einstellungen angezeigt. Und ab hier wird es etwas kompliziert.

Mit aktiven Inhalten sind z.B. Flash-Videos (z.B. youtube) und JavaScript (z.B. für aufklappbare Menüs) gemeint. Bei Einstellungen am unteren Rand kann man nun einzelne Domains temporär oder dauerhaft freigeben bzw. sperren. So lange man der aufgerufenen Webseite vertraut, kann man diese unter Einstellungen dauerhaft freigeben. Gibt man hier zu wenig frei, funktioniert die Webseite gar nicht oder nur eingeschränkt. Gibt man zuviel frei wird man unter Umständen mit Werbung überschüttet oder ein Virus/Trojaner kann sich installieren (sofern die aufgerufene Webseite entsprechenden Schadcode verbreitet). Domains wie z.B. heise.de oder google.de o.ä. kann man bedenkelos freigeben. google-analytics.com würde ich aber z.B. sperren, da hierüber google analysiert, wo der Besucher herkommt bzw. welchen Seiten er abruft.

Jeder, dem das zu aufwändig ist, kann sich von vmware die 2 Software-Packet VMware-Player und Browser-Appliance runterladen. Leider muß man sich für den VMware-Player kostenlos registrieren. In Hinblick auf die Sicherheit lohnt es sich aber. Nach der Installation vom vmware-Player einfach den PC neustarten die Browser-Appliance entpacken, über die vmx-Datei starten und warten. Der VMWare-Player fährt nun ein virtuelles Linux-System ein einem “kleinen” Fenster hoch. In diesem kleinen Fenster (welches man natürlich auch zum Vollbild vergrößern kann) läuft nun ein eigenständiges Linux-Betriebssystem. Am oberen Bildrand sieht man das Icon für den Firefox. Den Internet Explorer gibt es ja für Linux nicht. In dieser Virtuellen Umgebung kann man ganz beruhigt surfen. Falls man eine bösartige Webseite aufruft wird der Installationsversuch des Virus/Trojaners scheitern. Konnte sich der Virus/Trojaner doch erfolgreich installieren fährt man einfach das virtuelle Linux runter, löscht das Verzeichnis, entpackt es neu aus dem Zip-Archiv und kann nach dem starten weiter surfen.

quelle: mozilla.org, wikipedia.org, vmware.com, firefox-browser.de

amavisd-new und F-Secure oder anderes AV-Programm im chroot

3. Juni 2009 // Posted in Linux, Security, amavisd-new, postfix (Tags: , , , ) |  No Comments

Ich benutze zur Mail-Filterung postfix, amavisd-new, spammassassin und als Antiviren-Programm F-Secure Linux-Server-Security. Amavisd-new in ein chroot verschieben ist nicht wirklich ein großes Problem. Einfach ein Verzeichis anlegen, in der Konfiguration eintragen, die entsprechenden Dateien und Bibliotheken im chroot anlegen/kopieren und amavisd-new funktioniert.

Bei einem Antiviren-Programm geht das aber nicht so einfach. Ich habe lange nach einer Lösung für F-secure gesucht. Es funktionierte weder mit Links noch mit einer Änderung der Start-Datei unter /etc/init.d stabil.

Vor ein paar Tagen habe ich dann aber doch eine sehr einfache Lösung gefunden. Als erstes muß man screen installieren. Bei screen handelt es sich um eine Terminal-Emulation. Man kann mit screen auf der Konsole ein Programm, welches z.B. Fehlermeldungen nach stdout ausgibt, starten und sich aus dem screen-Terminal ausloggen. Logt man sich wieder ein, sieht man alle inzwischen aufgelaufenen Fehlermeldungen. Man kann also auf der screen-Konsole weiterarbeiten, das Programm unterbrechen oder was auch immer….

Um F-Secure Linux-Server-Security nun im chroot benutzen zu können, muß man als erstes alle Dateien in’s chroot in die entsprechenden Verzeichnisse kopieren. Bei einigen AV-Programmen kann man jetzt schon mittels screen ein chroot mit folgendem Befehlen starten:
screen -t test
chroot /chroot-Verzeichnis
/etc/init.d/AV-Programm start

Bei F-Secure-Linux-Server-Security funktioniert das so noch nicht. F-Secure braucht noch Zugriff auf das Proc-Verzeichnis. Links (egal ob Symlink oder Hardlink) funktionieren nich, da wir uns ja in einem chroot befinden. Um das Proc-verzeichnis auch im chroot-Verzeichnis benutzen zu können muß man einfach nur die /etc/fstab ändern. In der Datei fstab sollte schon ein Eintrag für proc vorhanden sein. Einfach diesen in eine neue Zeile kopieren und als Mount-Verzeichnis das chroot-Verzeichnis einstellen.

Jetzt kann F-Secure gestartet werden und es sollte funktionieren. Falls nicht, muß man nochmal alle Datei-Rechte, Bibliotheks- und Programm-Abhängigkeiten und die logs kontrollieren.

ssh absichern (mit iptables, ssh-blacklist, chroot)

1. Juni 2009 // Posted in Linux, Security, chroot, iptables, openssh (Tags: , , , , , , , , , , , ) |  No Comments

SSH ist im Prinzip DAS Werkzeug um einen Linux-Server zu administrieren oder Daten über das Netzwerk zu kopieren. Durch die weite Verbreitung ist es aber auch zum Ziel von Hackern/Crackern o.ä. geworden. Geknackte Linux-Server werden dann meistens als Command & Control-Server für Bots benutzt. Einige Provider von Root-Server sind inzwischen dazu übergegangen einen geknackten Server komplett zu sperren und nur noch SSH zuzulassen. Der Server-Besitzer/-Admin kann dann in Ruhe den Server säubern oder die Daten sichern und ihn neu aufsetzen. Auch wenn das für den Webseiten-Betreiber ärgerlich ist, ist es denoch richtig, da jeder geknackte Server eine Gefahr für andere PC’s darstellt.

Früher wurde entweder mit einer Wörterliste bzw. einer Brute-Force-Attacke und dem root-Account der Server versucht zu knacken. Inzwischen werden auch von Bots gesammelte Nutzerdaten bzw. verteilte Bot-Netz-Angriffe beim knacken von SSH-Server benutzt. Das heißt, ein Bot probiert 3 Passwörter aus und meldet das Ergebnis an den Command & Control-Server. Der nächste Bot probiert dann andere Passwörter usw…. Das macht es schwierig solche Angriffe per Blacklist abzuwehren.

Die einfachste Möglichkeit Angriffe zu erschweren ist den SSH-Port auf einen anderen Port zu ändern. Die Ports oberhalb von 40000 oder 50000 werden selten gescannt. Wer macht sich schon die Arbeit alle 65535 Ports eines einzigen Servers mit einem Portscanner zu scannen. Hierbei sollte man aber eins beachten. Falls man sich aus anderen (Firmen-)Netzen auf diesen Server per SSH verbinden will, dann muß dieser Port auch freigegeben sein. Falls dies nicht möglich ist, hat man praktisch keine andere Wahl, als den Standard-Port 22 zu benutzen.

Als nächstes kann man root mit “DenyUsers root” komplett von ssh aussperren. Vorher muß man natürlich einen alternativen Account anlegen UND testen!!!. Bei der Wahl des Benutzers kann man der Phantasie freien Lauf lassen. Er darf nur kein Standard-Benutzer bzw. ein Standard-Passwort sein. Ausgefallene Benutzernamen erschweren Angriffe erheblich. Mit “AllowUsersBenutzernme” kann man openssh noch anweisen, nur diesen einen Benutzer zuzulassen.

Als nächstes können wir mit ChrootDirectory den Benutzer noch in ein Change-Root einsperren (ich weiß, jetzt wirds paranoid). Das hat aber einen ganz wichtigen Hintergrund. Wenn man das Chroot mittels Bash (.bashrc,bash.bashrc und profile) soweit einschränkt das der User quasi nichts mehr machen kann außer einloggen und ausloggen, dann ist das ideal für einen Remote-Zugriff per TCP-Forwarding. Selbst wenn der Account gehackt wird, kann der Angreiffer nichts machen und er muß erstmal rausfinden, ob TCP-Forwarding funktioniert und wohin überhaupt. Das Chroot-Direktory kann man noch auf eine extra-Partition packen und diese ro(read-only) mounten. UmTCP-Forwarding zu aktivieren muß einfach “AllowTcpForwarding yes” in die ssh-Daemon-Konfiguration eingetragen werden.

Weitere wichtige Einstellungen:

  • PermitRootLogin – der User ist mit DenyUsers zwar schon ausgesperrt, aber es schadet nichts das auch auf no zu setzen
  • Protocol – sollte unbedingt auf 2 gesetzt werden
  • UseDNS – aus Performancegründen würde ich das auf no setzen
  • TCPKeepAlive – falls man immer länger auf dem Server arbeitet auf yes setzen
  • HostbasedAuthentication – unbedingt auf no setzen
  • PrintMotd – auf no setzen, da der Angreifer sonst auch ohne Login Daten über Architektur/Betriebssystem sieht
  • PrintLastLog – falls man nur alleine auf dem Server arbeitet egal, aber falls mehrere Benutzer sich einloggen können würde ich es aus Datenschutzgründen abstellen.
  • Strictmode – auf yes setzen
  • MaxAuthtries – ich habs auf 3 gesetzt
  • MaxStartups – hab ich auf 6 gesetzt
  • Subsystem Sftp kann man löschen oder mit # auskommentieren

Als letztes installieren wir noch sshblack. Hierbei handelt es sich um ein Perl-Script, welches eine Liste über fehlgeschlagene Logins führt und bei einem einstellbaren Schwellenwert die IP des Angreiffers für einen frei einstellbaren Zeitraum mittels iptables sperrt. Hierfür muß aber eine iptables-Firewall installiert bzw. eingerichtet werden. (dazu werde ich später noch etwas schreiben)

Jetzt wird sicher der eine oder andere sagen, man kann doch einen SSH-Server auch mit Zertifikaten absichern. Das ist vollkommen richtig. Das Problem dabei ist aber, das man dann nicht mehr von überall auf der Welt draufzugreifen kann. Ein Freund war mal in Indonesien und er hatte einen ping von etwa 500ms. Daran scheitert eine SSH-Verbindung. Nur mit einen Passwort funktioniert das Login aber. Man muß sich also fragen ob man nur aus Deutschland auf den Server zugreifen will oder von überall. In der oben beschriebenen Konfiguration ist der SSH-Server auch nur für TCP-Forwarding ausgelegt.

Man könnte also einen zweiten SSH-Server hinter den geschützen Server aufstellen oder auf der lokalen IP-Adresse 127.0.0.1 installieren und dann über TCP-Forwarding darauf zugreifen. Normale User, welche nichts auf irgendeinem Server per ssh zu suchen haben können so auch sicher remote ihre Mails abrufen. Ich würde z.B. eine Exchange-Server oder Lotus-Domino-Server nie direkt an’s Internet anschliessen, aber das ist Ansichtssache.