Anzeige:
Ergebnis 1 bis 8 von 8

Thema: Wie erstelle ich eine IPTABLES-Firewall?

  1. #1
    Registrierter Benutzer
    Registriert seit
    Jul 2002
    Ort
    Hamburg
    Beiträge
    608

    Wie erstelle ich eine IPTABLES-Firewall?

    Da ich sehr viel Zeit investieren musste um diesen komplexen Stoff zu verstehen,
    möchte ich dieses hiermit weitergeben.

    Um den Einstieg zu erleichtern habe ich ein Skript auf der Konsole erstellt, welches
    "/etc/rc.firewall" heißt. Bei meiner Distribution (Mandrake) wird dieses, wenn es
    existiert auch automatisch beim OS-Start ausgeführt.

    Letztendlich ist das Ganze nicht wirklich magisch: Das Skript ist eine Textdatei die
    jeder, der möchte, editieren und verbessern (hoffentlich ) kann. Damit's klappt
    muß diese ausführbar sein, also mindestens "chmod 755 /etc/rc.firewall", bzw.
    "chmod a+x /etc/rc.firewall" wer es lieber ausführlich mag.

    Da ich hoffe, das das Skript mittels Kommentaren selbsterklärend ist, habe ich
    folgend nur den Code eingefügt, Kritik ist willkommen. Angehängt ist eine
    "rc.firewall.txt", ".txt" damit sie hochgeladen werden konnte

    Let's begin:
    Code:
    #!/bin/bash
    echo "executing script:"
    # Folgend alle Variablen die irgendwelche Ports öffnen, das
    # bedeutet, das diese Firewall erst mal alles dicht macht,
    # eine sogenannte restriktive Firewall
    NET2SERVER=""
    LAN2SERVER="ssh domain http sunrpc hostname rpc2portmap
     webcache https ipp mysql 10000 32768"
    SERVER2LAN="ssh domain hostname rpc2portmap ipp 32768"
    SERVER2NET="ftp ftp-data http https"
    NET2LAN=""
    LAN2NET="ftp ftp-data http https pop3s cvspserver 5190
     8000 8030 8032 8400 8780"
    PORTS2REJECT="auth 4661 4662 4663 4664 4665 4666"
    NIC2NET="ppp0"
    NICs2LAN="eth1 eth2"
    allowedICMP="echo-request destination-unreachable
     source-quench time-exceeded parameter-problem"
    
    ## Module laden                            ##
    #############################################
    modprobe -v ip_tables
    modprobe -v ip_conntrack
    modprobe -v iptable_filter
    modprobe -v iptable_mangle
    modprobe -v iptable_nat
    modprobe -v ipt_LOG
    modprobe -v ipt_limit
    modprobe -v ipt_state
    modprobe -v ipt_owner
    modprobe -v ipt_REJECT
    modprobe -v ipt_MASQUERADE
    modprobe -v ip_conntrack_ftp
    modprobe -v ip_nat_ftp
    
    
    ## Kernelparameter setzen                  ##
    #############################################
    
    # accept_source_route: Dies würde erlauben, das fremde Rechner
    # den Weg definieren dürfen, den Packete nehmen. Weg.
    # accept_redirects: Dies würde fremden Rechnern das
    # Manipulieren der Routing-Tabelle erlauben. Weg.
    # *_redirects: Dies würde fremden Rechnern das Manipulieren
    # der Routing-Tabelle erlauben. Weg.
    for i in /proc/sys/net/ipv4/conf/*/{accept_source_route,
            accept_redirects,send_redirects}
    do
        echo 0 >$i
    done
    
    # Pakete sollen auch weitergeleitet werden "(--> LAN)"
    echo 1 >/proc/sys/net/ipv4/ip_FORWARD
    
    # SynCookie-Schutz aktivieren
    echo 1 >/proc/sys/net/ipv4/tcp_syncookies
    
    
    ## alle Regeln zurücksetzen                ##
    #############################################
    
    # Folgende Tabellen gibt es unter Linux, jede enthält chains, welche
    # die eigentlichen Regeln sind:
    # filter:      Enthält alle filternden Regeln
    # nat:	      Enthält Regeln, welche Ziele verdeckt weiterleiten 
    #               (z.B. Server im LAN von außen erreichen)
    # mangle:   Hier können Pakete gemangled werden, also manipuliert.
    
    # Zuallererst wir alles zurückgesetzt, das heißt alle Regeln gelöscht
    # und alle Tabellen auf drop gesetzt.
    # -F steht für flush, also leeren. -X steht für erase, also löschen.
    iptables -F
    iptables -t nat -F
    iptables -t mangle -F
    iptables -X
    iptables -t nat -X
    iptables -t mangle -X
    
    iptables -P INPUT	DROP
    iptables -P FORWARD DROP
    iptables -P OUTPUT DROP
    echo "All Rules deleted."
    
    ## neue Regeln                             ##
    #############################################
    
    # INPUT kommt von draußen, # OUTPUT geht rauswärts. Da viele Sachen
    # über höhere Ports ( >=1024 ) abgehandelt werden, nachdem
    # auf einem Standard-port die Verbindung verhandelt wurde, lassen
    # wir alle eingehenden TCP-Verbindungen zu, die NICHT das erste
    # Paket einer Übertragung sind. ESTABLISHED steht für verbunden,
    # d.h. zugehörig zu einer bestehenden Verbindung. RELATED sind
    # Verbindungen, welche vermutlicht ebenfalls zu einer bestehenden
    # dazugehören.
    iptables -A INPUT -p ALL -m state --state ESTABLISHED,RELATED -j ACCEPT
    echo "INPUT-states defined!!"
    iptables -A OUTPUT -p ALL -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
    echo "OUTPUT-states defined!!"
    
    # Lokale (-i[nterface] lo) Kommunikation soll natürlich frei verlaufen.
    iptables -A INPUT -i lo -j ACCEPT
    iptables -A OUTPUT -o lo -j ACCEPT
    
    # Nun lasse ich den Kontakt zu meinem Server zu. Ähnlich
    # verfährt man mit allen anderen Servern. dport steht für
    # d[estination]port und sport für s[ource]port.
    for port in $SERVER2NET; do
    	iptables -A OUTPUT -p tcp --sport $port -j ACCEPT
    	iptables -A OUTPUT -p udp --sport $port -j ACCEPT
    	echo "srv2net: Port $port allowed"
    done
    for port in $NET2SERVER; do
    	iptables -A INPUT -p tcp --dport $port -j ACCEPT
    	iptables -A INPUT -p udp --dport $port -j ACCEPT
    	echo "net2srv: Port $port allowed"
    done
    
    # Nun den Kontakt zwischen LAN und SERVER
    for port in $SERVER2LAN; do
    	for NIC in $NICs2LAN; do
    		iptables -A OUTPUT -o $NIC -p tcp --sport $port -j ACCEPT
    		iptables -A OUTPUT -o $NIC -p udp --sport $port -j ACCEPT
    	echo "srv2lan: Port $port on $NIC allowed"
    	done
    done
    for port in $LAN2SERVER; do
    	for NIC in $NICs2LAN; do
    		iptables -A INPUT -i $NIC -p tcp --dport $port -j ACCEPT
    		iptables -A INPUT -i $NIC -p udp --dport $port -j ACCEPT
    	echo "lan2srv: Port $port on $NIC allowed"
    	done
    done
    
    # Nun folgen Regeln um das LAN ins internet zu bringen. Dies geschiet
    # AUSSCHLIEßLICH über die FORWARD-chain. -o Gerät definiert,
    # ob es rauswärts oder reinwärts geht.
    iptables -A FORWARD -o $NIC2NET -p ALL -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
    for NIC in $NICs2LAN; do
    	iptables -A FORWARD -o $NIC -p ALL -m state --state ESTABLISHED,RELATED -j ACCEPT
    	echo "nics2lan: $NIC opened"
    done
    for port in $LAN2NET; do
    	iptables -A FORWARD -o $NIC2NET -p tcp --sport $port -j ACCEPT
    	iptables -A FORWARD -o $NIC2NET -p udp --sport $port -j ACCEPT
    	echo "lan2net: Port $port on $NIC2NET allowed"
    done
    for port in $NET2LAN; do
    	for NIC in $NICs2LAN; do
    		iptables -A FORWARD -o $NIC -p tcp --sport $port -j ACCEPT
    		iptables -A FORWARD -o $NIC -p udp --sport $port -j ACCEPT
    	echo "net2lan: Port $port on $NIC allowed"
    	done
    done
    
    # Zuletzt aktivieren wir die NAT, somit werden die LAN-Clients auf die
    # Internetseitige IP gefälscht, um von außen den Eindruck eines einzigen
    # Rechners zu erzeugen.
    iptables -t nat -A POSTROUTING -o $NIC2NET -j MASQUERADE
    
    # Nun öffnen wir die Kommunikation zur Namensauflösung "(DNS: port 53)".
    # Zuerst die ANfrage an einen DNS. Dieses läuft erst über UDP, wenns
    # nicht klappt über TCP. Die Antwort ist schwieriger, da die Antwort
    # über UDP läuft und die firewall somit nicht erkennen kann, ob es eine
    # bestehende oder neue Verbindung sein soll. Daher geben wir explizit
    # den DNS-Server an.
    iptables -A OUTPUT -p udp --sport 1024: --dport 53 -j ACCEPT
    iptables -A OUTPUT -p tcp --sport 1024: --dport 53 -j ACCEPT
    for DNS in $(cut -d ' ' -f 2 /etc/resolv.conf)
    do
    	iptables -A INPUT -p udp -s $DNS --sport 53 -j ACCEPT
    	iptables -A INPUT -p tcp -s $DNS --sport 53 -j ACCEPT
    	echo "DNS $DNS opened."
    done
    
    # Jetzt kümmern wir uns, um bestimmte ICMP-Packete, welche
    # nicht Port, sondern Inhalt-abhängig sind (Fehlermeldungen).
    # Da wir zur Fehlersuche nicht auf PING in jede Richtung
    # verzichten möchten, lassen wir alles durch.
    for type in $allowedICMP; do
    	for NIC in $NICs2LAN; do
    		iptables -A INPUT -i $NIC -p icmp --icmp-type $type -j ACCEPT
    		iptables -A OUTPUT -o $NIC -p icmp --icmp-type $type -j ACCEPT
    	echo "ICMP: $type on $NIC allowed."
    	done
    done
    
    #**Und zuletzt erlauben wir jedwegen Traffic INNERHALB des LAN
    iptables -A FORWARD -i eth1 -o eth2 -j ACCEPT
    iptables -A FORWARD -i eth2 -o eth1 -j ACCEPT
    echo "LAN2LAN enabled!"
    #**
    
    
    ## Logging                                 ##
    #############################################
    
    # Wir lassen die restlichen Pakete durchlaufen, aber ignorieren sie,
    # denn wir wollen es einem Eindringling nicht gönnen, herauszufinden,
    # was wir so blocken. Einige Ports blocken wir offen, um endlose
    # Wartevorgänge auf der anderen Seite zu verhindern.
    for PORT in $PORTS2REJECT; do
        iptables -A INPUT -p tcp --dport $PORT -j REJECT --reject-with tcp-reset
        iptables -A FORWARD -i $NIC2NET -p tcp --dport $PORT -j REJECT --reject-with tcp-reset
        echo "$PORT will be rejected."
    done
    iptables -A INPUT -j DROP
    
    # NETBIOS und CUPS droppen wir Kommentarlos, alles andere zeichnen wir auf.
    iptables -A INPUT -p tcp --dport netbios-ns -j DROP
    iptables -A INPUT -p tcp --dport netbios-dgm -j DROP
    iptables -A INPUT -p tcp --dport netbios-ssn  -j DROP
    iptables -A INPUT -p udp --dport netbios-ns -j DROP
    iptables -A INPUT -p udp --dport netbios-dgm -j DROP
    iptables -A INPUT -p udp --dport netbios-ssn  -j DROP
    iptables -A INPUT -p tcp --dport 631 -j DROP
    iptables -A INPUT -p udp --dport 631 -j DROP
    iptables -A INPUT -j LOG
    iptables -A OUTPUT -j LOG
    iptables -A FORWARD -j LOG
    
    # Außerdem wollen wir die Welt um uns nicht mit ungewollten
    # Paketen belästigen, daher werden diese zurückgewiesen.
    iptables -A OUTPUT -p tcp -j REJECT --reject-with tcp-reset
    iptables -A OUTPUT -p udp -j REJECT
    iptables -A OUTPUT -j DROP
    echo "Finished!"
    Nicht über die Unterschiede zur Anlage wundern, sind nur "kosmetischer" Natur...
    Der Teil innerhalb der ** ist nicht über Variablen gesteuert, fällt bei einer NIC ins LAN weg und muß bei mehr als zwei NICs ins LAN erweitert werden.

    (Wer will, kann ja gerne ein Scriptlet an mich senden, was dies automatisch macht..)
    Geändert von Qeldroma (31.05.03 um 10:14 Uhr)

  2. #2
    Debianer Avatar von msi
    Registriert seit
    Jan 2002
    Ort
    München
    Beiträge
    1.963
    das hier könnte auch ganz interessant sein:
    http://www.pl-berichte.de/t_netzwerk...-eigenbau.html

  3. #3
    Premium Mitglied Avatar von SeeksTheMoon
    Registriert seit
    Feb 2002
    Beiträge
    1.704
    Auf Sourceforge gibts ein interessantes Projekt:
    http://firewall-jay.sourceforge.net/

    Ein Shell-Script, dass die Einstellungen automatisch vornimmt.
    09F911029D74E35BD84156C5635688C0

  4. #4
    Premium Mitglied Avatar von SeeksTheMoon
    Registriert seit
    Feb 2002
    Beiträge
    1.704
    Das Tutorial oben erstellt schon eine recht komplexe Firewall.
    Um iptables grundlegend zu verstehen, sollte man vielleicht mit einem kleineren Script anfangen.
    Für ein besseres Verständnis habe ich auch die ausgeschriebenen Parameter von iptables genommen und nicht die kurzen, dann sind die Anweisungen klarer zu verstehen (leider wird das hier im Forum etwas zu breit).
    Dieses Script benötigt auch keine großartigen Zusatzmodule im Kernel, denn davon gibt es viel zu viele um in das Thema einzusteigen. Man kommt mit wirklich wenigen Modulen aus. (Für jedes Feature muss man in seinem Kernel ein Modul kompilieren und laden)
    In der manpage von iptables steht unter "extensions", was es alles an Erweiterungen gibt und beim Kernelbacken kann man auch was stöbern.

    Es soll aber erstmal eine simple Firewall sein, die von außen nichts hinein läßt, aber von innen alles hinaus läßt.
    Masquerading habe ich auch eingestellt, wenn der Firewall-Rechner auch als Router für ein LAN dient.

    Statt dem verwendeten DROP kann man auch REJECT benutzen (dafür ein eigenes Kernelmodul kompilieren), denn DROP verwirft Pakete kommentarlos, wodurch der Sender nicht weiß, was los ist. REJECT liefert an den Sender einer Anfrage eine Meldung, dass der Port geschlossen ist, worauf dieser hoffentlich aufhört, weitere Anfragen zu senden.

    Code:
    #!/bin/sh
    
    # zuerst setzt man für die drei Standard-chains INPUT (=Reinkommendes), OUTPUT 
    #(=Rausgehendes) und FORWARD (=Weiterleitung) eine 
    # möglichst restriktive Regel (=Policy) auf und lockert diese nachher:
    #
    # nix reinlassen:
    iptables --policy INPUT DROP
    # alles weiterleiten; wird für Masquerading gebraucht. 
    # Ohne Masquerading sollte man die nächste Zeile auf DROP stellen.
    iptables --policy FORWARD ACCEPT
    # alles raus erlauben. Will man das nicht, nimmt man DROP und muss dann nachher 
    #entsprechende Regeln schreiben, die ausgehenden Verkehr teilweise erlauben.
    iptables --policy OUTPUT ACCEPT
    
    # Forwarding generell erlauben und Masquerading aktivieren. Braucht man es nicht, 
    #lässt man die nächsten beiden Zeilen weg. 
    #Die Tabelle "nat" ist für Network Address Translation, das man für Masquerading 
    #benötigt (im Kernel nicht vergessen).
    echo "1" > /proc/sys/net/ipv4/ip_forward
    iptables --table nat --append POSTROUTING --out-interface eth0 --jump MASQUERADE
    
    #Port für www (80), https (443) und ssh (22) für tcp öffnen, damit man von außen auf 
    #z.B. auf einen lokal laufenden Apache kommt, oder sich per ssh einloggen kann.
    # Wird das nicht benötigt, lässt man die Zeilen einfach weg. Man kann sie auch um 
    #weitere Ports erweitern; je nach Dienst (z.B. FTP-Server, Donkey, o.ä.)
    # Hat man die Extension "multiport" im Kernel, muss man nicht für jeden Port eine 
    #eigene Regel schreiben; man schreibt dann durch Kommas getrennt die Ports 
    #zusammen, z.B. --destination-ports 22,80,443
    # --table filter ist übrigens Standard und muss nicht geschrieben werden.
    iptables --table filter --append INPUT --protocol tcp --destination-port 22 --in-interface eth0 --jump ACCEPT
    iptables --table filter --append INPUT --protocol tcp --destination-port 80 --in-interface eth0 --jump ACCEPT
    iptables --table filter --append INPUT --protocol tcp --destination-port 443 --in-interface eth0 --jump ACCEPT
    
    # Den Port für DNS (53) offen zu halten, kann ganz nützlich sein. DNS benutzt UDP als 
    #Protokoll, hab ich mir sagen lassen.
    iptables --table filter --append INPUT --protocol udp --source-port 53 --in-interface eth0 --jump ACCEPT
    Jeder Eintrag besteht hier aus dem Befehl "iptables", gefolgt von einer Tabelle, der Daten-"Richtung", dem Protokoll, den betroffenen Ports und dem Netzwerk-Interface, über die der Verkehr läuft.
    Hat man einen Alias für die Netzkarte vergeben, so kann man das übrigens nicht trennen (vielleicht geht es mit komplexeren Erweiterungen, keine Ahnung).
    Also eth0, eth0:0, eth0:1 werden alle generell mit eth0 angesprochen.
    Der Parameter --jump (bescheuerter Name) ist die tatsächliche Aktion, die erledigt werden soll, z.B. Paket annehmen, verwerfen o.ä.

    Wer da jetzt durchgestiegen ist und Sonderwünsche hat, der kann seine Firewall noch mehr ausbauen.
    In dem gentoo-Security-Handbuch steht auch ein ausführliches Kapitel über iptables:
    http://www.gentoo.de/inhalte/doku/gentoo-security

    Dieses Script hier ist nicht ideal: man kann vom Rechner mit dieser Firewall weder pingen noch surfen (aber von allen Rechnern, die im LAN hinter ihm sind). Es dient nur als Demobeispiel zur Veranschaulichung, bevor man sich komplexere Regeln zusammenstellt.
    Geändert von SeeksTheMoon (16.11.03 um 13:47 Uhr)
    09F911029D74E35BD84156C5635688C0

  5. #5
    Registrierter Benutzer
    Registriert seit
    Jul 2002
    Ort
    Hamburg
    Beiträge
    608
    ...und wer's noch in englisch haben möchte, der schaut einfach kurz mal hier nach.

    Ist meine Homepage, mit einigem an Linux-Info und natürlich auch die obige Firewall, nur halt bilingual (deutsch/englisch).

    Greets, qd

  6. #6
    Mod. FAQ/Howto/Emulation
    Registriert seit
    Sep 2000
    Beiträge
    17.397
    Buchtip: Linux-Firewalls - Ein praktischer Einstieg

    http://www.oreilly.de/german/freeboo...ger/index.html

    (Link und Tip von cane)

  7. #7
    Premium Mitglied Avatar von SeeksTheMoon
    Registriert seit
    Feb 2002
    Beiträge
    1.704
    Es gibt einen lustigen (weil fiesen) Weg, sich an einem Angreifer seines Rechners zu rächen, höchstwahrscheinlich ohne dass er was merkt oder ohne dass er es verhindern kann ohne zu rebooten.
    z.B. gehen mir diese Broadcasts auf den Sack, die beim IIS Kontrolle über die Konsole bekommen wollen (was beim Apache natürlich nicht klappt).
    Aber man kann so auch helfen Würmer auszubremsen.
    Die Rede ist von einem "neuen" Iptables target, das sich TARPIT nennt.
    (Es gibt auch daemons die das machen können, z.B. labrea)

    Tarpits funktionieren so, dass sie einen Angreifer rein lassen, aber nicht mehr raus. Das schluckt beim Angreifer Ressourcen, beim Verteidiger nicht (zumindest nicht so viele wie bei einem DROP oder gar so viele wie beim Angreifer).
    Die genaue Funktionsweise:
    When data transfer begins to occur, the TCP window size is set to zero, so no data can be transferred within the session. The connection is then held open, and any requests by the remote side to close the session are ignored. This means that the attacker must wait for the connection to timeout in order to disconnect.
    Das Verhalten ist zwar nicht immer ganz sozial (also falls jemand unseren Rechner nicht angreifen will, aber trotzdem ins tarpit fällt, das ist schon was fies), aber das ist eine Konfigurationsangelegenheit wie fies mans macht und außerdem jedem selbst überlassen.

    Was jetzt kommt, setzt voraus, dass man Ahnung vom Kernelbacken und von iptables-Firewalls hat.

    Man saugt sich dazu einen 2.4er oder 2.6er Kernel und sollte auch iptables installiert haben.
    Das TARPIT-Target befindet sich allerdings (leider!) weder im Kernel noch ist es bei iptables dabei, sondern man muss sich die iptables patch-o-matic runterladen. Das ist ein Paket mit diversen Kernelpatches für iptables, die neue Targets und was weiß ich noch alles bringen.
    Die ganzen Zusatzfeatures stehen hier:
    http://netfilter.org/patch-o-matic/pom-pending.html
    http://netfilter.org/patch-o-matic/pom-base.html
    http://netfilter.org/patch-o-matic/pom-extra.html

    Netfilter benutzt seit neustem Subversion und kein CVS mehr. Ich habe hier ein Tutorial geschrieben, wie man Subversion installiert.
    Momentan stehen noch keine Informationen auf der Webseite wie man die Daten mit subversion auscheckt, viellciht geht es mit
    Code:
    svn co http://cvs.netfilter.org/cgi-bin/viewcvs.cgi/trunk/patch-o-matic-ng
    (Name? Passwort? Keine Ahnung, ggf. über das Webinterface saugen: http://cvs.netfilter.org/cgi-bin/vie...tic-ng/TARPIT/ oder nach Tarballs Ausschau halten)

    wer den 2.4er Kernel hat, der gibt einfach
    ./runme extra/ipt_TARPIT.patch
    ein und bestätigt mit "y".

    Leute mit 2.6er Kernel laden die angepasste Version hier runter:
    http://cvs.netfilter.org/cgi-bin/vie...PIT/linux-2.6/

    Die c-Datei wandert nach /usr/src/linux/net/ipv4/netfilter und die Inhalte der anderen beiden Dateien müssen in die Konfig und Makefile gepatcht werden, das kann man mit einem Texteditor schnell selber machen.

    Jetzt lässt sich in den Kerneleinstellungen bei den Netfilter-Optionen TARPIT auswählen.
    Nach dem Kernelbacken/Reboot/Modul-Laden können wir unsere Firewall-Regeln der INPUT-Chain editieren.

    Wenn wir z.B. folgendes haben um den Webserver verfügbar zu machen:
    iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
    dann bietet sich folgende Ergänzungszeile an:
    iptables -I INPUT -p tcp -s 0.0.0.0/0 --dport 80 -m string --string "cmd.exe" -j TARPIT
    dazu muss man natürlich die string-Funktionen von iptables drin haben.
    Mit dieser Zeile ist Port 80 zwar verfügbar, aber sobald jemand auf die cmd.exe zugreifen will, wie das etwa 10minütlich im Netz passiert, dann haben wir schonmal ein Schwein am Haken.

    Wer z.B. die Verbreitung des Code Red/Nimda bekämpfen will, der trägt folgende Regel ein:
    iptables -I INPUT -p tcp -s 0.0.0.0/0 -m string --string "default.ida" -j TARPIT

    So, jetzt gehts darum den Bosartigkeitsgrad einzustellen
    Jeder wird am Ende seiner Regeln DROP-Regeln haben:
    iptables -A INPUT -p tcp -j DROP
    iptables -A INPUT -p udp -j DROP
    Mit unserem Tarpit können wir vor diesen beiden noch folgendes eintragen:
    iptables -A INPUT -p tcp -j TARPIT
    und schon haben wir jeden am Haken, der unserer Firewall (und somit uns) nicht schmeckt

    Wer es generell etwas freundlicher haben will, der kann das z.B. so machen:
    iptables -A INPUT -p tcp -m tcp --dport 135 -j TARPIT
    iptables -A INPUT -p tcp -m tcp --dport 139 -j TARPIT
    iptables -A INPUT -p tcp -m tcp --dport 1025 -j TARPIT
    iptables -A INPUT -p tcp -j REJECT
    iptables -A INPUT -p udp -j DROP
    das blockt DCOM Würmer, Angriffe auf den Taskplaner usw.
    Alle anderen Anfragen werden rejected, d.h. mit einer Fehlermeldung an den Surfer gedroppt.


    So, dieses Howto funktioniert leider mit keinem automatischen iptables-Generator den ich kenne (webmin, jays-iptables), denn tarpits sind exotisch bei iptables (aber geil ohne Ende ), obwohl die als target ziemlich billig einzufügen wären.

    Je mehr Leute das verwenden, desto effizienter kann man sich insgesamt gegen dieses menschliche oder programmierte Gesocks da draußen wehren.

    Ob das tarpit mit UDP klappt, weiß ich nicht genau, aber weil UDP ein verbindungsloses Protokoll ist, schätze ich mal dass das nicht funktioniert.
    Das müsste man noch austesten oder nachlesen.
    Geändert von SeeksTheMoon (22.11.04 um 11:32 Uhr)
    09F911029D74E35BD84156C5635688C0

  8. #8
    Registrierter Benutzer
    Registriert seit
    Jul 2002
    Ort
    Hamburg
    Beiträge
    608

    Kleines Update zu einem möglichen Fehler:

    Zitat Zitat von ThorstenS
    Hi,
    schöner Beitrag mit der Firewall!
    Dein vorgehen erinnert mich an die Regeln, die fireHol.sf.net erzeugt.

    Da ich nicht direkt unter deinen thread posten kann, hier noch mal ein Vorschlag:
    Du suchst in der resolv.conf nach IPs der nameserver, aber vergisst den 'search home.lan' Eintrag, den fast alle dort noch stehen haben.
    Daher hier mein Vorschlag an die IPs zu kommen:
    awk '/nameserver/ { print $2 }' /etc/resolv.conf

    Evtl. magst du es ja noch einbauen.

    Grüße
    Thorsten
    ....Ohne Worte ...... ;-)

    Danke

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •