Sessões de TCP
Para enviar dados sobre o TCP em uma rede, um processo de estabelecimento de sessão de aperto de mão de três vias é seguido. Existe um processo para iniciar uma sessão, e também há um processo para encerrar a sessão do TCP. Este tópico ajuda você a entender o processo envolvido no processamento de uma sessão de TCP.
Entender as verificações de sessão de 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 quaisquer segmentos de TCP com bandeiras não-SYN que tentam iniciar uma sessão.
Valida os números da sequência de TCP durante uma inspeção stateful.
O recurso de verificação de sessão por política do TCP permite configurar 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 dar suporte a opções de TCP por política, as duas opções a seguir estão disponíveis:
sequência de verificação necessária: o valor necessário para a verificação de sequência substitui o valor global sem verificação de sequência.
syn-check-required: O valor exigido pela 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 compromisso 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ência 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.Desativar a 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 intensas operações de CPU. Quando você desativa a verificação global do SYN e habilita a aplicação de verificação de SYN por política, você deve estar ciente desse impacto no desempenho.
Desativação de verificações de segurança de pacotes TCP
Em um dispositivo da Série SRX, você pode desativar 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 verificações de sequência de 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: configurar 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 desativar 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 SYN e sequência são habilitadas por padrão em todas as sessões de TCP. Em ambientes que precisam dar suporte a grandes transferências de arquivos ou que executam aplicativos não padrão, pode ser necessário configurar verificações de sequência e sincronização de maneira 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 da política:
Configure a verificação do 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 uma 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, comprometa a configuração.
[edit] user@host# commit
Verificação
Para verificar se a configuração está funcionando corretamente, entre no 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 TCP SYN para criação de sessão. A verificação sem sequência desativa a validação de verificação da sequência de 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 verificações de sequência de TCP em todas as sessões de TCP, o que reduz a segurança. Isso pode ser necessário em cenários com clientes como arquivos de transferência grandes 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, consulte o uso do editor de CLI no modo de configuração no guia de usuário da CLI.
Para desativar verificações de segurança de pacotes TCP:
Desativar a verificação da bit TCP SYN antes de criar uma sessão.
[edit security flow] user@host# set tcp-session no-syn-check
Desativar a verificação de números de sequência em segmentos de TCP durante uma inspeção stateful.
[edit security flow] user@host# set tcp-session no-sequence-check
Se você terminar de configurar o dispositivo, comprometa a configuração.
[edit ] user@host# commit
Verificação
Para verificar se a configuração está funcionando corretamente, entre no show security flow comando.
Exemplo: definir o tamanho máximo do segmento para todas as sessões de TCP para gateways de serviços da Série SRX
Este exemplo mostra como definir o tamanho máximo do segmento para todas as sessões de TCP para dispositivos 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 ingresso do roteador cujo valor de MSS é maior do que o que você especifica.
Se o bit DF for definido, ele não fragmenta o pacote e o Junos OS enviará o pacote de código 4 tipo 3 do ICMP para o servidor de aplicativo (Destination Unreachable; 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 dispositivos da Série SRX no modo de 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 dispositivos 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 do 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 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, comprometa 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 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 a show configuration security flow partir do modo operacional.
user@host> show configuration security flow
tcp-mss{
all-tcp{
mss 1300;
}
}
Visão geral do registro de entrega 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 na fila para segurar o excesso de pacotes até que a fila preencha 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 livres de 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 encerramento da sessão. Os dispositivos da Série SRX agora oferecem suporte à geração de RTLOG para eventos baseados em pacotes, como a queda de pacotes sem que exista uma sessão.
Os dispositivos da Série SRX oferecem suporte ao registro de pacotes de 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 do TCP evita qualquer perda de pacotes e permite a recuperação de pacotes registrando os pacotes fora de sincronização para comunicação livre de erros e impede que os servidores de banco de dados saiam de sincronização. Esse recurso é construído sobre a instalação de log de segurança (RTLOG).
O registro de queda de pacotes fora do estado do TCP oferece suporte à captura de logs de queda de pacotes TCP nas seguintes condições:
Session ages out— Quando existem aplicativos de nuvem em execução em cima de sessões de TCP longas 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 descartados.
Unsynchronized first packets due to attacks or asymmetric routes— Quando você implanta dispositivos 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 dispositivo 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 ficou inativa por um período de tempo ou as tabelas de conexões foram lançadas (por exemplo, por causa de uma instalação ou reinicialização de políticas).
Os pacotes de SYN_ACK vistos em outro site neste caso foram negados pelo dispositivo 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 dispositivo 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 de aperto de mão de três vias, o dispositivo da Série SRX derruba os pacotes TCP e esses pacotes descartados são registrados.
O log de entrega de pacotes não sincronizado de TCP fora do estado é um log baseado em pacotes, não um log baseado em sessão.
O registro de queda 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 pacotes de TCP fora do estado descartados pelo módulo Flow são registrados. Os pacotes TCP descartados pelo proxy TCP e O IDP não estão logados.
- Entender o registro de queda de pacotes fora do estado do TCP
- Recursos de registro de TCP fora do estado suportados
Entender o registro de queda de pacotes fora do estado do TCP
Para entender a implementação do registro de queda de pacotes fora do estado do TCP, considere que você implanta dispositivos 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 queda 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 nenhuma manutenção seja enviada. Se nenhum dado estiver sendo transmitido, o dispositivo 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 dispositivo da Série SRX, a sessão não está mais lá e o pacote é descartado, mas não logado. Esses pacotes TCP fora do estado que são descartados agora são registrados pelo dispositivo da Série SRX.
Recursos de registro de TCP fora do estado suportados
O registro fora do estado do TCP oferece suporte aos seguintes recursos:
Um componente de filtro de pacote para filtrar o tráfego alvo.
Um componente do acelerador para proteger a CPU de ser sobrecarregada por mensagens de log.
Flexibilidade para alterar a taxa de geração de logs.
- Componente do filtro de pacotes
- Componente do acelerador
- Flexibilidade para alterar a taxa de geração de log
Componente do filtro de pacotes
O filtro de registro aproveita o filtro de rastreamento de fluxo atual. Ele fornece diferentes maneiras 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 do acelerador
Registrar todos os pacotes de TCP fora do estado pode sobrecarregar o dispositivo quando o tráfego está pesado ou quando ocorre um ataque. Se a CPU estiver ociosa e você quiser registrar o máximo de mensagens possível, isso pode levar à sobrecarga da CPU.
O mecanismo do acelerador permite configurar o intervalo do acelerador a partir da CLI, para que você possa proteger sua CPU de sobrecarga.
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 aceleraçã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 padrão do acelerador é de 1 segundo. O intervalo do acelerador (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 do acelerador for configurado como 0, nenhum mecanismo de aceleração será envolvido. Isso é adequado para cenários em que o tráfego é muito leve e você quer registrar todos os logs de queda de pacotes.
A configuração do intervalo do acelerador como 2^N torna o mecanismo do acelerador sem bloqueio e fornece um bom desempenho de captura de log.
Flexibilidade para alterar a taxa de geração de log
Com base no conjunto de intervalos do acelerador, 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 da 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 preservar as características de fragmentação que chegam pode melhorar a taxa de transferência
Este tópico abrange os benefícios de usar o dispositivo da Série SRX para preservar as características dos fragmentos de pacotes recebidos.
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 de maior tamanho podem transitar pelo caminho desde o nó de origem até o nó de destino sem serem fragmentados em nenhum link no datapath. Quando um pacote deve ser fragmentado em pacotes menores para transitar por um enlace no caminho porque o pacote é maior do que o da unidade de transmissão máxima (MTU) estabelecida para esse enlace, cada um dos fragmentos resultantes deve conter informações de cabeçalho de pacote, além do payload 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 pacotes 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 do CAMINHO MTU funciona para descobrir o tamanho ideal do MTU para fragmentos que transitam pelo datapath desde o nó de origem até o nó de destino para uma sessão. O tamanho ideal do pacote, então, é o do caminho MTU. 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 dispositivo da Série SRX, os fragmentos de pacotes na interface de ingresso devem 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 pela interface de saída. Normalmente, é o tamanho mtu da interface de saída que determina o tamanho dos fragmentos transmitidos pelo dispositivo da Série SRX para o próximo enlace. Pode ser o caso de o tamanho de MTU de saída no dispositivo da Série SRX ser maior do que o CAMINHO MTU, o que, mais uma vez, resultaria em fragmentação de pacotes no caminho de dados, reduzindo o desempenho ou causando a queda de pacotes. Os fragmentos de pacotes devem ser pequenos o suficiente para transitar por todos os enlaces do caminho da origem ao destino.
Por padrão, o dispositivo da Série SRX usa o tamanho do MTU configurado para a interface de saída para determinar o tamanho dos fragmentos de pacote que transmite. No entanto, se você habilitar o recurso para preservar as características dos fragmentos recebidos, o dispositivo da Série SRX detecta e economiza o tamanho de fragmentos de pacotes recebidos.
Para diminuir a probabilidade de fragmentação de pacotes no caminho de dados, o dispositivo 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 recebidos. 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 dispositivo da Série SRX compara os dois números. Ele pega o número menor e o usa para o tamanho 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 pacotes recebidos.
A Tabela 1 resume como o tamanho do MTU de saída da Série SRX é determinado.
Tamanho do fragmento de entrada |
Tamanho do MTU de saída existente |
Tamanho final do 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 |
A interface de saída MTU existente é usada. |
Esse recurso é suportado em dispositivos da Série SRX. Ele oferece suporte ao tráfego e ao tráfego saindo 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 UTM e ALG, os próprios aplicativos poderiam alterar ou remontar pacotes mesmo se não houvesse fragmentos recebidos. Nesse caso, a interface de saída MTU existente é usada.
Quando um pacote de descoberta de CAMINHO MTU é entregue em uma sessão, o caminho MTU para essa sessão é reajustado ao valor estabelecido pelo pacote MTU de caminho.
set security flow preserve-incoming-frag-size comando para habilitar o recurso que leva em conta o tamanho dos fragmentos de pacotes recebidos.