<!-- CVS revision of original english document "1.20" -->

<chapt>Häufig gestellte Fragen / Frequently asked Questions (FAQ)

<p>Dieses Kapitel führt Sie in ein paar der am häufigsten
gestellten Fragen in der Security-Mailingliste von Debian ein. Sie sollten sie
lesen, bevor Sie dort etwas posten, oder die Leute werden Ihnen
»RTFM!« sagen.


<sect>Sicherheit im Debian Betriebssystem

<sect1>Ist Debian sicherer als X?

<p>Ein System ist so sicher, wie der Administrator fähig ist, es
sicher zu machen. Debians Standardinstallation von Diensten zielt darauf ab,
<em>sicher</em> zu sein. Sie ist aber nicht so paranoid wie andere
Betriebssysteme, die Dienste <em>standardmäßig abgeschaltet</em>. In jedem Fall
muss der Systemadministrator die Sicherheit des System den lokalen
Sicherheitsmaßstäben anpassen.

<p>Für eine Übersicht der Sicherheitslücken von vielen Betriebssystemen sollten
Sie sich die <url id="http://www.cert.org/stats/cert_stats.html"
name="US-CERT-Statistik"> ansehen oder sich selber Statistiken mit der <url
id="http://nvd.nist.gov/statistics.cfm" name="National Vulnerability Database">
(früher ICAT) erstellen. Sind diese Daten nützlich? Es müssen verschiedene
Faktoren berücksichtigt werden, wenn die Daten interpretiert werden sollen. Man
sollte beachten, dass diese Daten nicht dazu verwendet werden können, um die
Verwundbarkeit eines Betriebssystems mit der eines anderen zu vergleichen.
<footnote>
Zum Beispiel könnte es auf Grundlage einiger Daten scheinen, dass
Windows NT sicherer ist als Linux. Dies wäre eine fragwürdige Annahme. Das
liegt daran, dass Linux-Distributionen normalerweise viel mehr Anwendungen zur
Verfügung stellen als Microsofts Windows NT. Dieses Problem des <em>Abzählens
von Sicherheitslücken</em> wird besser in <url
id="http://www.dwheeler.com/oss_fs_why.html#security" name="Why Open Source
Software / Free Software (OSS/FS)? Look at the Numbers!"> von David A. Wheeler
beschrieben.
</footnote>
Bedenken Sie außerdem, dass sich einige registrierte Sicherheitslücken im
Zusammenhang mit Debian nur auf den <em>Unstable</em>-Zweig, also den nicht
offiziell veröffentlichten Zweig, beziehen.


<sect2>Ist Debian sicherer als andere Linux-Distributionen (wie Red Hat, SuSE,
...)?

<p>Der Unterschied zwischen den Linux-Distributionen ist nicht sehr groß mit
Ausnahme der Basisinstallation und der Paketverwaltung. Die meisten
Distributionen beinhalten zum Großteil die gleichen Anwendungen. Der
Hauptunterschied besteht in den Versionen dieser Programme, die mit der
stabilen Veröffentlichung der Distribution ausgeliefert werden. Zum Beispiel
sind der Kernel, Bind, Apache, OpenSSH, Xorg, gcc, zlib, etc. in allen
Linux-Distributionen vorhanden.

<p>Ein Beispiel: Red Hat hatte Pech und wurde veröffentlicht, als foo 1.2.3
aktuell war. Später wurde darin eine Sicherheitslücke entdeckt. Dagegen hatte
Debian das Glück, dass es mit foo 1.2.4 ausgeliefert wurde, in dem der Fehler
schon behoben war. Das war der Fall beim großen Problem mit <url
id="http://www.cert.org/advisories/CA-2000-17.html" name="rpc.statd"> vor ein
paar Jahren.

<p>Es besteht eine weitgehende Zusammenarbeit zwischen den jeweiligen
Sicherheitsteams der großen Linux-Distributionen. Bekannte
Sicherheitsaktualisierungen werden selten (wenn nicht sogar nie) von den
Anbietern der Distribution nicht eingespielt. Das Wissen um eine
Sicherheitslücke wird niemals vor anderen Anbietern von Distributionen geheim
gehalten, da die Ausbesserungen gewöhnlich vom Programmautor oder von <url
id="http://www.cert.org" name="CERT"> koordiniert werden. Das hat zur Folge,
dass notwendige Sicherheitsaktualisierungen üblicherweise zur selben Zeit
veröffentlicht werden. Damit ist die relative Sicherheit der verschiedenen
Distributionen ziemlich ähnlich.

<p>Einer großen Vorteile von Debian in Hinblick auf die Sicherheit ist die
Leichtigkeit von Systemaktualisierungen mit <prgn>apt</prgn>. Hier sind ein
paar andere Aspekte über die Sicherheit in Debian, die Sie berücksichtigen
sollten:

<list>

<item>Debian bietet mehr Sicherheitswerkzeuge an als andere
Distributionen. Vergleichen Sie dazu <ref id="sec-tools">.

<item>Debians Standardinstallation ist kleiner (weniger Funktionen) und daher
sicherer. Andere Distributionen tendieren im Namen der Benutzerfreundlichkeit
dazu, standardmäßig viele Dienst zu installieren, und manchmal sind diese nicht
ordentlich konfiguriert (denken Sie an <url
id="http://www.sophos.com/virusinfo/analyses/linuxlion.html" name="Lion"> oder <url
id="http://www.sophos.com/virusinfo/analyses/linuxramen.html" name="Ramen">). Debians
Installation ist nicht so streng wie OpenBSD (dort laufen Daemonen standardmäßig
nicht), aber es ist ein guter Kompromiss.
<footnote>
Ohne die Tatsache in Abrede zu stellen, dass einige Distributionen wie Red Hat
oder Mandrake auch die Sicherheit bei ihrer Standardinstallation
berücksichtigen, indem der Nutzer <em>Sicherheitsprofile</em> auswählen kann,
oder Wizards verwendet werden, um beim Einrichten einer <em>Personal
Firewall</em> zu helfen.
</footnote>

<item>Debian stellt die besten Verfahren zur Sicherheit in Dokumenten wie
diesem vor.

</list>


<sect1>In Bugtraq gibt es viele Debian-Fehler. Heißt das, dass es sehr
gefährdet ist?

<p>Die Debian-Distribution enthält eine große und wachsende Zahl von
Softwarepaketen, wahrscheinlich sogar mehr als mit vielen proprietären
Betriebssystem geliefert wird. Je mehr Pakete installiert sind, desto größer
ist die Möglichkeit von Sicherheitslücken in einem System.

<p>Immer mehr Menschen untersuchen den Quellcode, um Fehler zu entdecken. Es
gibt viele Anweisungen im Zusammenhang mit Audits des Quellcodes von großen
Softwarekomponenten, die in Debian enthalten sind. Immer wenn ein solcher Audit
Sicherheitslücken aufdeckt, werden sie ausgebessert und eine Anweisung wird an
Listen wie Bugtraq geschickt.

<p>Fehler, die in der Debian-Distribution vorhanden sind, betreffen
normalerweise auch andere Anbieter und Distributionen. Prüfen Sie einfach den
"Debian specific: yes/no"-Abschnitt am Anfang jeder Anweisung (DSA).


<sect1>Hat Debian irgendein Zertifikat für Sicherheit?

<p>Die kurze Antwort: Nein. 

<p>Die lange Antwort: Zertifikate kosten Geld (besonders ein <em>seriöses</em>
Sicherheitszertifikat). Niemand hat die Ressourcen aufgebracht, um Debian
GNU/Linux beispielsweise mit irgendeinem Level des
<!-- NOTE: commoncriteria.org is no longer available, jfs -->
<url id="http://niap.nist.gov/cc-scheme/st/" name="Common Criteria">
zertifizieren zu lassen. Wenn Sie daran interessiert sind, eine
GNU/Linux-Distribution mit Sicherheitszertifikaten zu haben, stellen Sie uns
die Ressourcen zur Verfügung, um dies möglich zu machen.

<p>Es gibt im Moment mindestens zwei Linux-Distributionen, die mit
verschiedenen <url id="http://en.wikipedia.org/wiki/Evaluation_Assurance_Level"
name="EAL"> Levels zertifiziert sind. Beachten Sie, dass einige CC-Tests im
<url id="http://ltp.sourceforge.net" name="Linux Testing Project"> vorhanden
sind, welche in Debian durch <package>ltp</package> angeboten wird.


<sect1>Gibt es irgendein Abhärtungsprogramm für Debian?

<p>Ja. <url name="Bastille Linux" id="http://bastille-linux.sourceforge.net">,
das sich ursprünglich an anderen Linux-Distributionen (Red Hat und Mandrake)
orientierte, es funktioniert derzeit auch mit Debian. Es sind Maßnahmen
eingeleitet, um Änderungen am Originalprogramm auch in das Debian-Paket
<package>bastille</package> einfließen zu lassen.

<p>Manche Leute glauben jedoch, dass ein Absicherungsprogramm nicht die
Notwendigkeit einer guten Administration ersetzt.


<sect1>Ich möchte einen XYZ-Dienst laufen lassen. Welchen sollte ich
benutzen?

<p>Einer der größten Stärken von Debian ist die große Vielfalt von Paketen, die
die gleichen Funktionen erfüllen (DNS-Server, Mail-Server, FTP-Server,
Web-Server etc.). Das kann einen unerfahrenen Administrator verwirren, wenn er
herausfinden will, welches Paket das richtige für ihn ist. Die beste Wahl hängt
in der Balance zwischen Ihrem Bedürfnis nach Funktionalität und dem nach
Sicherheit in der jeweiligen Situation ab. Im folgenden einige Fragen, die Sie
sich stellen sollten, wenn Sie zwischen ähnlichen Paketen entscheiden müssen:

<list>

<item>Wird es noch vom Originalautor betreut? Wann war die
letzte Veröffentlichung?

<item>Ist das Paket ausgereift? Die Versionsnummer sagt <em>nichts</em> darüber
aus, wie ausgereift es ist. Versuchen Sie seine Geschichte nachzuvollziehen.

<item>Ist es von Fehlern durchsetzt? Gab es Sicherheits-Ankündigungen im Zusammenhang
mit ihm?

<item>Stellt die Software die ganze Funktionalität zur Verfügung, die Sie
benötigen? Bietet es mehr, als Sie wirklich brauchen?

</list>


<sect1>Wie mache ich den Dienst XYZ unter Debian sicherer?
<!-- Changed to XYZ in order to avoid confusion :) jfs -->

<p>Sie werden in diesem Dokument Informationen über das Absichern von einigen
Diensten (FTP, Bind) unter Debian GNU/Linux finden. Für Dienste die hier nicht
abgedeckt werden, prüfen Sie die Programm-Dokumentation oder allgemeine
Linux-Informationen. Die meisten Sicherheitshinweise für Unix-Systeme sind auch
auf Debian anwendbar. So wird Dienst X unter Debian in den meisten Fällen wie
in einer anderen Linux-Distribution (oder Un*x, was das betrifft) abgesichert.


<sect1>Wie kann ich die Banner der Dienste entfernen?

<p>Wenn Sie z.B. nicht wollen, dass Nutzer sich  mit Ihrem POP3-Daemon
verbinden und dadurch Informationen über Ihr System erlangen, sollten Sie das
Banner, das der Dienst den Nutzern zeigt, entfernen (oder verändern).
<footnote>
Beachten Sie, dass das 'security by obscurity' ist und daher auf lange Sicht
gesehen wahrscheinlich nicht der Mühe wert ist.
</footnote>
Wie Sie das anstellen können. hängt von der Software ab, mit der Sie einen
bestimmten Dienst betreiben. Für <prgn>postfix</prgn> stellen Sie
beispielsweise das SMTP-Banner in <file>/etc/postfix/main.cf</file> ein: 
<example> 
  smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU) 
</example>

<p>Andere Software kann nicht so leicht verändert
werden. <package>ssh</package> muss neu kompiliert werden, um die angezeigte
Version zu ändern. Stellen Sie sicher, dass sie nicht den ersten Teil des
Banners (<tt>SSH-2.0</tt>) entfernen, da Clients ihn verwenden, um die von
Ihrem Paket unterstützten Protokolle zu identifizieren.


<sect1>Sind alle Debian Pakete sicher?

<p>Das Sicherheitsteam von Debian kann nicht alle Pakete aus Debian auf
potenzielle Sicherheitslücken hin analysieren, da es einfach nicht genug
Ressourcen gibt, um für das gesamte Projekt ein Quellcodeaudit
durchzuführen. Allerdings profitiert Debian von den Quellcode-Prüfungen durch
die Originalautoren.
<!-- FIXME kernel-audit doesn't exist on sourceforge:
or by other projects like the <url name="Linux
Kernel Security Audit Project"
id="http://sourceforge.net/projects/kernel-audit/">, or the <url name="Linux
Security-Audit Project" id="http://www.lsap.org/">.
-->

<p>Tatsächlich könnte ein Debian-Entwickler in einem Paket einen Trojaner
verbreiten, und es gibt keine Möglichkeit das nachzuprüfen. Sogar wenn es in
einen Zweig von Debian eingeführt werden würde, wäre es unmöglich, alle
möglichen Situationen abzudecken, in denen der Trojaner ausgeführt werden
würde. Das ist der Grund, warum Debian eine <em>"Keine
Gewährleistung"</em>-Klausel in seiner Lizenz hat.

<p>Allerdings können Debian-Benutzer insofern
Vertrauen fassen, dass der stabile Quellcode eine breite Prüfung
hinter sich hat. Die meisten Probleme würden dabei durch
Benutzung entdeckt. Es ist zu empfehlen, ungetestete
Software auf kritischen Systemen zu installieren, wenn Sie nicht die
notwendige Code-Prüfung vornehmen können. In jedem Fall
gewährleistet der Aufnahmeprozess in die Distribution (mit
digitalen Signaturen), dass im Falle von in die Distribution
eingeschleusten Sicherheitsproblemen das Problem letztendlich zum
Entwickler zurückgeführt werden kann. Das Debian-Projekt hat
diese Angelegenheiten nie auf die leichte Schulter genommen.


<sect1>Warum sind einige Log- und Konfigurationsdateien für die Welt lesbar?
Ist das nicht unsicher?

<p>Natürlich können Sie die Standardrecht von Debian auf Ihrem System
abändern. Der aktuelle Grundsatz in Bezug auf Log- und Konfigurationsdateien
besagt, dass sie für die Welt lesbar sind, <em>es sei denn</em>, sie enthalten
sensible Informationen.

<p>Seien Sie vorsichtig, wenn Sie Änderungen vornehmen:

<list>

<item>Prozesse könnten nicht mehr in der Lage sein, in Log-Dateien zu
schreiben, wenn Sie ihre Rechte einschränken.

<item>Einige Anwendungen könnten nicht mehr funktionieren, wenn sie ihre
Konfigurationsdatei nicht mehr lesen können. Wenn Sie zum Beispiel das Recht,
für die Welt lesbar zu sein, von <file>/etc/samba/smb.conf</file> entfernen,
kann das Programm <prgn>smbclient</prgn> nicht funktionieren, wenn es von einem
normalen Nutzer ausgeführt wird.

</list>

<p>FIXME: Check if this is written in the Policy. Some packages
(i.e. ftp daemons) seem to enforce different permissions.


<sect1>Warum hat /root/ (oder NutzerX) die Rechte 755?

<p>Tatsächlich kann die gleiche Frage auch für jeden anderen Nutzer gestellt
werden. Da Debians Standardinstallation <em>keine</em> Dateien unter diesem
Verzeichnis abgelegt, sind keine sensiblen Informationen vorhanden, die
geschützt werden müssten. Wenn Sie denken, dass diese Rechte für Ihr System zu
locker sind, können Sie sie auf 750 einschränken. Für Nutzer sollten Sie <ref
id="limit-user-perm"> lesen.

<p>Dieser <url
id="http://lists.debian.org/debian-devel/2000/debian-devel-200011/msg00783.html"
name= "Thread"> der Sicherheitsmailingliste von Debian hat weitere Ausführungen
zu diesem Thema.


<sect1>Nach der Installation von grsec oder einer Firewall bekomme ich viele
Nachrichten auf der Konsole. Wie entferne ich sie?

<p>Wenn Sie Nachrichten auf der Konsole empfangen und
<file>/etc/syslog.conf</file> so eingerichtet haben, dass sie in Dateien oder
auf ein spezielles TTY umgeleitet werden, sehen Sie vielleicht Nachrichten, die
direkt an die Konsole geschickt werden.

<p>Der Standardloglevel der Konsole ist bei jeden Kernel sieben, was bedeutet,
dass alle Nachrichten mit einer niedrigeren Priorität auf der Konsole
erscheinen werden. Für gewöhnlich haben Firewalls (die LOG-Regel) und einige
andere Sicherheitswerkzeuge eine niedrigere Log-Priorität. Daher werden ihre
Logs direkt an die Konsole geschickt.

<p>Um die Nachrichten, die an die Konsole geschickt werden, nicht verringern,
können Sie <prgn>dmesg</prgn> (Option <tt>-n</tt>, vergleichen Sie <manref
section="8" name="dmesg">) verwenden, das den Ringspeicher des Kernel
untersucht und <em>steuert</em>. Damit das nach dem nächsten Neustart in
Ordnung ist, ändern Sie in <file>/etc/init.d/klogd</file>

<example>
  KLOGD=""
</example>

<p>zu

<example>
  KLOGD="-c 4"
</example>

<p>ab.

<p>Verwenden Sie eine niedrigere Nummer für <tt>-c</tt>, wenn Sie immer noch
unerwünschte Nachrichten sehen. Eine Beschreibung der verschiedenen Loglevels
befindet sich in <file>/usr/include/sys/syslog.h</file>:

<example>
  #define LOG_EMERG       0       /* system is unusable */
  #define LOG_ALERT       1       /* action must be taken immediately */
  #define LOG_CRIT        2       /* critical conditions */
  #define LOG_ERR         3       /* error conditions */
  #define LOG_WARNING     4       /* warning conditions */
  #define LOG_NOTICE      5       /* normal but significant condition */
  #define LOG_INFO        6       /* informational */
  #define LOG_DEBUG       7       /* debug-level messages */
</example>


<sect1 id="faq-os-users">Benutzer und Gruppen des Betriebssystems

<sect2>Sind alle Systemnutzer notwendig?

<p>Ja und nein. Debian wird mit einigen vordefinierten Nutzern (User-ID (UID)
&lt; 99, beschrieben in der <url name="Debian Policy"
id="http://www.de.debian.org/doc/debian-policy/"> oder in
<file>/usr/share/doc/base-passwd/README</file>) geliefert. Dadurch wird die
Installation einiger Dienste erleichtert, für die es notwendig ist, unter einem
passenden Nutzer/UID zu laufen. Wenn Sie nicht vorhaben, neue Dienste zu
installieren, können Sie die Nutzer entfernen, denen keine Dateien auf Ihrem
System gehören und die keine Dienste laufen lassen. Unabhängig davon ist das
Standardverhalten in Debian, dass UIDs von 0 bis 99 reserviert sind und UIDs
von 100 bis 999 von Paketen bei der Installation erstellt werden und gelöscht
werden, wenn das Pakete vollständig gelöscht wird (purge) wird.

<p>Benutzer, denen keine Dateien gehören, finden Sie leicht mit dem folgenden
Kommando<footnote>Bedenken Sie, dass damit Ihr gesamtes System durchsucht
wird. Falls Sie viele Festplatten und Partitionen haben, sollten Sie u.U. den
Suchrahmen einschränken.</footnote> (führen Sie es als Root aus, da ein normaler Benutzer nicht genügend
Zugriffsrechte haben könnte, um einige sensible Verzeichnisse zu
durchsuchen):

<!-- Took the liberty to make this script more secure ... >:^) // era -->
<example>
  cut -f 1 -d : /etc/passwd | \
  while read i; do find / -user "$i" | grep -q . || echo "$i"; done
</example>

<p>Diese Nutzer kommen aus dem Paket <package>base-passwd</package>. Sie
finden Informationen über die Behandlung dieser Nutzer unter Debian in
der Dokumentation des Pakets.
Es folgt nun eine Liste der Standardnutzer (mit einer entsprechenden
Gruppe):

<list>

<item>root:	Root ist (typischerweise) der Superuser.

<item>daemon:	Einige unprivilegierte Daemonen, die Dateien auf
	die Festplatte schreiben müssen, laufen als daemon.daemon
(z.B. <prgn>portmap</prgn>, <prgn>atd</prgn>, wahrscheinlich noch
andere). Daemonen, die keine eigenen Dateien besitzen müssen, können
stattdessen als nobody.nogroup laufen. Komplexere oder sicherheitsbewusste
Daemonen laufen als eigenständige Nutzer.  Der Nutzer daemon ist auch praktisch
für lokal installierte Daemons.

<item>bin: 
	   aus historischen Gründen beibehalten.

<item>sys:
	   das gleiche wie bei bin.
              Jedoch gehören /dev/vcs* und
	      <file>/var/spool/cups</file> der Gruppe sys.

<item>sync:	Die Shell des Nutzers sync ist <file>/bin/sync</file>.
	Wenn das Passwort auf etwas leicht zu ratendes gesetzt wurde (zum
Beispiel »«), kann jeder das System von der Konsole aus synchronisieren lassen,
auch wenn er kein Konto hat.

<item>games:	Viele Spiele sind SETGID »games«, damit sie ihre
Highscore-Dateien schreiben können. Dies wird in der Richtlinie erklärt.

<item>man: Das Programm man läuft (manchmal) als Benutzer »man«, damit es
Cat-Seiten nach <file>/var/cache/man</file> schreiben kann.

<item>lp:
	wird von Druck-Daemonen benutzt

<item>mail:
	Mailboxen unter <file>/var/mail</file> gehören der Gruppe
»mail«, wie in der Policy erklärt wird. Der Benutzer und die Gruppe werden auch von
verschiedene MTAs zu anderen Zwecken benutzt.

<item>news:
	Verschiedene News-Server und ähnliche Programme (zum
Beispiel <prgn>suck</prgn>) benutzen den Nutzer und die Gruppe news auf
unterschiedliche Weise. Dateien im news-Spool gehören häufig dem Nutzer und der
Gruppe news. Programme wie <prgn>inews</prgn>, die man benutzen kann, um News
zu posten, sind normalerweise SETGID news.

<item>uucp:	Der Nutzer uucp und die Gruppe uucp werden vom UUCP-Subsystem
	benutzt. Ihnen gehören Spool- und Konfigurationsdateien.
Nutzer in der Gruppe uucp können uucico aufrufen.

<item>proxy: Wie Daemon wird dieser Nutzer und diese Gruppe von manchen
Daemonen (insbesondere Proxy-Daemonen) verwendet, die keine spezielle User-ID
haben, aber eigene Dateien besitzen müssen. Zum Beispiel wird die Gruppe proxy
von <prgn>pdnsd</prgn> benutzt, und <prgn>squid</prgn> läuft als Nutzer proxy.

<item>majordom:	<prgn>Majordomo</prgn> hat auf Debian-Systemen aus historischen
Gründen eine statisch zugewiesene UID. Auf neuen Systemen wird sie
	nicht installiert.

<item>postgres:	<prgn>Postgresql</prgn>-Datenbanken gehören diesem Nutzer und
dieser 
	Gruppe. Alle Dateien in <file>/var/lib/postgresql</file>
gehören diesem Nutzer, um anständige Sicherheit zu
	gewährleisten.

<item>www-data:	Einige Web-Server laufen als www-data.
        Web-Inhalte sollten
<em>nicht</em> diesem Nutzer gehören, andernfalls wäre ein kompromittierter
	Web-Server in der Lage, eine Web-Seite zu
	überschreiben. Daten, die der Web-Server schreibt,
	einschließlich Log-Dateien, gehören www-data.

<item>backup: So können Backup-/Wiederherstellungszuständigkeiten lokal an
irgendjemanden ohne volle Root-Zugriff delegiert werden.

<item>operator: operator ist historisch (und praktisch) das einzige
'Nutzer'-Konto, in das man sich entfernt einloggen kann, und das nicht von
NIS/NFS abhängt.

<item>list:	Mailinglisten-Archive und Daten gehören diesem Nutzer und
	dieser Gruppe. Manche Mailinglisten-Programme laufen auch unter
diesem Nutzer.

<item>irc: Wird von irc-Daemonen benutzt. Ein statisch zugewiesener Nutzer wird
nur wegen eines Fehlers in <prgn>ircd</prgn> benötigt, das beim Start SETUID()
auf sich selbst für eine bestimmte UID ausführt.

<item>gnats.

<item>nobody, nogroup: Daemonen die keine eigenen Dateien haben laufen als
Nutzer nobody
	und Gruppe nogroup. Demzufolge sollten keine Dateien auf dem
gesamten System diesem Nutzer oder dieser Gruppe gehören.

</list>

<p>Andere Gruppe, die keinen dazugehörigen Benutzer haben:

<list>

<item>adm: Die Gruppe adm wird zu Zwecken der Überwachung benutzt. Mitglieder
dieser
	Gruppe können viele Dateien in <file>/var/log</file> lesen
	und die xconsole benutzen.
	<file>/var/log</file> war früher einmal
	<file>/usr/adm</file> (und später <file>/var/adm</file>),
	daher der Name dieser Gruppe.

<item>tty: TTY-Geräte gehören dieser Gruppe. Die Befehle write und wall
benutzen dies, um auf die TTYs anderer Leute zu schreiben.

<item>disk:	Roh-Zugriff auf Festplatten. Größtenteils äquivalent zum
	Root-Zugriff.

<item>kmem:
	/dev/kmem und ähnliche Dateien sind von dieser Gruppe
lesbar. Dies ist größtenteils ein Relikt aus BSD. Aber jedes Programm, dass
Lese-Zugriff auf den Systemspeicher braucht, kann so SETGID kmem gemacht
werden.

<item>dialout:
	Voller und direkter Zugriff auf serielle Schnittstellen.
	Mitglieder dieser Gruppen können Modems rekonfigurieren,
	sich irgendwo einwählen, usw.

<item>dip: Der Name der Gruppe steht für »Dial-up IP«. Mitglied der Gruppe dip
zu sein erlaubt Ihnen Programme wie <prgn>ppp</prgn>, <prgn>dip</prgn>,
<prgn>wvdial</prgn> usw. zu benutzen, um eine Verbindung herzustellen. Die
Nutzer in dieser Gruppe können das Modem nicht konfigurieren. Sie können
lediglich Programme aufrufen, die es benutzen.

<item>fax:
	Erlaubt es den Mitgliedern, Fax-Software zu benutzen, um Faxe zu
	senden und zu empfangen.

<item>voice:
	Voicemail, nützlich für Systeme, die Modems als
	Anrufbeantworter benutzen.

<item>cdrom: Diese Gruppe kann dazu benutzt werden, einer bestimmen Menge von
Nutzern Zugriff auf CD-ROM-Laufwerke zu geben.

<item>floppy: Diese Gruppe kann dazu benutzt werden, einer bestimmen Menge von
Nutzern Zugriff auf Diskettenlaufwerke zu geben.

<item>tape: Diese Gruppe kann dazu benutzt werden, einer bestimmen Menge von
Nutzern Zugriff auf Bandlaufwerke zu geben.

<item>sudo: Mitglieder dieser Gruppe müssen ihr Passwort nicht eingeben, wenn
sie <prgn>sudo</prgn> benutzen. Siehe <file>/usr/share/doc/sudo/OPTIONS</file>.

<item>audio: Diese Gruppe kann dazu benutzt werden, einer bestimmen Menge von
Nutzern Zugriff auf jedes Audiogerät zu geben.

<item>src:
	Dieser Gruppe gehören die Quellcodes, einschließlich der
	Dateien in <file>/usr/src</file>. Sie kann benutzt werden, um
einem bestimmten Nutzern die Möglichkeit zu bieten, Quellcode
	des Systems zu verwalten.

<item>shadow:
	<file>/etc/shadow</file> ist von dieser Gruppe lesbar. Einige
Programme, die auf diese Datei zugreifen müssen, sind SETGID
	shadow.

<item>utmp:
	Diese Gruppe kann nach <file>/var/run/utmp</file> und
	ähnlichen Dateien schreiben. Programme, die darin schreiben
können müssen, sind SETGID utmp.

<item>video:
	Diese Gruppe kann dazu benutzt werden, einer bestimmen Menge von
Nutzern Zugriff auf ein Videogerät zu geben.

<item>staff: Erlaubt Nutzern lokale Modifikationen am System vorzunehmen
(<file>/usr/local</file>, <file>/home</file>), ohne dass sie Root-Privilegien
bräuchten. Vergleichen Sie sie mit »adm«, die sich mehr auf
Überwachung/Sicherheit bezieht.

<item>users: Während Debian-Systeme standardmäßig das System einer privaten
Nutzergruppe (jeder Nutzer hat seine eigene Gruppe) benutzen, ziehen es manche
vor, ein traditionelleres Gruppen-System zu verwenden. In diesem System ist
jeder Nutzer Mitglied dieser Gruppe.

</list>

<sect2>Ich entfernte einen Systembenutzer! Wie kann ich dies rückgängig machen?

<p>Wenn Sie einen Systembenutzer entfernt und kein Backup Ihrer
<file>password</file>- und <file>group</file>-Dateien haben, können Sie
versuchen, diesen mittels <prgn>update-passwd</prgn> (vergleichen Sie 
<manref name="update-passwd" section="8">) wiederherzustellen.

<sect2>Was ist der Unterschied zwischen den Gruppen adm und staff?

<p>Die Gruppe 'adm' besteht üblicherweise aus Administratoren. Die Rechte
dieser Gruppe erlauben es ihnen, Log-Dateien zu lesen, ohne <prgn>su</prgn>
benutzen zu müssen. Die Gruppe 'staff' ist gewöhnlich für Kundendienst- und
Junioradministratoren bestimmt und gibt ihnen die Möglichkeit, Dinge in
<file>/usr/local</file> zu erledigen und Verzeichnisse in
<file>/home</file> anzulegen.


<sect1>Warum gibt es eine neue Gruppe, wenn ich einen neuen Nutzer anlege?
(Oder warum gibt Debian jedem Nutzer eine eigene Gruppe?)

<p>Das Standardverhalten von Debian ist, dass jeder Nutzer seine eigene,
persönliche Gruppe hat. Das traditionelle UN*X-Modell weist alle Benutzer der
Gruppe <em>users</em> zu. Zusätzliche Gruppe werden erstellt, um den Zugang zu
gemeinsam genutzten Dateien, die mit verschiedenen Projektverzeichnissen
verbunden sind, einzuschränken. Die Dateiverwaltung wurde schwierig, wenn ein
einzelner Nutzer an verschiedenen Projekten arbeitete, da, wenn jemand eine
Datei erstellte, diese mit der primären Gruppe des Erstellers (z.B. 'users')
verbunden war.

<p>Das Modell von Debian löst dieses Problem, indem es jedem Nutzer seine
eigene Gruppe zuweist. So wird mit einer korrekten Umask (0002) und mit dem
SETGID-Bit für ein Projektverzeichnis den Dateien, die in diesem Verzeichnis
erstellt werden, automatisch die richtige Gruppe zugewiesen. Das erleichtert
die Arbeit von Menschen, die an verschiedenen Projekten arbeiten, da sie nicht
die Gruppe oder Umasks ändern müssen, wenn sie mit gemeinsam genutzten Dateien
arbeiten.

<p>Sie können allerdings dieses Verhalten verändern, indem Sie
<file>/etc/adduser.conf</file> modifizieren. Ändern Sie die Variable
<em>USERGROUPS</em> auf 'no' ab. Dadurch wird keine neue Gruppe erstellt, wenn
ein neuer Nutzer angelegt wird. Sie sollten auch <em>USERS_GID</em> die GID der
Gruppe zuweisen, der alle Nutzer angehören.


<sect1>Fragen über Dienste und offene Ports

<sect2>Warum werden Dienste während der Installation aktiviert?

<p>Das ist der Annäherung an das Problem, auf der einen Seite
sicherheitsbewusst und auf der anderen Seite benutzerfreundlich zu sein.
Anders als OpenBSD, das alle Dienste abschaltet, bis sie vom
Administrator aktiviert werden, aktiviert Debian GNU/Linux alle
installierten Dienste, bis sie abgeschaltet werden (siehe dazu <ref
id="disableserv">). Immerhin haben Sie den Dienst installiert, oder?

<p>Es gab viele Diskussionen auf Debian-Mailinglisten
(sowohl auf debian-devel als auch auf debian-security) darüber,
welches die bessere Vorgehensweise für eine Standardinstallation ist. Jedoch
gab es bisher (10. März 2002) keinen Konsens.


<sect2>Kann ich <prgn>inetd</prgn> entfernen?

<p><prgn>Inetd</prgn> ist nicht leicht zu entfernen, da
<package>netbase</package> von dem Paket abhängt, das es enthält
(<package>netkit-inetd</package>). Wenn Sie es entfernen wollen,
können Sie es entweder abschalten (siehe <ref id="disableserv">)
oder das Paket entfernen, indem Sie das Paket <package>equivs</package>
benutzen.


<sect2>Warum muss ich Port 111 offen haben?

<p>Port 111 ist sunrpcs Portmapper und wird standardmäßig bei der
Grundinstallationen eines Debian-Systems eingerichtet, da es keine Möglichkeit
gibt herauszubekommen, wann ein Programm eines Nutzers RPC gebrauchen könnte,
um korrekt zu arbeiten. Jedenfalls wird es meistens von
NFS benutzt. Wenn Sie kein NFS benutzen, entfernen Sie es, wie in <ref
id="rpc"> erklärt.

<p>In Versionen des Pakets <package>portmap</package> später als 5-5 können Sie
sogar den Portmapper installieren, aber ihn nur auf dem Localhost lauschen
lassen (dazu müssen Sie <file>/etc/default/portmap</file> verändern).


<sect2>Wozu ist der <prgn>identd</prgn> (Port 113) da?

<p>Der Dienst Identd ist ein Authentisierungdienst, der den Besitzer einer
bestimmten TCP/IP-Verbindung zu einem entfernten Server, der die Verbindung
annimmt, identifiziert. Wenn ein Benutzer sich mit einem entfernten Host
verbindet, schickt <prgn>inetd</prgn> auf dem entfernten Host üblicherweise
eine Anfrage an Port 113 zurück, um Informationen über den Besitzer
herauszufinden. Er wird häufig von Mail-, FTP- und IRC-Servern eingesetzt. Er
kann auch dazu verwendet werden, um einen Nutzer Ihres lokalen Systems, der ein
entferntes System angreift, aufzuspüren.

<p>Es gab ausführliche Diskussionen über die Sicherheit von <prgn>identd</prgn>
(siehe in den <url
id="http://lists.debian.org/debian-security/2001/debian-security-200108/msg00297.html"
name="Archiven der Mailingliste">. Im Allgemeinen ist <prgn>identd</prgn> auf
Multi-User-Systemen nützlicher als auch einer Workstation mit nur einem
Benutzer. Wenn Sie keine Verwendung von ihn haben, sollten Sie ihn abschalten,
damit Sie keinen Dienst für die Außenwelt offen lassen. Wenn Sie sich
entscheiden, den identd-Port mit einer Firewall zu blockieren, benutzen Sie
<em>bitte</em> die Regel 'reject' und nicht die Regel 'deny', da andernfalls
eine Verbindung zu einem Server, die <prgn>identd</prgn> verwendet, bis zu
einer Zeitüberschreitung hängen bleiben wird (lesen Sie dazu <url
id="http://logi.cc/linux/reject_or_deny.php3" name="reject or deny issues">).


<sect2>Ich habe Dienste, die die Ports 1 und 6 verwenden. Welche sind das und
wie kann ich sie entfernen?

<p>Sie führen den Befehl <tt>netstat -an</tt> aus und erhalten Folgendes:

<example>
  Active Internet connections (servers and established)
  Proto Recv-Q Send-Q Local Address           Foreign Address         State
  PID/Program name
  raw        0      0 0.0.0.0:1               0.0.0.0:*               7
  -
  raw        0      0 0.0.0.0:6               0.0.0.0:*               7
  -
</example>

<p>Sie sehen <em>nicht</em> Prozesse, die auf dem TCP/UDP-Port 1 und 6
lauschen. Tatsächlich sehen Sie einen Prozess, der auf einem
<em>Raw</em>-Socket für Protokoll 1 (ICMP) und 6 (TCP) lauscht. Ein solches
Verhalten ist für Trojaner und einige Systeme zur Eindringlingserkennung wie
<package>iplogger</package> und
<package>portsentry</package> üblich. Wenn Sie diese Pakete besitzen, löschen
Sie sie einfach. Falls nicht, versuchen Sie mit netcats Option <tt>-p</tt>
(Prozess) herauszufinden, welcher Prozess diese Lauscher betreibt.


<sect2>Ich habe festgestellt, dass ich den folgenden Port (XYZ) offen
habe. Kann ich ihn schließen?

<p>Ja, natürlich. Die Ports, die Sie offen lassen, hängen von Ihrem
individuellen Regelwerk bezüglich öffentlich zugänglicher Dienste ab. Prüfen
Sie, ob sie von <prgn>inetd</prgn> (siehe <ref id="inetd">) oder von anderen
installierten Paketen geöffnet werden, und leiten Sie passende Maßnahmen ein
(d.h. konfigurieren Sie inetd, entfernen Sie das Paket, verhindern Sie, dass
der Dienst beim Booten gestartet wird).


<sect2>Hilft das Löschen von Diensten aus <file>/etc/services</file>, um meinen
Rechner abzusichern.

<p><em>Nein</em>, <file>/etc/services</file> stellt nur eine
Verbindung zwischen virtuellem Namen und Portnummer her. Das Entfernen von
Namen aus dieser Datei verhindert (üblicherweise) nicht, dass ein Dienst
gestartet wird. Manche Daemonen starten vielleicht nicht, wenn
<file>/etc/services</file> verändert wurde, aber das ist nicht die Norm.  Um
einen Dienst richtig abzuschalten, sehen Sie sich <ref id="disableserv"> an.


<sect1>Allgemeine Sicherheitsfragen

<sect2>Ich habe mein Passwort vergessen und kann auf das System nicht
mehr zugreifen!

<p>Die nötigen Schritte, um wieder Zugriff erhalten,
hängen davon ab, ob Sie die vorgeschlagene Prozedur zum Absichern
von <prgn>lilo</prgn> und BIOS durchgeführt haben oder nicht.

<p>Wenn Sie beides eingeschränkt haben, müssen Sie im BIOS
erlauben, von anderen Medien als der Festplatte zu booten, bevor Sie
weitermachen können. Wenn Sie auch Ihr BIOS-Passwort vergessen
haben, müssen Sie Ihr BIOS zurücksetzen. Dazu öffnen Sie das PC-Gehäuse und
entfernen die BIOS-Batterie.

<p>Sobald Sie das Booten von CD-ROM oder Diskette eingeschaltet haben, sollten
Sie Folgendes ausprobieren:

<list>

<item>Booten Sie von eine Rettungsdiskette und starten den Kernel.

<item>Wechseln Sie mit Alt+F2 auf eine virtuelle Konsole.

<item>Mounten Sie die Partition, auf der sich Ihr /root befindet.

<item>Editieren Sie (auf der Rettungsdiskette von Debian 2.2 befindet sich
<prgn>ae</prgn>, Debian 3.0 enthält <prgn>nano-tiny</prgn>, der
<prgn>vi</prgn> ähnelt) die Datei <file>/etc/shadow</file> und
ändern Sie die Zeile:

<example>
  root:asdfjl290341274075:XXXX:X:XXXX:X::: (X=irgendeine Ziffer)
</example>

<p>in:

<example>
  root::XXXX:X:XXXX:X:::
</example>

</list>

<p>Dies entfernt das vergessene Root-Passwort, das sich im ersten durch
Doppelpunkte abgetrennten Feld nach dem Nutzernamen befand. Speichern Sie die
Datei ab, starten Sie das System neu und melden Sie sich als Root mit einem
leeren Passwort an. Dies wird funktionieren, außer wenn Sie Ihr System etwas
sicherer eingestellt haben, d.h. wenn Sie nicht erlauben, dass Nutzer leere
Passwörter haben, oder dass Root sich auf einer Konsole einloggen kann.

<p>Falls Sie derartige Maßnahmen getroffen haben, müssen Sie im
Single-User-Modus starten. Wenn Sie LILO eingeschränkt haben, müssen
<prgn>lilo</prgn> erneut ausführen, nachdem Sie das Root-Passwort
zurückgesetzt haben.
Das ist ziemlich verzwickt, da Ihre <file>/etc/lilo.conf</file> verändert
werden muss, da das Root-Dateisystem (/) eine RAM-Disk und keine echte
Festplatte ist.

<p>Sobald LILO nicht mehr eingeschränkt ist, versuchen Sie Folgendes:

<list>

<item>Drücken Sie Alt, Shift oder Steuerung (Control), kurz bevor das BIOS
seine Arbeit beendet hat, und Sie sollten nun einen LILO-Prompt erhalten.

<item>Geben Sie am Prompt <tt>linux single</tt>, <tt>linux init=/bin/sh</tt>
oder <tt>linux 1</tt> ein.

<item>Sie erhalten einen Shell-Prompt im Single-User-Modus (Sie
werden nach dem Passwort gefragt, aber das kennen Sie jetzt ja)

<item>Binden Sie die Root-Partition (/) im Schreib/Lese-Modus neu ein, indem
Sie den Befehl mount verwenden:
<example>
  mount -o remount,rw /
</example>

<item>Ändern Sie das Superuser-Passwort mit <prgn>passwd</prgn> (da
Sie der Superuser sind, werden Sie nicht nach dem alten Passwort
gefragt).

</list>


<sect1>Wie muss ich vorgehen, wenn ich meinen Nutzern einen Dienst anbieten
möchte, ihnen aber kein Shell-Konto geben will?
<!-- SB (20050317): Oder: "möchte, ihm aber kein Shell-Konto geben will?"-->

<p>Wenn Sie zum Beispiel einen POP-Dienst anbieten wollen,
müssen Sie nicht für jeden zugreifenden Benutzer ein Konto anlegen. Am besten
setzen Sie hierzu eine Authentifizierung, die auf Verzeichnisses basiert, durch
einen externen Dienst (wie Radius, LDAP oder eine SQL-Datenbank)
ein. Installieren Sie einfach die gewünschte
PAM-Bibliothek (<package>libpam-radius-auth</package>,
<package>libpam-ldap</package>, <package>libpam-pgsql</package> oder
<package>libpam-mysql</package>), lesen Sie die Dokumentation (Einsteiger
sehen bitte unter <ref id="auth-pam"> nach) und konfigurieren Sie den
PAM-nutzenden Dienst, so dass er Ihren Backend benutzt. Bearbeiten Sie dazu
die dem Dienst entsprechenden Dateien unter
<file>/etc/pam.d/</file> und ändern die folgenden Zeile von
<example>
  auth    required        pam_unix_auth.so shadow nullok use_first_pass
</example>
beispielsweise für ldap zu: 
<example>
  auth    required        pam_ldap.so
</example>

<!-- FIXME: check if this i right (jfs) -->

<p>Im Fall von LDAP-Verzeichnissen liefern manche Dienste LDAP-Schemata
mit, die Sie Ihrem Verzeichnis hinzufügen können, um
eine LDAP-Authentifizierung zu benutzen. Wenn Sie relationale
Datenbanken benutzen, gibt es einen nützlichen Trick: Benutzen Sie
die Klausel <em>where</em>, wenn Sie die PAM-Module konfigurieren. Wenn
Sie beispielsweise eine Datenbank mit der folgenden Tabelle haben:

<example>
  (user_id,user_name,realname,shell,password,uid,gid,homedir,sys,pop,imap,ftp)
</example>

<p>Wenn Sie die Attribute der Dienste zu Boolean-Feldern machen, können Sie sie
verwenden, um den Zugang zu den verschiedenen Diensten zu erlauben oder zu
verbieten. Sie müssen dazu nur die geeigneten Zeilen in folgende Dateien
einfügen:

<list>

<item><file>/etc/pam.d/imap</file>:<tt>where=imap=1</tt>.

<item><file>/etc/pam.d/qpopper</file>:<tt>where=pop=1</tt>.

<item><file>/etc/nss-mysql*.conf</file>:<tt>users.where_clause = user.sys = 1;</tt>.

<item><file>/etc/proftpd.conf</file>:<tt> SQLWhereClause "ftp=1"
</tt>.

</list>


<sect id="vulnerable-system">Mein System ist angreifbar! (Sind Sie sich
sicher?)

<sect1 id="vulnasses-false-positive">Der Scanner X zur Einschätzung der
Verwundbarkeit sagt, dass mein Debian-System verwundbar wäre?

<p>Viele Scanner zur Einschätzung der Verwundbarkeit liefern falsche
Positivmeldungen, wenn sie auf Debian-Systemen verwendet werden. Das liegt
daran, dass sie nur die Version eines Softwarepakets überprüfen, um
herauszufinden, ob es verwundbar ist. Sie prüfen nicht, ob tatsächlich eine
Sicherheitslücke vorhanden ist. Da Debian nicht die Version einer Software
ändert, wenn ein Paket repariert wird (häufig werden Ausbesserungen an neueren
Veröffentlichungen zurückportiert), neigen einige Werkzeuge dazu zu denken,
dass ein aktualisiertes Debian-System verwundbar ist, auch wenn das nicht der
Fall ist.

<p>Wenn Sie denken, dass Ihr System auf dem aktuellen Stand der
Sicherheitsaktualisierungen ist, sollten Sie die Querverweise zu den
Datenbanken mit Sicherheitslücken, in denen die DSAs veröffentlicht sind
(vergleichen Sie dazu <ref id="dsa">), verwenden, um falsche Positive
auszusondern, wenn das Programm, das Sie verwenden, CVE-Referenzen enthält.


<sect1>Ich habe in meinen Logfiles einen Angriff gesehen: Ist mein System
kompromittiert?

<p>Ein Hinweis auf einen Angriff heißt nicht notwendigerweise,
dass Ihr System gehackt wurde. Leiten Sie die üblichen Schritte
ein, um festzustellen, ob das System kompromittiert wurde (siehe <ref
id="after-compromise">). Selbst wenn Ihr System hinsichtlich des
protokollierten Angriffs nicht verwundbar ist, könnte ein entschlossener
Angreifer neben der von Ihnen entdeckten Sicherheitslücke auch eine andere
ausgenutzt haben.

<!-- Angriffsspuren, die "manchmal" auf Verwundbarkeiten hinweisen? -->
<!-- Irgendwie eine Trivialität --> 


<sect1>Ich habe in meinen Logs merkwürdige »MARK«-Einträge
gefunden. Wurde ich gehackt?

<p>Sie können die folgenden Zeilen in Ihren System-Logs finden:

<example>
  Dec 30 07:33:36 debian -- MARK --
  Dec 30 07:53:36 debian -- MARK --
  Dec 30 08:13:36 debian -- MARK --
</example>

<p>Dies stellt keinen Hinweis auf eine Kompromittierung dar, obwohl Nutzer, die
von einer Debian-Release wechseln, es vielleicht merkwürdig finden. Wenn Ihr
System keine große Last (oder nicht viele aktive Dienste) hat, können diese
Zeilen in alle Logs auftauchen. Dies ist ein Hinweis, dass Ihr
<prgn>syslogd</prgn>-Daemon richtig läuft. Aus <manref
section="8" name="syslogd">:

<example>
       -m interval
              Der Syslogd protokolliert regelmäßig einen
              Zeitstempel. Der voreingestellte Abstand zwischen zwei --
              MARK -- Zeilen ist 20 Minuten. Er kann mit dieser Option
              geändert werden. Setzen Sie den Abstand auf Null, um
              die Zeitstempel komplett abzuschalten.
</example>


<sect1>Ich habe Nutzer gefunden, die laut meinen Logfiles 'su' benutzen: Bin
ich kompromittiert?

<p>Sie könnten in Ihren Logdateien Zeilen wie die folgenden finden:

<example>
  Apr  1 09:25:01 server su[30315]: + ??? root-nobody
  Apr  1 09:25:01 server PAM_unix[30315]: (su) session opened for user nobody by (uid=0)
</example>

<p>Seien Sie nicht zu besorgt. Prüfen Sie, ob dies durch einen
<prgn>Cron</prgn>-Job hervorgerufen wird (normalerweise
<file>/etc/cron.daily/find</file> oder
<prgn>logrotate</prgn>):

<example>
  $ grep 25 /etc/crontab
  25 9    * * *   root    test -e /usr/sbin/anacron || run-parts --report
  /etc/cron.daily
  $ grep nobody /etc/cron.daily/*
  find:cd / && updatedb --localuser=nobody 2>/dev/null
</example>


<sect1>Ich habe 'possible SYN flooding' in meinen Logs entdeckt: Werde ich
angegriffen?

<p>Sie sehen Einträge wie diese in Ihren Logs:

<example>
  May 1 12:35:25 linux kernel: possible SYN flooding on port X. Sending cookies.
  May 1 12:36:25 linux kernel: possible SYN flooding on port X. Sending cookies.
  May 1 12:37:25 linux kernel: possible SYN flooding on port X. Sending cookies.
  May 1 13:43:11 linux kernel: possible SYN flooding on port X. Sending cookies.
</example>

<p>Überprüfen Sie mit <prgn>netstat</prgn>, ob es eine große Anzahl von
Verbindungen zum Server gibt. Zum Beispiel:

<example>
  linux:~# netstat -ant | grep SYN_RECV | wc -l
     9000
</example>

<p>Dies ist ein Anzeichen, dass ein Denial-of-Service-Angriff (DoS) auf den
Port X Ihres Systems (am wahrscheinlichsten gegen einen öffentlichen Dienst wie
Ihr Web- oder Mailserver). Sie sollten TCP-Syncookies in Ihrem Kernel
einschalten, siehe <ref id="tcp-syncookies">. Beachten Sie, dass ein
DoS-Angriff Ihr Netzwerk überfluten kann, auch wenn Sie verhindern können, dass
er Ihr System zum Absturz bringt.
<footnote>
Da keine Datei-Deskriptoren mehr vorhanden sind, könnte das System nicht mehr
antworten, bis das Zeitlimit der TCP-Verbindungen überschritten wurde.
</footnote>
Der einzige effektive Weg, diesen Angriff abzuwehren, ist, mit Ihrem
Netzprovider in Verbindung zu treten.


<sect1>Ich habe seltsame Root-Sessions in meinen Logs entdeckt: Wurde ich
gehackt?

<p>Sie sehen folgende Art von Einträgen in der Datei
<file>/var/log/auth.log</file>:

<example>
  May 2 11:55:02 linux PAM_unix[1477]: (cron) session closed for user root
  May 2 11:55:02 linux PAM_unix[1476]: (cron) session closed for user root
  May 2 12:00:01 linux PAM_unix[1536]: (cron) session opened for user root by
  (UID=0)
  May 2 12:00:02 linux PAM_unix[1536]: (cron) session closed for user root
</example>

<p>Sie kommen von einem ausgeführten <prgn>Cron</prgn>-Job (in unserem Beispiel
alle fünf Minuten). Um herauszufinden, welches Programm für diese Jobs
verantwortlich ist, überprüfen Sie die Einträge in <file>/etc/crontab</file>,
<file>/etc/cron.d</file>, <file>/etc/crond.daily</file> und Roots
<file>crontab</file> in <file>/var/spool/cron/crontabs</file>.


<sect1>Ich bin Opfer eines Einbruchs, was soll ich jetzt tun?

<p>Es gibt mehrere Schritte, die Sie bei einem Einbruch durchführen sollten:

<list>

<item>Prüfen Sie, ob Ihr System auf dem aktuellen Stand der
Sicherheitsaktualisierungen für veröffentlichte Verwundbarkeiten ist. Wenn Ihr
System verwundbar ist, hat die die Möglichkeit, dass Ihr System tatsächlich
gehackt wurde, erhöht. Die Wahrscheinlichkeit steigt weiter an, wenn die
Sicherheitslücke schon eine Zeit lang bekannt ist, da üblicherweise mehr
Tätigkeit mit älteren Verwundbarkeiten besteht. Hier ist ein Link zu <url
id="http://www.sans.org/top20/" name="SANS Top 20 Security Vulnerabilities">.

<item>Lesen Sie dieses Dokument, besonders den Abschnitt <ref
id="after-compromise">.

<item>Fragen Sie nach Hilfe. Sie können die Mailingliste debian-security
benutzen und um Rat fragen, wie Sie Ihr System wiederherstellen oder patchen.

<item>Benachrichtigen Sie Ihren lokalen <url id="http://www.cert.org"
name="CERT"> (wenn einer existiert, ansonsten sollten Sie sich vielleicht
direkt mit CERT in Verbindung setzen). Das könnte Ihnen helfen (vielleicht aber
auch nicht), aber wenigstens wird CERT über laufende Angriffe informiert. Diese
Information ist sehr wertvoll, um herauszufinden, welche Werkzeuge und
Angriffsarten von der <em>Blackhat</em>-Community verwendet werden.

</list>


<sect1>Wie verfolge ich einen Angriff zurück?

<p>Sie können einen Angriff zu seinem Ursprung zurückverfolgen, indem Sie die
Logs (wenn sie nicht geändert wurden) mit Hilfe eines Systems zur
Eindringlingserkennung (siehe <ref id="intrusion-detect">),
<prgn>traceroute</prgn>, <prgn>whois</prgn> oder ähnlicher Werkzeuge
(einschließlich forensischer Analyse) durchsehen. Wie Sie auf diese
Informationen reagieren und was <em>Sie</em> als Angriff betrachten, hängt
ausschließlich von Ihren Sicherheitsrichtlinien ab. Ist
ein einfacher Scan ein Angriff? Ist die Prüfung auf eine
Verwundbarkeit ein Angriff?


<sect1>Das Programm X in Debian ist angreifbar &ndash; was soll ich tun?

<p>Nehmen Sie sich zuerst einen Augenblick Zeit, um zu schauen, ob die
Sicherheitslücke in öffentlichen Sicherheitsmailinglisten (wie Bugtraq) oder
anderen Foren bekannt gemacht wurde. Das Sicherheitsteam von Debian ist
hinsichtlich dieser Listen auf dem Laufenden, daher könnte ihm dieses Problem
bereits bekannt sein.  Leiten Sie keine weiteren Maßnahmen ein, wenn Sie schon
eine Bekanntmachung auf <url id="http://security.debian.org"> sehen.

<p>Wenn anscheinend keine Informationen veröffentlicht wurden, schicken Sie
bitte eine E-Mail zu den betroffenen Paketen mit einer detaillierten
Beschreibung der Verwundbarkeit (Code, der dies bestätigt, ist auch in Ordnung)
an <url id="mailto:team@security.debian.org"
name="team@security.debian.org">. Dort erreichen Sie das Sicherheitsteam von
Debian.


<sect1 id="version-backport">Laut der Versionsnummer eines Paketes läuft bei mir
immer noch eine angreifbare Version!

<p>Statt auf neue Veröffentlichung zu aktualisieren, portiert Debian
sicherheitsrelevante Korrekturen zu der Version zurück, die in der
Stable-Veröffentlichung enthalten ist. Der Grund dafür ist, dass sicher
gegangen werden soll, dass die Stable-Veröffentlichung so wenig wie möglich
verändert wird. Damit wird verhindert, dass sich Dinge als Folge einer
Sicherheitskorrektur unerwartet ändern oder kaputt gehen. Ob Sie eine sichere
Version eines Paketes benutzen, stellen Sie fest, indem Sie das Changelog des
Paketes durchsehen, oder indem Sie die exakte Versionsnummer (ursprüngliche
Version -slash- Debian-Release) mit der Nummer aus der
Debian-Sicherheits-Ankündigung (DSA) vergleichen.


<sect1>Spezielle Software

<sect2><package>Proftpd</package> ist für einen Denial-of-Service-Angriff
anfällig.

<p>Fügen Sie Ihrer Konfigurationsdatei <tt>DenyFilter \*.*/</tt>
hinzu. Mehr Informationen entnehmen Sie <url id="http://www.proftpd.org/bugs.html">.


<sect2>Nach der Installation von <package>portsentry</package> sind viele Ports
offen.

<p>Dies ist nur die Art und Weise, wie <prgn>portsentry</prgn> arbeitet. Es
öffnet etwas zwanzig ungenutzte Ports und versucht so, Port-Scans zu entdecken.


<sect id="debian-sec-team-faq">Fragen zum Sicherheitsteam von Debian

<p>Diese Informationen stammen aus dem <url
id="http://www.de.debian.org/security/faq" name="Debian Sicherheits-FAQ">.
