TCP
Muitos aplicativos e serviços usam o TCP para se comunicar. Configure opções de TCP para melhorar a qualidade e a segurança do enlace.
Segurança para cabeçalhos TCP com conjunto de bandeiras SYN e FIN
Por padrão, seu dispositivo aceita pacotes que tenham os bits SYN e FIN definidos na bandeira TCP. Configure seu dispositivo para soltar pacotes com os bits SYN e FIN definidos para reduzir vulnerabilidades de segurança.
As bandeiras de controle SYN e FIN normalmente não são definidas no mesmo cabeçalho do segmento TCP. A bandeira SYN sincroniza números de sequência para iniciar uma conexão TCP. A bandeira FIN indica o fim da transmissão de dados para terminar uma conexão TCP. Seus propósitos são mutuamente exclusivos. Um cabeçalho TCP com o conjunto de bandeiras SYN e FIN é um comportamento anômico de TCP, causando várias respostas do destinatário, dependendo do sistema operacional. Veja a Figura 1.
de bandeiras SYN e FIN
Um invasor pode enviar um segmento com ambas as bandeiras definidas para ver que tipo de resposta do sistema é devolvida e, assim, determinar que tipo de sistema operacional está na extremidade recebedora. O invasor pode então usar quaisquer vulnerabilidades conhecidas do sistema para novos ataques. Quando você habilita a declaração, o tcp-drop-synfin-set Junos OS verifica se as bandeiras SYN e FIN são definidas em cabeçalhos TCP. Se descobrir esse cabeçalho, ele derruba o pacote.
[edit system internet-options] tcp-drop-synfin-set;
Desativar extensões do TCP RFC 1323
Para desativar extensões de RFC 1323 TCP, inclua a no-tcp-rfc1323 declaração no nível da [edit system internet-options] hierarquia:
[edit system internet-options] no-tcp-rfc1323;
Para desativar a extensão do número de proteção contra sequência embrulhada (PAWS) (descrita no RFC 1323, extensões de TCP para alto desempenho), inclua a no-tcp-rfc1323-paws declaração no nível de [edit system internet-options] hierarquia:
[edit system internet-options] no-tcp-rfc1323-paws;
Configure o TCP MSS para negociação de sessão
Durante o estabelecimento da conexão de sessão, dois pares concordam em negociações para determinar o tamanho do segmento ip de pacotes que trocarão durante sua comunicação. O valor do TCP MSS (tamanho máximo do segmento) em pacotes TCP SYN especifica o número máximo de bytes que o campo de dados ou segmento de um pacote TCP pode conter. Um valor mss que é definido muito alto pode resultar em um programa de dados IP que é muito grande para enviar e que deve ser fragmentado. A fragmentação pode incorrer em custos adicionais de sobrecarga e perda de pacotes.
Para diminuir a probabilidade de fragmentação e proteger contra perda de pacotes, você pode usar a tcp-mss declaração para especificar um valor de MSS TCP mais baixo. A tcp-mss declaração se aplica a todos os pacotes IPv4 TCP SYN que atravessam todas as interfaces de ingresso do roteador cujo valor de MSS é maior do que o que você especifica. Você não pode isentar portas específicas de seus efeitos.
A seção a seguir descreve como configurar o TCP MSS em roteadores da Série T, Série M e Série MX.
- Configuração do TCP MSS em roteadores da Série T e série M, e roteadores da Série MX usando uma placa de serviço
- Configuração do TCP MSS em linha em roteadores da Série MX usando placas de linha MPC
Configuração do TCP MSS em roteadores da Série T e série M, e roteadores da Série MX usando uma placa de serviço
Para especificar um valor de MSS TCP em roteadores da Série T e série M, bem como roteadores da Série MX usando uma placa de serviço, inclua a tcp-mss mss-value declaração no nível de [edit services service-set service-set-name] hierarquia:
[edit services service-set service-set-name] tcp-mss mss-value;
A faixa do tcp-mss mss-value parâmetro é de 536 a 65535 bytes.
Adicione o conjunto de serviços a qualquer interface para a qual você queira ajustar o valor do TCP-MSS:
[edit interfaces interface-name unit 0 family family service] input service-set service-set-name; output service-set service-set-name;
Para visualizar estatísticas de pacotes SYN recebidos e pacotes SYN cujo valor MSS é modificado, emita o comando do show services service-sets statistics tcp-mss modo operacional.
Para obter mais informações sobre a configuração do TCP MSS nos roteadores da Série T e série M, consulte a Biblioteca de interfaces de serviços do Junos OS para dispositivos de roteamento.
Configuração do TCP MSS em linha em roteadores da Série MX usando placas de linha MPC
Para especificar um valor de MSS TCP em roteadores da Série MX que usam placas de linha MPC, inclua a tcp-mss declaração no nível de [edit interfaces interface-name unit logical-unit-number family family] hierarquia:
[edit interfaces interface-name unit logical-unit-number family family] tcp-mss mss-value;
A faixa do mss-value parâmetro é de 64 a 65.535 bytes. O valor do TCP MSS deve ser inferior ao MTU da interface.
Esta declaração é suportada nas seguintes interfaces: gr- (GRE), ge- (Gigabit Ethernet), xe- (10 Gigabit Ethernet) e et- (40 Gigabit e 100 Gigabit Ethernet). As famílias apoiadas são inet e inet6.
Configurar o TCP MSS em linha em roteadores da Série MX usando placas de linha MPC funciona apenas para saída/saída de tráfego da interface, não para entrada/entrada de tráfego na interface.
Selecione um endereço de origem fixa para pacotes de TCP/IP gerados localmente
Os pacotes IP gerados localmente são os pacotes produzidos por aplicativos em execução no Mecanismo de Roteamento. O Junos OS escolhe um endereço de origem para esses pacotes para que os pares de aplicativos possam responder. Ele também permite especificar o endereço de origem por aplicativo. Para atender a essa finalidade, o comando Telnet CLI contém o source-address argumento.
Esta seção apresenta a default-address-selection declaração:
[edit system] default-address-selection;
Se você escolher especificamente o endereço de origem, como no caso da Telnet, default-address-selection não influenciará a seleção do endereço de origem. O endereço de origem torna-se o especificado com o source-address argumento (desde que o endereço seja um endereço válido especificado na interface de um roteador). Se o endereço de origem não for especificado ou se o endereço especificado for inválido, default-address-selection influenciará a seleção padrão do endereço de origem.
Se o endereço de origem não for explicitamente especificado como no caso da Telnet, então por padrão (quando default-address-selection não for especificado) o endereço de origem escolhido para pacotes IP gerados localmente é o endereço IP da interface de saída. Isso indica que, dependendo da interface de saída escolhida, o endereço de origem pode ser diferente para diferentes invocações de uma determinada aplicação.
Se a interface não for numerada (nenhum endereço IP é especificado em uma interface), o Junos OS usa um algoritmo previsível para determinar o endereço de origem padrão. Se default-address-selection for especificado, o Junos OS usa o algoritmo para escolher o endereço de origem, independentemente de a interface de saída estar numerada. Isso indica que, com default-address-selection, você pode influenciar o Junos OS a fornecer o mesmo endereço de origem em pacotes IP gerados localmente, independentemente da interface de saída.
O comportamento da seleção de endereços de origem pelo Junos OS pode ser resumido conforme mostrado na tabela a seguir:
| Interface de saída |
Quando |
Quando |
|---|---|---|
| Sem número |
Usar |
Usar |
| Numeradas |
Usar |
Use o endereço IP da interface de saída |
Consulte configuração de endereços e interfaces padrão, primárias e preferidas para obter mais informações sobre o algoritmo de seleção de origem do endereço padrão.
Para pacotes IP enviados por protocolos de roteamento IP (incluindo OSPF, RIP, RSVP e protocolos multicast, mas não incluindo IS-IS), a seleção de endereços locais costuma ser restringida pela especificação do protocolo para que o protocolo opere corretamente. Quando essa restrição existe no protocolo de roteamento, o endereço de origem do pacote não é afetado pela presença da default-address-selection declaração na configuração. Para protocolos em que o endereço local não é limitado pela especificação do protocolo, como IBGP e multihop EBGP, se você não configurar um endereço local específico ao configurar o protocolo, o endereço local é escolhido usando o mesmo método que outros pacotes IP gerados localmente.
Autenticação de TCP
Habilitar um método de autenticação de TCP melhora a segurança e garante a autenticidade dos segmentos de TCP trocados durante as sessões de BGP e LDP. Os dispositivos Junos oferecem suporte a três tipos principais de autenticação de TCP: TCP MD5, TCP Authentication Option (TCP-AO) e autenticação baseada em chaveiro TCP. Para obter mais informações sobre o TCP-AO, consulte TCP Authentication Option (TCP-AO).
Embora os dispositivos Junos ofereçam suporte aos métodos de autenticação TCP-AO e TCP MD5, você não pode usar ambos ao mesmo tempo para uma determinada conexão.
Suporte para sub-rede IP
Antes do Junos OS Evolved Release 22.4R1, os dispositivos Junos só permitem que você use a autenticação de TCP com um endereço específico. Isso significa que você só pode autenticar conexões TCP a pares remotos com endereços IP conhecidos.
A partir do Junos OS Evolved Release 22.4R1, TCP-AO e TCP MD5 autenticação oferecem suporte a sub-redes IP para sessões de LDP e BGP. Quando você configura a autenticação de TCP com um endereço de rede e um comprimento de prefixo, seu método de autenticação TCP escolhido autentica conexões TCP para toda a variedade de endereços sob essa sub-rede. Isso significa que você pode autenticar conexões TCP sem precisar saber os endereços IP exatos dos dispositivos de destino.
Quando as sub-redes IP se sobrepõem, o método de autenticação usa a combinação de prefixo (LPM) mais longa para determinar a chave de autenticação exata para uma sessão TCP específica.
BGP
Para configurar a autenticação baseada em prefixo para sessões BGP, inclua a allow (all | prefix-list) declaração em qualquer uma das seguintes hierarquias:
-
[edit protocols bgp group group-name] -
[edit protocols bgp group group-name dynamic-neighbor dyn-name]
Você pode usar endereços IPV4 ou IPV6 para a sub-rede.
Neste exemplo, o TCP MD5 autentica as conexões TCP com dispositivos na sub-rede 10.0.3.0/24 para todas as sessões BGP:
[edit protocols]
bgp {
group one {
authentication-key "$ABC123";
allow 10.0.3.0/24;
dynamic-neighbor dyn_one {
allow 10.0.3.0/24;
authentication-key "$ABC123";
}
}
}
LDP
Para configurar a autenticação baseada em prefixo para LDP, configure a autenticação de TCP sob a session-group ip-prefix hierarquia. Você deve usar um endereço IPv4.
Neste exemplo, o LDP usa o TCP-AO para autenticar qualquer conexão TCP com um dispositivo que tenha um endereço na sub-rede 10.0.0.0/24:
[edit protocols ldp]
session-group 10.0.0.0/24 {
authentication-algorithm ao;
authentication-key-chain tcpao;
}
Para saber como configurar seu chaveiro TCP-AO, consulte a Opção de Autenticação de TCP (TCP-AO).
Suporte para VRF
Em versões anteriores ao Junos OS Evolved Release 22.4R1, TCP MD5 e TCP-AO ignoram instâncias de roteamento e encaminhamento virtual (VRF). O dispositivo ignora as configurações TCP MD5 e TCP-AO em instâncias de roteamento não padrão. Quando você configura O TCP MD5 ou TCP-AO sob a instância VRF padrão, o dispositivo aplica esse método de autenticação a todas as sessões de TCP que têm destinos dentro da faixa de endereço IP para essa instância VRF. Se uma sessão de TCP pertencesse a uma instância VRF não padrão, mas tivesse o mesmo endereço IP de destino que a instância VRF padrão, o TCP MD5 e o TCP-AO aplicariam a mesma chave de autenticação a duas conexões TCP com o mesmo endereço IP de destino.
A partir do Junos OS Evolved Release 22.4R1, a autenticação do TCP-AO e do TCP MD5 são conscientes de VRF em sessões BGP e LDP. Você pode configurar o TCP-AO e o TCP MD5 em instâncias de roteamento não padrão. O método de autenticação de TCP que você configura em uma instância de roteamento é aplicado apenas às sessões de TCP dentro dessa instância VRF. Se uma conexão TCP em uma instância VRF diferente tiver o mesmo endereço IP de destino, o método de autenticação TCP não será aplicado a essa conexão TCP se a instância VRF não tiver a autenticação TCP configurada para o peer.
Configure a autenticação de TCP baseada em VRF como normalmente faria, mas em um routing-instances nível hierárquico. Para usar a autenticação TCP MD5, inclua a authentication-key authentication-key declaração. Para usar o TCP-AO, inclua as seguintes declarações:
user@device# set authentication-algorithm ao user@device# set authentication-key-chain keychain
Para saber como configurar seu chaveiro TCP-AO, consulte a Opção de Autenticação de TCP (TCP-AO).
Você pode combinar configurações conscientes de VRF com sub-redes IP. Isso permite autenticar conexões a uma variedade de endereços dentro da instância VRF.
BGP
Configure a autenticação de TCP baseada em VRF para sessões BGP em qualquer um dos seguintes níveis de hierarquia:
-
[edit routing-instances vrf-instance protocols bgp] -
[edit routing-instances vrf-instance protocols bgp group group-name] -
[edit routing-instances vrf-instance protocols bgp group group-name neighbor neighbor-ip] -
[edit routing-instances vrf-instance protocols bgp group group-name dynamic-neighbor dyn-name]
Se você configurar a autenticação baseada em VRF no dynamic-neighbor nível, inclua a declaração junto com a allow configuração do método de autenticação escolhido. Por exemplo, usar o TCP-AO com um vizinho dinâmico:
[edit routing-instances vrf-instance protocols bgp group group-name dynamic-neighbor dyn-name] user@device# set allow (all | prefix-list) user@device# set authentication-algorithm ao user@device# set authentication-key-chain keychain
No exemplo a seguir, o BGP usa a autenticação TCP para garantir a segurança das conexões TCP em uma instância VRF chamada vrf-one. No grupo um, o BGP usa o TCP MD5 para autenticar conexões ao vizinho com o endereço IP 10.0.1.1. Ele usa o TCP-AO para autenticar conexões ao vizinho com o endereço IP 10.0.1.2.
No grupo dois, o BGP usa o TCP-AO para autenticar conexões a qualquer dispositivo na sub-rede 10.0.0.0/24.
[edit routing-instances]
vrf-one {
protocols {
bgp {
group one {
peer-as 22;
neighbor 10.0.1.1 {
authentication-key "$ABC123"; ## SECRET-DATA
}
neighbor 10.0.1.2 {
authentication-algorithm ao;
authentication-key-chain tcpao;
}
}
group two {
peer-as 22;
dynamic-neighbor dyn_two {
allow 10.0.0.0/24;
authentication-algorithm ao;
authentication-key-chain tcpao;
}
}
}
}
}
LDP
Configure a autenticação baseada em VRF para sessões de LDP em qualquer um dos seguintes níveis de hierarquia:
-
[edit routing-instances vrf-instance protocols ldp] -
[edit routing-instances vrf-instance protocols ldp session session-ip] -
[edit routing-instances vrf-instance protocols ldp session-group ip-prefix]
Neste exemplo, o TCP-AO autentica conexões TCP em uma instância VRF chamada vrf-two. Ele autentica conexões TCP para o endereço 10.0.1.1, bem como qualquer endereço na sub-rede 10.0.0.0/24.
[edit routing-instances]
vrf-two {
protocols {
ldp {
session 10.0.1.1 {
authentication-algorithm ao;
authentication-key-chain tcpao;
}
session-group 10.0.0.0/24 {
authentication-algorithm ao;
authentication-key-chain tcpao;
}
}
}
}