Início / computer / Perguntas / 1794063
Accepted
denn0n
Asked: 2023-07-06 05:15:34 +0800 CST

Iptables falha ao bloquear a entrada de um ip específico

  • 772

Olá, tenho um servidor online que uso como gateway e o iptables está agindo de forma estranha

-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

mas 173.230.154.149 ainda pode chegar ao servidor apache em 80 ou 443, não deve ser bloqueado por

-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

e

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

Sim, é um servidor online que direciona todos os serviços da web para um servidor pessoal maior por meio de um vpn com openvpn

tudo funciona como esperado apenas não consigo bloquear a conexão de entrada de certo ip bruxa obviamente está atacando o servidor

a tipologia da rede é

Ip Externo 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
networking

1 respostas

  1. Best Answer

    Um pacote sendo roteado em vez de recebido por um processo local atravessa a cadeia filtro/FORWARD e não a cadeia filtro/INPUT, mesmo que isso seja causado pelo uso de NAT. Portanto, as regras de bloqueio atuais em filter/INPUT não têm efeito. Estas regras:

    -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

    deve ser simplesmente substituído por:

    -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

    Obviamente, eles devem ser adicionados antes das regras de acesso ao servidor web para que tenham algum efeito. Portanto, adicione-os pelo menos antes destes:

    -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

    Porque uma vez que a conexão inicial é aceita, todos os pacotes seguintes serão curto-circuitados por esta regra:

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

    Portanto, eles devem ser bloqueados na primeira vez que forem vistos.

    Observações adicionais:

    • regras redundantes

      -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 1ª regra acima, e também a 2ª regra, cada uma delas separadamente, tornam a 3ª regra redundante.

      Da mesma maneira:

      -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 primeira regra torna as duas seguintes redundantes.

      Mas tudo isso pode ter sido para testar o problema atual.

    • a menos que esteja executando um kernel muito recente (onde o problema foi corrigido), nenhuma regra REJECT deve ter permissão para rejeitar um pacote no estado INVALID. Tal pacote deve ser "apenas" DROP-ed, ou raras falhas aleatórias de conexão de tráfego legítimo podem acontecer.

      Isso agora está documentado em iptables-extensions(8):

      Aviso: Você não deve aplicar indiscriminadamente o alvo REJECT a pacotes cujo estado de conexão seja classificado como INVÁLIDO; em vez disso, você deve apenas DROP estes.

      (A página do manual fornece mais justificativas.)

      Então, normalmente,

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

      deve ser seguido por:

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

relate perguntas