######################################################################### # The Honeywall Bootable CD-ROM # # by # # The Honeynet Project and the Research Alliance # ######################################################################### Honeywall CD-ROM Interna ======================== Letzte Änderung: $Date: 3. Oktober 2005 Zweck ----- Der Zweck dieses Dokumentes ist es, einige Grundlagen des Aufbaus der Roo Honeywall zu erläutern. Dies ist eine Hilfestellung für diejenigen, die ihre Honeywall anpassen oder für sie programmieren wollen und soll einige Befehle und zu diesem Zweck verfügbare APIs vorstellen. Startvorgang ------------ Roo nutzt den System V Release 4 (SVR4) rc Startup-Mechanismus. Einen Überblick über diesen Prozess kann man hier finden. Red Hat und Fedora Linux nutzen ein erweitertes SVR4-Modell, das in das "chkconfig" Kommando integriert ist. Dieses dient dazu, Links in den /etc/rc?.d Verzeichnissen zu verwalten, die auf Skripte in den /etc/rc.d/init.d Verzeichnissen verweisen. (Siehe auch "man chkconfig") Neues in den Startprozess einfügen ---------------------------------- Um ein Skript in den Startprozess einzufügen, müssen Sie zuerst feststellen, welche Abhängigkeiten von anderen Skripten bestehen, damit diese ggf. zuerst gestartet werden. Nehmen wir an der daemon braucht das Netzwerk, dann muß seine Nummer höher sein als der S-Link zum Netzwerkskript (/etc/rc3.d/S10network). Das "chkconfig"-Programm erstellt diese Links mit den korrekten Nummern basierend auf einem Kommentar im Header des Skripts. Hier sehen Sie die ersten Zeilen aus /etc/rc.d/init.d/network um dies zu demonstrieren: #! /bin/bash # # network Bring up/down networking # # chkconfig: 2345 10 90 # description: Activates/Deactivates all network interfaces configured to \ # start at boot time. # Die Zahlen nach dem "chkconfig:" zeigen an, das das Netzwerk in den Runleveln 2, 3, 4 und 5 gestartet werden soll, eine Startsequenznummer (S) von 10 und eine Killsequenznummer (K) von 90 haben soll. Das Skript sollte das "daemon" Kommando nutzen, wie es in /etc/init.d/functions definiert wird. Binden Sie diese Datei ganz am Anfang des Skripts wie folgt ein: . /etc/init.d/functions Ein Beispiel, wie man diesen Befehl nutzt, um crond zu starten, findet man im /etc/init.d/crond Skript: start() { echo -n $"Starting $prog: " daemon crond RETVAL=$? echo [ $RETVAL -eq 0 ] && touch /var/lock/subsys/crond return $RETVAL } Um Logdateien und temporäre Dateien an einem Ort zusammen zu fassen und um Honeywall-Dateien von daemon-Dateien des Betriebssystems zu trennen, stellen Sie sicher, das die daemons ihre temporären Dateien mit Hilfe der hw_mktemp Funktion erstellen und nutzen Sie statt des hartkodierten /var/log die $LOGDIR Variable um das Basisverzeichnis für die Logdateien festzulegen. Hier ein Beispiel für monit: STATEFILE="$(hw_mktemp monit)" LOGFILE="$LOGDIR/monitlog" OPTIONS="-s $STATEFILE -l $LOGFILE" start() { echo -n "Starting monit..." daemon $monit $OPTIONS RETVAL=$? echo if [ $RETVAL = 0 ] ; then touch /var/lock/subsys/monit else RETVAL=1 fi return $RETVAL } Festplattenidentifizierung und -mounting ---------------------------------------- Da wir den "LiveCD"-Modus des Roo Vorgängers eeyore aufgegeben haben, wird angenommen, das die Festplatte während der Erstinstallation durch kickstart partitioniert und formatiert wird. Dadurch wird der Festplatte eine spezifische Partitionierung mit einer großen Root- und einer Swappartition zugewiesen. Das Standardverzeichnis für die Honeywall-Dateien ist /hw, das in der / Partition des primären Laufwerks liegen sollte. Menü ==== Konfigurationssubsystem und Konfigurationsdatei ----------------------------------------------- Die Honeywall legt Dateien an, in denen sie sich Einstellungen merkt, wie z.B. die Werte von Variablen, die von Startup-Skripten zur Konfiguration von Firewallregeln genutzt werden, Einstellungen zur Datensammlung und -kontrolle, Erlaubt/Verboten-Listen zur Zugriffs- und Protokollkontrolle damit sich die Honeywall in eine Produktivumgebung einfügen kann. Standardmäßig liegen alle diese Dateien in einem Verzeichnis namens /hw/conf. Alle Skripte, die diese Variablen zum ordnungsgemäßen Funktionieren brauchen, müssen einen Kommandozeilenbefehl oder ein API nutzen, um auf diese Variablen zuzugreifen und/oder sie zu verändern. Dadurch wird sichergestellt, das die Änderungen beim nächsten Neustart erhalten bleiben und so die Stabilität und Funktion der Honeywall auch nach Neustarts gegeben ist. Das Kommandozeilentool zur Änderung von Variablen heißt "hwctl". Das Bash-Shell API ist /etc/rc.d/init.d/hwfuncs.sub. Beide werden in der Folge noch eingehender beschrieben. Dateien ======= /etc/honeywall.conf ------------------- Diese Datei ist eine "Export-Datei". Sie wird genutzt, um Werte von Variablen in lesbarer Form zu speichern und kann dazu genutzt werden um Grundwerte zu setzen, eine große Zahl von Variablen mit neuen Werten zu versehen oder Werte für die spätere Verwendung zwischenzuspeichern. Eine Version dieser Datei ist standardmäßig im ISO der Distribution dabei, kann aber vom Benutzer ersetzt werden um z.B. Anpassungen an die eigene Umgebung vorzunehmen. Die Datei wird nicht direkt von Skripten ausgewertet. Diese sollten auf die Werte in den Dateien im Verzeichnis /hw/conf zurückgreifen. Die bevorzugte Methode auf diese Variablen zuzugreifen ist die Verwendung der hw_get und hw_set Funktionen aus hwfuncs.sub oder der Befehl "hwctl". Die Eingabe von "hwctl --help" (ohne nführungszeichen) liefert mehr Informationen über das Programm. /etc/snort ---------- Dieses Verzeichnis enthält alle Konfigurationsinformationen und Regeln für snort. /etc/snort_inline ----------------- Dieses Verzeichnis enthält alle Konfigurationsinformationen und Regeln für snort_inline. /etc/rc.d/init.d/hwfuncs.sub ---------------------------- Alle Shellfunktionen einschließlich der low-level Funktionen, die in der Honeywall verwendet werden. Diese Datei stellt das primäre BASH-Shell API bereit. /etc/init.d/driveinit.sh ------------------------ Mechanismus zum mounten von Festplatten /etc/rc.d/init.d/ (a.k.a. /etc/init.d) -------------------------------------- Enthält Skripte die die Honeywall initialisieren. Diese Skripte können auch verwendet werden, um einzelne Dienste zu stoppen, starten oder neuzustarten. Diese Dienste beinhalten: bridge.sh, monit.sh, hflowd, hflow-mysqld, hflow-p0f, hflow-pcap, hflow-snort, hflow-snort_inline, hwdaemons, hwnetwork, rc.firewall, and walleye-httpd. /hw/conf -------- In diesem Verzeichnis speichert die Honeywall die Werte aller Variablen. Dieses Verzeichnis ist ähnlich (nicht gleich) wie das /proc Dateisystem. Der bevorzugte Weg auf die hier hinterlegten Dateien zuzugreifen ist entweder die Verwendung von "hwctl" oder die API Funktionen aus hwfuncs.sub /hw/var/log/honeywall --------------------- Diese Datei wird für speziell von der Honeywall kommende syslog Nachrichten verwendet. Daemons, die gestoppt oder gestartet werden, tragen sich hier ein und auch die meisten Fehlermeldungen aus dem Menü oder der Walleye-Bedienoberfläche werden (hoffentlich) hier aufgezeichnet. Da die Bedienoberfläche den Bildschirm sehr schnell neu aufbaut, sind Fehlermeldungen oft gar nicht zu sehen. Skripte können (und sollten!) die "hw_log" Funktion verwenden. /hw/* ----- Es existieren noch andere Verzeichnisse unterhalb von /hw, die in kommenden Versionen alle zur Honeywall gehörenden Protokolle und Dateien aufnehmen sollen. Diese zentrale Speicherung erlaubt eine einfache Datensicherung und -wiederherstellung, erleichtert die Optimierung des Dateisystems und andere Maßnahmen zur Verbesserung der Performance. /var/log/messages ----------------- Diese Datei speichert alle System- und Firewallprotokolle, sowie alle ein- und ausgehenden Verbindungen. Beachten Sie, das die meisten Fehlermeldungen im Zusammenhang mit der Honeywall in /hw/var/log/honeywall zu finden sind. In einer späteren Version werden Firewall- und Verbindungsprotokolle etc. ebenfalls nach /hw/var/log/ verschoben. /var/log/iptables ----------------- Diese Datei dient dazu, die von iptables aufgezeichneten Verbindungsprotokolle von den normalen Systemprotokollen zu trennen. Der Prozess der Trennung der Honeywall Protokolle von den normalen Systemprotokollen ist noch nicht vollständig. Darüberhinaus nutzt iptables zur Protokollierung Kernelmechanismen und debug level. Der Kernel selber gibt auch debug Informationen aus, die zusammen mit den iptables Protokollen gespeichert werden. Iptables sollte eigentlich andere Mechanismen zur Protokollollierung verwenden (z.B. local0) um die Protokolleinträge sauber zu trennen. /var/log/snort -------------- Hier werden alle snort/snort_inline Protokolle und Alarme gespeichert. Für jeden Tag wird ein neues Unterverzeichnis angelegt. Programmierhinweise und Tips ============================ Verwendung von Variablen ------------------------ Variablen, in denen eine Einstellung der Honeywall gespeichert wird, werden in einem /proc-ähnlichen Bereich abgelegt. Standardmäßig ist hier /hw/conf vorgegeben. Ihre Namen beginnen mit "hw", damit sie von anderen System- und Umgebungsvariablen leicht zu unterscheiden sind und um Probleme mit gleichen Variablennamen zu vermeiden. Alle anderen Variablen, die keine Honeywalleinstellungen definieren, sollten nicht mit dem Präfix „hw“ beginnen. Damit soll Verwechselungen vorgebeugt werden. Die Dateien, die diese Variablen enthalten, können direkt mit "echo" oder "cat" earbeitet werden. Die bevorzugte Art, sie zu bearbeiten sind aber die API oder Hilfsprogramme. Die am meisten verwendete API für BASH-Skripte ist die /etc/rc.d/init.d/hwfuncs.sub. Beachten Sie, das der Verzeichnisort sich ändern kann, damit er von den normalen SVR4 getrennt ist. Die normalen Skripte liegen in /etc/rc.d/init.d. Um die Funktionen in ihrem Skript zu definieren, fügen Sie ziemlich am Anfang ihres Skriptes folgende Zeile ein: . /etc/rc.d/init.d/hwfuncs.sub Um aus allen aktuellen Honeywallvariablen in /hw/conf Umgebungsvariablen zu machen nutzen Sie folgenden Befehl hw_setvars Diese Funktion erlaubt es einem Skript, sofortigen Zugriff auf alle Variableninhalte zu bekommen, um damit z.B. daemons zu starten, den Staus von Einstellungen anzuzeigen, die Standardwerte für Variablen für einen Reset auszulesen etc. Es tut nichts weiter, außer das es die Umgebungsvariablen setzt. Es gibt noch zwei weitere Funktionen, für direkteren Lese- und Schreibzugriff auf Variablen in /hw/conf. Diese Funktionen sind hw_get und hw_set. Man kann sie z.B. wie folgt verwenden: host=$(hw_get HwHOSTNAME) # Hostname festlegen hw_set HwMANAGER "192.168.0.1 10.10.10.0/24" # Manager IPs setzen. Wann sollten Honeywall-Variablen genutzt werden? ------------------------------------------------ Sie sollten keine hw* Variablen für Dinge verwenden, die unbedingt auf die Existenz von etwas anderem angewiesen sind (z.B. eine Datenbank). Es handelt sich hierbei nämlich eigentlich um Konstanten und eine Existenzprüfung (also eine Funktion aus hwfuncs.sub wie hw_isconfigured) sollte der Verwendung einer Konfigurationsvariable vorgezogen werden. Wenn der Benutzer keine Möglichkeit hat, diese Variable zu ändern und, im Falle das er es doch macht, das System in einen inkonsistenten Zustand versetzen kann, wird von der Verwendung einer Honeywall hw* Variable abgeraten. Honeywall Programmierer sollten sich an Dave Dittrich wenden, wenn sie glauben, eine Variable sollte zu /hw/conf hinzugefügt werden. Das Ändern von Variablenwerten kann den Neustart bestimmter Subsysteme notwendig machen um z.B. iptables Einstellungen korrekt zu übernehmen, daemons korrekt zu konfigurieren etc. Dies wird durch die Verwendung von "make" und einem Makefile (/hw/Makefile.hwctl) sichergestellt. Dieses spezielle Makefile stellt eine Verbindung zwischen den PID-Dateien und den Variablendateien in /hw/conf her, damit der richtige daemon oder die richtigen daemons neu gestartet werden, falls ein Wert, auf denen sie basieren, sich geändert hat. Es gibt Optionen für das Kommandozeilentool "hwctl" ("-r", "-R" und "-s"), die es erlauben einen oder mehrere Variablenwerte zu ändern und anschließend die zugehörigen Dienste automatisch (neu) zu starten. "hwctl" legt auch automatisch Kopien der Datei /etc/honeywall.conf an. Zur Unterscheidung der einzelnen Versionen wird .0 bis .9 angehängt. hwctl Kommandozeilentool ------------------------ Der folgende Text ist die Ausgabe, die man bekommt, wenn man hwctl -h eingibt usage: hwctl [-n] [-e] variable ... hwctl [-n] [-e] [-q] [-r|-R|-s] variable=value ... hwctl [-n] [-e] [-q] [-r|-R|-s] -p hwctl [-n] [-e] -a hwctl [-n] [-e] -A hwctl {--help|-h|-V|--version} Revision 1.2 BESCHREIBUNG ------------ hwctl wird benutzt, um Parameter der Honeywall zur Laufzeit zu setzen oder zu ändern. Die Funktion ähnelt der von sysctl(8) für procfs, ist aber nicht exakt die gleiche. Man kann das Programm verwenden, um einzelne Variablen anzuzeigen oder zu ändern oder einen Satz Variablen damit bearbeiten, indem man mehr als eine als Argument des Befehls angibt. Die Anwesenheit eines Gleichheitszeichens im Argument (z.B. HwFOO=foo) weist der Variable den Wert zu, andernfalls wird nur der aktuelle Wert angezeigt. PARAMETER --------- Variable Name eines Wertes, der gelesen werden soll. Ein Beispiel ist HwHOSTNAME. Als Trennzeichen wird anstelle eines '.' auch ein '/' akzeptiert. Variable=Wert Um einen Wert zuzuweisen wird die Form Variable=Wert verwendet, wobei Variable der Variablenname ist und Wert der Wert, der zugewiesen wird. Enthält der Wert durch die Shell ausführbaren Code müssen sie ihn evtl. durch doppelte Anführungszeichen maskieren. -r Diese Option startet Dienste, die die gerade geänderten Werte nutzen, neu (das Feature ist noch nicht vollständig implementiert). -R Erzwingt einen vollständigen Stop/Start aller Dienste vor/nach dem Ändern einer Variable -s Nutzen Sie besser "start" als "restart" (-r, s.o.) als Argument wenn Sie rc-Dateien aufrufen. Diese Option ist in Verbindung mit -p nützlich, wenn Variablen mit ihren Ursprungswerten gesetzt werden sollen -n Diese Option unterdrückt die Ausgabe des Variablennamens, wenn die Werte ausgegeben werden -N Diese Option gibt nur die Variablennamen aus. Sie kann bei Shells mit einer programmierbaren Vervollständigung nützlich sein. -e Diese Option ignoriert Fehlermeldungen über unbekannte Variablennamen -q Diese Option unterdrückt die Ausgabe von Werten die auf stdout gesetzt sind -f Lädt die Werte für die Einstellungen der Honeywall aus einer angegebenen Datei. Wird keine angegeben, so wird /etc/honeywall.conf genommen. Die gleiche Funktion bietet auch "loadvars" -p Alias für -f für alle diejenigen, die besonders auf sysctl-Kompatibilität stehen -a Zeigt alle aktuell verfügbaren Werte an -h oder –help Zeigt diesen Hilfetext an -V Gibt nur die Versionsnummer ausführbar Beispiele --------- hwctl -a hwctl -n HwHOSTNAME hwctl -r HwTCPRATE=20 HwUDPRATE=10 HwICMPRATE=30 HwOTHERRATE=10 hwctl -R -p /etc/honeywall.conf Dateien ------- /hw/conf/* /etc/honeywall.conf Sie sollten sich im Zweifelsfall immer mit Hilfe von "hwctl -h" den aktuellen Hilfetext anzeigen lassen, da dieses Dokument nicht unbedingt aktualisiert wird, wenn sich im Programmcode etwas ändert. hwfuncs.sub API Funktionen -------------------------- Andere Funktionen, die in Skripten nützlich sein können sind u.a. hw_isconfigured Gibt 0 zurück, wenn die Honeywall noch nicht konfiguriert ist, sonst eine 1 hw_get var Gibt den Wert der Variable "var" zurück, oder einen Nullstring, wenn sie nicht gesetzt ist hw_set var val Setzt die Variable "var" auf den Wert "val". (Schließen Sie "val" in Anführungszeichen, wenn der Wert Leerzeichen enthält) hw_mktemp [name] Erzeugt einen einmaligen Dateinamen für eine temporäre Datei, basierend auf [name]. Mehr dazu in den manpages (man maketemp) hw_getver Gibt den Wert von VERSION zurück (version major/minor//release identifiers) hw_getlogdir Gibt den Wert von LOGDIR zurück, der Speicherort für die Honeywall Protokolldateien) hw_getconfdir Gibt den Wert für CONFDIR zurück, den Speicherort für die Honeywall Konfigurationsvariablen hw_gethwdir Gibt den Wert für HWDIR zurück, das oberste Verzeichnis mit allen zur Honeywall gehörenden Dateien hw_sethostname name Legt den Hostnamen fest und sorgt dafür, das /etc/hosts und HwHOSTNAME synchron sind hw_backtitle Titelstring für Dialogmenüs, der die hw_getver() Resultate beinhaltet. hw_log severity text Verwenden Sie "logger" um Nachrichten in der Datei /hw/var/log/honeywall aufzuzeichnen. Lesen Sie die manpages für syslog für die verschiedenen Level (z.B. info, warn, err, etc.) hw_build_ssh_config Stellt die SSH Konfigurationsdatei wieder her, in sie mit den aktuellen Werten neu geschrieben wird Die für die Verwendung in rc Startskripten wichtigste Funktion ist die Überprüfung, ob die Honeywall bereits konfiguriert ist oder nicht. Eine solche Prüfung kann man entweder machen indem man das Vorhandensein von benötigten Variablen mit Hilfe von hw_get prüft oder indem man etwas wie das folgende macht: if [ $(hw_isconfigured) -eq 1 ]; then # Go ahead and start things up else # We are not configured. # Tell the user, or just "exit 1" here. fi Für andere Funktionen schauen Sie sich "/etc/rc.d/init.d/hwfuncs.sub" an. Verwendung von absoluten Pfaden ------------------------------- Die Verwendung von absoluten Pfaden zu Sachen wie Protokolldateien oder dem Konfigurationsverzeichnis sollte in Skripten tunlichst vermieden werden. In Skripten hartkodierte Werte erschweren es ungemein, Dinge wie den Speicherort von Protokolldateien oder den Platz der zur Honeywall gehörenden Dateien innerhalb des Dateisystems zu ändern. E gibt viele Gründe, warum es sinnvoll wäre dieses zu tun, unter anderem (aber nicht ausschließlich): * Optimierung der i-node Tablegrößen, Blockgrößen etc. zur Leistungssteigerung * Um eine "LiveCD" zu erstellen, bei der das System von einem Wechselmedium startet und das Root-Dateisystem in einer Ramdisk anlegt * Um Nutzen aus RAID oder logischen Volumes ziehen zu können * Um es zu ermöglichen, Honeywall-Skripte unabhängig zu Testzwecken oder zur Fernkonfiguration zu verwenden Die Verwendung von hartkodierten Variablenwerten in Skripten gilt allgemein als schlechter Programmierstil, da man im Falle einer Änderung von etwas so einfachem wie einer Pfadangabe in Dutzenden von Dateien die entsprechenden Werte finden und ersetzen müßte. Statt dessen ist es besser, eine der globalen Variablen HWDIR, CONFDIR und LOGDIR zu verwenden oder auf die entsprechenden Funktionen hw_gethwdir(), hw_getconfdir(), oder hw_getlogdir() zurückzugreifen. In Zukunft werden wir ein API haben, das die o.g. Funktionen in Perl, Python und C bereitstellt. Ein Beispiel, wie man ein API mit Hilfe einer Sub-Shell zusammen"hackt" findet sich im Quellcode des Perlskripts "hwctl". Die Funktionen, die Honeywall- Variablen auslesen oder setzen (aus „hwctl“) sehen so aus: sub hwgetvar { my($var) = @_; my($result) = ""; chop($result = `. /etc/rc.d/init.d/hwfuncs.sub; echo \$$var; exit 0`); $result; } sub hwsetvar { my($var, $val) = @_; `. /etc/rc.d/init.d/hwfuncs.sub; hw_set \"$var\" \"$val\"; exit 0`; } Diese Funktionen können dann in einem Perlskript z.B. so verwendet werden: my $dir = &hwgetvar("CONFDIR"); &hwsetvar("HwUDPRATE","10"); Wenn wir erstmal ein echtes Perl-API haben wird die Ausführung in einer Shell unnötig. Diese Provisorien reichen aber bis dahin erstmal aus. Wenn jemand beim Schreiben der Codes helfen möchte, kann er oder sie sich an Dave Dittrich wenden (dittrich@u.washington.edu). Zusammenhänge zwischen Variablen und Diensten --------------------------------------------- Jedes beliebige zur Honeywall gehörende rc-Skript kann eine oder mehrere Variablen aus dem /hw/conf Verzeichnis nutzen. Ändert sich ein Wert, wird der Zeitstempel mit geändert um anzuzeigen, an festzuhalten, wann die Änderung erfolgte. Die rc-Datei für daemons erzeugt PID-Dateien, die die Prozess-ID (PID) des laufenden daemons enthalten. Ändert sich eine Variable, die ein daemon nutzt, so muß dieser daemon neu gestartet werden. Dies ist dieselbe Art von Zusammenhang wie zwischen .c und .o Dateien, so daß wir wir auf den Zeitvergleich und die Beziehungslogik von "make" zurückgreifen können, wenn wir herausfinden wollen, welche daemons neu gestartet werden müssen oder welche Programme neu aufgerufen werden müssen, damit sie Dateien neu anlegen, die auf Honeywall-Variablen zurückgreifen. Einige Sachen, wie das rc.firewall oder das bridge.sh Skript, haben keinen daemon mit einer PID, so daß eine „künstliche“ PID-Datei erstellt werden muß. Einzelheiten darüber, wie und wann sie erstellt wird finden Sie in /etc/init.d/rc.firewall oder /etc/init.d/bridge.sh. Die Beziehung zwischen zwei Diensten (bridge.sh und hflowd) und /etc/resolv.conf werden hier gezeigt. Vorangestellt werden die Variablen, die in den Regeln genutzt werden (mehr Informationen darüber, wie makefiles funktionieren, findet man im GNU MAKE Handbuch. Sie können auch Dave Dittrich um Hilfe fragen, wie man eine Regel in einem Skript erstellt). # Where are PID files kept? R=/var/run . . . # Get the value of CONFDIR as defined by hwfuncs.sub. C=$(shell bash -c '. /etc/rc.d/init.d/hwfuncs.sub; echo $$CONFDIR; exit 0') . . . # Bridging $R/bridge.sh.pid: \ $C/HwINET_IFACE \ $C/HwLAN_IFACE \ $C/HwMODE @$(LOGGER) "/etc/rc.d/init.d/hwdaemons $(ACTION)" @/etc/rc.d/init.d/hwdaemons $(ACTION) . . . # hflowd $R/hflowd.pid: \ $C/HwLAN_IP_RANGE \ $C/HwMANAGE_IP @$(LOGGER) "/etc/rc.d/init.d/hflowd $(ACTION)" @/etc/rc.d/init.d/hflowd $(ACTION) . . . # DNS resolution /etc/resolv.conf: \ $C/HwDOMAIN \ $C/HwMANAGE_DNS @$(LOGGER) "/dlg/config/dns2resolv.sh" @/dlg/config/dns2resolv.sh . . . Referenzen ---------- Isolinux: http://syslinux.zytor.com/iso.php Linux Kernel Documentation: initrd.txt Man Page für make Man Page für syslog, syslog.conf, syslogd Man Page für init Man Page für inittab Man Page für mingetty Fehler und Feedback ------------------- Feedback können Sie an project@honeynet.org senden. Fehler melden Sie bitte hier https://bugs.honeynet.org/.