IT-Academy Logo
Sign Up Login Help
Home - Betriebssysteme - Unix - Solaris-Spezielles - Solaris 2.6 & 7 härten



Solaris 2.6 & 7 härten

Der Vorgängerartikel zu "Solaris 8 härten". Behandelt werden die Maßnahmen, die man ergreifen sollte, um eine Solarisinstallation für eine Firewall (hier Checkpoint Firewall-1) vorzubereiten.


Autor: Jochen Berner (jberner)
Datum: 12-06-2002, 21:35:26
Referenzen: http://www.enteract.com/~lspitz/armoring.html (der englische Originalartikel)
Schwierigkeit: Fortgeschrittene
Ansichten: 9822x
Rating: Bisher keine Bewertung.

Hinweis:

Für den hier dargestellte Inhalt ist nicht der Betreiber der Plattform, sondern der jeweilige Autor verantwortlich.
Falls Sie Missbrauch vermuten, bitten wir Sie, uns unter missbrauch@it-academy.cc zu kontaktieren.

[Druckansicht] [Als E-Mail senden] [Kommentar verfassen]



Übersicht

Firewalls sind das am schnellsten wachsende technische Hilfsmittel in Bereich der Informationssicherheit. Jedoch ist jede Firewall nur so sicher wie das Betriebssystem auf dem sie läuft. Dieser Artikel befaßt sich damit, wie man Schritt für Schritt eine Solaris-Maschine härten kann, egal ob Sparc oder x86. Diese Schritte gelten in jeder Situation, als Beispiel dient jedoch eine Checkpoint Firewall-1 die unter Solaris 2.6 läuft. Am Ende dieses Artikels gibt es eine Adresse, wo man ein Script herunterladen kann, daß die meisten Aufgaben des Prozesses automatisch erledigt, inklusive der Implementierung von TCP-Wrappern.

Installation

Der beste Punkt, um mit dem Härten eines Systems zu beginnen ist ganz am Anfang: während der Betriebssysteminstallation. Da es hier um die Firewall geht, sollte man keiner bestehenden Installation trauen, sondern mit einer sauberen Neuinstallation beginnen, deren Integrität man garantieren kann.

Stell das System in ein isoliertes Netzwerk. Zu keiner Zeit sollte man das ungeschützte System an ein aktives Netz oder gar das Internet anbinden und es so einer möglichen Kompromittierung aussetzen. Ich selbst habe Systeme gesehen, die innerhalb von 15 Minuten nach Anschluß an das Internet gescannt und "gerootet" wurden. Um wichtige Dateien und Patches zu bekommen, braucht man eine zweite Maschine, die als Puffer dient. Diese zweite Maschine holt die Dateien aus dem Internet um dann anschließend an das isolierte "Konfigurationsnetz" angeschlossen zu werden um die Dateien zur Verfügung zu stellen.

Sobald die zukünftige Firewall in einem isolierten Netz steht kann man anfangen. Der erste Schritt ist die Auswahl des Betriebssystempaketes das man installieren möchte. Die Grundidee ist, nur das Minimum zu installieren, das man braucht um maximale Effizienz zu behalten. Je weniger Software installiert wird, desto weniger potentielle Sicherheitlücken entstehen. Ich empfehle die Core-Installation, da hier nur das absolute Minimum an Software installiert wird und ein sichereres Betriebssystem ensteht. Für die wirklich Paranoiden habe ich drei Checklisten erstellt, aus denen hervorgeht, wie man die Core-Installation verändern kann. Eine Liste ist für Solaris 2.6 und FW-1 4.0 (http://www.enteract.com/~lspitz/core6.txt), die zweite ist für Solaris 2.7 und FW-1 4.1 (http://www.enteract.com/~lspitz/core7.txt) und die dritte ist für Solaris 8 und FW-1.4.1 (http://www.enteract.com/~lspitz/core8.txt). Die dritte liste ist noch im Beta-Stadium, da Solaris 8 nicht von Checkpoint unterstützt wird. Sollte eine GUI gewünscht werden, zusätzliche Funktionen nötig sein oder man neu in Solaris sein, kann man auch die End-User Installation wählen. Alles andere, wie z.B. die Entwicklerinstallation, bringt nur überflüssige aber potentiell angreifbare Software mit sich. Man sollte sicherstellen, daß das Online-Handbuch mit installiert wird. Ich finde es sehr nützlich und es bringt nur wenig Gefahren mit sich. Mehr Informationen zum Minimieren einer Installation erhält man hier: http://www.sun.com/blueprints/1299/minimization.pdf

Während der Installation wird man aufgefordert, sein System zu partitionieren. Ich habe Suns Vorliebe für kleine Partitionen nie so richtig verstanden: es endet immer damit, das man die Partitionen zu klein macht und hinterher Platzprobleme bekommt. Ich mache root immer so groß wie möglich und packe alles andere dann da hinein um Platzproblemen zu entgehen. Wir brauchen aber trotzdem mehrere Partitionen um das root-Laufwerk zu schützen. Wenn wir die root-Partition nutzen um dort Daten wie Logs oder Mails abzulegen, würden wir einen denial-of-service verursachen und möglicherweise das System abstürzen lassen.

Deswegen empfehle ich immer eine separate Partition für /var, wohin die Systemlogs und Mails gehen. Indem man /var isoliert verhindert man, das die root-Partition vollgeschrieben wird. Meiner Erfahrung nach sind 400 MB genug für /var. Man kann auch darüber nachdenken für das Firewall-Logging und für /usr eigene Partitionen anzulegen. Wenn man eine eigene /usr anlegt kann man sie schreibgeschützt mounten und so die Binaries vor Änderungen schützen. Bei Checkpoints Firewall-1 geschieht das Logging standardmäßig in /etc/fw/log (/var/opt/CKPfw/log in der Version 4.0). Viele Solaris-Systeme haben zwei oder mehr Laufwerke. Wenn man das zweite Laufwerk nicht zum Spiegeln verwendet, kann man es zur Partition für das Firewall-Logging machen. Auch hier werden die anderen Partitionen geschützt, wenn die Firewall das Laufwerk vollschreiben sollte. Mit einem solchen Setup würde die Partitionierung etwa wie folgt aussehen:

/ - alles andere
/var - 400 MB
swap - 256 MB (oder normalerweise das Doppelte des RAMs)
/etc/fw/log - 2. Laufwerk(für CP FW-1 ver 3.0x)
/var/opt/CKPfw/log - 2. Laufwerk(für CP FW-1 ver 4.0x)
/var/opt/CPfw1-41/log - 2. Laufwerk(für CP FW-1 ver 4.1x)

Wenn das System nach der Installation neu gestartet wurde sollte man sicherstellen, das der von Sun empfohlene Patch Cluster (sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access) installiert wird. Um die Patches zu bekommen sollte wieder die Puffermaschine verwendet werden und die Firewall in ihrem isolierten Netz bleiben. Patches sind EXTREM WICHTIG für den Betrieb einer Firewall und sollten mindestens wöchentlich auf den neuesten Stand gebracht werden. BUGTRAQ (http://www.securityfocus.com) ist eine exzellente Quelle um hier auf dem Laufenden zu bleiben.

Dienste eliminieren

Nach der Installation aller Pakete und Patches und dem Neustart des Systems sind wir jetzt bereit das Betriebssystem zu härten. Härten besteht im wesentlichen darin, Dienste abzuschalten, Logging hinzuzufügen, verschiedene Dateien zu bearbeiten und TCP-Wrapper. Beginnen werden wir mit dem Abschalten von Diensten.

Solaris ist standardmäßig ein mächtiges Betriebssystem, das viele nützliche Dienste anbietet. Die meisten davon werden aber nicht gebraucht und stellen ein potentielles Risiko für eine Firewall dar. Der erste Ansatzpunkt ist /etc/inetd.conf. Diese Datei legt fest auf welche Dienste der /usr/sbin/inetd Daemon lauscht. Im Ursprungszustand ist /etc/inetd.conf für 35 Dienste konfiguriert, brauchen werden wir aber nur zwei: ftp und telnet. Alle anderen kann man eliminieren indem man sie auskommentiert. Dies geschieht, indem man vor alle Zeilen ein Doppelkreuz (#) setzt, mit Ausnahme dieser beiden:

ftp stream tcp6 nowait root /usr/sbin/in.ftpd in.ftpd
telnet stream tcp6 nowait root /usr/sbin/in.telnetd in.telnetd

Das Auskommentieren ist sehr wichtig, da viele der durch inetd gestarteten Prozesse ernste Bedrohungen darstellen. Überprüfen was man auskommentiert hat kann man mit folgendem Kommando (es zeigt alle Dienste an, die aktiv gelassen wurden):

#grep -v "^#" /etc/inetd.conf

Der nächste Ansatzpunkt ist /etc/rc2.d und /etc/rc3.d. Hier liegen die Startskripte die vom init-Prozess gestartet werden. Viele von ihnen werden nicht gebraucht. Um ein Skript am Starten zu hindern, ersetzt man einfach das groß geschriebene S am Anfang durch ein kleines. Auf diese Weise kann man das Skript einfach wieder in den Startvorgang einbinden, indem man das kleine gegen ein großes S ersetzt. Die folgenden Skripte werden nicht benötigt und stellen ernste Sicherheitsrisiken für ihr System dar:

/etc/rc2.d
S73nfs.client - benutzt um per NFS ein anderes Dateisystem zu mounten. Eine Firewall sollte so etwas NIEMALS tun.
S74autofs - benutzt zum automatischen mounten von fremden Dateisystemen. Noch einmal: Eine Firewall sollte so etwas NIEMALS tun.
S80lp - benutzt zum Drucken. Eine Firewall sollte eigentlich nicht drucken müssen.
S88sendmail - lauscht auf eingehende mail. Das System kann trotzdem immer noch mails senden (z.B. Alarmmeldungen) wenn man den Dienst abschaltet.
S71rpc - portmapper daemon, ein sehr unsicherer Dienst (nötig, wenn man CDE benutzen will)
S99dtlogin - CDE daemon, startet standardmäßig CDE

/etc/rc3.d
S15nfs.server - gibt Dateisysteme frei, für Firewalls eine GANZ schlechte Idee.
S76snmpdx - snmp daemon

Irgendeine grafische Benutzeroberfläche (CDE oder OpenWindows) zu benutzen ist keine gute Idee. Eine GUI sollte nur benutzt werden wenn absolut unbedingt nötig ist. CDE, die Standardoberfläche, kann man deaktivieren, indem man das S99dtlogin Startskript umbenennt. Um eine Vorstellung davon zu bekommen, wie viele Ports und Dienste CDE braucht, kann man den folgenden Befehl eingeben, während CDE läuft:

ps -aef | wc - l

Nachdem man S99dtlogin und s71rpc (für CDE benötigt) deaktiviert hat, kann man das Kommando noch einmal eingeben und vergleichen wie die Zahl der Dienste abgenommen hat. Je weniger laufen, desto besser. Für diejenigen, die die Core-Installation gewählt haben, ist alles das kein Thema, da keine Benutzeroberfläche installiert wurde.

Logging und Tuning

Nachdem wir nun so viele Dienste wie möglich abgeschaltet haben, möchten wir das Logging aktivieren. Die meisten Systemlogs liegen in /var/adm. Wir möchten dort jetzt zwei zusätzliche Logdateien anlegen: sulog und loginlog. /var/adm/sulog protokolliert alle su Versuche, egal ob erfolgreich oder nicht. Das ermöglicht es festzustellen, wer versucht hat root-Rechte auf dem System zu bekommen. /var/adm/loginlog protokolliert aufeinderfolgende fehlgeschlagene login-Versuche. Wenn ein Benutzer fünf mal versucht sich anzumelden und alle fünf Versuche schlagen fehl wird das protokolliert. Um beide Dateien zu aktivieren, einfach ein touch auf die beiden Dateien /var/adm/sulog und /var/adm/loginlog ausführen. Danach per chmod 640 die Rechte umsetzen, da beide Dateien wichtige Informationen enthalten.

Es folgt das Tuning. Dies beinhaltet verschiedene Dateimanipulationen. Als erstes wird eine Datei /etc/issue erstellt. Diese Datei ist das ASCII-Textbanner, das bei jeder telnet-Sitzung angezeigt wird. Der Text wird bei jedem Versuch, sich an dem Rechner per telnet anzumelden angezeigt.

Außerdem wird die Datei /etc/ftpusers angelegt. Jedes Benutzerkonto das in dieser Datei aufgeführt ist, kann sich NICHT per ftp mit der Maschine verbinden! Das verhindert, das Standardsystemaccounts sich per ftp mit der Maschine verbinden können. Die einfachste Methode diese Datei zu erstellen ist der Befehl

cat /etc/passwd | cut -f1 -d: > /etc/ftpusers

Man sollte sicherstellen, das jedes Konto, das doch ftp-Zugriff auf die Firewall braucht NICHT in der Datei /etc/ftpuser auftaucht.

Darüber hinaus sollte man sich überzeugen, daß root sich nicht per telnet mit der Firewall verbinden kann. Das zwingt Benutzer, sich mit ihrem eigenen Konto anzumelden um dann per su-Befehl zu root zu werden (und dafür haben wir ja eine Protokollierung eingerichtet). Diese Einstellung ist eigentlich Standard, sollte aber trotzdem in der Datei /etc/default/login überprüft werden.

Als letztes schalte ich gerne den telnet OS-Banner ab und erstelle für ftp ein eigenes Banner. Für telnet kreiert man eine Datei /etc/default/telnetd und fügt folgenden Eintrag hinzu:

BANNER="" # Eliminiert den "SunOS 5.6" Banner für Telnet

Für ftp erzeugt man eine Datei /etc/default/ftpd und fügt die Zeile

BANNER="WARNING:Authorized use only" # Warning banner for ftp

hinzu.

Verbindung zur Firewall

Es ist entscheidend, daß man einen sicheren und kontrollierten Weg findet, um auf die Firewall zuzugreifen. Oft braucht man zur Administration oder den Upload von Dateien einen Zugriff über das Netz: dieser Zugriff muß gesichert werden. Zwei Möglichkeiten sollen im folgenden diskutiert werden: ssh und TCP Wrapper.

Ich bevorzuge ssh, da es jede Kommunikation zwischen mir und der Firewall verschlüsselt. TCP-Wrapper schützen den Netzverkehr NICHT gegen Sniffer. Benutzer können immer noch jeden Tastendruck (inklusive Paßwörter) im Netz abfangen. Wenn Sie sich Sorgen über Benutzer machen, die ihre Kommunikation mit der Firewall belauschen, dann ersetzen Sie telnet/ftp durch ssh. ssh verschlüsselt jede Kommunikation mit der Firewall und erlaubt so das Hochladen von Dateien und die Administration auf eine sichere Art und Weise. ssh ähnelt TCP-Wrappern insofern, als es seine eigenen Protokollorierungsfunktionen besitzt und einschränken kann, welche Systeme sich mit ihm verbinden können. Mehr Informationen über ssh und das Programm selber inklusive Sourcecode für Clients und den Serverdaemon findet man unter http://www.ssh.org/download.html. Ich empfehle die Verwendung der Version 1.2.7, da die Versionen 2.x eine einschränkende Lizenz haben. Für 95/NT Nutzer empfehle ich wärmstens SecureCRT (http://www.vandyke.com/products/securecrt/index.html) als ssh Client.

TCP-Wrapper können zwar nicht verschlüsseln, sind aber in der Lage zu protokollieren und zu kontrollieren wer Zugriff auf das System hat. Es handelt sich hier um ein Programm, das sich um die inetd Dienste wie telnet und ftp "herumlegt". Mit einem TCP-Wrapper startet das System den Wrapper für eingehende Verbindungen über inetd, protokolliert alle Versuche und überprüft sie anhand einer Zugriffskontrolliste. Wenn der Zugriff berechtigt erfolgt, übergibt der Wrapper die Verbindung an das entsprechende Programm wie z.B. telnet. Wird die Verbindung durch die Zugriffskontrolliste abgelehnt, dann wird die Verbindung gekappt.

Einige wundern sich jetzt vielleicht warum eine Firewall solche TCP-Wrapper braucht, da sie doch alle diese Aufgaben selber erledigt. Die Antwort ist ganz einfach. Erstens bietet ein Wrapper einen zweiten Verteidigungswall für den Fall, daß die Firewall kompromittiert wurde oder abgestürzt ist. Zweitens, nicht minder wichtig, schützen Wrapper vor Firewall-Fehlkonfigurationen. Ich habe oft falsch konfigurierte Firewalls gesehen, besonders in VPN Situationen, wo unbefugten Benutzern Zugriff auf die Firewall erlaubt wurde. Drittens bieten Wrapper ein zweites Protokollierungssystem, mit dessen Hilfe man die anderen Systemprotokolle verifizieren kann.

Man kann TCP-Wrapper hier bekommen: ftp.porcupine.org/pub/security/index.html#software. Auch hier sollte man sein Puffersystem benutzen, um die Dateien herunterzuladen und zu kompilieren. Auf der Firewall sind Compiler nicht erwünscht und wir wollen die gehärtete Solarismaschine in ihrem isolierten Netzwerk schützen. Wenn man alles heruntergeladen hat, sollte man als erstes diese README Datei (www.enteract.com/~lspitz/README) durchlesen, da sie eine exzellente Einführung in das Thema TCP-Wrapper darstellt. Zwei Optionen empfehle ich beim kompilieren der TCP-Wrapper. Erstens : wählen sie die Einstellung "paranoid", da dann ein reverse lookup für alle Verbindungen durchgeführt wird. Zweitens: nutzen sie die "advanced configuration", die eigentlich recht simpel ist. Diese Konfiguration hält alle Programmteile in ihren ursprünglichen Verzeichnissen, was für zukünftige Patches wichtig sein kann. Die Implementierung von TCP-Wrappern beinhaltet das editieren verschiedener Dateien (die folgenden Beispiele beziehen sich auf die "advanced configuration"). Als erstes wird nach der Kompilierung das tcpd Programm in /usr/local/bin installiert. Danach muß die Datei /etc/inetd.conf geändert werden um festzulegen welche Dienste geschützt werden sollen (Beispiel unter http://www.enteract.com/~lspitz/example.html#D). Drittens muß die Datei /etc/syslog.conf so angepaßt werden, das tcpd mitprotokolliert wird (Beispiel unter http://www.enteract.com/~lspitz/example.html#E), dazu erzeugen sie per touch-Befehl die Datei /var/adm/tcpdlog. Als letztes müssen die Zugriffskontrollisten /etc/hosts.allow und /etc/hosts.deny angelegt werden (Beispiel unter http://www.enteract.com/~lspitz/example.html#F).

Nachdem die richtigen Dateien editiert wurden und in den richtigen Verzeichnissen stehen, wird /usr/bin/inetd per kill -HUP neu gestartet. Der Neustart des daemons stellt sicher, daß die TCP-Wrapper gestartet werden. Prüfen Sie, ob die Zugriffskontrollisten und das Logging funktionieren.

Für die wahren Paranoiker

Ich halte die oben beschriebenen Maßnahmen für absolut notwendig. Durch das Abarbeiten der obigen Schritte haben Sie die Sicherheit ihres Systems sehr verbessert. Unglücklicherweise ist ihr System nicht zu 100% sicher, noch wird es dieses jemals sein. Also habe ich für die echten Paranoiker einige zusätzliche Maßnahmen ausgearbeitet.

Als erstes werden wir die Gruppe wheel erstellen. Diese Gruppe besteht aus ausgewählten Personen, die mächtige Kommandos wie z.B. /usr/bin/su ausführen können. Durch Beschränkung der Personengruppe, die diese Kommandos ausführen kann, steigert man die Systemsicherheit. Um die Gruppe zu erstellen, laden Sie /etc/group in den vi, tragen sie die Gruppe "wheel" ein and fügen sie die Systemadministratoren in die Gruppe ein. Anschließend suchen sie die kritischen Systemprogramme, wie z.B. /usr/bin/su ändern die Besitzergruppe zu wheel und die Berechtigungen auf "nur durch Besitzer und Gruppe ausführbar" (stellen sie sicher, das bei besonderen Programmen das suid oder guid Bit unverändert bleibt). Für /usr/bin/su sähe das folgendermaßen aus:

/usr/bin/chgrp wheel /usr/bin/su
/usr/bin/chmod 4750 /usr/bin/su

Anmerkung: Nicht vergessen: für su gibt es auch noch eine andere Programmdatei in /sbin. Für 2.6 heißt diese Datei /sbin/su.static. Sie ist identisch mit /usr/bin/su, allerdings sind die Programmbibliotheken statisch gelinkt, daher auch die gestiegene Dateigröße. Vergessen sie nicht, diese Datei auch zu ändern.

Als zweites werden wir die Dateien .rhosts, .netrc und /etc/hosts.equiv sperren. Die r-Befehle nutzen diese Dateien um auf Systeme zuzugreifen. Um sie sperren, benutzen sie den touch-Befehl für jede der Dateien und setzen sie anschließend die Berechtigungen auf 0. Auf diese Weise kann niemand die Dateien erstellen oder verändern. Die Befehle sehen z.B. so aus:

/usr/bin/touch /.rhosts /.netrc /etc/hosts.equiv
/usr/bin/chmod 0 /.rhosts /.netrc /etc/hosts.equiv

Außerdem ändern wir die Parameter, die die Sequenznummer beim Aufbau einer TCP-Verbindung bestimmen. Indem wir diese Zahl zu einer wirklichen Zufallszahl machen, schützen wir das System gegen "Session hijacking" und IP-Spoofing. Erreichen kann man das, indem man den Wert TPC_STRONG_ISS=2 in die Datei /etc/default/inetinit einträgt (Beispiel unter http://www.enteract.com/~lspitz/example.html#G). Standardmäßig trägt das System beim Installieren hier eine 1 ein, was nicht so sicher ist.

Um sich gegen Pufferüberläufe oder "stack smashing" zu schützen fügt man folgende Zeilen in die /etc/system ein:

set noexec_user_stack=1
set noexec_user_stack_log=1

Als nächstes modifizieren wir das IP-Modul. Fügen sie diese Befehle einem ihrer Startskripte hinzu. Mehr Informationen zum Thema ndd und IP-Tuning findet man hier www.sun.com/blueprints/1299/network.pdf.

### Set kernel parameters for /dev/ip
ndd -set /dev/ip ip_respond_to_echo_broadcast 0
ndd -set /dev/ip ip_forward_directed_broadcasts 0
ndd -set /dev/ip ip_respond_to_timestamp 0
ndd -set /dev/ip ip_respond_to_timestamp_broadcast 0
ndd -set /dev/ip ip_forward_src_routed 0
ndd -set /dev/ip ip_ignore_redirect 1

Als letztes eliminiere ich gerne so viele suid root Programme wie möglich. suid root Programme stellen ein großes Sicherheitsrisiko dar, da man angreifbare Versionen benutzen kann, um root zu werden. Da es sich hier um ein spezielles System mit nur wenigen Accounts handelt, kann man die meisten suid Programme abschalten oder löschen. Um alle diese suid root Programme zu finden, verwendet man den folgenden Befehl:

find / -type f -perm -4000 -exec ls -lL {} \; | tee -a /var/tmp/suid.txt

Nachdem man alle Programme identifiziert hat, kann man die meisten davon entfernen, indem man die Berechtigungen auf 555 setzt oder sie gleich ganz löscht. Zum Beispiel habe ich das suid Bit von den hier (www.enteract.com/~lspitz/example.html#I) aufgelisteten Dateien einer Solaris 2.7 Core-Installation entfernt.

Schlussfolgerung

Wir haben einige der grundlegenden Schritte kennengelernt mit denen man eine Solaris Installation härten kann. Der Schlüssel zu einem sicheren System liegt darin, nur die minimale Software zu installieren und einen schichtweisen Schutz (z.B. mit TCP-Wrappern) zu implementieren. Es gibt noch viele weitere Möglichkeiten die man hat, wie z.B. sudo (http://www.fisica.uson.mx/carlos/Security/Programs/prog-full.html), das es dem Administrator erlaubt, Benutzern eingeschränkte root-Rechtezu geben und ihre Aktivitäten zu überwachen, tripwire (ftp.cerias.purdue.edu/pub/tools/unix/ids/tripwire/) das Veränderungen an den Systemdateien überwacht und swatch (http://www.enteract.com/~lspitz/swatch.html) das automatisch Logdateien überwacht und Alarm schlägt. Bedenken Sie das kein System 100% sicher ist. Mit den beschriebenen Maßnahmen können sie jedoch das Risiko von Sicherheitsproblemen erheblich reduzieren.

Mehr Informationen wie man sein Solaris-System sicherer macht, findet man auf den Sun Microsystems BLueprint Seiten und dort besonders hier: http://www.sun.com/blueprints/0100/security.pdf

Den wirklich Interessierten empfehle ich sich mit Brad Powell's "Härtungsskript" Titan (http://www.fish.com/~brad/titan/Titan-Docs/TITAN_documentation.html). Dieses professionelle Werkzeug ist wesentlicher mächtiger und modularer aufgebaut als das was ich hier vorgestellt habe und beschreibt Sicherheit wesentlich detaillierter. Daneben kann man auch hier mal reinschauen: yassp.park.xerox.com (Yet Another Security Solaris Package).

Downloads

Um ihnen Zeit und Mühen zu sparen, habe ich ein Skript erstellt, das alles was in diesem Artikel besprochen worden ist macht. Es testet ihr Solaris-System und nimmt alle angesprochenen Änderungen vor, wobei es alle veränderten Dateien zuerst sichert. Darüber hinaus installiert dieses Skript auch TCP-Wrapper. Es testet welcher Prozessor (x86 oder Sparc) genutzt wird und welche Version (2.5.1, 26., 2.7 und 2.8) läuft und nimmt die passenden Änderungen vor. Ich empfehle, dieses Skript nur auf neuen Installationen anzuwenden. Kommentare oder Empfehlungen schicken sie bitte an lance@spitzner.net

Downloadadresse für armor-1.3.1.tar.Z: http://www.enteract.com/~lspitz/armor-1.3.1.tar.Z
MD5 Checksum for armor-1.3.1.tar.Z = 45009a639877c7c4015564be97af74fa

Anmerkungen des Übersetzers:

Der original englischsprachige Artikel ist zu finden unter http://www.enteract.com/~lspitz/armoring.html. Da ich kein professioneller Übersetzer bin, können sich durchaus Unklarheiten und falsche (hoffentlich nicht sinnentstellende) Übersetzungen eingeschlichen haben. Korrekturen, Vorschläge oder sonstiges bitte an Jochen_Berner@hotmail.com.



[back to top]



Userdaten
User nicht eingeloggt

Gesamtranking
Werbung
Datenbankstand
Autoren:04511
Artikel:00815
Glossar:04116
News:13565
Userbeiträge:16552
Queueeinträge:06248
News Umfrage
Ihre Anforderungen an ein Online-Zeiterfassungs-Produkt?
Mobile Nutzung möglich (Ipone, Android)
Externe API Schnittstelle/Plugins dritter
Zeiterfassung meiner Mitarbeiter
Exportieren in CSV/XLS
Siehe Kommentar



[Results] | [Archiv] Votes: 1158
Comments: 0