Eu tenho uma rede secundária do meu roteador ER605, isso é usado para que o dispositivo conectado, um raspberry pi, possa ser isolado. Eu o uso para colocar em quarentena e digitalizar arquivos recebidos de fontes duvidosas (como meus sogros computadores perpetuamente afetados por malware). Preciso acessar o pi e exfiltrar arquivos digitalizados para minha rede principal. Pretendo usar o VNC para acesso e colocar arquivos ok'd diretamente no meu QNAP NAS via compartilhamento SMB.
A regra 5 da ACL bloqueia a comunicação da rede de quarentena para minha rede principal. Para obter o VNC para meu pi de quarentena da minha rede principal, inicialmente adicionei a regra 4, que era insuficiente (a leitura on-line sugeria que eu precisava de uma ACL para mensagens de retorno), então adicionei uma versão da regra 3 que fazia referência ao serviço VNC e que ainda falhou. Por capricho, tentei criar a definição de serviço VNC_duplex que troca a porta de origem e destino e alterar a regra nº 3 do serviço VNC para o duplex VNC, e viola VNC funcionou!
Estou muito feliz por isso estar funcionando, mas não tenho certeza do motivo ou se é seguro. Estou correto ao entender que a regra 3 da ACL permite que um script malicioso envie uma mensagem de qualquer porta no raspberry pi para a porta 5900 em qualquer dispositivo da minha rede principal? Qual é a maneira semântica de entender isso e poderia ser mais seguro?
Minha rede e VLANS:
Também configurei alguns intervalos de IP para descrever as áreas da minha rede às quais desejo segmentar/conceder acesso:
Meus tipos de serviço (os últimos quatro são personalizados por mim):
E finalmente meu ACL:
Quando o Pi envia respostas para o seu computador, o Pi é a fonte.
Não é apenas que os pacotes de 'retorno' tenham o endereço IP do Pi como o "IP de origem" - eles também têm o número da porta correspondente no lado do Pi como a "porta de origem".
Todos os modelos de serviço originais em seu firewall são definidos apenas para a direção "para frente"; por exemplo, o modelo "VNC" corresponde a 5900 como a porta de destino – que, conforme explicado, corresponde apenas a pacotes que têm o servidor VNC como destino, mas não aos pacotes de 'retorno'.
Não. O que ele permite é o oposto – permite que um script envie uma mensagem da porta 5900 no raspberry pi para qualquer porta da sua rede primária. (O 'Source' em "Source Port = 5900" realmente significa a origem dos pacotes.)
Como a porta de origem de uma conexão pode ser escolhida arbitrariamente (se desejado), isso significa que a rede primária está aberta a qualquer pessoa que saiba da existência dessa exceção; tudo o que eles precisam fazer é pedir ao sistema operacional para vincular uma conexão à porta local 5900. (Mas, por outro lado, como a porta de origem geralmente é aleatória e o intervalo começa bem além de 5900, qualquer pessoa que não saiba sobre essa exceção é improvável que o descubra por acidente.)
"Fonte" realmente significa a fonte do pacote individual , não de toda a conexão. (Na verdade, a porta quase poderia ser considerada parte do endereço da "camada de transporte" do pacote e, de fato, em vários outros protocolos não-IP, ela era literalmente parte do endereço.)
Cada porta está associada a um endpoint específico, da mesma forma que cada endereço IP está associado a um endpoint específico – se você fizer uma conexão com o Pi, não espera que um pacote de 'retorno' do Pi ainda apareça o endereço IP do Pi como um "destino" e o mesmo se aplica aos números das portas.
A abordagem usual é evitar totalmente tais ACLs reflexivas e usar um firewall dinâmico . A maioria dos roteadores é capaz de rastrear conexões ativas ("estados" ou "fluxos") – eles meio que precisam fazer isso se implementarem o típico 1:muitos NAT – e o filtro do firewall pode ter uma regra especial que permite qualquer pacote correspondente para uma conexão "estabelecida" (como em iptables/nftables), ou permitir tais pacotes implicitamente (como em pf).
Parece que o ER603 ganhou suporte para ACLs com estado no firmware 2.1 . (As pessoas parecem estar dizendo que não funciona, no entanto.)
Se você precisar usar ACLs sem estado, a abordagem alternativa é permitir apenas pacotes de 'retorno' que tenham o sinalizador TCP "ACK" definido. O pacote inicial de uma conexão TCP nunca tem esse sinalizador definido, enquanto todos os outros pacotes têm; basta ter uma única regra que permita pacotes TCP ACK em qualquer porta.
Naturalmente, essa abordagem funciona apenas para TCP – você não pode fazer muito sobre UDP sem rastreamento de estado, exceto esperar que ninguém descubra o buraco que sua ACL reflexiva faz.
Você também deve ter outra regra que permita pacotes de 'retorno' ICMP também (por exemplo, resposta de eco e as várias mensagens de 'erro' ICMP - no mínimo "Fragmentação necessária" precisa ser permitida, mas preferencialmente outros erros como "Inalcançável" devem ser permitido também).