Gast King555 Geschrieben 5. April 2011 Geschrieben 5. April 2011 Ich setze Debian 5 ein. Bisher hat folgende Anweisung immer funktioniert: iptables -A INPUT -s 46.4.0.0/16 -j DROP (in dem Fall das Sperren einer ganzen IP-Range). Neuerdings geht das nicht mehr, die IPs haben noch Zugriff. Auch wenn nur eine einzige IP angegeben ist, funktioniert der Zugriff immer noch. Muss ich evtl. zwingend das Protokoll angeben? Jetzt sagt mir iptables "all". Sollte doch alle Protokolle sperren, oder nicht? Wo liegt mein Fehler? Oder kann es sein, dass die Anweisung nach einiger Zeit irgendwie ungültig wird, obwohl "iptables -L" mir diese noch anzeigt?
EdwinMosesPray Geschrieben 9. April 2011 Geschrieben 9. April 2011 Hallo king555 Zuerst wären ein paar andere Hinweise sehr hilfreich, um das Ganze im Zusammenhang zu sehen. Z.B. hat das Ganze jemals funktioniert? Das hast du ja schon beantwortet. Sind Änderungen vor der Zeile gemacht worden? Meines Wissens arbeitet der Filter die Konfiguration Zeile für Zeile ab. Trifft ein Ereignis zu, wird es ausgeführt und die Verarbeitung für dieses Paket beendet. Das heisst, ein "iptables -A INPUT ....... -j ACCEPT" VOR deiner Zeile würde alles erlauben und nachfolgende Zeilen nicht mehr beachten. Mir hat es immer geholfen, wenn ich mir ein sog. "Match-Packet" vorgestellt habe und damit iptables Zeile für Zeile durchgegangen bin. Die Frage nach dem ganzen Zusammenhang ist deshalb wichtig, weil auch andere Faktoren mitspielen könnten. Ankommende IP's aus dieser Range sind zwar geblockt, aber was ist, wenn ausgegehende Verbindungen auf diese IP möglich sind und "Connection-Tracker" (.... -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT) aktiv ist? Also Antwortpakete auf neue oder bestehende Verbindungen durchgelassen werden? Vielleicht konnte ich einen Anstoß geben Viel Erfolg Frank M.
Gast King555 Geschrieben 9. April 2011 Geschrieben 9. April 2011 Danke, du konntest auf jeden Fall einen Anstoß geben. Tatsächlich gibt es eine Anweisung, die ALLES akzeptiert, und zwar VOR dem Sperren der IPs. Demnach wurden meine ganzen Sperrregeln ignoriert. Mir war ehrlich gesagt bisher nicht bewusst, dass das erste ACCEPT die Bearbeitung beendet. Es ist so, dass es ein vorgefertigtes Firewall-Skript auf meinem System gibt, welches diverse Dinge ausführt (ungültige Pakete droppen usw.). Am Ende steht dann das ACCEPT für alles andere. Nun habe ich mir aber noch ein eigenes Skript geschrieben, mit zusätzlichen Anweisungen. Das wird danach ausgeführt. Scheinbar lautet die Lösung, dass ich statt "-A" einfach "-I" machen muss. Schon sind die Anweisungen ÜBER dem ACCEPT. Wäre doch richtig so, oder? Funktioniert auf jeden Fall bei meinen Tests. Nun gibt es aber noch zwei Fragen, die sich dadurch ergeben haben: 1.) Wenn ich eine neue Chain erstelle ("iptables -N MY_CHAIN"), wie sorge ich dafür, dass diese VOR meinem Alles-ACCEPT bearbeitet wird? Ich kann da ja kein "-I" machen. Oder kommt es darauf an, wie ich die IPs in diese Chain einfüge? Also dass ich dann mit "-I" arbeite. 2.) Ich habe folgende Anweisung in meinem Skript stehen: # Ping-Flood begrenzen: iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT Würde das ACCEPT auch in diesem Fall, also bei einem "limit", dafür sorgen, dass alles danach nicht mehr ausgeführt wird? Danke schonmal!
EdwinMosesPray Geschrieben 9. April 2011 Geschrieben 9. April 2011 Hallo king555 Ich bin mir nicht sicher, ob das Paket in dem Fall auch dann als "fertig" abgehakt wird. Da es sich um ein ICMP Ping handelt, hat es eh keinen weiteren Nutzen. Spätestens wenn der 2. Ping / sek. kommt, wird es verworfen. Eine relativ sichere Firewall mit iptables würde etwa so beginnen: # Policy Einstellungen iptables -P OUTPUT ACCEPT iptables -P FORWARD DROP iptables -P INPUT DROP Hier ist erstmal der INPUT auf den Firewall Rechner und der FORWARD ins Netz gesperrt. Nun brauchst du dir auch keine Sorgen um ICMP machen ;-) Jetzt fängst du an die Dienste durchzulassen, die benötigt werden, z.B.: # Lokales Interface freigeben iptables -A INPUT -j ACCEPT -i lo # HTTP - HyperTextTransportProtocol (http / https) iptables -A INPUT -j ACCEPT -p tcp -m tcp --dport 80 iptables -A INPUT -j ACCEPT -p tcp -m tcp --dport 443 # FTP - FileTransferProtocol (ftp / ftpdata) iptables -A INPUT -j ACCEPT -p tcp -m tcp --dport 20 iptables -A INPUT -j ACCEPT -p tcp -m tcp --dport 21 ..... Zum Schluss noch eingehende Antworten von innen aufgebauter Verbindungen (Antworten auf ausgehende Verbindungen): # Connection-Tracking iptables -A INPUT -j ACCEPT -m state --state ESTABLISHED,RELATED Jetzt könntest du noch alles loggen, was durchfällt: # Alles was durchfällt wird geloggt iptables -A INPUT -j LOG --log-prefix "Dropped by firewall: " # # # Ende Bei dem o.g. Beispiel kannst du sogar bis zum nächsten Neustart der Firewall temporär Regeln einfügen, die unten an das Script angefügt und ausgeführt werden, z.B.: administrator@server:~$ iptables -I INPUT -j ACCEPT -s 86.24.0.0/16 Oder Löschen mit: administrator@server:~$ iptables -D INPUT -j ACCEPT -s 86.24.0.0/16 Gruß Frank M.
Gast King555 Geschrieben 9. April 2011 Geschrieben 9. April 2011 Jetzt habe ich nochmal genauer in mein vordefiniertes Firewall-Skript reingeschaut und festgestellt, dass es quasi schon so gemacht wird. Mit der einzigen Ausnahme, dass ganz unten alles, was bisher nicht explizit verboten ist, zugelassen wird. So sieht das Skript aus (erzeugt von der Webverwaltungsoberfläche "Plesk" bzw. deren Firewall-Modul): #!/bin/sh # # Automatically generated by Plesk netconf # set -e echo 0 > /proc/sys/net/ipv4/ip_forward ([ -f /var/lock/subsys/ipchains ] && /etc/init.d/ipchains stop) >/dev/null 2>&1 || true (rmmod ipchains) >/dev/null 2>&1 || true /sbin/iptables -F /sbin/iptables -X /sbin/iptables -Z /sbin/iptables -P INPUT DROP /sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT /sbin/iptables -A INPUT -p tcp ! --syn -j REJECT --reject-with tcp-reset /sbin/iptables -A INPUT -m state --state INVALID -j DROP /sbin/iptables -P OUTPUT DROP /sbin/iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT /sbin/iptables -A OUTPUT -p tcp ! --syn -j REJECT --reject-with tcp-reset /sbin/iptables -A OUTPUT -m state --state INVALID -j DROP /sbin/iptables -P FORWARD DROP /sbin/iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT /sbin/iptables -A FORWARD -p tcp ! --syn -j REJECT --reject-with tcp-reset /sbin/iptables -A FORWARD -m state --state INVALID -j DROP /sbin/iptables -A INPUT -i lo -j ACCEPT /sbin/iptables -A OUTPUT -o lo -j ACCEPT /sbin/iptables -A FORWARD -i lo -o lo -j ACCEPT /sbin/iptables -t mangle -F /sbin/iptables -t mangle -X /sbin/iptables -t mangle -Z /sbin/iptables -t mangle -P PREROUTING ACCEPT /sbin/iptables -t mangle -P OUTPUT ACCEPT /sbin/iptables -t mangle -P INPUT ACCEPT /sbin/iptables -t mangle -P FORWARD ACCEPT /sbin/iptables -t mangle -P POSTROUTING ACCEPT /sbin/iptables -t nat -F /sbin/iptables -t nat -X /sbin/iptables -t nat -Z /sbin/iptables -t nat -P PREROUTING ACCEPT /sbin/iptables -t nat -P OUTPUT ACCEPT /sbin/iptables -t nat -P POSTROUTING ACCEPT /sbin/iptables -A INPUT -p tcp --dport 8443 -j ACCEPT /sbin/iptables -A INPUT -p tcp --dport 8880 -j ACCEPT /sbin/iptables -A INPUT -p tcp --dport 80 -j ACCEPT /sbin/iptables -A INPUT -p tcp --dport 443 -j ACCEPT /sbin/iptables -A INPUT -p tcp --dport 21 -j ACCEPT /sbin/iptables -A INPUT -p tcp --dport 22 -j ACCEPT /sbin/iptables -A INPUT -p tcp --dport 587 -j ACCEPT /sbin/iptables -A INPUT -p tcp --dport 25 -j ACCEPT /sbin/iptables -A INPUT -p tcp --dport 465 -j ACCEPT /sbin/iptables -A INPUT -p tcp --dport 110 -j ACCEPT /sbin/iptables -A INPUT -p tcp --dport 995 -j ACCEPT /sbin/iptables -A INPUT -p tcp --dport 143 -j DROP /sbin/iptables -A INPUT -p tcp --dport 993 -j DROP /sbin/iptables -A INPUT -p tcp --dport 106 -j DROP /sbin/iptables -A INPUT -p tcp --dport 3306 -s 127.0.0.1 -j ACCEPT /sbin/iptables -A INPUT -p tcp --dport 3306 -j DROP /sbin/iptables -A INPUT -p tcp --dport 5432 -j DROP /sbin/iptables -A INPUT -p tcp --dport 9008 -j DROP /sbin/iptables -A INPUT -p tcp --dport 9080 -j DROP /sbin/iptables -A INPUT -p udp --dport 137 -j DROP /sbin/iptables -A INPUT -p udp --dport 138 -j DROP /sbin/iptables -A INPUT -p tcp --dport 139 -j DROP /sbin/iptables -A INPUT -p tcp --dport 445 -j DROP /sbin/iptables -A INPUT -p udp --dport 1194 -j DROP /sbin/iptables -A INPUT -p udp --dport 53 -j DROP /sbin/iptables -A INPUT -p tcp --dport 53 -j DROP /sbin/iptables -A INPUT -p icmp --icmp-type 8/0 -j ACCEPT /sbin/iptables -A INPUT -j ACCEPT /sbin/iptables -A OUTPUT -j ACCEPT /sbin/iptables -A FORWARD -j DROP echo 1 > /proc/sys/net/ipv4/ip_forward echo 1 > /opt/psa/var/modules/firewall/ip_forward.active chmod 644 /opt/psa/var/modules/firewall/ip_forward.active # # End of script # Danach wird bei mir noch "fail2ban" aktiviert, welches sich in iptables einklinkt. Am Ende kommt dann noch mein Skript (wird derzeit manuell ausgeführt) und zusätzlich ein Cronjob mit IPs, die gedroppt werden (ändern sich ständig, daher holt der Cronjob die von woanders her). Ich frage mich jetzt, ob ich das überhaupt so beibehalten kann, also mit mehr als einem Skript. Die mehreren Skripte sind derzeit für mich die einfachste Möglichkeit. Das ist mein 2. Skript: #!/bin/sh # Einige zusaetzliche Firewall-Anweisungen # SYN-Flood begrenzen: iptables -N syn-flood iptables -A syn-flood -m limit --limit 100/second --limit-burst 150 -j RETURN iptables -A syn-flood -j LOG --log-prefix "SYN flood: " iptables -A syn-flood -j DROP # Ping-Flood begrenzen: iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT # Portscanner ausschalten: iptables -A INPUT -p tcp --tcp-flags ALL NONE -m limit --limit 1/h -j ACCEPT iptables -A INPUT -p tcp --tcp-flags ALL ALL -m limit --limit 1/h -j ACCEPT # alle TCP-Sessions muesen mit einem SYN beginnen, sonst werden sie verworfen iptables -A INPUT -p tcp ! --syn -m state --state NEW -j LOG --log-prefix "Stealth Scan" iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP # ungewoehnliche Flags verwerfen iptables -A INPUT -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP iptables -A INPUT -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP # Bekannte Hacking-IPs / Anonymisierungsdienste blocken: iptables -I INPUT -s 46.4.0.0/16 -j DROP # vorher stand hier -A, ich habe es schon auf -I geändert # [...] # TOR-Exit-Nodes blocken (eigentliches Skript wird per Cronjob ausgefuehrt): iptables -N TOR_EXIT exit 0 Das Anti-TOR-Skript macht folgendes (bzw. das ist die Hauptanweisung): /sbin/iptables -A TOR_EXIT -s x.x.x.x -j DROP [...] Es gibt dann auf meinem Server noch "DDoS Deflate", welches IPs dynamisch wie folgt blockt: iptables -I INPUT -s x.x.x.x -j DROP Nun habe ich aktuell folgende iptables-Ausgabe (ich habe mit ">>>>>" Kommentare eingefügt): Chain INPUT (policy DROP) target prot opt source destination >>>>> Hier stehen die durch ddos_deflate gesperrten IPs: DROP all -- xxxxxxxxxxxxxxx.adsl.alicedsl.de anywhere >>>>> Hier stehen die per 2. Skript manuell gesperrten IPs: DROP all -- proxy1.anon-online.org anywhere >>>>> Hier hat sich fail2ban eingeklinkt: fail2ban-proftpd tcp -- anywhere anywhere multiport dports ftp,ftp-data,ftps,ftps-data fail2ban-courierauth tcp -- anywhere anywhere multiport dports smtp,ssmtp,imap2,imap3,imaps,pop3,pop3s fail2ban-apache tcp -- anywhere anywhere multiport dports www,https fail2ban-sasl tcp -- anywhere anywhere multiport dports smtp,ssmtp,imap2,imap3,imaps,pop3,pop3s fail2ban-ssh tcp -- anywhere anywhere multiport dports 58566 fail2ban-couriersmtp tcp -- anywhere anywhere multiport dports smtp,ssmtp fail2ban-ssh-ddos tcp -- anywhere anywhere multiport dports 58566 fail2ban-apache-overflows tcp -- anywhere anywhere multiport dports www,https fail2ban-pam-generic tcp -- anywhere anywhere >>>>> Aus dem 1. Skript (Plesk): ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED REJECT tcp -- anywhere anywhere tcp flags:!FIN,SYN,RST,ACK/SYN reject-with tcp-reset DROP all -- anywhere anywhere state INVALID ACCEPT all -- anywhere anywhere ACCEPT tcp -- anywhere anywhere tcp dpt:8443 ACCEPT tcp -- anywhere anywhere tcp dpt:8880 ACCEPT tcp -- anywhere anywhere tcp dpt:www ACCEPT tcp -- anywhere anywhere tcp dpt:https ACCEPT tcp -- anywhere anywhere tcp dpt:ftp ACCEPT tcp -- anywhere anywhere tcp dpt:ssh ACCEPT tcp -- anywhere anywhere tcp dpt:submission ACCEPT tcp -- anywhere anywhere tcp dpt:smtp ACCEPT tcp -- anywhere anywhere tcp dpt:ssmtp ACCEPT tcp -- anywhere anywhere tcp dpt:pop3 ACCEPT tcp -- anywhere anywhere tcp dpt:pop3s DROP tcp -- anywhere anywhere tcp dpt:imap2 DROP tcp -- anywhere anywhere tcp dpt:imaps DROP tcp -- anywhere anywhere tcp dpt:poppassd ACCEPT tcp -- localhost anywhere tcp dpt:mysql DROP tcp -- anywhere anywhere tcp dpt:mysql DROP tcp -- anywhere anywhere tcp dpt:postgresql DROP tcp -- anywhere anywhere tcp dpt:9008 DROP tcp -- anywhere anywhere tcp dpt:9080 DROP udp -- anywhere anywhere udp dpt:netbios-ns DROP udp -- anywhere anywhere udp dpt:netbios-dgm DROP tcp -- anywhere anywhere tcp dpt:netbios-ssn DROP tcp -- anywhere anywhere tcp dpt:microsoft-ds DROP udp -- anywhere anywhere udp dpt:openvpn DROP udp -- anywhere anywhere udp dpt:domain DROP tcp -- anywhere anywhere tcp dpt:domain ACCEPT icmp -- anywhere anywhere icmp type 8 code 0 ACCEPT all -- anywhere anywhere >>>>> Aus dem 2. Skript (eigenes): ACCEPT icmp -- anywhere anywhere icmp echo-request limit: avg 1/sec burst 5 ACCEPT tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,PSH,ACK,URG/NONE limit: avg 1/hour burst 5 ACCEPT tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,PSH,ACK,URG limit: avg 1/hour burst 5 LOG tcp -- anywhere anywhere tcp flags:!FIN,SYN,RST,ACK/SYN state NEW LOG level warning prefix `Stealth Scan' DROP tcp -- anywhere anywhere tcp flags:!FIN,SYN,RST,ACK/SYN state NEW DROP tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,PSH,ACK,URG/FIN,PSH,URG DROP tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,PSH,ACK,URG DROP tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,ACK,URG DROP tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,PSH,ACK,URG/NONE DROP tcp -- anywhere anywhere tcp flags:SYN,RST/SYN,RST DROP tcp -- anywhere anywhere tcp flags:FIN,SYN/FIN,SYN >>>>> Aus dem Anti-TOR Skript (wird ganz oft wiederholt): TOR_EXIT all -- anywhere anywhere TOR_EXIT all -- anywhere anywhere Chain FORWARD (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED REJECT tcp -- anywhere anywhere tcp flags:!FIN,SYN,RST,ACK/SYN reject-with tcp-reset DROP all -- anywhere anywhere state INVALID ACCEPT all -- anywhere anywhere DROP all -- anywhere anywhere Chain OUTPUT (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED REJECT tcp -- anywhere anywhere tcp flags:!FIN,SYN,RST,ACK/SYN reject-with tcp-reset DROP all -- anywhere anywhere state INVALID ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere Chain TOR_EXIT (269 references) target prot opt source destination RETURN all -- anywhere anywhere Chain fail2ban-apache (1 references) target prot opt source destination RETURN all -- anywhere anywhere Chain fail2ban-apache-noscript (0 references) target prot opt source destination RETURN all -- anywhere anywhere Chain fail2ban-apache-overflows (1 references) target prot opt source destination RETURN all -- anywhere anywhere Chain fail2ban-courierauth (1 references) target prot opt source destination DROP all -- ip-209-172-57-37.static.privatedns.com anywhere DROP all -- ec2-75-101-221-211.compute-1.amazonaws.com anywhere DROP all -- 74.3.243.146.reverse.gogrid.com anywhere DROP all -- mail.justpropertymanagement.com.au anywhere RETURN all -- anywhere anywhere Chain fail2ban-couriersmtp (1 references) target prot opt source destination RETURN all -- anywhere anywhere Chain fail2ban-pam-generic (1 references) target prot opt source destination RETURN all -- anywhere anywhere Chain fail2ban-proftpd (1 references) target prot opt source destination RETURN all -- anywhere anywhere Chain fail2ban-sasl (1 references) target prot opt source destination RETURN all -- anywhere anywhere Chain fail2ban-ssh (1 references) target prot opt source destination RETURN all -- anywhere anywhere Chain fail2ban-ssh-ddos (1 references) target prot opt source destination RETURN all -- anywhere anywhere Chain fail2ban-xinetd-fail (0 references) target prot opt source destination RETURN all -- anywhere anywhere Chain fail2ban-xinetd-fail-log (0 references) target prot opt source destination LOG all -- anywhere anywhere limit: avg 6/min burst 2 LOG level warning prefix `fail2ban-xinetd-fail:DROP ' DROP all -- anywhere anywhere Chain syn-flood (0 references) target prot opt source destination RETURN all -- anywhere anywhere limit: avg 100/sec burst 150 LOG all -- anywhere anywhere LOG level warning prefix `SYN flood: ' DROP all -- anywhere anywhere Nun stellt sich mir die Frage, ob ich in meinem 2. Skript einfach alles auf "-I" statt "-A" setzen kann, damit es funktioniert. Und wie sorge ich dafür, dass die TOR_EXIT-Regeln abgearbeitet werden?
EdwinMosesPray Geschrieben 11. April 2011 Geschrieben 11. April 2011 (bearbeitet) Hallo king555 /sbin/iptables -P INPUT DROP /sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT Grober Fehler.... '-P INPUT DROP' lässt erstmal nichts zu. Punkt. Nun lässt du ALLES durch, was von innen heraus aufgebaut wird. Somit sind ALLE Antwortpakete von innen initiierter Verbindungen von jeglicher weiteren Filterung ausgeschlossen. Diese Zeile gehört ans Ende der Filterung. /sbin/iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT ... /sbin/iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT Ich wundere mich, dass überhaupt neue Verbindungen rausgehen... dann muss ein Fehler woanders sein. /sbin/iptables -A INPUT -m state --state INVALID -j DROP ... /sbin/iptables -A OUTPUT -m state --state INVALID -j DROP ... /sbin/iptables -A FORWARD -m state --state INVALID -j DROP Unnötig... weil du in den -P Policies schon alles geDROPt hast /sbin/iptables -t mangle -P OUTPUT ACCEPT /sbin/iptables -t mangle -P INPUT ACCEPT /sbin/iptables -t mangle -P FORWARD ACCEPT ??? Hier werden die Policies der Tabelle mangle auf ACCEPT gesetzt... ... /sbin/iptables -A INPUT -p udp --dport 137 -j DROP /sbin/iptables -A INPUT -p udp --dport 138 -j DROP /sbin/iptables -A INPUT -p tcp --dport 139 -j DROP /sbin/iptables -A INPUT -p tcp --dport 445 -j DROP ... Siehe oben. Was durch die Policies geDROPt wird, braucht nicht nochmal geDROPt werden. Doppelt gemoppelt. Nach einem '-P INPUT DROP' brauchst du nur noch angeben, was du durchlassen 'ACCEPT' willst. 137, 138, 139 kannst du abkürzen mit --dport 137:139 /sbin/iptables -A INPUT -j ACCEPT /sbin/iptables -A OUTPUT -j ACCEPT Mega Fehler! ALLES, was oben nicht explizit verboten wurde, wird hier dann wieder durchgelassen!!! Deshalb funktionieren auch ausgehende Verbindungen (siehe oben). Setzt '-P INPUT DROP' und '-P OUTPUT DROP' ausser Kraft. Chain INPUT (policy DROP) ... ACCEPT all -- anywhere anywhere Chain OUTPUT (policy DROP) ... ACCEPT all -- anywhere anywhere Würde mir als Admin jetzt schlaflose Nächte bereiten! Die Konfiguration solltest du mal gut überdenken! Gruß Frank M. Bearbeitet 11. April 2011 von EdwinMosesPray
EdwinMosesPray Geschrieben 11. April 2011 Geschrieben 11. April 2011 Eine kleine Hilfe: In welcher Reihenfolge die Tabellen und Ketten abgearbeitet werden wissen sie nun. Wie aber werden Regeln abgearbeitet? Beim Erstellen von Regeln bekommen diese eine fortlaufende Nummer und werden anhand derer nacheinander abgearbeitet. Wenn nun eine Regel zutrifft wird die Verarbeitung in der entsprechenden Kette beendet. Quelle: 64-bit.de/dokumentationen/netzwerk/e/002/DE-IPTABLES-HOWTO-3 Gruß, Frank M.
EdwinMosesPray Geschrieben 11. April 2011 Geschrieben 11. April 2011 Ohne jetzt weitere Hinweise zu haben und ohne Gewähr, würde ich deine Firewall so beginnen: #!/bin/bash ### Alte Tabelle löschen ### iptables -F ### Policy Einstellungen ### iptables -P OUTPUT ACCEPT iptables -P FORWARD DROP iptables -P INPUT DROP ### Localhost ### iptables -A INPUT -i lo -o lo -j ACCEPT ### Grundsaetzliche IP-Bereiche sperren ### iptables -A INPUT -s 46.4.0.0/16 -j DROP iptables -A INPUT -s xxx.xxx.xxx.xxx -j DROP # TOR ### Flooding und andere Flags ### # Info ACK, RST, FIN sind wichtig für die TCPIP Kommunikation !!! # # Ping-Flood begrenzen iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT # ### ### INPUT REGELN ### # # HTTP und HTTPS Proxy durchlassen ipables -A INPUT -p tcp --dport 8443 -j ACCEPT iptables -A INPUT -p tcp --dport 8880 -j ACCEPT # # HTTP und HTTPS durchlassen iptables -A INPUT -p tcp --dport 80 -j ACCEPT iptables -A INPUT -p tcp --dport 443 -j ACCEPT # # FTP und FTP-Data durchlassen iptables -A INPUT -p tcp --dport 20 -j ACCEPT iptables -A INPUT -p tcp --dport 21 -j ACCEPT # # SSH durchlassen iptables -A INPUT -p tcp --dport 22 -j ACCEPT # # Submission [RFC4409] durchlassen iptables -A INPUT -p tcp --dport 587 -j ACCEPT # # SMTP und SMTPs durchlassen iptables -A INPUT -p tcp --dport 25 -j ACCEPT iptables -A INPUT -p tcp --dport 465 -j ACCEPT # # POP3 und POP3s durchlassen iptables -A INPUT -p tcp --dport 110 -j ACCEPT iptables -A INPUT -p tcp --dport 995 -j ACCEPT # # Connection Tracking iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # # Alles was durchfällt, wird geloggt iptables -A INPUT -j LOG --log-prefix "Firewall drop (INPUT): " # ### ### FORWARD REGELN ### # # Connection Tracking iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT # # Alles was durchfällt, wird geloggt iptables -A FORWARD-j LOG --log-prefix "Firewall drop (FORWARD): " # ### ### Forwarding jetzt einschalten ### echo 1 > /proc/sys/net/ipv4/ip_forward ### Tabelle anzeigen ### iptables -L ### Ende ###
Gast King555 Geschrieben 13. April 2011 Geschrieben 13. April 2011 Wow, danke für deine Mühe und deine ausführlichen Postings! Ich werde mir das Ganze am Wochenende mal genauer zu Gemüte führen und mir ein neues Firewallkonzept überlegen. Mich wundert allerdings, dass das vordefinierte Firewallskript von Plesk anscheinend so fehlerhaft bzw. schlecht ist. Es handelt sich dabei ja nicht um irgendein Skript, welches ich irgendwo im Netz gefunden habe, sondern das von meinem System erzeugte Skript aus einer 1300-EUR-Software (auch wenn ein teurer Preis noch kein gutes Produkt macht).
Gast King555 Geschrieben 16. April 2011 Geschrieben 16. April 2011 Ich habe nochmal ein paar Zwischenfragen: Wenn nun eine Regel zutrifft wird die Verarbeitung in der entsprechenden Kette beendet. Ist es dabei egal, ob eine Regel ein ACCEPT oder ein DROP (oder REJECT) angibt? Ist die Kette nach Zutreffen eines Eintrags definitiv beendet? Und was ist denn mit den limit-Befehlen? Da steht doch auch ein ACCEPT hinter. Die Kette dürfte dann aber eigentlich nicht zu Ende sein. Werden die LOG-Befehle immer ausgeführt? Denn die stehen ja NACH den ACCEPTs oder DROPs. Und bezieht sich das LOG immer auf ALLES davor? D.h. wird die Logzeile quasi IMMER ausgeführt? Und wie sorge ich dafür, dass neue (eigene) Chains abgearbeitet werden? Oder werden die sowieso immer alle abgearbeitet? Z.B. meine TOR_EXIT-Chain. Wie mache ich das, dass er die Regeln auch prüft? Es handelt sich dabei wie gesagt um eine dynamische Liste. Daher muss die eine eigene Chain bekommen. Diese wird alle 30 Minuten geleert und neu gefüllt. Und was bedeutet "x references" bei den fail2ban-Chains? Da steht z.B. "Chain fail2ban-apache-noscript (0 references)".
EdwinMosesPray Geschrieben 24. April 2011 Geschrieben 24. April 2011 (bearbeitet) Hallo king555 Ist es dabei egal, ob eine Regel ein ACCEPT oder ein DROP (oder REJECT) angibt? Ist die Kette nach Zutreffen eines Eintrags definitiv beendet? Was soll denn danach noch mit dem Paket passieren? Das Paket wird akzeptiert und durchgelassen (ACCEPT) oder es wird nicht akzeptiert und ignoriert (DROP) oder es wird nicht akzeptiert und der Absender bekommt eine Rückmeldung, dass es nicht akzeptiert wurde (REJECT). Willst du ein nicht akzeptiertes Paket nochmal untersuchen lassen?! Es wird abgelehnt und fertig oder es wird durchgelassen und fertig. Wie beim Türsteher "Du kommst hier net rein". Und was ist denn mit den limit-Befehlen? LIMIT bedeutet, dass BIS zum Limit alles durchgelassen wird. Beim Erreichen des Limits werden die Pakete abgelehnt/verworfen/ignoriert. Wenn du sagst, 1 Ping pro Sekunde ist OK, dann geht auch nur 1 Ping pro Sekunde durch. Kommen zwei oder mehr Pings innerhalb der Sekunde an, werden diese Pakete verworfen/ignoriert. Werden die LOG-Befehle immer ausgeführt? Denn die stehen ja NACH den ACCEPTs oder DROPs. In meinem Beispiel oben werden NUR die Pakete ins Log geschrieben, die durch die Firewall durchfallen. Das heisst, wenn keine Regel greift. Wie ich dir oben auch mal gesagt habe, stell dir bitte ein beliebiges TCP/IP-Paket vor und gehe die Regeln Zeile für Zeile durch: 1 Beispiel (Verbindungsaufbau mit deinem nicht vorhandenen MySQL-Server): eth0: 80.23.117.8 => deine IP => Quellport 15390 => Zielport 3306 => TCP => SYN [COLOR="green"]iptables -A INPUT -i lo -o lo -j ACCEPT[/COLOR] #Paket kommt über eth0 rein [COLOR="green"]iptables -A INPUT -s 46.4.0.0/16 -j DROP[/COLOR] #Paket fängt nicht mit 46.4.x.x an [COLOR="green"]iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT[/COLOR] #Paket ist kein Ping [COLOR="green"]ipables -A INPUT -p tcp --dport 8443 -j ACCEPT[/COLOR] #Zielport ist nicht 8443 [COLOR="green"]iptables -A INPUT -p tcp --dport 8880 -j ACCEPT[/COLOR] #Zielport ist nicht 8880 [COLOR="green"]iptables -A INPUT -p tcp --dport 80 -j ACCEPT[/COLOR] #Zielport ist nicht 80 [COLOR="green"]iptables -A INPUT -p tcp --dport 443 -j ACCEPT[/COLOR] #Zielport ist nicht 443 [COLOR="green"]iptables -A INPUT -p tcp --dport 20 -j ACCEPT[/COLOR] #Zielport ist nicht 20 [COLOR="green"]iptables -A INPUT -p tcp --dport 21 -j ACCEPT[/COLOR] #Zielport ist nicht 21 [COLOR="green"]iptables -A INPUT -p tcp --dport 22 -j ACCEPT[/COLOR] #Zielport ist nicht 22 [COLOR="green"]iptables -A INPUT -p tcp --dport 587 -j ACCEPT[/COLOR] #Zielport ist nicht 587 [COLOR="green"]iptables -A INPUT -p tcp --dport 25 -j ACCEPT[/COLOR] #Zielport ist nicht 25 [COLOR="green"]iptables -A INPUT -p tcp --dport 465 -j ACCEPT[/COLOR] #Zielport ist nicht 465 [COLOR="green"]iptables -A INPUT -p tcp --dport 110 -j ACCEPT[/COLOR] #Zielport ist nicht 110 [COLOR="green"]iptables -A INPUT -p tcp --dport 995 -j ACCEPT[/COLOR] #Zielport ist nicht 995 [COLOR="green"]iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT[/COLOR] #Paket ist keine Antwort auf ein ausgehendes Paket [COLOR="red"][B]iptables -A INPUT -j LOG --log-prefix "Firewall drop (INPUT): "[/B][/COLOR] #Paket wird geloggt [B]Ich bin mir nicht sicher, ob bei -j LOG die Verarbeitung endet !!!![/B] 2. Beispiel (Verbindungsaufbau mit deiner Webseite): eth0: 80.23.117.8 => deine IP => Quellport 15390 => Zielport 80 => TCP => SYN [COLOR="green"]iptables -A INPUT -i lo -o lo -j ACCEPT[/COLOR] #Paket kommt über eth0 rein [COLOR="green"]iptables -A INPUT -s 46.4.0.0/16 -j DROP[/COLOR] #Paket fängt nicht mit 46.4.x.x an [COLOR="green"]iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT[/COLOR] #Paket ist kein Ping [COLOR="green"]ipables -A INPUT -p tcp --dport 8443 -j ACCEPT[/COLOR] #Zielport ist nicht 8443 [COLOR="green"]iptables -A INPUT -p tcp --dport 8880 -j ACCEPT[/COLOR] #Zielport ist nicht 8880 [COLOR="red"][B]iptables -A INPUT -p tcp --dport 80 -j ACCEPT[/B][/COLOR] #Zielport ist 80 Hier endet der Durchlauf, das Paket wird zum Webserver durchgelassen ALLE ankommenden Pakete, die die Regeln durchlaufen und NICHT zutreffen, werden geloggd. Ich bin mir nicht sicher, ob nach einem -j LOG die Verarbeitung endet! Vermutlich nicht! Und wie sorge ich dafür, dass neue (eigene) Chains abgearbeitet werden? Mit dem Schalter -I (Insert) werden Regeln zu deinen bestehenden Firewall-Regeln hinzugefügt. Diese werden meines Wissens on the fly der Tabelle angefügt und dann wie gewohnt durchlaufen. Es handelt sich dabei wie gesagt um eine dynamische Liste. Daher muss die eine eigene Chain bekommen. Diese wird alle 30 Minuten geleert und neu gefüllt. Ich würde die Chain on the fly mit mit dem 30 Minuten Script erstellen. Vorher die 'alten' Daten mit -D löschen! Vielleicht funktioniert zum Löschen auch ein -D THOR_EXIT THOR-Script: iptables -D THOR_EXIT iptables -N THOR_EXIT iptables -I ...... iptables -I ...... Und was bedeutet "x references" bei den fail2ban-Chains? Mit fail2ban hatte ich bisher keinen Kontakt. Tut mir leid. Ich hoffe, ich konnte etwas helfen Frohe Ostern, Frank M. Bearbeitet 24. April 2011 von EdwinMosesPray
EdwinMosesPray Geschrieben 24. April 2011 Geschrieben 24. April 2011 (bearbeitet) Es handelt sich dabei wie gesagt um eine dynamische Liste. Daher muss die eine eigene Chain bekommen. Diese wird alle 30 Minuten geleert und neu gefüllt. Ich habe das gerade an meinem eigenen Linux-Server getestet. Folgendes habe ich heraus gefunden: > Du kannst 'iptables -N THOR_EXIT' in dein normales Script reinschreiben. Damit erstellst du die Chain. > In dein 30min Script schreibst du als Erstes 'iptables -F THOR_EXIT'. Das löscht alle Einträge der Chain > Dann fügst du die neuen Regeln mit 'iptables -I THOR_EXIT ..... -j DROP' ein. Ich hoffe das klappt automatisch Chain fail2ban-apache-noscript (0 references) Die Chain 'fail2ban-apache-noscript' hat 0 Einträge (Regeln ala INPUT .... -j DROP). Gruß, Frank M. Bearbeitet 24. April 2011 von EdwinMosesPray
Gast King555 Geschrieben 25. April 2011 Geschrieben 25. April 2011 Vielen Dank! Ich denke, jetzt müsste ich es hinbekommen.
Empfohlene Beiträge
Erstelle ein Benutzerkonto oder melde Dich an, um zu kommentieren
Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können
Benutzerkonto erstellen
Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!
Neues Benutzerkonto erstellenAnmelden
Du hast bereits ein Benutzerkonto? Melde Dich hier an.
Jetzt anmelden