Im allgemeinen sind es drei Dinge, die man durch die Systemsicherheit erreichen möchte
Es wird Sie Zeit für mehr Systemadministration, Rechenzeit, Plattenkapazität und damit Geld kosten. Sie werden mehr Zeit für die Nutzerschulung benötigen und Sie werden Probleme mit uneinsichtigen Nutzern haben. Die Vorteile liegen in einem ruhigen und erholsamen Schlaf für Sie und der wesentlich geringeren Wahrscheinlichkeit, daß Sie, daß Sie Zeit, Geld und Nerven für die Wiederinstandsetzung Ihres Systems aufwenden müssen.
Denken Sie daran, daß falls Ihnen die Maschine geklaut wird (fast) alles umsonst war, daß Sie das Rootpasswort auch an die Tür schreiben können, falls Sie die Bootdisketten und Installations-CD herumliegen lassen. Der Zugriff auf die Systemconsole sollte nur dem Systemadministrator möglich sein !
Nutzen Sie abhängig von dem bei Ihnen benötigten Schutzgrad auch solche Möglichkeiten, wie die Einstellung des Read-Only-Modes bei SCSI-Festplatten. (Das geht natürlich nur, wenn auf der Platte nur Binaries und Scripts liegen und Sie die Systemadministration am Freitag 16:00 Uhr durchführen können, da Sie für Updates erst die Maschine herunterfahren, ausschalten, die Festplatte umjumpern, die Maschine wieder hochfahren, Update vornehmen, Maschine herrunterfahren, ... müssen.)
Wenn die Arbeitsfähigkeit der Maschine bei Ihnen einen hohen Stellenwert hat. so müssen Sie für Defekte an der Hardware und den Fall der Fälle auch entsprechende Hardware zur Verfügung haben. Im schlimmsten Fall ist das eine vollständige Ersatzmaschine.
Selbstverständlich sollte das System auch gegen einen Crash durch Stromausfall, gegen Feuer und vor der Feuerwehr selbst, Blitzschlag, Spannungsspitzen u.s.w. geschützt sein.
Dann haben wir ja noch brandaktuelle Backup's oder etwa nicht ? Offensichtlich ist ein gutes Backup ein wichtiger Teil eines guten Sicherheitskonzepts ist. Andererseits sollte man in einem solchen Fall einen konkreten Plan haben und auf ihn vorbereitet sein. Um einen solchen Plan ordentlich aufzustellen, müssen Sie genügend paranoid sein !
Das Endziel eines Angriffes ist fast immer der Root-Account. Bei gut administrierten Systemen ist dieses Ziel nicht direkt zu erreichen. Eine häufige Zwischenstufe eines Angriffes ist ein ganz normaler Nutzeraccount. Nutzerschulungen sollten zum einen nicht nur auf die Sicherheitsproblematik beschränkt werden und zum anderen regelmäßig wiederholt werden. Vermeiden Sie jedoch den Abstumpfungseffekt durch zu häufige Wiederholungen. Geben Sie den Nutzern etwas schwarz auf weiß in die Hand und versuchen Sie den Nutzern die Notwendigkeit von Sicherheitsmaßnahmen klarzumachen. Sie werden ein funktionierendes Sicherheitskonzept nur mit den Nutzern und nicht gegen die Nutzer durchsetzten können. Legen Sie fest, was der Nutzer darf und was nicht (auch dann nicht falls es tun könnte).
Angriffe von innen kommen von den Mitgliedgliedern Ihrer eigenen Organisation, also Nutzern, die Dinge tun, die sie eigentlich nicht tun sollten. (Das schließt Angriffe über das lokale Netz mit ein, welche jedoch in diesem Vortrag nicht mit betrachtet werden sollen.)
Angriffe von außen kommen von irgendwoher über das Netz und sind nicht Gegenstand dieses Vortrages.
Nicht alle ungünstigen Aktionen sind auch gewollt. Jeder löscht einmal eine Datei, welche er gar nicht löschen wollte.
Datei mit falschen Schutzrechten + unerfahrener Nutzer = sehr schlecht.
Viren sind Programme, welche ein sogenanntes Wirtsprogramm, (welches zumeist ganz sinnvolle und nützliche Aufgaben ausführt,) infiziert und dann zumeist unangenehme Seiteneffekte verursacht. Um Viren in den Verkehr zu bringen werden sehr gern Spiele benutzt.
Trojanische Pferde sind Programme, welche neben der eigentlichen Aufgabe noch etwas anderes tun. Ein beliebiges Script könnte zum Beispiel die Zeile
rm -rf ~
enthalten. (Toller Effekt !) Spiele eignen sich toll zur Installation.
Würmer sind Programme, welche das Netz zur Verbreitung nutzen.
Karnickel (manchmal auch Bakterien genannt) erzeugen ständig neue Kindprozesse, welche das System dann durch Mangel an Systemresourcen zum Stillstand bringen.
Derartige Programme lassen sich nicht immer eindeutig in eine einzige Gruppe einteilen. Zum Beispiel kann die Schadensfunktion eines Viruses darin bestehen durch Erzeugung immer neuer Kinder Ihr System zum Absturz zu bringen.
Gegen derartige Angriffe ist man nur durch Verwendung von Programmen aus sicheren Quellen geschützt und das Durchsehen der Quellen (soweit Sie Zeit haben, jedoch immer bei Programmen mit SUID und SGID). Testen Sie die zu installierenden Programme zuerst soweit möglich in einer geschützten Umgebung (User test und Gruppe test oder nogroup = gid -2).
Ein Beispiel:
Sie erhalten von einem Kollegen folgenden Brief:
Lieber Hans !
Ich habe vergessen Dir mitzuteilen, daß ab der nächsten Woche wird der Herr Hugo Müller sein einjähriges Praktikum bei uns beginnen wird. Richte ihm doch bitte bis morgen früh einen Account unter hmueller mit dem Passwort Ketschup ein.
Warum darf dieser Account in keinem Fall eingerichtet werden ? Weder bei der Deutschen Post noch bei Email können Sie der Absenderangabe vertrauen. Auch Verschlüsselung authorisiert einen solchen Brief nicht !
Ein häufiges Problem ist bei solchen Angriffen ist, daß es für eine bestimmte Maschine mehrere verantwortliche Personen gibt. Diese Art von Angriffen wird meist mit einer besonderen Dreistigkeit geführt und beruht auf dem Prinzip, der angegriffenen Person zu suggerieren, daß man eine ihr gegeüber weisungsbefugte oder wenigstens gleichgestellte Person (unter Kollegen) ist. Diese Angriffe werden natürlich auch gegen Nutzer geführt. Derartige Verfahren werden in Hackerkreisen mit dem Begriff "social engineering" bezeichnet.
Das Passwort ist das wichtigste eingebaute Sicherheitsinstrument unter UNIX und darf daher auch nur dem Nutzer bekannt sein. Auch der Systemadministrator sollte keine Passwörter seiner Nutzer kennen ! Daher ist von den Nutzern unbedingt zu verlangen, daß ein vom Systemadministrator vergebenes Passwort sofort geändert wird. Außerdem muß ein Passwort gut sein. Namen, Lieblings-... , Teile der Adresse (steht meistens ohnehin alles auf der Web-Page oder in .plan), kurzum alles was zur Person gehört ist ungeeignet. Die Nutzer werden natürlich genau diese Dinge als Passwort verwenden, da sich diese Dinge am leichtesten merken lassen. Außerdem sollte ein Passwort mindestens ein Sonderzeichen enthalten.Viele Nutzer haben auch die Angewohnheit immer nur zwischen zwei verschiedenen Passwoerten hin und her zu wechseln. Für dieses Problem sind mir bisher jedoch nur Lösungen mit periodisch ablaufenden Scripts bekannt.
Das Passwort wird normalerweise im File /etc/passwd verschlüsselt abgelegt. Für jeden Nutzer des Systems existiert in dieser Datei eine Zeile in folgender Form:
loginname:verschlüsseltes_Passwort:UID:GID:Realname, Telefon, ... :Home-Verzeichnis:Loginshell
Diese Datei ist für jeden lesbar. Dadurch kann ein jeder die Datei mit nach Hause nehmen und dort in aller Ruhe die Passwörter Ihrer Nutzer knacken. Hacker benutzen dazu das Programm crack. Man kann dieses Programm jedoch auch dazu einsetzen, um die Passwörter seiner lieben Nutzer einmal zu testen. (Ich empfehle das sehr - aber bitte nicht erschrecken.) Das Programm ist recht einfach zu handhaben. Bevor Sie es jedoch installieren und/oder starten setzen Sie bitte Ihre umask auf 077 ! (Das Programm und die Quellen sollten nur Sie benutzen und nicht Ihre Nutzer !) Übersetzen Sie zunächst die Quellen im Unterverzeichnis Sources durch den Aufruf von make. (Beim Test musste die Datei conf.h nicht angepasst werden, es kann jedoch im Einzelfall notwendig sein.) Erstellen Sie eine Gesamtwörterbuchdatei durch einen Befehl wie
cat /usr/dict/german/*.txt > /usr/dict/words
(Je nach Land, Distribution u.s.w. muss der Befehl hinsichtlich der Namen etwas modifiziert werden.) Die Beschreibung der Regeln für die Generierung von Vorschlägen sind etwas kryptisch und sollen hier nicht näher besprochen werden, da die mitgelieferten Regeln eigentlich ganz gut sind, solange man nicht vor hat die Seite zu wechseln. Für die Regeln zur Generierung von Vorschlägen aus den verschiedenen Feldern des Passwort-Files ist die Datei Scripts/gecos.rules zuständig und für die Generierung für die Vorschläge aus den Wörterbüchern die Datei Scripts/dict.rules.
Im Unterverzeichnis DictSrc können Sie noch ein paar komprimierte Zusatzwörterbücher unterbringen. (Sehen Sie vorher im Crack Script nach welches Komprimierungsprogramm zu verwenden ist. Meist ist es gzip.) (Es gibt bis zu über 4 MB große Wörterbücher im Netz.)Im Verzeichnis Dict muß mindestens ein Wörterbuch enthalten sein. Falls Sie keines haben schreiben Sie sich eben selbst eines mit einem Wort.
Die Ergebnisse werden in je zwei Dateien für jeden Crack-Lauf ausgegeben:
out.pid - Fehlermeldungen
out.Systemnamepid - Eine Art Log des Cracklaufes (enthält auch die geknackten Passwörter)
Runtime/F.merged - enthält die Passwörter mit den zugehörigen Login.
Passen Sie das Script Crack an Ihre Bedüfnisse an. Ein Beispiel finden Sie hier .
Sie können das Programm auch automatisch durch cron starten lasen und im Anschluß falls Sie das Shadow-Password-Paket installiert haben, per Script die entsprechenden Nutzer zwingen Ihr Passwort zu ändern. Zu Beachten ist, daß Sie wenn Sie das Shadow-Password-Paket nutzen, sich ein kleines Script schreiben sollten, welches die Datei passwd in das Verzeichnis, unter welchem Sie Crack installiert haben kopiert, und die "+" Zeichen aus dem zweiten Feld gegen die verschlüsselten Passwörter aus der Datei /etc/shadow austauscht.
Eine recht einfache Methode das Password eines anderen Nutzers zu erhalten besteht darin, sich selbst einzuloggen und ein Programm ablaufen zu lassen, welches so aussieht, wie das Login-Programm, dessen Aufgabe jedoch darin besteht, Login-Name und Password eines Nutzers aufzuzeichnen. Die Sache geht wie folgt vor sich:
Wie erzwingen wir nun gute Passwörter ? Dafür gibt es die zwei Programme npasswd und passwd+. Ich möchte hier npasswd kurz beschreiben, da passwd+ wie Crack etwas kryptisch ist in den Beschreibungsdateinen, für die Prüfung des Passwortes. Außerdem schein npasswd auch weiter verbreitet zu sein als passwd+, welches wohl auch vom Entwicklungsstand her noch nicht ganz ausgereift ist. Bisher konnten von passwd+ leider nur alpha Versionen gefunden werden. Der Vorteil von passwd+ ist, daß es Prüfungen des Passwortes ähnlich dem Programm Crack durchführt. npasswd führt nur einige einfache Längenprüfung und Prüfung gegen eine oder mehrere Wortlisten durch, ohne jedoch die Wörter dabei auf Modifikation zu prüfen. (Wenn Sansibar in der Wortliste enthalten ist wird Rabisnas nicht bemängelt. Leider enthalten die Quelltexte keine Anpassungen für Linux. Daher sollte in diesem Fall das Programm vorcompiliert aus einer SICHEREN Quelle bezogen werden. (Achtung ! Bei der Nutzung des Shadow-Password-Paketes geht das mit hoher Wahrscheinlichkeit schief !)
Die Konfigurationsdatei npasswd.conf seht standartmäßig unter /usr/lib.
Um den Ort der Konfigurationsdatei zu verändern ist eine Neuübersetzung notwendig.
Das Binary sollte unter /bin stehen. Ändern Sie am besten passwd in passwd.old und erzeugen Sie einen Link passwd -> npasswd. (Bei der Nutzung des Shadow-Password-Paketes benötigen Sie das alte passwd noch um die Möglichkeiten der zwangsweisen Änderung und automatischen Sperrung des Passwortes nutzen zu können.)
Das Shadow-Password-Paket bringt einige Erweiterungen des normalen Passwort Programmes. Besonders wichtig sind zwei Dinge:
Die Installation bei Neusystemen sollte unkritisch sein, da die meisten Distributionen das Paket von sich aus anbieten. Die Umstellung eines laufenden Systems ist ebenfalls nicht schwer, erfordert aber sorgfältige Vorbereitung, Planung und Zeit. Der Vorgang ist im File doc/HOWTO sehr ausführlich beschrieben. Treffen Sie auf alle Fälle Vorkehrungen für den Fall, daß Sie etwas schief geht und Sie sich nicht wieder einloggen können. (Backup und Bootdisk)
Sehen wir uns das System genauer an. Zunächst die Rechte der beiden entscheidenden Dateien:
# ls -l /etc/passwd -rw-r--r-- 1 root root 720 Dec 31 18:01 /etc/passwd # ls -l /etc/shadow -rw------- 1 root root 397 Jan 2 23:34 /etc/shadow
Das Passwort Feld in /etc/passwd enthält nur ein "+". Das Passwort steht in /etc/shadow. Das Format der Zeilen in /etc/shadow ist wie folgt:
loginname:verschlüsseltes_Passwort:letzte_Änderung:min:max:warnung:inaktiv:verfall
Dabei haben die neuen Felder die folgende Bedeutung:
verfall ist besonders gut zu verwenden, bei Personen, von welchen bekannt ist, daß Sie nur eine vorher bestimmte Zeit lang tätig sein werden.
Damit man nicht per Hand in /etc/shadow herumändern muß gibt es das Programm usermod, dessen wichtigste Optionen sind.
Auch passwd hat einige neue Optionen:
Durch das Shadow-Password-Paketes ergeben sich damit viele neue Möglichkeiten .
Die Default-Werte für das Syslog Aging stehen im File /etc/login.defs und sind standartmäßig etwas zu freizügig. Außem sollten unbedingt su, newgrp und sg Aktivitäten geloggt werden. Des weiteren haben Logfiles eigentlich unter /etc nichts zu suchen, sondern gehören unter /var/adm/... . Des weiteren haben Sie die Möglichkeit in /etc/porttime die Loginzeiten bestimmter Nutzer zu begrenzen. Falls um 17:00 Uhr Dienstschluß ist und der Zugriff normaler Nutzer auf das System per Modem nicht vorgesehen ist, so ist nach 17:00 Uhr ohnehin nur noch ein Hacker am Werk, auf dessen Login wir durchaus verzichten können.
Weitere Möglichkeiten der Verbesserung des Password-Schutzes bieten sich durch eine integrierte Schnittstelle des Shadow-Password-Paketes, welche die Einbindung von sekundären Authentisierungsmechanismen z.B. per Chipkarte erlaubt. Hier muß der Nutzer nach der Eingabe seines Passwortes noch eine Chipkarte in ein geeignetes Lesegerät einführen. Eine andere Form eines sekundären ist zum Authentisierungsmechanismus ist z.B. die Abfrage von fünf persönlichen Dingen des Nutzers (z.B. Lieblingstier, Name seiner Großmutter, Lieblingsfarbe, ...). Die Auswahl erfolgt durch Zufall aus einer größeren Datenbank. Dabei kann man die Sache für Fremde noch zusätzlich undurchsichtig machen, in dem z.B. eine Frage falsch beantwortet werden muß.
Einige Linux Distributionen enthalten ein sicherheitstechnisch ungünstiges Login Programm, welches schon nach der Eingabe des Login Names den Login Vorgang abbricht, falls der Login-Name falsch war. Damit ist jedoch auch sofort klar welcher Teil der Kombination von Password und Login Programm falsch war. Das Login Programm sollte in diesem Fall ausgetauscht werden.
Ein anderes in UNIX-Systemen fest eingebautes Sicherheitsinstrument sind die Rechte. Jede Datei hat unter UNIX einen Eigentümer und eine Gruppe. Da ein Nutzer kann mehreren Gruppen angehören ist in /etc/passwd eine primäre Gruppe eingetragen. Mit dem Kommando newgrp neue_Gruppe kann man falls man mehreren Gruppen angehört seine aktive Gruppe ändern. Mit chgrp Gruppe kann die Zugehörigkeit einer Datei zu einer Gruppe verändert werden. (Natürlich außer für root nur in Gruppen, welchen man selber angehört.) Mit id werden aktuelle Userid (UID) und Groupid (GID) angezeigt. Dazu ein Beispiel:
bash$ id
uid=4249(fischerj) gid=1000(world)
bash$ newgrp web
bash $ id
uid=4249(fischerj) gid=101(web) groups=1000(world)
Um nun zu regeln wer mit einer Datei was tun darf gibt es Rechte, welche durch den Befehl ls mit der Option -l angezeigt werden können. Die Ausgabe entspricht dem folgenden Schema:
arwxrwxrwx n user gruppe Bytes Mon DD xxxxx name
Dabei haben die einzelnen Felder folgende Bedeutung:
Zu beachten ist, daß UNIX im allgemeinen drei Zeitangaben verwaltet. Welche Zeitangabe ausgegeben wird ist von den Optionen, mit welchen der ls Befehl aufgerufen wird abhängig. Die Rechte können von root oder vom Eigentümer der Datei mit dem Befehl chgrp geändert werden. Wichtig ist auch der Befehl umask, mit welchem festgelegt wird, mit welchen Rechten eine neu angelegte Datei versehen werden soll. (Siehe dazu auch das File /etc/permissions bei den neueren S.U.s.E. Distributionen.)
Hier nun einige Beispiele für die Manipulation von Gruppenzugehörigkeit und der Zuriffsrechte auf Dateien.
Was bedeutet nun dieses merkwürdige "s" in den Rechten ? Es zeigt an, daß dieses Programm nicht unter der UID des ausführenden Nutzers, ausgeführt wird, sondern mit der UID des Eigentümers der Datei. Das ist zum Beispiel notwendig, um bei dem Nutzer zu erlauben mit Hilfe von passwd sein Passwort oder mit Hilfe von chsh seine Login-Shell zu ändern. Normalerweise kann der Nutzer die Datei /etc/passwd bzw. /etc/shadow nicht schreiben, sondern nur root. Da jedoch das Programm passwd root gehört und unter der UID von root ausgeführt wird erhält der Nutzer für die Zeit der Ausführung von passwd root Rechte. Genauso können Programme auch unter der GID der Datei anstatt der GID des ausführenden Nutzers ausgeführt werden. Bei derartigen Programmen ist immer besondere Vorsicht geboten. Prüfen Sie ob das Programm eventuell auch mit einem gesetzen SGID-Bit statt einem SUID-Bit läuft. (Eventuell müssen Sie dafür eine neue Pseudo-Gruppe einrichten.) Versuchen Sie immer, ob ein SUID eines root gehörenden Programmes eventuell auch einem (neuen) Pseudonutzer zugeordnet werden kann. (Befehl: chown name datei - geht nur als root)
Warum sind Programme, welche mit SUID und SGID so gefährlich ? Falls ein solches Programm einen Shellausgang hat oder ein Editor mit diesem Programm aufgerufen werden kann, so kann mit Hilfe des Editors Ihre Datei /etc/passwd bzw. /etc/shadow und auch alle anderen Dateien Ihres Systems verändert werden. Bei einem Shellausgang erlangt der Nutzer sofort alle root Rechte. Derartige Ausgänge eines Programmes müssen nicht immer dokumentiert sein. Es gab und gibt auch Fälle, in welchen der Programmierer einfach vergessen hat Funktionen, welche ihm bei der Entwicklung des Programmes helfen sollten später wieder auszubauen. Solche Fehler schlagen auch oft bei Gastaccounts zu, in welchem einem Nutzer gast z.B. als Shell ein Programm /usr/bin/demo zugeordnet wird. Wenn das Programm demo einen Shellausgang hat, erlangt gast die Rechte eines normalen Nutzers und kann sich in aller Ruhe in Ihrem System umsehen. Ein guter Ausgangspunkt um ein System zu unterwandern.
Wie wichtig die Rechte sind sehen wir, wenn wir annehmen, daß egon Mitglied der Gruppen system und projekt ist und sein home Verzeichnis für die gesamte Gruppe projekt schreibbar ist. Falls nun irgendwelche Sytemfiles wie z.B. /etc/passwd (vieleicht durchaus aus gutem Grund) für die Gruppe system schreibbar sind. Nun kann die Datei .bashrc gelesen und gesichert, das Original gelöscht, modifiziert und wieder zurück kopiert werden. In der modifizierten Datei .bashrc stehen dann die Befehle zur Modifikation der Datei /etc/passwd. System erfolgreich unterwandert !
Noch besser wird das Ganze, wenn eventuell nur ein beliebiges Programm, welches der Gruppe system gehört ausgetauscht wird. Hier bietet sich die Möglichkeit, daß das nun ersetzte Programm das Originalprogramm (nennen wir es supergame) ganz normal aufruft außer wir werden von root aufgerufen, dann verändern wir die Datei /etc/passwd und stellen anschließend den Zustand vor dem Programmaustausch wieder her um unsere Spuren zu verwischen oder wir werden von felix aufgerufen (der probiert jedes neue Spiel aus, da können wir ganz sicher sein), dann werden wir eine Fehlerausschrift der Form: Fehler in supergame.conf erzeugen. Auf diesem Umweg erreichen wir, daß root die Sache auch wirklich ausprobiert, da felix sofort zu ihm gehen wird, um den Fehler beheben zu lassen. Diese recht subtile Form eines Angriffes läßt sich am besten an einem Beispiel mit ein paar Files demonstrieren.
Linux bietet mit dem ext2-Filesystem einige zusätzliche Sicherheitsmerkmale durch zusätzliche Fileattribute, welche allerdings im Gegensatz zu den normalen Fileattributen nur für alle oder niemanden gesetzt werden können. Sie stehen also nicht wie die normalen Fileattribute für den Eigentümer, die Gruppe und alle anderen gesondert zur Verfügung. Zu beachten ist, daß die Attribute a und i nur von root gesetzt oder rückgesetzt werden können. (Die man-Page weist nur bei dem Attribut i auf diesen Umstand hin.) Alle anderen Attribute können nur vom Eigentümer des Files oder von root gestzt oder rückgesetzt werden. Nun die Attribute im einzelnen:
Die erweiterten Fileattribute des ext2 Filesystems können mit lsattr zur Anzeige gebracht werden. Wichtige Optionen dabei sind:
Geändert werden können die Attribute des ext2 Filesystems mit dem Befehl
chattr [Optionen] +|- files
Die zwei wichtigen Attribute sind -V für den Verbose Mode und -R für die rekursive Änderung mit allen Unterverzeichnissen.
Auch hierzu wieder einige Beispiele .
Der erste Schritt um Angriffsversuche zu erkennen ist eine regelmäßige Überwachung des Systems. Dazu gehört die Untersuchung der Logfiles und wichtigen Konfigurationsfiles ebenso, wie die Untersuchung der laufenden Prozesse und Nutzeraktivitäten. Die besten Befehle hierfür sind who, ps mit seinen verschiedenen Optionen (die wichtigsten sind a, x, m, u, l) und top. Die meisten Nutzer haben ein gewisses Profil, was die verwendeten Programme, Loginzeiten u.s.w. betrifft. Wenn das System regelmäßig beobachtet wird werden Sie ein Gefühl für Ihre Nutzer erhalten. Sie werden zum Beispiel feststellen, daß Nutzer hubert seine Mail immer mit xmail etwa 15:30 Uhr liest, während Nutzer kunigunde eventuell immer erst um 17:00 Uhr anfängt zu arbeiten und sich per Modem einwählt, mit pine Ihre Mail liest und anschließend etwa 30 Minuten Dateien zwischen Ihrem lokalen System und dem Fileserver hin und her schaufelt. Wenn nun hubert sich plötzlich um 19:30 einwählt, was er sonst nie tut, so ist dies durchaus ein Grund einmal nachzusehen, was er so treibt.
Hier noch ein Beispiel für who. (Wer ist alles im System angemeldet ?)
root tty2 Jan 1 17:34 jan tty3 Jan 1 16:38 jan tty4 Jan 1 17:18
Achten Sie bei der Untersuchung auch auf Prozesse, die zwar lange im System verbleiben, jedoch wenig Rechenzeit konsumieren. Hier könnte ein trojanisches Pferd lauern.
Bei der Untersuchung der Dateien /etc/passwd und /etc/group auf doppelte UIDs und GIDs (also Nutzer bzw. Gruppen, welche die gleiche UID bzw. GID haben). Außerdem sollte kein realer Nutzer der primären Gruppe root angehören. Das Shadow-Password-System bietet hier die beiden Befehle pwck
user postgres: directory /usr/lib/postgres does not exist user lnx: directory /usr/lib/lnx does not exist user yard: directory /usr/lib/YARD does not exist user ftp: directory /local/ftp does not exist pwck: no changes
und grpck an.
group bin: no user daemon delete member `daemon'? n grpck: no changes
Mit faillog können Sie sich fehlgeschlagene logins anzeigen lassen und diese eventuell auch mit Hilfe eines Scripts verarbeiten lassen.
Username Failures Maximum Latest test 2 0 Wed Jan 1 16:49:28 1997 on tty4
Ein weiteres Hilfsmittel ist last, womit sich die letzten Logins verfolgen lassen.
jan tty3 Wed Jan 1 16:38 still logged in root tty2 Wed Jan 1 16:28 still logged in root tty2 Wed Jan 1 12:44 - 13:04 (00:19) runlevel ~ Wed Jan 1 12:43 reboot ~ Wed Jan 1 12:43 shutdown ~ Tue Dec 31 20:12 runlevel ~ Tue Dec 31 20:12 root tty6 Tue Dec 31 20:10 - 20:12 (00:01) root tty6 Tue Dec 31 19:26 - 19:45 (00:18) root tty5 Tue Dec 31 18:14 - 18:52 (00:38)
Die sehr viel leistungsfähigeren Programme COPS und tripwire, sowie weiterführende Maßnahmen zur Systembeobachtung sollen einem späteren Vortrag vorbehalten bleiben.
Außerdem sollte von den Möglichkeiten des syslog-daemon Gebrauch gemacht werden. Ich möchte hier jedoch nicht näher darauf eingehen, da er im Manual und einigen Büchern recht gut beschrieben ist.
Zu den rechtlichen Grundlagen sollen hier keine Aussagen gemacht werden, da diese zum großen Teil heute ganz einfach unzureichend sind. Dort, wo gesetzliche Regelungen existieren existieren zumeist mehrere gegensätzliche Auffassungen über deren Auslegung.
Allgemein kann jedoch gesagt werden, daß man sich auf einem schmalen Grad bewegt. Dazu einige Stichworte:
Kommerzielle Nutzung, sowie Änderungen ohne schriftliche Zustimmung des Autors sind untersagt.