☰

Iptables kann eingehenden Datenverkehr von einer bestimmten IP nicht blockieren

tag-icon • tag-icon networking iptables tcp centos-7
Iptables kann eingehenden Datenverkehr von einer bestimmten IP nicht blockieren

Hallo, ich habe einen Online-Server, den ich als Gateway verwende, und iptables verhält sich seltsam

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 443 -j BLOCK_CHAIN
-A INPUT -i eth0 -p tcp -m tcp --dport 80 -j BLOCK_CHAIN
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i tun+ -j ACCEPT
-A FORWARD -i tun+ -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o tun+ -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -i eth0 -o tun+ -p tcp -m tcp --dport 80 --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -i eth0 -o tun+ -p tcp -m tcp --dport 443 --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A BLOCK_CHAIN -s 173.230.154.149/32 -j REJECT --reject-with icmp-host-prohibited
-A BLOCK_CHAIN -m state --state NEW -j ACCEPT

aber 173.230.154.149 kann immer noch auf den Apache-Server in 80 oder 443 zugreifen, es sollte nicht blockiert werden durch

-A INPUT -i eth0 -p tcp -m tcp --dport 443 -j BLOCK_CHAIN
-A INPUT -i eth0 -p tcp -m tcp --dport 80 -j BLOCK_CHAIN

Und

-A BLOCK_CHAIN -s 173.230.154.149/32 -j REJECT --reject-with icmp-host-prohibited

Ja, es ist ein Online-Server, der alle Webdienste über ein VPN mit OpenVPN an einen größeren privaten Server weiterleitet.

alles funktioniert wie erwartet, ich kann nur eingehende Verbindungen von bestimmten IP-Adressen nicht blockieren, die offensichtlich den Server angreifen

Die Typologie des Netzwerks ist

Externe IP XX.XX.X.XX VPN 10.0.0.0/24

-A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.0.0.100
-A PREROUTING -i eth0 -p tcp -m tcp --dport 443 -j DNAT --to-destination 10.0.0.100

Antwort1

Ein Paket, das von einem lokalen Prozess geroutet und nicht empfangen wird, durchläuft die Filter/FORWARD-Kette und nicht die Filter/INPUT-Kette, selbst wenn dies durch die Verwendung von NAT verursacht wird. Daher haben die aktuellen Sperrregeln in Filter/INPUT keine Wirkung. Diese Regeln:

-A INPUT -i eth0 -p tcp -m tcp --dport 443 -j BLOCK_CHAIN
-A INPUT -i eth0 -p tcp -m tcp --dport 80 -j BLOCK_CHAIN

sollte einfach ersetzt werden durch:

-A FORWARD -i eth0 -p tcp -m tcp --dport 443 -j BLOCK_CHAIN
-A FORWARD -i eth0 -p tcp -m tcp --dport 80 -j BLOCK_CHAIN

Damit sie überhaupt Wirkung zeigen, sollten sie natürlich vor den Regeln hinzugefügt werden, die den Zugriff auf den Webserver erlauben. Fügen Sie sie also mindestens vor diesen hinzu:

-A FORWARD -i eth0 -o tun+ -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -i eth0 -o tun+ -p tcp -m tcp --dport 80 --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -i eth0 -o tun+ -p tcp -m tcp --dport 443 --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j ACCEPT

Denn sobald die erste Verbindung akzeptiert wurde, werden alle weiteren Pakete durch diese Regel kurzgeschlossen:

-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Sie müssen daher beim ersten Auftauchen blockiert werden.

Zusätzliche Bemerkungen:

  • überflüssige Regeln

    -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i tun+ -j ACCEPT
-A FORWARD -i tun+ -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT

    Sowohl die 1. Regel oben als auch die 2. Regel, jeweils für sich betrachtet, machen die 3. Regel überflüssig.

    Ebenfalls:

    -A FORWARD -i eth0 -o tun+ -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -i eth0 -o tun+ -p tcp -m tcp --dport 80 --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -i eth0 -o tun+ -p tcp -m tcp --dport 443 --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j ACCEPT

    Die erste Regel macht die beiden folgenden überflüssig.

    Aber das alles diente möglicherweise nur dem Testen des aktuellen Problems.

  • Sofern kein sehr aktueller Kernel verwendet wird (bei dem das Problem behoben ist), sollte es keiner REJECT-Regel erlaubt sein, ein Paket im Status INVALID abzulehnen. Ein solches Paket sollte „nur“ DROP-ed werden, da es sonst zu seltenen zufälligen Verbindungsfehlern bei legitimem Datenverkehr kommen kann.

    Dies ist nun dokumentiert iniptables-extensions(8):

    Achtung: Sie sollten das REJECT-Ziel nicht wahllos auf Pakete anwenden, deren Verbindungsstatus als INVALID klassifiziert ist; stattdessen sollten Sie diese nur DROPEN.

    (Die Manpage liefert dann weitere Begründungen.)

    Normalerweise

    -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

    sollte gefolgt werden von:

    -A FORWARD -m conntrack --ctstate INVALID -j DROP

verwandte Informationen