All posts by Omer Yoachimik

Tendências de ataques DDoS no segundo trimestre de 2022

2022-07-06 Omer Yoachimik

Post Syndicated from Omer Yoachimik original https://blog.cloudflare.com/ddos-attack-trends-for-2022-q2-pt-br/

Tendências de ataques DDoS no segundo trimestre de 2022

Bem-vindo ao nosso relatório de DDoS do segundo trimestre de 2022. Este relatório inclui informações e tendências sobre o cenário de ameaças DDoS — conforme observado em toda a Rede global da Cloudflare. Uma versão interativa deste relatório também está disponível no Radar.

No segundo trimestre deste ano, aconteceram os maiores ataques da história, incluindo um ataque DDoS por HTTPS de 26 milhões de solicitações por segundo que a Cloudflare detectou e mitigou de forma automática. Além disso, os ataques contra a Ucrânia e a Rússia continuam, ao mesmo tempo em que surgiu uma campanha de ataques DDoS com pedido de resgate.

Destaques

Internet na Ucrânia e na Rússia

A guerra no terreno é acompanhada por ataques direcionados à distribuição de informações.
Empresas de mídia de radiodifusão na Ucrânia foram as mais visadas por ataques DDoS no segundo trimestre. Na verdade, todos os seis principais setores vitimados estão na mídia on-line/internet, publicações e radiodifusão.
Por outro lado, na Rússia, a mídia on-line deixou de ser o setor mais atacado e caiu para o terceiro lugar. No topo, estão empresas como bancos, serviços financeiros e seguros (BFSI, na sigla em inglês) do país, que foram as mais visadas no segundo trimestre; sendo vítimas de quase 50% de todos os ataques DDoS na camada de aplicativos. O segundo lugar é das empresas de criptomoedas.

Ataque DDoS com pedido de resgate

Detectamos uma nova onda de ataques DDoS com pedido de resgate realizados por entidades que alegam ser a Fancy Lazarus.
Em junho de 2022, houve o maior pico do ano nos ataques DDoS com pedido de resgate até agora: um em cada cinco participantes na pesquisa que passaram por um ataque DDoS relataram ter recebido um pedido de resgate ou outras ameaças.
No T2 em geral, o percentual de ataques DDoS com pedido de resgate aumentou 11% na comparação com o trimestre anterior.

Ataques DDoS na camada de aplicativos

No segundo trimestre de 2022, houve um aumento de 44% em termos anuais nos ataques DDoS na camada de aplicativos.
Empresas nos EUA foram as maiores vítimas, seguidas por outras no Chipre, em Hong Kong e na China. Os ataques à empresas do Chipre aumentaram 171% na comparação trimestral.
O setor de aviação e aeronáutica foi o mais visado no segundo trimestre, seguido por: internet, bancos, serviços financeiros, seguros, jogos e apostas.

Ataques DDoS na camada de rede

No segundo trimestre de 2022, houve um aumento de 75% em termos anuais nos ataques DDoS na camada de rede. Ataques de 100 Gbps e mais cresceram 19% em termos trimestrais; e ataques com mais de três horas aumentaram em 9% no mesmo período.
Os setores mais atacados foram: telecomunicações, jogos/apostas e tecnologia e serviços de informação.
Empresas nos EUA foram as maiores vítimas, seguidas por outras em Singapura, na Alemanha e na China.

Este relatório é baseado nos ataques DDoS detectados e mitigados automaticamente pelos sistemas de proteção contra DDoS da Cloudflare. Para saber mais sobre como isso funciona, confira este post no blog com mais detalhes.

Uma observação sobre como medimos os ataques DDoS observados em nossa Rede

Para analisar tendências de ataques, calculamos a taxa de “atividade DDoS”, que é o percentual do tráfego de ataque com relação ao tráfego total (ataque + limpo) observado em nossa Rede global, em um local específico ou em uma determinada categoria (por exemplo, setor ou país de faturamento). Medir os percentuais nos permite normalizar os pontos de dados e evitar uma abordagem tendenciosa em números absolutos, envolvendo, por exemplo, um data center da Cloudflare que recebe mais tráfego total e, provavelmente, mais ataques.

Ataques com pedido de resgate

Nossos sistemas estão constantemente analisando o tráfego e ao detectar ataques DDoS, automaticamente aplicam a mitigação. Cada cliente que sofre um ataque DDoS recebe uma pesquisa automatizada a fim de nos ajudar a entender melhor a natureza do ataque e o êxito da mitigação.

Há mais de dois anos a Cloudflare realiza pesquisas junto a clientes que foram atacados — uma das perguntas da pesquisa destina-se a saber se eles receberam ameaças ou pedidos de resgate exigindo pagamento em troca de parar o ataque DDoS.

O número de participantes que relatou ameaças ou pedidos de resgate no segundo trimestre aumentou 11% em termos trimestrais e anuais. Durante este trimestre, mitigamos ataques DDoS com pedido de resgate realizados por entidades que alegavam ser o grupo de ameaças avançadas permanentes (APT, na sigla em inglês) conhecido como “Fancy Lazarus”. A iniciativa se concentrou em instituições financeiras e empresas de criptomoedas.

Analisando o segundo trimestre em mais detalhes, é possível ver que em junho um em cada cinco participantes relataram ataques DDoS com pedido de resgate ou ameaças — o mês com maior volume em 2022, o mais alto desde dezembro de 2021.

Ataques DDoS na camada de aplicativos

Ataques DDoS na camada de aplicativos, especificamente ataques DDoS por HTTP, são ataques que normalmente buscam interromper um servidor web tornando-o incapaz de processar solicitações legítimas dos usuários. Se um servidor é bombardeado com mais solicitações do que consegue processar, ele descartará solicitações legítimas e — em alguns casos — irá travar, resultando na deterioração da performance ou em uma interrupção para os usuários legítimos.

Ataques DDoS na camada de aplicativos por mês

No segundo trimestre, houve um aumento de 44% em termos anuais nos ataques DDoS na camada de aplicativos.

No T2 em geral, o volume de ataques DDoS na camada de aplicativos aumentou 44% na comparação anual, mas caiu 16% em termos trimestrais. Maio foi o mês mais movimentado no trimestre. Quase 47% de todos os ataques DDoS na camada de aplicativos ocorreu em maio, ao passo que o mês de junho foi o que teve o menor número de ataques (18%).

Ataques DDoS na camada de aplicativos por setor

Ataques ao setor de aviação e aeronáutica cresceram 256% em termos trimestrais

No segundo trimestre, o setor de aviação e aeronáutica foi o mais visado com ataques DDoS na camada de aplicativos. Depois, estão os setores de bancos, instituições financeiras e seguros (BFSI), e em terceiro lugar o setor de jogos/apostas.

Espaços cibernéticos da Ucrânia e da Rússia

Empresas de mídia e publicação são as mais visadas na Ucrânia.

Enquanto a guerra na Ucrânia continua em campo, no ar e na água, outra guerra é travada no espaço cibernético. Entidades que visam empresas ucranianas parecem estar tentando silenciar informações. Os seis setores mais atacados na Ucrânia estão todos em radiodifusão, internet, mídia on-line e publicação — quase 80% de todos os ataques DDoS ao país.

No outro lado da guerra, bancos, instituições financeiras e empresas de seguro (BFSI) da Rússia são os que sofreram mais ataques. Quase 50% de todos os ataques DDoS foram contra o setor de BFSI. O segundo setor mais visado é o de criptomoedas, seguido por mídia on-line.

Em ambos os lados da guerra, é possível ver que os ataques são altamente distribuídos, o que indica o uso de botnets distribuídas globalmente.

Ataques DDoS na camada de aplicativos por país de origem

No segundo trimestre, os ataques da China aumentaram 112, enquanto dos EUA diminuíram 43%.

Para entender a origem dos ataques HTTP, analisamos a geolocalização do endereço de IP de origem do cliente que gerou as solicitações HTTP de ataque. Ao contrário dos ataques na camada de rede, os IPs de origem não podem ser falsificados em ataques HTTP. Uma alta porcentagem de atividade DDoS em um determinado país não indica que os ataques estão vindo desse local, mas significa que há botnets funcionando dentro das fronteiras da nação em questão.

Pelo segundo trimestre consecutivo, os Estados Unidos estão no topo da lista como principal origem de ataques DDoS por HTTP. Logo depois estão China, Índia e Alemanha. Mesmo que os EUA tenham permanecido em primeiro lugar, os ataques com origem no país tiveram uma queda de 43% em termos trimestrais, ao passo que os originados em outras regiões aumentaram (China em 112%, Índia em 89% e Alemanha em 80%).

Ataques DDoS na camada de aplicativos por país-alvo

A fim de identificar quais países eram visados pela maioria dos ataques DDoS por HTTP, agrupamos os ataques DDoS pelos países de faturamento de nossos clientes e os representamos como porcentagem em relação ao total de ataques DDoS.

Ataques DDoS por HTTP em países baseados nos EUA aumentaram 45% na comparação trimestral, levando os EUA ao primeiro lugar como principal alvo de ataques DDoS na camada de aplicativos. Ataques a empresas chinesas diminuíram 79% em termos trimestrais, aindo do primeiro para o quarto lugar. Ataques no Chipre aumentaram 171%, o que tornou o país o segundo mais atacado no segundo trimestre, seguido por Hong Kong, China e Polônia.

Ataques DDoS na camada de rede

Enquanto os ataques na camada de aplicativo visam o aplicativo (Camada 7 do Modelo OSI) que executa o serviço que os usuários finais estão tentando acessar (HTTP/S em nosso caso), os ataques na camada de rede visam sobrecarregar a infraestrutura de rede (como roteadores e servidores internos) e a próprio link com da internet.

Ataques DDoS na camada de rede por mês

No segundo trimestre, houve um aumento de 75% em termos anuais nos ataques DDoS na camada de rede; e uma alta de 19% na comparação trimestral em ataques volumétricos de 100 Gbps e mais.

No segundo trimestre, o número total de ataques DDoS à camada de rede aumentou 75% em termos anuais, mas não mudou muito em comparação com o trimestre anterior. Abril foi o mês mais movimentado do trimestre, com quase 40% dos ataques.

Ataques DDoS na camada de rede por setor

No segundo trimestre, ataques a empresas de telecomunicações cresceram 45% em termos trimestrais.

Pelo segundo trimestre consecutivo, o setor de telecomunicações foi o mais visado por ataques DDoS na camada de rede. Além disso, os ataques a empresas de telecomunicações cresceram 45% em termos trimestrais. O setor de jogos ficou em segundo lugar, seguido por empresas de tecnologia e serviços de informação.

Ataques DDoS na camada de rede por país-alvo

Aumento de 70% em termos trimestrais nos ataques a redes dos EUA

No segundo trimestre, os EUA continuaram sendo o país mais atacado, seguido por Singapura, que saltou para o segundo lugar em relação ao quarto no trimestre anterior. Logo depois, em terceiro, está a Alemanha, seguida por China, Maldivas e Coreia do Sul.

Ataques DDoS na camada de rede por país de entrada

No segundo trimestre, quase um terço do tráfego observado pela Cloudflare na Palestina e no Azerbaijão foi parte de um ataque DDoS à camada de rede.

Ao tentar entender onde fica a origem de ataques DDoS na camada de rede, não podemos seguir o mesmo método usado para a análise de ataques na camada de aplicativos. Para que um ataque DDoS na camada de aplicativos aconteça, é preciso ocorrer handshakes bem-sucedidos entre o cliente e o servidor, a fim de estabelecer uma conexão HTTP/S. E para um handshake bem-sucedido acontecer, os ataques não podem falsificar o endereço de IP da origem. Embora o invasor possa usar botnets, proxies e outros métodos para ofuscar a identidade, o local do IP de origem do cliente, que faz o ataque, representa adequadamente a origem de ataques DDoS na camada de aplicativos.

Por outro lado, para lançar ataques DDoS na camada de rede, na maioria dos casos, não é necessário nenhum handshake. Os invasores podem falsificar o endereço de IP de origem para ofuscar a origem do ataque e introduzir aleatoriedade nas propriedades do ataque, o que pode dificultar que sistemas simples de proteção contra DDoS bloqueiem o ataque. Dessa forma, se formos tentar descobrir o país de origem com base em um endereço de IP falsificado, obteríamos um “país falsificado”.

Por esse motivo, ao analisar origens de ataques DDoS na camada de rede, dividimos o tráfego pelos locais de data centers da Cloudflare em que o tráfego foi ingerido, e não pelo IP de origem (possivelmente) falsificado, para entender melhor de onde os ataques vêm. Conseguimos ter precisão geográfica em nosso relatório porque temos data centers em mais de 270 cidades em todo o mundo. No entanto, até esse método não é 100% preciso, pois o tráfego pode passar por backhaul e ser direcionado por meio de diversos provedores de internet e países, por motivos que variam da redução de custos até à gestão de falhas e congestionamentos.

A Palestina saiu do segundo para o primeiro lugar como local da Cloudflare com maior percentual de ataques DDoS à camada de rede, seguida por Azerbaijão, Coreia do Sul e Angola.

Para visualizar todas as regiões e países, confira o mapa interativo.

Vetores de ataque

No segundo trimestre, houve um aumento dos ataques de DNS, e essa modalidade se tornou o segundo vetor de ataque mais frequente.

Vetor de ataque é o termo usado para descrever o método usado pelo invasor para lançar um ataque DDoS. Por exemplo, o protocolo IP, atributos de pacote, como sinalizadores TCP, método de inundação e outros critérios.

No segundo trimestre, 56% de todos os ataques na camada de rede foram inundações SYN, que ainda são o vetor de ataque mais popular e exploram a solicitação de conexão inicial do handshake TCP com estado. Durante essa solicitação de conexão inicial, os servidores não têm nenhum contexto sobre a conexão TCP, pois ela é nova; e sem a proteção adequada, pode ser difícil mitigar uma inundação de solicitações de conexão inicial. Assim fica mais fácil para o invasor consumir os recursos de um servidor desprotegido.

Após as inundações SYN, estão os ataques direcionados à infraestrutura DNS, inundações RST que exploram o fluxo de conexão TCP e ataques genéricos por UDP.

Ameaças emergentes

No segundo trimestre, as principais ameaças emergentes incluíram ataques por CHARGEN, Ubiquiti e Memcached.

Identificar os principais vetores de ataques ajuda as empresas a entender o cenário de ameaças. Por sua vez, isso as ajuda a melhorar a postura de segurança para se protegerem contra essas ameaças. Da mesma forma, aprender sobre novas ameaças emergentes, que ainda não representam uma parte significativa dos ataques, pode ajudar a mitigá-los antes que se tornem uma força expressiva.

No segundo trimestre, as principais ameaças emergentes foram ataques de amplificação que exploram o protocolo gerador de caracteres (CHARGEN), que desviam o tráfego de dispositivos Ubiquiti expostos e o conhecido ataque Memcached.

Abuso do protocolo CHARGEN para realizar ataques de amplificação

No segundo trimestre, ataques ao protocolo CHARGEN aumentaram 378% em termos trimestrais.

Definido inicialmente em RFC 864 (1983), o protocolo gerador de caracteres (CHARGEN) é um serviço da pilha de protocolos de internet que faz exatamente isso: gera caracteres de forma aleatória e não para de enviá-los ao cliente até ele encerrar a conexão. A intenção original era fazer teste e depuração. No entanto, é raramente usado, porque é muito fácil de explorar para gerar ataques de reflexão/amplificação.

Um invasor pode falsificar o IP de origem da vítima e enganar os servidores de apoio em todo o mundo para direcionar um fluxo de caracteres aleatórios “de volta” os servidores da vítima. Esse tipo de ataque é de reflexão/amplificação. Dependendo do número de fluxos CHARGEN simultâneos, se os servidores da vítima estiverem desprotegidos, serão inundados e não conseguirão processar o tráfego legítimo — resultando em um evento de negação de serviço.

Ataques de amplificação que exploram o protocolo de descoberta Ubiquiti

No segundo trimestre, ataques por Ubiquiti aumentaram 313% em termos trimestrais.

Ubiquiti é uma empresa americana que oferece dispositivos de Internet of Things (IoT) a consumidores e empresas. Os dispositivos da Ubiquiti podem ser descobertos em uma rede pelo protocolo de descoberta Ubiquiti na porta UDP/TCP 10001.

Semelhante ao vetor de ataque CHARGEN, os invasores podem falsificar o IP de origem para o endereço de IP da vítima e pulverizar os endereços de IP que estão com a porta 10001 aberta. Esses então responderiam à vítima e inundariam se o volume for suficiente.

Ataque DDoS ao Memcached

No segundo trimestre, ataques DDoS ao Memcached cresceram 281% em termos trimestrais.

Memcached é um sistema de caching de banco de dados para acelerar sites e redes. Semelhante ao CHARGEN e Ubiquiti, os servidores Memcached compatíveis com UDP podem ser aproveitados para iniciar ataques DDoS de amplificação/reflexão. Nesse caso, o invasor solicita conteúdo do sistema de caching e falsificam o endereço de IP da vítima como IP de origem nos pacotes UDP. A vítima será inundada com as respostas Memcache, que podem ser amplificadas por um fator de até 51.200x.

Ataques DDoS na camada de rede por taxa de ataque

Ataques volumétricos de mais de 100 Gbps aumentaram 19% em termos trimestrais. Ataques com mais de três horas cresceram 9%.

Existem diferentes maneiras de medir o tamanho de um ataque DDoS nas camadas 3 e 4. Uma é o volume de tráfego que ele fornece, medido como taxa de bits (especificamente, terabits por segundo ou gigabits por segundo). Outra é o número de pacotes que ele entrega, medido como taxa de pacotes (especificamente, milhões de pacotes por segundo).

Os ataques com altas taxas de bits tentam causar um evento de negação de serviço saturando a conexão com a internet, enquanto os ataques com altas taxas de pacotes tentam sobrecarregar os servidores, roteadores ou outros dispositivos de hardware em linha. Os dispositivos dedicam uma certa quantidade de memória e capacidade de computação para processar cada pacote. Portanto, ao bombardeá-los com muitos pacotes, os dispositivos podem ficar sem recursos de processamento. Nesse caso, os pacotes são “descartados,” ou seja, o dispositivo não consegue processá-los. Para os usuários, isso resulta em interrupções e em negação de serviço.

Distribuição por taxa de pacotes

A maioria dos ataques DDoS na camada de rede permanecem abaixo de 50 mil pacotes por segundo. Embora 50 kpps esteja no lado inferior do espectro na escala da Cloudflare, isto ainda pode derrubar facilmente ativos da internet desprotegidos e congestionar até mesmo uma conexão Ethernet Gigabit padrão.

Ao analisar as mudanças nos tamanhos dos ataques, vemos que houve uma queda em ataques com uso intenso de pacotes acima de 50 kpps no segundo trimestre, resultando em um aumento de 4% nos ataques menores.

Distribuição por taxa de bits

No segundo trimestre, a maioria dos ataques DDoS na camada de rede ficaram abaixo de 500 Mbps. Também é uma gota no oceano se pensarmos na escala da Cloudflare, mas que pode desconectar rapidamente ativos da internet desprotegidos com menos capacidade ou até congestionar uma conexão Ethernet Gigabit padrão.

É interessante ver que ataques grandes entre 500 Mbps e 100 Gbps diminuíram de 20% a 40% em termos trimestrais, mas ataques volumétricos acima de 100 Gbps cresceram 8%.

Ataques DDoS na camada de rede por duração

No segundo trimestre, ataques com mais de três horas aumentaram 9%.

Medimos a duração de um ataque registrando a diferença entre quando ele foi detectado pela primeira vez por nossos sistemas como um ataque e o último pacote que vimos com a assinatura desse ataque no alvo específico.

No segundo trimestre, 51% dos ataques DDoS à camada de rede duraram menos de 10 minutos, e 41% duraram de 10 a 20 minutos. Os 8% restantes incluem ataques que vão de 20 minutos até mais de 3 horas.

Vale lembrar que mesmo quando um ataque tem apenas alguns minutos, se ele for bem-sucedido, as consequências podem durar mais do que o próprio ataque. Os profissionais de TI que lidam com ataques bem-sucedidos podem passar horas e até dias restaurando serviços.

Embora a maioria dos ataques realmente sejam curtos, é possível ver um aumento de mais de 15% em ataques de 20 a 60 minutos, bem como um crescimento de 12% em ataques com mais de 3 horas.

Ataques curtos podem facilmente passar despercebidos, especialmente ataques burst que, em segundos, bombardeiam um alvo com um número significativo de pacotes, bytes ou solicitações. Nesse caso, os serviços de proteção contra DDoS, que contam com mitigação manual por meio de análise de segurança, não conseguem mitigar o ataque a tempo. Eles podem apenas aprender com esse ataque durante a análise pós-ataque e, em seguida, implantar uma nova regra que filtre o identificador do ataque, esperando capturá-lo na próxima vez. Da mesma forma, também é ineficiente usar um serviço “sob demanda”, em que a equipe de segurança redireciona o tráfego para um provedor de DDoS durante o ataque, uma vez que o ataque já terá terminado antes que o tráfego seja encaminhado para o provedor de DDoS sob demanda.

É recomendável que as empresas utilizem serviços de proteção contra DDoS automatizados sempre ativos, que analisem o tráfego e apliquem a identificação em tempo real com rapidez suficiente para bloquear ataques de curta duração.

Resumo

A missão da Cloudflare é ajudar a construir uma internet melhor, ou seja, mais segura, mais rápida e mais confiável para todos, até mesmo ao enfrentar ataques DDoS. Como parte de nossa missão, desde 2017 oferecemos proteção contra DDoS ilimitada e sem restrições, além de gratuita, para todos os nossos clientes. Ao longo dos anos, tornou-se cada vez mais fácil para os invasores lançar ataques DDoS. Para combater a vantagem do invasor, queremos garantir que também seja fácil e gratuito para organizações de todos os tamanhos se protegerem contra ataques DDoS de todos os tipos.
Ainda não usa a Cloudflare? Comece agora com os planos Free e Pro para proteger sites ou fale conosco para ter uma proteção contra DDoS mais abrangente para toda a rede usando o Magic Transit.

2022년 2분기 DDoS 공격 동향

2022-07-06 Omer Yoachimik

Post Syndicated from Omer Yoachimik original https://blog.cloudflare.com/ddos-attack-trends-for-2022-q2-ko-kr/

2022년 2분기 DDoS 공격 동향

2022년 2분기 DDoS 보고서에 오신 것을 환영합니다. 이 보고서에는 Cloudflare 네트워크 전반에서 관찰된 DDoS 위협 환경에 대한 인사이트와 동향이 담겨있습니다. 이 보고서의 인터랙티브 버전을 Radar에서도 이용할 수 있습니다.

2분기에 우리는 Cloudflare에서 자동으로 감지하고 대처한 초당 2,600만 회의 요청이 이루어진 HTTPS DDoS 공격을 포함하여 사상 최대 규모의 공격을 경험했습니다. 또한, 우크라이나와 러시아에 대한 공격은 지속되고 있으며, 새로운 랜섬 DDoS 공격이 등장하였습니다.

주요 특징

우크라이나와 러시아에서의 인터넷

지상에서의 전쟁은 정보 전파를 겨냥하는 공격과 함께 이루어집니다.
2분기에 가장 많은 DDoS 공격이 이루어진 대상은 우크라이나의 방송매체 회사들이었습니다. 실제로, 가장 많은 공격을 받은 상위 6개 산업은 모두 온라인/인터넷 매체, 출판, 방송 분야에 속했습니다.
반면, 러시아의 경우 온라인 매체는 가장 많은 공격을 받은 산업 순위에서 3위로 처집니다. 온라인 매체보다 순위가 높은 산업을 보면 러시아의 은행, 금융 서비스 및 보험(BFSI) 회사들이 2분기에 공격을 가장 많이 받았고, 전체 응용 프로그램 계층 DDoS 공격의 거의 50%가 BFSI 분야를 대상으로 했습니다. 두 번째로 공격을 많이 받은 것은 암호화폐 회사들이었습니다.

개방형 인터넷이 러시아로 계속 유입되도록 하고 공격이 외부로 유출되지 않도록 차단하기 위해 Cloudflare에서 어떤 일을 하는지 자세히 읽어보세요.

랜섬 DDoS 공격

우리는 팬시 라자러스(Fancy Lazarus)라고 자칭하는 공격자들에 의한 랜섬 DDoS 공격이 급증하는 것을 목격했습니다.
2022년 6월에는 랜섬 공격 건수가 올해 들어 최고 수준으로 늘어났습니다. DDoS 공격을 경험한 설문 응답자 5명 중 1명이 랜섬 DDoS 공격이나 기타 위협의 대상이 되었다고 응답했습니다.
2분기 전체로 보면 랜섬 DDoS 공격의 비율은 이전 분기 대비 11% 증가하였습니다.

응용 프로그램 계층 DDoS 공격

2022년 2분기에 응용 프로그램 계층 DDoS 공격은 전년 대비 44% 증가하였습니다.
가장 많이 공격의 대상이 된 것은 미국의 조직들이었고, 키프로스, 홍콩, 중국이 그 뒤를 이었습니다. 키프로스 내 조직들에 대한 공격은 이전 분기 대비 171% 증가했습니다.
2분기에 가장 많은 공격을 받은 산업은 항공우주 산업이었으며, 인터넷, BFSI, 그리고 4위의 게임/도박 산업이 그 뒤를 이었습니다.

네트워크 계층 DDoS 공격

2022년 2분기에 네트워크 계층 DDoS 공격은 전년 대비 75% 상승하였습니다. 100Gbps 이상의 공격은 이전 분기 대비 19%, 3시간 이상 지속된 공격 횟수는 이전 분기 대비 9% 증가하였습니다.
가장 많은 공격을 받은 산업은 이동통신, 게임/도박, 정보기술, 서비스 산업이었습니다.
가장 많이 공격의 대상이 된 것은 미국의 조직들이었고, 싱가포르, 독일, 중국이 그 뒤를 이었습니다.

이 보고서는 Cloudflare의 DDoS 방어 시스템에서 자동으로 감지되어 완화된 DDoS 공격을 기반으로 한 것입니다. 이 시스템의 원리에 대해 자세히 알아보려면 이 심층 블로그 게시물을 참고하세요.

우리가 네트워크에서 관찰된 DDoS 공격을 측정하는 방식

우리는 공격 동향을 분석하기 위해 “DDoS 활동” 비율을 측정합니다. 이는 우리의 전역 네트워크 또는 특정 위치 또는 특정 범주(예: 산업 또는 청구서 발행 국가)에서 관찰된 총 트래픽(공격 트래픽 + 정상 트래픽) 중 공격 트래픽의 비율을 의미합니다. 해당 트래픽 비율을 측정하면 데이터 포인트를 정규화하고, 예를 들어 더 많은 총 트래픽을 수신하면서 더 많은 공격을 받을 가능성이 있는 Cloudflare 데이터 센터에 대한 절대 수치에 편향이 반영되지 않도록 할 수 있습니다.

랜섬 공격

우리의 시스템은 지속해서 트래픽을 분석하면서, DDoS 공격이 감지되면 자동으로 완화 조치를 적용합니다. DDoS 공격을 당한 각 고객에게는 자동 설문이 표시되어 당사에서 공격의 특성을 보다 자세히 파악하고 완화에 성공하는 데 도움이 됩니다.

현재 2년 여에 걸쳐 Cloudflare는 공격을 받은 고객들을 대상으로 설문을 진행하고 있으며, 질문 중 하나로 DDoS 공격을 멈추는 대가로 돈을 요구하는 위협이나 랜섬 노트를 받았는지 물었습니다.

2분기에 위협이나 협박 메일을 받은 응답자의 수는 이전 분기 및 전년 대비 11% 상승하였습니다. 이번 분기 내내 우리는 지능형 지속 위협(APT) 집단 “팬시 라자러스”라고 자칭하는 공격자들이 실행한 랜섬 DDoS 공격을 완화해 왔습니다. 공격은 주로 금융기관과 암호화폐 회사에 집중되었습니다.

2분기를 더 자세히 살펴보면, 6월에 응답자 5명 중 1명이 랜섬 DDoS 공격을 받았거나 위협을 받았다고 응답했습니다. 이는 2022년 들어 응답 비율이 가장 높은 한 달이었으며, 2021년 12월 이후 가장 높은 수치입니다.

응용 프로그램 계층 DDoS 공격

응용 프로그램 계층 DDoS 공격 중 특히 HTTP DDoS 공격은 주로 웹 서버가 합법적인 사용자 요청을 처리할 수 없도록 하여 웹 서버를 사용 불가능하게 만드는 것을 목표로 합니다. 서버가 처리할 수 있는 양보다 많은 요청이 쏟아질 경우, 해당 서버는 합법적인 요청의 처리를 중단하게 되고, 경우에 따라서는 충돌을 일으켜 성능이 저하되거나 합법적인 사용자의 서비스도 거부하게 됩니다.

월별 응용 프로그램 계층 DDoS 공격

2분기에 응용 프로그램 계층 DDoS 공격은 전년 대비 44% 증가하였습니다.

2분기 전체에 걸쳐 응용 프로그램 계층 DDoS 공격 건수는 전년 대비 44% 증가하였지만, 이전 분기 대비 16% 감소하였습니다. 5월은 이 분기 들어 가장 분주했던 달입니다. 전체 응용 프로그램 계층 DDoS 공격의 47% 가까이가 5월에 발생했으며, 공격 건수는 6월에 가장 적었습니다(18%).

산업별 응용 프로그램 계층 DDoS 공격

항공우주 산업에 대한 공격은 이전 분기 대비 256% 증가했습니다.

항공우주 산업은 2분기에 가장 많이 응용 프로그램 계층 DDoS 공격의 대상이 된 산업이었습니다. 은행, 금융기관 및 보험(BFSI) 산업과 3위의 게임/도박 산업이 그 뒤를 이었습니다.

우크라이나와 러시아의 사이버 공간

우크라이나에서 가장 많이 공격 대상이 된 것은 미디어 및 출판 회사입니다.

지상, 공중, 바다에서 우크라이나 전쟁이 계속되고 있는 가운데, 사이버 공간에서도 전쟁이 계속되고 있습니다. 우크라이나 회사들을 겨냥하는 공격자는 정보 전파를 막으려 하는 것으로 추정됩니다. 우크라이나에서 가장 많이 공격받은 산업 6개는 모두 방송, 인터넷, 온라인 미디어, 출판업계에 속해 있습니다. 이는 우크라이나를 목표로 한 DDoS 공격 전체의 거의 80%에 달합니다.

반대편에서의 전쟁에서는 러시아의 은행, 금융기관 및 보험(BFSI) 회사들이 공격을 가장 많이 받았습니다. DDoS 공격 전체의 거의 50%가 BFSI 업계를 겨냥했습니다. 공격을 두 번째로 많이 받은 대상은 암호화폐 업계였고, 온라인 매체가 그 뒤를 이었습니다.

전쟁 당사자 양측에서 공격의 근원지가 매우 다양함을 확인할 수 있는데, 이는 전 세계에 걸쳐 봇넷이 사용되었음을 의미합니다.

공격 출처 국가별 응용 프로그램 계층 DDoS 공격

2분기에 중국발 공격은 112% 증가했지만, 미국발 공격은 43% 감소했습니다.

HTTP 공격의 출처를 파악하려면 공격 HTTP 요청을 생성한 클라이언트가 가진 소스 IP 주소의 지리적 위치를 살펴보아야 합니다. 네트워크 계층 공격 시와는 달리 HTTP 공격 시에는 소스 IP의 스푸핑이 불가능합니다. 특정 국가에서 DDoS 활동 비율이 높다는 것은 해당 국가에서 주도적으로 공격을 하고 있다는 것이 아니라 대개 해당 국가 내에서 봇넷이 작동 중임을 의미합니다.

2분기 연속으로 미국이 HTTP DDoS 공격의 주요 근원지 순위에서 1위를 차지했습니다. 미국 다음으로 2위에 중국, 3위와 4위에 인도와 독일이 각각 위치해 있습니다. 미국이 여전히 1위를 유지하고 있지만, 미국발 공격 건수는 지난 분기 대비 43% 감소하였으며, 다른 지역발 공격은 증가하였습니다. 중국발 공격은 112%, 인도발 공격은 89%, 독일발 공격은 50% 증가하였습니다.

대상 국가별 응용 프로그램 계층 DDoS 공격

어느 국가가 가장 많은 HTTP DDoS 공격을 받았는지 파악하기 위해 우리는 고객의 청구서 발행 국가별로 DDoS 공격을 분류하고, 이를 모든 DDoS 공격 대비 비율로 분석합니다.

미국에 본사를 둔 여러 회사에 대한 HTTP DDoS 공격 건수가 지난 분기 대비 45% 증가해 미국이 다시 응용 프로그램 계층 DDoS 공격의 주요 공격 대상 1위로 올라섰습니다. 중국의 회사들에 대한 공격은 지난 분기 대비 79% 급락해 해당 순위에서 중국이 1위에서 4위로 내려갔습니다. 키프로스에 대한 공격이 171% 증가하여 키프로스는 2분기에 두 번째로 많은 공격을 받은 나라가 되었습니다. 키프로스 다음에는 홍콩, 중국, 폴란드가 위치합니다.

네트워크 계층 DDoS 공격

응용 프로그램 계층 공격이 최종 사용자가 액세스하려는 서비스(우리의 경우 HTTP/S)를 구동하는 응용 프로그램(OSI 모델의 계층 7)를 대상으로 하는 반면, 네트워크 계층 공격은 네트워크 인프라(예: 인라인 라우터 및 서버)와 인터넷 링크 자체를 마비시키는 것을 목표로 합니다.

월별 네트워크 계층 DDoS 공격

2분기에 네트워크 계층 DDoS 공격은 전년 대비 75% 증가하였으며, 100Gbps 이상의 볼류메트릭 공격은 이전 분기 대비 19% 증가하였습니다.

2분기에 네트워크 계층 DDoS 공격의 총 건수는 전년 대비 75% 증가하였지만, 이전 분기와 비교할 때 큰 변화는 없었습니다. 이번 분기 들어 가장 분주했던 달은 4월로, 공격의 거의 40%가 4월에 발생하였습니다.

산업별 네트워크 계층 DDoS 공격

2분기에 이동통신 회사에 대한 공격이 이전 분기 대비 45% 증가하였습니다.

2분기 연속으로 통신 산업이 네트워크 계층 DDoS 공격의 가장 큰 목표가 되었습니다. 또한, 이동통신 회사에 대한 공격이 지난 분기 대비 45% 증가하였습니다. 게임 업계가 2위였고 정보 기술 및 서비스 회사들이 그 뒤를 이었습니다.

대상 국가별 네트워크 계층 DDoS 공격

미국 네트워크에 대한 공격은 이전 분기 대비 70% 증가했습니다.

2분기에도 미국은 가장 공격을 많이 받은 국가였습니다. 미국 다음으로는 지난 분기 4위였던 싱가포르가 2위로 상승했습니다. 3위는 독일, 그리고 그 뒤를 중국, 몰디브, 한국이 이었습니다.

수신 국가별 네트워크 계층 DDoS 공격

2분기에 Cloudflare가 팔레스타인과 아제르바이잔에서 관찰한 트래픽의 거의 1/3이 네트워크 계층 DDoS 공격이었습니다.

네트워크 계층 DDoS 공격이 어디에서 발생했는지 파악하려고 할 때 응용 프로그램 계층 공격 분석에 사용하는 방법과 같은 방법을 사용할 수는 없습니다. 응용 프로그램 계층 DDoS 공격을 시작하려면 HTTP/S 연결을 설정하기 위해 클라이언트와 서버 간에 성공적인 핸드셰이크가 발생해야 합니다. 성공적인 핸드셰이크를 발생시키려면 공격은 소스 IP 주소를 스푸핑할 수 없습니다. 공격자는 봇넷, 프록시 등의 방법을 사용하여 ID를 난독화할 수 있지만, 공격하는 클라이언트의 소스 IP 위치는 응용 프로그램 계층 DDoS 공격의 소스를 충분히 나타냅니다.

반면에 네트워크 계층 DDoS 공격을 시작하려면 대부분의 경우 핸드셰이크가 필요하지 않습니다. 공격자는 공격 소스를 난독화하고 공격 속성에 임의성을 도입하기 위해 소스 IP 주소를 스푸핑할 수 있습니다. 그럴 경우 단순한 DDoS 방어 시스템으로는 공격을 차단하기가 더 어려워질 수 있습니다. 따라서 스푸핑된 소스 IP를 기반으로 소스 국가를 파생시키면 ‘스푸핑된 국가’가 됩니다.

이러한 이유 때문에 네트워크 계층 DDoS 공격 소스를 분석할 때는 (잠재적으로) 스푸핑된 소스 IP가 아니라 트래픽이 수집된 Cloudflare 데이터 센터 위치별로 트래픽을 버킷팅하여 공격이 어디에서 발생했는지 파악합니다. 전 세계 270여 개 도시에 Cloudflare 데이터 센터가 있기 때문에 보고서에 지리적 위치를 정확하게 나타낼 수 있습니다. 그러나 이 방법도 100% 정확하지는 않습니다. 비용 절감, 혼잡, 장애 관리 등 다양한 이유로 트래픽이 백홀되고 다양한 인터넷 서비스 공급자 및 국가를 통해 라우팅될 수 있기 때문입니다.

네트워크 계층 DDoS 공격 비율이 가장 높은 Cloudflare 지역 측면에서 팔레스타인이 2위에서 1위로 상승하였습니다. 팔레스타인 다음으로는 아제르바이잔, 한국, 앙골라가 위치합니다.

모든 지역 및 국가를 보려면 인터랙티브 지도를 참고하세요.

공격 벡터

2분기에는 DNS 공격의 건수가 증가하여 두 번째로 흔한 공격 방법이 되었습니다.

공격 벡터는 공격자가 DDoS 공격을 실행하기 위해 사용하는 방법, 즉 IP 프로토콜, TCP 플래그 같은 패킷 속성, 폭주 등의 방법을 설명하는 용어입니다.

2분기에 전체 네트워크 계층 공격의 56%는 SYN 폭주 공격이었습니다. SYN 폭주는 여전히 가장 흔한 공격 방법입니다. 이 공격은 스테이트풀 TCP 핸드셰이크의 초기 연결 요청을 남용합니다. 초기 연결 요청 시에 서버에는 이 새로운 TCP 연결에 대한 어떠한 정보도 존재하지 않아 올바르게 보호되어 있지 않으면 수많은 초기 연결 요청의 폭주를 완화하는 데 어려움을 겪을 수 있습니다. 이에 따라 공격자는 보호되지 않은 서버의 리소스를 쉽게 소모시킬 수 있습니다.

DNS 인프라를 겨냥하는 SYN 폭주에 이어 TCP 연결 흐름을 남용하는 RST 폭주와 UDP를 통한 일반적인 공격이 있습니다.

새롭게 떠오르는 위협

2분기에 새로 등장한 위협으로는 CHARGEN, Ubiquiti, 멤캐시드를 통한 공격이 있었습니다.

주요 공격 벡터를 식별하면 조직에서 위협 환경을 파악하는 데 도움이 됩니다. 그에 따라 이러한 위협으로부터 보호하기 위해 조직의 보안 상태를 개선하는 데 도움이 될 수 있습니다. 마찬가지로, 아직 공격의 상당 부분을 차지하지 않는 새로운 위협에 대해 학습할 경우 해당 공격이 상당한 위력을 발휘하기 전에 공격을 완화하는 데 도움이 될 수 있습니다.

2분기에 새로 등장한 위협 상위권에는 문자 생성기 프로토콜(CHARGEN)을 남용하는 증폭 공격, 노출된 Ubiquiti 디바이스에서 트래픽을 반사하는 증폭 공격, 악명 높은 멤캐시드 공격이 있습니다.

CHARGEN 프로토콜을 남용해 증폭 공격 시행하기

2분기에는 CHARGEN 프로토콜을 남용한 공격이 이전 분기 대비 378% 증가하였습니다.

RFC 864(1983)에서 최초로 정의된 문자 생성기(CHARGEN) 프로토콜은 인터넷 프로토콜 스위트 상의 서비스로, 이름 그대로 임의의 문자를 생성하고 클라이언트가 연결을 닫기까지 해당 문자를 클라이언트에게 전송하는 것을 중지하지 않는 역할을 합니다. 이 서비스의 초기 개발 목적은 테스트와 디버깅 목적이었지만, 쉽게 남용해 증폭/반사 공격을 만들어낼 수 있기 때문에 거의 사용되지 않습니다.

공격자는 피해자의 소스 IP를 스푸핑해 전 세계에서 이 프로토콜을 지원하는 서버를 속여 임의의 문자로 이루어진 문자열을 피해자의 서버로 “되돌려보내도록” 만들 수 있습니다. 이 공격을 증폭/반사 공격이라고 합니다. 충분한 양의 CHARGEN 흐름이 존재한다면 피해자의 서버는 보호되지 않은 경우 폭주하게 되어 정상적인 트래픽을 처리할 수 없게 되며 따라서 서비스 거부 이벤트가 발생하게 됩니다.

Ubiquiti Discovery 프로토콜을 남용하는 증폭 공격

2분기에는 Ubiquity를 통한 공격이 이전 분기 대비 313% 증가했습니다.

Ubiquiti는 미국에 기반을 두고 소비자와 기업에 네트워킹 및 사물 인터넷(IoT) 장치를 제공하는 회사입니다. Ubiquiti 장비는 UDP/TCP 포트 10001를 사용해 Ubiquiti Discovery 프로토콜을 이용하는 네트워크에서 찾아볼 수 있습니다.

CHARGEN 공격 방식과 유사하게 여기에서도 공격자가 소스 IP를 피해자의 IP 주소로 스푸핑해 포트 10001이 열린 상태의 IP 주소를 살포할 수 있습니다. 이들 주소는 그 뒤 피해자의 IP에 반응해 충분한 양이 존재한다면 그 포트를 폭주하게 만듭니다.

멤캐시드 DDos 공격

2분기에 멤캐시드 DDoS 공격은 이전 분기 대비 281% 증가했습니다.

멤캐시드는 웹사이트와 네트워크의 속도를 향상시키기 위한 데이터베이스 캐싱 시스템입니다. CHARGEN과 Ubiquiti의 경우와 유사하게 UDP를 지원하는 멤캐시드 서버를 남용해 증폭/반사 DDoS 공격을 실행할 수 있습니다. 이 경우에는 공격자가 캐싱 시스템 상의 콘텐츠를 요청하고 UDP 패킷의 소스 IP를 피해자의 IP 주소로 스푸핑합니다. 이 경우 피해자는 최대 51,200배 증폭될 수 있는 멤캐시 응답으로 과부하가 걸리게 됩니다.

공격 비율별 네트워크 계층 DDoS 공격

100Gbps 이상의 볼류메트릭 공격이 지난 분기 대비 19% 증가했습니다. 3시간 이상 지속된 공격은 9% 증가했습니다.

L3/4 DDoS 공격의 규모를 측정하는 방법은 여러 가지입니다. 하나는 공격 트래픽의 양을 비트 전송률(초당 테라비트 또는 초당 기가비트 수)로 측정하는 방법입니다. 또 하나의 방법은 총 패킷의 개수를 패킷 전송률(수백만 단위의 초당 패킷 수)로 측정하는 것입니다.

비트 전송률이 높은 공격은 인터넷 링크를 포화시킴으로써 서비스 거부 이벤트를 발생시키려는 시도이며, 패킷 전송률이 높은 공격은 서버, 라우터, 기타 인라인 장비를 마비시키려는 시도입니다. 이러한 장비는 각각의 패킷을 처리하기 위해 일정량의 메모리와 연산 능력을 할당합니다. 따라서 장비에 많은 패킷을 퍼부으면 처리를 위한 리소스를 완전히 고갈시킬 수 있습니다. 이러한 경우에는 패킷의 “드롭(drop)”, 즉 해당 장비가 패킷을 처리할 수 없는 상황이 발생합니다. 그 결과 사용자는 서비스 중단 및 서비스 거부를 경험하게 됩니다.

패킷 전송률별 분포

네트워크 계층 DDoS 공격은 대부분 초당 50,000패킷 미만으로 유지됩니다. 50kpps는 Cloudflare의 규모에서는 스펙트럼의 아래쪽에 위치하지만, 여전히 보호되지 않는 인터넷 자산을 손쉽게 중단시키고 표준 기가비트 이더넷 연결까지도 혼잡하게 만들 수 있습니다.

공격 규모의 변화를 살펴보면 50kpps 이상의 패킷에 집중하는 공격 건수가 2분기에 감소해 소규모 공격 건수가 4% 증가하였음을 확인할 수 있습니다.

비트 전송률별 분포

2분기에는 네트워크 계층 DDoS 공격이 대부분 500Mbps 미만으로 유지되었습니다. 이 또한 Cloudflare의 규모에서 보면 아주 작은 티끌에 지나지 않지만, 용량이 작고 보호되지 않은 인터넷 자산을 빠르게 마비시키거나 심지어는 표준 기가비트 이더넷 연결의 경우에도 최소한 혼잡을 발생시킬 수 있습니다.

흥미롭게도 500Mbps에서 100Gbps 사이의 대규모 공격은 이전 분기 대비 20~40% 감소하였지만, 100Gbps 이상의 볼류메트릭 공격은 8% 증가하였습니다.

지속 시간별 네트워크 계층 DDoS 공격

2분기에 3시간 이상 지속된 공격은 9% 증가했습니다.

Cloudflare에서는 시스템에서 공격이 처음으로 감지 및 확인된 시점과 해당 공격 서명이 관찰된 마지막 패킷 사이의 간격을 기록하여 특정 타겟을 노리는 공격의 지속 시간을 측정합니다.

2분기에는 전체 네트워크 계층 DDoS 공격의 51%가 10분 미만 지속되었습니다. 41%는 10~20분 동안 지속되었습니다. 나머지 8%에는 20분부터 3시간 이상까지 지속된 공격이 포함됩니다.

한 가지 유의할 점은 공격이 몇 분 동안만 지속되더라도 공격이 성공하면 그 영향이 초기 공격 지속 시간보다 훨씬 더 오래 지속될 수 있다는 것입니다. 공격이 성공리에 끝나면 IT 직원은 서비스를 복구하는 데 몇 시간, 심지어 며칠까지 작업을 해야 할 수도 있습니다.

대부분의 공격은 정말 짧았지만, 20~60분 사이의 공격 건수가 15% 증가하였음을, 그리고 3시간 이상 지속된 공격은 12% 증가하였음을 확인할 수 있습니다.

짧은 공격은 감지되지 않은 채 지나갈 수 있으며, 막대한 수의 패킷, 바이트 또는 요청을 몇 초 안에 집중시켜 대상을 공격하는 버스트 공격은 특히 감지가 어렵습니다. 이 경우, 보안 분석을 통한 수동 완화에 의존하는 DDoS 방어 서비스로는 적시에 공격을 완화할 방법이 없습니다. 단지 공격 후 분석에서 이를 확인한 다음 해당 공격 지문을 필터링하는 새로운 규칙을 배포하고 다음을 기약할 수 있을 뿐입니다. 마찬가지로, 보안팀이 공격 진행 도중에 트래픽을 DDoS 공급자에게 리디렉션하는 “주문형” 서비스도 비효율적입니다. 해당 트래픽이 주문형 DDoS 공급자에게 라우팅되기 전에 이미 공격이 끝나버리기 때문입니다.

기업들에게는 트래픽을 분석하여 실시간 핑거프린팅을 빠르게 적용함으로써 단기 공격을 막아낼 수 있는 자동화된 상시 가동 DDoS 방어 서비스를 사용하는 것을 권장합니다.

요약

Cloudflare의 사명은 더 나은 인터넷 환경을 구축하는 데 힘을 보태는 것입니다. 더 나은 인터넷이란 더 안전하고 빠르며 믿을 수 있는 인터넷입니다. DDoS 공격이 발생하더라도 말입니다. 이 사명의 일환으로 2017년부터 우리는 모든 고객에게 무료로 무제한 DDoS 방어 기능을 제공하고 있습니다. 여러 해가 지나면서 공격자들이 DDoS 공격을 실행하기가 점점 더 쉬워지고 있습니다. 그렇지만 공격 실행이 더 쉬워졌을지라도, 우리는 모든 조직 역시 그 규모와 상관없이 모든 종류의 DDoS 공격에 맞서 스스로를 더 쉽게 무료로 보호할 수 있도록 하려 합니다.
아직 Cloudflare를 사용하지 않으시나요? 지금 우리의 Free 및 Pro 요금제에 가입해서 귀사의 웹 사이트를 보호하거나 당사에 문의해서 네트워크 전체에 대한 포괄적인 DDoS 방어를 제공하는 Magic Transit을 이용해 보세요.

2022 年第二季度 DDoS 攻擊趨勢

2022-07-06 Omer Yoachimik

Post Syndicated from Omer Yoachimik original https://blog.cloudflare.com/ddos-attack-trends-for-2022-q2-zh-tw/

2022 年第二季度 DDoS 攻擊趨勢

歡迎閱讀我們的 2022 年第二季 DDoS 報告。本報告包括有關 DDoS 威脅情勢的深入解析與趨勢，這些資訊從全球 Cloudflare 網路中觀察所得。Radar 上也會提供本報告的互動版本。

第二季度，我們看到了有史以來最大的一些攻擊，包括 Cloudflare 自動偵測並緩解的每秒 2600 萬個請求的 HTTPS DDoS 攻擊。此外，針對烏克蘭和俄羅斯的攻擊仍在繼續，而新的 DDoS 勒索攻擊活動又出現了。

重點內容

俄羅斯和烏克蘭網際網路

地面戰爭伴隨著針對資訊傳播的攻擊。
烏克蘭的廣播媒體公司成為第二季度 DDoS 攻擊的最大目標。事實上，前六大最受攻擊的產業均為網路/網際網路媒體、出版業和廣播業。
另一方面，在俄羅斯，網路媒體曾經是遭受攻擊最多的產業，如今下降到第三位。第二季度，俄羅斯的銀行、金融服務及保險業 (BFSI) 公司成為遭受攻擊最多的公司，躍居首位；BFSI 產業成為幾乎 50% 的應用程式層 DDoS 攻擊的目標。俄羅斯的加密貨幣公司是遭受攻擊第二多的公司。

更一步瞭解 Cloudflare 如何讓開放式網際網路流量流入俄羅斯，同時避免向外展開攻擊。

DDoS 勒索攻擊

我們觀察到新一波 DDoS 勒索攻擊，由自稱 Fancy Lazarus 的實體發出。
2022 年 6 月，勒索攻擊達到今年以來的最高水準：每五名經歷過 DDoS 攻擊的問卷調查受訪者中，就有一人報告受到 DDoS 勒索攻擊或其他威脅。
整體來說，第二季度 DDoS 勒索攻擊環比增長 11%。

應用程式層 DDoS 攻擊

2022 年第二季度，應用程式層 DDoS 攻擊同比增長 44%。
位於美國的組織是此類攻擊的主要目標，其次是賽普勒斯、香港和中國。針對賽普勒斯組織的攻擊數環比增長 171%。
第二季度，航空和太空產業遭受此類攻擊最多，其次是網際網路產業、銀行業、金融服務業及保險業，而遊戲/博彩業則位居第四。

網路層 DDoS 攻擊

2022 年第二季度，網路層 DDoS 攻擊數同比增長 75%。100 Gbps 及以上的攻擊數環比增長 19%，持續 3 小時以上的攻擊數環比增長 9%。
遭受此類攻擊最多的產業分別是電信業、遊戲/博彩以及資訊技術和服務業。
美國的組織是此類攻擊的主要目標，其次是新加坡、德國和中國。

本報告基於 Cloudflare 的 DDoS 防護系統自動偵測和緩解的 DDoS 攻擊數。如需深入瞭解該系統的運作方式，請查看此深度剖析部落格貼文。

有關我們如何衡量在網路中觀察到的 DDoS 攻擊的說明

為分析攻擊趨勢，我們會計算「DDoS 活動」率，即攻擊流量在我們的全球網路中、特定位置或特定類別（如行業或帳單國家/地區）觀察到的總流量（攻擊流量+潔淨流量）中所佔的百分比。透過衡量這些百分比，我們能夠標準化資料點並避免以絕對數字反映而出現的偏頗，例如，某個 Cloudflare 資料中心接收到更多的總流量，因而發現更多攻擊。

勒索攻擊

我們的系統會持續分析流量，並在偵測到 DDoS 攻擊時自動套用緩解措施。每個受到 DDoS 攻擊的客戶都會收到提示，請求參與一個自動化調查，以幫助我們更好地瞭解該攻擊的性質以及緩解措施的成功率。

兩年多以來，Cloudflare 一直在對受到攻擊的客戶進行調查，調查中的一個問題是，他們是否收到威脅或勒索信，要求付款以換得停止 DDoS 攻擊。

第二季度報告威脅或勒索信的受訪者數量環比和同比增長 11%。在本季度，我們一直在緩解 DDoS 勒索攻擊，這些攻擊由自稱是進階持續威脅 (APT) 組織「Fancy Lazarus」的實體發起的。金融機構和加密貨幣公司成為這起活動的主要目標。

深入探究第二季度，我們可以看到，在 6 月份，每五名受訪者中就有一人報告收到 DDoS 勒索攻擊或威脅 — 這既是 2022 年報告數量最多的月份，也是自 2021 年 12 月以來報告數量最多的月份。

應用程式層 DDoS 攻擊

應用程式層 DDoS 攻擊，特別是 HTTP DDoS 攻擊，旨在通過使 HTTP 伺服器無法處理合法用戶請求來破壞它。如果伺服器收到的請求數量超過其處理能力，伺服器將丟棄合法請求甚至崩潰，導致對合法使用者的服務效能下降或中斷。

應用程式層 DDoS 攻擊：月份分佈

第二季度，應用程式層 DDoS 攻擊數同比增長 44%。

整體來說，在第二季度，應用程式層 DDoS 攻擊數量同比增長 44%，但環比下降 16%。5 月是本季度最繁忙的月份。幾乎 47% 的應用程式層 DDoS 攻擊都發生在 5 月，而 6 月發生的攻擊數最少 (18%)。

應用程式層 DDoS 攻擊：行業分佈

針對航空和太空業的攻擊數環比增長 256%。

第二季度，航空和太空是遭受應用程式層 DDoS 攻擊最多的產業。銀行、金融機構和保險業 (BFSI) 緊隨其後，而遊戲/博彩業則位居第三。

烏克蘭和俄羅斯的網路空間

媒體和出版公司是烏克蘭遭受攻擊最多的公司。

隨著烏克蘭地面、空中和水面戰爭的繼續，網路空間的戰爭也在繼續。將烏克蘭公司作為攻擊目標的實體似乎在試圖掩蓋資訊。烏克蘭遭受攻擊最多的前六大產業均為廣播、網際網路、網路媒體和出版業 — 這幾乎占所有針對烏克蘭的 DDoS 攻擊的 80%。

而戰爭的另一方，俄羅斯的銀行、金融機構和保險 (BFSI) 公司受到的攻擊最多。幾乎 50% 的 DDoS 攻擊的目標都是 BFSI 行業。第二大目標是加密貨幣行業，然後是網路媒體。

在戰爭雙方，我們可以看到攻擊都是高度分散的，這表明使用了全球分散式殭屍網路。

應用程式層 DDoS 攻擊：來源國家/地區分佈

第二季度，來自中國的攻擊增長了 112%，而來自美國的攻擊减少了 43%。

為瞭解 HTTP 攻擊的來源，我們研究了產生攻擊 HTTP 請求之用戶端來源 IP 位址的地理位置。與網路層攻擊不同，HTTP 攻擊中的來源 IP 位址無法偽造。特定國家/地區的 DDoS 活動百分比較高，這並不意味著該特定國家/地區正在發起攻擊，而是表明有殭屍網路在其境內運作。

美國作為 HTTP DDoS 攻擊的主要來源，已經連續第二個季度位居榜首。中國在美國之後，位居第二，而印度和德國分別位居第三和第四。儘管美國仍然處於首位，但來自美國的攻擊數環比下降了 43%，而來自其他地區的攻擊數卻有所增長；來自中國的攻擊數增長了 112%，來自印度的攻擊數增長了 89%，來自德國的攻擊數則增長了 50%。

應用程式層 DDoS 攻擊：目標國家/地區分佈

為確定哪些國家/地區遭受最多的 HTTP DDoS 攻擊，我們按客戶的帳單國家/地區對 DDoS 攻擊進行了分類，並以其佔據所有 DDoS 攻擊數的百分比進行表示。

針對美國國家/地區的 HTTP DDoS 攻擊數環比增長 45%，使美國重新成為應用程式層 DDoS 攻擊的主要目標而居於首位。針對中國公司的攻擊數環比下降 79%，使其從第一位下降到第四位。針對賽普勒斯的攻擊數增長了 171%，使其成為第二季度遭受攻擊第二多的國家/地區。在賽普勒斯之後，則是香港、中國和波蘭。

網路層 DDoS 攻擊

應用程式層攻擊的目標是最終使用者嘗試訪問的服務（本例中為 HTTP/S）所在的應用程式（OSI 模型的第 7 層），而網路層攻擊以網路基礎結構（例如聯網路由器和伺服器）和網際網路鏈路本身為目標。

網路層 DDoS 攻擊：月份分佈

第二季度，網路層 DDoS 攻擊數同比增長 75%，100 Gbps 及以上的巨流量攻擊數環比增長 19%。

第二季度，網路層 DDoS 攻擊總數同比增長 75%，但與上一季度相比變化不大。4 月是本季度最繁忙的月份，幾乎 40% 的攻擊都發生在 4 月。

網路層 DDoS 攻擊：行業分佈

第二季度，針對電信公司的攻擊數環比增長 45%。

電信產業已經連續第二個季度成為網路層 DDoS 攻擊的最主要目標。尤其是，針對電信公司的攻擊數環比增長了 45%。而遊戲行業位居第二，緊跟其後是資訊科技和服務公司。

網路層 DDoS 攻擊：目標國家/地區分佈

針對美國網路的攻擊數環比增長了 70%。

第二季度，美國仍是遭受攻擊最多的國家/地區。排在美國之後的是新加坡，從上一季度的第四位躍升至第二位。排在第三位的則是德國，然後是中國、馬爾地夫和南韓。

網路層 DDoS 攻擊：輸入國家/地區分佈

第二季度，Cloudflare 在巴勒斯坦和亞塞拜然觀察到的流量中，近三分之一是網路層 DDoS 攻擊。

在試圖弄清網路層 DDoS 攻擊的來源時，我們不能使用與進行應用程式層攻擊分析相同的方法。要發起應用程式層 DDoS 攻擊，用戶端與伺服器之間必須成功握手，以建立 HTTP/S 連線。為成功實現握手，攻擊不能偽造其來源 IP 位址。雖然攻擊者可能會使用機器人、代理或其他方法來掩蓋自己的身分，但攻擊用戶端的來源 IP 位置確實就是應用程式層 DDoS 攻擊的攻擊來源。

而要發起網路層 DDoS 攻擊，在大多數情況下都無需握手。攻擊者可以偽造來源 IP 位址來混淆攻擊來源並在攻擊屬性中引入隨機性，這可能會使簡單的 DDoS 防護系統更難攔截攻擊。因此，如果我們根據偽造的來源 IP 位址推導出源國家/地區，我們將得到一個『偽造的國家/地區』。

為此，在分析網路層 DDoS 攻擊來源時，我們會根據吸收流量的 Cloudflare 資料中心位置對流量進行分類，而不是（潛在的）偽造來源 IP，從而瞭解攻擊來源。我們的資料中心遍及全球超過 270 個城市，因此能夠在本報告中實現地理上的準確性。然而，即便是這种方法也不能達到 100% 的準確性，因為出於各種原因，比如降低成本、網路壅塞或管理不善，流量可能會透過不同的網際網路服務提供者和國家/地區回傳或路由。

巴勒斯坦成為網路層 DDoS 攻擊百分比最高的 Cloudflare 位置，從第二位躍升至首位。排在巴勒斯坦之後的是亞塞拜然、南韓和安哥拉。

要檢視所有國家和地區，請查看互動式地圖。

攻擊手段

第二季度，DNS 攻擊數增加，使其成為第二常見的攻擊手段。

用語「攻擊手段」用於描述攻擊者用來發起 DDoS 攻擊的方法，如 IP 通訊協定、TCP 旗標等封包屬性、洪水方法和其他條件。

第二季度，56% 的網路層攻擊是 SYN 洪水。SYN 洪水仍然是最常見的攻擊手段。它們濫用具狀態 TCP 握手的初始連線請求。在這個初始連線請求期間，伺服器沒有任何關於 TCP 連線的環境，因為它是新的，而且若沒有適當的保護，可能很難緩解初始連線請求的氾濫。這使得攻擊者更容易消耗未受保護的伺服器的資源。

緊隨 SYN 洪水之後的是針對 DNS 基礎結構的攻擊，而濫用 TCP 連線流程的 RST 洪水再次位居第三，然後是一般的 UDP 攻擊。

新興威脅

第二季度，主要的新興威脅包括 CHARGEN、Ubiquiti 和 Memcached 攻擊。

識別主要攻擊手段有助於組織瞭解攻擊狀況。轉而幫助他們改善安全狀態，防禦這些威脅。同樣地，瞭解尚未在攻擊中發揮重大作用的新興威脅能讓我們在其造成重大影響之前緩解它們。

第二季度，主要的新興威脅是濫用 Character Generator 通訊協定 (CHARGEN) 的放大攻擊、反映暴露 Ubiquiti 裝置流量的放大攻擊，以及臭名昭著的 Memcached 攻擊。

濫用 CHARGEN 通訊協定發起放大攻擊

第二季度，濫用 CHARGEN 通訊協定的攻擊數環比增長了 378%。

最初於 RFC 864 (1983) 中定義，字元產生器 (CHARGEN) 通訊協定是網際網路通訊協定套件的一項服務，顧名思義，它會任意產生字元，並在用戶端關閉連線之前，不斷地向用戶端傳送字元。其初衷是測試和偵錯。然而，它卻很少被使用，因為很容易被濫用以產生放大/反射攻擊。

攻擊者可以偽造其受害者的來源 IP，並欺騙世界各地的支援伺服器，以將任意字元串流「重新」定向至受害者的伺服器。這種類型的攻擊就是放大/反射。如果並行 CHARGEN 串流足够多，則受害者的伺服器在未受到保護的情況下，會遭受洪水攻擊，進而無法應對合法流量 — 導致拒絕服務事件。

利用 Ubiquiti Discovery 通訊協定的放大攻擊

第二季度，Ubiquity 攻擊數環比增長了 313%。

Ubiquiti 總部位於美國，該公司為消費者和企業提供網路和物聯網 (IoT) 裝置。您可以透過 UDP/TCP 連接埠 10001 在使用 Ubiquiti Discovery 通訊協定的網路上發現 Ubiquiti 裝置。

與 CHARGEN 攻擊手段類似，此類攻擊的攻擊者也可以將來源 IP 偽造成受害者的 IP 位址，並噴濺開啟連接埠 10001 的 IP 位址。然後，它們會回應受害者，如果回應數量足够多，則基本上會淹沒受害者。

Memcached DDoS 攻擊

第二季度，Memcached DDoS 攻擊數環比增長了 281%。

Memcached 是一個資料庫快取系統，可用於加速網站和網路。與 CHARGEN 和 Ubiquiti 類似，支援 UDP 的 Memcached 伺服器可能會被濫用，以發起放大/反射 DDoS 攻擊。在這種情況下，攻擊者會從快取系統請求內容，並偽造受害者的 IP 位址作為 UDP 封包中的來源 IP。Memcached 回應可放大最高 51200 倍，因此會淹沒受害者。

網路層 DDoS 攻擊：攻擊速度分佈

超過 100 Gbps 的巨流量攻擊數環比增長 19%。超過三小時的攻擊數增長 9%。

衡量 L3/4 DDoS 攻擊規模有不同的方法。一種方法是測量它傳遞的流量大小，以位元速率為單位（例如，Tbps 或 Gbps）。另一種是測量它傳遞的資料封包數，以封包速率為單位（例如， Mpps：百萬封包/每秒）。

高位元速率的攻擊試圖使網際網路鏈路飽和，而高封包速率的攻擊會使伺服器、路由器或其他聯網硬體裝置不堪重負。這些裝置分配一定的記憶體量和計算能力來處理每個封包。因此，通過向裝置發送大量封包，該裝置的處理資源就可能被耗盡。在這種情況下，封包就會「被丟棄」，即裝置無法再處理封包。對使用者而言，這會導致服務中斷和拒絕服務。

基於封包速率的分佈情況

大部分網路層 DDoS 攻擊都低於每秒 50,000 封包。雖然在 Cloudflare 面臨的攻擊範圍內，50 kpps 的封包速率並不算高，但仍可輕鬆摧毀未受保護的網際網路設備，即便是標準的千兆位元級乙太網路連線也會遭遇壅塞。

分析攻擊規模的變化時，我們可以看到，第二季度超過 50 kpps 的高封包量攻擊有所减少，導致小型攻擊增長 4%。

基於位元速率的分佈情況

第二季度，大部分網路層 DDoS 攻擊都低於 500 Mbps。這在 Cloudflare 面臨的攻擊範圍內同樣不足掛齒，但可以非常快速地關閉未受保護且網路處理能力較低的網際網路設備，或者至少能夠造成網路壅塞，即便是標準的千兆位元級乙太網路連線。

有趣的是，介於 500 Mbps 和 100 Gbps 之間的大型攻擊數環比减少了 20-40%，但 100 Gbps 以上的巨流量攻擊數卻增長了 8%。

網路層 DDoS 攻擊：持續時間分佈

第二季度，持續超過三小時的攻擊數增長了 9%。

我們測量攻擊持續時間的方式是：記錄系統首次偵測到攻擊與具備該攻擊特徵且前往該特定目標的最後一個封包之間的時間差。

第二季度，51% 的網路層 DDoS 攻擊持續時間不足 10 分鐘。另有 41% 的攻擊持續了 10-20 分鐘。剩下的 8% 則為 20 分鐘到 3 小時以上的攻擊。

需要記住的重要一點是，即使攻擊只持續幾分鐘，只要攻擊成功，其影響就會遠遠超過最初的攻擊時長。IT 人員回應成功的攻擊可能需要幾小時甚至幾天時間，才能恢復服務。

儘管大多數攻擊時間確實很短暫，但我們可以看到 20-60 分鐘之間的攻擊增長了 15% 以上，而持續時間超過三小時的攻擊則增長了 12%。

短時間的攻擊很可能不被察覺，特別是爆發攻擊，此類攻擊會在幾秒鐘內用大量的封包、位元組或請求轟擊目標。在這種情況下，依賴于安全分析來手動緩解的 DDoS 保護服務沒有機會及時緩解攻擊。此類服務只能從攻擊後分析中吸取教訓，然後部署篩選該攻擊指紋的新規則，期望下次能捕捉到它。同樣，使用「按需」服務（即安全團隊在遭到攻擊時將流量重定向至 DDoS 保護提供商）也無濟於事，因為在流量到達按需 DDoS 保護提供商前，攻擊就已經結束了。

建議公司使用始終啟用的自動化 DDoS 防護服務來分析流量，並足夠快速地套用即時指紋識別以封鎖持續時間短暫的攻擊。

概述

Cloudflare 的使命是幫助建構更好的網際網路，讓所有人擁有更快速、更安全、更可靠的體驗，即使在面臨 DDoS 攻擊時也是如此。作為我們使命的一部分，自 2017 年開始，我們一直在為所有客戶免費提供非計量、無限制的 DDoS 防護。這些年來，攻擊者越來越容易發起 DDoS 攻擊。為反擊攻擊者的優勢，我們想要確保所有規模的組織都能夠簡單且免費地保護他們自身，防禦所有類型的 DDoS 攻擊。
尚未使用 Cloudflare？立即開始使用，您可使用我們的 Free 和 Pro 方案保護您的網站，或聯絡我們獲得全面的 DDoS 保護，使用 Magic Transit 保護您的整個網路。

2022 年第二季度 DDoS 攻击趋势

2022-07-06 Omer Yoachimik

Post Syndicated from Omer Yoachimik original https://blog.cloudflare.com/ddos-attack-trends-for-2022-q2-zh-cn/

2022 年第二季度 DDoS 攻击趋势

欢迎阅读我们的 2022 年第二季度 DDoS 攻击报告。本报告介绍有关 DDoS 威胁格局的洞察和趋势——反映了在 Cloudflare 全球网络中观察到的情况。本报告的交互式版本可在 Radar 上查看。

第二季度期间，我们观察到一些全球规模最大的攻击，包括一次每秒 2600 万次请求的 HTTPS DDoS 攻击，这些攻击均被 Cloudflare 自动检测并缓解。此外，针对乌克兰和俄罗斯的攻击继续，并出现了一场新的勒索 DDoS 攻击活动。

要点

乌克兰和俄罗斯互联网

地面战斗伴随着针对信息传播的攻击。
乌克兰的广播媒体公司是第二季度 DDoS 攻击的最主要目标。事实上，受攻击最多的前六个行业均来自在线/互联网媒体、出版和广播。
另一方面，在俄罗斯，在线媒体作为受攻击最多的行业排名下降到第三位。俄罗斯的银行、金融服务和保险（BFSI）公司在第二季度成为最主要的攻击目标；几乎 50% 的应用层 DDoS 攻击均针对 BFSI 领域。俄罗斯的加密货币公司成为攻击的第二大目标。

进一步了解 Cloudflare 如何使开放互联网正常流入俄罗斯，并阻止攻击出境。

勒索 DDoS 攻击

我们观察到一波新的勒索 DDoS 攻击，由声称是 Fancy Lazarus 的组织发动。
2022 年 6 月，勒索攻击达到今年以来的最高水平：每 5 个经历过 DDoS 攻击的受访者中就有一个报称遭到勒索 DDoS 攻击或其他威胁。
总体而言，第二季度期间，勒索 DDoS 攻击的比例环比上升了 11%。

应用层 DDoS 攻击

2022 年第二季度期间，应用层 DDoS 攻击环比增长 44%。
美国的组织受到最多攻击，其次是塞浦路斯、中国香港和中国内地。针对塞浦路斯境内组织的攻击环比增长 171%。
航空航天行业是第二季度受到最多攻击的行业，其次是互联网行业，银行、金融服务和保险，以及第四位的博彩行业。

网络层 DDoS 攻击

2022 年第二季度期间，网络层 DDoS 攻击环比增长 75%。100 Gbps 及更大的攻击增长19%，持续 3 小时以上的攻击环比增长 9%。
受到最多攻击的行业为电信，游戏/博彩，信息技术和服务行业。
受到最多攻击的是位于美国的组织，其次是新加坡、德国和中国内地。

本报告基于 Cloudflare DDoS 防护系统自动检测并缓解的 DDoS 攻击。如需进一步了解其工作原理，请查看这篇深入剖析的博客文章。

简要说明一下我们如何测量在我们网络上观察到的 DDoS 攻击。

为分析攻击趋势，我们计算 “DDoS 活动”率，即攻击流量占我们全球网络上观察到的总流量（攻击+干净）、或在特定地点、或特定类别（如行业或账单国家）流量中的百分比。通过测量百分比，我们能够对数据点进行标准化，并避免绝对数字所反映出来的偏差。例如，如果某个 Cloudflare 数据中心接收到更多流量，则其也可能受到更多攻击。

勒索攻击

我们的系统持续分析流量，并在检测到 DDoS 攻击时自动应用缓解措施。每个遭受 DDoS 攻击的客户都会收到自动调查的提示，以帮助我们更好地了解攻击的性质和缓解是否成功。

两年多来，Cloudflare 一直对受到攻击的客户进行调查，其中一个问题是客户是否收到勒索信，要求其支付赎金来换取停止 DDoS 攻击。

第二季度期间，报称收到威胁或勒索信的受访者数量较上一季度和去年同期分别增加 11%。本季度期间，我们缓解了多次勒索 DDoS 攻击，发动者声称是高级持续性威胁（APT）组织 “Fancy Lazarus”。这些攻击活动的主要目标是金融机构和加密货币公司。

第二季度的详细数据显示， 6 月期间，有五分之一的受访者报称遭到一次勒索 DDoS 攻击或威胁——为 2022 年比例最高的月份，也是 2021 年 12 月以来的最高水平。

应用层 DDoS 攻击

应用层 DDoS 攻击，特别是 HTTP DDoS 攻击，旨在通过使 HTTP 服务器无法处理合法用户请求来造成破坏。如果服务器收到的请求数量超过其处理能力，服务器将丢弃合法请求甚至崩溃，导致对合法用户的服务性能下降或中断。

应用层 DDoS 攻击月度分布

第二季度，应用层 DDoS 攻击环比增长 44%。

总体而言，应用层 DDoS 攻击同比增长 44%，但环比减少 16%。5 月是该季度期间攻击最活跃的月份。近 47% 的应用层 DDoS 攻击发生在 5 月，而 6 月的攻击最少（18%）。

应用层 DDoS 攻击：行业分布

对航空航天行业发动的攻击环比增长 256%。

第二季度，航空航天行业是受到最多应用层攻击的行业。其次是银行、金融机构和保险行业（BFSI），排名第三的是博彩行业。

乌克兰和俄罗斯网络空间

乌克兰的媒体和出版公司受到最多攻击。

随着乌克兰的战事在海陆空继续，网络空间的对抗也在继续。以乌克兰公司为目标的实体似乎在试图掩盖信息。在乌克兰，受到攻击最多的六大行业均在广播、互联网、在线媒体和出版领域——占乌克兰所遭受 DDoS 攻击总数的接近 80%。

在战争的另一方，俄罗斯银行、金融机构和保险行业（BFSI）公司受到最多攻击。接近一半的 DDoS 攻击以 BFSI 领域为目标。第二大目标是加密货币行业，其次为在线媒体。

在战争的双方，我们都看到攻击是高度分布式的，表明使用了全球分布的僵尸网络。

应用层 DDoS 攻击：来源国家/地区分布

第二季度，源于中国的攻击增长112%，而来自美国的攻击减少 43%。

为了解 HTTP 攻击的来源，我们查看产生攻击的 HTTP 请求客户端的源 IP 地址。与网络层攻击不同，HTTP 攻击中的源 IP 无法假冒。特定国家/地区的高 DDoS 活动比例较高并不意味着该国家/地区发动了攻击，而是表明有僵尸网络在其境内运行。

第二季度，美国连续第二个季度成为最主要的 HTTP DDoS 攻击来源地。其次是中国，印度和德国分别居第三和第四位。尽管美国依然居首位，但源于美国的攻击环比减少了 43%，而来自其他地区的攻击有所增加；源于中国的攻击增加了 112%，来自印度攻击的增加了 89%，来自德国的攻击增加 50%。

应用层 DDoS 攻击：目标国家/地区分布

为确定哪些国家/地区遭受到最多攻击，我们按客户的账单国家/地区统计 DDoS 攻击，并计算占 DDoS 攻击总数的百分比。

针对美国公司的 HTTP DDoS 攻击环比增长 45%，使美国再次成为应用层 DDoS 攻击的最主要目标。中国企业受到的攻击环比减少 79%，导致其从第一位下降至第四位。塞浦路斯受到的攻击增加了 171%，使其成为第二季度受攻击第二多的国家。其次是中国香港、中国内地和波兰。

网络层 DDoS 攻击

应用层攻击的目标是（OSI 模型）第七层的应用程序，其上运行着最终用户尝试访问的服务（对我们而言是 HTTP/S），而网络层攻击旨在使网络基础设施（例如内联路由器和服务器）及互联网链路本身不堪重负。

网络层 DDoS 攻击：月份分布

在第二季度，网络层 DDoS 攻击环比增长 75%，100 Gbps 及更大规模的攻击环比增长了 19%。

第二季度期间，网络层 DDoS 攻击的总数同比增长了 75%，但环比变化不大。4 月是当季攻击最活跃的月份，接近 40% 的攻击发生在 4 月。

网络层 DDoS 攻击：行业分布

在第二季度，针对电信公司的攻击环比增长 45%。

电信行业连续第二个季度成为网络层 DDoS 攻击的最主要目标。更有甚者，针对电信公司的攻击环比增长了 45%。其次为博彩行业，第三位是信息技术和服务公司。

网络层 DDoS 攻击：按目标国家/地区分布

对美国网络发动的攻击环比增长了 70%。

在第二季度，美国依然是受到最多攻击的国家。其次是新加坡，从前一季度的第四位跃升至第二位。德国居第三位，然后是中国、马尔代夫和韩国。

网络层 DDoS 攻击：出口国家分布

在第二季度，Cloudflare 在巴勒斯坦和阿塞拜疆观察到的流量中，接近三分之一属于一次网络层 DDoS 攻击。

在尝试了解网络层 DDoS 攻击的来源时，我们不能使用分析应用层攻击的相同方法。要发动应用层 DDoS 攻击，必须在客户端和服务器之间发生成功的握手，才能建立 HTTP/S 连接。要发生成功的握手，攻击不能伪造其来源 IP 地址。虽然攻击者可以使用僵尸网络、代理和其他方法来混淆自己的身份，攻击客户端的源 IP 地址位置足以代表应用层 DDoS 攻击的攻击来源。

另一方面，要发动网络层 DDoS 攻击，大部分情况下不需要握手。攻击者可伪造源 IP 地址来混淆攻击来源，并在攻击属性中引入随机性，使得简单的 DDoS 防御系统更难拦截攻击。因此，如果我们根据伪造的源 IP 推导出源国家/地区，我们将得到一个伪造的国家/地区。

为此，在分析网络层 DDoS 攻击来源时，我们以接收流量的 Cloudflare 数据中心的位置来分类流量，而非根据（可能）伪造的源 IP 地址，以便了解攻击的源头。由于在全球 270 多个城市设有数据中心，我们能够在报告中实现地理位置上的准确性。然而，即使这个方法也不是 100% 准确的，因为出于降低成本、拥堵和故障管理等各种原因，流量可通过各种互联网服务提供商（ISP）和国家/地区来回传和路由。

巴勒斯坦从第二位上升到第一位，成为网络层 DDoS 攻击比例最高的 Cloudflare 数据中心所在地。其次是阿塞拜疆、韩国和安哥拉。

要查看所有地区和国家，请参阅交互式地图。

攻击手段

在第二季度，DNS 攻击有所增加，成为第二大最常见的攻击手段。

攻击手段是指攻击者用于发动 DDoS 攻击的方法，即 IP 协议、数据包属性（如 TCP 标志）、洪水方法和其他条件。

在第二季度，56% 的网络层攻击为 SYN 洪水。SYN 洪水依然是最常见的攻击手段。此类攻击滥用有状态 TCP握手的初始连接请求。在初始连接请求期间，由于是新的 TCP 请求，服务器没有关于它的任何上下文；如果缺乏适当的保护措施，服务器可能难以缓解大量涌入的初始连接请求。这使得攻击者更容易消耗未受保护的服务器的资源。

其次是针对 DNS 基础设施的攻击，同样滥用 TCP 连接流的 RST 洪水，以及基于 UDP 的一般攻击。

新兴威胁

在第二季度，最主要的新兴威胁包括基于 CHARGEN、Ubiquiti 和 Memcached 的攻击。

识别最主要的攻击手段有助于组织了解威胁形势，继而帮助他们改善安全态势，以防范这些威胁。同样的，新兴威胁也许仅占很少一部分，但了解这些威胁有助于在它们成为强大力量前加以缓解。

第二季度，最主要的威胁是滥用字符生成器协议（CHARGEN）的放大攻击，反射暴露 Ubiquiti 设备流量的放大攻击，以及臭名昭著的 Memcached 攻击。

滥用 CHARGEN 协议发动放大攻击

在第二季度，滥用 CHARGEN 协议的攻击同比增长 378%。

字符生成器（CHARGEN）协议最初在RFC 864(1983) 中定义，是互联网协议套件的一种服务。顾名思义，这种协议任意生成字符，并不断向客户端发送字符，直到客户端关闭连接为止。它最初的目的是用于测试和调试。然而，这种协议极少被使用，因其很容易被滥用来产生放大/反射攻击。

攻击者可以假冒受害者的源 IP，并欺骗世界各地的支持服务器来将随意产生的字符发送“回”受害者的服务器。这是一种放大/反射攻击。如果有足够的 CHARGEN 数据流，受害者的服务器——如果不受保护——就会被淹没，无法处理合法流量，导致拒绝服务事件。

利用 Ubiquiti 发现协议的放大攻击

在第二季度，利用 Ubiquity 发动的攻击环比增长 313%。

Ubiquiti 是一家位于美国的公司，为消费者和企业提供网络和物联网（IoT）设备。使用 Ubiquiti 发现协议，可通过 UDP/TCP 端口 10001 发现网络中 Ubiquiti 设备。

类似于 CHARGEN 攻击手段，攻击者可将源 IP 假冒成受害者的 IP 地址并发送使 10001 端口打开的 IP 地址。后者将对受害者发出响应，如容量足够，受害者的服务器就会被淹没。

Memcached DDoS 攻击

在第二季度，Memcached DDoS 攻击环比增长了 281%。

Memcached 是一个数据库缓存系统，可以加快网站和网络的速度。类似于 CHARGEN 和 Ubiquiti，支持 UDP 的 Memcached 服务器可被滥用来发动放大/反射 DDoS 攻击。在这种情况下，攻击者会从缓存系统请求内容，并在 UDP 数据包中将受害者的 IP 地址伪造成源 IP。这些响应可以被放大高达 51200 倍，从而淹没受害者的服务器。

网络层 DDoS 攻击：攻击规模分布

100 Gbps 以上的大容量攻击环比增长 19%。持续 3 小时以上的攻击增长 9%。

衡量 L3/4 DDoS 攻击的规模有不同的方法。一种方法是测量它产生的流量大小，以比特率为单位（例如，Tbps 或 Gbps）。另一种是测量它产生的数据包数，以数据包速率为单位（例如， Mpps：百万数据包/每秒）。

高比特率的攻击试图使互联网链路饱和，而高数据包速率的攻击会使路由器或其他联网硬件设备不堪重负。这些设备分配一定的内存和计算能力来处理每个数据包。因此，通过向设备发送大量数据包，该设备的处理资源就可能被耗尽。在这种情况下，数据包就会“被丢弃”，即设备无法再处理数据包。对用户而言，这会导致服务中断和拒绝服务。

数据包速率分布

大多数网络层 DDoS 攻击的包速率在 50 kpps 以下。虽然 50 kpps 在 Cloudflare 的尺度上处于较低水平，但其仍能轻松地压垮不受保护的互联网资产，甚至能堵塞标准的千兆以太网连接。

从攻击规模的变化来看，超过 50 kpps 的数据包密集型攻击环比有所减少，导致小规模攻击增加了 4%。

比特率分布

第二季度期间，大多数网络层 DDoS 攻击的包速率在 500 Mbps 以下。对 Cloudflare 的规模而言，这也是微不足道的，但仍能在很短时间内导致容量较小且未受保护的互联网资产宕机，或至少导致堵塞，即使标准的千兆以太网连接也有可能受到影响。

值得关注的是，介于 500 Mbps 和 100 Gbps 的大型攻击环比减少了 20-40%，但超过 100 Gbps 的大规模攻击增长了 8%。

网络层 DDoS 攻击：持续时间分布

在第二季度，持续 3 小时以上的攻击增加了 9%。

我们测量攻击持续时间的方式是：记录系统首次检测到攻击与具备该攻击特征的最后一个数据包之间的时间差。

在第二季度，51% 的网络层 DDoS 攻击持续不到 10 分钟。另外 41% 持续 10-20 分钟。余下 8% 包括从 20 分钟到 3 小时以上的的攻击。

值得注意的是，即使某一次攻击仅持续几分钟，如果能够取得成功，则其影响会远远超过最初的攻击持续时间。对于一次成功的攻击，IT 人员可能要花费数小时或甚至数天才能恢复服务。

虽然大多数攻击都很短，但我们发现，持续 20-60 分钟的攻击增长超过 15%，持续3 小时以上的攻击增长 12%。

短时间的攻击很可能不被察觉，特别是突发式攻击，此类攻击会在几秒钟内用大量的包、字节或请求轰击目标。在这种情况下，依赖于安全分析来手动缓解的 DDoS 保护服务没有机会及时缓解攻击。此类服务只能从攻击后分析中吸取教训，然后部署过滤该攻击指纹的新规则，期望下次能捕捉到它。同样，使用“按需”服务（即安全团队在遭到攻击时将流量重定向至 DDoS 保护提供商）也无济于事，因为在流量到达按需 DDoS 保护提供商前，攻击就已经结束了。

建议企业使用始终启用的自动化 DDoS 防护服务，此类服务能分析流量并应用实时指纹识别，从而及时拦截短暂的攻击。

摘要

Cloudflare 的使命是帮助构建更好的互联网，使互联网对所有人都更安全、更快速、更可靠——即使面对 DDoS 攻击也如此。作为这个使命的一部分，我们自 2017 年以来一直向我们所有客户提供免费的不计量、无限 DDoS 防护。近年来，攻击者发动 DDoS 攻击的难度变得越来越低。为了对抗攻击者的优势，我们想确保所有规模的组织能够更轻松且免费地防御各种类型的 DDoS 攻击。
还没有使用 Cloudflare？立即开始使用我们的 Free 和 Pro 计划来保护您的网站，也可以联系我们，使用 Magic Transit 为您的整个网络提供全面的 DDoS 保护。

2022年第2四半期におけるDDoS攻撃の傾向

2022-07-06 Omer Yoachimik

Post Syndicated from Omer Yoachimik original https://blog.cloudflare.com/ddos-attack-trends-for-2022-q2-ja-jp/

2022年第2四半期におけるDDoS攻撃の傾向

2022年第2四半期DDoSレポートへようこそ。このレポートには、グローバルなCloudflareネットワークで観測されたDDoS脅威の状況についてのインサイトと動向が含まれています。また、本レポートのインタラクティブ版はRadarでご覧いただけます。

毎秒2600万件のリクエストのHTTPS DDoS攻撃をCloudflareが自動的に検出して軽減するなど、第2四半期には、これまでにない大規模な攻撃が発生しています。さらに、ウクライナとロシアに対する攻撃は続いており、新しいランサムDDoS攻撃キャンペーンも出現しています。

ハイライト

ウクライナおよびロシアのインターネット

地上での戦争は、情報の拡散を狙った攻撃を伴います。
第2四半期に主なDDoS攻撃の標的となったのは、ウクライナの放送メディア企業でした。実際、最も攻撃されている上位6業種は、すべてオンライン/インターネットメディア、出版、放送のものです。
一方、ロシアでは、オンラインメディアが最も攻撃されている業界として第3位に転落しました。トップに向かって進んでいる企業であるため、第2四半期に最も標的とされたのは、ロシアの銀行、金融サービス、保険（BFSI）企業で、アプリケーション層DDoS攻撃全体の約50%がBFSIセクターを標的としていました。ロシアの暗号通貨関連企業は2番目に最も攻撃されました。

オープンインターネットのロシアへの流入を続けるため、攻撃を防ぐためにCloudflareが行っていることをご覧ください。

ランサムDDoS攻撃

Fancy Lazarusを名乗るエンティティによるランサムDDoS攻撃の新たな波が来ています。
2022年6月にはランサム攻撃がピークに達し、これまでの1年間で最高となりました。DDoS攻撃を経験した調査回答者の5人に1人が、ランサムDDoS攻撃などの脅威を受けたと回答しています。
第2四半期全体では、ランサムDDoS攻撃の割合が前四半期比で11%増となりました。

アプリケーション層DDoS攻撃

2022年第2四半期、アプリケーション層DDoS攻撃は前年比で44％増となりました。
米国の組織が最も狙われ、次いでキプロス、香港、中国と続きます。キプロスにおける組織への攻撃は前四半期比で171%増となりました。
第2四半期に最も標的にされたのは航空・宇宙業界、次いでインターネット業界、銀行・金融サービスおよび保険、そして4位はゲーミング/ギャンブルとなっています。

ネットワーク層DDoS攻撃

2022年第2四半期、ネットワーク層DDoS攻撃は前年比で75％増となりました。100Gbps以上の攻撃は前四半期比で19%増、3時間以上継続する攻撃は前四半期比で9%増となりました。
攻撃された上位の業種は、電気通信、ゲーミング/ギャンブル、情報技術およびサービス業界でした。
米国の組織が最も標的にされ、次いでシンガポール、ドイツ、中国と続いています。

本レポートは、CloudflareのDDoS Protectionシステムによって自動的に検知・軽減されたDDoS攻撃に基づいています。この仕組みの詳細については、詳しく書かれたこちらのブログ記事をご覧ください。

当社ネットワークで観測されたDDoS攻撃の測定方法についての特記事項

攻撃の傾向を分析するために、当社のグローバルネットワーク、特定の場所、または特定のカテゴリ（業界や請求先の国など）で観測された総トラフィック（攻撃＋クリーン）に占める攻撃トラフィックの割合である「DDosの活動」レートを計算します。割合を測定することで、データポイントを正規化し、例えば総トラフィックが多く、攻撃回数も多いと思われるCloudflareデータセンターに対する絶対数に反映される数値の偏りを回避することができます。

ランサム攻撃

当社のシステムはトラフィックを常時分析し、DDoS攻撃を検知すると自動的に被害軽減措置を適用するシステムです。DDoSの被害に遭われたお客様には、攻撃の性質や軽減措置の効果をよりよく理解するために、自動化されたアンケートをお願いしています。

Cloudflareは2年以上前から、攻撃を受けたお客様を対象にアンケートを実施しています。アンケート項目の1つに、DDoS攻撃を中止する代わりに脅威や支払いを要求する身代金請求書を受け取ったかどうかというものがあります。

第2四半期に脅威や身代金要求メッセージがあったという回答は、前四半期比、前年比ともに11％増となりました。当四半期は、高度で継続的な脅威（APT）グループ、「Fancy Lazarus」を名乗るエンティティが仕掛けたランサムDDoS攻撃を軽減しています。金融機関や暗号通貨企業などを中心にキャンペーンを展開しています。

第2四半期に掘り下げると、6月には回答者の5人に1人がランサムDDoS攻撃や脅威を受けたと報告しています。これは2022年で最も高い月で、2021年12月以降最高となりました。

アプリケーション層DDoS攻撃

アプリケーション層DDoS攻撃（具体的にはHTTP DDoS攻撃）は通常、正当なユーザーリクエストを処理できないようにしてWebサーバーを停止させることを目的とします。処理能力を超えるリクエストが殺到すると、サーバーは正当なリクエストをドロップするか、場合によってはクラッシュし、その結果、正当なユーザーに対するパフォーマンスの低下や障害がに繋がります。

アプリケーション層DDoS攻撃の月別推移

第2四半期のアプリケーション層DDoS攻撃は、前年比で44％増となりました。

全体として、第2四半期のアプリケーション層DDoS攻撃の量は、前年比で44%増となりましたが、前四半期比では16%減となりました。5月は当四半期で最も忙しい月でした。アプリケーション層DDoS攻撃は、全体の約47%が5月に発生したのに対し、6月に起きた攻撃数は最も少ないものでした（18%）。

アプリケーション層DDoS攻撃＜業界別＞

航空・宇宙業界への攻撃は前四半期比で256％増となりました。

第2四半期では、アプリケーション層DDoS攻撃で最も標的とされたのは航空・宇宙業界でした。以下、銀行・金融機関・保険（BFSI）業界、ゲーミング/ギャンブル業界と続きます。

ウクライナおよびロシアのサイバースペース

ウクライナで最も狙われているのはメディア企業と出版社です。

ウクライナでの戦争が地上、空中、水上で続いているように、サイバースペースでも戦争が続いています。ウクライナ企業を標的にするエンティティは、情報を封じ込めようとしているようです。ウクライナで最も攻撃された上位6業種は、すべて放送、インターネット、オンラインメディア、出版のもので、これはウクライナを標的とするDDoS攻撃全体のほぼ80%に相当します。

もう一方の側は、ロシアの銀行、金融機関、保険（BFSI）の企業が最も多くの攻撃を受けました。DDoS攻撃全体のほぼ50%がBFSIセクターを標的としました。2番目に最も標的となったのは暗号通貨業界、次いでオンラインメディアでした。

戦争の両側で、攻撃は高度に分散化され、世界中に分散されたボットネットが使用されていることが分かります。

アプリケーション層DDoS攻撃＜攻撃元の国別＞

第2四半期には、中国からの攻撃が112%増となった一方で、米国からの攻撃は43%縮小しています。

HTTP攻撃の発信元を理解するため、当社は攻撃のHTTPリクエストを生成したクライアントに属する送信元IPアドレスのジオロケーションを調べました。ネットワーク層の攻撃とは異なり、HTTP攻撃ではソースIPアドレスをスプーフィングすることはできません。ある国でのDDoS活動の割合が高いということは、その特定の国が攻撃を仕掛けているということではなく、その国の国境内から活動するボットネットが存在することを示しています。

HTTP DDoS攻撃の主な発生源として、第2四半期連続で米国がトップとなりました。米国に続く2位は中国、3位と4位はインドとドイツです。米国が1位を維持しているにもかかわらず、米国発の攻撃が前四半期比で43%減少した一方で、中国からの攻撃が112%、インドからの攻撃が89%、ドイツからの攻撃が50%と、他の地域からの攻撃は増加しています。

アプリケーション層DDoS攻撃＜標的国別＞

どの国が最もHTTP DDoS攻撃の標的になっているかを特定するため、お客様の請求先国別にDDoS攻撃を分類し、全DDoS攻撃に対する割合で表現しています。

米国を拠点とする国へのHTTP DDoS攻撃は前四半期比で45%増となり、アプリケーション層DDoS攻撃の主な標的として米国が1位に返り咲きました。中国企業への攻撃は前四半期比で79％減となり、1位から4位に下がりました。キプロスへの攻撃は171％増加し、第2四半期に最も攻撃された国第2位となりました。キプロスに続いて、香港、中国、ポーランドが続いています。

ネットワーク層DDoS攻撃

アプリケーション層攻撃は、エンドユーザーがアクセスしようとしているサービスを実行するアプリケーション（OSI参照モデルのレイヤー7）を狙うのに対し、ネットワーク層攻撃はネットワークインフラ（インラインルーターやサーバーなど）とインターネットリンクそのものを圧倒しようとします。

ネットワーク層DDoS攻撃＜月別＞

第2四半期のネットワーク層DDoS攻撃は前年比で75%増、100Gbps以上の帯域幅消費型攻撃は前四半期比で19%増となりました。

第2四半期は、ネットワーク層DDoS攻撃の総量が前年比で75％増となりましたが、前四半期と比較して大きな変化はありませんでした。4月は、攻撃の約40％が発生し、四半期で最も忙しい月となりました。

業種別ネットワーク層DDoS攻撃

第2四半期の通信会社への攻撃は、前四半期比で45％増となりました。

ネットワーク層DDoS攻撃は、2四半期連続で通信業界が最も多く標的となりました。さらに、通信会社への攻撃は前四半期比で45％増となりました。2位はゲーミング業界、続いて情報技術・サービス企業でした。

ネットワーク層DDoS攻撃＜標的国別＞

米国ネットワークへの攻撃は前四半期比で70％増となりました。

第2四半期においても、米国は最も攻撃された国です。米国に続き、シンガポールが前四半期の4位から2位に急浮上しました。3位はドイツ、それから中国、モルディブ、韓国でした。

流入国別ネットワーク層DDoS攻撃

第2四半期にCloudflareがパレスチナとアゼルバイジャンで観測したトラフィックの約3分の1は、ネットワーク層DDoS攻撃の一部でした。

ネットワーク層DDoS攻撃の発生源を把握しようとする場合、アプリケーション層の攻撃解析と同じ方法は使えません。アプリケーション層DDoS攻撃を仕掛けるには、HTTP/S接続を確立するために、クライアントとサーバーの間でハンドシェイクを成功させる必要があります。ハンドシェイクを成功させるため、攻撃者はその送信元IPアドレスを偽装することができません。そのため攻撃者はボットネット、プロキシ、およびその他の方法を使用して身元を難読化させることができますが、攻撃側クライアントの送信元IPは偽装できないため、そのIPはアプリケーション層DDoS攻撃の発信源を正しく示しています。

一方、ネットワーク層DDoS攻撃を仕掛けるには、ほとんどの場合ハンドシェイクは必要ありません。攻撃者は攻撃元を難読化し、攻撃特性にランダム性を導入して単純なDDoS防御システムでは攻撃をブロックすることを困難にするために、ソースIPアドレスを偽装することができます。そのため、偽装された送信元IPに基づいて発信源の国を導き出した場合、「偽装された国」を得ることになります。

このため、ネットワーク層DDoS攻撃の発信源を分析する際には、攻撃の発信源を把握するためにスプーフィングされた（可能性のある）ソースIPではなく、トラフィックが取り込まれたCloudflareエッジデータセンターのロケーション別にバケットを構成します。世界270以上の都市にデータセンターがあるため、レポートで地理的な精度を実現できます。ただし、コスト削減から輻輳や障害管理まで、さまざまな理由でトラフィックがバックホールされ、さまざまなインターネットサービスプロバイダや国を経由してルーティングされる可能性があるため、この方法でも100%正確ではありません。

ネットワーク層DDoS攻撃の割合が最も高いCloudflareのロケーションとして、パレスチナが2位から1位に跳ね上がりました。パレスチナに続いて、アゼルバイジャン、韓国、アンゴラと続きます。

すべての地域と国を表示するには、インタラクティブマップをご覧ください。

攻撃ベクトル

第2四半期では、DNS攻撃が増加し、2番目に多い攻撃ベクトルとなりました。

攻撃ベクトルとは、攻撃者がDDoS攻撃を行う際に用いる手法のことで、IPプロトコル、TCPフラグなどのパケット属性、フラッディング方法などの基準を示す言葉です。

第2四半期において、ネットワーク層に対する全攻撃の56%は、SYNフラッドでした。SYNフラッドは、依然として最も一般的な攻撃ベクトルです。この攻撃は、ステートフルなTCPハンドシェイクの最初の接続リクエストを悪用します。この最初の接続リクエストの間、サーバーは新しいTCP接続に関するコンテキストを持たず、適切な保護がなければ、最初の接続リクエストのフラッドを軽減することが困難であることが分かるかもしれません。このため、攻撃者は保護されていないサーバーのリソースを容易に消費することができます。

SYNフラッドの次は、DNSインフラストラクチャを狙った攻撃、再びTCP接続フローを悪用するRSTフラッド、UDPを使った一般的な攻撃です。

新たな脅威

第2四半期における、新たな上位の脅威にはCHARGEN、Ubiquiti、Memcachedを狙った攻撃があります。

上位の攻撃ベクトルを特定することは、組織が脅威の状況を理解するのに役立ちます。そうすることで、これらの脅威から身を守るためにセキュリティ体制を強化することができます。同様に、まだ攻撃の大部分を占めていない新たな脅威について知ることは、それらが大きな力となる前に軽減するのに役立ちます。

第2四半期には、Character Generatorプロトコル（CHARGEN）を悪用した増幅攻撃、露出したUbiquitiデバイスのトラフィックを反映した増幅攻撃、悪名高いMemcached攻撃が新たな脅威の上位にランクインしています。

CHARGENプロトコルを悪用した増幅攻撃の開始

第2四半期には、CHARGENプロトコルを悪用した攻撃が前四半期比で378%増となりました。

RFC 864（1983）で最初に定義されたCharacter Generator（CHARGEN）プロトコルは、インターネットプロトコルスイートのサービスで、その名の通り、文字を任意に生成し、クライアントが接続を閉じるまでクライアントへの送信を停止しません。その当初の目的は、テストとデバッグでした。しかし、増幅/リフレクション攻撃を生成するために非常に簡単に悪用される可能性があるため、めったに使用されません。

攻撃者は、被害者のソースIPをスプーフィングすることができ、世界中のサポートサーバーを騙して、任意の文字のストリームを被害者のサーバーに「戻す」ことができます。この種の攻撃は、増幅/リフレクションです。十分な数のCHARGENストリームが同時に発生すると、被害者のサーバーは、保護されていない場合、殺到して正当なトラフィックに対処できなくなり、結果としてサービス拒否が発生することになります。

Ubiquiti Discoveryプロトコルを不正利用した増幅攻撃

第2四半期には、ユビキティに対する攻撃が前四半期比で313％増となりました。

Ubiquitiは、米国に拠点を置く企業で、消費者や企業向けにInternet of Things（IoT）デバイスを提供しています。Ubiquitiのデバイスは、UDP/TCPポート10001のUbiquiti Discoveryプロトコルを使用してネットワーク上で見つけることができます。

CHARGEN攻撃ベクトルと同様に、ここでも攻撃者はソースIPを被害者のIPアドレスに偽装し、10001番ポートを開放しているIPアドレスに吹き付けることができます。そして、それらは被害者に対応し、量が十分であれば実質的に殺到することになります。

memchachedを利用したDDoS攻撃

第2四半期には、Memcached DDoS攻撃は前四半期比で281%増となりました。

Memcachedは、Webサイトやネットワークを高速化するためのデータベースキャッシュシステムです。CHARGENやUbiquitiと同様に、UDPをサポートするMemcachedサーバーは、増幅/リフレクション型DDoS攻撃を仕掛けるために悪用される可能性があります。この場合、攻撃者はキャッシュシステムからコンテンツをリクエストし、UDPパケットのソースIPとして被害者のIPアドレスをスプーフィングします。被害者には、最大51,200倍に増幅されたMemcacheのレスポンスが殺到することになります。

ネットワーク層DDoS攻撃＜攻撃レート別＞

100Gbpsを超える帯域幅消費型攻撃は前四半期比で19%増となりました。3時間以上の攻撃は9％増加しました。

L3/4 DDoS攻撃の規模の測定には、さまざまな方法があります。1つは送信するトラフィックの量で、ビットレート（具体的にはテラビット/秒またはギガビット/秒）を使用して測定するものです。もう1つは送信するパケットの数で、パケットレート（具体的には、何百万パケット/秒）を使用して測定するものです。

ビットレートの高い攻撃は、インターネットリンクの閉塞を発生させることによってサービス妨害を起こそうとし、パケットレートの高い攻撃はサーバーやルーター、その他のインラインハードウェア機器を過負荷状態に陥れようとします。これらの機器は各パケットの処理に特定量のメモリと計算能力を割きます。多数のパケットが送り付けられると機器の処理リソースが枯渇してしまう可能性があります。その場合はパケットが「ドロップ」されます。つまり、機器がそれらを処理できない状態となるのです。ユーザーに対しては、サービスの中断や拒否になります。

パケットレート別分布

ネットワーク層DDoS攻撃の大半は、毎秒5万パケット以下にとどまっています。50kppsはCloudflareの規模では低い方ですが、それでも保護されていないインターネットのプロパティを簡単にダウンさせ、標準的なギガビットイーサネット接続でさえも輻湊させることができます。

攻撃規模の変化を見ると、50 kppsを超えるパケット集中型の攻撃が第2四半期に減少し、その結果、小規模な攻撃が4％増加したことがわかります。

ビットレート別分布

第2四半期は、ネットワーク層DDoS攻撃の大半が500Mbps未満にとどまっています。これもCloudflareの規模ではわずかな減少ですが、保護されていないインターネットのプロパティを即座に停止させ、また少なくとも標準的なギガビットイーサネット接続でさえも輻湊を引き起こすことができます。

興味深いことに、500Mbpsから100Gbpsの間の大規模な攻撃は前四半期比で20～40%減少しましたが、100Gbps以上の帯域幅消費型攻撃は8%増加しました。

ネットワーク層DDoS攻撃＜継続時間別＞

第2四半期では、3時間以上の攻撃は9%増となりました。

当社では、攻撃が当社のシステムによって最初に検出されたときと、特定のターゲットに向けた攻撃シグネチャを持つ最後のパケットを確認したときの差を記録することによって、攻撃の持続時間を測定しています。

第2四半期では、ネットワーク層DDoS攻撃の51%が10分未満で終了しました。さらに41％は10〜20分でした。残りの8％は、20分から3時間以上にわたる攻撃です。

留意すべき重要な点は、たとえ数分間の攻撃であっても、それが成功すれば、その影響は最初の攻撃時間をはるかに超えて続く可能性があるということです。攻撃が成功した場合、対応するIT担当者はサービスの復旧に数時間から数日を費やすことがあります。

ほとんどの攻撃が短時間になっているものの、20分〜60分の攻撃が15％以上、3時間以上の攻撃が12％増となっていることがわかります。

短時間の攻撃は検出されない可能性があり、特に標的に対して数秒以内に大量のパケットやバイト、リクエストを送りつけるバースト攻撃は見逃されがちです。この場合、セキュリティ分析に基づく手作業の軽減措置に依存するDDoS攻撃対策では、攻撃への被害軽減措置がとても間に合いません。攻撃について事後の分析を通して学び、その攻撃固有のフィンガープリントでフィルタリングする新たなルールをデプロイして、次回の攻撃は検知できるよう願うしかありません。同様に、「オンデマンド」サービスを利用してセキュリティチームが攻撃中にDDoS対策サービスのプロバイダーへトラフィックをリダイレクトする場合も、オンデマンドDDoS対策のプロバイダーへトラフィックがルーティングされる前に攻撃が済んでしまうため非効率です。

これらの企業では、トラフィックを分析し、短時間の攻撃をブロックするのに十分な速さでリアルタイムのフィンガープリンティングを適用する、自動化された常時稼働型のDDoS攻撃対策サービスを使用することが推奨されます。

まとめ

Cloudflareのミッションは、より良いインターネットの構築を支援することです。より良いインターネットとは、たとえDDoS攻撃に直面しても、誰にとっても、より安全で、より速く、より信頼できるインターネットです。ミッションの一環として、2017年以降、すべてのお客様に定額制で無制限のDDoS攻撃対策を無償で提供しています。ここ数年、攻撃者がDDoS攻撃を仕掛けることはますます容易になってきています。しかし、このように簡単になったからこそ、あらゆる規模の組織があらゆる種類のDDoS攻撃から身を守ることも、これまで以上に簡単かつ無料でできるようにしたいと考えています。
まだCloudflareをお使いでない方は、当社のFreeまたはProプランを使用したWebサイトの保護を今すぐ始めるか、Magic Transitを使用したネットワーク全体の包括的なDDos攻撃対策に関してお問い合わせください。

Tendencias de los ataques DDoS en el segundo trimestre de 2022

2022-07-06 Omer Yoachimik

Post Syndicated from Omer Yoachimik original https://blog.cloudflare.com/ddos-attack-trends-for-2022-q2-es-es/

Tendencias de los ataques DDoS en el segundo trimestre de 2022

Te damos la bienvenida a nuestro informe sobre los ataques DDoS del segundo trimestre de 2022, que incluye nuevos datos y tendencias sobre el panorama de las amenazas DDoS, según lo observado en la red global de Cloudflare. Puedes consultar la versión interactiva de este informe en Radar.

En el segundo trimestre, hemos observado algunos de los mayores ataques hasta la fecha, incluido un ataque DDoS HTTPS de 26 millones de solicitudes por segundo que Cloudflare detectó y mitigó automáticamente. Además, continúan los ataques contra Ucrania y Rusia, al tiempo que ha aparecido una nueva campaña de ataques DDoS de rescate.

Aspectos destacados

Internet en Ucrania y Rusia

La guerra en el terreno va acompañada de ataques dirigidos a la difusión de información.
Las empresas de medios de comunicación de Ucrania fueron el blanco más común de ataques DDoS en el segundo trimestre. De hecho, los seis sectores que recibieron el mayor número de ataques pertenecen a los medios de comunicación en línea/Internet, la edición y audiovisual.
En Rusia, por el contrario, los medios de comunicación en línea descendieron al tercer lugar como el sector más afectado. En los primeros puestos, las empresas de banca, servicios financieros y seguros (BFSI) de Rusia fueron las que recibieron más ataques en el segundo trimestre. Casi el 50 % de todos los ataques DDoS a la capa de aplicaciones tuvieron como objetivo el sector BFSI. Las empresas de criptomonedas en Rusia fueron el segundo sector peor parado.

Más información sobre las medidas de Cloudflare para mantener el flujo de Internet abierto en Rusia y evitar que se propaguen los ataques fuera del país.

Ataques DDoS por rescate

Hemos observado una nueva oleada de ataques DDoS de rescate por parte de entidades que dicen ser Fancy Lazarus.
En junio de 2022, los ataques de rescate alcanzaron su punto más alto del año hasta la fecha. Uno de cada cinco encuestados que experimentaron un ataque DDoS declaró haber sido objeto de un ataque DDoS de rescate u otras amenazas.
En general, en el segundo trimestre, el porcentaje de ataques DDoS de rescate aumentó un 11 % en términos intertrimestrales.

Ataques DDoS a la capa de aplicación

En el segundo trimestre de 2022, los ataques DDoS a la capa de aplicación se incrementaron un 44 % respecto al mismo periodo del año pasado.
Las organizaciones de Estados Unidos fueron las más afectadas, seguidas de Chipre, Hong Kong y China. Los ataques a organizaciones en Chipre aumentaron un 171 % en comparación con el trimestre anterior.
El sector de la aviación y aeroespacial fue el más afectado en el segundo trimestre, seguido de Internet, la banca, los servicios financieros y los seguros, y los videojuegos/apuestas, que ocuparon el cuarto lugar.

Ataques DDoS a la capa de red

En el segundo trimestre de 2022, los ataques DDoS a la capa de red aumentaron un 75 % interanual. Los ataques de 100 GB/s o más se incrementaron un 19 % con respecto al trimestre anterior, y los ataques que duraron más de 3 horas se alzaron un 9 % en la misma comparación.
Los principales blancos de ataques fueron los sectores de las telecomunicaciones, videojuegos/apuestas y tecnologías de la información y servicios.
Las organizaciones de Estados Unidos fueron las que recibieron el mayor número de ataques, seguidas de Singapur, Alemania y China.

Este informe contempla los ataques DDoS que los sistemas de protección contra DDoS de Cloudflare detectaron y mitigaron de manera automática. Para obtener más información sobre su funcionamiento, consulta esta publicación detallada del blog.

Nota sobre cómo medimos los ataques DDoS observados en nuestra red

Para analizar las tendencias de los ataques, calculamos la tasa de la “actividad DDoS”, que es el porcentaje de tráfico de ataque sobre el tráfico total (ataque + legítimo) observado en nuestra red global, o en una ubicación específica o categoría determinada (por ejemplo, sector o país de facturación). Medir los porcentajes nos permite normalizar los datos y evitar los sesgos reflejados en las cifras absolutas hacia, por ejemplo, un centro de datos de Cloudflare que recibe más tráfico total y, probablemente, también más ataques.

Ataques de rescate

Nuestros sistemas analizan constantemente el tráfico y aplican soluciones de mitigación de forma automática cuando se detectan ataques DDoS. Cada cliente que es blanco de un ataque DDoS recibe una encuesta automatizada que nos ayuda a comprender mejor la naturaleza del ataque y el éxito de la mitigación.

Desde hace más de dos años, Cloudflare ha encuestado a clientes que han sido víctimas de ataques. Una de las preguntas de la encuesta es si han recibido una amenaza o una nota de rescate exigiendo un pago a cambio de detener el ataque DDoS.

El número de encuestados que informaron de amenazas o notas de rescate en el segundo trimestre aumentó un 11 % en términos intertrimestrales e interanuales. Durante este trimestre, hemos mitigado ataques DDoS de rescate lanzados por entidades que dicen ser el grupo de amenazas avanzadas persistentes “Fancy Lazarus”. La campaña se ha centrado en instituciones financieras y empresas de criptomonedas.

Ya hacia finales del segundo trimestre, en junio, uno de cada cinco encuestados declaró haber recibido un ataque o amenaza DDoS de rescate, el pico mensual más alto del año y desde diciembre de 2021.

Ataques DDoS a la capa de aplicación

Los ataques DDoS a la capa de aplicación, en concreto los ataques DDoS HTTP, son ofensivas que suelen tener como objetivo interrumpir un servidor web evitando que pueda procesar las solicitudes legítimas de los usuarios. Si el servidor se satura con más solicitudes de las que puede procesar, el servidor descartará las solicitudes legítimas y, en algunos casos, se bloqueará, lo que degradará el rendimiento o interrumpirá los servicios para los usuarios legítimos.

Ataques DDoS a la capa de aplicación por mes

En el segundo trimestre, los ataques DDoS a la capa de aplicación aumentaron un 44 % interanual.

En general, en el segundo trimestre, el volumen de ataques DDoS a la capa de aplicación aumentó un 44 % interanual, pero disminuyó un 16 % intertrimestral. Mayo fue el mes más activo del trimestre. Casi el 47 % de todos los ataques DDoS a la capa de aplicación tuvieron lugar en mayo, mientras que el menor número de ataques se produjo en junio (18 %).

Ataques DDoS a la capa de aplicación por industria

Los ataques al sector aeronáutico y aeroespacial aumentaron un 256 % con respecto al trimestre anterior.

En el segundo trimestre, el sector de la aviación y el aeroespacial fue el más afectado por los ataques DDoS a la capa de aplicación. En segundo lugar, se situó el sector BFSI, y en tercer lugar el sector de los videojuegos/apuestas.

El ciberespacio en Ucrania y Rusia

Las empresas de medios de comunicación y editoriales son los principales blancos de ataques en Ucrania.

Mientras la guerra en Ucrania continúa por tierra, mar y aire, también lo hace en el ciberespacio. Las entidades que atacan a empresas ucranianas parecen estar intentando silenciar la información. Los seis principales blancos de ataque en Ucrania pertenecen a los sectores audiovisuales, Internet, medios de comunicación en línea y editorial, lo que supone casi el 80 % de todos los ataques DDoS contra Ucrania.

Del otro lado del conflicto, las empresas rusas de banca, instituciones financieras y seguros fueron las más afectadas. Casi el 50 % de todos los ataques DDoS tuvieron como objetivo el sector BFSI. El segundo sector peor parado fue el de las criptomonedas, seguido de los medios de comunicación en línea.

En ambos lados de la guerra, podemos ver que los ataques están muy distribuidos, lo que indica el uso de botnets distribuidas globalmente.

Ataques DDoS a la capa de aplicación por país de origen

En el segundo trimestre, los ataques procedentes de China aumentaron un 112 %, mientras que los ataques procedentes de Estados Unidos se redujeron un 43 %.

Para entender el origen de los ataques HTTP, observamos la geolocalización de la dirección IP de origen perteneciente al cliente que generó las solicitudes HTTP de ataque. A diferencia de los ataques a la capa de red, las direcciones IP de origen no se pueden suplantar en los ataques HTTP. Un alto porcentaje de actividad DDoS en un país determinado no significa que ese país específico esté lanzando los ataques, sino que indica la presencia de botnets que operan dentro de su propio país.

Por segundo trimestre consecutivo, Estados Unidos encabeza las listas como principal origen de ataques DDoS HTTP. Tras Estados Unidos se encuentra China en segundo lugar, e India y Alemania en el tercer y cuarta posición. Aunque Estados Unidos se mantuvo en el primer puesto, los ataques originados en este país se redujeron un 43 % con respecto al trimestre anterior, si bien los ataques procedentes de otras regiones crecieron. Los ataques de China se alzaron un 112 %, los de India un 89 % y los de Alemania un 50 %.

Ataques DDoS a la capa de aplicación por país de destino

Para identificar qué países son el objetivo de la mayoría de los ataques DDoS HTTP, agrupamos los ataques DDoS por el país de facturación de nuestros clientes y lo representamos como un porcentaje de todos los ataques DDoS.

Los ataques DDoS HTTP a empresas estadounidenses aumentaron un 45 % en términos intertrimestrales, lo que volvió a situar a EE. UU. en el primer lugar como principal objetivo de ataques DDoS a la capa de aplicación. Los ataques a empresas chinas cayeron un 79 % en términos intertrimestrales, pasando así del primer al cuarto puesto. Los ataques a Chipre aumentaron un 171 %, convirtiéndose en el segundo país más atacado en el segundo trimestre. Tras Chipre se encuentran Hong Kong, China y Polonia.

Ataques DDoS a la capa de red

Si bien los ataques a la capa de aplicación (capa 7 del modelo OSI) se dirigen contra la aplicación que ejecuta el servicio al que los usuarios finales intentan acceder (HTTP/S en nuestro caso), los ataques a la capa de red pretenden saturar la infraestructura de la red (como enrutadores y servidores en línea) y la propia conexión de Internet.

Ataques DDoS a la capa de red por mes

En el segundo trimestre, los ataques DDoS a la capa de red se incrementaron un 75 % interanual, y los ataques volumétricos de 100 GB/s o más lo hicieron un 19 % en la misma comparación.

En el segundo trimestre, la cantidad total de ataques DDoS a la capa de red aumentó un 75 % respecto al mismo periodo del año pasado, pero apenas varió en comparación con el trimestre anterior. Abril fue el mes más activo del trimestre, ya que concentró casi el 40 % de los ataques.

Ataques DDoS en la capa de red por sector

En el segundo trimestre, los ataques a empresas de telecomunicaciones aumentaron un 45 % en términos intertrimestrales.

Por segundo trimestre consecutivo, el sector de las telecomunicaciones fue el principal blanco de ataques DDoS a la capa de red. Más aún, los ataques a empresas de telecomunicaciones crecieron un 45 % en comparación con el trimestre anterior. El sector de los videojuegos ocupó el segundo lugar, seguido de las empresas de tecnologías de la información y servicios.

Ataques DDoS en la capa de red por país de destino

Los ataques a las redes estadounidenses crecieron un 70 % en términos intertrimestrales.

En el segundo trimestre, Estados Unidos siguió siendo el país más afectado. Después de EE. UU. se situó Singapur, que escaló del cuarto lugar del trimestre anterior al segundo lugar. En tercer lugar estaba Alemania, y después China, Maldivas y Corea del Sur.

Ataques DDoS a la capa de red por país de ingreso

En el segundo trimestre, casi un tercio del tráfico que Cloudflare observó en Palestina y Azerbaiyán formaba parte de un ataque DDoS a la capa de red.

Para entender dónde se originan los ataques DDoS a la capa de red, no podemos utilizar el mismo método que usamos para el análisis de los ataques a la capa de aplicación. Para lanzar un ataque DDoS contra la capa de aplicación, se debe lograr un protocolo de enlace entre el cliente y el servidor para establecer una conexión HTTP/S. Para que esto ocurra, los ataques no pueden suplantar su dirección IP de origen. Si bien el atacante puede utilizar botnets, proxies y otros métodos para ofuscar su identidad, la ubicación de la dirección IP de origen del cliente atacante representa suficientemente la procedencia de los ataques DDoS a la capa de aplicación.

Por otro lado, para lanzar ataques DDoS a la capa de red, en la mayoría de los casos, no se necesita un protocolo de enlace. Los atacantes pueden suplantar la dirección IP de origen para ofuscar el origen del ataque y desconcertar por el carácter aleatorio de sus propiedades, lo que puede impedir que sistemas sencillos de protección DDoS bloqueen el ataque. Por lo tanto, si tuviéramos que obtener el país de origen basándonos en una dirección IP de origen suplantada, obtendríamos un “país falso”.

Por esta razón, al analizar la procedencia de los ataques DDoS a la capa de red, agrupamos el tráfico por las ubicaciones de los centros de datos de Cloudflare en los que se recibió el tráfico, y no por la dirección IP de origen (potencialmente) suplantada, para comprender la procedencia de los ataques. Podemos conseguir precisión geográfica en nuestro informe porque tenemos centros de datos en más de 270 ciudades de todo el mundo. Sin embargo, incluso este método no es 100 % exacto, ya que el tráfico se puede redireccionar y enrutar a través de varios proveedores de servicios de Internet y países por distintas razones, desde la reducción de costes hasta la gestión de la congestión y los fallos.

Palestina pasó del segundo al primer puesto como ubicación de Cloudflare con el mayor porcentaje de ataques DDoS a la capa de red. Tras Palestina están Azerbaiyán, Corea del Sur y Angola.

Para ver todas las regiones y países, consulta el mapa interactivo.

Vectores de ataque

En el segundo trimestre, los ataques de DNS aumentaron, convirtiéndose en el segundo vector de ataque más frecuente.

Un vector de ataque es un término utilizado para describir el método que el atacante utiliza para lanzar su ataque DDoS, es decir, el protocolo IP, los atributos del paquete, tales como las marcas TCP, el método de inundación y otros criterios.

En el segundo trimestre, el 56 % de todos los ataques a la capa de red fueron inundaciones SYN. Las inundaciones SYN siguen siendo el vector de ataque más popular. Abusan de la solicitud de conexión inicial del protocolo de enlace TCP con estado. Durante esta solicitud de conexión inicial, los servidores no tienen ningún contexto sobre la conexión TCP, ya que es nueva, y sin la protección adecuada pueden tener dificultades para mitigar una avalancha de solicitudes de conexión inicial. Esto facilita que el atacante consuma los recursos de un servidor sin protección.

Después de las inundaciones SYN están los ataques contra la infraestructura DNS, las inundaciones RST que vuelven a abusar del flujo de conexiones TCP y los ataques genéricos sobre UDP.

Amenazas emergentes

En el segundo trimestre, las principales amenazas emergentes fueron los ataques sobre CHARGEN, Ubiquiti y Memcached.

Identificar los principales vectores de ataque ayuda a las organizaciones a comprender el panorama de las amenazas. A su vez, puede ayudarles a mejorar su postura de seguridad para protegerse contra esas amenazas. Del mismo modo, conocer las nuevas amenazas emergentes que aún no representan una parte significativa de los ataques, puede ayudar a mitigarlas antes de que ejerzan una presión importante.

En el segundo trimestre, las principales amenazas emergentes fueron los ataques de amplificación que abusan del protocolo generador de caracteres (CHARGEN), los ataques de amplificación que reflejan el tráfico de los dispositivos Ubiquiti expuestos y el famoso ataque a Memcached.

Abuso del protocolo CHARGEN para lanzar ataques de amplificación

En el segundo trimestre, los ataques que abusan del protocolo CHARGEN aumentaron en un 378 % respecto al trimestre anterior.

Definido inicialmente en el RFC 864 (1983), el protocolo generador de caracteres (CHARGEN) es un servicio de la familia de protocolos de Internet que hace exactamente lo que dice que hace, generar caracteres de forma arbitraria y no dejar de enviarlos al cliente hasta que este cierra la conexión. Su intención original era la de realizar pruebas y depuración. Sin embargo, rara vez se utiliza porque se puede explotar con facilidad para generar ataques de amplificación/reflexión.

Un atacante puede suplantar la dirección IP de origen de su víctima y engañar a los servidores de apoyo de todo el mundo para dirigir un flujo de caracteres arbitrarios “de vuelta” a los servidores de la víctima. Este tipo de ataque es la amplificación/reflexión. Con un número suficiente de flujos simultáneos de CHARGEN, los servidores de la víctima, si no están protegidos, se verán inundados e incapaces de hacer frente al tráfico legítimo, lo que provocará una denegación de servicio.

Ataques de amplificación que explotan el protocolo de descubrimiento de Ubiquiti

En el segundo trimestre, los ataques a Ubiquity aumentaron un 313 % en términos intertrimestrales.

Ubiquiti es una empresa con sede en Estados Unidos que ofrece dispositivos de red e Internet de las cosas (IoT) para consumidores y empresas. Los dispositivos de Ubiquiti se pueden descubrir en una red mediante el protocolo de descubrimiento de Ubiquiti a través del puerto UDP/TCP 10001.

De manera similar al vector de ataque CHARGEN, aquí también los atacantes pueden suplantar la dirección IP de origen para que sea la dirección IP de la víctima y difundir las direcciones IP que tienen el puerto 10001 abierto. Estas responderían a la víctima y la inundarían esencialmente si el volumen es suficiente.

Ataques DDoS dirigido a Memcached

En el segundo trimestre, los ataques DDoS a Memcached aumentaron un 281 % con respecto al trimestre anterior.

Memcached es un sistema de almacenamiento en caché de bases de datos para acelerar los sitios web y las redes. Al igual que CHARGEN y Ubiquiti, los servidores de Memcached que admiten UDP pueden ser objeto de abuso para lanzar ataques DDoS de amplificación/reflexión. En este caso, el atacante solicitaría contenido al sistema de caché y suplantaría la dirección IP de la víctima como dirección IP de origen en los paquetes UDP. La víctima se inundará con respuestas de Memcache que se pueden amplificar por un factor de hasta 51 200 veces.

Ataques DDoS a la capa de red por velocidad de ataque

Los ataques volumétricos de más de 100 GB/s aumentan un 19 % respecto al trimestre anterior. Los ataques de más de 3 horas aumentaron un 9 %.

Hay diferentes formas de medir el tamaño de un ataque DDoS a las capas 3 y 4. Una es el volumen de tráfico que entrega, medido como la velocidad de bits (en concreto, terabits por segundo o gigabits por segundo). Otro es el número de paquetes que entrega, medido como la velocidad de paquetes (en concreto, millones de paquetes por segundo).

Los ataques con una velocidad de bits elevada intentan provocar un evento de denegación de servicio bloqueando la conexión de Internet, mientras que los ataques con alta velocidad de paquetes tratan de saturar los servidores, enrutadores u otros dispositivos de hardware en línea. Estos dispositivos dedican una cierta cantidad de memoria y capacidad de procesamiento para procesar cada paquete. Por lo tanto, si se satura con muchos paquetes, el dispositivo se puede quedar sin recursos de procesamiento. En este caso, los paquetes se “descartan”, es decir, el dispositivo no puede procesarlos. Para los usuarios, esto se traduce en interrupciones y denegación del servicio.

Distribución por velocidad de paquete

La mayoría de los ataques DDoS a la capa de red siguen siendo inferiores a 50 000 paquetes por segundo. Si bien 50 000 paquetes está en el extremo inferior del Spectrum de Cloudflare, esta velocidad puede interrumpir fácilmente propiedades de Internet que no estén protegidas y sobrecargar incluso una conexión Gigabit Ethernet estándar.

Si observamos los cambios en el tamaño de los ataques, podemos ver que los ataques de un volumen importante de paquetes, de más de 50 000 paquetes por segundo, disminuyeron en el segundo trimestre, lo que supuso un aumento del 4 % en los ataques pequeños.

Distribución por velocidad de bits

En el segundo trimestre, la mayoría de los ataques DDoS a la capa de red se mantuvieron por debajo de los 500 MB/s, una velocidad mínima en la escala de Cloudflare, aunque pueden interrumpir con mucha rapidez propiedades de Internet que carezcan de protección o tengan menos capacidad o, incluso bloquear una conexión Gigabit Ethernet estándar.

Curiosamente, los ataques grandes de entre 500 MB/s y 100 GB/s disminuyeron un 20-40 % en términos intertrimestrales, pero los ataques volumétricos por encima de 100 GB/s aumentaron un 8 %.

Ataques DDoS a la capa de red por duración

En el segundo trimestre, los ataques de más de 3 horas se incrementaron un 9 %.

Medimos la duración de un ataque registrando la diferencia entre el momento en que nuestros sistemas lo detectan como ataque por primera vez, y el último paquete que vemos con esa firma de ataque hacia ese objetivo específico.

En el segundo trimestre, el 51 % de los ataques DDoS a la capa de red duraron menos de 10 minutos. Otro 41 % duró entre 10-20 minutos. El 8 % restante incluye ataques que van desde los 20 minutos a más de 3 horas.

Una cosa importante a tener en cuenta es que aunque un ataque dure solo unos minutos, si logra su objetivo, las repercusiones podrían ser más graves que la duración inicial del ataque. Los equipos informáticos que responden a un ataque que ha logrado su objetivo pueden pasar horas e incluso días restableciendo sus servicios.

Aunque la mayoría de los ataques son efectivamente breves, se observa un aumento de más del 15 % en los ataques que oscilan entre 20-60 minutos, y un aumento del 12 % de los ataques con una duración de más de 3 horas.

Los ataques breves pueden pasar fácilmente desapercibidos, sobre todo, los ataques en ráfaga que, en cuestión de segundos, atacan un objetivo con un número significativo de paquetes, bytes o solicitudes. En este caso, los servicios de protección DDoS que dependen de la mitigación manual mediante análisis de seguridad no tienen ninguna posibilidad de mitigar el ataque a tiempo. Solo pueden analizarlo después del ataque, implementar una nueva regla que filtre la huella digital del ataque y esperar a identificarlo la próxima vez. Del mismo modo, el uso de un servicio “a petición”, en el que el equipo responsable de la seguridad redirige el tráfico a un proveedor de DDoS durante el ataque, también es ineficiente porque el ataque ya habrá terminado antes de que el tráfico se dirija al proveedor de soluciones DDoS a la carta.

Se recomienda que las empresas utilicen servicios de protección DDoS automatizados y siempre activos que analicen el tráfico y apliquen una huella digital en tiempo real lo suficientemente rápido como para bloquear ataques de corta duración.

Resumen

La misión de Cloudflare es ayudar a mejorar Internet. Una red más eficiente es aquella que es más segura, rápida y fiable para todos, incluso frente a los ataques DDoS. Como parte de nuestra misión, desde 2017, hemos estado ofreciendo protección DDoS ilimitada y de uso no medido de forma gratuita a todos nuestros clientes. A lo largo de los años, a los atacantes les resulta cada vez más fácil lanzar ataques DDoS. Sin embargo, por muy fácil que se haya vuelto, queremos asegurarnos de que sea aún más sencillo y gratuito para todo tipo de organizaciones protegerse de ataques DDoS de cualquier naturaleza.
¿Todavía no utilizas Cloudflare? Empieza hoy mismo con nuestros planes gratuito y Pro para proteger tus sitios web, o ponte en contacto con nosotros para beneficiarte de una protección DDoS integral para toda tu red utilizando Magic Transit.

Cloudflare mitigates 26 million request per second DDoS attack

2022-06-14 Omer Yoachimik

Post Syndicated from Omer Yoachimik original https://blog.cloudflare.com/26m-rps-ddos/

Cloudflare mitigates 26 million request per second DDoS attack

Last week, Cloudflare automatically detected and mitigated a 26 million request per second DDoS attack — the largest HTTPS DDoS attack on record.

The attack targeted a customer website using Cloudflare’s Free plan. Similar to the previous 15M rps attack, this attack also originated mostly from Cloud Service Providers as opposed to Residential Internet Service Providers, indicating the use of hijacked virtual machines and powerful servers to generate the attack — as opposed to much weaker Internet of Things (IoT) devices.

Cloudflare mitigates 26 million request per second DDoS attack

Record-breaking attacks

Over the past year, we’ve witnessed one record-breaking attack after the other. Back in August 2021, we disclosed a 17.2M rps HTTP DDoS attack, and more recently in April, a 15M rps HTTPS DDoS attack. All were automatically detected and mitigated by our HTTP DDoS Managed Ruleset which is powered by our autonomous edge DDoS protection system.

The 26M rps DDoS attack originated from a small but powerful botnet of 5,067 devices. On average, each node generated approximately 5,200 rps at peak. To contrast the size of this botnet, we’ve been tracking another much larger but less powerful botnet of over 730,000 devices. The latter, larger botnet wasn’t able to generate more than one million requests per second, i.e. roughly 1.3 requests per second on average per device. Putting it plainly, this botnet was, on average, 4,000 times stronger due to its use of virtual machines and servers.

Also, worth noting that this attack was over HTTPS. HTTPS DDoS attacks are more expensive in terms of required computational resources because of the higher cost of establishing a secure TLS encrypted connection. Therefore, it costs the attacker more to launch the attack, and for the victim to mitigate it. We’ve seen very large attacks in the past over (unencrypted) HTTP, but this attack stands out because of the resources it required at its scale.

Within less than 30 seconds, this botnet generated more than 212 million HTTPS requests from over 1,500 networks in 121 countries. The top countries were Indonesia, the United States, Brazil and Russia. About 3% of the attack came through Tor nodes.

The top source networks were the French-based OVH (Autonomous System Number 16276), the Indonesian Telkomnet (ASN 7713), the US-based iboss (ASN 137922) and the Libyan Ajeel (ASN 37284).

The DDoS threat landscape

It’s important to understand the attack landscape when thinking about DDoS protection. When looking at our recent DDoS Trends report, we can see that most of the attacks are small, e.g. cyber vandalism. However, even small attacks can severely impact unprotected Internet properties. On the other hand, large attacks are growing in size and frequency — but remain short and rapid. Attackers concentrate their botnet’s power to try and wreak havoc with a single quick knockout blow — trying to avoid detection.

DDoS attacks might be initiated by humans, but they are generated by machines. By the time humans can respond to the attack, it may be over. And even if the attack was quick, the network and application failure events can extend long after the attack is over — costing you revenue and reputation. For this reason, it is recommended to protect your Internet properties with an automated always-on protection service that does not rely on humans to detect and mitigate attacks.

Helping build a better Internet

At Cloudflare, everything we do is guided by our mission to help build a better Internet. The DDoS team’s vision is derived from this mission: our goal is to make the impact of DDoS attacks a thing of the past. The level of protection that we offer is unmetered and unlimited — It is not bounded by the size of the attack, the number of the attacks, or the duration of the attacks. This is especially important these days because as we’ve recently seen, attacks are getting larger and more frequent.

Not using Cloudflare yet? Start now with our Free and Pro plans to protect your websites, or contact us for comprehensive DDoS protection for your entire network using Magic Transit.

Integrating Network Analytics Logs with your SIEM dashboard

2022-05-17 Omer Yoachimik

Post Syndicated from Omer Yoachimik original https://blog.cloudflare.com/network-analytics-logs/

Integrating Network Analytics Logs with your SIEM dashboard

We’re excited to announce the availability of Network Analytics Logs. Magic Transit, Magic Firewall, Magic WAN, and Spectrum customers on the Enterprise plan can feed packet samples directly into storage services, network monitoring tools such as Kentik, or their Security Information Event Management (SIEM) systems such as Splunk to gain near real-time visibility into network traffic and DDoS attacks.

What’s included in the logs

By creating a Network Analytics Logs job, Cloudflare will continuously push logs of packet samples directly to the HTTP endpoint of your choice, including Websockets. The logs arrive in JSON format which makes them easy to parse, transform, and aggregate. The logs include packet samples of traffic dropped and passed by the following systems:

Network-layer DDoS Protection Ruleset
Advanced TCP Protection
Magic Firewall

Note that not all mitigation systems are applicable to all Cloudflare services. Below is a table describing which mitigation service is applicable to which Cloudflare service:

Mitigation System	Cloudflare Service
Mitigation System	Magic Transit	Magic WAN	Spectrum
Network-layer DDoS Protection Ruleset	✅	❌	✅
Advanced TCP Protection	✅	❌	❌
Magic Firewall	✅	✅	❌

Packets are processed by the mitigation systems in the order outlined above. Therefore, a packet that passed all three systems may produce three packet samples, one from each system. This can be very insightful when troubleshooting and wanting to understand where in the stack a packet was dropped. To avoid overcounting the total passed traffic, Magic Transit users should only take into consideration the passed packets from the last mitigation system, Magic Firewall.

An example of a packet sample log:

{"AttackCampaignID":"","AttackID":"","ColoName":"bkk06","Datetime":1652295571783000000,"DestinationASN":13335,"Direction":"ingress","IPDestinationAddress":"(redacted)","IPDestinationSubnet":"/24","IPProtocol":17,"IPSourceAddress":"(redacted)","IPSourceSubnet":"/24","MitigationReason":"","MitigationScope":"","MitigationSystem":"magic-firewall","Outcome":"pass","ProtocolState":"","RuleID":"(redacted)","RulesetID":"(redacted)","RulesetOverrideID":"","SampleInterval":100,"SourceASN":38794,"Verdict":"drop"}

All the available log fields are documented here: https://developers.cloudflare.com/logs/reference/log-fields/account/network_analytics_logs/

Setting up the logs

In this walkthrough, we will demonstrate how to feed the Network Analytics Logs into Splunk via Postman. At this time, it is only possible to set up Network Analytics Logs via API. Setting up the logs requires three main steps:

Create a Cloudflare API token.
Create a Splunk Cloud HTTP Event Collector (HEC) token.
Create and enable a Cloudflare Logpush job.

Let’s get started!

1) Create a Cloudflare API token

Log in to your Cloudflare account and navigate to My Profile.
On the left-hand side, in the collapsing navigation menu, click API Tokens.
Click Create Token and then, under Custom token, click Get started.
Give your custom token a name, and select an Account scoped permission to edit Logs. You can also scope it to a specific/subset/all of your accounts.
At the bottom, click Continue to summary, and then Create Token.
Copy and save your token. You can also test your token with the provided snippet in Terminal.

When you’re using an API token, you don’t need to provide your email address as part of the API credentials.

Read more about creating an API token on the Cloudflare Developers website: https://developers.cloudflare.com/api/tokens/create/

2) Create a Splunk token for an HTTP Event Collector

In this walkthrough, we’re using a Splunk Cloud free trial, but you can use almost any service that can accept logs over HTTPS. In some cases, if you’re using an on-premise SIEM solution, you may need to allowlist Cloudflare IP address in your firewall to be able to receive the logs.

Create a Splunk Cloud account. I created a trial account for the purpose of this blog.
In the Splunk Cloud dashboard, go to Settings > Data Input.
Next to HTTP Event Collector, click Add new.
Follow the steps to create a token.
Copy your token and your allocated Splunk hostname and save both for later.

Read more about using Splunk with Cloudflare Logpush on the Cloudflare Developers website: https://developers.cloudflare.com/logs/get-started/enable-destinations/splunk/

Read more about creating an HTTP Event Collector token on Splunk’s website: https://docs.splunk.com/Documentation/Splunk/8.2.6/Data/UsetheHTTPEventCollector

3) Create a Cloudflare Logpush job

Creating and enabling a job is very straightforward. It requires only one API call to Cloudflare to create and enable a job.

To send the API calls I used Postman, which is a user-friendly API client that was recommended to me by a colleague. It allows you to save and customize API calls. You can also use Terminal/CMD or any other API client/script of your choice.

One thing to notice is Network Analytics Logs are account-scoped. The API endpoint is therefore a tad different from what you would normally use for zone-scoped datasets such as HTTP request logs and DNS logs.

This is the endpoint for creating an account-scoped Logpush job:

https://api.cloudflare.com/client/v4/accounts/{account-id}/logpush/jobs

Your account identifier number is a unique identifier of your account. It is a string of 32 numbers and characters. If you’re not sure what your account identifier is, log in to Cloudflare, select the appropriate account, and copy the string at the end of the URL.

https://dash.cloudflare.com/{account-id}

Then, set up a new request in Postman (or any other API client/CLI tool).

To successfully create a Logpush job, you’ll need the HTTP method, URL, Authorization token, and request body (data). The request body must include a destination configuration (destination_conf), the specified dataset (network_analytics_logs, in our case), and the token (your Splunk token).

Method:

POST

URL:

https://api.cloudflare.com/client/v4/accounts/{account-id}/logpush/jobs

Authorization: Define a Bearer authorization in the Authorization tab, or add it to the header, and add your Cloudflare API token.

Body: Select a Raw > JSON

{
"destination_conf": "{your-unique-splunk-configuration}",
"dataset": "network_analytics_logs",
"token": "{your-splunk-hec-tag}",
"enabled": "true"
}

If you’re using Splunk Cloud, then your unique configuration has the following format:

{your-unique-splunk-configuration}=splunk://{your-splunk-hostname}.splunkcloud.com:8088/services/collector/raw?channel={channel-id}&header_Authorization=Splunk%20{your-splunk–hec-token}&insecure-skip-verify=false

Definition of the variables:

{your-splunk-hostname}= Your allocated Splunk Cloud hostname.

{channel-id} = A unique ID that you choose to assign for.`{your-splunk–hec-token}` = The token that you generated for your Splunk HEC.

An important note is that customers should have a valid SSL/TLS certificate on their Splunk instance to support an encrypted connection.

After you’ve done that, you can create a GET request to the same URL (no request body needed) to verify that the job was created and is enabled.

The response should be similar to the following:

{
    "errors": [],
    "messages": [],
    "result": {
        "id": {job-id},
        "dataset": "network_analytics_logs",
        "frequency": "high",
        "kind": "",
        "enabled": true,
        "name": null,
        "logpull_options": null,
        "destination_conf": "{your-unique-splunk-configuration}",
        "last_complete": null,
        "last_error": null,
        "error_message": null
    },
    "success": true
}

Shortly after, you should start receiving logs to your Splunk HEC.

Read more about enabling Logpush on the Cloudflare Developers website: https://developers.cloudflare.com/logs/reference/logpush-api-configuration/examples/example-logpush-curl/

Reduce costs with R2 storage

Depending on the amount of logs that you read and write, the cost of third party cloud storage can skyrocket — forcing you to decide between managing a tight budget and being able to properly investigate networking and security issues. However, we believe that you shouldn’t have to make those trade-offs. With R2’s low costs, we’re making this decision easier for our customers. Instead of feeding logs to a third party, you can reap the cost benefits of storing them in R2.

To learn more about the R2 features and pricing, check out the full blog post. To enable R2, contact your account team.

Cloudflare logs for maximum visibility

Cloudflare Enterprise customers have access to detailed logs of the metadata generated by our products. These logs are helpful for troubleshooting, identifying network and configuration adjustments, and generating reports, especially when combined with logs from other sources, such as your servers, firewalls, routers, and other appliances.

Network Analytics Logs joins Cloudflare’s family of products on Logpush: DNS logs, Firewall events, HTTP requests, NEL reports, Spectrum events, Audit logs, Gateway DNS, Gateway HTTP, and Gateway Network.

Not using Cloudflare yet? Start now with our Free and Pro plans to protect your websites against DDoS attacks, or contact us for comprehensive DDoS protection and firewall-as-a-service for your entire network.

Cloudflare blocks 15M rps HTTPS DDoS attack

2022-04-27 Omer Yoachimik

Post Syndicated from Omer Yoachimik original https://blog.cloudflare.com/15m-rps-ddos-attack/

Cloudflare blocks 15M rps HTTPS DDoS attack

Earlier this month, Cloudflare’s systems automatically detected and mitigated a 15.3 million request-per-second (rps) DDoS attack — one of the largest HTTPS DDoS attacks on record.

While this isn’t the largest application-layer attack we’ve seen, it is the largest we’ve seen over HTTPS. HTTPS DDoS attacks are more expensive in terms of required computational resources because of the higher cost of establishing a secure TLS encrypted connection. Therefore it costs the attacker more to launch the attack, and for the victim to mitigate it. We’ve seen very large attacks in the past over (unencrypted) HTTP, but this attack stands out because of the resources it required at its scale.

The attack, lasting less than 15 seconds, targeted a Cloudflare customer on the Professional (Pro) plan operating a crypto launchpad. Crypto launchpads are used to surface Decentralized Finance projects to potential investors. The attack was launched by a botnet that we’ve been observing — we’ve already seen large attacks as high as 10M rps matching the same attack fingerprint.

Cloudflare customers are protected against this botnet and do not need to take any action.

The attack

What’s interesting is that the attack mostly came from data centers. We’re seeing a big move from residential network Internet Service Providers (ISPs) to cloud compute ISPs.

This attack was launched from a botnet of approximately 6,000 unique bots. It originated from 112 countries around the world. Almost 15% of the attack traffic originated from Indonesia, followed by Russia, Brazil, India, Colombia, and the United States.

Within those countries, the attack originated from over 1,300 different networks. The top networks included the German provider Hetzner Online GmbH (Autonomous System Number 24940), Azteca Comunicaciones Colombia (ASN 262186), OVH in France (ASN 16276), as well as other cloud providers.

How this attack was automatically detected and mitigated

To defend organizations against DDoS attacks, we built and operate software-defined systems that run autonomously. They automatically detect and mitigate DDoS attacks across our entire network — and just as in this case, the attack was automatically detected and mitigated without any human intervention.

Our system starts by sampling traffic asynchronously; it then analyzes the samples and applies mitigations when needed.

Sampling

Initially, traffic is routed through the Internet via BGP Anycast to the nearest Cloudflare data centers that are located in over 250 cities around the world. Once the traffic reaches our data center, our DDoS systems sample it asynchronously allowing for out-of-path analysis of traffic without introducing latency penalties.

Analysis and mitigation

The analysis is done using data streaming algorithms. HTTP request samples are compared to conditional fingerprints, and multiple real-time signatures are created based on dynamic masking of various request fields and metadata. Each time another request matches one of the signatures, a counter is increased. When the activation threshold is reached for a given signature, a mitigation rule is compiled and pushed inline. The mitigation rule includes the real-time signature and the mitigation action, e.g. block.

Cloudflare customers can also customize the settings of the DDoS protection systems by tweaking the HTTP DDoS Managed Rules.

You can read more about our autonomous DDoS protection systems and how they work in our deep-dive technical blog post.

Helping build a better Internet

At Cloudflare, everything we do is guided by our mission to help build a better Internet. The DDoS team’s vision is derived from this mission: our goal is to make the impact of DDoS attacks a thing of the past. The level of protection that we offer is unmetered and unlimited — It is not bounded by the size of the attack, the number of the attacks, or the duration of the attacks. This is especially important these days because as we’ve recently seen, attacks are getting larger and more frequent.

Not using Cloudflare yet? Start now with our Free and Pro plans to protect your websites, or contact us for comprehensive DDoS protection for your entire network using Magic Transit.

DDoS Attack Trends for 2022 Q1

2022-04-12 Omer Yoachimik

Post Syndicated from Omer Yoachimik original https://blog.cloudflare.com/ddos-attack-trends-for-2022-q1/

DDoS Attack Trends for 2022 Q1

Welcome to our first DDoS report of 2022, and the ninth in total so far. This report includes new data points and insights both in the application-layer and network-layer sections — as observed across the global Cloudflare network between January and March 2022.

The first quarter of 2022 saw a massive spike in application-layer DDoS attacks, but a decrease in the total number of network-layer DDoS attacks. Despite the decrease, we’ve seen volumetric DDoS attacks surge by up to 645% QoQ, and we mitigated a new zero-day reflection attack with an amplification factor of 220 billion percent.

In the Russian and Ukrainian cyberspace, the most targeted industries were Online Media and Broadcast Media. In our Azerbaijan and Palestinian Cloudflare data centers, we’ve seen enormous spikes in DDoS activity — indicating the presence of botnets operating from within.

The Highlights

The Russian and Ukrainian cyberspace

Russian Online Media companies were the most targeted industries within Russia in Q1. The next most targeted was the Internet industry, then Cryptocurrency, and then Retail. While many attacks that targeted Russian Cryptocurrency companies originated in Ukraine or the US, another major source of attacks was from within Russia itself.
The majority of HTTP DDoS attacks that targeted Russian companies originated from Germany, the US, Singapore, Finland, India, the Netherlands, and Ukraine. It’s important to note that being able to identify where cyber attack traffic originates is not the same as being able to attribute where the attacker is located.
Attacks on Ukraine targeted Broadcast Media and Publishing websites and seem to have been more distributed, originating from more countries — which may indicate the use of global botnets. Still, most of the attack traffic originated from the US, Russia, Germany, China, the UK, and Thailand.

Ransom DDoS attacks

In January 2022, over 17% of under-attack respondents reported being targeted by ransom DDoS attacks or receiving a threat in advance.
That figure drastically dropped to 6% in February, and then to 3% in March.
When compared to previous quarters, we can see that in total, in Q1, only 10% of respondents reported a ransom DDoS attack; a 28% decrease YoY and 52% decrease QoQ.

Application-layer DDoS attacks

2022 Q1 was the busiest quarter in the past 12 months for application-layer attacks. HTTP-layer DDoS attacks increased by 164% YoY and 135% QoQ.
Diving deeper into the quarter, in March 2022 there were more HTTP DDoS attacks than in all of Q4 combined (and Q3, and Q1).
After four consecutive quarters in a row with China as the top source of HTTP DDoS attacks, the US stepped into the lead this quarter. HTTP DDoS attacks originating from the US increased by a staggering 6,777% QoQ and 2,225% YoY.

Network-layer DDoS attacks

Network-layer attacks in Q1 increased by 71% YoY but decreased 58% QoQ.
The Telecommunications industry was the most targeted by network-layer DDoS attacks, followed by Gaming and Gambling companies, and the Information Technology and Services industry.
Volumetric attacks increased in Q1. Attacks above 10 Mpps (million packets per second) grew by over 300% QoQ, and attacks over 100 Gbps grew by 645% QoQ.

This report is based on DDoS attacks that were automatically detected and mitigated by Cloudflare’s DDoS Protection systems. To learn more about how it works, check out this deep-dive blog post.

A note on how we measure DDoS attacks observed over our network
To analyze attack trends, we calculate the “DDoS activity” rate, which is either the percentage of attack traffic out of the total traffic (attack + clean) observed over our global network, or in a specific location, or in a specific category (e.g., industry or billing country). Measuring the percentages allows us to normalize data points and avoid biases reflected in absolute numbers towards, for example, a Cloudflare data center that receives more total traffic and likely, also more attacks.

To view an interactive version of this report view it on Cloudflare Radar.

Ransom Attacks

Our systems constantly analyze traffic and automatically apply mitigation when DDoS attacks are detected. Each DDoS’d customer is prompted with an automated survey to help us better understand the nature of the attack and the success of the mitigation.

For over two years now, Cloudflare has been surveying attacked customers — one question on the survey being if they received a threat or a ransom note demanding payment in exchange to stop the DDoS attack. In the last quarter, 2021 Q4, we observed a record-breaking level of reported ransom DDoS attacks (one out of every five customers). This quarter, we’ve witnessed a drop in ransom DDoS attacks with only one out of 10 respondents reporting a ransom DDoS attack; a 28% decrease YoY and 52% decrease QoQ.

When we break it down by month, we can see that January 2022 saw the largest number of respondents reporting receiving a ransom letter in Q1. Almost one out of every five customers (17%).

Application-layer DDoS attacks

Application-layer DDoS attacks, specifically HTTP DDoS attacks, are attacks that usually aim to disrupt a web server by making it unable to process legitimate user requests. If a server is bombarded with more requests than it can process, the server will drop legitimate requests and — in some cases — crash, resulting in degraded performance or an outage for legitimate users.

Application-layer DDoS attacks by month

In Q1, application-layer DDoS attacks soared by 164% YoY and 135% QoQ – the busiest quarter within the past year.

Application-layer DDoS attacks increased to new heights in the first quarter of 2022. In March alone, there were more HTTP DDoS attacks than in all of 2021 Q4 combined (and Q3, and Q1).

Application-layer DDoS attacks by industry

Consumer Electronics was the most targeted industry in Q1.

Globally, the Consumer Electronics industry was the most attacked with an increase of 5,086% QoQ. Second was the Online Media industry with a 2,131% increase in attacks QoQ. Third were Computer Software companies, with an increase of 76% QoQ and 1,472 YoY.

However, if we focus only on Ukraine and Russia, we can see that Broadcast Media, Online Media companies, and Internet companies were the most targeted. Read more about what Cloudflare is doing to keep the Open Internet flowing into Russia and keep attacks from getting out.

Application-layer DDoS attacks by source country

To understand the origin of the HTTP attacks, we look at the geolocation of the source IP address belonging to the client that generated the attack HTTP requests. Unlike network-layer attacks, source IP addresses cannot be spoofed in HTTP attacks. A high percentage of DDoS activity in a given country usually indicates the presence of botnets operating from within the country’s borders.

After four consecutive quarters in a row with China as the top source of HTTP DDoS attacks, the US stepped into the lead this quarter. HTTP DDoS attacks originating from the US increased by a staggering 6,777% QoQ and 2,225% YoY. Following China in second place are India, Germany, Brazil, and Ukraine.

Application-layer DDoS attacks by target country

In order to identify which countries are targeted by the most HTTP DDoS attacks, we bucket the DDoS attacks by our customers’ billing countries and represent it as a percentage out of all DDoS attacks.

The US drops to second place, after being first for three consecutive quarters. Organizations in China were targeted the most by HTTP DDoS attacks, followed by the US, Russia, and Cyprus.

Network-layer DDoS attacks

While application-layer attacks target the application (Layer 7 of the OSI model) running the service that end users are trying to access (HTTP/S in our case), network-layer attacks aim to overwhelm network infrastructure (such as in-line routers and servers) and the Internet link itself.

Network-layer DDoS attacks by month

While HTTP DDoS attacks soared in Q1, network-layer DDoS attacks actually decreased by 58% QoQ, but still increased by 71% YoY.

Diving deeper into Q1, we can see that the amount of network-layer DDoS attacks remained mostly consistent throughout the quarter with about a third of attacks occurring every month.

Cloudflare mitigates zero-day amplification DDoS attack

Amongst these network-layer DDoS attacks are also zero-day DDoS attacks that Cloudflare automatically detected and mitigated.

In the beginning of March, Cloudflare researchers helped investigate and expose a zero-day vulnerability in Mitel business phone systems that amongst other possible exploitations, also enables attackers to launch an amplification DDoS attack. This type of attack reflects traffic off vulnerable Mitel servers to victims, amplifying the amount of traffic sent in the process by an amplification factor of 220 billion percent in this specific case. You can read more about it in our recent blog post.

We observed several of these attacks across our network. One of them targeted a North American cloud provider using the Cloudflare Magic Transit service. The attack originated from 100 source IPs mainly from the US, UK, Canada, Netherlands, Australia, and approximately 20 other countries. It peaked above 50 Mpps (~22 Gbps) and was automatically detected and mitigated by Cloudflare systems.

Network-layer DDoS attacks by industry

Many network-layer DDoS attacks target Cloudflare’s IP ranges directly. These IP ranges serve our WAF/CDN customers, Cloudflare authoritative DNS, Cloudflare public DNS resolver 1.1.1.1, Cloudflare Zero Trust products, and our corporate offices, to name a few. Additionally, we also allocate dedicated IP addresses to customers via our Spectrum product and advertise the IP prefixes of other companies via our Magic Transit, Magic WAN, and Magic Firewall Products for L3/4 DDoS protection.

In this report, for the first time, we’ve begun classifying network-layer DDoS attacks according to the industries of our customers using the Spectrum and Magic products. This classification allows us to understand which industries are targeted the most by network-layer DDoS attacks.

When we look at Q1 statistics, we can see that in terms of attack packets and attack bytes launched towards Cloudflare customers, the Telecommunications industry was targeted the most. More than 8% of all attack bytes and 10% of all attack packets that Cloudflare mitigated targeted Telecommunications companies.

Following not too far behind, in second and third place were the Gaming / Gambling and Information Technology and Services industries.

Network-layer DDoS attacks by target country

Similarly to the classification by our customers’ industry, we can also bucket attacks by our customers’ billing country as we do for application-layer DDoS attacks, to identify the top attacked countries.

Looking at Q1 numbers, we can see that the US was targeted by the highest percentage of DDoS attacks traffic — over 10% of all attack packets and almost 8% of all attack bytes. Following the US is China, Canada, and Singapore.

Network-layer DDoS attacks by ingress country

When trying to understand where network-layer DDoS attacks originate, we cannot use the same method as we use for the application-layer attack analysis. To launch an application-layer DDoS attack, successful handshakes must occur between the client and the server in order to establish an HTTP/S connection. For a successful handshake to occur, the attacker cannot spoof their source IP address. While the attacker may use botnets, proxies, and other methods to obfuscate their identity, the attacking client’s source IP location does sufficiently represent the attack source of application-layer DDoS attacks.

On the other hand, to launch network-layer DDoS attacks, in most cases, no handshake is needed. Attackers can spoof the source IP address in order to obfuscate the attack source and introduce randomness into the attack properties, which can make it harder for simple DDoS protection systems to block the attack. So if we were to derive the source country based on a spoofed source IP, we would get a ‘spoofed country’.

For this reason, when analyzing network-layer DDoS attack sources, we bucket the traffic by the Cloudflare edge data center locations where the traffic was ingested, and not by the (potentially) spoofed source IP to get an understanding of where the attacks originate from. We are able to achieve geographical accuracy in our report because we have data centers in over 270 cities around the world. However, even this method is not 100% accurate, as traffic may be back hauled and routed via various Internet Service Providers and countries for reasons that vary from cost reduction to congestion and failure management.

In Q1, the percentage of attacks detected in Cloudflare’s data centers in Azerbaijan increased by 16,624% QoQ and 96,900% YoY, making it the country with the highest percentage of network-layer DDoS activity (48.5%).

Following our Azerbaijanian data center is our Palestinian data center where a staggering 41.9% of all traffic was DDoS traffic. This represents a 10,120% increase QoQ and 46,456% YoY.

To view all regions and countries, check out the interactive map.

Attack vectors

SYN Floods remain the most popular DDoS attack vector, while use of generic UDP floods drops significantly in Q1.

An attack vector is a term used to describe the method that the attacker uses to launch their DDoS attack, i.e., the IP protocol, packet attributes such as TCP flags, flooding method, and other criteria.

In Q1, SYN floods accounted for 57% of all network-layer DDoS attacks, representing a 69% increase QoQ and a 13% increase YoY. In second place, attacks over SSDP surged by over 1,100% QoQ. Following were RST floods and attacks over UDP. Last quarter, generic UDP floods took the second place, but this time, generic UDP DDoS attacks plummeted by 87% QoQ from 32% to a mere 3.9%.

Emerging threats

Identifying the top attack vectors helps organizations understand the threat landscape. In turn, this may help them improve their security posture to protect against those threats. Similarly, learning about new emerging threats that may not yet account for a significant portion of attacks, can help mitigate them before they become a significant force.

When we look at new emerging attack vectors in Q1, we can see increases in DDoS attacks reflecting off of Lantronix services (+971% QoQ) and SSDP reflection attacks (+724% QoQ). Additionally, SYN-ACK attacks increased by 437% and attacks by Mirai botnets by 321% QoQ.

Attacker reflecting traffic off of Lantronix Discovery Service

Lantronix is a US-based software and hardware company that provides solutions for Internet of Things (IoT) management amongst their vast offering. One of the tools that they provide to manage their IoT components is the Lantronix Discovery Protocol. It is a command-line tool that helps to search and find Lantronix devices. The discovery tool is UDP-based, meaning that no handshake is required. The source IP can be spoofed. So an attacker can use the tool to search for publicly exposed Lantronix devices using a 4 byte request, which will then in turn respond with a 30 byte response from port 30718. By spoofing the source IP of the victim, all Lantronix devices will target their responses to the victim — resulting in a reflection/amplification attack.

Simple Service Discovery Protocol used for reflection DDoS attacks

The Simple Service Discovery Protocol (SSDP) protocol works similarly to the Lantronix Discovery protocol, but for Universal Plug and Play (UPnP) devices such as network-connected printers. By abusing the SSDP protocol, attackers can generate a reflection-based DDoS attack overwhelming the target’s infrastructure and taking their Internet properties offline. You can read more about SSDP-based DDoS attacks here.

Network-layer DDoS attacks by attack rate

In Q1, we observed a massive uptick in volumetric DDoS attacks — both from the packet rate and bitrate perspective. Attacks over 10 Mpps grew by over 300% QoQ, and attacks over 100 Gbps grew by 645% QoQ.

There are different ways of measuring the size of an L3/4 DDoS attack. One is the volume of traffic it delivers, measured as the bit rate (specifically, terabits per second or gigabits per second). Another is the number of packets it delivers, measured as the packet rate (specifically, millions of packets per second).

Attacks with high bit rates attempt to cause a denial-of-service event by clogging the Internet link, while attacks with high packet rates attempt to overwhelm the servers, routers, or other in-line hardware appliances. These devices dedicate a certain amount of memory and computation power to process each packet. Therefore, by bombarding it with many packets, the appliance can be left with no further processing resources. In such a case, packets are “dropped,” i.e., the appliance is unable to process them. For users, this results in service disruptions and denial of service.

Distribution by packet rate

The majority of network-layer DDoS attacks remain below 50,000 packets per second. While 50 kpps is on the lower side of the spectrum at Cloudflare scale, it can still easily take down unprotected Internet properties and congest even a standard Gigabit Ethernet connection.

When we look at the changes in the attack sizes, we can see that attacks of over 10 Mpps grew by over 300% QoQ. Similarly, attacks of 1-10 Mpps grew by almost 40% QoQ.

Distribution by bitrate

In Q1, most of the network-layer DDoS attacks remain below 500 Mbps. This too is a tiny drop in the water at Cloudflare scale, but can very quickly shut down unprotected Internet properties with less capacity or at the very least congest, even a standard Gigabit Ethernet connection.

Similarly to the trends observed in the packet-per-second realm, here we can also see large increases. The amount of DDoS attacks that peaked over 100 Gbps increased by 645% QoQ; attacks peaking between 10 Gbps to 100 Gbps increased by 407%; attacks peaking between 1 Gbps to 10 Gbps increased by 88%; and even attacks peaking between 500 Mbps to 1 Gbps increased by almost 20% QoQ.

Network-layer DDoS attacks by duration

Most attacks remain under one hour in duration, reiterating the need for automated always-on DDoS mitigation solutions.

In previous reports, we provided a breakdown of ‘attacks under an hour’, and larger time ranges. However, in most cases over 90 percent of attacks last less than an hour. So starting from this report, we broke down the short attacks and grouped them by shorter time ranges to provide better granularity.

One important thing to keep in mind is that even if an attack lasts only a few minutes, if it is successful, the repercussions could last well beyond the initial attack duration. IT personnel responding to a successful attack may spend hours and even days restoring their services.

In the first quarter of 2022, more than half of the attacks lasted 10-20 minutes, approximately 40% ended within 10 minutes, another ~5% lasted 20-40 minutes, and the remaining lasted longer than 40 minutes.

Short attacks can easily go undetected, especially burst attacks that, within seconds, bombard a target with a significant number of packets, bytes, or requests. In this case, DDoS protection services that rely on manual mitigation by security analysis have no chance in mitigating the attack in time. They can only learn from it in their post-attack analysis, then deploy a new rule that filters the attack fingerprint and hope to catch it next time. Similarly, using an “on-demand” service, where the security team will redirect traffic to a DDoS provider during the attack, is also inefficient because the attack will already be over before the traffic routes to the on-demand DDoS provider.

It’s recommended that companies use automated, always-on DDoS protection services that analyze traffic and apply real-time fingerprinting fast enough to block short-lived attacks.

Summary

Cloudflare’s mission is to help build a better Internet. A better Internet is one that is more secure, faster, and reliable for everyone — even in the face of DDoS attacks. As part of our mission, since 2017, we’ve been providing unmetered and unlimited DDoS protection for free to all of our customers. Over the years, it has become increasingly easier for attackers to launch DDoS attacks. But as easy as it has become, we want to make sure that it is even easier — and free — for organizations of all sizes to protect themselves against DDoS attacks of all types.

Not using Cloudflare yet? Start now with our Free and Pro plans to protect your websites, or contact us for comprehensive DDoS protection for your entire network using Magic Transit.

CVE-2022-26143: A Zero-Day vulnerability for launching UDP amplification DDoS attacks

2022-03-08 Omer Yoachimik

Post Syndicated from Omer Yoachimik original https://blog.cloudflare.com/cve-2022-26143-amplification-attack/

CVE-2022-26143: A Zero-Day vulnerability for launching UDP amplification DDoS attacks

A zero-day vulnerability in the Mitel MiCollab business phone system has recently been discovered (CVE-2022-26143). This vulnerability, called TP240PhoneHome, which Cloudflare customers are already protected against, can be used to launch UDP amplification attacks. This type of attack reflects traffic off vulnerable servers to victims, amplifying the amount of traffic sent in the process by an amplification factor of 220 billion percent in this specific case.

Cloudflare has been actively involved in investigating the TP240PhoneHome exploit, along with other members of the InfoSec community. Read our joint disclosure here for more details. As far as we can tell, the vulnerability has been exploited as early as February 18, 2022. We have deployed emergency mitigation rules to protect Cloudflare customers against the amplification DDoS attacks.

Mitel has been informed of the vulnerability. As of February 22, they have issued a high severity security advisory advising their customers to block exploitation attempts using a firewall, until a software patch is made available. Cloudflare Magic Transit customers can use the Magic Firewall to block external traffic to the exposed Mitel UDP port 10074 by following the example in the screenshot below, or by pasting the following expression into their Magic Firewall rule editor and selecting the Block action:

(udp.dstport eq 10074).

To learn more, register for our webinar on March 23rd, 2022.

Exploiting the vulnerability to launch DDoS attacks

Mitel Networks is based in Canada and provides business communications and collaboration products to over 70 million business users around the world. Amongst their enterprise collaboration products is the aforementioned Mitel MiCollab platform, known to be used in critical infrastructure such as municipal governments, schools, and emergency services. The vulnerability was discovered in the Mitel MiCollab platform.

The vulnerability manifests as an unauthenticated UDP port that is incorrectly exposed to the public Internet. The call control protocol running on this port can be used to, amongst other things, issue the debugging command startblast. This command does not place real telephone calls; rather, it simulates a “blast” of calls in order to test the system. For each test call that is made, two UDP packets are emitted in response to the issuer of the command.

According to the security advisory, the exploit can “allow a malicious actor to gain unauthorized access to sensitive information and services, cause performance degradations or a denial of service condition on the affected system. If exploited with a denial of service attack, the impacted system may cause significant outbound traffic impacting availability of other services.”

Since this is an unauthenticated and connectionless UDP-based protocol, you can use spoofing to direct the response traffic toward any IP and port number — and by doing so, reflect and amplify a DDoS attack to the victim.

We’ve mainly focused on the amplification vector because it can be used to hurt the whole Internet, but the phone systems themselves can likely be hurt in other ways with this vulnerability. This UDP call control port offers many other commands. With some work, it’s likely that you could use this UDP port to commit toll fraud, or to simply render the phone system inoperable. We haven’t assessed these other possibilities, because we do not have access to a device that we can safely test with.

The good news

Fortunately, only a few thousand of these devices are improperly exposed to the public Internet, meaning that this vector can “only” achieve several hundred million packets per second total. This volume of traffic can cause major outages if you’re not protected by an always-on automated DDoS protection service, but it’s nothing to be concerned with if you are.

Furthermore, an attacker can’t run multiple commands at the same time. Instead, the server queues up commands and executes them serially. The fact that you can only launch one attack at a time from these devices, mixed with the fact that you can make that attack for many hours, has fascinating implications. If an attacker chooses to start an attack by specifying a very large number of packets, then that box is “burned” – it can’t be used to attack anyone else until the attack completes.

How Cloudflare detects and mitigates DDoS attacks

To defend organizations against DDoS attacks, we built and operate software-defined systems that run autonomously. They automatically detect and mitigate DDoS attacks across our entire network.

The analysis is done using data streaming algorithms. Packet samples are compared to the fingerprints and multiple real-time signatures are created based on the dynamic masking of various fingerprint attributes. Each time another packet matches one of the signatures, a counter is increased. When the system qualifies an attack, i.e., the activation threshold is reached for a given signature, a mitigation rule is compiled and pushed inline. The mitigation rule includes the real-time signature and the mitigation action, e.g., drop.

You can read more about our autonomous DDoS protection systems and how they work in our joint-disclosure technical blog post.

Helping build a better Internet

Cloudflare’s mission is to help build a better Internet. A better Internet is one that is more secure, faster, and reliable for everyone — even in the face of DDoS attacks and emerging zero-day threats. As part of our mission, since 2017, we’ve been providing unmetered and unlimited DDoS protection for free to all of our customers. Over the years, it has become increasingly easier for attackers to launch DDoS attacks. To counter the attacker’s advantage, we want to make sure that it is also easy and free for organizations of all sizes to protect themselves against DDoS attacks of all types.

Not using Cloudflare yet? Start now.

Protecting Holocaust educational websites

2022-01-27 Omer Yoachimik

Post Syndicated from Omer Yoachimik original https://blog.cloudflare.com/protecting-holocaust-educational-websites/

Protecting Holocaust educational websites

Today is the International Holocaust Remembrance Day. On this day, we commemorate the victims that were murdered by the Nazis and their accomplices.

During the Holocaust, and in the events that led to it, the Nazis exterminated one third of the European Jewish population. Six million Jews, along with countless other members of minority and disability groups, were murdered because the Nazis believed they were inferior.

Cloudflare’s Project Galileo provides free protection to at-risk groups across the world including Holocaust educational and remembrance websites. During the past year alone, Cloudflare mitigated over a quarter of a million cyber threats launched against Holocaust-related websites.

Antisemitism and the Final Solution

In the Second World War and the years leading up to it, antisemitism served as the foundation of racist laws and fueled violent Pogroms against Jews. The tipping point was a night of violence known as the Kristallnacht (“Night of Broken Glass”). Jews and other minority groups were outlawed, dehumanized, persecuted and killed. Jewish businesses were boycotted, Jewish books burned and synagogues destroyed. Jews, Roma and other “enemies of the Reich” were forced into closed ghettos and concentration camps. Finally, as part of the Final Solution for the Jewish Question, Germany outlined a policy to deliberately and systematically exterminate the Jewish race in what came to be known as the Holocaust.

As part of the Final Solution, the Nazis deployed mobile killing units. Jews were taken to forests near their villages, forced to dig mass graves, undress, and then shot — falling into the mass graves they dug. This was the first step. However, this was “inefficient”. More “efficient” solutions were engineered using deadly gas. Eventually, six main extermination camps were established. They were extremely “efficient” at exterminating humans. Initially, the Nazis experimented with gas vans for mass extermination. Later, they built and operated gas chambers which could kill more humans and do it faster. After being gassed, prisoners would load the bodies into ovens in crematoriums to be burned. In one of the larger death camps, Auschwitz-Birkenau, more than one million Jews were murdered — some 865,000 were gassed and burned on arrival.

Fighting racism with education

Seventy-seven years later, sadly, racism and antisemitism are once again on the rise and have gained traction across Europe during the pandemic and across UK university campuses. Earlier this week, United Nations Secretary-General António Guterres decried the resurgence of antisemitism and said that “…the rise in antisemitism — the oldest form of hate and prejudice — has seen new reports of physical attacks, verbal abuse, the desecration of Jewish cemeteries, synagogues vandalized, and last week the hostage-taking of the rabbi and members of Beth Israel Congregation in Colleyville, Texas.”

It is through education that we will defeat bigotry and racism, and we will do our part at Cloudflare — through education and by supporting Holocaust educational organizations.

“Our response to ignorance must be education”
– United Nations Secretary-General António Guterres

Supporting Holocaust educational organizations with Project Galileo

As part of Project Galileo, we currently provide free security and performance products to more than 1,500 organizations in 111 countries. These organizations are targeted by cyber attacks due to their critical work. These groups include human rights defenders, independent media and journalists, and organizations that work in strengthening democracy. Among them are organizations dedicated to educating about the horrors of the Holocaust, and preserving and telling the stories of the victims and survivors of the Holocaust to younger and future generations.

Over the past year, we’ve seen cyber attacks on Holocaust-related websites gradually increase throughout the year. These attacks include mostly application-layer attacks that were automatically detected and mitigated by Cloudflare’s Web Application Firewall and DDoS Protection systems.

In May 2021, cyber attacks on Holocaust-related websites peaked as they increased by 263% compared to their monthly average.

Applying to Project Galileo

Cloudflare’s mission is to help build a better Internet. Part of this mission includes protecting free expression online for vulnerable groups.

The Internet can be a powerful tool in this matter. However, organizations often face attacks from powerful and entrenched opponents, yet operate on limited budgets and lack the resources to secure themselves against malicious traffic intended to silence them. If they are silenced, the Internet stops fulfilling its promise.

To combat the threats, Cloudflare’s Project Galileo provides robust security and performance products for at-risk public interest websites at no cost. Application to Project Galileo is open to any vulnerable public interest website. You can apply via our partners or apply directly to Project Galileo if you don’t have any affiliation with our trusted partners.

A note from Cloudflare’s Jewish employees

Many of us, like myself, are descendants of Holocaust survivors. My grandparents fled from Nazi-occupied Poland to survive. Sadly, my grandparents — as other elderly survivors, are no longer with us. Many of us have faced antisemitism in various forms. Together, we are part of Cloudflare’s Employee Resource Group for Cloudflare’s Jewish community: Judeoflare. We have a responsibility to make sure the world remembers and never forgets the atrocities of the Holocaust and what racism and antisemitism can lead to.

Cloudflare customers on Free plans can now also get real-time DDoS alerts

2022-01-17 Omer Yoachimik

Post Syndicated from Omer Yoachimik original https://blog.cloudflare.com/free-ddos-alerts/

Cloudflare customers on Free plans can now also get real-time DDoS alerts

We’re excited to announce that customers using our Free plan can now get real-time alerts about HTTP DDoS attacks that were automatically detected and mitigated by Cloudflare. The real-time DDoS alerts were originally announced over a year ago but were made available to customers on the Pro plan or higher. This announcement extends the DDoS alerts feature to Free plan users. You can read the original announcement blog post here.

What is a DDoS attack?

A Distributed Denial of Service (DDoS) attack is a cyber-attack that attempts to disrupt your online business. Whether your business relies on VoIP servers, UDP-based gaming servers, or HTTP servers, DDoS attacks can be used to disrupt any type of Internet property, server, or network.

In this blog post, we’ll focus on DDoS attacks that target HTTP servers. Whether your HTTP server is powering a mobile app, an eCommerce website, an API gateway, or any other HTTP application, if an attacker sends you more requests than it can handle, your server won’t be able to serve your real users. A flood of requests can cause service disruptions or even take your entire server offline. DDoS attacks can have real-world consequences such as a blow to your revenue and reputation.

How Cloudflare detects and mitigates DDoS attacks

Protecting your server against DDoS attacks requires two main capabilities:

The bandwidth to absorb both your users’ requests and the attack requests
The ability to differentiate between your users’ requests and the attack requests

Using our home-grown systems, we do just that, regardless of the size, frequency and duration of the attacks. All Cloudflare customers, including those using the Free plan, are protected by our unmetered DDoS mitigation commitment.

To protect against DDoS attacks, first, we route your traffic to our network of data centers. Our network spans more than 250 cities in over 100 countries around the world. Its capacity is over 100 Tbps — fifty times larger than the largest attack we’ve ever seen. Our bandwidth is more than enough to absorb both your users’ traffic and attack traffic.

Cloudflare’s global network

Second, once your traffic reaches our data centers, it goes through state-of-the-art analysis mechanisms that constantly scan for DDoS attacks. Once an attack is detected, a real-time mitigation rule is automatically generated to surgically mitigate the attack requests based on the attack pattern, whilst leaving your users’ requests untouched. Using the HTTP DDoS Managed Ruleset you can customize the settings of the mitigation system to tailor it to your needs and specific traffic patterns.

Not sure what to do? That’s ok. For the most part, you won’t need to do anything and our system will automatically keep your servers protected. You can read more about it in our Get Started guide or in the original blog post. If you’re interested, you can also read more about how our mitigation system works in this technical blog post: A deep-dive into Cloudflare’s autonomous edge DDoS protection

Configuring a DDoS alert

Once our system detects and mitigates a DDoS attack, you’ll receive a real-time alert. To receive an alert, make sure you, first, configure a notification policy by following these steps:

Log in to the Cloudflare dashboard and select your account.
In the Home Screen, go to Notifications.
Click Add and choose the HTTP DDoS Attack Alerter.
Give your alert a name, an optional description, add the recipients’ email addresses and click Create.

To learn more about DDoS alerts and supported delivery methods, check out our guide Understanding Cloudflare DDoS Alerts.

Free DDoS protection, control, and visibility

Cloudflare’s mission is to help build a better Internet, and it guides everything we do. As part of this mission, we believe that a better Internet is one where enterprise-grade DDoS protection is available for everyone, not just bigger organizations.

Furthermore, we’ve also made our DDoS Managed Ruleset available for everyone to make sure that even non-paying customers can tailor and optimize their DDoS protection settings. Taking a step further, we want all of our users to be able to react as fast as possible when needed. This is why we’re providing real-time alerts for free. Knowledge is power, and notifying our users of attacks in real-time empowers them to ensure their website is safe, available, and performant.

Not using Cloudflare yet? Start now.

DDoS Attack Trends for Q4 2021

2022-01-10 Omer Yoachimik

Post Syndicated from Omer Yoachimik original https://blog.cloudflare.com/ddos-attack-trends-for-2021-q4/

DDoS Attack Trends for Q4 2021

This post is also available in 日本語, Deutsch, Français, Español.

The first half of 2021 witnessed massive ransomware and ransom DDoS attack campaigns that interrupted aspects of critical infrastructure around the world (including one of the largest petroleum pipeline system operators in the US) and a vulnerability in IT management software that targeted schools, public sector, travel organizations, and credit unions, to name a few.

The second half of the year recorded a growing swarm of one of the most powerful botnets deployed (Meris) and record-breaking HTTP DDoS attacks and network-layer attacks observed over the Cloudflare network. This besides the Log4j2 vulnerability (CVE-2021-44228) discovered in December that allows an attacker to execute code on a remote server — arguably one of the most severe vulnerabilities on the Internet since both Heartbleed and Shellshock.

Prominent attacks such as the ones listed above are but a few examples that demonstrate a trend of intensifying cyber-insecurity that affected everyone, from tech firms and government organizations to wineries and meat processing plants.

Here are some DDoS attack trends and highlights from 2021 and Q4 ‘21 specifically:

Ransom DDoS attacks

In Q4, ransom DDoS attacks increased by 29% YoY and 175% QoQ.
In December alone, one out of every three survey respondents reported being targeted by a ransom DDoS attack or threatened by the attacker.

Application-layer DDoS attacks

The Manufacturing industry was the most attacked in Q4 ’21, recording a whopping 641% increase QoQ in the number of attacks. The Business Services and Gaming/Gambling industries were the second and third most targeted industries by application-layer DDoS attacks.
For the fourth time in a row this year, China topped the charts with the highest percentage of attack traffic originating from its networks.
A new botnet called the Meris botnet emerged in mid-2021 and continued to bombard organizations around the world, launching some of the largest HTTP attacks on record — including a 17.2M rps attack that Cloudflare automatically mitigated.

Network-layer DDoS attacks

Q4 ’21 was the busiest quarter for attackers in 2021. In December 2021 alone, there were more than all the attacks observed in Q1 and Q2 ’21 separately.
While the majority of attacks were small, terabit-strong attacks became the new norm in the second half of 2021. Cloudflare automatically mitigated dozens of attacks peaking over 1 Tbps, with the largest one peaking just under 2 Tbps — the largest we’ve ever seen.
Q4 ’21, and November specifically, recorded a persistent ransom DDoS campaign against VoIP providers around the world.
Attacks originating from Moldova quadrupled in Q4 ’21 QoQ, making it the country with the highest percentage of network-layer DDoS activity.
SYN floods and UDP floods were the most frequent attack vectors while emerging threats such as SNMP attacks increased by nearly 5,800% QoQ.

This report is based on DDoS attacks that were automatically detected and mitigated by Cloudflare’s DDoS Protection systems. To learn more about how it works, check out this deep-dive blog post.

A note on how we measure DDoS attacks observed over our network

To analyze attack trends, we calculate the “DDoS activity” rate, which is the percentage of attack traffic out of the total traffic (attack + clean) observed over our global network. Measuring attack numbers as a percentage of the total traffic observed allows us to normalize data points and avoid biases reflected in absolute numbers towards, for example, a Cloudflare data center that receives more total traffic and likely, also more attacks.

An interactive version of this report is available on Cloudflare Radar.

Ransom Attacks

For over two years now, Cloudflare has been surveying attacked customers — one question on the survey being if they received a ransom note demanding payment in exchange to stop the DDoS attack. Q4 ’21 recorded the highest survey responses ever that indicated ransom threats — ransom attacks increased by 29% YoY and 175% QoQ. More specifically, one out of every 4.5 respondents (22%) reported receiving a ransom letter demanding payment by the attacker.

When we break it down by month, we can see that December 2021 topped the charts with 32% of respondents reporting receiving a ransom letter — that’s nearly one out of every three surveyed respondents.

Application-layer DDoS attacks

Application-layer DDoS attacks by industry

In Q4, DDoS attacks on Manufacturing companies increased by 641% QoQ, and DDoS attacks on the Business Services industry increased by 97%.

When we break down the application-layer attacks targeted by industry, the Manufacturing, Business Services, and Gaming/Gambling industries were the most targeted industries in Q4 ’21.

Application-layer DDoS attacks by source country

For the fourth quarter in a row, China remains the country with the highest percentage of DDoS attacks originating from within its borders. More than three out of every thousand HTTP requests that originated from Chinese IP addresses were part of an HTTP DDoS attack. The US remained in second place, followed by Brazil and India.

Application-layer DDoS attacks by target country

For the third consecutive time this year, organizations in the United States were targeted by the most HTTP DDoS attacks, followed by Canada and Germany.

Network-layer DDoS attacks

While application-layer attacks target the application (Layer 7 of the OSI model) running the service that end users are trying to access, network-layer attacks aim to overwhelm network infrastructure (such as in-line routers and servers) and the Internet link itself.

Cloudflare thwarts an almost 2 Tbps attack

In November, our systems automatically detected and mitigated an almost 2 Tbps DDoS attack. This was a multi-vector attack combining DNS amplification attacks and UDP floods. The entire attack lasted just one minute. The attack was launched from approximately 15,000 bots running a variant of the original Mirai code on IoT devices and unpatched GitLab instances.

Network-layer DDoS attacks by month

December was the busiest month for attackers in 2021.

Q4 ‘21 was the busiest quarter in 2021 for attackers. Over 43% of all network-layer DDoS attacks took place in the fourth quarter of 2021. While October was a relatively calmer month, in November, the month of the Chinese Singles’ Day, the American Thanksgiving holiday, Black Friday, and Cyber Monday, the number of network-layer DDoS attacks nearly doubled. The number of observed attacks increased towards the final days of December ’21 as the world prepared to close out the year. In fact, the total number of attacks in December alone was higher than all the attacks in Q2 ’21 and almost equivalent to all attacks in Q1 ’21.

Network-layer DDoS attacks by attack rate

While most attacks are still relatively ‘small’ in size, terabit-strong attacks are becoming the norm.

The distribution of attacks by their size (in bit rate) and month is shown below. As seen in the graph above, the majority of attacks took place in December. However, the graph below illustrates that larger attacks, over 300 Gbps in size, took place in November. Most of the attacks between 5-20 Gbps took place in December.

Distribution by packet rate

An interesting correlation Cloudflare has observed is that when the number of attacks increases, their size and duration decrease. In the first two-thirds of 2021, the number of attacks was relatively small, and correspondingly, their rates increased, e.g., in Q3 ’21, attacks ranging from 1-10 million packets per second (mpps) increased by 196%. In Q4 ’21, the number of attacks increased and Cloudflare observed a decrease in the size of attacks. 91% of all attacks peaked below 50,000 packets per second (pps) — easily sufficient to take down unprotected Internet properties.

Larger attacks of over 1 mpps decreased by 48% to 28% QoQ, while attacks peaking below 50K pps increased by 2.36% QoQ.

Distribution by bit rate

Similar to the trend observed in packet-intensive attacks, the amount of bit-intensive attacks shrunk as well. While attacks over 1 Tbps are becoming the norm, with the largest one we’ve ever seen peak just below 2 Tbps, the majority of attacks are still small and peaked below 500 Mbps (97.2%).

In Q4 ’21, larger attacks of all ranges above 500 Mbps saw massive decreases ranging from 35% to 57% for the larger 100+ Gbps attacks.

Network-layer DDoS attacks by duration

Most attacks remain under one hour in duration, reiterating the need for automated always-on DDoS mitigation solutions.

We measure the duration of an attack by recording the difference between when it is first detected by our systems as an attack and the last packet we see with that attack signature towards that specific target. In the last quarter of 2021, 98% of all network-layer attacks lasted less than one hour. This is very common as most of the attacks are short-lived. Even more so, a trend we’ve seen is that when the number of attacks increases, as in this quarter, their rate and duration decreases.

It’s recommended that companies use automated, always-on DDoS protection services that analyze traffic and apply real-time fingerprinting fast enough to block short-lived attacks.

Attack vectors

SYN floods remain attackers’ favorite method of attack, while attacks over SNMP saw a massive surge of almost 5,800% QoQ.

For the first time in 2021, the percentage of SYN flood attacks significantly decreased. Throughout 2021, SYN floods accounted for 54% of all network-layer attacks on average. While still grabbing first place as the most frequent vector, its share dropped by 38% QoQ to 34%.

However, it was a close-run for SYN attacks and UDP attacks. A UDP flood is a type of denial-of-service attack in which a large number of User Datagram Protocol (UDP) packets are sent to a targeted server with the aim of overwhelming that device’s ability to process and respond. Oftentimes, the firewall protecting the targeted server can also become exhausted as a result of UDP flooding, resulting in a denial-of-service to legitimate traffic. Attacks over UDP jumped from fourth place in Q3 ’21 to second place in Q4 ’21, with a share of 32% of all network-layer attacks — a 1,198% increase in QoQ.

In third place came the SNMP underdog that made a massive leap with its first time 2021 appearance in the top attack vectors.

Emerging threats

When we look at emerging attack vectors — which helps us understand what new vectors attackers are deploying to launch attacks — we observe a massive spike in SNMP, MSSQL, and generic UDP-based DDoS attacks.

Both SNMP and MSSQL attacks are used to reflect and amplify traffic on the target by spoofing the target’s IP address as the source IP in the packets used to trigger the attack.

Simple Network Management Protocol (SNMP) is a UDP-based protocol that is often used to discover and manage network devices such as printers, switches, routers, and firewalls of a home or enterprise network on UDP well-known port 161. In an SNMP reflection attack, the attacker sends out a large number of SNMP queries while spoofing the source IP address in the packet as the targets to devices on the network that, in turn, reply to that target’s address. Numerous responses from the devices on the network results in the target network being DDoSed.

Similar to the SNMP amplification attack, the Microsoft SQL (MSSQL) attack is based on a technique that abuses the Microsoft SQL Server Resolution Protocol for the purpose of launching a reflection-based DDoS attack. The attack occurs when a Microsoft SQL Server responds to a client query or request, attempting to exploit the Microsoft SQL Server Resolution Protocol (MC-SQLR), listening on UDP port 1434.

Network-layer DDoS attacks by country

Attacks originating from Moldova quadrupled, making it the country with the highest percentage of network-layer DDoS activity.

When analyzing network-layer DDoS attacks, we bucket the traffic by the Cloudflare edge data center locations where the traffic was ingested, and not by the source IP. The reason for this is that, when attackers launch network-layer attacks, they can spoof the source IP address in order to obfuscate the attack source and introduce randomness into the attack properties, which can make it harder for simple DDoS protection systems to block the attack. Hence, if we were to derive the source country based on a spoofed source IP, we would get a spoofed country.

Cloudflare is able to overcome the challenges of spoofed IPs by displaying the attack data by the location of the Cloudflare data center in which the attack was observed. We are able to achieve geographical accuracy in our report because we have data centers in over 250 cities around the world.

To view all regions and countries, check out the interactive map.

Summary

Cloudflare’s mission is to help build a better Internet. A better Internet is one that is more secure, faster, and reliable for everyone — even in the face of DDoS attacks. As part of our mission, since 2017, we’ve been providing unmetered and unlimited DDoS protection for free to all of our customers. Over the years, it has become increasingly easier for attackers to launch DDoS attacks. To counter the attacker’s advantage, we want to make sure that it is also easy and free for organizations of all sizes to protect themselves against DDoS attacks of all types.

Not using Cloudflare yet? Start now.

How to customize your layer 3/4 DDoS protection settings

2021-12-09 Omer Yoachimik

Post Syndicated from Omer Yoachimik original https://blog.cloudflare.com/l34-ddos-managed-rules/

How to customize your layer 3/4 DDoS protection settings

After initially providing our customers control over the HTTP-layer DDoS protection settings earlier this year, we’re now excited to extend the control our customers have to the packet layer. Using these new controls, Cloudflare Enterprise customers using the Magic Transit and Spectrum services can now tune and tweak their L3/4 DDoS protection settings directly from the Cloudflare dashboard or via the Cloudflare API.

The new functionality provides customers control over two main DDoS rulesets:

Network-layer DDoS Protection ruleset — This ruleset includes rules to detect and mitigate DDoS attacks on layer 3/4 of the OSI model such as UDP floods, SYN-ACK reflection attacks, SYN Floods, and DNS floods. This ruleset is available for Spectrum and Magic Transit customers on the Enterprise plan.
Advanced TCP Protection ruleset — This ruleset includes rules to detect and mitigate sophisticated out-of-state TCP attacks such as spoofed ACK Floods, Randomized SYN Floods, and distributed SYN-ACK Reflection attacks. This ruleset is available for Magic Transit customers only.

To learn more, review our DDoS Managed Ruleset developer documentation. We’ve put together a few guides that we hope will be helpful for you:

Cloudflare’s DDoS Protection

A Distributed Denial of Service (DDoS) attack is a type of cyberattack that aims to disrupt the victim’s Internet services. There are many types of DDoS attacks, and they can be generated by attackers at different layers of the Internet. One example is the HTTP flood. It aims to disrupt HTTP application servers such as those that power mobile apps and websites. Another example is the UDP flood. While this type of attack can be used to disrupt HTTP servers, it can also be used in an attempt to disrupt non-HTTP applications. These include TCP-based and UDP-based applications, networking services such as VoIP services, gaming servers, cryptocurrency, and more.

To defend organizations against DDoS attacks, we built and operate software-defined systems that run autonomously. They automatically detect and mitigate DDoS attacks across our entire network. You can read more about our autonomous DDoS protection systems and how they work in our deep-dive technical blog post.

Unmetered and unlimited DDoS Protection

The level of protection that we offer is unmetered and unlimited — It is not bounded by the size of the attack, the number of the attacks, or the duration of the attacks. This is especially important these days because as we’ve recently seen, attacks are getting larger and more frequent. Consequently, in Q3, network-layer attacks increased by 44% compared to the previous quarter. Furthermore, just recently, our systems automatically detected and mitigated a DDoS attack that peaked just below 2 Tbps — the largest we’ve seen to date.

Managed Rulesets

You can think of our autonomous DDoS protection systems as groups (rulesets) of intelligent rules. There are rulesets of HTTP DDoS Protection rules, Network-layer DDoS Protection rules and Advanced TCP Protection rules. In this blog post, we will cover the latter two rulesets. We’ve already covered the former in the blog post How to customize your HTTP DDoS protection settings.

In the Network-layer DDoS Protection rulesets, each rule has a unique set of conditional fingerprints, dynamic field masking, activation thresholds, and mitigation actions. These rules are managed (by Cloudflare), meaning that the specifics of each rule is curated in-house by our DDoS experts. Before deploying a new rule, it is first rigorously tested and optimized for mitigation accuracy and efficiency across our entire global network.

In the Advanced TCP Protection ruleset, we use a novel TCP state classification engine to identify the state of TCP flows. The engine powering this ruleset is flowtrackd — you can read more about it in our announcement blog post. One of the unique features of this system is that it is able to operate using only the ingress (inbound) packet flows. The system sees only the ingress traffic and is able to drop, challenge, or allow packets based on their legitimacy. For example, a flood of ACK packets that don’t correspond to open TCP connections will be dropped.

How attacks are detected and mitigated

Sampling

Initially, traffic is routed through the Internet via BGP Anycast to the nearest Cloudflare edge data center. Once the traffic reaches our data center, our DDoS systems sample it asynchronously allowing for out-of-path analysis of traffic without introducing latency penalties. The Advanced TCP Protection ruleset needs to view the entire packet flow and so it sits inline for Magic Transit customers only. It, too, does not introduce any latency penalties.

Analysis & mitigation

The analysis for the Advanced TCP Protection ruleset is straightforward and efficient. The system qualifies TCP flows and tracks their state. In this way, packets that don’t correspond to a legitimate connection and its state are dropped or challenged. The mitigation is activated only above certain thresholds that customers can define.

The analysis for the Network-layer DDoS Protection ruleset is done using data streaming algorithms. Packet samples are compared to the conditional fingerprints and multiple real-time signatures are created based on the dynamic masking. Each time another packet matches one of the signatures, a counter is increased. When the activation threshold is reached for a given signature, a mitigation rule is compiled and pushed inline. The mitigation rule includes the real-time signature and the mitigation action, e.g., drop.

Example

As a simple example, one fingerprint could include the following fields: source IP, source port, destination IP, and the TCP sequence number. A packet flood attack with a fixed sequence number would match the fingerprint and the counter would increase for every packet match until the activation threshold is exceeded. Then a mitigation action would be applied.

However, in the case of a spoofed attack where the source IP addresses and ports are randomized, we would end up with multiple signatures for each combination of source IP and port. Assuming a sufficiently randomized/distributed attack, the activation thresholds would not be met and mitigation would not occur. For this reason, we use dynamic masking, i.e. ignoring fields that may not be a strong indicator of the signature. By masking (ignoring) the source IP and port, we would be able to match all the attack packets based on the unique TCP sequence number regardless of how randomized/distributed the attack is.

Configuring the DDoS Protection Settings

For now, we’ve only exposed a handful of the Network-layer DDoS protection rules that we’ve identified as the ones most prone to customizations. We will be exposing more and more rules on a regular basis. This shouldn’t affect any of your traffic.

For the Network-layer DDoS Protection ruleset, for each of the available rules, you can override the sensitivity level (activation threshold), customize the mitigation action, and apply expression filters to exclude/include traffic from the DDoS protection system based on various packet fields. You can create multiple overrides to customize the protection for your network and your various applications.

In the past, you’d have to go through our support channels to customize the rules. In some cases, this may have taken longer to resolve than desired. With today’s announcement, you can tailor and fine-tune the settings of our autonomous edge system by yourself to quickly improve the accuracy of the protection for your specific network needs.

For the Advanced TCP Protection ruleset, for now, we’ve only exposed the ability to enable or disable it as a whole in the dashboard. To enable or disable the ruleset per IP prefix, you must use the API. At this time, when initially onboarding to Cloudflare, the Cloudflare team must first create a policy for you. After onboarding, if you need to change the sensitivity thresholds, use Monitor mode, or add filter expressions you must contact Cloudflare Support. In upcoming releases, this too will be available via the dashboard and API without requiring help from our Support team.

Pre-existing customizations

If you previously contacted Cloudflare Support to apply customizations, your customizations have been preserved, and you can visit the dashboard to view the settings of the Network-layer DDoS Protection ruleset and change them if you need. If you require any changes to your Advanced TCP Protection customizations, please reach out to Cloudflare Support.

If so far you didn’t have the need to customize this protection, there is no action required on your end. However, if you would like to view and customize your DDoS protection settings, follow this dashboard guide or review the API documentation to programmatically configure the DDoS protection settings.

Helping Build a Better Internet

At Cloudflare, everything we do is guided by our mission to help build a better Internet. The DDoS team’s vision is derived from this mission: our goal is to make the impact of DDoS attacks a thing of the past. Our first step was to build the autonomous systems that detect and mitigate attacks independently. Done. The second step was to expose the control plane over these systems to our customers (announced today). Done. The next step will be to fully automate the configuration with an auto-pilot feature — training the systems to learn your specific traffic patterns to automatically optimize your DDoS protection settings. You can expect many more improvements, automations, and new capabilities to keep your Internet properties safe, available, and performant.

Not using Cloudflare yet? Start now.

Cloudflare blocks an almost 2 Tbps multi-vector DDoS attack

2021-11-13 Omer Yoachimik

Post Syndicated from Omer Yoachimik original https://blog.cloudflare.com/cloudflare-blocks-an-almost-2-tbps-multi-vector-ddos-attack/

Cloudflare blocks an almost 2 Tbps multi-vector DDoS attack

Earlier this week, Cloudflare automatically detected and mitigated a DDoS attack that peaked just below 2 Tbps — the largest we’ve seen to date. This was a multi-vector attack combining DNS amplification attacks and UDP floods. The entire attack lasted just one minute. The attack was launched from approximately 15,000 bots running a variant of the original Mirai code on IoT devices and unpatched GitLab instances.

Network-layer DDoS attacks increased by 44%

Last quarter, we saw multiple terabit-strong DDoS attacks and this attack continues this trend of increased attack intensity. Another key finding from our Q3 DDoS Trends report was that network-layer DDoS attacks actually increased by 44% quarter-over-quarter. While the fourth quarter is not over yet, we have, again, seen multiple terabit-strong attacks that targeted Cloudflare customers.

How did Cloudflare mitigate this attack?

To begin with, our systems constantly analyze traffic samples “out-of-path” which allows us to asynchronously detect DDoS attacks without causing latency or impacting performance. Once the attack traffic was detected (within sub-seconds), our systems generated a real-time signature that surgically matched against the attack patterns to mitigate the attack without impacting legitimate traffic.

Once generated, the fingerprint is propagated as an ephemeral mitigation rule to the most optimal location in the Cloudflare edge for cost-efficient mitigation. In this specific case, as with most L3/4 DDoS attacks, the rule was pushed in-line into the Linux kernel eXpress Data Path (XDP) to drop the attack packet at wirespeed.

Read more about Cloudflare’s DDoS Protection systems.

Helping build a better Internet

Cloudflare’s mission is to help build a better Internet — one that is secure, faster, and more reliable for everyone. The DDoS team’s vision is derived from this mission: our goal is to make the impact of DDoS attacks a thing of the past. Whether it’s the Meris botnet that launched some of the largest HTTP DDoS attacks on record, the recent attacks on VoIP providers or this Mirai-variant that’s DDoSing Internet properties, Cloudflare’s network automatically detects and mitigates DDoS attacks. Cloudflare provides a secure, reliable, performant, and customizable platform for Internet properties of all types.

For more information about Cloudflare’s DDoS protection, reach out to us or have a go with a hands-on evaluation of Cloudflare’s Free plan here.

Update on recent VoIP attacks: What should I do if I’m attacked?

2021-10-07 Omer Yoachimik

Post Syndicated from Omer Yoachimik original https://blog.cloudflare.com/update-on-voip-attacks/

Update on recent VoIP attacks: What should I do if I’m attacked?

Attackers continue targeting VoIP infrastructure around the world. In our blog from last week, May I ask who’s calling, please? A recent rise in VoIP DDoS attacks, we reviewed how the SIP protocol works, ways it can be abused, and how Cloudflare can help protect against attacks on VoIP infrastructure without impacting performance.

Cloudflare’s network stands in front of some of the largest, most performance-sensitive voice and video providers in the world, and is uniquely well suited to mitigating attacks on VoIP providers.

Because of the sustained attacks we are observing, we are sharing details on recent attack patterns, what steps they should take before an attack, and what to do after an attack has taken place.

Below are three of the most common questions we’ve received from companies concerned about attacks on their VoIP systems, and Cloudflare’s answers.

Question #1: How is VoIP infrastructure being attacked?

The attackers primarily use off-the-shelf booter services to launch attacks against VoIP infrastructure. The attack methods being used are not novel, but the persistence of the attacker and their attempts to understand the target’s infrastructure are.

Attackers have used various attack vectors to probe the existing defenses of targets and try to infiltrate any existing defenses to disrupt VoIP services offered by certain providers. In some cases, they have been successful. HTTP attacks against API gateways and the corporate websites of the providers have been combined with network-layer and transport-layer attack against VoIP infrastructures. Examples:

TCP floods targeting stateful firewalls
These are being used in “trial-and-error” type attacks. They are not very effective against telephony infrastructure specifically (because it’s mostly UDP) but very effective at overwhelming stateful firewalls.
UDP floods targeting SIP infrastructure
Floods of UDP traffic that have no well-known fingerprint, aimed at critical VoIP services. Generic floods like this may look like legitimate traffic to unsophisticated filtering systems.
UDP reflection targeting SIP infrastructure
These methods, when targeted at SIP or RTP services, can easily overwhelm Session Border Controllers (SBCs) and other telephony infrastructure. The attacker seems to learn enough about the target’s infrastructure to target such services with high precision.
SIP protocol-specific attacks
Attacks at the application layer are of particular concern because of the higher resource cost of generating application errors vs filtering on network devices.

Question #2: How should I prepare my organization in case our VoIP infrastructure is targeted?

Deploy an always-on DDoS mitigation service
Cloudflare recommends the deployment of always-on network level protection, like Cloudflare Magic Transit, prior to your organization being attacked.
Do not rely on reactive on-demand SOC-based DDoS Protection services that require humans to analyze attack traffic — they take too long to respond. Instead, onboard to a cloud service that has sufficient network capacity and automated DDoS mitigation systems.

Cloudflare has effective mitigations in place for the attacks seen against VoIP infrastructure, including for sophisticated TCP floods and SIP specific attacks.
Enforce a positive security model
Block TCP on IP/port ranges that are not expected to receive TCP, instead of relying on on-premise firewalls that can be overwhelmed. Block network probing attempts (e.g. ICMP) and other packets that you don’t normally expect to see.
Build custom mitigation strategies
Work together with your DDoS protection vendor to tailor mitigation strategies to your workload. Every network is different, and each poses unique challenges when integrating with DDoS mitigation systems.
Educate your employees
Train all of your employees to be on the lookout for ransom demands. Check email, support tickets, form submissions, and even server access logs. Ensure employees know to immediately report ransom demands to your Security Incident Response team.

Question #3: What should I do if I receive a ransom/threat?

Do not to pay the ransom
Paying the ransom only encourages bad actors—and there’s no guarantee that they won’t attack your network now or later.
Notify Cloudflare
We can help ensure your website and network infrastructure are safeguarded against these attacks.
Notify local law enforcement
They will also likely request a copy of the ransom letter that you received.

Cloudflare is here to help

With over 100 Tbps of network capacity, a network architecture that efficiently filters traffic close to the source, and a physical presence in over 250 cities, Cloudflare can help protect critical VoIP infrastructure without impacting latency, jitter, and call quality. Test results demonstrate a performance improvement of 36% on average across the globe for a real customer network using Cloudflare Magic Transit.

Some of the largest voice and video providers in the world rely on Cloudflare to protect their networks and ensure their services remain online and fast. We stand ready to help.

Talk to a Cloudflare specialist to learn more.
Under attack? Contact our hotline to speak with someone immediately.

How to customize your HTTP DDoS protection settings

2021-09-20 Omer Yoachimik

Post Syndicated from Omer Yoachimik original https://blog.cloudflare.com/http-ddos-managed-rules/

How to customize your HTTP DDoS protection settings

We’re excited to announce the availability of the HTTP DDoS Managed Ruleset. This new feature allows Cloudflare customers to independently tailor their HTTP DDoS protection settings. Whether you’re on the Free plan or the Enterprise plan, you can now tweak and optimize the settings directly from within the Cloudflare dashboard or via API.

We expect that in most cases, Cloudflare customers won’t need to customize any settings. Our mission is to make DDoS disruptions a thing of the past, with no customer overhead. To achieve this mission we’re constantly investing in our automated detection and mitigation systems. In some rare cases, there is a need to make some configuration changes, and so now, Cloudflare customers can customize those protection mechanisms independently. The next evolutionary step is to make those settings learn and auto-tune themselves for our customers, based on their unique traffic patterns. Zero-touch DDoS protection at scale.

Unmetered DDoS Protection

Back in 2017, we announced that we will never kick a customer off of our network because they face large attacks, even if they are not paying us at all (i.e., using the Free plan). Furthermore, we committed to never charge a customer for DDoS attack traffic — no matter the size and duration of the attack. Just this summer, our systems automatically detected and mitigated one of the largest DDoS attacks of all time. As opposed to other vendors, Cloudflare customers don’t need to request a service credit for the attack traffic: we simply exclude DDoS traffic from our billing systems. This is done automatically, just like our attack detection and mitigation mechanisms.

Autonomous DDoS Protection

Our unmetered DDoS protection commitment is possible due to our ongoing investment in our network and technology stack. The global coverage and capacity of our network allows us to absorb the largest attacks ever recorded, without manual intervention. Using BGP Anycast, traffic is routed to the closest Cloudflare edge data center as a form of global inter-data center load balancing. Traffic is then load balanced efficiently inside the data center between servers with the help of Unimog, our home-grown L4 load balancer, to ensure that traffic arrives at the least loaded server. Then, each server scans for malicious traffic and, if detected, applies mitigations in the most optimal location in the tech stack. Each server detects and mitigates attacks completely autonomously without requiring any centralized consensus, and shares details with each other using multicast. This is done using our proprietary autonomous edge detection and mitigation system, and this is how we’re able to continue offering unmetered DDoS protection for free at the scale we operate at.

Configurable DDoS Protection

Our autonomous systems use a set of dynamic rules that scan for attack patterns, known attack tools, suspicious patterns, protocol violations, requests causing large amounts of origin errors, excessive traffic hitting the origin/cache, and additional attack vectors. Each rule has a predefined sensitivity level and default action that varies based on the rule’s confidence that the traffic is indeed part of an attack.

But how do we determine those confidence levels? The answer to that depends on each specific rule and what that rule is looking for. Some rules look for the patterns in HTTP attributes that are generated by known attack tools and botnets, known protocol violations and other general suspicious patterns and traffic abnormalities. If a given rule is searching for the HTTP patterns of known attack tools, then once found, the likelihood (i.e., confidence) that this traffic is part of an attack is high, and we can therefore safely block all the traffic that matches that rule. However, in other cases, the detected patterns or abnormal activity might resemble an attack but can actually be caused by faulty applications that generate abnormal HTTP calls, misbehaving API clients that flood their origin server, and even legitimate traffic that naively violates protocol standards. In those cases, we might want to rate-limit the traffic that matches the rule or serve a challenge action to verify and allow legitimate users in while blocking bad bots and attackers.

Configuring the DDoS Protection Settings

In the past, you’d have to go through our support channels to customize any of the default actions and sensitivity levels. In some cases, this may have taken longer to resolve than desired. With today’s release, you can tailor and fine-tune the settings of our autonomous edge system by yourself to quickly improve the accuracy of the protection for your specific application needs.

If you previously contacted Cloudflare Support to apply customizations, the DDoS Ruleset has been set to Essentially off or Low for your zone, based on your existing customization. You can visit the dashboard to view the settings and change them if you need.

If you’ve requested to exclude or bypass the mitigations for specific HTTP attributes or IPs, or if you’ve requested a significantly high threshold that requires Cloudflare approval, then those customizations are still active but may not yet be visible in the dashboard.

If you haven’t experienced this issue previously, there is no action required on your end. However, if you would like to customize your DDoS protection settings, go directly to the DDoS tab or follow these steps:

Log in to the Cloudflare dashboard, and select your account and website.
Go to Firewall > DDoS.
Next to HTTP DDoS attack protection, click Configure.
In Ruleset configuration, select the action and sensitivity values for all the rules in the HTTP DDoS Managed Ruleset.

Alternatively, follow the API documentation to programmatically configure the DDoS protection settings.

In the configuration page, you can select a different Action and Sensitivity Level to override all the DDoS protection rules as a group of rules (i.e., the “ruleset”).

Alternatively, you can click Browse Rules to override specific rules, rather than all of them as a set of rules.

Mitigation Action

The mitigation action defines what action to take when the mitigation rule is applied. Our systems constantly analyze traffic and track potentially malicious activity. When certain request-per-second thresholds exceed the configured sensitivity level, a mitigation rule with a dynamically generated signature will be applied to mitigate the attack. The default mitigation action can vary according to the specific rule. A rule with less confidence may apply a Challenge action as a form of soft mitigation, and a rule with a Block action is applied when there is higher confidence that the traffic is part of an attack — as a form of a stricter mitigation action.

The available values for the action are:

Block
Challenge (CAPTCHA)
Log
Use Rule Defaults

Some examples of when you may want to change the mitigation action include:

Safer onboarding: You’re onboarding a new HTTP application which has odd traffic patterns, naively violates protocol violations or causes spiky behavior. In this case, you can set the action to Log and see what traffic our systems flag. Afterwards, you can make the necessary changes to the sensitivity levels as required and switch the mitigation action back to the default.
Stricter mitigation: A DDoS attack has been detected but a Rate-limit or Challenge action have been applied due to the rule’s default logic. However, in this specific case, you’re sure that this is malicious traffic, so you can change the action to Block for a more complete mitigation.

Mitigation Sensitivity

The sensitivity level defines when the mitigation rule is applied. Our systems constantly analyze traffic and track potentially malicious activity. When certain request-per-second thresholds are crossed, a mitigation rule with a dynamically generated signature will be applied to mitigate the attack. Toggling the sensitivity levels allows you to define when the mitigation is applied. The higher the sensitivity, the faster the mitigation is applied. The available values for sensitivity are:

High (default)
Medium
Low
Essentially Off

Essentially Off means that we’ve set an exceptionally low sensitivity level so in most cases traffic won’t be mitigated for you. However, attack traffic will be mitigated at exceptional levels to ensure the safety and stability of the Cloudflare network.

Some examples of when you may want to change the sensitivity action include:

Avoid impact to legitimate traffic: One of the rules has applied mitigation to your legitimate traffic due to a suspicious pattern. In this case, you may want to reduce the rule sensitivity to avoid recurrence of the issue and negative impact to your traffic.
Legacy applications: One of your legacy HTTP applications is violating protocol standards, or you may have mistakenly introduced a bug into your mobile application/API client. These cases may result in abnormal traffic activity that may be flagged by our systems. In such a case, you can select the Essentially Off sensitivity level until you’ve resolved the issue on your end, to avoid false positives.

Overriding Specific Rules

As mentioned above, you can also select a specific rule to override its action and sensitivity levels. The per-rule override takes priority over the ruleset override.

When configuring per-rule overrides, you’ll see that some rules have a DDoS Dynamic action. This means that the mitigation is multi-staged and will apply different mitigation actions depending on various factors including attack type, request characteristics, and various other factors. This dynamic action can also be overridden if you choose to do so.

DDoS Attack Analytics

When a DDoS attack is detected and mitigated, you’ll receive a real-time DDoS alert (if you’ve configured one) and you’ll be able to view the attack in the Firewall analytics dashboard. The attack details and the rule ID that was triggered will also be displayed in the Activity log as part of each HTTP request log that was mitigated.

Helping Build a Better Internet

At Cloudflare, everything we do is guided by our mission to help build a better Internet. A significant part of that mission is to make DDoS downtime and service disruptions a thing of the past. By giving our users the visibility and tools they need in order to understand and improve their DDoS protection, we’re hoping to make another step towards a better Internet.

Do you have feedback about the user interface or anything else? In the new DDoS tab, we’ve added a link to provide feedback, so you too can help shape the future of Cloudflare’s DDoS protection Managed Rules.

Not using Cloudflare yet? Start now.

Cloudflare thwarts 17.2M rps DDoS attack — the largest ever reported

2021-08-19 Omer Yoachimik

Post Syndicated from Omer Yoachimik original https://blog.cloudflare.com/cloudflare-thwarts-17-2m-rps-ddos-attack-the-largest-ever-reported/

Cloudflare thwarts 17.2M rps DDoS attack — the largest ever reported

Earlier this summer, Cloudflare’s autonomous edge DDoS protection systems automatically detected and mitigated a 17.2 million request-per-second (rps) DDoS attack, an attack almost three times larger than any previous one that we’re aware of. For perspective on how large this attack was: Cloudflare serves over 25 million HTTP requests per second on average. This refers to the average rate of legitimate traffic in 2021 Q2. So peaking at 17.2 million rps, this attack reached 68% of our Q2 average rps rate of legitimate HTTP traffic.

Automated DDoS mitigation with Cloudflare’s autonomous edge

This attack, along with the additional attacks provided in the next sections, were automatically detected and mitigated by our autonomous edge DDoS protection systems. The system is powered by our very own denial of service daemon (dosd). Dosd is a home-grown software-defined daemon. A unique dosd instance runs in every server in each one of our data centers around the world. Each dosd instance independently analyzes traffic samples out-of-path. Analyzing traffic out-of-path allows us to scan asynchronously for DDoS attacks without causing latency and impacting performance. DDoS findings are also shared between the various dosd instances within a data center, as a form of proactive threat intelligence sharing.

Once an attack is detected, our systems generate a mitigation rule with a real-time signature that matches the attack patterns. The rule is propagated to the most optimal location in the tech stack. As an example, a volumetric HTTP DDoS attack may be blocked at L4 inside the Linux iptables firewall instead of at L7 inside the L7 reverse proxy which runs in the user space. Mitigating lower in the stack, e.g. dropping the packets at L4 instead of responding with a 403 error page in L7, is more cost-efficient. It reduces our edge CPU consumption and intra-data center bandwidth utilization — thus helping us mitigate large attacks at scale without impacting performance.

This autonomous approach, along with our network’s global scale and reliability, allow us to mitigate attacks that reach 68% of our average per-second-rate, and higher, without requiring any manual mitigation by Cloudflare personnel, nor causing any performance degradation.

The resurgence of Mirai and new powerful botnets

This attack was launched by a powerful botnet, targeting a Cloudflare customer in the financial industry. Within seconds, the botnet bombarded the Cloudflare edge with over 330 million attack requests.

The attack traffic originated from more than 20,000 bots in 125 countries around the world. Based on the bots’ source IP addresses, almost 15% of the attack originated from Indonesia and another 17% from India and Brazil combined. Indicating that there may be many malware infected devices in those countries.

Volumetric attacks increase

This 17.2 million rps attack is the largest HTTP DDoS attack that Cloudflare has ever seen to date and almost three times the size of any other reported HTTP DDoS attack. This specific botnet, however, has been seen at least twice over the past few weeks. Just last week it also targeted a different Cloudflare customer, a hosting provider, with an HTTP DDoS attack that peaked just below 8 million rps.

Two weeks before, a Mirai-variant botnet launched over a dozen UDP and TCP based DDoS attacks that peaked multiple times above 1 Tbps, with a max peak of approximately 1.2 Tbps. And while the first HTTP attacks targeted Cloudflare customers on the WAF/CDN service, the 1+ Tbps network-layer attacks targeted Cloudflare customers on the Magic Transit and Spectrum services. One of these targets was a major APAC-based Internet services, telecommunications and hosting provider. The other was a gaming company. In all cases, the attacks were automatically detected and mitigated without human intervention.

The Mirai botnet started with roughly 30K bots and slowly shrinked to approximately 28K. However, despite losing bots from its fleet, the botnet was still able to generate impressive volumes of attack traffic for short periods. In some cases, each burst lasted only a few seconds.

These attacks join the increase in Mirari-based DDoS attacks that we’ve observed on our network over the past weeks. In July alone, L3/4 Mirai attacks increased by 88% and L7 attacks by 9%. Additionally, based on the current August per-day average of the Mirai attacks, we can expect L7 Mirai DDoS attacks and other similar botnet attacks to increase by 185% and L3/4 attacks by 71% by the end of the month.

Back to the Mirai

Mirai, which means ‘future’ in Japanese, is a codename for malware that was first discovered in 2016 by MalwareMustDie, a non-profit security research workgroup. The malware spreads by infecting Linux-operated devices such as security cameras and routers. It then self-propagates by searching for open Telnet ports 23 and 2323. Once found, it then attempts to gain access to vulnerable devices by brute forcing known credentials such as factory default usernames and passwords. Later variants of Mirai also took advantage of zero-day exploits in routers and other devices. Once infected, the devices will monitor a Command & Control (C2) server for instructions on which target to attack.

How to protect your home and business

While the majority of attacks are small and short, we continue to see these types of volumetric attacks emerging more often. It’s important to note that these volumetric short burst attacks can be especially dangerous for legacy DDoS protection systems or organizations without active, always-on cloud-based protection.

Furthermore, while the short duration may say something about the botnet’s capability to deliver sustained levels of traffic over time, it can be challenging or impossible for humans to react to it in time. In such cases, the attack is over before a security engineer even has time to analyze the traffic or activate their stand-by DDoS protection system. These types of attacks highlight the need for automated, always-on protection.

How to protect your business and Internet properties

Onboard to Cloudflare to protect your Internet properties.
DDoS is enabled out of the box, and you can also customize the protection settings.
Follow our preventive best practices, to ensure that both your Cloudflare settings and your origin server settings are optimized. As an example, make sure that you allow only traffic from Cloudflare’s IP range. Ideally, ask your upstream Internet Service Provider (ISP) to apply an access control list (ACL), otherwise, attackers may target your servers’ IP addresses directly and bypass your protection.

Recommendations on how to protect your home and IoT appliances

Change the default username and password of any device that is connected to the Internet such as smart cameras and routers. This will reduce the risk that malware such as Mirai can gain access to your router and IoT devices.
Protect your home against malware with Cloudflare for Families. Cloudflare for Families is a free service that automatically blocks traffic from your home to malicious websites and malware communication.

Ransom DDoS attacks target a Fortune Global 500 company

2021-01-07 Omer Yoachimik

Post Syndicated from Omer Yoachimik original https://blog.cloudflare.com/ransom-ddos-attacks-target-a-fortune-global-500-company/

Ransom DDoS attacks target a Fortune Global 500 company

In late 2020, a major Fortune Global 500 company was targeted by a Ransom DDoS (RDDoS) attack by a group claiming to be the Lazarus Group. Cloudflare quickly onboarded them to the Magic Transit service and protected them against the lingering threat. This extortion attempt was part of wider ransom campaigns that have been unfolding throughout the year, targeting thousands of organizations around the world. Extortionists are threatening organizations with crippling DDoS attacks if they do not pay a ransom.

Throughout 2020, Cloudflare onboarded and protected many organizations with Magic Transit, Cloudflare’s DDoS protection service for critical network infrastructure, the WAF service for HTTP applications, and the Spectrum service for TCP/UDP based applications — ensuring their business’s availability and continuity.

Unwinding the attack timeline

I spoke with Daniel (a pseudonym) and his team, who work at the Incident Response and Forensics team at the aforementioned company. I wanted to learn about their experience, and share it with our readers so they could learn how to better prepare for such an event. The company has requested to stay anonymous and so some details have been omitted to ensure that. In this blog post, I will refer to them as X.

Initially, the attacker sent ransom emails to a handful of X’s publicly listed email aliases such as press@, shareholder@, and hostmaster@. We’ve heard from other customers that in some cases, non-technical employees received the email and ignored it as being spam which delayed the incident response team’s time to react by hours. However, luckily for X, a network engineer that was on the email list of the hostmaster@ alias saw it and immediately forwarded it to Daniel’s incident response team.

In the ransom email, the attackers demanded 20 bitcoin and gave them a week to pay up, or else a second larger attack would strike, and the ransom would increase to 30 bitcoin. Daniel says that they had a contingency plan ready for this situation and that they did not intend to pay. Paying the ransom funds illegitimate activities, motivates the attackers, and does not guarantee that they won’t attack anyway.

…Please perform a google search of “Lazarus Group” to have a look at some of our previous work. Also, perform a search for “NZX” or “New Zealand Stock Exchange” in the news. You don’t want to be like them, do you?…

The current fee is 20 Bitcoin (BTC). It’s a small price to pay for what will happen if your whole network goes down. Is it worth it? You decide!…

If you decide not to pay, we will start the attack on the indicated date and uphold it until you do. We will completely destroy your reputation and make sure your services will remain offline until you pay…

–An excerpt of the ransom note

The contingency plan

Upon receiving the email from the network engineer, Daniel called him and they started combing through the network data — they noticed a significant increase in traffic towards one of their global data centers. This attacker was not playing around, firing gigabits per second towards a single server. The attack, despite just being a proof of intention, saturated the Internet uplink to that specific data center, causing a denial of service event and generating a series of failure events.

This first “teaser” attack came on a work day, towards the end of business hours as people were already wrapping up their day. At the time, X was not protected by Cloudflare and relied on an on-demand DDoS protection service. Daniel activated the contingency plan which relied on the on-demand scrubbing center service.

Daniel contacted their DDoS protection service. It took them over 30 minutes to activate the service and redirect X’s traffic to the scrubbing center. Activating the on-demand service caused networking failures and resulted in multiple incidents for X on various services — even ones that were not under attack. Daniel says hindsight is 2020 and he realized that an always-on service would have been much more effective than on-demand, reactionary control that takes time to implement, after the impact is felt. The networking failures amplified the one-hour attack resulting in incidents lasting much longer than expected.

Onboarding to Cloudflare

Following the initial attack, Daniel’s team reached out to Cloudflare and wanted to onboard to our automated always-on DDoS protection service, Magic Transit. The goal was to onboard to it before the second attack would strike. Cloudflare explained the pre-onboarding steps, provided details on the process, and helped onboard X’s network in a process Daniel defined as “quite painless and very professional. The speed and responsiveness were impressive. One of the key differentiation is the attack and traffic analytics that we see that our incumbent provider couldn’t provide us. We’re seeing attacks we never knew about being mitigated automatically.”

The attackers promised a second, huge attack which never happened. Perhaps it was just an empty threat, or it could be that the attackers detected that X is protected by Cloudflare which deterred them and they, therefore, decided to move on to their next target?

Recommendations for organizations

I asked Daniel if he has any recommendations for businesses so they can learn from his experience and be better prepared, should they be targeted by ransom attacks:

1. Utilize an automated always-on DDoS protection service

Do not rely on reactive on-demand SOC-based DDoS Protection services that require humans to analyze attack traffic. It just takes too long. Don’t be tempted to use an on-demand service: “you get all of the pain and none of the benefits”. Instead, onboard to a cloud service that has sufficient network capacity and automated DDoS mitigation systems.

2. Work with your vendor to build and understand your threat model

Work together with your DDoS protection vendor to tailor mitigation strategies to your workload. Every network is different, and each poses unique challenges when integrating with DDoS mitigation systems.

3. Create a contingency plan and educate your employees

Be prepared. Have plans ready and train your teams on them. Educate all of your employees, even the non-techies, on what to do if they receive a ransom email. They should report it immediately to your Security Incident Response team.

Cloudflare customers need not worry as they are protected. Enterprise customers can reach out to their account team if they are being extorted in order to review and optimize their security posture if needed. Customers on all other plans can reach out to our support teams and learn more about how to optimize your Cloudflare security configuration.

Not a Cloudflare customer yet? Speak to an expert or sign up.