Durante os últimos dias eu li muito sobre o PF como uma boa alternativa ao iptables e uma maneira muito melhor e segura de filtragem. No entanto, deparei-me com a seguinte declaração, que pensei que poderia ser um problema de segurança:
Keeping State for UDP: One will sometimes hear it said that, "One can not create state with UDP as UDP is a stateless protocol!" While it is true that a UDP communication session does not have any concept of state (an explicit start and stop of communications), this does not have any impact on PF's ability to create state for a UDP session. In the case of protocols without "start" and "end" packets, PF simply keeps track of how long it has been since a matching packet has gone through. If the timeout is reached, the state is cleared. The timeout values can be set in the options section of the pf.conf file.
Minhas preocupações: O UDP não possui SequenceNr. Então, se um atacante interceptar um fluxo UDP (que já recebeu um estado na tabela de estados do pf) ele poderia facilmente injetar pacotes falsificados que passarão pelo firewall, não?
Isso não é um grande problema de segurança? Ou eu entendi mal algo no mecanismo do pf?
Qualquer outro firewall terá o mesmo problema que o PF, pois todos eles precisam manter algum tipo de 'estado' para permitir que os pacotes voltem para um dispositivo atrás de um NAT ou outro tipo de bloco de entrada que permita respostas, mas pára novos pacotes.
Caso 1: um cliente UDP dentro do firewall inicia a comunicação com um servidor UDP. O firewall cria uma entrada de mapeamento para permitir que a conversa continue. O invasor aproveita isso para falsificar alguns pacotes na direção inversa.
Em primeiro lugar, os pacotes precisam ser falsificados para parecer que estão vindo do servidor, caso contrário, eles não corresponderão ao endereço remoto. Eles também precisam ser direcionados para a porta IP e UDP do cliente, caso contrário, eles não passarão pelo firewall. Então, esses pacotes falsificados chegam ao cliente, que pensa que eles estão vindo do servidor: eles são recebidos pelo aplicativo cliente, mesmo que seu soquete de datagrama esteja marcado como conectado ao servidor. Se o aplicativo é escrito com segurança, eles acabam sendo lançados em seu nível de protocolo interno porque não passam nas verificações de integridade (criptografia e somas de verificação). Os datagramas falsificados do UDP causarão estragos em aplicativos inerentemente inseguros, é claro; isso não é culpa do firewall.
Caso 2: o servidor UDP dentro do firewall tem uma porta permanente para a frente. Claro que qualquer um pode enviar UDP para isso; basta validar os pacotes e suportar apenas sessões autenticadas e seguras.
Não é um risco significativo no cenário que você descreve.
Um invasor capaz de espionar o tráfego UDP já está em uma posição muito privilegiada. Na verdade, não é particularmente relevante que uma conexão seja ou não listada em uma tabela de controle de conexão.
Da perspectiva da rede, um invasor normalmente deseja a) observar o tráfego e os dados indo e voltando do host eb) modificando alguns deles para atender a uma finalidade específica. Em seguida, dependendo do objetivo, as informações podem ser usadas para representar o host ou uma entidade, tentar comprometer o host, atacar outros hosts, etc.