You are currently browsing posts tagged “chroot”

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];

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.