Para alguns fins particulares, preciso enriquecer o cabeçalho HTTP com informações adicionais (que serão tratadas pelo aplicativo no lado do servidor HTTP). A ideia básica era modificar o pacote recebido, enviá-lo ao destino e nunca se preocupar com a resposta. O esquema muito simplificado de caminhos de tráfego é
+---+ +------+ +---+
| +<<-----o MDFY +<<------o |
| R | +------+ | S |
| C | | N |
| V | | D |
| o--------------------->>+ |
+---+ +---+
O problema vem com números TCP SEQ/ACK. Após o handshake TCP, o Remetente envia um pacote de 4 bytes de comprimento, que chega ao Modificador onde o comprimento muda para 22, então o pacote chega ao Receptor e envia o número ACK +23, enquanto o Remetente espera +5. Isso surpreende o remetente e a sessão fica sem sincronização. Vejo isso quando, por exemplo, tento o netcat para teste - para pacotes não modificados, a sessão fecha imediatamente após a troca de dados, enquanto para pacotes modificados a sessão fica obsoleta por um longo tempo (na verdade, eu paro pressionando Ctrl-C).
Não vejo uma maneira fácil de lidar com esta situação. Parece que, uma vez modificada no meio, a sessão inteira deve ser tratada pelo Modificador porque o Remetente não sabe nada sobre a modificação do número de sequência e confiará em seus próprios números. Fazer isso terá um impacto significativo no desempenho e aumentará a complexidade, pois preciso manter o estado de cada sessão e modificar cada pacote proveniente de ambos os lados para manter os números SEQ/ACK.
Talvez eu não veja outra maneira, exceto escrever o próprio DPI? :-) Qualquer conhecimento, ideias e sugestões são apreciados.
Obrigado.
Responder1
A única opção mais simples que vejo é usar um proxy transparente.
Neste caso, o cliente envia a solicitação ao servidor de destino. O servidor proxy captura a solicitação, adiciona o cabeçalho e cria outra solicitação ao servidor de destino. O servidor de destino retorna a resposta ao proxy, que a retorna ao cliente.
A desvantagem aqui é que o servidor não vê o endereço IP original do cliente, mas o endereço IP do proxy.
Então, para a abordagem MITM no nível TCP, podem existir kits de ferramentas que implementam a funcionalidade necessária para que a implementação completa não seja necessária.
Responder2
Isso parece uma espécie de NAT incompleto; e o problema está exatamente em ser incompleto.
Você não pode MITM apenas em uma direção de um fluxo de pacotes TCP: você precisa lidar com ambos os fluxos, exatamente para lidar com situações como esta (o NAT padrão geralmente só se preocupa com endereços/portas de origem e destino, mas o princípio é o mesmo; se você deseja desfigurar pacotes durante o trânsito e deseja que essa desfiguração seja transparente para ambos os pontos de extremidade, você precisa obtertudocerto).
Depois que você começar a levar tudo em consideração, em breve você terá o NAT completo: não há necessidade de reinventar a roda, pois há muitas implementações que permitirão que você manipule os pacotes como desejar.
As opções reais disponíveis dependerão, obviamente, do sistema operacional e do software de roteamento/firewal em uso.