iptables / https: Roteador obtendo tráfego INPUT originado na porta 443

Question

Acho uma pergunta sobre nginx / https, mas pode ser sobre iptables (também) caso eu esteja interpretando mal as coisas.

Eu configurei recentemente um firewall no meu roteador entre o meu servidor web (nginx) e a internet. O Nginx está configurado para escutar nas portas 80 e 443 e redireciona a maioria das 80 chamadas para 443, usando um certificado para criptografar. Com o encaminhamento adequado no lugar tudo funciona muito bem - pelo menos eu não encontrei quaisquer falhas ainda.

O firewall (tabela de filtros iptables) é definido como ACCEPT policy, mas quando um pacote atinge o final da corrente INPUT , ele encaminha para uma cadeia LOGDROP que, bem, registra e descarta.

Percorrendo os logs, encontrei pacotes descartados originados da porta 443 no servidor direcionado ao roteador. Exemplo (endereços MAC e IP randomizados, .136 é servidor, .122 é roteador):

Oct 10 05:18:47 ASUS user.warn kernel: IPTables-Dropped: IN=br0 OUT= MAC=3C:AE:78:D4:B1:E3 SRC=192.168.1.136 DST=192.168.1.122 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=10743 DF PROTO=TCP SPT=443 DPT=33272 WINDOW=0 RES=0x00 RST URGP=0

Estas tentativas aparecem semiformalmente (1-3 tentativas a cada dez minutos) ao longo de uma noite após a qual eles se esgotaram.

Assumindo que eu interpreto o log corretamente, o servidor está contatando o roteador diretamente da porta https - o que não faz sentido porque por que um roteador precisaria de conteúdo da web, criptografado ou não criptografado? E aparentemente conseguindo sem ter pedido?

Suponho que as solicitações externas de conteúdo https ultrapassem a cadeia FORWARD nos dois sentidos e, portanto, não sejam exibidas aqui. Como eu disse AFAICT todos os pedidos de https para o servidor são respondidos como deveriam.

Minha pergunta é:

Qual é a explicação provável para esses pacotes? Um servidor estranho que faz com que o nginx envie pacotes onde nenhum pacote é solicitado? Ou está recebendo solicitações de algum lugar que faz com que ele responda à máquina errada?

    

Answer 1

A mensagem de log de exemplo que você forneceu é um pacote RST , que geralmente é enviado pelo kernel quando não há nada escutando na porta de destino.

Oct 10 05:18:47 ASUS user.warn kernel: IPTables-Dropped:
    IN=br0 OUT= MAC=3C:AE:78:D4:B1:E3 SRC=192.168.1.136 DST=192.168.1.122
    LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=10743 DF PROTO=TCP SPT=443 DPT=33272
    WINDOW=0 RES=0x00 RST URGP=0

Especificamente aqui, terá havido um pedido anterior de 192.168.1.122 a 192.168.1.136:443 que foi rejeitado pelo servidor 192.168.1.136 porque nada estava - naquele momento - escutando na porta 443. (Ou há um firewall em 192.168.1.136 com uma regra REJECT para essa combinação endereço / porta. Neste nível não podemos diferenciar.)

Infelizmente, isso não explica por que o seu roteador .122 deveria estar tentando se comunicar com o nginx em .136, mas isso pode ajudá-lo a interpretar a mensagem do arquivo de log mais facilmente.