Sessões TCP

Por padrão, as opções de verificação TCP SYN e verificação de sequência são habilitadas em todas as sessões TCP. O Sistema operacional Junos (Junos OS) realiza as seguintes operações durante as sessões TCP:

• Verifica se há sinalizadores SYN no primeiro pacote de uma sessão e rejeita todos os segmentos TCP com sinalizadores não SYN que tentam iniciar uma sessão.

• Valida os números de sequência TCP durante a inspeção stateful.

O recurso de verificação de sessão TCP por política permite configurar verificações SYN e de sequência para cada política. Atualmente, os sinalizadores de opções TCP, no-sequence-check e no-syn-check, estão disponíveis em nível global para controlar o comportamento dos gateways de serviços. Para dar suporte a opções TCP por política, as duas opções a seguir estão disponíveis:

• sequence-check-required: o valor sequence-check-required substitui o valor global no-sequence-check.

• syn-check-required: o valor syn-check-required substitui o valor global no-syn-check.

Para configurar opções de TCP por política, você deve desativar as respectivas opções globais; caso contrário, a verificação de confirmação falhará. Se as opções TCP globais estiverem desabilitadas e a proteção contra inundação SYN permitir o primeiro pacote, as opções TCP por política controlarão se as verificações SYN e/ou de sequência serão executadas.

Este exemplo mostra como configurar verificações de segurança de pacotes TCP para cada política no dispositivo.

Este exemplo mostra como desabilitar as verificações de segurança de pacotes TCP no dispositivo.

Este exemplo mostra como definir o tamanho máximo do segmento para todas as sessões TCP para firewalls da Série SRX.

Em qualquer rede comutada por pacotes, quando a demanda excede a capacidade disponível, os pacotes são enfileirados para reter os pacotes em excesso até que a fila seja preenchida e, em seguida, os pacotes são descartados. Quando o TCP opera em tal rede, ele toma todas as ações corretivas para manter as comunicações de ponta a ponta livres de erros.

Os módulos de fluxo já suportam a geração de RTLOG para eventos baseados em sessão, como criação e fechamento de sessão. Os firewalls da Série SRX agora suportam a geração de RTLOG para eventos baseados em pacotes, como queda de pacotes, sem a existência de uma sessão.

Os firewalls da Série SRX suportam o registro de pacotes TCP fora do estado não sincronizados que são descartados pelo módulo de fluxo.

O recurso de registro de queda de pacotes fora do estado TCP evita qualquer perda de pacote e permite a recuperação de pacotes registrando os pacotes fora de sincronia para comunicação sem erros e impede que os servidores de banco de dados fiquem fora de sincronia. Esse recurso é criado sobre o recurso de log de segurança (RTLOG).

O registro de descarte de pacotes fora do estado TCP dá suporte à captura de logs de descarte de pacotes TCP nas seguintes condições:

• Session ages out— Quando há aplicativos de nuvem em execução sobre longas sessões TCP e quando esses aplicativos não atualizam as sessões TCP após a expiração da sessão, os pacotes TCP são descartados. Esse recurso oferece suporte ao registro desses pacotes TCP descartados.

• Unsynchronized first packets due to attacks or asymmetric routes— Quando você implanta firewalls Série SRX em dois locais e quando o roteamento às vezes força tráfego assimétrico, o pacote de sincronização (SYN) é visto em um site, mas os pacotes de confirmação de sincronização (SYN_ACK) são vistos em outro site.

  Isso significa que o firewall da Série SRX vê um pacote TCP ACK para o qual não tem uma entrada de tabela de estado correspondente. Isso pode ocorrer porque a conexão ficou inativa por um período de tempo ou as tabelas de conexões foram liberadas (por exemplo, devido a uma instalação ou reinicialização de política).

  Os SYN_ACK pacotes que são vistos em outro local neste caso foram negados pelo Série SRX Firewall, mas não foram registrados. Esse recurso oferece suporte ao registro em log dos pacotes de SYN_ACK negados.

• Other out-of-state conditions (like TCP sequence check fail and synchronization packet received in FIN state)— Quando um firewall da Série SRX detecta uma falha de sequência, se o dispositivo está no estado TCP de fechamento de quatro vias, mas recebe pacotes SYN, ou se há uma falha de handshake de três vias, o firewall da Série SRX descarta os pacotes TCP e esses pacotes descartados são registrados.

• Entender o registro de queda de pacotes TCP fora do estado
• Recursos de registro TCP fora do estado suportados

Quando os dados são enviados de um host para outro, eles são transmitidos como uma série de pacotes. O desempenho é aprimorado e os recursos de rede são conservados quando pacotes do maior tamanho podem transitar pelo caminho do nó de origem para o nó de destino sem serem fragmentados em nenhum link no caminho de dados. Quando um pacote deve ser fragmentado em pacotes menores para transitar por um link no caminho porque o pacote é maior do que o da unidade máxima de transmissão (MTU) estabelecida para esse link, cada um dos fragmentos resultantes deve conter informações de cabeçalho de pacote, além da carga útil ou dados. O aumento da sobrecarga pode reduzir a taxa de transferência e degradar o desempenho da rede. Além disso, os fragmentos de pacote devem ser remontados no nó de destino, o que consome recursos de rede adicionais.

Por outro lado, os recursos de rede são desperdiçados quando um host envia pacotes muito menores do que a MTU (unidade de transmissão máxima do caminho), resultando em uma taxa de transferência abaixo do ideal. O processo de descoberta de MTU de caminho funciona para descobrir o tamanho ideal de MTU para fragmentos que transitam pelo caminho de dados do nó de origem para o nó de destino para uma sessão. O tamanho ideal do pacote, então, é o da MTU do caminho. A fragmentação ocorre quando o tamanho de um pacote excede o caminho MTU.

Se os serviços da camada de aplicativo estiverem configurados no firewall da Série SRX, os fragmentos de pacotes na interface de entrada deverão ser remontados antes que os serviços possam ser aplicados e o conteúdo inspecionado. Esses fragmentos de pacote remontados devem ser divididos novamente antes que os dados sejam transmitidos para fora da interface de saída. Normalmente, é o tamanho da MTU da interface de saída que determina o tamanho dos fragmentos transmitidos pelo firewall da Série SRX para o próximo link. Pode ser que o tamanho da MTU de saída no firewall da Série SRX seja maior que a MTU do caminho, o que, novamente, resultaria em fragmentação de pacotes no caminho de dados, reduzindo o desempenho ou causando a queda de pacotes. Os fragmentos de pacote devem ser pequenos o suficiente para transitar por todos os links no caminho da origem ao destino.

Por padrão, o firewall da Série SRX usa o tamanho de MTU configurado para a interface de saída para determinar o tamanho dos fragmentos de pacote que ele transmite. No entanto, se você habilitar o recurso para preservar as características do fragmento de entrada, o firewall da Série SRX detectará e salvará o tamanho dos fragmentos de pacote de entrada.

Para diminuir a probabilidade de fragmentação de pacotes no caminho de dados, o firewall da Série SRX rastreia e ajusta a MTU de saída para esse fluxo. Ele identifica o tamanho máximo de todos os fragmentos de entrada. Ele usa essas informações em conjunto com a MTU existente da interface de saída para determinar o tamanho correto da MTU para pacotes fragmentados enviados pela interface de saída. O firewall da Série SRX compara os dois números. Ele pega o número menor e o usa para o tamanho da MTU da interface de saída.

Configure o dispositivo usando o set security flow preserve-incoming-frag-size comando para habilitar o recurso que leva em conta o tamanho dos fragmentos de pacote recebidos.

A Tabela 1 resume como o tamanho da MTU de saída da Série SRX é determinado.

As duas considerações a seguir afetam o tamanho do fragmento:

• Para aplicativos baseados em fluxo, como Segurança de conteúdo e ALG, os próprios aplicativos podem alterar ou remontar pacotes mesmo que não haja fragmentos recebidos. Nesse caso, a interface de saída existente MTU é usada.

• Quando um pacote de descoberta de MTU de caminho é entregue a uma sessão, o MTU do caminho para essa sessão é redefinido para o valor estabelecido pelo pacote de MTU de caminho.

O curto-circuito do proxy TCP é ativado por padrão em seu dispositivo. Ele é acionado automaticamente quando não há usuários (plug-ins de aplicação de política L7/serviços de aplicativos avançados) interessados em usar o Proxy TCP para a sessão. Após o estabelecimento bem-sucedido da sessão TCP e a aplicação da política, o dispositivo faz a transição da sessão para um estado de curto-circuito, permitindo que os pacotes de dados subsequentes fluam diretamente entre o cliente e o servidor.

Durante a fase inicial de handshake, o dispositivo mantém o comportamento completo do proxy TCP, gerenciando de forma independente o estado TCP, os números de sequência e as confirmações para ambos os lados da conexão. Depois que a sessão é verificada como legítima e estável, o dispositivo não faz mais proxy de números de sequência ou retransmissões para tráfego de dados. Em vez disso, ele encaminha pacotes diretamente enquanto continua a monitorar a sessão em busca de conformidade com políticas e violações de segurança.

O curto-circuito de proxy TCP é adequado para implantações que exigem segurança e validação de TCP fortes sem a sobrecarga de desempenho de longo prazo do proxy TCP completo. Ele é particularmente eficaz em ambientes de alta taxa de transferência, como data centers, bordas de provedores de serviços e redes empresariais de grande porte.