☰

Iptables не может заблокировать входящие соединения с определенного IP-адреса

tag-icon • tag-icon networking iptables tcp centos-7
Iptables не может заблокировать входящие соединения с определенного IP-адреса

Привет, у меня есть онлайн-сервер, который я использую как шлюз, и iptables ведет себя странно.

-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

но 173.230.154.149 все еще может получить доступ к серверу Apache в 80 или 443, он не должен быть заблокирован

-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 BLOCK_CHAIN -s 173.230.154.149/32 -j REJECT --reject-with icmp-host-prohibited

Да, это онлайн-сервер, который направляет все веб-сервисы на персональный более крупный сервер через VPN с OpenVPN.

все работает как и ожидалось, просто я не могу заблокировать входящие соединения с определенных IP, которые, очевидно, атакуют сервер

типология сети - это

Внешний 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

решение1

Пакет, маршрутизируемый, а не принимаемый локальным процессом, проходит через цепочку filter/FORWARD, а не через цепочку filter/INPUT, даже если это вызвано использованием NAT. Поэтому текущие правила блокировки в filter/INPUT не действуют. Эти правила:

-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 -i eth0 -p tcp -m tcp --dport 443 -j BLOCK_CHAIN
-A FORWARD -i eth0 -p tcp -m tcp --dport 80 -j BLOCK_CHAIN

Очевидно, их следует добавлять перед правилами, разрешающими доступ к веб-серверу, чтобы они могли иметь какой-либо эффект. Поэтому добавьте их хотя бы перед этими:

-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 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Поэтому их необходимо блокировать при первом появлении.

Дополнительные замечания:

  • избыточные правила

    -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+ -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

    Первое правило делает два последующих излишними.

    Но все это могло быть сделано для проверки текущей проблемы.

  • Если только не запущено самое последнее ядро ​​(где проблема исправлена), никакое правило REJECT не должно отклонять пакет в состоянии INVALID. Такой пакет должен быть "только" ОТБРАСЫВАТЬСЯ, иначе могут произойти редкие случайные сбои соединения легитимного трафика.

    Теперь это задокументировано вiptables-extensions(8):

    Предупреждение: не следует без разбора применять цель REJECT к пакетам, состояние соединения которых классифицируется как INVALID; вместо этого следует только ОТБРАСЫВАТЬ их.

    (Далее на странице руководства приводится дополнительное обоснование.)

    Так что обычно,

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

    должно следовать:

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

Связанный контент