Estou vendo várias das duas linhas a seguir nos meus logs do dmesg¹:
[602956.308844] [iptables] (10): IN=eno1 OUT=eno2 MAC=xx:yy:..:zz SRC=10.174.26.245 DST=192.168.22.59 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=53 DPT=47150 WINDOW=28960 RES=0x00 ACK SYN URGP=0
[602956.652575] [iptables] (10): IN=eno1 OUT=eno2 MAC=xx:yy:..:zz SRC=10.172.0.22 DST=192.168.22.59 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=53 DPT=44204 WINDOW=28960 RES=0x00 ACK SYN URGP=0
Meu firewall os bloqueia porque não reconhece os endereços IP 10.172.0.22 e 10.174.26.245.
Na verdade, olhando as listas de endereços IP eno1 e eno2, esses dois não estão incluídos. Eu tenho dois 10.xxx que uso, mas não os dois listados acima (daí o firewall bloqueando esses dois).
Minha rede se parece com isso:
+----------+ +--------+ +--------+ +--------+
| Internet |<--->| Router |<--->| Server |<--->| Laptop |
+----------+ +--------+ +--------+ +--------+
Tanto o servidor quanto o laptop possuem firewalls. O laptop está conectado em 192.168.22.59. Nenhum desses pacotes UDP TCP é enviado a ele.
O eno1 e o eno2 estão no servidor. O eno1 se conecta ao roteador, que se conecta à internet. A conexão do roteador usa endereços de rede local (IPv4 e IPv6). O eno2 é minha rede local (LAN). O servidor está configurado para ENCAMINHAR tráfego entre o laptop e a internet.
O laptop usa uma VPN e suspeito que possa vir dela, mas o laptop também tem um firewall e, portanto, ignoraria esse tráfego. O que me pergunto é de onde esses pacotes estão vindo? Seria de um sistema local ou de algum hacker? Ou a VPN poderia ser a culpada? De qualquer forma, não entendo como um pacote UDP TCP pode estar usando um endereço IP que não está presente em uma interface de rede e, se for local, não vejo como poderia vir de fora. Existe uma maneira de descobrir quem envia esses pacotes, supondo que seja um processo local?
Observação: Tenho o libvirt instalado, mas tentei interromper a VPN que estou usando e não adiantou. Além disso, as duas pontes que ele cria não usam os endereços IP 10.17[24].xx. Além disso, não consigo imaginar nenhum motivo para a VPN enviar pacotes UDP TCP para a máquina errada.
Atualizar
Então, fui até meu laptop e reconectei a VPN. Depois disso, as duas linhas acima pararam de aparecer.
Isso me permitiu ver outra linha:
[608974.298853] [iptables] (192): IN=eno1np0 OUT=eno2np1 MAC=xx:yy:...:zz SRC=192.168.19.2 DST=192.168.22.189 LEN=151 TOS=0x00 PREC=0x00 TTL=63 ID=8281 DF PROTO=UDP SPT=53 DPT=47512 LEN=131
Este é UDP, mas a questão é que, assim como no laptop, ele precisa de dados do que parece ser um IP local que vem do roteador (portanto, da internet). O dispositivo 189 é minha impressora HP, então talvez ela também tenha um sistema semelhante a uma VPN e falhe em solicitações de DNS de vez em quando dessa maneira.
Resolução
Na verdade, eu consegui ver esses dois IPs na tabela de rotas, o que você pode fazer assim:
$ ip route
Isso significa que meu gráfico seria mais ou menos assim:
+----------+ +-----+ +--------+ +--------+ +--------+
| Internet |<--->| VPN |<--->| Router |<--->| Server |<--->| Laptop |
+----------+ +-----+ +--------+ +--------+ +--------+
Claro, como mencionado pela telcoM, também há o ISP entre o roteador e a VPN, mas ele não é o culpado. Agora, eu DESCARTO esses pacotes sem registrá-los primeiro:
-A bad_tcp_packets -i eno1 -s 10.172.0.0/16 -j DROP
-A bad_tcp_packets -i eno1 -s 10.174.0.0/16 -j DROP
Um ponto a ser observado: isso significa que usar uma VPN pode abrir um conjunto de IPs locais do outro lado. Portanto, você precisa ficar atento a isso, pois isso pode afetar a configuração da sua LAN.
¹ Configurei meu firewall para registrar esses acessos para garantir que eu possa ver esses problemas. No momento, não estou tentando evitar o registro, mas sim entendê-lo.
Ambas as mensagens de log que você listou têm
PROTO=TCP SPT=53eACK SYN URGP=0.Portanto, o protocolo é TCP, não UDP. Embora eu não fique muito surpreso se cada um deles vier após uma troca de dois pacotes UDP entre o laptop e um dos IPs misteriosos, respectivamente.
SYN+ACK indica que esses pacotes são a segunda etapa do handshake triplo inicial do TCP: o cliente envia um SYN, o servidor responde com SYN+ACK, o cliente confirma com um ACK e, assim, uma conexão TCP é estabelecida.
Como o pacote SYN+ACK é uma resposta do servidor , sua porta de origem é a mesma que a porta de destino do pacote SYN original e
SPT=53indica que o número da porta é 53.O serviço conhecido na porta 53 (tanto UDP quanto TCP) é... DNS. Portanto, 10.174.0.22 e 10.174.26.245 são provavelmente os servidores de resolução de DNS do seu provedor de serviços de internet e, como endereços IPv4 roteáveis publicamente são cada vez mais valiosos, o provedor parece ter movido seus servidores de resolução de DNS de uso do cliente para um segmento IP 10.xxx, porque os servidores de resolução de DNS não precisam ser públicos: apenas os próprios clientes do provedor precisarão acessá-los. Isso é diferente dos servidores DNS autoritativos , que devem ser públicos para que outros servidores de resolução de DNS no mundo todo possam acessá-los.
Então sua rede é na verdade mais como:
Os dois endereços IP misteriosos estariam em algum lugar dentro da caixa "infraestrutura do ISP".
Um cliente DNS simples enviaria inicialmente uma consulta DNS como um pacote UDP. O servidor DNS responderia com um UDP, mas se a resposta completa não couber em um único pacote UDP (por exemplo, porque o cliente está tentando resolver um nome pertencente a um serviço de nuvem com muitos endereços IP), a resposta UDP de pacote único do servidor de resolução de DNS conterá um sinalizador que basicamente diz "este é apenas o começo da resposta completa; pergunte novamente por TCP se precisar do restante". O servidor de resolução armazenará a resposta em cache, portanto, se o cliente se reconectar por TCP, poderá reenviá-la facilmente, usando quantos pacotes TCP forem necessários para o resultado completo da consulta.
Mas se esses IPs misteriosos não corresponderem aos servidores de resolução de DNS do seu ISP, pode ser que o seu ISP (ou talvez uma VPN que você esteja usando) esteja fazendo um trabalho ruim ao isolar as redes privadas dos seus clientes umas das outras, e você terá "ruído de fundo da Internet" (vazamentos das redes privadas de outros clientes do seu ISP, varreduras de portas e talvez até tentativas de ataque tentando fingir que estão vindo da sua rede privada para que o seu firewall não as bloqueie).
Se for esse o caso, você deve configurar cuidadosamente seu servidor para encaminhar apenas o tráfego necessário, e nada mais. Você também deve verificar se consegue configurar filtros de tráfego no seu roteador: se for o caso, filtre qualquer tráfego que use os endereços da sua rede interna como IP de origem, mas vindo do lado esquerdo do roteador. Você também pode bloquear quaisquer outros intervalos de IP privados no roteador, da esquerda para a direita, permitindo apenas aqueles que são usados legitimamente pelo seu provedor de internet (se houver).
Supondo que você use uma máscara de rede /24 em sua rede:
Você também deve usar o rastreamento de conexão para permitir que o servidor aceite automaticamente respostas legítimas a conexões iniciadas da direita para a esquerda. Isso permitirá que você seja muito mais rigoroso na escolha do que seu servidor deve encaminhar da esquerda para a direita.
Quando você ativa um túnel VPN no laptop, ele normalmente bloqueia conexões não criptografadas de/para todos os lugares, exceto o servidor do túnel VPN (a menos que exceções sejam configuradas para sua rede local) e roteia tudo pelo túnel VPN, então, em vez do "ruído de fundo da Internet" do seu ISP, o laptop verá o ruído de fundo da Internet do ponto de saída da VPN.
Se você configurou a VPN no seu laptop para permitir conexões com a sua rede local enquanto a VPN estiver ativa, e a conexão VPN não estiver suficientemente protegida por firewall, você poderá receber tráfego não solicitado através da VPN para a sua rede local, onde eles podem encontrar a capacidade de encaminhamento do seu servidor e (se não for suficientemente restrita) usá-la para acessar a VPN e retornar pela sua conexão normal de internet, efetivamente usando sua conexão VPN ao contrário para ocultar o que estão fazendo. É do seu interesse garantir que isso não aconteça.