AA_PO-21680-Fotolia-Gordon_Bussiek_Tuersteher.jpg

© Gordon_Bussiek, Fotolia

Türsteher

Dienste vor Brute-Force- und Wörterbuch-Attacken schützen

21.06.2013
Fail2ban und Sshguard schützen Server-Dienste gegen Brute-Force- und Wörterbuchattacken, indem sie auffällig gewordene Störenfriede kurzerhand aussperren.

Das Internet wimmelt geradezu von Rechnern, die still und leise ihre Dienste anbieten – etwa als Home-Server für die Familie oder als File- und Web-Server in WGs, Kirchengemeinden und Sportvereinen. Solche Maschinen stellen beliebte Ziele für Attacken dar: Einmal geknackt, lassen sie sich bestens als Ausgangspunkt für illegale Aktionen nutzen.

Meist verschafft sich der Angreifer dabei über Brute-Force- und Wörterbuchattacken Zugang zum System. Das klappt auch ohne umfangreiches Wissen, denn netzwerkfähige Passwort-Cracker wie Ncrack, Hydra oder Medusa arbeiten so benutzerfreundlich, dass auch Nichtspezialisten nach kurzer Einarbeitungszeit mit ihnen umgehen können.

Bei der Wörterbuchattacke versuchen Angreifer, schwache Passwörter mithilfe von Wortlisten zu knacken. Umfangreiche Wortlisten liefern beispielsweise Spellchecker wie Aspell und Ispell, andere finden sich im Netz oder lassen sich mit geringem Aufwand aus maschinenverarbeitbaren Texten gewinnen. Weil immer noch viele Nutzer einfache Passworte ohne Großbuchstaben, Ziffern und Sonderzeichen verwenden, führt solch ein Wörterbuchangriff oft schnell zum Erfolg.

Bei mindestens acht, besser zwölf Zeichen langen Passworten, die neben Groß- und Kleinbuchstaben auch Ziffern und Sonderzeichen enthalten, laufen Wörterbuchangriffe mit hoher Wahrscheinlichkeit ins Leere. Hier klappt höchstens eine Brute-Force-Attacke, bei denen der Passwort-Cracker beliebige Zeichenkombinationen durchprobiert. Je nach Länge und Güte des Passworts führt ein derartiger Angriff früher oder später zum Erfolg. Dass viele Dienste und Anwendungen im Netz parallele Verbindungen zulassen und oft auch die Anzahl der Zeichen in Passworten beschränken, erleichtert solche Attacken.

Server protokollieren zwar in aller Regel fehlgeschlagene Logins, doch solange die Dienste anstandslos laufen, macht sich kaum ein Betreiber die Mühe, die Log-Dateien regelmäßig durchzusehen. Läuft auf dem Server kein IDS, das angesichts vieler erfolgloser Login-Versuchen seine warnende Stimme erhebt, fallen Brute-Force- und Wörterbuchangriffe meist erst spät auf.

Hier helfen Anwendungen weiter, welche die Server-Logs überwachen und die betroffenen Ports automatisch sperren, sobald Unregelmäßigkeiten auftreten. Zwei erfahrene "Türsteher" aus dieser Riege sind Fail2ban [1] und Sshguard [2]. Beide Anwendungen dienen als Ergänzung zu einer Firewall.

Eine Firewall kann zwar verhindern, dass viele parallele Verbindungen zu einem Rechner geöffnet werden, vermag aber fehlgeschlagene Logins nicht zu erkennen. Ein Angreifer braucht also nur zu ermitteln, wie viele parallele Verbindungen erlaubt sind, um dann eine auf die Firewall zugeschnittene Attacke abzusetzen. Sofern der Admin nicht über die resultierenden, riesigen Log-Dateien stolpert, verläuft der Angriff unbemerkt.

Fail2ban

Das seit 2004 entwickelte Python-Programm Fail2ban nutzt eine Client/Server-Architektur und kann die Log-Dateien mehrerer Server-Dienste überwachen, so etwa jene von SSH, Web, FTP und E-Mail. Erkennt das Tool eine Attacke, greift es auf Firewalls wie Iptables oder den TCP-Wrapper zurück, um die betroffenen Ports für eine festgelegte Zeit zu sperren. Parallel dazu benachrichtigt es den Administrator per E-Mail über die Attacke. Als Kriterium für einen Angriff nutzt Fail2ban Muster wie etwa Fehlermeldungen, die von einer IP-Adresse ausgelöst wurden.

Das aktuelle Fail2ban 0.8.8 vor findet sich in den Repositories aller gängigen Distributionen, sodass Sie es komfortabel mithilfe der Paketverwaltung einrichten. Alternativ greifen Sie zum Sourcecode von Github.com [3] und führen im Quellverzeichnis python setup.py install aus. Die Programmdateien landen standardmäßig unter /usr/share/fail2ban oder /usr/bin.

Die Entwickler empfehlen, Fail2ban stets über den Client zu steuern. Das Kommando fail2ban-client -h prüft, ob die Installation erfolgreich war. Um Fail2ban nach einer manuellen Installation automatisch beim Booten zu starten, gilt es eventuell noch ein Init-Skript anzulegen. Bei einer Installation aus einem Repository sollte das automatisch erfolgt sein.

Fail2ban einrichten

In Fail2ban kommen Sie nicht um Filter, Aktionen und Jails herum. Bei einem Filter handelt es sich um ein Suchmuster in Form eines regulären Ausdrucks, auf dessen Basis Fail2ban die Log-Dateien durchforstet. Eine Aktion ist ein auszuführendes Kommando, etwa um eine Firewall zu aktivieren oder den Admin anzumailen. Ein Jail besteht aus einem Filter sowie einer oder mehreren Aktionen.

Prinzipiell lässt sich Fail2ban zwar auch zur Laufzeit konfigurieren, doch da die Einstellungen dann bei jedem Neustart verloren gehen, ist es sinnvoll, sie gleich in Konfigurationsdateien zu hinterlegen. Diese finden sich üblicherweise im Verzeichnis /etc/fail2ban. Im File fail2ban.conf treffen Sie Einstellungen hinsichtlich des Servers, wie etwa den Log-Level (Listing 1, Zeile 2). Hier legen Sie auch die Fail2ban-Log-Datei (Zeile 3) fest und definieren den Unix-Socket (Zeile 4), über den der Server mit dem Client kommuniziert.

Listing 1

# Log-Level: 1=Error, 2=Warn, 3=Info, 4=Debug
loglevel = 3
logtarget = /var/log/fail2ban.log
socket = /var/run/fail2ban/fail2ban.sock

Im Unterverzeichnis filter.d/ hinterlegen Sie Regeln in Form regulärer Ausdrücke für die einzelnen Dienste. Eine Regel darf aus mehreren Ausdrücken bestehen, die Sie zeilenweise auflisten. Ein Beispiel für den SSH-Daemon zeigt Listing 2. Beim Ausdruck <HOST> handelt es sich um ein Alias, das reguläre Ausdrücke für Hostnamen sowie IPv4- und IPv6-Adressen ersetzt. Das macht die Filter leichter lesbar. Ob die Regeln funktionieren, testet folgender Befehl (Abbildung 1):

$ fail2ban-regex /Pfad/zur/Log-Datei /etc/fail2ban/filter.d/Filtername

Listing 2

# Regex für sshd
failregex = Failed password for .* from <HOST>
            FAILED su for .* by .*
            Invalid user .* from <HOST>
Abbildung 1: Alle 45 Minuten ein fehlerhafter Login-Versuch von einem isländischen Host? Das stinkt. Fail2ban-regex prüft reguläre Ausdrücke in Filtern und kann neue Erkenntnisse bringen.

Fail2ban: Aktionen

Das Verzeichnis action.d/ beherbergt die Aktionen, die Fail2ban ausführen soll, wenn es in einer Log-Datei so viele zu einem Filter passende Einträge findet, dass eine unmittelbare Reaktion Not tut. In der Regel finden sich deswegen an dieser Stelle Anweisungen für die Firewall, doch man kann hier auch E-Mails absetzen oder andere Befehle ausführen. Listing 3 zeigt die Aktion iptables aus Debians Fail2ban-Konfiguration.

Listing 3

[Definition]
# Option:  actionstart
# Notes.:  command executed once at the start of Fail2Ban.
# Values:  CMD
actionstart = iptables -N fail2ban-<name>
              iptables -A fail2ban-<name> -j RETURN
              iptables -I INPUT -p <protocol> --dport <port> -j fail2ban-<name>
# Option:  actionstop
# Notes.:  command executed once at the end of Fail2Ban
# Values:  CMD
actionstop = iptables -D INPUT -p <protocol> --dport <port> -j fail2ban-<name>
             iptables -F fail2ban-<name>
             iptables -X fail2ban-<name>
# Option:  actioncheck
# Notes.:  command executed once before each actionban command
# Values:  CMD
actioncheck = iptables -n -L INPUT | grep -q fail2ban-<name>
# Option:  actionban
# Notes.:  command executed when banning an IP.
# Tags:    <ip>  IP address
#          <failures>  number of failures
#          <time>  unix timestamp of the ban time
# Values:  CMD
actionban = iptables -I fail2ban-<name> 1 -s <ip> -j DROP
# Option:  actionunban
# Notes.:  command executed when unbanning an IP. Take care that the
#          command is executed with Fail2Ban user rights.
# Tags:    <ip>  IP address
#          <failures>  number of failures
#          <time>  unix timestamp of the ban time
# Values:  CMD
actionunban = iptables -D fail2ban-<name> -s <ip> -j DROP
[Init]
# Defaut name of the chain
name = default
# Option:  port
# Notes.:  specifies port to monitor
# Values:  [ NUM | STRING ]  Default:
port = ssh
# Option:  protocol
# Notes.:  internally used by config reader for interpolations.
# Values:  [ tcp | udp | icmp | all ] Default: tcp
protocol = tcp

Die Option actionstart (Zeile 2) legt eine neue Filterkette fail2ban-<name> an. Diese enthält zu Beginn nur eine Regel, welche den Ball sofort wieder an die übergeordnete Kette zurückspielt (-j RETURN). Die INPUT-Chain wird anschließend angewiesen, alle Pakete für die von Fail2ban kontrollierten Ports und Protokolle an die Chain fail2ban-<name> weiterzureichen. In der Regel passiert hier also noch nichts – actionCheck (Zeile 16) prüft lediglich, ob fail2ban-<name> existiert.

Die Option actionban (Zeile 21) fügt in fail2ban-<name> an erster Stelle eine Regel ein, mit der die Firewall den betroffenen Port für den angreifenden Host sperrt. Bei <ip> handelt es sich um einen Platzhalter, der sowohl eine IP-Adresse als auch einen Hostnamen enthalten kann. Die Option actionunban (Zeile 29) löscht die entsprechende Regel wieder, actionstop (Zeile 9) macht alle in actionstart vorgenommenen Änderungen wieder rückgängig.

Unter [Init] (ab Zeile 38) finden sich lediglich ein paar Variablen, die Fail2ban standardmäßig setzt, falls das aufrufende Jail keine entsprechenden Informationen liefert.

Fail2ban: Jails

Nach der Definition von Aktionen und Filtern gilt es nun noch die Jails einzurichten. Die meisten Distributionen konfigurieren Fail2ban für die gängigsten Dienste bereits vor, sodass Sie nur minimale Anpassungen an den Filtern, Aktionen und Jails vornehmen müssen.

Die Definitionen der Jails lagern in der Datei /etc/fail2ban/jail.conf. Hier tragen Sie beispielsweise ein, wie viele Fehlversuche sie für einzelne Dienste erlauben (maxretry), wie lange ein Port bei zu vielen Fehlversuchen gesperrt bleibt (bantime) und welche Log-Dateien Fail2ban auswertet (logpath).

Listing 4

[DEFAULT]
# "ignoreip" can be an IP address, a CIDR mask or a DNS host
#ignoreip = 127.0.0.1
bantime  = 600
maxretry = 3
backend = polling
destemail = falko@*
mta = sendmail
banaction = iptables-multiport
action_ = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s]
#defaul action
action = %(action_)s
# JAILS
[ssh]
enabled = true
port    = ssh
filter  = sshd
logpath  = /var/log/auth.log
findtime = 3600
maxretry = 3
bantime = 7200

Listing 4 zeigt einen Auszug aus der jail.conf von Debian. In der Sektion [DEFAULT] legen Sie Standardwerte fest, um diese später nicht ständig wiederholen zu müssen. Ob Sie ignoreip (Zeile 3) setzen, müssen Sie sorgsam abwägen: Der Eintrag darf IP-Adressen einzelner Rechner oder ganzer Netzwerke enthalten. Hier können Angriffe Fail2bans Radar unterlaufen, falls sie von innen erfolgen oder ein Angreifer bereits ein Nutzerkonto übernommen hat. Das backend (Zeile 6) legt fest, wie Fail2ban Log-Dateien überwacht. Neben dem traditionellen polling ist auch der Einsatz des leistungsfähigeren Gamin [4] möglich.

Neben der E-Mail-Adresse des Admins (Zeile 7) und dem zu verwendenden Mail-Programm (Zeile 8) lassen sich auch noch Variablen für verschiedene Aktionen setzen. Den Aktionen wird ein Array mit Variablen übergeben (Zeile 10), deren Werte Fail2ban in der korrespondierenden Konfigurationsdatei in action.d/ einsetzt. Die Entwickler haben hier sogar an Platzhalter für den Namen des Jails gedacht (%(__name__)).

Die Abschnitte für einzelne Jails leiten Sie in eckigen Klammern ein mit dem Namen des Jails ein (Zeile 15). Anschließend folgen Zeilen, in denen Sie festlegen, ob ein Jail aktiv ist (Zeile 16), welche Ports betroffen sind (Zeile 17), welche Filterregeln greifen (Zeile 18) und welche Log-Datei Fail2ban heranzieht (Zeile 19). Ferner dürfen Sie hier die Vorgabewerte etwa für die maximale Anzahl der Fehlversuche oder die Aktion überschreiben.

Das Testen der Filterregeln bringt teilweise erhellende Einsichten – wie etwa die Erkenntnis, dass die standardmäßige bantime und findtime von 600 Sekunden nicht immer ausreicht (siehe Abbildung 1). Dabei legt findtime fest, in welchem Zeitraum potenzielle Angriffe erfolgen müssen, damit Fail2ban sie als zusammenhängend betrachtet (Zeile 20).

Haben Sie alles nach Ihren Vorstellungen eingerichtet, starten Sie Fail2ban mithilfe des Startskripts (unter Debian /etc/init.d/fail2ban) neu oder lesen die überarbeitete Konfiguration ein. Manuell aktivieren Sie Fail2ban via fail2ban-client start. Dass eine neue Konfiguration vorliegt, teilt der Client dem Server mit fail2ban-client reload mit.

Sshguard

Sshguard arbeitet ähnlich wie Fail2ban. Es untersucht Logs und entscheidet anhand vorgegebener Regeln, ob ein Dienst via Firewall eine Zeit lang gesperrt werden soll. Die Anwendung steht unter einer BSD-Lizenz. Da sie in C implementiert wurde, muss sie keinen Interpreter aufrufen und verbraucht so weniger Speicher- und Prozessorkapazität.

Mit der "Touchiness" verfügt Sshguard zudem über eine interessante Funktion, welche die Sicherheit erhöht. Verstößt ein Angreifer das erste Mal gegen eine Regel, sperrt Sshguard ihn für eine gewisse Zeit T aus. Mit jedem weiteren festgestellten Verstoß n erhöht sich Sperrfrist auf 2(-1)*T. Mit jedem Zugriffsversuch erhöht sich die Dauer der Blockade also exponentiell: Nach dem dritten festgestellten Verstoß bleibt der Angreifer viermal solange ausgesperrt wie am Anfang, nach dem vierten Angriff achtmal so lange, und so fort.

Allerdings arbeitet Sshguard weniger flexibel als Fail2ban und schützt lediglich den SSH-Daemon sowie mehrere Mail- und FTP-Dienste. Sie können auch nicht ohne Weiteres eigene Muster angeben, auf die Sshguard anschließend achtet. Die Anwendung verifiziert auf Wunsch, ob Log-Einträge vom richtigen Dienst kommen und bietet eine Blacklist für Hosts, die mehrmals (Voreinstellung: dreimal) gegen die Regeln verstoßen. Ebenso ist Whitelisting möglich.

Installation und Konfiguration

Wie Fail2ban findet sich auch Sshguard in den Repositories der gängigen Distributionen und lässt sich daher mit den Paketwerkzeugen in Betrieb nehmen. Die manuelle Installation aus den Quellen führt über folgenden Dreisatz:

$ ./configure --with-firewall=<label> ;; make ;; make install

Dabei ersetzen Sie den Platzhalter <label> durch die Bezeichnung der zu verwendenden Firewall (bei Linux meist Iptables oder der TCP-Wrapper).

Anders als Fail2ban konfigurieren Sie Sshguard nicht über Dateien, sondern direkt beim Befehlsaufruf. Vorab gilt es die Firewall darauf vorzubereiten, von Sshguard Regeln entgegenzunehmen. Listing 5 zeigt ein Beispiel für eine IPv4-Firewall. Möchten Sie nicht die komplette INPUT-Chain an die Sshguard-Chain durchreichen, beschränken Sie die weiterzuleitenden Pakete mit -m multiport -p tcp --destination-ports 21,22,110,143 auf die von Sshguard unterstützten Dienste. Da Iptables-Regeln sich mit jedem Systemstart verflüchtigen, müssen Sie sie permanent hinterlegen und beim Booten erneut laden, etwa mit iptables-save und iptables-restore.

Listing 5

#neue Chain hinzufügen
iptables -N sshguard
#INPUT-CHAIN an sshguard weiterleiten
iptables -A INPUT -j sshguard

Iptables arbeitet so, dass stets die erste passende Regel greift. Das bedeutet, dass bei einer bereits konfigurierten Firewall die Regeln für Sshguard mit iptables -A INPUT -j sshguard ganz am Ende landen und eventuell nicht wie erwartet wirken. Abhilfe schafft in diesem Fall der Befehl iptables -I INPUT 1 -j sshguard, der die Regel in der INPUT-Chain an erster Stelle platziert. Damit die Chain Sshguard auch wieder verlässt und weitere Firewall-Regeln abgearbeitet werden, sollte auch hier ein iptables -A sshguard -j RETURN folgen.

Sshguard ab Version 1.5 ordnet jedem Angriff einen Gefährlichkeitsgrad ("dangerousness") zu, der in der Vorgabe bei 10 liegt und den es bei Folgeverstößen aufaddiert. Zwei fehlerhafte Login-Versuche führen also zu einer Gefährlichkeit von 20 und so fort. Die Vorgabe für die Dangerousness definiert die Konstante DEFAULT_ATTACKS_DANGEROUSNESS in der Include-Datei sshguard.h des Quellcodes, per Kommandozeilenparameter lässt sie sich daher nicht ändern.

Sshguard unterstützt die Logging-Systeme Syslog, Syslog-ng, Metalog, Multilog sowie Raw-Log-Dateien. Auf Linux-Servern trifft man am häufigsten Syslog und Syslog-ng an. Ab Version 1.5 kommt Sshguard auch mit dem Log Sucker [5] zurecht, der Log-Dateien selbstständig überwacht.

In Versionen vor 1.5 müssen Sie Log-Einträge über eine Pipe an Sshguard weiterreichen. Um Syslogd dazu bewegen, Sshguard vor v1.5 alle protokollierten Auth-relevanten Ereignisse mitzuteilen, bedarf es folgender Anweisung:

auth.info;authpriv.info | /usr/local/sbin/sshguard

Diese Zeile tragen Sie in der Datei /etc/syslog.conf oder deren Äquivalent ein, wie etwa der rsyslog.conf unter Debian. Für Rechner mit Syslog-ng findet sich eine Anleitung in der Setup-Sektion der Sshguard-Dokumentation [6]. Um Sshguard letztendlich scharf zu schalten, genügt folgendes Kommando:

# sshguard -l /Pfad/zur/Log-Datei/ [-l /Pfad/zu/weiteren/Log-Dateien/] -a Gefährlichkeit -p Sperrzeit -s Vergesslichkeit

Hier definiert -l den Pfad zu den Log-Dateien, -a gibt an, wann Sshguard die Schotten für einen Dienst dicht macht. Als Grundlage dazu dienen die addierten Dangerousness-Werte. Bei einem Wert von 40 (Vorgabe) wären demnach 4 Fehlversuche erlaubt. Bei Versionen vor Sshguard 1.5 entspricht -a einer schlichten Zählvariable, hier würde ein Wert von 40 sehr viele Fehlversuche erlauben.

Der Parameter -p teilt Sshguard mit, wie viele Sekunden es einen attackierenden Host aussperren soll (Vorgabe: 7 Minuten). Die "Vergesslichkeit" hinter -s legt fest, wie viele Sekunden sich Sshguard fehlerhafte Login-Versuche merkt – der Standardwert beträgt hier 20 Minuten. Probiert ein Angreifer in höheren Intervallen Nutzer/Passwort-Kombinationen durch, zählt Sshguard nicht mit und aktiviert keine Firewall.

Um Nervensägen dauerhaft auszusperren, die mehr als einmal unangenehm aufgefallen sind, ergänzen Sie den Aufruf um den Parameter -b [num:]Datei. Hier legt num fest, nach wie vielen Attacken Sshguard den Angreifer in die Blacklist Datei einträgt. Umgekehrt gibt es eine Whitelist, in der Sie Hosts und Netzwerke auflisten, deren Fehlversuche Sshguard ignorieren soll. Hier existiert allerdings wie bei der entsprechenden Fail2ban-Funktion die Gefahr, Angriffe von innen nicht zu erkennen.

Mit -f Service-Code:PID-File weisen Sie Sshguard an, die Herkunft von Log-Meldungen zu überprüfen. Die PID-Files lassen sich nur in Verbindung mit Syslog und Syslog-ng validieren. Der Service-Code identifiziert den fraglichen Dienst [7]; hier steht etwa 100 für den SSH-Daemon, und das PID-File gehört dem zu überwachenden Service.

Erkennt Sshguard, dass eine Log-Meldung von einem anderen als dem zu überwachenden Dienst kam, ignoriert es sie. Stimmt die PID mit dem Service oder einem übergeordneten Prozess überein, wird sie akzeptiert und ausgewertet. Die Entwickler weisen darauf hin, dass die Log-Validierung mit Log Sucker momentan noch nicht richtig funktioniert, und raten, von der Nutzung abzusehen, bis eine neue Version veröffentlicht wurde.

Empfinden Sie Sshguard im Vordergrund als störend, schicken Sie den Prozess gleich nach dem Start in den Hintergrund, indem er ihm ein abschließendes & mitgeben. Um den Dienst nicht nach jedem Booten manuell starten zu müssen, tragen ist die Startanweisung in ein Startskript ein, etwa in /etc/rc.local.

Pförtner testen

Ob Fail2ban oder Sshguard zukünftig potenzielle Störenfriede zuverlässig abweisen, können Sie schnell testen: Dazu genügt es, sich einige Male falsch einzuloggen. Bereits nach wenigen Fehlversuchen sollte sich der Server tot stellen. Eine Ausgabe der Iptables-Regeln mit iptables -L sollte die entsprechende Firewall-Regel anzeigen (Abbildung 2).

Abbildung 2: Ob Fail2ban und Sshguard wie erwartet funktionieren, erfahren Sie im Selbsttest und durch einen Blick auf die Firewall.

Fazit

Fail2ban bringt den größeren Funktionsumfang mit. Es kann praktisch jede aus dem Internet erreichbare Anwendung schützen, die Log-Dateien schreibt. Zudem nimmt es bei Angriffen jede Aktion vor, die Sie definieren. Über die Paketverwaltung einer Distribution installiert bietet Fail2ban meist bereits eine gute Basis mit zahlreichen Filtern, Aktionen und Jails.

Sshguard beherrscht nur die bereits mit einkompilierten Filter, eigene Regeln kann man hier nicht ohne Weiteres hinzufügen. Andererseits müssen Sie sich hier aber auch nicht mit regulären Ausdrücken plagen: Sie bringen den Dienst in Windeseile und mit nur wenigen Tastenanschlägen in Stellung und lassen ihn dann seines Amtes walten. Bei der Touchiness handelt es sich um ein nettes Feature, das hartnäckige Fieslinge schnell ins Aus schießt.

Beide Anwendungen bieten ein Whitelisting, mit dem Sie bestimmten Hosts einen Freibrief ausstellen. Erfolgt jedoch ein Angriff von innen oder wurde ein als vertrauenswürdig eingestufter Host gekapert, kann die Whitelist nach hinten losgehen.

Sowohl Fail2ban als auch Sshguard verrichten letztlich ihre Aufgaben tadellos und zuverlässig, jedoch kann weder das eine noch das andere Programm eine Firewall ersetzen. Beide ergänzen diese nur um eine zusätzliche Schutzfunktion. 

Glossar

IDS

Intrusion Detection System. Bei solchen Angriffserkennungssystemen unterscheidet man grundsätzlich zwischen hostbasierten HIDS, welche die auf einem Rechner anfallenden (Log-)Daten laufend auswerten, und netzwerkbasierten NIDS, welche den Netzwerkverkehr auf Unregelmäßigkeiten hin analysieren. Viele IDS-Implementationen kombinieren heute HIDS- und NIDS-Fähigkeiten.

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 6 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

LinuxCommunity kaufen

Einzelne Ausgabe
 
Abonnements
 

Ähnliche Artikel

Kommentare