Die Sicherheit von Windows 2000
Version 2.4 15. April 2001

1.0 Inhaltsverzeichnis

Laut RFC 2052 baut ein Client-Zugriff auf die Domain-Services von Windows 2000 wie AD und Kerberos auf den in der Spezifikation festgelegten DNS SRV-Datensatz auf, der das Aufspüren eines Servers über den Service-Typ bzw. über das Protokoll ermöglichen soll: Service.Proto.Name TTL Class SRV Priority Weight Port TargetAus diesem Grunde können sich viele interessante und relevante Informationen durch einen einfachen Zonetransfer durch das Nutzen von "nslookup" oder der Eingabe "ls -d <Domain-Name>" auslesen lassen, wenn man die Daten aus der übertragenen Zone genau analysiert.

Eine simple Beobachtung, die der Angreifer machen würde, wäre zum Beispiel der Standort des globalen Katalogdienstes der Domäne ("gc._tcp"), die Domänencontroller, die eine Kerberos-Beglaubigung durchführen ("_kerberos._tcp"), die LDAP-Server ("_ldap._tcp") und die damit verbundenen Portadressen.

Erfreulicherweise lässt die Implementierung des DNS von Microsoft in der jüngsten Windows-Generation ein einfaches und sicherheitsrelevantes Handling zu, um Zone-Transfers beliebig einzuschränken. Die Einstellungen werden in den Optionen für die Lookup-Zone definiert, welche sich unnerhalb der "Microsoft Management-Konsole" des Snap-In-Modus bei Computerverwaltung unter "\Serveranwendungen und Dienste\DNS\[Servername]" findet.

1.0 Inhaltsverzeichnis

Wie immer kann also auch bei Win2k ein Port-Scan die Betriebssystem-Version und die aktiven Dienste herausfinden, um eine mögliche Tür ins System aufzuzeigen. Ich werde versuchen die möglichen Angriffe auf diese neu hinzugekommenen Dienste in diesem Dokument zu erläutern. Die unbrauchbaren oder hinlänglich bekannten Attacken aus den NT-Tagen werde ich hier zwar nicht ausser Acht lassen, jedoch zur Ergänzung jeweils nur kurz anschneiden.

Obwohl es unter Windows NT nicht sonderlich einfach war NetBIOS anstandslos zu deaktivieren, bietet Windows 2000 endlich diese Funktion ohne Hürden. Unter "Netzwerk bzw. DFÜ-Netzwerk" können die gewünschten Parameter ganz einfach und ohne Probleme gesetzt werden: Einfach auf die Schaltfläche Eigenschaften für Internet Protokoll (TCP/IP)" klicken, und in den erweiterten Einstellungen im "WINS-Register das "NetBIOS über TCP/IP deaktivieren". Somit wird die Fähigkeit geschaffen, ein natives TCP/IP zu benutzen, wobei die Ports 135 und 139 bei einem TCP-Portscan nicht mehr auftauchen würden.

Die Deaktivierung von NetBIOS, besonders bei Rechnern mit direkter Anbindung zum Internet, lohnt sich immer, wenn die Möglichkeit dazu besteht: Neben einer Steigerung der Performance wird weniger Angriffs-Fläche für Datenklau und DoS-Attacken geboten, da die meisten Angriffe auf NT-basierende Systeme erfahrungsgemäss auf NetBIOS-Verbindungen aufbauen.

1.0 Inhaltsverzeichnis

5.1 LDAP (Leightweight Directory Access Protocol)
Eine für den Endverbraucher grundlegendste Änderung im neuen Windows-System ist die Einführung eines auf LDAP (Leightweight Directory Access Protocol) basierenden Dienst, der von Microsoft liebevoll Active Directory genannt wird. Da dieser Zusatz einfach zu handhaben und dementsprechend praktisch ist, wird die Installation und der Nutzen dieses Features bald grossflächig in Unternehmens-Netzwerken Einzug halten. Doch nicht nur Freunden wird damit die Arbeit erleichtert, sondern auch den eigenen Feinden, da sie informellen Nutzen aus diesem Dienst ziehen werden können.

AD wurde für die Weitergabe einer einheitlichen logischen Darstellung aller für die technische Infrastruktur eines Netzwerkes nötigen Objektdaten entwickelt. Wie so oft enthält das Windows NT Resource Kit eine beachtliche Menge an Tools, um aus diesem Dienst wertvolle Informationen zu gewinnen. Das Standart-Werkzeug für den Umgang mit AD ist ein einfacher LDAP-Client mit dem Namen "ldp", der eine Verbindung zum AD-Server aufbaut und den Inhalt des Directories anzeigen kann.

Die ausgelesenen Informationen unterscheiden sich nach der Konfiguration des angesprochenen Systems. Doch ein Problem tritt bei dieser Schnüffelei zu Tage: Windows NT 4 RAS-Server (Remote Access Service) müssen in der Lage sein, ein Benutzerobjekt im AD abzufragen, um herauszufinden, ob es für einen vermeindlichen Zugriff die Berechtigung besitzt. Die Windows 2000-Installation führt den Benutzer an einer Abfrage vorbei, die es erlaubt die Sicherheit dieser Directories für die angerissene Abwärtskompatibilität herunterzuschrauben, so dass die Suchoperation für traditionelle RAS-Server zugelassen wird. Wird die schwächere Option beim Installations-Vorgang gewählt, sind die Benutzerobjekte auch bei den "ldp"-Abfragen ersichtlich: Die Namen aller eingerichteten Benutzerkonten sind ohne grössere Umschweife für einen Angreifer sichtbar.

Die Gegenmassnahme geht von netsh aus: Dieses Windows 2000-Utility bereinigt die geschwächte Sicherheit von den zuvor vorgenommenen Einstellungen während der Installation, sobald es in der Kommandozeile ausgeführt wird. Natürlich verlieren alle NT 4-RAS-Server nach  diesem Vorgang ihren Nutzen im Zusammenspiel mit den 2000-Rechnern. Der Synthax für das kleine Shell-Tool liest sich wie folgt: netsh ras set domainaccess [legacy | standart] domain = [Domänen-Name]Wird die Option legacy gesetzt, können Windows NT 4- und Windows 2000-RAS-Server in vertrauten NT 4-Domänen Benutzer aus der angegebenen Domain beglaibigen. Wird der Standart-Modus gewählt, sind die Benutzerobjekte auch dann vor einer gelegentlichen Auswertung geschützt, wenn der Schalter legacy später aktiviert wird. Die Benutzerobjekte sind erst ab dann wieder gefährdet, wenn die Lese-Berechtigung manuell wieder umgestellt wird. Für weitere Informationen zu dieser Berechtigung geben Sie "netsh ras set domainaccess /?" ein.5.2 Null-Sitzungen
Eine der beliebtesten Methoden ein System aus dem Hause Microsoft anzugreifen, bleibt seit NT erhalten: Die bekannte Null-Sitzung. Das einzige Manko beim neuen System ist der Verlust der Fähigkeit die Registry-Informationen über differente "Reg..."-API-Aufrufe auszulesen. Die Auswertung von Benutzern und Freigaben ist weiterhin mit DumpACL über eine Null-Sitzung möglich. Auch "user2sid" kann noch immer die SID der Benutzer und Gruppen identifizieren und die Inversion "sid2user" kann auch weiterhin das Gegenteil: Somit bleibt das in Erfahrung bringen von Standartbenutzern und -gruppen auch unter Windows 2000 mit einer einfachen Null-Sitzung ein Kinderspiel, auch wenn sie umbenannt wurden.

Die Gegenmassnahme beinhaltet eine Manipulation des Registry-Werts "RestrictAnonymous", welcher standartmässig auf 0 (deaktiviert) eingestellt wird. Zwar sind auch dann noch Null-Sitzungen zum System möglich, doch verlieren die meisten Angriffe, wie zum Beispiel "user2sid" und "sid2user" ihre Gefährlichkeit. Die beste Lösung gegen Null-Sitzungen ist und bleibt die NetBIOS-Ports 135 bis 139 (UDP und TCP) an der Netzwerkgrenze zu filtern.

1.0 Inhaltsverzeichnis

6.1 NetBIOS-Freigaben
Die beliebten Brute-Force-Tools wie das NetBIOS Auditing Tool (NAT) sind noch immer nützlich, wenn es um das Erraten von Passwörtern auf Windows 2000-Systemen geht.

Doch viel Gefährlicher sind aus meiner Sicht die inkompetenten Benutzer, die ihre gesamte Festplatte der Aussenwelt freigeben, manchmal sogar mit kompletten Schreibrechten ohne Passwort-Restriktionen.

Wann immer es möglich ist sollte auf die NetBIOS-Freigabe verzichtet werden. Dies gilt besonders bei jenen Systemen, die direkt vom Internet aus ansprechbar sind, denn im Netz der Netze tummeln sich über 260 Millionen potentielle Angreifer in über 250 Ländern.

Ein Angreifer könnte nun die starke Authentifizierung in einer Windows 2000-Domäne mittels SYN-Flooding auf TCP-Port 88 (Kerberos) am Domänen-Controller unterlaufen, da alle Clients auf die wackelige NT-Beglaubigungsroutine herabgesetzt werden. Das Schnüffeln ist dann nur noch ein Kinderspiel.

Das Sicherheitsmodell von Windows 2000 sieht eine Hierarchie zur Trennung von Prozessen vor. Es ist vorgesehen, dass Prozesse innerhalb nur einer Windows Station laufen und Threads stets nur in einem oder mehreren Desktops. Ein Prozess sollte nicht auf einen Desktop einer anderen Windows-Station zugreifen können. Genau dieses funktioniert aber für nicht-priviligierte Benutzer doch und damit können In- oder Outputs, zu denen auch Passworte gehören können, gelesen werden. Microsoft hat einen Patch unter http://www.microsoft.com/Downloads/Release.asp?ReleaseID=20836 eröffentlicht.

Abhilfe zu diesem Problem schafft ein Patch, der unter folgender URL heruntergeladen werden kann: http://www.microsoft.com/windows2000/downloads/critical/q253934/default.asp

1.0 Inhaltsverzeichnis

Die jüngste DoS-Attacke kann durch das Versenden von binären Nullen an einen offenen Port - betroffen sind die TCP Ports 7, 9, 21, 23, 7778 und die UDP Ports 53, 67, 68, 135, 137, 500, 1812, 1813, 2535, 3456 - des Systems heraufbeschworen werden. Diese Attacke hat dann sogleich eine 100%ige Auslastung der CPU zur Folge. Ein Angriff kann sehr einfach von einem Linux System aus durchgeführt werden, indem man netcat mit einem /dev/zero Input verwendet:
Für die TCP-Variante z.B. "nc ziel.host 7 < /dev/zero" und die UDP-Variante z.B. "nc -u ziel.host 53 < /dev/zero".

7.1 EFS (Encrypting File System)
Wurde die Datei autoexec.bat auf einem System unter Windows 2000 auf der NTFS-Festplatte verschlüsselt, können sich lokal keine Benutzer mehr anmelden. Zusätzlich ist natürlich auch der Zugang über das Netzwerk nicht mehr möglich. Das Problem ist, wenn die Datei autoexec.bat mit dem Encrypting File System (EFS) verschlüsselt ist, sie nur noch mit Hilfe eines Zertifikates des Benutzers, der sie verschlüsselt hat, entschlüsselt werden kann. Für das Login anderer Benutzer ist die Datei notwendig, aber unlesbar. Workarounds sind im Advisory und bei Microsoft (Q229716, Q185590) zu finden. Microsoft arbeitet an einem Patch.

7.2 Telnet
Für den mit allen Versionen von Windows 2000 ausgelieferten Telnet Server ist eine Möglichkeit zum Denial-of-Service gefunden worden. Hierzu schickt ein Client einen speziellen String über das Netzwerk an den Server. Dieser arbeitet erst nach einem Restart des Telnet Servers wieder normal. Der Patch steht im Internet zur Verfügung. 7.3 SMTPD
Das witzige ist auch, dass der hauseigene SMTP-Server das ganze System ausbremsen kann, sobald eine grössere Menge unzustellbarer Mails im Ausgang liegen. Diese unzustellbaren Mails blockieren Filehandles, wodurch für andere Mails unnötig viele Dateioperationen ausgeführt werden müssen. Diese Operationen kosten Rechenzeit und verlangsamen das System. Microsoft gab umgehend einen Patch zu diesem Problem heraus, der den ganzen Ablauf beim Eintreten eines solchen Problemfalls besser managen könnnen soll. Der Patch ist bisher nur auf Anfrage bei Microsoft erhältlich.7.4 HTTPD
Auch der IIS 5.0 von Windows 2000 ist gegen Remote-DoS-Attacken nicht gefeilt: Sobald bestimmte Zeichen im HTTP-Header auftauchen, stürzt das besagte System ab. Der Fix für dieses Problem ist leider auch nur wieder auf direkte Anfrage beim Hersteller erhältlich.

Der Webserver von Microsoft weist desöfteren Fehlfunktionen auf, die für (destruktive) Angriffe genutzt werden können. Es wird mir mit der Zeit wahrscheinlich nicht möglich sein, hier eine stets aktuelle Liste dieser Bugs hier zu publizieren. Informieren Sie sich zum Beispiel bei http://www.aerasec.de/security/ oder direkt bei Microsoft.

1.0 Inhaltsverzeichnis

8.1 getadmin und sechole
Den Erweiterungen der eigenen Privilegien mit den Tools "getadmin" und "sechole" wurde schon mit der Veröffentlichung von Service Pack 3 Einhalt während der NT-Epoche geboten und erzielt auch gegen das neue System keine Erfolge. Einzig kann eine DLL-Einschleusung den Gewinn für den Angreifer bedeuten, da "pwdump2" nach wie vor anstandslos funktioniert.8.2 Passwörter knacken
Die rundum überarbeitete Sicherheitsarchitektur schränkt den Einsatz von Tools aus alten NT-Tagen drastisch ein. Einen besonderen Betrag dazu leistet die Standart-Nutzung von SYSKEY bei Windows 2000 Advanced Server. Das "pwdump2"-Utility ist das einzige, das in der Lage war, einige Passwortsequenzen aus der Registry auszulesen; nämlich die, die über einen "msv1_0.dll"-API-Aufruf ansprechbar sind, der von vom besagten Programm gekapert wird. Bei Domänencontrollern mit aktiviertem AD können die Passwörter von "pwdump2" nicht angesprochen werden, da die Benutzerkonten direkt im AD gespeichert werden. Bei allen Servern, die auf AD verzichten, können die einzelnen Passwörter ausgelesen werden.

Die SAM-Datei selbst wird weiterhin im lokalen Unterverzeichnis "\system32\config" gespeichert und ist noch immer vom Betriebssystem direkt gesperrt. Trotz dem neuen NTSF v.5-Dateisystem kann noch immer von einer alten DOS-Bootdiskette mit dem NTFSDOS-Utility gebootet werden um die geschützten Daten ungehindert auf Diskette ausgelagern zu lassen. Da die neue SAM-Version jedoch mit SYSKEY verschlüsselt wurde, verlieren logischerweise die alten Tools wie L0phtcrack ihre Wirkung. Eine exakte und aktuelle Sicherungskopie der SAM-Datei taucht weiterhin im Unterverzeichnis "\repair" auf, obwohl sie nicht mehr "SAM._" genannt wird. Das "rdisk"-Programm wird durch die Microsoft Backup-Anwendung ersetzt, die eine Funktion zur Erstellung einer Rettungsdiskette enthält. Mit diesem Utility kann nur noch die SAM-Datei auf Diskette gespeichert werden, um eine lokale Kopie im Repair-Subdirectory zu verhindern.

Protected Store ist ein Teil der CryptoAPI (Windows 2000 Professional, Server und Advanced Server), der für die sichere Verwahrung sensibler Informationen wie z.B. privater Schlüssel und Zertifikate zuständig ist. Vom Design her sollte die Verschlüsselung immer mit der stärkstmöglichen Schlüssel-Länge vorgenommen werden. Die Implementation unter Windows 2000 führt die Verschlüsselung allerdings immer nur mit 40 Bit durch, auch wenn das System eine stärkere Verschlüsselung durchführen könnte. Zu Erhöhung der Sicherheit hat Microsoft ein Patch und ein Tool unter http://www.microsoft.com/Downloads/Release.asp?ReleaseID=21703 publiziert.

1.0 Inhaltsverzeichnis

9.1 Bidirektionale Vertrauensbeziehungen
Aus der Sicht eines Sicherheits-Experten ist die Abschaffung von unidirektionalen Vertrauensbeziehungen innerhalb eines Windows 2000-Netzes ein Geschenk Gottes. In einer reinen Windows 2000-Umgebung besteh nun glücklicherweise nur bidirektionale transitive Vertrauensbeziehungen, die durch Kerberos-Implementierungen bedingt sind. Die Vertrauensbeziehung zu Windows NT-Rechnern läuft aus Kompatibilitätsgründen noch immer unidirektional ab.

Seit Windows 2000 Build 2031 sind alle Mitglieder der Gruppe "Domain Admins" (eine globale Gruppe der Domain in der Win2k-Terminologie) bis zu einem bestimmten Grad in allen Domänen des eigenen Netzes berechtigt. Dies gilt besonders für die vollständige Kontrolle der AD-Konfiguration, die aus einem gemeinsamen Satz von Replikations-Beziehungen administriert wird. Ein kompromittiertes Konto dieser Superuser-Gruppe könnte daher verheerende Folgen für ein gesamtes Unternehmensnetzwerk haben, wenn ein Angreifer sich darin mit bösen Absichten zu tummeln pflegt. Aus diesem Grund empfehle ich Partner-Netzwerke oder Netze mit grosser Angriffsfläche einer eigenen Domain zuzuteilen, um übergreifende Schäden durch Attacken zu verhindern.

1.0 Inhaltsverzeichnis

10.1 Dateien verstecken
Der beliebte Trick aus den alten DOS-Tagen, als noch FAT16 im Einsatz war, hiess "Dateien mittels 'attrib' verstecken". Die versteckten Daten sind aber mit einigen kleinen Kniffen trotzdem einsehbar: Zum Beispiel wenn die Option "Alle Dateien anzeigen" auf der grafischen Oberfläche aktiviert wurde, oder in der DOS-Eingabeaufforderung der Befehl "dir /A H" ausgeführt wird.

Eine andere Möglichkeit besteht im Nutzen des NTRK cp-Posix-Utility, das auch unter Windows 2000 seinen Dienst verrichten kann, obwohl NTFS V.5 benutzt wird, um Dateien in den Datenströmen hinter anderen Dateien zu verstecken. Möchte man die Daten wieder herstellen, sind administrative Rechte nötig.

Da wohl im Moment eine zentrale Protokollierung nicht in den absehbar kommenden Versionen von Windows vorgesehen ist, werden alle Protokolle weiterhin auf lokalen Systemen gespeichert, womit das System in dieser Hinsicht weiterhin einen Minuspunkt im Gegensatz zum Syslog-Daemon unter Unix bekommt.

Neben der Schnittstelle für das Einstellen der Überwachung von Gruppenrichtlinien funktioniert das "auditpol"-Programm aus dem NTRK noch genau so gut wie vor der neuen Epoche.

Das "elsave"-Utility kann alle, auch die neuen, Protokolle über einen Remote-Zugriff löschen, sofern die entsprechenden Privilegien auf dem Ziel-System eingeholt werden konnte: elsave -s \\marc -l "File Replication Service" -C

1.0 Inhaltsverzeichnis

11.1 Manipulation der Startdateien
Da dem Angreifer am liebsten während der ganzen Uptime des Systems eine Hintertür bereitstehen soll, binden sie deren Aufstarten oft unbemerkt in den Startdateien ein. Diese Verstecke sind in der Regel bestimmte Schlüssel in der Registry ("HKLM\SOFWTARE\Microsoft\Windows\CurrentVesion\Run*") und der Autostart-Ordner, der sich nun neu als Subdirectory mit dem Namen "\Dokumente\Username\Startmenü\Programme\Autostart" versteckt.11.2 Remote-Control & trojanische Pferde
Alle Remote-Controll-Software auf den Windows NT-Zeiten reagiert anstandslos korrekt bei einem Einsatz auf einem Windows 2000-Rechner: NetBus, Back Orifice 2000 und WinVNC haben brav ihren Dienst verrichtet. Da der Quelltext der neuesten Version von Back Orifice von den Machern "Cult of the dead Cow" freigegeben wurde, könnten zur Anfangsphase einige Mutationen durch die allgemeinen Scan-Vorgänge der üblichen Anti-Viren-Software schlittern können.

Mit NetBus lassen sich auch in der aktuellen 2000er Umgebung die Tastaturschläge problemlos aufzeichnen, genau wie mit dem Invisible Keylogger Stealth (IKS). Eine Verschlüsselung des Datenstroms zwischen Tastatur und Betriebssystem wird irgendwie verständlicherweise von den Microsoft-Programmierern auch nicht in Betracht gezogen.

1.0 Inhaltsverzeichnis

12.1 Gruppenrichtlinien
Gruppenrichtlinien-Objekte (GPO) können im AD oder an einem lokalen Computer gespeichert werden, um bestimmte Konfigurationsparameter für eine ganze Domäne oder das eigene System festzulegen. GPO können auf Standorte, Domains oder Organisationseinheiten (OU) beschränkt werden, um den darin befindlichen Benutzern oder Computer vererbt werden, wie man das aus der Unix-Welt kennt.

GP lassen sich in jedem MMC-Fenster anzeigen und mit administrativen Rechten auch bearbeiten. Die GPO, die mit Windows 2000 standartmässig eingerichtet werden, sind Richtlinien für den lokalen Computer, die Standart-Domäne und den Standart-Domänencontroller. Eine weitere Möglichkeit ein GPO anzuzeigen besteht darin, die Eigenschaften eines bestimmten Verzeichnis-Objekts (Domain, OU, Standort) anzuzeigen und dann auf das Gruppenrichtlinien-Register zu klicken. Danach öffnet sich ein übersichtliches Fenster, das die gegenwärtige GPO nach Prioritäten geordnet veranschaulicht. Auch kann dadurch ermittelt werden, ob die Vererbung explizit unterdrückt wurde.

Ein GPO kann bei der Anpassung eine Vielzahl an Sicherheitsoptionen zur Verfügung stellen, um ganz individuell die Rechte des Objekts zu editieren. Besonders interessant ist der Zweig "Computerverwaltung\Windows-Einstellungen\Lokale Richtlinien\Sicherheitsrichtlinie\Sicherheitsoptionen" des GPO. Es finden sich über 30 Parameter, die richtig eingesetzt markant zur Verbesserung der Sicherheit von allen Computer-Objekten, die Mitglied der GPO sind, konfiguriert werden können. Unter anderem kann dort auch die Auswertung von Benutzerkonten und Freigaben durch anonyme Benutzer unterdrückt, oder das Administrator-Konto umbenannt werden. Diese wichtigen Einstellungen wurden bei NT 4 noch "primitiv" in der Registry verewigt. Im Zweig "Sicherheitseinstellungen" können desweiteren die Einstellungen der Richtlinien für die Benutzerkonten, die Überwachung, das Ereignisprotokoll, den Public Key und IPSec konfiguriert werden. Diese Festlegungen können Zentral durchgeführt werden, wenn die Ebene der Vererbung dementsprechend gesetzt wurde.

Die Idee hinter GPO ist genial, doch traten zum Teil unzuverlässige Ereignisse bei der Aktivierung von speziellen Kombinationen aus lokalen und zentralen Richtlinien auf. Auch die Verzögerung, bis die neuen Einstellungen aktiviert sind, ist nervend: Erst nach einer Ab- und neuer Anmeldung an der lokalen Konsole macht die Änderungen wirksam: Ein Reboot ist zum Glück in der Form nicht mehr nötig. Die Änderungen werden jedoch beim Anwenden des mitgelieferten Security-Tools "secedit" sofort wirksam. Folgender Syntax aktualisiert die Richtlinie im selben Augenblick: secedit /refreshpolicy MACHINE_POLICYUm die Richtlinien für die Benutzerkonfiguration im selben Atemzug wirksam zu machen, muss man sich folgender Eingabe bedienen: secedit /refreshpolicy USER_POLICY12.2 Mitgelieferte Sicherheitstools
Neben der schon zuvor erklärten Gruppenrichtlinien sind einige weitere Sicherheitskonfigurationstools eng im System verflochten worden, welche die Administration und Auswertung um einige Ecken erleichtern und vereinfachen können. Das Sicherheitskonfiguration- und -analysetool gibt dem Administrator die Kompetenz lokale Systemkonfigurationen nach fehlenden Übereinstimmungen mittels zuvor definierter Schablone abzusuchen. Das Utility ist als MMC-Snap-In aufrufbar, kann jedoch auch auch als Befehlszeilen-Programm mit dem Namen "secedit" exekutiert werden. Leider lässt sich diese Methode nur auf lokale Systeme ausführen und kann nicht auf die komplette Domäne übertragen werden. Doch kann die Shell-Version des Tools auch in das Start-Skript eingebunden werden, damit bei jedem Neustart die Sicherheit des Systems automatisch überprüft wird. Hier können die Entwickler jedoch noch ein bisschen Hand ansetzen, und den vielen Administratoren einen ehrenwerten Dienst mittels mehr Komfort erweisen.

1.0 Inhaltsverzeichnis

1.0 Inhaltsverzeichnis