VHS Herne Linux Workshop I/2000 5 Abende , 20 UE, 18.30 - 21.45 Uhr 1. Block (4.5.) ================= Der LehrerPC hatte verschiedene Probleme: 1.)Lilo konnte linux nicht mehr starten( das ging letztes Jahr noch) mit boot-CD konnte ich das installierte System booten, dann musste ich per hand die lilo.conf editieren, yast hat das nicht higekrigt, denn lilo sollte im Bootsector der root-partition installiert werden, diese ist aber eine logische Partition - tricky! 2.)der rechner lief ruckelig, langsam, auf console 10 rauschten SCSI Fehlermeldungen durch: hatte keine Lust den Fehler zu suchen, wollte alle SCSI-Module mit rmmod entfernen, ging aber nicht: busy Also habe ich in /etc/modules.conf alias scsi_hostadapter off eingetragen und rebootet. 3.) X-Window(oder KDE) ist einmal eingefroren ?! - alte Version ? Ein Teilnehmer-PC hatte einen unsichtbaren Mauscursor !? - die Erstellung einer neuen Konfiguration mit sax hat geholfen. Themen: * /sbin/init.d/ Startscripte * locate, updatedb, find * cron-jobs /etc/crontab kcrontab * auf entfernten Rechnern arbeiten textbasiert: mit telnet oder besser mit ssh graphisch: einzelne Fenster mit xhost und DISPLAY Umleitung gesamten Desktop mit xdm oder kdm als Server und X -query servername oder X -indirect servername damt xdm oder kdm das auch zulässt, bitte entsprechenden Artikel in der Suse support DB lesen. * NFS: Verzeichnisse(z.B. eine gemountete CD) übers Netz freigeben * Webseiten von 3 LUGs gezeigt und auf Linux-Treffen in Marl, Essen, Herne hingewiesen 2. Block (11.5.) ================= Soundkarten-Treiber ISA-PnP karten findet man mit pnpdump | less aktivieren mit: pnpdump -c > /etc/isapnp.conf PCI-Karten findet man mit cat /proc/pci (hier kann man auch sehen, welche SB-PCI man hat: 1370 oder 1371) entweder: klassische Kernel-Module, auch OSS-free genannt /etc/modules.conf (früher auch /etc/conf.modules genannt) editieren. oder: ALSA(http://www.alsa-project.org/ sind auch Kernel Module, gehören aber nicht zum Standard-2.2.x Kernel) ALSA am besten mit alsaconf oder yast2 konfigurieren -> ergibt Alsa-Einträge in modules.conf testen: startet kmix ? welche Teile der Karte wurden erkannt/aktiviert: cat /dev/sndstat oder cd /proc/asound/ cat * alle Kernel-Module zeigen: modprobe ungenutzte Module entfernen: rmmod -a Versuch, ein Modul zu laden (schauen, ob Modul zur Hardware passt): modprobe --- ZIP-Drive ist wie eine Festplatte zu benutzen z.B. ein SCSI-Gerät: root@machine> mount -t vfat /dev/sda4 /zip !!! sda4-> 4.Partition! - seltsam , aber so sind die Dinger ab Werk formatiert. - nur root darf so mounten, dann können User auf diesem Gerät nur lesen, nicht schreiben. root kann für das Gerät einen Eintrag in /etc/fstab machen, damit user auch mounten & schreiben dürfen: user@machine> mount /zip --- "altes" StarOffice 5.1 nervt mit Freischalt-Code und druckt immer dasselbe Stop-Sign ?! Wenn man den Drucker "lp" benutzen möchte , dann sind Soffice's Voreinstellungen ok. Sonst: als root mit soffice den Drucker konfigurieren. Vorraussetzung: ein funktionierendendes Linux-Drucksystem ( lpd & apsfilter & ghostscript ) Druckerwarteschlange ansehen: lpq oder klpq Druckjobs löschen: mit lprm oder klpq die meissten Anwendungen können auch "in Datei drucken" das ist dann i.d.R. eine Postscript-Datei; Diese kann man dann so ausdrucken: lpr datei.ps oder auf dem Monitor ansehen: ghostview datei.ps (num-lock-taste ausmachen! ;-) --- Linux Printserver für UNIX/Linux Clients (lpd, Port 515) Ein Druck-Server benötigt eine korrekte /etc/hosts oder einen DNS-Nameserver wo alle Druck-Clients drinstehen. UND eine /etc/hosts.lpd wo alle drinstehen , die drucken dürfen. Der Client richtet eine lokale Warteschlange für den entfernten Drucker an. yast -> Netzwerk-> Netzwerk-Drucker Server & Client benötigen beide einen laufenden lpd Fehlermeldungen findet man mit: tail -f /var/spool/lpd/DRUCKERNAME/log oder eventuell auch in tail -f /var/log/messages --- Meine /etc/hosts habe ich auf dem lokalen Webserver zur verfügung gestellt: cp /etc/hosts /usr/local/httpd/htdocs/ leider lief auf Port 80(http) der thttpd - wer installiert denn sooowas ?? also habe ich den erstmal gestoppt: root@machine> rcthttpd stop und Apache restartet: root@machine> rcapache restart 3. Block (16.5.) ================= wie lädt man ein Kernel-modul: von Hand: modprobe (ohne .o-Endung) automatisch: durch Eintrag in /etc/modules.conf Platz schaffen durch deinstallation von Paketen ----------------------------------------------- welche Pakete sind installiert ? rpm -qa wenn man eine passende Suse CD hat: Install. festlegen/starten -> Serie wählen -> Pakete markieren vorher [i] nachher [D] =deinstall ( R = reinstall ) F10, F10, installation starten, KEIN Backup oder Konfiguration laden, default oder Minimal anwählen, dann "ersetzen" dann: installation starten, KEIN Backup wenn man keine passende Suse CD zur Hand hat: yast -> Pakete löschen oder rpm -e Paketname wieviel Platz verbraucht ein Verzeicnis und sein Inhalt ? du -sh (s=Summe,h=human readible) du -sh * wieviel Platz ist noch auf den Partitionen frei ? df -h X-Window-Tastenbelegung ändern ------------------------------- xkeycaps (numlock ausschalten, rechtsklick auf gewünschte Taste) xmodmap ~/.Xmodmap <- wird immer beim start von X ausgeführt Pakete installieren ------------------- mit mc kann man sowol in rpm-pakete als auch in tgz-archive hineinschauen. RPM --- rpm Pakete enthalten fertige ausführbare Programme und dazugehörige Dateien inclusive der Information in welche Verzeichnisse die einzelnen Dateien installiert werden sollen. (absolute Pfade) rpm pakete können pre- und post- install und deinstall -skripte enthalten, die im Verlauf der (De-)Installation ausgeführt werden. Ausserdem bietet das rpm System noch viele weitere Features, die im (online-)Buch "maximum RPM" ausführlich beschrieben werden. install oder update eines Paketes: rpm -U paketname.rpm tgz/tar-Archive --------------- tgz oder tar.gz Pakete enthalten meisstens ein Verzeichnis mit den Quelltexten des Programms. Inhalt zeigen: tar tvfz paket.tgz Auspacken: cd /tmp tar xvfz paket.tgz Einpacken: tar cvfz paket.tgz /verz1 /home/mherweg/verz2 .tgz und .tar.gz sind gleichbedeutend. .tar.Z packt man so aus: uncompress paket.tar.Z tar xvf paket.tar wenn das tgz ein Quell(Source)Paket war, dann findet man in dem ausgepackten Verzeichnis README und INSTALL Dateien in denen steht, was es zu beachten gibt. findest Du eine configure Datei , dann führe sie aus, ist configure zufrieden(alles nötige ist auf dem System vorhanden) dann erstellt es Makefile(s) Compile-vorgang starten um ausführbares binary zu erhalten: make Programm und zugehörige Dateien installieren: als root: make install tgz Paket mit fertigem binary 'drin (enthält keine Quellen( .c .h ...)) ----------------------------- - hat man verwendet , als es noch kein rpm gab. z.B. mein selbstgemachtes xanim-Paket ich habe es so erstellt: cd / tar cvfz /tmp/xanim2.80.0_linux_binary.tgz usr/X11R6/bin/xanim usr/local/xanim/mods von einer DOS-Diskette nach /tmp kopieren : mcopy A:xanim* /tmp vorsichtshalber vorher mal den Inhalt ansehen: tar tfz /tmp/xanim2.80.0_linux_binary.tgz usr/X11R6/bin/xanim usr/local/xanim/mods/ usr/local/xanim/mods/vid_cvid_2.0_linuxELFx86g21.xa usr/local/xanim/mods/vid_cyuv_1.0_linuxELFx86g21.xa usr/local/xanim/mods/vid_h261_1.0_linuxELFx86g21.xa usr/local/xanim/mods/vid_h263_1.0_linuxELFx86g21.xa usr/local/xanim/mods/vid_iv32_2.1_linuxELFx86g21.xa usr/local/xanim/mods/vid_iv41_1.0_linuxELFx86g21.xa usr/local/xanim/mods/vid_iv50_1.0_linuxELFx86g21.xa und dann in / auspacken(=installieren): cd / tar xvfz /tmp/xanim2.80.0_linux_binary.tgz xanim & aktion sind Player für AVIs & Qt-MOVies (aktion ist nur eine KDE-Oberfläche für xanim) für mpeg-movies gibt es z.B. mpeg_play oder MTV CD-Brenner ---------- cdrecord (kann multi-session, bootbare CDs, Hybrid(MAC & PC)....) mkisofs (ein ISO-Image erzeugen um es danach zu brennen) xcdroast (Oberfläche) cdparanoia (audio-CD Ripper) cdda2wav (audio-CD Ripper) cdrdao (disk at once brennen) ... wenn man nur ein ATAPI((E)IDE) Gerät besitzt, so muss man per modifizertem Kernel ein SCSI-Gerät simulieren. Anleitung dazu gibt's vielfach im Internet. Brennprogramme startet man al root, weil direkte auf das Device z.B. /dev/scd0 zugegriffen wird. Emulatoren ---------- wine - um win16 und win32-programme laufen zu lassen. Man benötigt teilweise ein installiertes Windows, weil in wabi längst nicht alle DLLs enthalten sind/sein können. wabi - von SUN, um win16-programme laufen zu lassen. dosemu - DOS-Emulator (genaugenommen ein BIOS-Emulator, man benötigt command.com u.s.w. z.B. freeDOS, DR-DOS, MS-DOS o.a.) vmware - simuliert einen kompletten PC, ist pay-ware stonx - Atari ST Emulator (CPU-intensiv) uae - Unix Amiga Emulator executor - Mac-Emulator , ist pay-ware weitere Emulatoren: Mame, SNES, Gameboy, PalmPilot, ZX81, ZX Spectrum, Altair, C64.... 4. Block (25.5.) ================= erfolgreich ein Quellpaket installieren und compilieren: als Beispiel der WWW-Browser "w3m" , gefunden bei www.freshmeat.net (wo sonst ;-) ging auch nicht auf Anhieb, weil einige Header-Files (.h) aus den Kernel-Quellen benötigt werden - also schnell das Paket "lx_suse" (enthält Kernel-Sources) installiert, dann ging's. source=executable: sogennnte Skript-Sprachen: bash, perl, Tcl/Tk, python... als Beispiel mein bash-script "fdcopy" vorgestellt, ausserdem "alsaconf" als schönes Beispiel wie man bash-scripte mit Hilfe von "dialog" schöner machen kann. Der Windows Emulator "wine" --------------------------- * neueste Version von wine downloaden & installieren * /etc/wine.conf an den eigenen Rechner Anpassen * Win-Partition mounten * ein Win16 oder win32 Programm starten, z.B.: wine notepad.exe SAMBA ----- File und Druckserver für Windows-clients, aber auch: Linux als smb-Client Samba-Server konfigurieren: entweder /etc/smb.conf editieren oder SWAT verwenden Samba User & passworte anlegen mit smbpasswd: anlegen: smbpasswd -a username (muss ein existierender Linux User sein) Samba passwort ändern: smbpasswd username SWAT aktivieren: Kommetartzeichen # in /etc/inetd.conf entfernen, rcinetd restart Zuordnung Dienstname<->Portnummer steht in /etc/services auf SWAT zugreifen: point your webbrowser to http://localhost:901 Als Linux-Client auf windows-shares zugreifen: smbclient smbmount //rechner/sharename /lokaler_mountpoint mount -t smb //rechner/sharename /lokaler_mountpoint Bildbearbeitung mit GIMP ------------------------ Gimp ist ein pixelorientertes Grafikprogramm, ähnl. Photoshop Es eignet sich besonders zur Photobearbeitung und für WWW-Graphiken. Im WWW und in Zeitschriften findet man viele GIMP-Kurse/Tutorials. Es gibt midestens 2 deutsche Gimp-Bücher. Das Gimp User Manual(GUM) kann man sich als zusätzliches Paket installiern. Die nächste stabile Version wird 1.2 sein. Wer mit 1.1.x-Versionen arbeitet, sollte hin und wieder sein Bild abspeichern. Gimp gibt es seit einiger Zeit in einer internationalisierten Version d.h. Menus erscheinen in der jeweiligen Landessprache des Users. Wer etwas vektor/objektorientertes benötigt, wird in den üblichen Office-Paketen fündig, "dia" kann man auch mal probieren(wie Visio) Ich selbst benutze hin und wieder "xfig" Einen Verwandten von xfig findet man auch in gimp wieder: Filter->Render->Gfig 5. Block (8.6.) ================= Proxy ----- Proxy-Server werden hauptsächlich aus 2 Gründen eingesetzt: 1.) man spart Bandbreite, weil Internet-Inhalte zwischengespeichert (cache) werden. 2.) man erhöht die Sicherheit des lokalen Netzes, weil interne Anfragen immer nur an der Proxy gehen. Der Proxy holt die Seiten aus dem Internet oder aus seinem (Festplatten)-Cache und liefert sie dem Client(Browser). So verhindert man, dass direkt Datenpakete zwichen dem internenen Netz und dem Internet verkehren. Bei den Client PCs muss nur der Proxy im Browser eingetragen werden. Routing & Nameserver-Einträge sind bei den Clients nicht nötig. InternetProvider, mittlere bis grosse Firmen, UNIs usw. benutzen den Proxy-Server Squid. Squid kann man über eine einzige, gut dokumentierte config-Datei konfigurieren. Für den Heimgebrauch emfehle ich den Proxy & Offline-Reader wwwoffle. Konfiguration : /etc/wwwoffle/wwwoffle.conf dort eintragen: - den eigenen Rechnernamen eitragen unter dem der Rechner für alle Clients bekannt ist, - welche Client-PCs dürfen wwwoffle benutzen ? - bis auf welche Grösse soll der Festplatten Cache nach einem wwwoffle -purge Aufruf gestutzt werden ? Hintergrund-Prozess(daemon): wwwoffled Mit dem client-Programm wwwoffle oder über einen WWW-Browser... http://martin:8080/control/ http://martin:8080/index/lasttime/ http://martin:8080/index/outgoing/ http://martin:8080/index/monitor/ ... lässt sich wwwoffled steuern. In mein Internet-Einwahl-Skript(oder in kppp) schreibe ich z.B.: wwwoffle -online ; wwwoffle -fetch In das Auflegen-Script dann: wwwoffle -offline --- Firewall Der Linux-Kernel kann Datenpakete nach verschiedenen Kriterien reinlassen rauslassen duchlassen(routen) alternativ dazu: verwerfen oder verweigern Kriterien: Quell-IP-Adresse, Quell-Port, Ziel-IP-Adresse, Ziel-Port, Protokoll-Art(TCP,UDP,ICMP) Es gibt einen zusammenhang zwischen Port-Nummern und Diensten(ftp,http,smtp,pop3,dns....) siehe /etc/services Tools zum einstellen der Firewall-Regeln: Kernel 2.0 ipfwadm 2.2 ipchains 2.4 iptables Vortrag auf dem LinuxTag 1999: -------------------------------------------------------------------------------------- Firewalls unter Linux von Thomas Avieny (t_avieny@informatik.uni-kl.de), Klaus Knopper (knopper@unix-ag.uni-kl.de) Theorie Thomas Avieny Warum werden Firewalls benötigt? Heute besteht häufig die Notwendigkeit ein firmeneigenes Netz mit der Außenwelt zu verbinden. Dabei bestehen für jeden Rechner innerhalb des eigenen Intranet Risiken wie Attacken oder Datendiebstahl bzw. Datenverlust. Somit ist es durch gezielte Angriffe von außerhalb möglich, den (Rechner-)Betrieb lahmzulegen, aber auch an firmeninterne, sensible Daten zu gelangen. Verhindern lässt sich dies mit Hilfe von sogenannten Firewalls. Allerdings sind Firewalls auch kein Allheilmittel, sondern bieten nur einen gewissen Schutz und müssen an die jeweiligen Bedürfnisse angepasst und dauerhaft betreut werden. Grundsätzliche Überlegungen Im allgemeinen Sprachgebrauch bezeichnet man mit einem Firewall einen einzelnen Rechner, der als Schnittstelle Intranet und Außenwelt verbindet und den ein- und ausgehenden Datenfluss überwacht und gegebenenfalls filtert bzw. blockiert. Dazu muss entschieden werden, ob der Firewall eher restriktiv (alles verbieten, was nicht ausdrücklich erlaubt wird) oder freizügig (alles erlauben, was nicht explizit verboten wird) gestaltet werden soll. Grundsätzlich gibt es verschiedene Konzepte, um auf ein- und ausgehende Aktivitäten Einfluss zu nehmen. Jedes Konzept stellt einen Kompromiss zwischen Sicherheit und Zugänglichkeit dar. Dies zeigt sich daran, dass ein Konzept transparent, und somit auch komfortabel für den Anwender, oder sicher ist, was sich meist in zusätzlichen Passwortabfragen äußert. Paketfilter (Screening Router) Paketfilter (engl. Screening Router) stellen das einfachste Firewall-Konzept dar, indem sie jedes einzelne Paket untersuchen und nach bestimmten Kriterien weiterleiten oder abblocken. Dazu verwenden sie Informationen aus dem IP- und TCP-Header der einzelnen Pakete. In erster Linie sind das Absender- und Empfängeradresse, Absender- und Empfängerport sowie der Pakettyp, also Informationen, die der Transportschicht des Internet-Schichten-Modells entsprechen. Um einen Paketfilter zu erzeugen werden die Kriterien in sogenannte Regeln gefasst und diese später der Reihe nach bearbeitet. Damit wird es möglich, den Datenfluss von bzw. zu bestimmten Rechnern zu kontrollieren. Über die Portnummern können verschiedene Dienste/Programme berücksichtigt werden. Screening Router sind für den Anwender völlig transparent, d.h. im Normalfall merkt er nichts von einem solchen Filter. Allerdings bieten sie auch nur einen sehr einfachen Schutz. Es ist beipielsweise nicht möglich, sogenannte "flooding attacks" (viele kurz aufeinander geschickte Pakete) zu erkennen. Darüber hinaus ist die Filterliste anfällig für Fehler und kann nur von Administratoren mit genauen Kenntnissen erstellt werden. Die wichtigste Einschränkung ist jedoch, dass sich praktikabel gewisse Dienste und Programme nur für alle oder keinen Benutzer zugänglich machen lassen! SOCKS-Server Mit Hilfe von SOCKS-Servern wird es nun möglich, Dienste bzw. Programme nur für bestimmte Benutzer zugänglich zu machen. Ein vollständiges SOCKS-System besteht aus dem eigentlichen SOCKS-Server der auf dem Bastion-Host, d.h. dem Firewall-Rechner, installiert wird, sowie einer Bibliothek auf jedem Client. Die zu benutzenden Programme müssen alle angepasst werden, was allerdings durch das einheitliche Protokoll kein hoher Aufwand ist. Die zusätzliche Funktionalität wird hier durch eine zusätzliche Passwortabfrage und somit einem gewissen Komfortverlust erkauft. Außerdem ist der Aufwand gegenüber Paketfiltern natürlich höher! Mit SOCKS-Servern ist es immer noch nicht möglich, bestimmte Aktionen oder Befehle einzelner Programme, d.h. auf Anwendungsebene, zu erlauben bzw. zu verbieten. Application-Level Gateways Durch Application-Level-Gateways wird es nun möglich, wirklich jede Aktion eines Programms zu kontrollieren. Dazu wird allerdings für jede Applikation ein eigener, sehr spezieller Server benötigt, der die entsprechende Funktionalität bietet. Somit benutzt jeder dieser Server ein eigenes Protokoll, das die Kommandos des Programmes berücksichtigt. Diese Lösung bietet damit auch den besten Schutz, ist allerdings am aufwendigsten. Beurteilung von Firewalls Firewalls sind zwar kein Allheilmittel, bieten bei sinnvoller Anwendung aber schon einen brauchbaren Schutz. Außerdem erleichtern sie den Aufwand gegenüber Lösungen für jeden einzelnen Rechner ganz beträchtlich, bieten sie doch eine zentralisierte Stelle für Installation, Konfiguration und Administration. Zu beachten ist weiterhin: Ein Firewall setzt ein sicheres Betriebssystem vorraus, außerdem sollte nur Firewall-Software auf diesem Rechner installiert sein! Durch die gleichzeitige Verwendung und Kombination der verschiedenen Systeme kann die Sicherheit gesteigert werden. Firewalls bieten nur einen sehr eingeschränkten Schutz gegenüber Viren und Trojanischen Pferden. Schon ein einziges Modem innerhalb des Intranet kann einen noch so sicheren Firewall umgehen! Konfigurationsbeispiele unter Linux Klaus Knopper Der Linux-Kernel unterstützt bereits ohne Zuhilfenahme von Daemon-Prozessen statisches Routing, IP-Forwarding, IP-Paketfilter, IP-Accounting, Port-Umleitung und Masquerading (auch oft im Zusammenhang mit NAT - Network Address Translation - genannt). Diese Eigenschaften werden in Form von kernelinternen Tabellen bzw. Ketten von Regeln (Chains) konfiguriert. Zur Verwaltung dieser Regeln dienen die Programme ipfwadm (Kernel bis 2.0.36) und ipchains (Kernel ab 2.2.0). ipchains bietet gegenüber ipfwadm durch ein neues Konzept von Regel-Verkettungen (siehe Skizze) eine höhere Flexibilität sowie einige neue Optionen, die erst mit den neuen Kernels verwendet werden können. Im Folgenden werden Konfigurationsbeispiele mit ipchains betrachtet, wovon die meisten - mit abgewandelter Syntax - prinzipiell auch auf ipfwadm übertragbar sind. Voraussetzungen Ausstattung Für die folgenden Beispiele müssen einige Mindestanforderungen an das Hostsystem erfüllt sein. Linux ab Kernel 2.2, Mehrere Netzwerkinterfaces (z.B. zwei Netzwerkkarten oder eine Netzwerkkarte plus Modem/ISDN), TCP/IP-Support im Kernel (Standard) IP-Forwarding-Support im Kernel, IP-Firewall-Support im Kernel, evtl. IP-Masquerading-Support im Kernel und spezielle Masquerading-Module, installierte Programmpakete ipfwadm bzw. ipchains. Die ipfwadm/ipchains-Pakete sind üblicherweise Standard-Ausrüstung in der Contrib der jeweiligen Linux-Distribution und als freie Software inklusive Quelltext erhältlich. Falls der Kernel keinen Firewall-Support hat, muss er neu übersetzt werden. Hierzu sind bei make menuconfig die Optionen Network firewalls, IP: firewalling und bei Masquerading IP: always defragment sowie möglichst alle Masquerading-Optionen im Menüpunkt Networking options auszuwählen. Festlegungen Der Einfachheit halber sei in folgenden Beispielen angenommen, dass ein internes Netzwerk mit IP-Adressen im Bereich 192.168.1.1 bis 192.168.1.254 vorhanden sei, wobei der als Router/Firewall einzusetzende Linux-Rechner auf der Netzwerkkarte eth0 mit der Adresse 192.168.1.254 konfiguriert und mit dem internen Netz verbunden ist. Als externe Schnittstelle des Linux-Rechners wird im Beispiel ein analoges Modem verwendet, das vom Provider über PPP eine dynamische IP-Adresse zugewiesen bekommt, über die es Daten ins Internet schicken und vom Internet entgegennehmen kann. Da die IP-Adresse von ppp0 nicht konstant ist, müssen die ipchains-Regeln entsprechend flexibel ausgelegt werden, da sonst bei jedem Dialout die Konfiguration der Filter- und Forwardingregeln geändert werden müsste. ipchains Für ein- und ausgehende IP-Pakete (TCP, UDP und ICMP) können Regeln definiert und miteinander verkettet werden. Bei einer Kette von Regeln (Chain 1 in der Skizze) wird nacheinander überprüft, ob auf ein Paket die angegebenen Eigenschaften (Source/Destination-Adresse, Source/Destination-Port, Art des Paketes, Interface) zutreffen. Treffen die von einer Regel angegebenen Eigenschaften zu, wird zu einer vordefinierten Behandlung des Paketes (Tabelle) oder in eine für diesen Fall definierte weitere Kette von Regeln (Chain 2 in der Skizze) verzweigt. Die vordefinierten und vom Kernel direkt umsetzbaren Behandlungen eines IP-Paketes, auf das eine Regel zutrifft, sind: ACCEPT Akzeptieren des Paketes DENY Das Paket wird ohne Rückmeldung an den Absender verworfen (dieser bekommt eventuell einen Timeout, wenn es sich um ein TCP-Paket handelte) REJECT Das Paket wird verworfen und der Absender erhält per ICMP eine Rückmeldung, dass die Verbindung abgebrochen wurde. (Dies führt auf der Absender-Seite zu der bekannten Meldung "connection refused", die auch im Normalfall auftritt, wenn auf dem Zielport kein Server-Dienst läuft.) MASQ Das Paket wird nach Umschreiben der Source-Adresse in die des Routers an den Zielhost weitergeleitet REDIRECT Das Paket wird auf eine andere IP-Adresse/Port umgeleitet RETURN Rücksprung zur nächsten Regel in der vorigen Regelkette Folgende Chains sind vordefiniert: input Regeln für ankommende Pakete output Regeln für abzuschickende Pakete forward Regeln für weiterzuleitende Pakete neuer_name Benutzerdefinierte Regeln, die in die bereits gesetzten eingeklinkt werden können (z.B. Chain 2 in der obigen Skizze) Forwarding Kernel IP-Forwarding Per Default ist bei den älteren Kernels 2.0.x das Forwarding von IP-Paketen zwischen Netzwerkinterfaces aktiviert, d.h. der Kernel leitet automatisch aufgrund von Source- und Destination-IP eines Paketes die Daten an die entsprechenden Netze, sofern über seine lokalen Interfaces erreichbar, weiter. Mit dem Kommando echo 0 > /proc/sys/net/ipv4/ip_forward lässt sich das Forwading, unabhängig von gesetzten Firewall-Regeln oder Routing-Tabellen, deaktivieren. mit echo 1 > /proc/sys/net/ipv4/ip_forward lässt es sich aktivieren. Default-Policies Wenn noch keine Regeln definiert wurden oder nach Aufruf von ipchains -F input ipchains -F output ipchains -F forward sind üblicherweise die Default-Behandlungen alle gleich ACCEPT, d.h. es werden Pakete in ein- und ausgehender Richtung akzeptiert und je nach Herkunft- und Zieladresse weitergeleitet. Daher genügt es, mit route die statischen Routes und das Defaultgateway zu setzen, um einen Linux-Rechner als Router zu betreiben. Wird dynamisches Routing verwendet, so müssen die Kernel-Routingtabellen durch einen Daemon (routed, gated) aktualisiert werden. Masquerading Ein privates Netz mit den üblicherweise nicht gerouteten, reservierten IP-Adressen 192.168.1.x soll über einen Linux-Rechner Zugang zum Internet erhalten. Durch Masquerading ist es möglich, den Netzzugang über die Modem-Schnittstelle des Linux-Rechners (ppp0) gemeinsam für alle Rechner im privaten Netz zu nutzen. Die Rechner im privaten Netz müssen hierfür lediglich die ins interne Netz zeigende IP-Adresse 192.168.1.254 des Linux-Rechners als Default-Gateway eintragen. Auf dem Linux-Rechner wird mit der Regel ipchains -A forward -s 192.168.1.0/0 -d 0/0 -j MASQ das IP-Masquerading für das private Netz aktiviert. Erkennt der Linux-Kernel ein IP-Paket, das aus dem internen Netz stammt und eine Zieladresse im externen Netz besitzt, so merkt er sich die Adresse des sendenden Rechners, ersetzt diese im IP-Paket durch seine eigene und leitet das Paket über sein externes Interface ppp0 weiter. Der externe, angerufene Host sieht also nur die derzeit weltweit gültige externe IP-Adresse des Linux-Rechners. IP-Pakete, die anschließend vom angerufenen Host auf den Source-Port des vermeintlichen "Anrufers" zurückgeschickt werden, werden vom Linux-Router so umgeschrieben, dass als Zieladresse wiederum die Adresse des Rechners im internen Netz eingetragen wird, der die Verbindung ursprünglich initiiert hat. Auf diese Weise entsteht über den masqueradenden Linux-Router eine bidirektionale Verbindung zwischen den beiden Rechner im internen und externen Netz. Dieses Feature hat den Vorteil, dass (fast) alle Dienste des Internet uneingeschränkt aus dem Intranet genutzt werden können, sofern sie keinen Verbindungsaufbau in Rückrichtung erfordern. Ein direkter Verbindungsaufbau aus dem externen ins interne Netz ist nicht möglich, da der IP-Bereich des internen Netzes vor dem externen "versteckt" wird. Im Zusammenspiel mit den weiter unten erwähnten Anti-Spoofing-Regeln ist dies bereits eine sehr komfortable Lösung, um in vielen Fällen ausreichende Sicherheit für das interne Netz zu gewährleisten. Dienste wie FTP, die einen Verbindungsaufbau aus dem externen ins interne Netz erfordern (ftp-data), sind mit Masquerading allein zunächst problematisch. Hierfür gibt es jedoch Lösungen mit Hilfe von zusätzlichen Kernel-Modulen, die dienstspezifisch bei einer bereits bestehenden Steuerverbindung Pakete zu Ports des dienstanfordernden Rechners im internen Netz weiterleiten. Beispiel: modprobe ip_masq_ftp modprobe ip_masq_irc modprobe ip_masq_raudio Eine weitergehende Kontrolle der im Kernel implementierten Masquerading-Funktionen bietet das Utility ipmasqadm, das ebenso wie ipchains zur Standardausrüstung eines Linux-Routers gehört. Paketfilter Default-Policies Zum Betrieb eines komplexeren Firewalls - vor allem dann eingesetzt, wenn das interne Netz nicht per Masquerading versteckt, sondern mit weltweit gültigen IP-Adressen versehen wird - gibt es je nach Sicherheitsbedarf in der Praxis zwei Fälle: Fall 1: Die Default-Policy für die Annahme/Weiterleitung von IP-Paketen bleibt auf ACCEPT und der Zugriff auf unerwünschte Ports wird gezielt gesperrt. Fall 2: Zunächst wird der gesamte durch den Linux-Router gehenden Netzwerkverkehr gesperrt und dann gezielt für bestimmte Adressen und Ports wieder geöffnet. Im Fall 1 wird, falls beispielsweise der Telnet-Dienst vom externen ins interne Netz gesperrt werden soll, folgende Regel angewendet: ipchains -I input -i ppp0 -d 192.168.1.0/0 23 -p tcp -j DENY Vom (Modem-)Interface ppp0 kommende TCP-Pakete mit Zieladresse im internen Netz und Zielport 23 (Telnet) werden hiermit verworfen. Ein telnet zum Firewall-Rechner selbst wäre hierbei aber immer noch möglich, da dessen externe Adresse nicht mit der angegebenen Maske 192.168.1.0/0 übereinstimmt! Im Fall 2 wird im Beispiel die Default-Policy für die Input-Regeln auf DENY gesetzt. Hierdurch werden sämtliche ankommenden IP-Pakete verworfen, wenn keine der noch zu definierenden ipchains-Regeln greift. ipchains -P input DENY (Hinweis: Man sollte dies aus verständlichen Gründen nicht über das Netz versuchen, sondern an der Konsole oder mit einem vorher ausgiebig getesteten Script arbeiten. Falls Folgeregeln zum Wiederöffnen von Ports fehlschlagen, sperrt man sich sonst selbst aus.) Die meisten der im Folgenden kommentierten ipchains-Regeln beziehen sich auf Fall 2. Forwarding für interne Netzwerkadressen erlauben Pakete aus dem internen Netz sollen den Firewall passieren dürfen. # Lokale Verbindungen erlauben (X-Window, lokale daemons etc.) ipchains -A input -i lo -j ACCEPT # Privates Netz hinter eth0 hat uneingeschränkten Zugriff ipchains -A input -i eth0 -j ACCEPT Anti-Spoofing und Verbindungaufbau nur in eine Richtung Obwohl die Netzwerkadressen 192.168.x.x normalerweise nicht von Providern geroutet werden (sollten), ist ein Angriff möglich, in dem der Angreifer vortäuscht, seine IP-Pakete stammten aus dem internen Netz und dürften wegen der oben behandelten Masquerading-Regeln den Linux-Router passieren. Hier muss der Linux-Firewall erkennen, dass die Pakete nicht aus dem internen Netz stammen, sondern aus dem externen Netz über das Interface ppp0 geschickt wurden, und muss diese verwerfen. ipchains -A input -i ppp0 -s 192.168.1.0/0 -j DENY Diese Regel sollte vor denjenigen Regeln stehen, die Verbindungen erlauben. Zugriff auf gewünschte Dienste erlauben Nach den oben definierten Regeln können bereits Pakete aus dem internen Netz das externe Netz erreichen. Nun muss ein "Rückweg" ermöglicht werden, wobei darauf geachtet werden muss, dass hierdurch keine Angriffspunkte entstehen. Beispielsweise ist es günstiger, auf dem Firewall einen Caching Nameserver zu betreiben, der vom internen Netz aus abgefragt werden kann, als den Zugriff auf externe Nameserver (und den Rückweg!) für das interne Netz zu erlauben. Im folgenden Beispiel wird das Entgegennehmen von WWW-Daten (TCP, Port 80) erlaubt, jedoch nur, falls die Verbindung aus dem internen Netz initiiert wurde. ipchains -A input -i ppp0 -s 0/0 80 -p tcp ! -y -j ACCEPT Diese Regel funktioniert aufgrund der Tatsache, dass beim Aufbau von TCP-Verbindungen ein Handshake wie unten abgebildet erfolgen muss. Im ersten TCP-Paket beim Verbindungsaufbau von Host A zu Host B ist das Synchronize-Flag gesetzt. In der Antwort des angerufenen Host B sind sowohl Synchronize als auch Acknowledge gesetzt, woraufhin Host A mit dem Senden eines weiteren Acknowledge und den eigentlichen Daten beginnen kann. Es genügt also, diejenigen Pakete auszufiltern, die lediglich SYN gesetzt haben, um den Aufbau einer TCP-Verbindung zu verhindern. Beim UDP-Protokoll besteht diese Möglichkeit nicht. Umleitung (redirect) auf lokale Ports Folgende ipchains-Regel leitet alle Verbindungen, die vom internen Netz aus an externe WWW-Server gehen, auf den Port 3128 des Firewalls um, auf dem ein Squid-Cache läuft. Der Linux-Firewall wird hierdurch zu einem transparenten (von den Clients unbemerkten) Proxy. ipchains -A input -i eth0 -d 0.0.0.0/0 80 -p tcp -j REDIRECT 3128 Neben dem nützlichen Effekt, dass unabhängig von der Browser-Einstellung immer der Cache des Linux-Gateways verwendet wird, kann man sich so das Zulassen direkter WWW-Verbindungen auf Port 80 zwischen Rechnern im internen und externen Netz ersparen. Der Firewall selbst muss natürlich so eingestellt werden, dass er entsprechende WWW-Daten von Port 80 externer Rechner entgegennimmt. Ein weiterer Anwendungsfall ist die Umleitung einer Verbindung auf einen lokalen Port, auf dem ein verschlüsselnder Proxy läft, der eine für den Benutzer transparente Verbindung zu einer Gegenstelle herstellt. Die Daten werden auf der Strecke zwischen den beiden Proxies verschlüsselt übertragen, der Anwender erhät auf seiner Seite jedoch die vom Firewall bereits entschlüsselte Fassung, ohne sich um technische Details der abhörsicheren Übertragung kümmern zu müssen. Nachwort Die hier vorgestellten ipchains-Regeln dienen nur zur Veranschaulichung und sind zum Betrieb eines auf eine konkrete Anwendung bezogenen Firewalls in den wenigsten Fällen ausreichend. Da Firewalls sehr individuell auf den Benutzerkreis abgestimmt werden müssen, ist es nicht möglich, ein auch nur annähernd allgemeingültiges Init-Shellskript mit ipchains-Regeln für einen Firewall anzugeben, auch wenn dies bei vielen Distributionen mittlerweile versucht wird. Zur Konfiguration eines Firewalls und zum komfortablen Aufstellen der Regeln gibt es jedoch diverse graphische Tools, mit denen das Einrichten eines Firewalls ohne genaue Kenntnis der Syntax von ipchains oder Kenntnis von Abläufen im Kernel möglich gemacht werden soll. Links hierzu sind u.a. auf den unten angegebenen Web-Seiten zu finden. Literatur und Links Craig Hunt, TCP/IP Netzwerk Adminstration, O'Reilly Verlag Olaf Kirch, Linux Wegweiser für Netzwerker, O'Reilly Verlag WWW: http://ipmasq.cjb.net/ WWW: http://www.rustcorp.com/linux/ipchains/ WWW: http://www.knopper.net/firewall/ ------------------------------------------------------------------------------------------------------------ http://www.little-idiot.de/firewall/ --- Masqurading Interne IP-Adressen werden nach aussen hin versteckt. Von aussen sieht es so aus , als ob alle Anfragen der Clients vom Masqurading-Host ausgehen. Client-Rechner müssen einen Nameserver für's Internet eingestellt haben. Client-Rechner müssen die lokale IP-Adresse des Masqurading-Hosts als default-Gateway eintragen. Folgende Zeilen kann man in ein Startscript des Masqurading-Hosts eintragen um das Masqurading zu aktivieren: # # IP-forwarding einschalten # echo "1" > /proc/sys/net/ipv4/ip_forward # # Masq-Regel aktivieren # Quelle: alle Rechner von 192.168.1.1 bis 192.168.1.254 # Ziel: alle anderen Netze/Rechner # die 0 hinter dem / ist die Netzwerkmaske: 0.0.0.0 # /24= 24 Stück High-Bits: 11111111 11111111 11111111 00000000 = 255.255.255.0 = ein Class C-Netz geht auch, # ist vielleicht sauberer. # /sbin/ipchains -A forward -s 192.168.1.0/0 -d 0/0 -j MASQ # # module für spezielle dienste # MSQ_MODULES="ip_masq_cuseeme ip_masq_ftp ip_masq_irc ip_masq_quake ip_masq_raudio ip_masq_vdolive" for i in ${MSQ_MODULES}; do /sbin/insmod $i done #------------EOF------------------------------------ aktuell eingestellte Paketfilter Regeln ansehen: ipchains -L masq.-Aktivitäten kontrollieren: ipchains -L -M alle Regeln entfernen(flushen): ipchains -F ----------------------------------------------------------------------------- ENDE ----------------------------------------------------------------------------- Ankündgungen neuer Kurse findet ihr hier: http://www.nel.de/mherweg/linux_vhs.html Weiterhin viel Spass mit freier Software wünscht euch.... Martin Herweg m.herweg@gmx.de