As operadoras de rede e os engenheiros de segurança estão combatendo ataques e tentando proteger a rede enquanto, ao mesmo tempo, lutam com mais cargas de trabalho e custos relacionados à administração da rede. Ao incorporar a inteligência de segurança da Juniper Networks nos roteadores da Série MX, a segurança pode ser estendida à infraestrutura de roteamento para transformar camadas de conectividade em camadas de defesa automatizadas em escala. Essa combinação, disponível no JUNOS 19.3, ajuda as operadoras de rede a oferecer outro nível de segurança.
Como funciona?
A inteligência de segurança da Juniper Networks (SecIntel) fornece inteligência de ameaças em tempo real, permitindo a filtragem de tráfego automática e responsiva. Embora a SecIntel tradicionalmente necessite de um ou mais Gateways de Serviços SRX da Juniper Networks, a funcionalidade da SecIntel agora será disponibilizada nos roteadores da Série MX.
Estender a inteligência de segurança aos roteadores da Juniper série MX oferece outra camada de segurança de rede, bloqueando o tráfego de comando e controle descoberto pelo Juniper Sky ATP e pelo Juniper Threat Labs e listas negras personalizadas em um nível de hardware de rede. Isso transforma camadas de conectividade em camadas de defesa automatizadas. O roteador é transformado em um ponto de imposição de segurança da informação para milhares de clientes, ajudando a proteger a Internet para todos, uma rede por vez. Os clientes não precisarão investir em hardware adicional para aproveitar os novos recursos da SecIntel; apenas algumas linhas de configuração e uma atualização para a versão mais recente do software são necessárias. Por sua vez, isso simplifica a integração de rede e ajuda a minimizar o esforço administrativo.
Integração
O Juniper Connected Security protege os usuários, aplicativos e infra-estrutura, estendendo a inteligência de segurança e a fiscalização para todos os pontos de conexão da rede. Os clientes podem obter visibilidade e segurança de ponta a ponta, preservando os investimentos existentes. O Juniper Connected Security fornece integração automatizada pronta para uso entre os produtos da Juniper, fornecidos por nossos parceiros de tecnologia e até mesmo por nossos concorrentes. No entanto, ajudar os clientes a tirar o máximo proveito de seus investimentos não termina aqui. Ao trazer os recursos da SecIntel para os roteadores da Série MX, estamos dando aos clientes visibilidade do tráfego diretamente no ponto de conexão.
O bloqueio de URLs e URLs maliciosos conhecidos no nível de hardware / PFE usando os roteadores da série MX complementará os recursos e integrações existentes, como a proteção contra DDoS. A delegação do bloqueio de comunicações de comando e controle conhecidas aos roteadores da série MX impede o comprometimento potencial diretamente na camada de rede e libera recursos nos dispositivos da série SRX para se concentrar em ameaças desconhecidas direcionadas.
Sobre o ataque DDoS
No final de fevereiro de 2018, foi observado um ataque DDoS de grande volume. Foi um ataque de reflexão e amplificação do serviço memcached baseado em UDP, reportado como força de 1.4Tbpos.
O 1.4Tbps é mais que toda a capacidade de rede de muitos SP. O grande SP do mundo tem rede com maior capacidade, mas mesmo para eles - por que desperdiçar 10-20-30% de seus recursos para transportar tráfego malicioso? Então - DROP IT! E faça isso o mais cedo possível.
Mais sobre ataque pode ser encontrado aqui:
https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/http://www.zdnet.com/article/memcached-ddos-the-biggest-baddest-denial-of-service-attacker-yet/https://githubengineering.com/ddos-incident-report/
Também vale a pena ler sobre reflexão e amplificação aqui:
https://blog.cloudflare.com/reflections-on-reflections/https://blog.cloudflare.com/deep-inside-a-dns-amplification-ddos-attack/
O memcached é um serviço de rede que fornece banco de dados na memória. Do que eles são armazenados como pares de valor-chave, onde o valor pode ter tamanho arbitrário (grande). O princípio do ataque é plantar objetos únicos (muito poucos) no servidor do memcached e, em seguida, gerar solicitações de leitura para esse objeto em alta taxa usando o endereço de origem falsificado. Como os pedidos de leitura possuem apenas uma chave pequena e a resposta transporta um objeto inteiro, espera-se que o fator de amplificação seja igual a 1: 50.000. Então, 1Gbps de solicitações poderia potencialmente acionar 50Tbps de ataque…
O ataque de reflexão e amplificação do serviço memcached não é diferente de outro da classe. Ele é baseado em UDP, originado em servidores gerenciados abusados e não muito bem gerenciados e usa a porta de origem 11211 (porta de usuário registrada pela IANA para o serviço memcached). As portas de destino são aleatórias e o IP de destino é o IP da vítima.
Identificação vetorial de ataque
Primeiro de tudo - o uso do serviço de rede que fornece banco de dados na memória não é algo esperado pela Internet. Mas quem é o SP para julgar as práticas dos usuários finais? Como SP, deve-se carregar todo o tráfego com IP de destino válido.
Além disso, a porta UDP 11211 pertence ao espaço “user port” da IANA, o que significa que qualquer programa de espaço do usuário pode ser vinculado a essa porta. Mesmo se a IANA registrou a porta 11211 para o serviço memcached, ela não é uma alocação normativa (em contraste com as portas do sistema - abaixo do valor 1024). Qualquer usuário pode permitir que qualquer programa use a porta 11211 - e isso é perfeitamente legal e normal. (por exemplo, um pode executar o proxy SIP na porta UDP 11211)
Assim, o tráfego de descarte simples da porta UDP 11211 não é uma opção.
No entanto, quando atacar esses danos é detectado, algo precisa ser feito.
Infelizmente, se um ataque for detectado (e 'suspeito' eu devo dizer) baseado no fato de que determinado IP de destino está exposto a tráfego extremamente alto, a porta UDP 11211 (por exemplo, coleta e análise IPFIX), não significa que todo esse tráfego é um ataque memcached de reflexão e amplificação, com certeza. Pode ser uma mistura de tráfego legítimo do memcached, outro tráfego legítimo do aplicativo e ataque do memcached.
Descartando no roteador, todo o tráfego proveniente da porta UDP 11211 e destinado à vítima poderia levar ao descarte de tráfego legítimo, completando efetivamente o DDoS.
No entanto, há uma luz no fim do túnel.
Primeiro, podemos procurar padrões específicos do memcached na carga útil para evitar o descarte de pacotes de outros aplicativos que por coincidência usam a mesma porta UDP. (veja o exemplo abaixo)Segundo - você lembra que o ataque começou com o plantio de um objeto grande no memcached, que é então solicitado várias vezes? Isso significa que muitas respostas terão a mesma carga útil. Esta oportunidade de abertura para descartar mais tráfego malicioso no próprio roteador.
Para resumir, veja o caso A. sozinho - o mecanismo de detecção de DDoS identifica o vetor de ataque da seguinte forma:
Src IP: aleatório, possivelmente múltiplos de 1000
Protoco: UDP
Comprimento do pacote: 1442 ou 1446
Porta Src: 11211
Dst I: IP da vítimaCarga: 0x0000 a partir de 14 th de bytes de carga útil de UDP. (bits reservados no protocolo memcached)
Mitigação de ataque no MX.
Então, temos que descartar o tráfego que coincide com a característica acima. Isso significa que para cada pacote precisamos verificar os valores que ele carrega em certos campos de cabeçalho L3 e L4… e na carga útil. Nem todo roteador de peering pode fazer isso, mas o Juniper MX pode. E é o roteador de peering de grande escala mais popular usado.
Todas as versões do JUNOS suportadas atualmente suportam a construção 'flexible-match-filter'. Também todas as versões das placas de linha MPC , mesmo as mais antigas - 16x10GE MPC - suportam este tipo de correspondência. Então, o que precisamos fazer é configurar o MX com algo como:
firewall {
família inet {
filtrar DDOS-MITIGATE {
[…]
termo MEMCACHD-AMP-RQ {
de {
Endereço de Origem {
1.1.1.1/32;
1.2.1.1/32;
}
protocolo udp;
porta de destino 11211;
flexível-match-mask {
máscara-em-hexadecimal 0xFFFFF;
prefixo 0x00010000;
nome da máscara flexível MEMCACHED-RD-REQ;
}
}
então {
[…]
}
}
prazo MEMCACHD-AMP-RSPD {
de {
endereço de destino {
1.1.1.1/32;
1.2.1.1/32;
}
comprimento de pacote [1442 1446];
protocolo udp;
porta de origem 11211;
flexível-match-mask {
máscara-em-hexadecimal 0xFFFF;
prefixo 0x0000;
nome de máscara flexível MEMCACHED-RD-RSPD;
}
}
então {
[…]
}
}
[…]
}
}
correspondência flexível MEMCACHED-RD-RSPD {
match-start layer-4;
byte-offset 14;
bit-offset 0;
comprimento de bit 16;
}
Correspondência flexível MEMCACHED-RD-REQ {
match-start layer-4;
byte-offset 12;
bit-offset 0;
bit comprimento 32;
}
}
Observe que temos dois termos aqui - MEMCACHD-AMP-RSPD - corresponde a todo o tráfego de memcached enviado pelo servidor, conforme identificado pelo mecanismo de detecção de DDoS. O MEMCACHD-AMP-RQ corresponde ao pedido do memcached que aciona respostas amplificadas acima. Dependendo da posição do atacante na Internet, o pedido pode não ter que atravessar determinado roteador, mas vale a pena aplicar este termo apenas no caso.
Obviamente, ninguém espera que o operador do NOC o coloque em múltiplos MX manualmente digitando no console. Novamente, o JUNOS - o sistema operacional de rede mais popular para roteadores de peering - está aqui para ajudar. Você pode usar a extraordinária capacidade de automação do JUNOS e carregar acima da configuração de vida curta em DB efêmero via protocolo NetConf padrão. A configuração efêmera DB traz os seguintes benefícios:
permitir que as alterações sejam feitas com muita rapidez, sem analisar e auditar toda a configuração,
fornece separação de alterações de saída curta feitas por controle (por exemplo, regras de proteção contra DDoS - o tempo de ativação é de horas) a partir da configuração permanente da linha de base (que dura anos).
Abaixo, o simples script python / PyEZ está carregando e confirmando a regra de filtro acima no DB efêmero:
from jnpr.junos import Dispositivo
do lxml import etree
do jnpr.junos.utils.config import Config
dev = Device (host = '11.11.11.11 ', usuário = ' bar ', senha = ' foo ')
dev.open ()
DDOS-MITIGATE_FF = “<firewall> <família> <inet> <filtro> <nome> DDOS-MITIGATE </ name> <termo>
<nome> MEMCACHD-AMP-RQ </ name> <de> <endereço de origem> <name> 1.1.1.1/32 </ name> </ source-address>
<endereço-fonte> <nome> 1.2.1.1/32 </ name> </ endereço-fonte> <protocolo> udp </ protocol> < porta de destino> 11211 </ destination-port>
<máscara de correspondência flexível> <máscara-em-hexadecimal> 0xFFFFF </ mask-in-hex> <prefixo> 0x00010000 </ prefix>
<nome-da-máscara-flexível> MEMCACHED -RD-REQ </ nome da máscara flexível> </ flexible-match-mask> </ from>
<então> <count> MEMCACHD-AMP-RQ </ count> <descartar> </ discard> </ then> </ term>
<term> <nome> MEMCACHD-AMP-RSPD </ name> <de> <endereço de destino> <nome> 1.1.1.1/32 </ name> </ destination-address>
<endereço de destino> <nome> 1.2.1.1/32 </ name> </ destination-address>
<tamanho do pacote> 1442 </ packet-length> <comprimento do pacote> 1446 </ packet-length> <protocol> udp </ protocol>
<porta-fonte> 11211 </ source-port> <máscara-de-correspondência-flexível> <máscara-em-hexágono> 0xFFFF </ mask-in-hex> <prefixo> 0x0000 </ prefix>
<flexível -mask-name> MEMCACHED-RD-RSPD </ nome-da-maquete-flexível> </ flexible-match-mask> </ de>
<então> <count> MEMCACHD-AMP-RSPD </ count> <descarte> </ descarte> </ then> </ term> </ filter> </ inet> </ family>
<correspondência flexível> <nome> MEMCACHED-RD-RSPD </ name> <partida-partida> camada-4 </ match -iniciar><deslocamento de byte> 14 </ byte-offset>
< deslocamento de bit> 0 </ bit-offset> <comprimento de bit> 16 </ bit-length> </ flexível-correspondência> <flexível-correspondência> <nome> MEMCACHED-RD-REQ </ name>
<partida-partida> camada-4 </ partida-de-partida> <byte-offset> 12 </ byte-offset> <bit-offset> 0 <bit-offset>
<comprimento de bit> 32 </ bit-length> </ flexible-match> </ firewall> "
com Config (dev, mode = ' efêmero ', ephemeral_instance = "DDOS-DETECTION") como cu:
cu.load (DDOS-MITIGATE_FF)
cu.commit ()
dev.close ()
Conclusão
A combinação dos recursos de filtragem e automação MX / JUNOS permite a SP para mitigação cirúrgica de ataques de amplificação em massa, sem a necessidade de obter terabits de capacidade de depuradores de compilação DPI / fins. O ataque de terabit é mitigado apenas na entrada na rede - no roteador de peering.
ASG
https://www.asgit.com.br/
contato@asg.com.br
(51) 3376.1210
Comments