Das Netfilter Kochbuch Alexander W. Janssen $Id: netfilter-kochbuch-de.sgml,v 1.2 2001/06/05 20:55:21 yalla Exp $ Dieses Dokument erlaetert den Gebrauch von Netfilter und iptables anhand praktischer Beispiele. Es ist sowohl fuer Anfaenger, Umsteiger von ipchains und Firewallinteressierten gedacht. ______________________________________________________________________ Table of Contents 1. Vorwort 1.1 Worum geht's ? 1.2 Was gibt's hier ? 1.3 In welchem Status ist das Dokument ? 2. Todo Liste 3. Was ist Netfilter ? 3.1 Netfilter kurz und knapp 3.2 Features von Netfilter 3.3 iptables, Firewallmanagement 4. Eine simple Firewall 4.1 Die Heimloesung: IP-Masqerading oder "Wie komme ich mit nur einer IP aber vielen Rechnern ins Netz ? 4.2 Was ist Portforwarding ? 4.2.1 Wie hoste ich Spiel hinter einer maskierenden Firewall ? 4.2.2 Wie zwinge ich bestimmte Dienste auf bestimmte Hosts hinter der Firewall ? 4.3 Wie kann ich flexibler Routen ? 4.3.1 Wie zwinge ich bestimmte Hosts auf bestimmte Strecken ? 5. Die Architektur des Netfilter Frameworks 5.1 Tabellen 5.2 Chains 5.3 Matches 5.4 Targets 6. NAT 6.1 Was ist NAT ? 6.2 Source NAT oder IP-Masquerading 6.3 Destination NAT 7. Firewall im ernsthaften Einsatz 7.1 Einfuehrung 7.2 Die Demilitarisierte Zone 7.3 Zugriff von Innen nach Aussen 7.4 Zugriff von Aussen nach Innen 7.5 Zugriff in die DMZ 8. Mitloggen und Accouting 8.1 Das LOG Target 8.2 Das ULOG Target 8.2.1 Das MySQL-Plugin 8.2.1.1 Konfiguration des MySQL-Plugins 8.2.1.2 Konfiguration des MySQL-Datenbankservers 8.2.1.3 Einfaches PHP-Script fuer den Apache, um Logfiles anzusehen 8.2.2 Das logemu-Plugin 8.2.3 Das pwsniff-Plugin 9. Angriffsbewertung 9.1 Portscanner 9.2 "Denial of Service" Angriffe 9.2.1 Einschraekungen des Loggingverhaltens 9.3 Gegenmassnahmen 9.3.1 Sperren von Netzen und Hosts waehrend eines Angriffes 10. "Schraeges Routing" 10.1 Hilfe, mein Nachbarnetz nutzt die Selben IP's ! 11. Firewalldesign 11.1 Nachdenken ueber Sicherheit 11.2 Was brauchen wir, was ist unnoetig, was gefaehrlich und unerwuenscht ? 11.3 Ansaetze zum Firewalldesign 11.3.1 "Verbiete alles, erlaube nur was noetig ist" 11.3.2 "Erlaube alles, verbiete was wir nicht haben wollen" 11.4 Zugestaendnisse an Mitarbeiter und Kunden 11.5 Nachdenken ueber Datenschutz 12. VPN 12.1 IPsec 12.2 IP6 12.3 Tunneling 13. Verifikation des Design 13.1 Portscan 13.2 Penetration 13.3 Exploits 13.4 Der Routerfaktor 13.5 Info's ueber aktuelle Sicherheitsluecken 13.6 Externes Sicherheitsconsulting 14. Erlaeuterung einer beliebten Firewalls 14.1 Die SuSE 7.0 Firewall 15. Vergleich von Netfilter mit kommerziellen Firewalls 15.1 Firewall-1 von Checkpoint 15.2 Cisco PIX 16. Quellen 17. Disclaimer und Copyright 18. Dank ______________________________________________________________________ 11.. VVoorrwwoorrtt 11..11.. WWoorruumm ggeehhtt''ss ?? Jaja, so geht's. Da gibt es einen neuen Kernel, und man muss schon wieder ein neues Managementtool zur Linuxfirewall lernen. Am Anfang war ipfwadm, und dannach kam ipchains. Kaum hatte man sich an ipchains gewoehnt, kam iptables. Nun, dieses Dokument ist eigentlich aus der Not entstanden. Ich habe mich schon sehr frueh mit Netfilter beschaeftigen muessen, da ich einem Projekt bei meinem Arbeitgeber eine Firewall auf Linuxbasis ausetzten sollte. Es wurde sher frueh klar, das ipchains "tot" ist und das es wenig Sinn macht, weiterhin darauf zu setzen. Also wurden eifrig die neusten Entwicklerkernel heruntergeladen, netfilter von Hand eingeklebt, kompiliert und getestet. Mitunter mit erbuechternden Folgen. Nun ist der neue Linuxkernel in der Version 2.4.1 verfuegbar, und Netfilter hat meiner Meinung nach (schon lange) einen Stand erreicht, der den Gebrauch im Produktionsbetrieb zulaesst. Es gab nicht sehr viele Dokumente, die mir und meinen Kollegen beim Aufsetzen der ersten Netfilterfirewall geholfen haben, trotzdem gibt es vier wertvolle Quellen, die am Schluss erwaehnt werden. 11..22.. WWaass ggiibbtt''ss hhiieerr ?? Ich will mit diesem Kochbuch das praktisch anwenden, was in den gegenwaertzigen HOWTO's noch unzureichend dokumentiert ist: Mit welcher Variante man welches Ergebniss erreichen kann. Das Dokument setzt Basiswissen im Bereich IP-Netze und Routing vorraus, Wissen ueber die alte Linuxfirewall und ipchains ist nuetzlich, aber nicht notwendig. 11..33.. IInn wweellcchheemm SSttaattuuss iisstt ddaass DDookkuummeenntt ?? Dieses Dokument ist noch in einem sehr fruehen Stadium, also bin ich ueber Hilfe, Anregungen, Anmerkungen und natuetlich Berichtigungen jederzeit dankbar. Dieses Kochbuch hat eine Menge Kapitel, und mindestens genau so viele sind zur Zeit noch leer. Wenn Du, werter Leser, dich geneigt fuehlst, ein leeres Kapitel zu vervollstaendigen und dich auch noch ein wenig mit dem Linuxdoc SGML System auskennst, dann schreibe mir einfach eine Email und teile mir mit, was du tun moechtest. Auch waere ich daran interessiert, wenn sich Freiwillge zwecks Uebersetzung in andere Sprachen bei mir melden wuerden. Ich moechte noch von virneherein erwaehnen, dass ich weder ein Kernelhacker noch ein Netfilterentwickler bin. Ich habe mir nur in viel muehseliger Kleinarbeit die Informationen zusammengesucht, die ich fuer das Firewallsetup an verschiedenen Standorten brauchte. Ich dachte mir, dass es nuetzlich waere, dieses Wissen mit Euch zu teilen. Wie fuer alle Dokumente gilt hier auch: Benutzung auf eigene Gefahr ! Ich kann nicht garantieren, dass alles, was hier beschrieben ist, funktioniert, geschweige denn richtig ist. Fuer weitere Infos schaut in den Disclaimer und ins Copyright. Ausserdem habe ich sehr viele Informationen schamlos geklaut, teils aus "Rusty's unreliable Guides", aus der "Advanced Routing Howto", der "Linux packetfilter HOWTO" und der "Netfilter hacking HOWTO". Naeheres gibts bei den Quellen. Genug der Worte, los gehts ! Viel Spass beim Lesen, Alexander "Yalla" Janssen > 22.. TTooddoo LLiissttee +o Das Dokument modularisieren, dass mehrere Leute an unterschiedlichen Dokumenten zur selben Zeit arbeiten koennen so dass Sie unterschiedlich commitet werden koennen. Notiz fuer mich: Wie geht denn das ? +o Die fehlenden Kapitel vervollstaendigen +o Kompetente Information ueber das connection-tracking besorgen (Mailingliste durchwuehlen...) +o Script zusammensuchen 33.. WWaass iisstt NNeettffiilltteerr ?? 33..11.. NNeettffiilltteerr kkuurrzz uunndd kknnaapppp Netfilter ist der neue Linux Firewall Mechanismus. Er ist integraler Bestandteil des Netzwerkteils von Linux. Netfilter haengt sich, salopp gesagt, in die Sende- und Empfangsleitungen von Linux ein. Wann immer Daten in die Firewall fliessen oder verlassen, ist Netfilter am Ball und trifft anhand von Regeln, die der Benutzer mit dem Tool iptables erstellt, Entscheidungen, was mit diesen Daten passieren soll. Netfilter koennte sich entscheiden, die Daten passieren zu lassen, sie mitzuloggen, sie zu verwerfen, zurueckzuweisen oder gar woanders hin umzuleiten. Netfilter koennte auch ueber den NAT-Mechanismus die Absender- oder Empfaengeradresse oder Port austauschen, oder auch die Pakete markieren, damit sie der Routingmechanismus anders behandelt. Kurzum: Netfilter ist in der Lage, Daten, die durch die Firewall fliessen, zu beeinflussen. Traditionell leiten Router ihre Pakete und deren Inhalt unbeinflusst weiter - eine Firewall kann jedoch vor oder nach dem Routing Entscheidungen treffen, das Paket nach Regeln zu behandeln. 33..22.. FFeeaattuurreess vvoonn NNeettffiilltteerr +o Es bietet eine Paketfirewall der besonderen Art. Es gibt sehr viele Kriterien, nach denen man Pakete auswaehlen kann und es lassen sich eingene Erweiterungen schreiben. Auch lassen sich eigene Targets, dass sind die Komponenten, die letztendlich irgend was mit dem Paket machen (durchlassen, wegwerfen), mit eitwas Programmierkenntniss schreiben. +o Wenn gewuenscht, bringt Netfilter "stateful inspection" mit ins Rennen. Mit der stateful Inspection lassen sich Paketfilter sehr einfach schreiben, es ist also nicht zwangslaefig mehr die Angabe der TCP-Flags noetig. 33..33.. iippttaabblleess,, FFiirreewwaallllmmaannaaggeemmeenntt iptables ist das Programm, mit der Linux 2.4 Firewall administriert wird. Es fasst alle Funktionen wie NAT, mangeling und den Paketfilter unter einer einheitlichen Syntax zusammen. 44.. EEiinnee ssiimmppllee FFiirreewwaallll Die simpelste Firewall, die es wohl gibt, ist die, die den lokalen Rechner vor dem boesen Internet beschuetzt. Idealerweise ist eine Firewall so aufgebaut, dass man nur loakl abgehende Verbindungen aufbauen kann. Eingehende Verbindungen sollen so weit es geht und erwuenscht ist, verboten werden. "Warum", fragt sich nun der aufmerksame Leser, "brauche ich eine loakle Firewall ? Ich habe doch kein Netzwerk !". Nun, diese Frage ist nicht unberechtigt. In Zeiten, wo eine Flatrate mittlerweile in Deutschland erschwinglich ist, ist man gut und gerne 24 Stunden "online", bevor sich die IP durch einen zwanghaften Abbruch aendert. Eine IP, die sich fuer laengere Zeit als ein und dasselbe Host zeigt, ist ein potielles Ziel fuer die selbsternannten "Hacker", den Script Kiddies. Ihnen wird es einen Heidenspass machen, dich zu attackieren, sobald sie wissen, dass es dich gibt ! Dies ist keine ungesunde Paranoia - man muss sich halt nur vor Augen halten, dass die Zeiten von "winnuke" vorbei sind. Ein gewoehnlicher User ist meistens nicht so auf dem Laufenden und sieht es auch gar nciht ein, seinen loaklem FTP-Server zu patchen, "nur" weil "wieder einmal" ein Fehler im wu-ftpd bekannt wurde. Aber Script Kiddies oder andere destruktive Naturen haben schneller einen Exploit zur Hand, ehe man bemerkt, dass man eigentlich angegriffen wird. Und eine Sicherheitslcke, die dem Angreifer eine Rootshell oeffnet, hat eine ganz andere Qualitaet als ein abgestuerzter Rechner. (FIXME: Besseres Beispiel einfuegen, das mit ftp hinkt, da man eh verloren ist, wenn der Exploit angwandt wird) Hier ein Beispiel, dass diesen Forderungen gerecht wird. Es sind, soweit an dieser Stelle zu erlaetern, Kommentare angefgt. # Loesche zuerst alle Regeln in allen Tabellen ipatbles -t filter -F iptables -t nat -F ipatbles -t mangle -F # Nun setzte alle Ketten defaultmaessig auf "alles wegwerfen" iptables -P INPUT DROP iptables -P FORWARD DROP # Nur die OUPUT-Kette, das sind die Daten, die die Firewall selber # rausschickt, wird freigeschaltet iptables -P OUTPUT ACCEPT # Nun erlaube Daten, die von der Firewall selber kommen, auch die Firewall # zu betreten (lo = Loopbackdevice aka 127.0.0.1) iptables -A INPUT -i lo -j ACCEPT # Erlaube Daten, die aus einer Verbindung stammen, die wir selber # erzeugt haben, die Firewall zu betreten ipatbles -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT Diese minimale Firewall bietet also nun folgende Features: +o Sie blockt alle Verbindungsaufbauten von aussen +o Sie erlaubt Verbindungen von innen, die nach aussen oder innen gehen +o Sie erlaubt Daten den Zugang nach innen, deren Verbindung wir selber aufgebaut haben Diese Firewall erlaubt wohlgemerkt sonst gar nicht. Moechte man aber z.B. einen FTP-Server oeffnen, kann man das mit folgenden Befehl tun: # FTP fuer den Zugriff von aussen freischalten iptables -A INPUT -p tcp --dport 20:21 -j ACCEPT Analog dazu kann man auch seinen lokalen Webserver erlauben: # Webzugriff freischalten iptables -A INPUT -p tcp --dport 80 -j ACCEPT 44..11.. eeiinneerr IIPP aabbeerr vviieelleenn RReecchhnneerrnn iinnss NNeettzz ?? DDiiee HHeeiimmllooeessuunngg:: IIPP-- MMaassqqeerraaddiinngg ooddeerr ""WWiiee kkoommmmee iicchh mmiitt nnuurr Das ist meistens die brennenste Frage, die zuallererst geschrien wird: "Ich will doch nur Masquerading !" Ok, hier sollt ihr es haben. Ich habe das gesamte Setup schamlos aus Rusty's Netfilter Guide geklaut. (HIER EINFUeGEN) 44..22.. WWaass iisstt PPoorrttffoorrwwaarrddiinngg ?? Portforwarding ist, wenn eine Maschine einen Port bereitstellt, die Daten annimmt, die Verarbeitung aber letztendlich einer anderen Maschine ueberlaesst. Am besten erlaetert man dies an einem Beispiel: Meine Firewall bietet keine FTP-Dienst an, soll sie auch gar nicht. Hinter meiner Firewall habe ich nun einen Rechner, der diese Aufgabe uebernehmen soll. Die Firewall macht jedoch die Ports 21 und 20 auf und leitet alle Anfragen an den FTP-Host weiter. Der Benutzer denkt jedoch, dass er mit meiner Firewall spricht. Der ganze Mechanismus wird durch NAT und Connectiontracking realisiert. Was passiert hier also im Detail ? Die Firewall nimmt die Daten vom Client entgegen, vertauscht die Absenderadresse des Clients mit seiner eigenen, internen Adresse (unter der sie fuer den eigentlichen FTP-Server bekannt ist), ffnet einen neuen Port von dem sie aus quasi als Vermittler dem FTP-Server die Anfrage stellt. Der FTP-Server redet also nun mit der Firewall. Die Firewall weiss nun ueber ihren Port, mit dem sie mit dem FTP-Server verbunden ist, zu welchem Client im Internet die Verbindung gehoert. 44..22..11.. WWiiee hhoossttee iicchh SSppiieell hhiinntteerr eeiinneerr mmaasskkiieerreennddeenn FFiirreewwaallll ?? Als Beispiel, wie sich ein Portforwarding in Verbindung mit NAT realisieren laesst, zeige ich, wie man das Spiel "Delta Force" aus einem Windowsrechner hinter der Firewall mit einer privaten IP hosten kann: (HIER EINFUeGEN) 44..22..22.. WWiiee zzwwiinnggee iicchh bbeessttiimmmmttee DDiieennssttee aauuff bbeessttiimmmmttee HHoossttss hhiinntteerr ddeerr FFiirreewwaallll ?? 44..33.. WWiiee kkaannnn iicchh fflleexxiibblleerr RRoouutteenn ?? 44..33..11.. WWiiee zzwwiinnggee iicchh bbeessttiimmmmttee HHoossttss aauuff bbeessttiimmmmttee SSttrreecckkeenn ?? 55.. DDiiee AArrcchhiitteekkttuurr ddeess NNeettffiilltteerr FFrraammeewwoorrkkss iptables ist ein Tool, um Regeln in in die Firewall einzupflegen. Um die Architektur im Detail zu verstehen, muessen ein paar Begriffe eingefuehrt und erlaeutert werden. 55..11.. TTaabbeelllleenn Das Netfilter-Framework kennt insgesamt drei Standarttabellen. Die wohl wichtigste Tabelle, die filter-Tabelle, nimmt Regeln fuer den Paketfilter auf. Eine andere wichtige Tabelle, die nat-Tabelle; sie nimmt Regeln zur Manipulation des Paketheaders auf. Dort findet z.B. Source-NAT, Destination-NAT oder das bekannte IP Masquerading statt. Dazu mehr im Punkt NAT. Die dritte, "grosse" Tabelle ist die mangle- Tabelle. In dieser Tabelle lassen sich z.B. die TOS-Bits setzen oder die Pakete intern markieren um im Routing-Code auf andere Wege zu schicken. In jeder Tabelle befinden sich mindestens eine Chain. Die Chains nehmen die verschiedenen Regeln auf, die sich wiederum aus einem Match und einem Target zusammensetzen. 55..22.. CChhaaiinnss Eine Chain ist eine Abfolge von Firewallregeln. Die Regeln in einer Chain werden immer von oben nach unten abgearbeitet. Ein Paket wandert also in eine Chain hinein und der Match der ersten Regeln wird gegen das Paket geprueft. Trifft der Match zu, wird das Paket auf das Target angewandt. Das Target wiederum kann ein "finales" oder ein "nichtfinales" Target sein. Wird ein Paket auf ein finales Target angewandt, ist die Reise fuer dieses Paket in dieser Chain vorbei und das naechste Paket betritt die Chain. Ist es jedoch auf ein nichtfinales Target angewandt worden, wandert das Paket weiter durch die Chain. Jede Chain zaehlt zusaetzlich noch die Anzahl der Pakete mit, die in diese Chain gelangt sind. Auch zaehlt sie die Anzahl der effektiven Bytes mit. Als Zusatzinformation bleibt noch zu sagen, dass man eigene Chains mit eigenen Regeln erstellen kann und beinahe beliebig zwischen den Chains hin- und herspringen kann (was effektiv heisst, dass man ein Paket von einer Stelle der Firewall zu anderen schickt). 55..33.. MMaattcchheess Ein Match ist der Teil einer Regel, der bestimmt, welches Paket auf das Target angewandt wird. Hier mal ein Beispiel in Prosa und dannach in Code: "Alle Pakete, die von 192.168.0.1 nach 192.168.1.6 gehen und zum Port 22/tcp gehen" -s 192.168.0.1 -d 192.168.1.6 -p tcp --dport 22 "Alle Pakete, die vom externen Interface kommen und keine ICMP-echo-requests sind" (eth2 ist dabei das externe Interface) -i eth2 -p ! icmp --icmp-type ! icmp-echo-request 55..44.. TTaarrggeettss Targets bestimmten letztendlich, was mit dem gematchten Paket gemacht werden soll. Hier mal eine Liste typischer Targets: +o ACCEPT - Akzeptiere (erlaube) das Paket. Finales Target. +o DROP - Werfe das Paket weg +o REJECT - Weise das Paket mit einem Fehler zuruechk +o SNAT - Ersetze die Source IP-Adresse des Paketes durch eine andere 66.. NNAATT 66..11.. WWaass iisstt NNAATT ?? NAT ist die Abkuerzung fuer "Network Address Translation". Mit dieser Funktion kann man die Absender- und Empfaengeradresse eines Datenpaketes auf der Firewall so veraendern, dass das Paket entweder woander hingeschickt wird (wenn DNAT - Destination NAT, also die destination IP veraendert wurde) oder dass es so aussieht, als ob jemand anderes das Paket losgeschickt hat (SNAT - source NAT oder MASQUERADE). 66..22.. SSoouurrccee NNAATT ooddeerr IIPP--MMaassqquueerraaddiinngg Dieses sehr populaelre NAT wird sehr haefig eingesetzt. Seine beiden Haupteinsatzgebiete sind einmal kleine, private Netzwerke, die nur eine einzige offizielle IP-Adresse besitzten aber trotzdem durch einen Router Zugriff auf's Internet von allen internen PC's mit privaten IP- Adressen haben wollen - im anderen Fall moechte man durch SNAT einfach verschleiern, das hinter der Firewall noch eine ganze Menge anderer Rechner stehen (daher auch der Name "Masquerading"). 66..33.. DDeessttiinnaattiioonn NNAATT 77.. FFiirreewwaallll iimm eerrnnsstthhaafftteenn EEiinnssaattzz 77..11.. EEiinnffuueehhrruunngg 77..22.. DDiiee DDeemmiilliittaarriissiieerrttee ZZoonnee 77..33.. ZZuuggrriiffff vvoonn IInnnneenn nnaacchh AAuusssseenn 77..44.. ZZuuggrriiffff vvoonn AAuusssseenn nnaacchh IInnnneenn 77..55.. ZZuuggrriiffff iinn ddiiee DDMMZZ 88.. MMiittllooggggeenn uunndd AAccccoouuttiinngg Das Mitloggen von Verbindungen ist ein wesentliches Feature, was man von jeder Firewall erwarten kann. Das Netfilter bietet gleich zwei verschiedene Logmechanismen, unter denen man auswaehlen kann. 88..11.. DDaass LLOOGG TTaarrggeett Das LOG-Target ist ein Target, dass jedes Paket, das es empfaengt, zum syslogd schickt. Im System-Logfile finden sich dann die mitgeloggten Pakete. Beispiel: # Ein paar Variablen setzen, damit das Beispiel deutlich wird EXTIF=ippp0 INTERNALIF=eth0 # Alle ftp-Zugriffe ins private Netz verbieten und mitloggen iptables -t filter -A FORWARD -i $EXTIF -o $INTERNALIF -p tcp --dport 20:21 -j LOG Falls nun vom Interface ippp0 ein Zugriff auf einen Rechner erfolgt, der hinter dem Interface eth0 steht, der dem Protkoll TCP und den Zielports 20 oder 21 (den FTP-Ports) erfolgt, wird dieses Paket geloggt. Man muss sich aber merken, dass es nicht weggeworfen wird ! Dies muesste man im Anschluss noch tun. Der dazugehrige Eintrag in /var/log/messeages wird dann in etwa so aussehen: --- hier einfuegen --- 88..22.. DDaass UULLOOGG TTaarrggeett Das ULOG-Target ist wesentlich flexibler als das LOG-Target. Es tut im wesentlichen genau dass, was das LOG-Target auch tut, nur kann man sich aussuchen, was mit diesem Paket gemacht werden soll und welches Programm das Paket letztendlich bearbeitet. Es ist also nicht, wie LOG, auf den syslogd beschrnkt. Technisch gesehen schickt das ULOG-Target das Paket an eine lokale NETLINK-Multicast Gruppe. Ein beliebiges Programm, dass auf diese Gruppe hoert, kann dann das Paket entgegennehmen und etwas tun. Das bekannteste Programm, was mit dem ULOG-Target zusammenarbeitet, ist sicherlich der ulogd, der "Userspace Logging Daemon". Ulogd arbeitet mit sogenannten Plugins, an die es die Daten weiterreicht. 88..22..11.. DDaass MMyySSQQLL--PPlluuggiinn Das MySQL-Plugin fuer den ulogd ist wohl das momentan beste Plugin, dass es gibt. Es schickt die Paketheader nicht in eine Datei, sondern direkt ueber IP an einen beliebigen MySQL Datenbankserver. In diesem DB-Server gibt es dann eine Datenbank, in der die Tabelle ist, wo die Daten hineingeloggt werden. 88..22..11..11.. KKoonnffiigguurraattiioonn ddeess MMyySSQQLL--PPlluuggiinnss 88..22..11..22.. KKoonnffiigguurraattiioonn ddeess MMyySSQQLL--DDaatteennbbaannkksseerrvveerrss 88..22..11..33.. EEiinnffaacchheess PPHHPP--SSccrriipptt ffuueerr ddeenn AAppaacchhee,, uumm LLooggffiilleess aannzzuusseehheenn 88..22..22.. DDaass llooggeemmuu--PPlluuggiinn 88..22..33.. DDaass ppwwssnniiffff--PPlluuggiinn 99.. AAnnggrriiffffssbbeewweerrttuunngg 99..11.. PPoorrttssccaannnneerr 99..22.. ""DDeenniiaall ooff SSeerrvviiccee"" AAnnggrriiffffee 99..22..11.. EEiinnsscchhrraaeekkuunnggeenn ddeess LLooggggiinnggvveerrhhaalltteennss 99..33.. GGeeggeennmmaassssnnaahhmmeenn 99..33..11.. SSppeerrrreenn vvoonn NNeettzzeenn uunndd HHoossttss wwaaeehhrreenndd eeiinneess AAnnggrriiffffeess 1100.. ""SScchhrraaeeggeess RRoouuttiinngg"" 1100..11.. HHiillffee,, mmeeiinn NNaacchhbbaarrnneettzz nnuuttzztt ddiiee SSeellbbeenn IIPP''ss !! Genau diesen Fall habe ich schon einmal gehabt, mich auf die Hinterbeine gesetzt und doch noch geloest bekommen. Ich werde das Script ohne viele Kommentare hier einfuegen - wenn dies jemand braucht, wird er dieses Script schon verstehen. Aber grundsaetzlich braucht man dafuer das Tool iproute2 und man muss Paketmangeling und fwmark-routing im Kernel aktiviert haben. Was noch wichtig ist: Beide Netze sind 192.168.0.0/24, und sie verwenden das 192.168.10.0/24'er Netz als Dummy-Netz. Wenn also der Rechner 192.168.0.5 den Rechner 192.168.0.10 im anderen Netz bekommen will, spricht er zu 192.168.10.5 - dies laesst sich mit einem gut aufgesetzen DNS bewaeltigen, so dass der User nicht nachdenken muss. #!/bin/bash case "$1" in start) # Zhler fr Klasse C Subnetz auf null setzen i=0 # fwmark Classmark setzen iptables -t mangle -A PREROUTING -i eth1 -s 192.168.0.2 \ -d 192.168.10.0/24 -j MARK --set-mark 0x1 iptables -t mangle -A PREROUTING -i eth2 -s 192.168.0.0/24 \ -d 192.168.10.0/24 -j MARK --set-mark 0x2 # Fr das gesamte Subnetz die D-/ und SNAT Regeln in beide Richtungen # aufsetzen while [ "$i" != 256 ] do iptables -t nat -A PREROUTING -i eth1 -d 192.168.10.$i -j DNAT \ --to-destination 192.168.0.$i iptables -t nat -A PREROUTING -i eth2 -d 192.168.10.$i -j DNAT \ --to-destination 192.168.0.$i iptables -t nat -A POSTROUTING -o eth2 -s 192.168.0.$i -j SNAT \ --to-source 192.168.10.$i iptables -t nat -A POSTROUTING -o eth1 -s 192.168.0.$i -j SNAT \ --to-source 192.168.10.$i i=`expr ${i} + 1` done ;; stop) # Zhler fr Klasse C Subnetz auf null setzen i=0 # fwmark Classmark setzen iptables -t mangle -D PREROUTING -i eth1 -s 192.168.0.2 \ -d 192.168.10.0/24 -j MARK --set-mark 0x1 iptables -t mangle -D PREROUTING -i eth2 -s 192.168.0.0/24 \ -d 192.168.10.0/24 -j MARK --set-mark 0x2 # Fr das gesamte Subnetz die D-/ und SNAT Regeln in beide Richtungen # aufsetzen while [ "$i" != 256 ] do iptables -t nat -D PREROUTING -i eth1 -d 192.168.10.$i -j DNAT \ --to-destination 192.168.0.$i iptables -t nat -D PREROUTING -i eth2 -d 192.168.10.$i -j DNAT \ --to-destination 192.168.0.$i iptables -t nat -D POSTROUTING -o eth2 -s 192.168.0.$i -j SNAT \ --to-source 192.168.10.$i iptables -t nat -D POSTROUTING -o eth1 -s 192.168.0.$i -j SNAT \ --to-source 192.168.10.$i i=`expr ${i} + 1` done ;; *) echo "Fehler ! Erlaubte Parameter: (start|stop)" exit 1 ;; esac exit 0 1111.. FFiirreewwaallllddeessiiggnn 1111..11.. NNaacchhddeennkkeenn uueebbeerr SSiicchheerrhheeiitt FIXME: das ist fuer Julia :-) 1111..22.. WWaass bbrraauucchheenn wwiirr,, wwaass iisstt uunnnnooeettiigg,, wwaass ggeeffaaeehhrrlliicchh uunndd uunneerr-- wwuueennsscchhtt ?? 1111..33.. AAnnssaaeettzzee zzuumm FFiirreewwaallllddeessiiggnn 1111..33..11.. ""VVeerrbbiieettee aalllleess,, eerrllaauubbee nnuurr wwaass nnooeettiigg iisstt"" 1111..33..22.. ""EErrllaauubbee aalllleess,, vveerrbbiieettee wwaass wwiirr nniicchhtt hhaabbeenn wwoolllleenn"" 1111..44.. ZZuuggeessttaaeennddnniissssee aann MMiittaarrbbeeiitteerr uunndd KKuunnddeenn 1111..55.. NNaacchhddeennkkeenn uueebbeerr DDaatteennsscchhuuttzz 1122.. VVPPNN 1122..11.. IIPPsseecc 1122..22.. IIPP66 1122..33.. TTuunnnneelliinngg 1133.. VVeerriiffiikkaattiioonn ddeess DDeessiiggnn 1133..11.. PPoorrttssccaann FIXME: nmap & co 1133..22.. PPeenneettrraattiioonn FIXME: Liste bekannter Penetrationstools (Nessus und co) 1133..33.. EExxppllooiittss FIXME: was ist ein Exploit ? 1133..44.. DDeerr RRoouutteerrffaakkttoorr FIXME: Was ist ein Smurf ? 1133..55.. IInnffoo''ss uueebbeerr aakkttuueellllee SSiicchheerrhheeiittsslluueecckkeenn FIXME: Hier Liste (CERT, Bugtraq etc) 1133..66.. EExxtteerrnneess SSiicchheerrhheeiittssccoonnssuullttiinngg FIXME: Soll man ? 1144.. EErrllaaeeuutteerruunngg eeiinneerr bbeelliieebbtteenn FFiirreewwaallllss 1144..11.. DDiiee SSuuSSEE 77..00 FFiirreewwaallll FIXME: Hier die Firewall mit Kommentaren einfuegen. Zu klaeren: Steht die unter der GPL ? 1155.. VVeerrgglleeiicchh vvoonn NNeettffiilltteerr mmiitt kkoommmmeerrzziieelllleenn FFiirreewwaallllss 1155..11.. FFiirreewwaallll--11 vvoonn CChheecckkppooiinntt FIXME: Freiwillige vor ! 1155..22.. CCiissccoo PPIIXX FIXME: Freiwillige vor ! 1166.. QQuueelllleenn FIXME: Ohhhh jaaaaa, ganz wichtig 1177.. DDiissccllaaiimmeerr uunndd CCooppyyrriigghhtt FIXME: Hier GPL oder diese andere Textsource Lizens rein 1188.. DDaannkk Muss ich wirklich ? ;-)