Sessões de TCP
Para enviar dados por TCP em uma rede, um processo de estabelecimento de sessão de três vias é seguido. Há um processo para iniciar uma sessão, e também há um processo para encerrar a sessão do TCP. Esse tópico ajuda você a entender o processo envolvido no processamento de uma sessão de TCP.
Entender as verificações de sessão do TCP por política
Por padrão, as opções de verificação e verificação de sequência do TCP SYN são habilitadas em todas as sessões de TCP. O sistema operacional Junos (Junos OS) realiza as seguintes operações durante as sessões de TCP:
Verifica as bandeiras SYN no primeiro pacote de uma sessão e rejeita qualquer segmento de TCP com bandeiras não-SYN que tentem iniciar uma sessão.
Valida os números da sequência de TCP durante a inspeção stateful.
O recurso de verificação de sessão por política do TCP permite que você configure sYN e verificações de sequência para cada política. Atualmente, as bandeiras de opções de TCP, sem verificação de sequência e sem syn-check, estão disponíveis em nível global para controlar o comportamento dos gateways de serviços. Para oferecer suporte a opções de TCP por política, as seguintes duas opções estão disponíveis:
verificação de sequência: o valor necessário para verificação de sequência substitui o valor global sem verificação de sequência.
syn-check-required: O valor exigido para syn-check substitui o valor global sem 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 globais de TCP forem desabilitadas e a proteção contra inundações SYN permitir o primeiro pacote, as opções de TCP por política controlarão se as verificações de SYN e/ou sequências são realizadas.
A opção por política
syn-check-requirednão substituirá o comportamento doset security flow tcp-session no-syn-check-in-tunnelcomando CLI.A desativação da verificação SYN global reduz a eficácia do dispositivo na defesa contra inundações de pacotes.
Desativar a verificação SYN global e aplicar a verificação SYN após a pesquisa de políticas afetará muito o número de pacotes que o roteador pode processar. Isso, por sua vez, resultará em operações intensas de CPU. Ao desabilitar a verificação global do SYN e habilitar a aplicação de verificação de SYN por política, você deve estar ciente desse impacto de desempenho.
Desativação de verificações de segurança de pacotes TCP
Em um firewall da Série SRX, você pode desabilitar verificações de segurança em pacotes TCP para garantir a interoperabilidade com hosts e dispositivos com implementações TCP defeituosas.
A opção no-sequence-check desativa as verificações de sequência do TCP. Também aumenta a taxa de transferência.
O set security flow tcp-session no-sequence-check comando desativa as verificações da sequência de TCP em todas as sessões de TCP em modos padrão ou baseados em hash.
Exemplo: configuração de verificações de segurança de pacotes TCP por política
Este exemplo mostra como configurar verificações de segurança de pacotes TCP para cada política no dispositivo.
Requisitos
Antes de começar, você deve desabilitar as opções tcp-syn-checkde tcp e tcp-sequence-check que estão configuradas em nível global. .
Visão geral
As opções de verificação de sequência e SYN são habilitadas por padrão em todas as sessões de TCP. Em ambientes que precisam oferecer suporte a grandes transferências de arquivos ou que executam aplicativos fora do padrão, pode ser necessário configurar verificações de sequência e sincronização de forma diferente para cada política. Neste exemplo, você configura a seqüência e a verificação de sincronização da política pol1.
Configuração
Procedimento
Procedimento passo a passo
Para configurar verificações de segurança de pacotes TCP no nível de política:
Configure a verificação para o bit TCP SYN antes de criar uma sessão.
[edit] user@host# set security policies from-zone Zone-A to-zone Zone-B policy pol1 then permit tcp-options syn-check-required
Configure a verificação de números de sequência em segmentos de TCP durante a inspeção stateful.
[edit] user@host# set security policies from-zone Zone-A to-zone Zone-B policy pol1 then permit tcp-options sequence-check-required
Se você terminar de configurar o dispositivo, confirme a configuração.
[edit] user@host# commit
Verificação
Para verificar se a configuração está funcionando corretamente, insira o show security policies detail comando.
Exemplo: Desativação de verificações de segurança de pacotes TCP para gateways de serviços da Série SRX
Este exemplo mostra como desativar verificações de segurança de pacotes TCP no dispositivo.
Requisitos
Antes de começar, entenda as circunstâncias para desativar as verificações de segurança de pacotes TCP. .
Visão geral
O Junos OS fornece um mecanismo para desativar verificações de segurança em pacotes TCP para garantir a interoperabilidade com hosts e dispositivos com implementações TCP defeituosas. Durante a não verificação SYN, o Junos OS não procura o pacote SYN do TCP para criação de sessão. A verificação sem sequência desativa a validação de verificação da sequência do TCP. Além disso, aumenta a taxa de transferência. A verificação e a sequência do SYN são habilitadas por padrão. O comando de fluxo de segurança definido desativa as verificações de SYN do TCP e as verificações de sequência de TCP em todas as sessões de TCP, reduzindo assim a segurança. Isso pode ser exigido em cenários com clientes como grandes arquivos de transferência ou com aplicativos que não funcionam corretamente com padrões.
Configuração
Procedimento
Procedimento passo a passo
O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter instruções sobre como fazer isso, veja Usando o Editor de CLI no modo de configuração no Guia do usuário da CLI.
Para desativar verificações de segurança de pacotes TCP:
Desativar a verificação do bit TCP SYN antes de criar uma sessão.
[edit security flow] user@host# set tcp-session no-syn-check
Desativar a verificação dos números de sequência em segmentos de TCP durante a inspeção stateful.
[edit security flow] user@host# set tcp-session no-sequence-check
Se você terminar de configurar o dispositivo, confirme a configuração.
[edit ] user@host# commit
Verificação
Para verificar se a configuração está funcionando corretamente, insira o show security flow comando.
Exemplo: definir o tamanho máximo do segmento para todas as sessões de TCP para firewalls da Série SRX
Este exemplo mostra como definir o tamanho máximo do segmento para todas as sessões de TCP para firewalls da Série SRX.
Requisitos
Antes de começar, entenda as circunstâncias para definir o tamanho máximo do segmento.
Visão geral
Você pode encerrar todas as sessões de TCP alterando o tamanho máximo do segmento (TCP-MSS). Para diminuir a probabilidade de fragmentação e proteger contra perda de pacotes, você pode usar o tcp-mss para especificar um valor de MSS TCP mais baixo. Isso se aplica a todos os pacotes TCP SYN que atravessam as interfaces de entrada do roteador cujo valor de MSS é maior do que o que você especifica.
Se o bit DF estiver definido, ele não fragmentará o pacote e o Junos OS enviará um pacote de código 4 tipo 3 de erro ICMP para o servidor de aplicativo (Destino inalcançável; Fragmentação necessária e conjunto DF). Esta mensagem de erro do ICMP contém o MTU correto (conforme definido em tcp-mss) a ser usado pelo servidor do aplicativo, que deve receber esta mensagem e ajustar o tamanho do pacote de acordo. Isso é especificamente necessário com VPNs, pois o IPsec adicionou sobrecarga de pacotes; assim, os tcp-mss devem ser reduzidos adequadamente.
Ao executar firewalls da Série SRX no modo pacote, você usa o set system internet-options tcp-mss para ajustar o valor do TCP-MSS. Todas as portas são afetadas pela configuração TCP-MSS; você não pode excluir uma porta específica. Ao executar firewalls da Série SRX no modo de fluxo, embora você possa usar o set system internet-options tcp-mss , recomendamos usar apenas o set security flow tcp-mss para ajustar o valor TCP-MSS. Se ambas as declarações estiverem configuradas, a menor dos dois valores entrará em vigor.
Configuração
Procedimento
Procedimento passo a passo
Para configurar o tamanho máximo do segmento para todas as sessões de TCP:
Defina o tamanho máximo do segmento do TCP para todas as sessões de TCP.
[edit security flow] user@host# set tcp-mss all-tcp mss 1300
Se você terminar de configurar o dispositivo, confirme a configuração.
[edit ] user@host# commit
Resultados
A partir do modo de configuração, confirme sua configuração entrando no show security flow comando. Se a saída não exibir a configuração pretendida, repita as instruções de configuração neste exemplo para corrigi-la.
Para a brevidade, essa show saída de comando inclui apenas a configuração que é relevante para este exemplo. Qualquer outra configuração no sistema foi substituída por elipses (...).
[edit]
user@host# show security flow
...
tcp-mss{
all-tcp{
mss 1300;
}
}
...
Verificação
Para verificar se a configuração está funcionando corretamente, insira o comando do show configuration security flow modo operacional.
user@host> show configuration security flow
tcp-mss{
all-tcp{
mss 1300;
}
}
Visão geral do registro de quedas de pacotes fora do estado do TCP
Dentro de qualquer rede comutada por pacotes, quando a demanda excede a capacidade disponível, os pacotes ficam enfileirados para segurar o excesso de pacotes até que a fila se encha e, em seguida, os pacotes são descartados. Quando o TCP opera em tal rede, é preciso qualquer ação corretiva para manter comunicações de ponta a ponta sem erros.
Os módulos de fluxo já suportam a geração de RTLOG para eventos baseados em sessão, como criação de sessão e fechamento de sessão. Os firewalls da Série SRX agora oferecem suporte à geração de RTLOG para eventos baseados em pacotes, como a queda de pacotes sem uma sessão existente.
Os firewalls da Série SRX oferecem suporte ao registro de pacotes fora do estado de TCP não sincronizados que são descartados pelo módulo de fluxo.
O recurso de registro de queda de pacotes fora do estado do TCP evita qualquer perda de pacotes e permite a recuperação de pacotes registrando os pacotes fora de sincronização para comunicação sem erro e impede que os servidores de banco de dados saiam de sincronia. Esse recurso é construído em cima da instalação de log de segurança (RTLOG).
O registro de quedas de pacotes fora do estado do TCP suporta a captura de logs de queda de pacotes TCP sob as seguintes condições:
Session ages out— Quando há aplicativos de nuvem em execução em cima de longas sessões de TCP e quando esses aplicativos não atualizam as sessões de TCP após o fim da sessão, os pacotes TCP são descartados. Esse recurso oferece suporte ao registro desses pacotes TCP perdidos.
Unsynchronized first packets due to attacks or asymmetric routes— Quando você implanta firewalls da Série SRX em dois locais e, quando o roteamento às vezes força o tráfego assimétrico, o pacote de sincronização (SYN) é visto em um site, mas os pacotes de reconhecimento 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 ele não tem uma entrada de tabela de estado correspondente. Isso pode ocorrer porque a conexão estava inativa por um período de tempo ou as tabelas de conexão foram liberadas (por exemplo, devido a uma instalação ou reiniciamento de políticas).
Os pacotes de SYN_ACK que são vistos em outro site neste caso foram negados pelo firewall da Série SRX, mas não foram registrados. Esse recurso oferece suporte ao registro 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á em estado de fechamento de quatro vias do TCP, mas recebe pacotes SYN, ou se houver uma falha em três vias, o firewall da Série SRX derruba os pacotes TCP e esses pacotes perdidos são registrados.
O log de entrega de pacotes fora do estado de TCP não sincronizado é um log baseado em pacotes, não um log baseado em sessão.
O registro de quedas de pacotes fora do estado do TCP foi projetado com um mecanismo de aceleração para proteger a CPU de ser atacada, e em cada intervalo de aceleração alguns logs podem ser descartados.
Apenas os pacotes de fora do estado TCP descartados pelo módulo Flow estão logados. Os pacotes TCP descartados pelo proxy TCP e IDP não estão logados.
- Entenda o registro de quedas de pacotes fora do estado do TCP
- Recursos de registro fora do estado do TCP suportados
Entenda o registro de quedas de pacotes fora do estado do TCP
Para entender a implementação do registro de quedas de pacotes fora do estado do TCP, considere que você implanta firewalls da Série SRX em dois locais e que o roteamento às vezes força o tráfego assimétrico, onde o pacote SYN é visto em um site, mas o pacote SYN_ACK é visto em outro site. O pacote de SYN_ACK neste caso seria negado, mas não registrado. O recurso de registro de quedas de pacotes fora do estado do TCP oferece visibilidade dessas quedas de pacotes não sincronizadas.
Considere o cenário em que os bancos de dados dentro do data center mantêm seus soquetes TCP abertos, sem que sejam enviados keepalives. Se nenhum dado estiver sendo transmitido, o firewall da Série SRX ficará sem tempo para as sessões. Embora os bancos de dados enviem alguns dados por esse soquete TCP, quando o tráfego chega ao firewall da Série SRX, a sessão não está mais lá e o pacote é descartado, mas não está logado. Esses pacotes TCP fora do estado que são descartados agora são registrados pelo firewall da Série SRX.
Recursos de registro fora do estado do TCP suportados
O registro fora do estado do TCP oferece suporte aos seguintes recursos:
Um componente de filtro de pacotes para filtrar o tráfego alvo.
Um componente de aceleração para proteger a CPU de ser sobrecarregada por mensagens de log.
Flexibilidade para alterar a taxa de geração de log.
- Componente do filtro de pacotes
- Componente de acelerador
- Flexibilidade para mudar a taxa de geração de logs
Componente do filtro de pacotes
O filtro de registro aproveita o filtro de rastreamento de fluxo atual. Ele oferece maneiras diferentes de filtrar o tráfego. Você deve configurar os filtros para gerar logs de pacotes, caso contrário, os logs não serão acionados.
Essa funcionalidade de filtro evita habilitar logs de maneira inesperada. Os filtros máximos suportados são 64.
Use o set security flow packet-log packet-filter <filter-name> comando para habilitar os componentes de filtro relacionados que você deseja.
Componente de acelerador
Registrar todos os pacotes de fora do estado do TCP pode sobrecarregar o dispositivo quando o tráfego está pesado ou quando ocorre um ataque. Se a CPU estiver ociosa e quiser registrar o máximo de mensagens possível, isso pode levar à sobrecarga da CPU.
O mecanismo de aceleração permite configurar o intervalo de aceleração da CLI para que você possa proteger sua CPU de estar sobrecarregada.
Uma tabela de hash é introduzida para mapear seus dados logados. A chave de hash é gerada com o endereço IP de origem, endereço IP de destino, porta de origem e porta de destino.
Em cada intervalo de limitação, apenas um número limitado (mais de um) de mensagens será enviado ao RTLOG. As mensagens de log restantes serão aceleradas.
O intervalo de aceleração padrão é de 1 segundo. O intervalo de aceleração (no nível de milissegundo) precisa ser configurado como uma potência de dois ou zero (0, 1, 2, 4, 8, 16 ... 2^N).
Quando o intervalo de aceleração estiver configurado como 0, nenhum mecanismo de aceleração estará envolvido. Isso é adequado para cenários em que o tráfego é muito leve e você deseja registrar todos os logs de queda de pacotes.
A configuração do intervalo de aceleração como 2^N torna o mecanismo de acelerador sem bloqueio e fornece um bom desempenho de captura de log.
Flexibilidade para mudar a taxa de geração de logs
Com base no conjunto de intervalos de limitação, a taxa de geração de log pode ser modificada e gerenciada.
Isso significa que em cada intervalo de 32 milissegundos (ms), um número limitado de logs poderia ser gerado e o restante poderia ser descartado. Recomendamos que você configure o intervalo como (0, 1, 2, 4, 8, 16, 32 ... 2^N).
Se o valor de entrada não estiver alinhado a 2^N, ele estará alinhado a 2^N automaticamente durante o processamento do fluxo. Por exemplo, se você configurar um intervalo de 10 ms, ele estará alinhado a um intervalo de 8 ms automaticamente.
Entender como a preservação das características de fragmentação de entrada pode melhorar a taxa de transferência
Este tópico aborda os benefícios de usar o firewall da Série SRX para preservar as características dos fragmentos de pacotes de entrada.
Quando os dados são enviados de um host para outro, eles são transmitidos como uma série de pacotes. O desempenho é melhorado e os recursos de rede são conservados quando pacotes do maior tamanho podem transitar pelo caminho do nó de origem até o nó de destino sem serem fragmentados em qualquer link no datapath. 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 de transmissão máxima (MTU) estabelecida para esse link, cada um dos fragmentos resultantes deve conter informações de cabeçalho de pacote, além da carga 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, 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 o MTU de caminho (unidade de transmissão máxima de caminho), resultando em taxa de transferência abaixo do ideal. O processo de descoberta de MTU do caminho funciona para descobrir o tamanho ideal de MTU para fragmentos que transitam pelo datapath do nó de origem até o nó de destino para uma sessão. O tamanho ideal do pacote, então, é o do MTU do caminho. A fragmentação ocorre quando o tamanho de um pacote excede o caminho MTU.
Se os serviços de camada de aplicativo estiverem configurados no firewall da Série SRX, os fragmentos de pacotes na interface de entrada devem ser remontados antes que os serviços possam ser aplicados e o conteúdo inspecionado. Esses fragmentos de pacotes remontados devem ser quebrados novamente antes que os dados sejam transmitidos pela interface de saída. Normalmente, é o tamanho 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 o caso de que o tamanho de MTU de saída no firewall da Série SRX seja maior do que o CAMINHO MTU, o que, novamente, resultaria em fragmentação de pacotes no datapath, reduzindo o desempenho ou causando a queda de pacotes. Os fragmentos de pacotes devem ser pequenos o suficiente para transitar por todos os enlaces no caminho da fonte ao destino.
Por padrão, o firewall da Série SRX usa o tamanho do MTU configurado para a interface de saída para determinar o tamanho dos fragmentos de pacotes que transmite. No entanto, se você habilitar o recurso para preservar as características dos fragmentos de entrada, o firewall da Série SRX detecta e economiza o tamanho de fragmentos de pacotes de entrada.
Para diminuir a probabilidade de fragmentação de pacotes no datapath, o firewall da Série SRX acompanha e ajusta o 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 o MTU existente da interface de saída para determinar o tamanho correto do 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 a interface de saída tamanho MTU.
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 de entrada.
A Tabela 1 resume como o tamanho do MTU de saída da Série SRX é determinado.
Tamanho do fragmento de entrada |
Tamanho de MTU de saída existente |
Tamanho final de MTU de saída |
|---|---|---|
Se o maior fragmento for |
menor do que o tamanho de MTU de saída existente |
maior tamanho de fragmento de entrada é usado. |
Se o maior fragmento for |
maior do que o tamanho de MTU de saída existente |
MTU de interface de saída existente é usada. |
Esse recurso é compatível com firewalls da Série SRX. Ele oferece suporte ao tráfego e à saída de tráfego de um túnel. Ela se aplica ao tráfego IPv4 e IPv6.
As duas considerações a seguir afetam o tamanho do fragmento:
Para aplicativos baseados em fluxo, como a Segurança de Conteúdo e ALG, os próprios aplicativos poderiam alterar ou remontar pacotes mesmo que não houvesse fragmentos recebidos. Neste caso, a interface de saída EXISTENTE MTU é usada.
Quando um pacote de descoberta de MTU de caminho é entregue em uma sessão, o caminho MTU para essa sessão é redefinido para o valor estabelecido pelo pacote MTU de caminho.
Tabela de histórico de mudanças
O suporte de recursos é determinado pela plataforma e versão que você está usando. Use o Feature Explorer para determinar se um recurso é suportado em sua plataforma.
set security flow preserve-incoming-frag-size comando para habilitar o recurso que leva em conta o tamanho dos fragmentos de pacote de entrada.