Das Gateway in eine Festung verwandeln

In diesem Kapitel behandeln wir Konzepte um das vorher installierte System noch sicherer zu machen (oder auch zu "härten").

Inhalt

Einleitung

Im vorherigen Beitrag haben wir ein sicheres Linux Gateway mit Router und Firewall Funktion erstellt. (Falls du den vorherigen Artikel: ((Router-Firewall selbst Bauen|Router / Firewall selbst Bauen)) nicht gelesen hast, solltest du dies jetzt tun, da dieser Artikel auf dem vorherigen basiert.) Jetzt kommt die Feinarbeit, das umwandeln unseres Gateways in eine Festung.
Das erste was man jetzt aber verstehen muss ist, es gibt keinen Weg um komplett sicher zu sein. Es ist einfach nicht genügend Zeit vorhanden um alles zu tun; Grosse Firmen stellen riesige Informatik Abteilungen an, deren einziges Lebensziel darin besteht ihre Netzwerke abzusichern und werden immer noch geknackt.
Unser richtiges Ziel hier ist es die freundlichen Leute freundlich zu behalten, die Script Kiddies und Würmer draussen zu halten und den Rest zu verlangsamen um dir die Möglichkeit zu geben diese zu Entdecken bevor sie in deinem Netzwerk Schaden anrichten können.
Idealerweise fängt diese Sicherheit schon nach einer sauberen Installation an, bevor das System je ans Internet angeschlossen wird.

System Updates und Sicherheitsratschläge

In der Welt der IT-Sicherheit ist Wissen Macht. Sicherheitsexperten sind immer einen Schritt hinter den Crackern, viele Sicherheitslücken werden nicht von den Sicherheits- Experten, aber von den Crackern entdeckt.
Du musst dich über neue Probleme immer auf dem neuesten Stand halten und solltest vor allem die Programme updaten, sobald eine neue Version rauskommt.

Tippe regelmässig

aptitude update && aptitude upgrade -s

auf deinem Gateway ein; dies zeigt dir eine Liste aller installierten Pakete für die es eine neue Version gibt.

Falls du wirklich aktiv sein willst, solltest du zu www.securityfocus.com gehen und dich sowohl zur BugTraq wie auch zur CERT Mailingliste anmelden.

Physische Sicherheit

Für Heimanwender stellt die physische Sicherheit kein Problem dar, in einer Firma sollte man das Gateway auch physisch absichern, damit niemand ungewollt Sachen installieren-, den Netzstecker ziehen kann, usw.
Folgende Ratschläge sind hierbei -je nach Bedarf- hilfreich:

  • Alle Laufwerke, wie CD-ROM, Diskette, usw. entfernen
  • Alle nicht benötigten Anschlüsse wie z.B. USB, Serielle Schnittstelle, usw. deaktivieren oder entfernen
  • Den Gateway Computer in einem Schrank oder Tresor einschliessen
  • Die Steckdose so versiegeln, dass sie von aussen nicht mehr erreicht werden kann
  • Ein Notstrom-Gerät an das Gateway anschliessen; dieses sollte zusammen mit dem Gateway im verschlossenen Schrank stehen

Wie gesagt, obige Ratschläge sind für viele Leute nicht erforderlich; ich würde dennoch mindestens die Laufwerke aus dem Gateway Computer entfernen, sobald er stabil läuft.

Benutzer Accounts und Passworte

Neben dem root Account und den spezial Accounts, welche später behandelt werden, sollte es nur einen User Account geben. Der root und User Account sollten gute Passworte haben. Ein gutes Passwort ist mindestens 8 Zeichen lang, besteht aus einem mix aus gross- und Kleinbuchstaben, Nummern, Sonderzeichen und ist kein Wort das in einem Wörterbuch vorkommt. Es ist ebenfalls eine gute Idee die Passworte von Zeit zu Zeit zu ändern und schreib sie nicht auf einen auf den Monitor geklebten Zettel, wo jeder es lesen kann. Benutze verschiedene Passworte für jeden Computer im Netzwerk, denn so wenn ein System geknackt wurde, wird ein Angreifer immer noch nicht Zugang zu den anderen Systemen im Netzwerk haben. Nochmals, weil Passwörter knacken Zeit braucht, wirst du ihn hoffentlich entdecken bevor er zu weit kommt.

Ausserdem sollte man remote (auch im internen Netz) Benutzer nur mittels private/public Key aufs System lassen und root gar nicht.

Du kannst dir einen Private-Key wie ein extrem langes Passwort vorstellen, welches hunderte Zeichen lang- und in einer (verschlüsselten) Datei gespeichert ist.

Nun musst du die Schlüsselpaare erst erstellen.
Dazu loggst du dich auf dem gateway (oder einem anderen Linux) ein und tippst:

ssh-keygen -t rsa -b 2048

Du wirst dann nach einem Passwort (Passphrase) gefragt, welches natürlich die selben Sicherheits-Anforderungen haben muss wie jedes gute Passwort auch.

Den private-key verschiebst du nun auf deine Admin-Workstation; dieser darf nicht auf dem gateway verbleiben! – Ansonsten wäre das etwa so, wie wenn du einen Tresor hättest und den Schlüssel in einer abgeschlossenen Schreibtischschublade vor dem Tresor lagern würdest… 😉

Nun kannst du im ssh-client (z.B. Putty) deinen Private-Key angeben und dich damit und deinem Passwort auf dem System anmelden.

Direkte Logins mit nur einem Passwort ohne private key dürfen auf dem gateway nur physisch am System stattfinden. Dies werden wir später so konfigurieren.

[stextbox id=“note“ caption=“Hinweis: Entfernen der Standard-Benutzer“]Die Distributionen erstellen in der Regel einige (deaktivierte) Standard-Benutzer wie: „daemon“, „sys“, „sync“ oder „games“.
Diese Benutzer haben in der Regel eine UID zwischen 0 und 99.
Diese sind deaktiviert und sollten auf dem System belassen werden, da sie so gut wie kein Sicherheitsrisiko darstellen.

Benutzer ab UID 100 könnten gelöscht werden, wenn man sicher ist, dass man damit nichts zerbricht.

Falls du diese trotzdem löschen willst, solltest du nur die user löschen, welche keine Datei besitzen.

Diese findest du mit:

find / -user $USERNAME -ls &

Alle Benutzer kann man sich mit:

cat /etc/passwd

anzeigen lassen.

Mittels folgendem Code kann man sich alle Benutzer anzeigen lassen, denen Dateien gehören und die man im System lassen sollte:

# Benutzer
cut -f 1 -d : /etc/passwd | while read i; do find / -user "$i" | grep -q . || echo "$i"; done
 
# Gruppen
cut -f 1 -d : /etc/passwd | while read i; do find / -group "$i" | grep -q . && echo "$i"; done

Falls dennoch etwas schief gegangen ist: Unter Debian kann man mit:

update-passwd

den Original-Zustand der Systemuser wiederherstellen.
[/stextbox]

Shell von innaktiven Benutzern ändern

Die Standard-Benutzer der Linux distribution sollten zwar vorhanden sein, müssen aber nicht unbedingt eine valide login-shell (z.B. /bin/sh) haben.

Bei folgenden Benutzern kann man die shell auf: /bin/false setzen:

  • daemon
  • bin
  • sys
  • games
  • man
  • lp
  • mail
  • news
  • uucp
  • proxy
  • www-data
  • list
  • irc
  • gnats
  • nobody
  • sshd
  • libuuid
  • ntp
  • openvpn
  • Debian-exim
  • logcheck
  • snort
  • postfix

Zu beachten ist jeweils, dass einige system-user eine shell brauchen! – Cron-Jobs, laufen beispielsweise nicht ohne shell!

Unnötige Programme

Ein Grossteil der Computersicherheit basiert darauf sowenig wie möglich installiert zu haben; denn jedes zusätzliche Programm ist ein Angriffspunkt mehr.
Auch bei einer minimalinstallation werden noch unnötige Programme installiert, die es zu entfernen gilt:

aptitude purge resolvconf nano ufw wireless-regdb crda qstat nano gdb gcc-3.3 dpkg-dev libc6-dev cpp-3.3 manpages-dev flex g++ linux-kernel-headers bin86 cpp gcc g++-3.3 bison make libstdc++5-3.3-dev

Konfigurationsdateien

Dies ist zweifellos der wichtigste Abschnitt. Schlecht verwaltete Konfigurationsdateien sind das grösste Sicherheitsrisiko für jedes System.

/etc/inetd.conf
Von hier aus starten einige TCP/IP Services. Da der einzige Service, den wir laufen lassen wollen sshd ist, der nicht von inetd gestartet wird, sollte diese Datei ebenfalls leer- oder gar nicht vorhanden sein. Falls nicht, lösche sie mit rm /etc/inetd.conf, erstelle eine neue mit touch /etc/inetd.conf und schliesse sie mit chattr +i /etc/inetd.conf für zukünftige Schreibzugriffe ab.

/etc/host.conf
Da wir eine Verteidigung gegen Attacken von aussen aufbauen, sollten wir hier als letzte Zeile in /etc/hosts.conf schreiben:

nospoof on

/etc/fstab
Von hier bekommt das System Informationen darüber, welche Laufwerke und Partitionen beim auf starten gemountet werden müssen und wo. Falls du dein System als eine grosse Partition partitioniert hast, oder du keine separate Partition für /home und /tmp erstellst hast, kannst du diesen Abschnitt überspringen. /home und /tmp sind wichtige Bereiche, weil sie von anderen Benutzern als root gelesen und geschrieben werden können. Was wir nun wollen ist limitieren was der Benutzer auf diesen Partitionen machen darf. In /home wollen wir nicht, dass ein Benutzer ein SUID-Programm oder ein Laufwerk erstellt und zusätzlich in /tmp wollen wir dass keine Programme ausgeführt werden können. Dies erreichen wir, indem wir die Datei /ec/fstab ändern.
Deine Datei sollte etwa so aussehen:

# <file system> <mount point> <type>    <options>       <dump>  <pass>
/dev/hda1      /              ext3      defaults        1       1
/dev/hda9      /boot          ext3      defaults        1       2
/dev/hda5      /home          ext3      defaults        1       2
/dev/hda6      /tmp           ext3      defaults        1       2
/dev/sda1      /usr           ext3      defaults        1       2
/dev/hda7      /var           ext3      defaults        1       2
/dev/hda8      swap           swap      defaults        0       0
none           /proc          proc      defaults        0       0

Nun ändern wir das "defaults" unter <options> für diese Filesysteme wie folgt ab:

<mount point>  <options>
/home          rw,nosuid,nodev,noexec
/tmp           defaults,nodev,nosuid,noexec
/usr           defaults,ro,nodev
/var           defaults,nodev,nosuid,noexec

[stextbox id=“note“ caption=“Hinweis“]Du könntest /home theoretisch auch auf read-only setzten, doch dann würde mit deinem User-Account keine shell-history mehr geloggt werden können.[/stextbox]

Damit kann nun auf /usr und /var nicht mehr geschrieben werden, weil es auf read-only (ro) gesetzt ist.

Um trotzdem noch system-updates machen zu können, erstellt man sich nun ein "apt-prescript" welches automatisch beim aufruf von aptitude aufgerufen wird und temporär den Schreibschutz aufhebt:

DPkg
{
  Pre-Invoke  { "mount /usr -o remount,rw" };
  Pre-Invoke  { "mount /var -o remount,exec" };
  Post-Invoke { "mount /usr -o remount,ro" };
  Post-Invoke { "mount /var -o remount,noexec" };
 
  // Wenn man mit iptatbles noch ausgehende HTTP/FTP connections blockt, kann man dies ebenfalls temporär aktivieren:
  // Die Zeilennummer (hier 5) muss evtl angepasst werden!
  //Pre-Invoke  { "iptables -I OUTPUT 5 -o eth0 -p tcp -m multiport --dports 21,80 -m state --state NEW -j ACCEPT" };
  //Post-Invoke { "iptables -D OUTPUT -o eth0 -p tcp -m multiport --dports 21,80 -m state --state NEW -j ACCEPT" };
};

Programme

Nun geht es daran die einzelnen Programme und Dienste abzusichern.

SUID Programme

Als erstes müssen wir alle SUID Programme finden; dies sind Programme, die die Identität von root annehmen, wenn sie ausgeführt werden, was ein hohes Sicherheitsrisiko darstellt.
Dies macht diese Programme Ziele von Buffer Overflow Attacken und Vertauschungen mit Trojanern.

Um alle SUID Programme auf dem System zu finden tippe:

ls -alF `find / -perm -4000`

ein; die Ausgabe wird etwa so aussehen:

-rwsr-xr-x 1 root root  94776 Dec 11  2012 /bin/mount*
-rwsr-xr-x 1 root root  36136 Apr 12  2011 /bin/ping*
-rwsr-xr-x 1 root root  36896 Apr 12  2011 /bin/ping6*
-rwsr-xr-x 1 root root  36816 May 25  2012 /bin/su*
-rwsr-xr-x 1 root root  69080 Dec 11  2012 /bin/umount*
-rwsr-xr-x 1 root root  46264 May 25  2012 /usr/bin/chfn*
-rwsr-xr-x 1 root root  41272 May 25  2012 /usr/bin/chsh*
-rwsr-xr-x 1 root root  31496 Jun 25  2012 /usr/bin/fping*
-rwsr-xr-x 1 root root  31496 Jun 25  2012 /usr/bin/fping6*
-rwsr-xr-x 1 root root  68024 May 25  2012 /usr/bin/gpasswd*
-rwsr-xr-x 1 root root  36432 May 25  2012 /usr/bin/newgrp*
-rwsr-xr-x 1 root root  51096 May 25  2012 /usr/bin/passwd*
-rwsr-xr-x 2 root root 113048 Mar  1 06:20 /usr/bin/sudo*
-rwsr-xr-x 2 root root 113048 Mar  1 06:20 /usr/bin/sudoedit*
-rwsr-xr-x 1 root root 245064 Feb  8  2013 /usr/lib/openssh/ssh-keysign*
-rwsr-xr-x 1 root root  10496 Dec 30  2012 /usr/lib/pt_chown*

Wie du sehen kannst, zeigt die linke Seite die Berechtigung an; jedes Programm mit einem "s" darin hat das SUID bit gesetzt, beim deaktivieren des SUID bits kann nur noch root das Programm ausführen. Was nun gemacht werden muss, ist rauszufinden bei welchen Programmen das SUID bit sicher abgeschaltet werden kann – viele von diesen Programmen brauchen es allerdings um normal ablaufen zu können; andere wiederum sollten sowieso nur von root ausgeführt werden. Das SUID bit schaltest du mit dem Befehl

chmod a-s dateiname

ab.
Empfohlen für diesen Schritt werden:

  • /usr/bin/gpasswd,
  • /usr/bin/chfn,
  • /usr/bin/chsh,
  • /usr/bin/newgrp,
  • /bin/mount,
  • /bin/umount
chmod -v a-s /usr/bin/gpasswd /usr/bin/chfn /usr/bin/chsh /usr/bin/newgrp /bin/mount /bin/umount
mode of `/usr/bin/gpasswd' retained as 0755 (rwxr-xr-x)
mode of `/usr/bin/chfn' changed from 4755 (rwsr-xr-x) to 0755 (rwxr-xr-x)
mode of `/usr/bin/chsh' changed from 4755 (rwsr-xr-x) to 0755 (rwxr-xr-x)
mode of `/usr/bin/newgrp' changed from 4755 (rwsr-xr-x) to 0755 (rwxr-xr-x)
mode of `/bin/mount' changed from 4755 (rwsr-xr-x) to 0755 (rwxr-xr-x)
mode of `/bin/umount' changed from 4755 (rwsr-xr-x) to 0755 (rwxr-xr-x)

Prozesse

Mittels

ps aux |grep -v "["

kannst du dir die Prozesse auf deinem System anzeigen lassen.
Stelle sicher, dass kein Prozess läuft, von dem du nicht genau weisst was er tut und ob er laufen soll oder nicht.
Unnötige Prozesse mittels

update-rc.d PROZESS

off deaktivieren.

Normal sind z.B.:

  • udevd –daemon
  • /usr/sbin/rsyslogd
  • /usr/sbin/cron
  • /usr/sbin/sshd
  • /usr/sbin/ntpd
  • /sbin/getty 38400 tty1

Netzwerk-Dienste

Nun gilt es herauszufinden welche Netzwerkdienste laufen.

Dies findest du mit

netstat -pn -l -A inet

heraus; die Ausgabe zeigt dir alle Dienste an, zu denen man sich Verbinden kann:

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:25            0.0.0.0:*                           26542/smtpd
udp        0      0 10.1.1.1:22             0.0.0.0:*               LISTEN      2200/sshd
udp        0      0 0.0.0.0:1194            0.0.0.0:*               LISTEN      2178/openvpn

Die Spalte "Local Address" zeigt auf welchem Netzwerk-Interface der Dienst läuft:

<ol>
127.0.0.1          Der Dienst ist nur vom lokalen System erreichbar
10.1.1.1 (LAN-IP)  Der Dienst ist nur vom internen Netzwerk erreichbar
</ol>
0.0.0.0            Der Dienst ist von überall erreichbar

Dienste mit dem letzten Eintrag (0.0.0.0) sind besonders heikel, denn diese sind von überall (also auch vom Internet) erreichbar!

Hier sollten wirklich nur die Dienste laufen, welche du unbedingt übers Internet von überall aus erreichen musst. Alle anderen Dienste sollten nur übers lokale Netzwerk, bzw. wenn du dich mit denen nicht remote Verbinden musst, nur lokal auf 127.0.0.1 laufen.

Und selbst wenn du dich von einem entfernten Standort (z.B. dem Büro) verbinden musst wäre das aufsetzten eines ((Mit OpenVPN zwei Netzwerke verbinden|VPN))s die bessere Lösung.

Bei fast allen Diensten kann man konfigurieren an welches Interface der Dienst sich "bindet".

Stelle nach diesen Kriterien sicher, dass die Dienste alle auf dem korrekten Interface laufen. Und Dienste die man nicht braucht, sollten natürlich gar nicht erst laufen.

SSH

Der SSH-Server sollten eines der einzigen Programme sein, welches läuft und auf den Interfaces hört. Entsprechend sollte auch dieses abgesichert sein.

Hier binden wir den SSH-Server auf die lokale LAN-Adresse, deaktivieren passwort logins, deaktivieren root logins, lassen nur noch ausgewählte Benutzer zu und deaktivieren unnötige Dinge wie x-forwarding oder den sftp-server.

Folgende Zeilen müssen dazu in der Datei /etc/ssh/sshd_config geändert werden:

Port 22
# Falls SSH auf dem Internet-Interface läuft sollte man wenigstens einen anderen Port dafür nehmen und
# den Default-Port 22 per iptables-firewall nur von innen zugänglich machen
Port 9876
ListenAddress 10.1.1.1                       #Falls der Dienst im Internet laufen muss: 0.0.0.0 (default) und anderer Port (s.o.)
 
LogLevel DEBUG                               # Damit sieht man mehr Infos in den logs
 
PermitRootLogin no
AllowUsers hmuster                           # Hier kommt dein Benutzername hin
PasswordAuthentication no
 
X11Forwarding no
 
#Subsystem sftp /usr/lib/openssh/sftp-server # Auskommentieren

Achtung, ab jetzt kannst du dich per SSH nur noch mit deinem SSH-Private-Key anmelden, den du hoffentlich zuvor erstellt hattest… 😉

/proc tuning

Mittels dem /proc filesystem können verschiedene Kernel-Variablem gesetzt werden.
Die wichtigsten rund um die IT-Sicherheit eines routers/firewall sind:

net.ipv4.icmp_echo_ignore_broadcasts = 1
Hiermit ignoriert der Kernel alle Echo-Request-Pakete (Ping) an die Broadcast-Adresse.
Üblicherweise beantworten alle Linux-/Unix-Betriebssysteme einen Echo-Request an ihre Broadcast-Adresse. So kann man sehr leicht in einem Netzwerk alle verfügbaren Unix-Systeme ermit-
teln.
Da aber viele Router in der Vergangenheit (und auch heute noch) derartige Broadcast-Ping-Anfragen nicht verworfen haben, konnte damit eine Verstärkung des Verkehrs erzeugt werden.
Man sendet ein Ping an die Broadcast-Adresse eines Netzwerks mit 10 Unix-Rechnern und erhält 10 Antworten zurück. Wenn man die Absenderadresse fälscht (IP-Spoofing), kann man so einen anderen Rechner mit Ping-Antworten überschwemmen. Dieser Angriff trägt den Namen Smurf-Angriff.

net.ipv4.tcp_syncookies = 1
Hiermit werde SYN-Cookies im Linux-Kernel aktiviert. Der Linux-Kernel wird anfangen, SYN-Cookies zu versenden, sobald der SYN-Backlog überläuft.
Damit kann man sich gegen einen SYN-Flood wehren.

net.ipv4.ip_forward = 1
net.ipv4.conf.all.forwarding = 1
Schaltet das IP-Forwarding ein. Für router ein unverzichbarer Wert.

net.ipv4.conf.all.accept_redirects = 0
Normalerweise wird ein Paket das in ein anderes subnet soll an ein Gateway geschickt, mit einem ICMP redirect schickt kann das Gateway mitteilen das ein anderer router eine bessere Route für das Paket hat. Ein cracker kann das für eine man-in-the-middle Attacke ausnützen. Diese Option sollte IMMER auf 0 sein.

net.ipv4.conf.all.accept_source_route = 0
Dieser Parameter definiert, ob das System IP-Pakete mit der IP-Option Source-Routing akzeptiert.
Da damit ein Angreifer Pakete über selbst gewählte Routen versenden kann, sollte diese Option abgeschaltet sein (0). Dies ist auch der Default.

net.ipv4.conf.all.log_martians = 1
Wenn diese Option aktiviert ist, loggt der Kernel Pakete mit ungültigen Adressen.

net.ipv4.conf.all.rp_filter = 1
Diese Variable schaltet einen Reverse-Path-Filter für diese Netzwerkkarte an.
Dieser Filter prüft, ob eine Antwort an den Absender des Pakets auch über diese Netzwerkkarte versendet werden würde.
Diese Variable bietet so einen gewissen Schutz vor IP-Spoofing-Angriffen.

net.ipv4.conf.all.secure_redirects = 1
Normalerweise akzeptiert ein Linux-System sämtliche ICMP-Redirects.
Wenn diese Variable aktiviert ist, werden nur Redirects von bekannten Default-Gateways akzeptiert.

Remote loging aktivieren

Wenn ein Angreifer in das System einbricht könnte er theoretisch die logfiles löschen oder ändern um seine Spuren zu verwischen.

Um dies zu verhindern kann man die logfiles per remote-log an ein externes System weiter leiten, auf welches der Angreifer (erstmal) keinen Zugriff hat.

Dazu muss man beim gateway in /etc/rsyslog.conf (oberhalb der lokalen Einträge!) folgendes stehen:

#========================== SPECIFIC AND REMOTE LOGGING =======================
# The "& ~"-Line stops further proccessing of the messages
 
#if $syslogfacility-text == 'kernel' and ($msg contains . 'iptables') . then /var/log/firewall.log
if $programname == 'kernel' and ($msg contains 'iptables') then @syslog
if $programname == 'kernel' and ($msg contains 'iptables') then /var/log/firewall.log
if $programname == 'kernel' and ($msg contains 'iptables') then ~
 
if $programname contains 'kernel' and ($msg contains 'martian' or $msg contains 'll header') then /var/log/martian.log
& ~
 
# Send all logs to deinsyslogserver syslog
<ul>
<li>.*                             @deinsyslogserver

Am wichtigsten ist nur die Zeile:

<em>.</em>                             @deinsyslogserver

Die restlichen Anweisungen sind nur dazu da um beispielsweise die firewall logs in ein separates logfile zu schrieben.

Auf "deinsyslogserver" sehen die relvanten Einträge in der rsyslogd.conf so aus:

# Provides UDP syslog reception
$ModLoad imudp.so
$UDPServerRun 514
 
# Provides TCP syslog reception
$ModLoad imtcp.so
$InputTCPServerRun 514
 
 
#========================== LOGS FROM REMOTE HOSTS ============================
# The "& ~"-Line stops further proccessing of the messages
$template PerHostLog,"/var/log/%HOSTNAME%/syslog.log"
 
if $programname == 'kernel' and ($msg contains 'iptables') then /var/log/gateway/firewall.log
& ~
if $programname contains 'openvpn' then /var/log/gateway/openvpn.log
& ~
if $programname contains 'kernel' and ($msg contains 'martian' or $msg contains 'll header') then ~
& ~
 
if $fromhost == 'gateway' then -?PerHostLog
& ~

System Integrität überprüfen

Das letzte, was wir nun noch tun wollen ist das System so aufzusetzen, damit es in der Lage ist dich zu warnen, falls irgendwas verändert wurde. Sobald irgendein Einbrecher reinkommt und ein Trojaner pflanzt, oder ein Account erstellt, wollen wir dass das System uns sagen kann was verändert wurde.

debian-harden

Debian stellt ein paket "harden" zur Verfügung, dass all die wichtigen Tools rund um Intrusion Detection (IDS) und System hardening zur Verfügung stellt:

aptitude install harden

rkhunter

rkhunter durchsucht das System regelmässig nach Rootkits und Trojanern und sendet eine Meldung per Mail, wenn etwas nicht stimmt.

AIDE

AIDE erstellt einen kompletten Snapshot vom System und informiert, sobald Dateien geändert wurden.

logwatch

Logwatch ist ein nettes Tool, dass die täglich die Auswertungen der wichtigsten logfiles zusendet.

Abschluss

Es ist nun relativ sicher das System ins Internet zu stellen. Sobald dies getan ist, willst du wahrscheinlich deine Sicherheit überprüfen. Unter: www.security-check.ch kannst du dein System auf offene Ports überprüfen lassen und siehst, wie sicher du nun durchs Internet surfst.

Related Links

|| Link | Beschreibung
[http://linuxgazette.net/issue55/stoddard.html|Building a Secure Gateway, part II By Chris Stoddard] | Von diesem sehr gut gemachten Tutorial stammen viele Informationen auf dieser Seite
[http://www.debian.org/doc/manuals/securing-debian-howto/ch4.de.html|Anleitung zum Absichern von Debian] | Viele Hinweise, wie man sein Debian-System absichern kann
[http://www.security-check.ch/|www.security-check.ch] | Eine Seite bei der man sein System auf Angriffsmöglichkeiten hin checken lassen kann
||

Related Downloads

|| File | Beschreibung
[http://linux.tucows.com/preview/51638.html|FCHECK] | Ein Tool um über Änderungen an einem Linux System informiert zu werden
||

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert