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/

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.

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.

Entwicklung der DDoS-Bedrohungslandschaft im zweiten Quartal 2022

2022-07-06 Omer Yoachimik

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

Entwicklung der DDoS-Bedrohungslandschaft im zweiten Quartal 2022

Willkommen zu unserem DDoS-Bericht für das zweite Quartal 2022. Darin beschreiben wir Trends hinsichtlich der DDoS-Bedrohungslandschaft, die sich im globalen Cloudflare-Netzwerk beobachten ließen, und die von uns daraus gezogenen Schlüsse. Eine interaktive Version dieses Berichts ist auch bei Radar verfügbar.

Im zweiten Quartal haben wir einige der größten Angriffen aller Zeiten registriert, darunter eine HTTPS-DDoS-Attacke mit 26 Millionen Anfragen pro Sekunde, die von Cloudflare automatisch erkannt und abgewehrt wurde. Neben fortgesetzten Angriffen auf die Ukraine und Russland hat sich zudem eine neue Ransom-DDoS-Angriffskampagne entwickelt.

Die wichtigsten Erkenntnisse auf einen Blick

Das Internet in Russland und der Ukraine

Der Krieg wird nicht nur physisch, sondern auch in der digitalen Welt ausgefochten. Dort zielen die Angriffe darauf ab, die Verbreitung von Informationen zu verhindern.
In der Ukraine waren im zweiten Quartal Rundfunk- und Medienunternehmen das häufigste Ziel von DDoS-Angriffen. Tatsächlich sind die sechs am stärkten betroffenen Branchen alle den Bereichen Online-/Internetmedien, Verlagswesen und Rundfunk zuzurechnen.
Demgegenüber sind in Russland die Online-Medien unter den Angriffszielen auf den dritten Platz zurückgefallen. Spitzenreiter war das Segment Banken, Finanzdienstleistungen und Versicherungen (Banking, Financial Services and Insurance – BFSI). Fast 50 % aller DDoS-Angriffe auf Anwendungsschicht richteten sich gegen diese Sparte. Am zweithäufigsten wurden in Russland Unternehmen im Bereich Kryptowährungen attackiert.

Erfahren Sie mehr darüber, was Cloudflare unternimmt, um das offene Internet in Russland aufrechtzuerhalten und Angriffe zu verhindern.

Ransom-DDoS-Angriff

Es war eine neue Welle von Ransom DDoS-Angriffen durch Akteure zu verzeichnen, die nach eigenen Angaben der „Fancy Lazarus“-Gruppe angehören.
Im Juni 2022 erreichten die Ransom-Angriffe den bisherigen Höchststand des Jahres: Jeder fünfte unter den Befragten, der eine DDoS-Attacke erlebt hat, gab an, einem Ransom-DDoS-Angriff oder ähnlich gearteten Bedrohungen ausgesetzt gewesen zu sein.
Insgesamt stieg der Anteil der Ransomware-DDoS-Angriffe vom ersten auf das zweite Quartal um 11 %.

DDoS-Angriffe auf Anwendungsschicht

Im Jahresvergleich erhöhten sich die DDoS-Angriffe auf Anwendungsschicht zwischen April und Juni 2022 um 44 %.
Am häufigsten waren Unternehmen in den USA betroffen, gefolgt von Zypern, Hongkong und China. Die Attacken auf zypriotische Firmen nahmen gegenüber dem entsprechenden Vorjahreszeitraum um 171 % zu.
Im Branchenvergleich stand die Luft- und Raumfahrtindustrie im zweiten Quartal am stärksten im Fokus – gefolgt von der Internetbranche, dem BFSI-Sektor und dem Glücksspielsegment.

DDoS-Angriffe auf Netzwerkschicht

Die DDoS-Angriffe auf Netzwerkschicht stiegen im zweiten Quartal 2022 gemessen am Vorjahr um 75 % an. Verglichen mit den vorangegangenen drei Monaten legten Attacken mit 100 Gbit/s und mehr um 19 % und Angriffe mit einer Dauer von über drei Stunden um 9 % zu.
Am stärksten unter Beschuss standen die Telekommunikations-, Glücksspiel-, Informationstechnologie- und Dienstleistungsbranche.
Unternehmen in den USA waren am häufigsten betroffen, gefolgt von Firmen in Singapur, Deutschland und China.

Dieser Bericht beruht auf DDoS-Angriffen, die von den Schutzsystemen von Cloudflare automatisch erkannt und abgewehrt wurden. Wie dabei genau vorgegangen wurde, erfahren Sie in diesem ausführlichen Blog-Beitrag.

Wie wir DDoS-Angriffe messen, die in unserem Netzwerk registriert werden

Um Angriffstrends zu analysieren, berechnen wir die „DDoS-Aktivitätsrate“, die dem prozentualen Anteil des Angriffs-Traffics am gesamten Datenverkehr (Angriffs-Traffic + regulärer Traffic) in unserem globalen Netzwerk oder an einem konkreten Standort oder in einer bestimmten Kategorie entspricht. Wir messen die Prozentsätze, um eine statistische Normalisierung der Datensätze vorzunehmen und Verzerrungen zu vermeiden, die in den absoluten Zahlen auftreten, z. B. durch ein Cloudflare-Rechenzentrum, das insgesamt mehr Traffic und daher wahrscheinlich auch mehr Angriffe verzeichnet.

Ransom-Angriffe

Unsere Systeme analysieren ständig den Datenverkehr und wenden automatisch Schutzmaßnahmen an, wenn DDoS-Angriffe entdeckt werden. Jeder Kunde, der eine solche Attacke erlebt hat, wird zur Teilnahme an einer automatischen Umfrage aufgefordert. Diese hilft uns dabei, die Art des Angriffs und den Erfolg der Abwehrmaßnahmen besser einzuschätzen.

Seit über zwei Jahren befragt Cloudflare angegriffene Kunden danach, ob ihnen mit einem DDoS-Angriff gedroht wurde oder ihnen in Aussicht gestellt wurde, dass sie einen solchen durch Zahlung eines Lösegelds abwenden bzw. beenden können.

Die Anzahl der Befragten, die im Berichtszeitraum entsprechende Drohungen oder Lösegeldforderungen meldeten, steigerte sich um jeweils 11 % im Quartals- und Jahresvergleich. Im zweiten Jahresviertel haben wir Ransomware-DDoS-Angriffe von Akteuren abgewehrt, die behaupten, der APT (Advanced Persistent Threat)-Gruppe „Fancy Lazarus“ anzugehören. Die jüngste Kampagne konzentriert sich auf Finanzinstitute und Unternehmen im Bereich Kryptowährungen.

Im Juni gab unter den Befragten jeder fünfte an, einen Ransom-DDoS-Angriff erlebt oder eine entsprechende Drohung erhalten zu haben. Dies ist der höchste Wert seit Dezember 2021.

DDoS-Angriffe auf Anwendungsschicht

DDoS-Angriffe auf Anwendungsschicht – genauer gesagt HTTP-DDoS-Attacken – sind normalerweise Versuche, einen Webserver zu stören, sodass er keine legitimen Nutzer-Anfragen mehr verarbeiten kann: Wenn ein Server eine Flut von Anfragen erhält und nicht alle bearbeiten kann, verwirft er legitime Anfragen und stürzt in manchen Fällen sogar ab. Für die Nutzer hat das eine schlechtere Performance oder einen Ausfall zur Folge.

DDoS-Angriffe auf Anwendungsschicht aufgeschlüsselt nach Monat

Das Volumen der DDoS-Angriffe auf Anwendungsschicht hat sich im zweiten Quartal gemessen am Vorjahreszeitraum um 44 % erhöht.

Verglichen mit den vorangegangenen drei Monaten ergab sich dagegen ein Rückgang um 16 %. Die höchste Angriffsaktivität des zweiten Quartals wurde im Mai registriert, denn in diesem Monat fanden fast 47 % aller DDoS-Attacken auf Anwendungsschicht statt, während die wenigsten Angriffe im Juni erfolgten (18 %).

DDoS-Angriffe auf Anwendungsschicht aufgeschlüsselt nach Branche

Die Angriffe auf die Luft- und Raumfahrtindustrie sind gegenüber dem Vorquartal um 256 % gestiegen.

Die Branche war im Berichtszeitraum Spitzenreiter bei DDoS-Angriffen auf Anwendungsschicht. Dahinter folgten das Segment BFSI und an dritter Stelle die Glücksspielindustrie.

Der Cyberspace in Russland und der Ukraine

In der Ukraine stehen Medien- und Verlagsunternehmen am stärksten im Fadenkreuz.

Der Krieg tobt dort nicht nur am Boden, in der Luft und auf dem Wasser, sondern auch im Cyberspace. Akteure, die es auf ukrainische Firmen abgesehen haben, scheinen zu versuchen, Informationen zu unterdrücken. Die sechs am häufigsten angegriffenen ukrainischen Branchen stehen alle mit Rundfunk, Internet, Online-Medien und dem Verlagswesen in Verbindung. Auf diese Bereiche entfallen fast 80 % aller DDoS-Attacken in der Ukraine.

Was die andere Kriegspartei betrifft, stand in Russland der Bereich BFSI am stärksten unter digitalem Beschuss, denn fast 50 % aller DDoS-Angriffe richteten sich gegen diesen Sektor. Das zweithäufigste Angriffsziel war das Segment Kryptowährungen, gefolgt von Online-Medien.

Auf beiden Seiten ist zu beobachten, dass die Angriffe in hohem Maße dezentral sind, was auf den Einsatz global verteilter Botnetze hindeutet.

DDoS-Angriffe auf Anwendungsschicht aufgeschlüsselt nach Ursprungsland

Die Attacken aus China sind im Zeitraum April bis Juni 2022 um 112 % gestiegen, während von den Vereinigten Staaten ausgehende Angriffe um 43 % abgenommen haben.

Um die Herkunft der HTTP-Attacken zu ermitteln, nutzen wir die Geolokalisierungsdaten der Ursprungs-IP-Adresse des Clients, von dem die für den Angriff eingesetzten HTTP-Anfragen versandt wurden. Anders als bei Angriffen auf Netzwerkschicht können Ursprungs-IP-Adressen bei HTTP-Angriffen nicht gefälscht werden. Entfällt ein hoher Anteil der DDoS-Aktivität auf ein bestimmtes Land, heißt das nicht zwangsläufig, dass die Angriffe tatsächlich alle von diesem Land ausgehen. Vielmehr deutet dies auf den Einsatz von Botnetzen hin, die aus diesem Staat heraus agieren bzw. dort betrieben werden.

Die USA waren das zweite Quartal in Folge die größte Quelle von HTTP-DDoS-Angriffen. Es folgen China auf Rang zwei sowie Indien und Deutschland auf dem dritten und vierten Platz. Obwohl die Vereinigten Staaten weiterhin das Ranking anführen, gingen die US-amerikanischen Angriffe im Quartalsvergleich um 43 % zurück. Ein Zuwachs wurde dagegen bei den Attacken aus China (+112 %), Indien (+89 %) und Deutschland (+50 %) verbucht.

DDoS-Angriffe auf Anwendungsschicht aufgeschlüsselt nach Zielland

Um herauszufinden, auf welche Länder die meisten HTTP-DDoS-Angriffe abzielen, haben wir die Attacken nach den Ländern der Rechnungsadressen unserer Kunden aufgeschlüsselt und ihren prozentualen Anteil an allen DDoS-Angriffen dargestellt.

HTTP-DDoS-Angriffe auf Unternehmen mit Sitz in den USA nahmen im Quartalsvergleich um 45 % zu und brachten die Vereinigten Staaten wieder auf den ersten Platz als Hauptziel von DDoS-Angriffen auf Anwendungsschicht. Die Attacken auf chinesische Firmen sind im Quartalsvergleich um 79 % gesunken, sodass die Volksrepublik vom ersten auf den vierten Platz zurückgefallen ist. Die Angriffe auf Zypern haben sich hingegen um 171 % erhöht, was dem Land im zweiten Quartal Rang zwei bescherte. Es folgen Hongkong, China und Polen.

DDoS-Angriffe auf Netzwerkschicht

Bei Angriffen auf Anwendungsschicht (Layer 7 im OSI-Modell) sind die Dienste betroffen, auf die Endnutzer zugreifen wollen (in unserem Fall HTTP/S). Demgegenüber zielen Attacken auf Netzwerkschicht auf eine Überlastung der Netzwerkinfrastruktur (wie Router und Server innerhalb des Netzwerkpfads) und der Internetverbindung selbst ab.

DDoS-Angriffe auf Netzwerkschicht aufgeschlüsselt nach Monat

Im zweiten Quartal nahmen DDoS-Angriffe auf Netzwerkschicht um 75 % im Jahresvergleich zu. Volumetrische Angriffe von 100 Gbit/s und mehr stiegen gemessen am ersten Jahresviertel 2022 um 19 %.

Die Gesamtzahl der DDoS-Angriffe auf Netzwerkschicht erhöhte sich gegenüber dem Vorjahr um 75 %, änderte sich aber im Vergleich zum Vorquartal nicht wesentlich. Der April war der ereignisreichste Monat des Quartals, denn in diesem Zeitraum fanden fast 40 % der Angriffe statt.

DDoS-Angriffe auf Netzwerkschicht aufgeschlüsselt nach Branche

Im zweiten Jahresviertel 2022 wurden 45 % mehr Angriffe auf Telekommunikationsunternehmen verzeichnet als im ersten.

Zum zweiten Mal in Folge war die Telekommunikationsbranche das beliebteste Ziel von DDoS-Angriffen auf Netzwerkschicht. Mehr noch: Die Angriffe auf Telekommunikationsunternehmen stiegen um 45 % im Vergleich zum Vorquartal. Die Glücksspielindustrie belegte den zweiten Platz, gefolgt von Firmen aus dem Bereich Informationstechnologie und Dienstleistungen.

DDoS-Angriffe auf Netzwerkschicht aufgeschlüsselt nach Zielland

Die Angriffe auf US-Netzwerke stiegen im Quartalsvergleich um 70 %.

Im Zeitraum April bis Juni blieben die Vereinigten Staaten das am meisten angegriffene Land. Darauf folgte Singapur, denn der Stadtstaat kletterte vom vierten Platz im vorherigen Quartal auf den zweiten. An dritter Stelle lag Deutschland, gefolgt von China, den Malediven und Südkorea.

DDoS-Angriffe auf der Netzwerkschicht aufgeschlüsselt nach Land, aus dem der Traffic eingeht

Im Berichtszeitraum war fast ein Drittel des von Cloudflare in Palästina und Aserbaidschan beobachteten Datenverkehrs Teil eines DDoS-Angriffs auf Netzwerkschicht.

Wenn wir versuchen zu verstehen, wo DDoS-Angriffe auf Netzwerkschicht ihren Ursprung haben, können wir nicht dieselbe Methode anwenden wie bei der Analyse von Angriffen auf Anwendungsschicht. Um einen DDoS-Angriff auf Anwendungsschicht zu starten, müssen zur Herstellung einer HTTP/S-Verbindung erfolgreiche Handshakes zwischen dem Client und dem Server stattfinden. Dies ist nur möglich, wenn die Angreifer ihre Ursprungs-IP-Adresse nicht fälschen. Der Angreifer kann seine Identität zwar unter anderem mit Botnets und Proxys verschleiern, aber die Ursprungs-IP-Adresse des angreifenden Clients bildet die Angriffsquelle von DDoS-Angriffen auf Anwendungsschicht in ausreichendem Maße ab.

Andererseits ist für DDoS-Angriffe auf Netzwerkschicht in den meisten Fällen kein Handshake erforderlich. Angreifer können die Usprungs-IP-Adresse fälschen, um die Herkunft des Angriffs zu verschleiern und Zufälligkeit in die Angriffseigenschaften zu bringen. Dies kann es für einfache DDoS-Schutzsysteme schwieriger machen, die Attacke zu blockieren. Würden wir also das Herkunftsland aus einer gefälschten Ursprungs-IP ableiten, kämen wir zu einem falschen Ergebnis.

Aus diesem Grund haben wir bei der Analyse der Quellen von DDoS-Angriffen auf Netzwerkschicht den Datenverkehr nicht nach den (potenziell) gefälschten Usprungs-IPs aufgeschlüsselt, sondern nach den Standorten der Cloudflare-Rechenzentren, bei denen der Datenverkehr eingegangen ist. Da wir über Rechenzentren in über 270 Städten auf der ganzen Welt verfügen, können wir in unserem Bericht eine große geografische Genauigkeit erreichen. Doch selbst diese Methode ist nicht zu 100 % exakt, da der Datenverkehr aus diversen Gründen (von Kosteneinsparungen bis hin zum Überlastungs- und Ausfallmanagement) über verschiedene Internetdienstanbieter und Länder umgeleitet werden kann.

Palästina steigt als Cloudflare-Standort mit dem höchsten Prozentsatz an DDoS-Angriffen auf Netzwerkschicht vom zweiten auf den ersten Platz auf. Dahinter folgen Aserbaidschan, Südkorea und Angola.

Sie möchten sich alle Regionen und Länder ansehen? Benutzen Sie hierzu unsere interaktive Karte.

Angriffsvektoren

DNS-Attacken haben im zweiten Quartal zugenommen und sind zum zweithäufigsten Angriffsvektor aufgestiegen.

Ein Angriffsvektor bezeichnet die für einen DDoS-Angriff eingesetzte Methode, wobei als Kriterien unter anderem das IP-Protokoll, Paketattribute wie TCP-Flags und die Flooding-Methode herangezogen werden.

Im zweiten Quartal handelte es sich bei 56 % aller Angriffe auf Netzwerkschicht um SYN-Floods. Diese sind damit nach wie vor der beliebteste Angriffsvektor. Sie missbrauchen die erste Verbindungsanfrage zur Durchführung des zustandsabhängigen TCP-Handshake. Während dieser ersten Verbindungsanfrage verfügen Server noch über keinen Kontext bezüglich der TCP-Verbindung, da diese neu ist. Ohne den richtigen Schutz kann es ihnen daher schwer fallen, eine Flut von ersten Verbindungsanfragen abzuwehren. Dies macht es dem Angreifer leichter, die Ressourcen eines ungeschützten Servers voll zu beanspruchen.

Hinter den SYN-Floods folgen Angriffe auf die DNS-Infrastruktur, RST-Floods, die wiederum den TCP-Verbindungsfluss missbrauchen, und generische Angriffe über UDP.

Neue Bedrohungen

Angriffe mittels CHARGEN, Ubiquiti und Memcached gehörten im zweiten Quartal zu den wichtigsten neuen Bedrohungen.

Die Identifizierung der wichtigsten Angriffsvektoren erleichtert es Unternehmen, die Bedrohungslandschaft zu verstehen. Dies wiederum kann ihnen helfen, ihr Sicherheitsniveau zu verbessern, um sich vor diesen Bedrohungen zu schützen. Ebenso kann das Wissen um neu aufkommende Bedrohungen, die vielleicht noch keinen großen Teil der Angriffe ausmachen, zu ihrer frühzeitigen Neutralisierung beitragen.

Im zweiten Quartal waren die wichtigsten neuen Bedrohungen Amplification-Angriffe, die das Character Generator Protocol (CHARGEN) missbrauchen, Amplification-Angriffe, die den Datenverkehr von ungeschützten Ubiquiti-Geräten reflektieren, und der berüchtigte Memcached-Angriff.

Missbrauch des CHARGEN-Protokolls zur Durchführung von Amplification-Angriffen

Die Angriffe, bei denen das CHARGEN-Protokoll missbraucht wurde, haben vom ersten auf das zweite Quartal um 378 % zugenommen.

Das ursprünglich in RFC 864 (1983) definierte Character Generator (CHARGEN)-Protokoll ist ein Dienst der Internetprotokollfamilie, der genau das tut, was sein Name besagt: Er generiert willkürlich Zeichen und hört nicht auf, sie an den Client zu senden, bis dieser die Verbindung beendet. Ursprünglich war er zum Testen und Debugging gedacht. Er wird jedoch nur noch selten verwendet, weil er so leicht für Amplification-/Reflection-Angriffe missbraucht werden kann.

Ein Angreifer kann die Ursprungs-IP seines Opfers fälschen und unterstützende Server auf der ganzen Welt täuschen, um einen Strom beliebiger Zeichen „zurück“ zu den Servern des Opfers zu leiten. Es handelt sich hierbei um einen Amplification/Reflection-Angriff. Bei einer ausreichenden Anzahl gleichzeitiger CHARGEN-Ströme würden die Server des Opfers, wenn sie ungeschützt sind, überflutet. Sie wären dann nicht mehr in der Lage, den legitimen Datenverkehr zu bewältigen – was zu einem Denial-of-Service-Ereignis führen würde.

Amplification-Angriffe, die das Ubiquiti Discovery-Protokoll ausnutzen

Im zweiten Jahresviertel haben die Angriffe über Ubiquity im Quartalsvergleich um 313 % zugelegt.

Ubiquiti ist ein US-amerikanisches Unternehmen, das Netzwerk- und IoT (Internet of Things)-Geräte für Verbraucher und Unternehmen anbietet. Ubiquiti-Geräte können mit dem Ubiquiti Discovery-Protokoll über UDP/TCP-Port 10001 in einem Netzwerk ermittelt werden.

Ähnlich wie beim CHARGEN-Angriffsvektor können Angreifer auch hier die Ursprungs-IP-Adresse durch die IP-Adresse des Opfers ersetzen und Anfragen an IP-Adressen mit offenem Port 10001 verteilen. Diese würden dann auf das Opfer reagieren und es bei ausreichendem Volumen im Prinzip mit Daten überschwemmen.

Memcached-DDoS-Angriffe

Im zweiten Quartal wurden 281 % mehr DDoS-Angriffe über Memcached verzeichnet als in den vorangegangenen drei Monaten.

Memcached ist ein Datenbank-Caching-System zur Beschleunigung von Websites und Netzwerken. Ähnlich wie CHARGEN und Ubiquiti können Memcached-Server, die UDP unterstützen, für Amplification/Reflection-DDoS-Angriffe missbraucht werden. In diesem Fall würde der Angreifer Inhalte vom Caching-System anfordern und die IP-Adresse des Opfers als Ursprungs-IP in den UDP-Paketen eintragen. Das Opfer wird mit den Memcache-Antworten bombardiert, die um einen Faktor von bis zu 51.200 verstärkt werden können.

DDoS-Angriffe auf Netzwerkschicht aufgeschlüsselt nach Angriffsrate

Volumetrische Angriffe mit über 100 Gbit/s sind um 19 % gegenüber dem Vorquartal gestiegen. Attacken mit einer Dauer von mehr als drei Stunden haben um 9 % zugenommen.

Es gibt verschiedene Möglichkeiten, die Größe eines L3/4-DDoS-Angriffs zu messen. So kann man sich das Volumen des damit einhergehenden Traffics ansehen, das als Bitrate ausgedrückt wird. Diese wird in Terabit pro Sekunde oder Gigabit pro Sekunde angegeben. Ein anderer Messwert ist die Anzahl der übermittelten Datenpakete. Diese sogenannte Paketrate wird in Millionen Paketen pro Sekunde angegeben.

Angriffe mit hohen Bitraten zielen darauf ab, die Internetverbindung zu belegen, sodass es zu einer „Denial of Service“ (Nichtverfügbarkeit) kommt. Mit hohen Paketraten dagegen wird versucht, die Server, Router oder andere Hardwaregeräte innerhalb des Netzwerkpfads durch Überlastung lahmzulegen. Diese Geräte wenden eine bestimmte Speicher- und Rechenleistung zur Verarbeitung eines Datenpakets auf. Werden sie daher mit Paketen regelrecht überschwemmt, sind ihre Verarbeitungskapazitäten unter Umständen irgendwann erschöpft. In einem solchen Fall werden Pakete „verworfen“ – mit anderen Worten: Die Appliance ist nicht in der Lage, sie zu verarbeiten. Für Nutzer hat das zur Folge, dass die von ihnen angesteuerten Dienste nicht richtig funktionieren oder nicht mehr verfügbar sind.

Aufschlüsselung nach Paketrate

Die Mehrheit der DDoS-Angriffe auf Netzwerkschicht bleibt unter 50.000 Paketen pro Sekunde. 50.000 Pakete pro Sekunde sind bei der Dimension des Cloudflare-Netzwerks eher am unteren Ende des Spektrums angesiedelt. Dennoch können damit leicht Ausfälle ungeschützter Websites verursacht und sogar Standard-Gigabit-Ethernet-Verbindungen überlastet werden.

Wenn wir uns die Veränderungen bei den Angriffsgrößen ansehen, ist festzustellen, dass paketintensive Angriffe mit mehr als 50.000 Paketen pro Sekunde in zweiten Jahresviertel zurückgegangen sind, während kleine Angriffe um 4 % zugelegt haben.

Aufschlüsselung nach Bitrate

Die Mehrheit der DDoS-Angriffe auf Netzwerkschicht blieben im zweiten Quartal unter 500 Mbit/s. Bei der Größe des Cloudflare-Netzwerks ist auch dies zu vernachlässigen. Dennoch können solche Attacken ungeschützte Websites mit weniger Kapazität sehr schnell lahmlegen oder zumindest eine Standard-Gigabit-Ethernet-Verbindung überlasten.

Interessanterweise sind große Angriffe mit einem Umfang zwischen 500 Mbit/s und 100 Gbit/s im Quartalsvergleich um 20–40 % zurückgegangen, während volumetrische Attacken mit mehr als 100 Gbit/s um 8 % zugenommen haben.

DDoS-Angriffe auf Netzwerkschicht aufgeschlüsselt nach Dauer

Im zweiten Quartal sind Angriffe mit einer Dauer von mehr als drei Stunden um 9 % gestiegen.

Zur Ermittlung der Dauer eines Angriffs wird die Zeit zwischen dem Moment, in dem er von unseren Systemen erstmals als solcher erkannt wird, und dem Augenblick, in dem wir das letzte Paket mit der Signatur dieser Attacke auf dieses konkrete Ziel registrieren, gemessen.

Im Berichtszeitraum dauerten 51 % der DDoS-Angriffe auf Netzwerkschicht weniger als 10 Minuten. Weitere 41 % dauerten 10–20 Minuten. Die verbleibenden 8 % umfassen Angriffe, die zwischen 20 Minuten und mehr als drei Stunden dauern.

Es ist wichtig, zu bedenken, dass die Auswirkungen eines erfolgreichen Angriffs weit über seine eigentliche Dauer – die möglicherweise nur ein paar Minuten beträgt – hinausgehen können. IT-Mitarbeitende, die auf einen erfolgreichen Angriff reagieren, müssen unter Umständen Stunden oder sogar Tage investieren, um Dienste wieder in Betrieb zu setzen.

Die meisten Angriffe sind zwar in der Tat nach kurzer Zeit wieder vorbei, doch es war ein Anstieg um über 15 % bei Attacken mit einer Dauer von 20–60 Minuten und um 12 % bei Angriffen mit einer Dauer von mehr als drei Stunden festzustellen.

Kurze Attacken bleiben leicht unbemerkt, insbesondere solche, die ein Ziel für wenige Sekunden mit einer großen Zahl an Paketen, Bytes oder Anfragen bombardieren. In diesen Fällen haben Abwehrlösungen, die auf einer manuellen Bekämpfung mittels Sicherheitsanalyse beruhen, keine Chance, den Angriff rechtzeitig zu unterbinden. Es bleibt dann nur die Möglichkeit, ihn im Nachhinein zu untersuchen und auf Grundlage der dabei gewonnenen Erkenntnisse eine neue Regel zu erstellen, anhand derer der Traffic anschließend auf das Angriffsprofil hin gefiltert werden kann. Dann besteht zumindest eine gewisse Hoffnung, dass die nächste Attacke erkannt wird. Ebenso wenig zielführend ist der Einsatz eines „On Demand“-Services, bei denen das Sicherheitsteam den Datenverkehr während eines Angriffs zu einem DDoS-Dienst umleitet. Denn in diesen Fällen ist die Attacke vorüber, bevor der Traffic dort ankommt.

Unternehmen wird die Verwendung automatisch funktionierender und ständig aktiver DDoS-Schutzdienste empfohlen. Diese analysieren den Datenverkehr und wenden in Echtzeit Fingerprinting an, wodurch sie schnell genug sind, um auch kurze Angriffe zu blockieren.

Zusammenfassung

Cloudflare hat es sich zur Aufgabe gemacht, ein besseres Internet zu schaffen. Das bedeutet ein sichereres, schnelleres und zuverlässigeres Web für alle – auch bei DDoS-Angriffen. Deshalb bieten wir seit 2017 allen unseren Kunden zeitlich unbeschränkten und unbegrenzten DDoS-Schutz gratis an. Im Lauf der Jahre ist es immer einfacher geworden, DDoS-Angriffe durchzuführen. Wir wollen aus diesem Grund sicherstellen, dass es für Unternehmen gleich welcher Größe noch einfacher und kostenlos ist, sich vor DDoS-Angriffen aller Art zu schützen.
Sie nutzen Cloudflare noch nicht? Dann starten Sie jetzt mit unseren Free- und Pro-Tarifen zum Schutz Ihrer Websites oder kontaktieren Sie uns für umfassenden DDoS-Schutz für Ihr gesamtes Netzwerk mit Magic Transit.

Tendances en matière d’attaques DDoS au deuxième trimestre 2022

2022-07-06 Omer Yoachimik

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

Tendances en matière d'attaques DDoS au deuxième trimestre 2022

Bienvenue dans notre rapport consacré aux attaques DDoS survenues lors du deuxième trimestre 2022. Ce document présente des tendances et des statistiques relatives au panorama des menaces DDoS, telles qu’observées sur le réseau mondial de Cloudflare. Une version interactive de ce rapport est également disponible sur Radar.

Au cours du deuxième trimestre, nous avons observé certaines des plus vastes attaques jamais enregistrées, notamment une attaque DDoS HTTPS de 26 millions de requêtes par seconde, automatiquement détectée et atténuée par nos soins. Nous avons également constaté la poursuite des attaques contre l’Ukraine et la Russie, de même que l’émergence d’une nouvelle campagne d’attaques DDoS avec demande de rançon.

Points clés

Le réseau Internet russe et ukrainien

La guerre au sol s’accompagne d’attaques ciblant la diffusion des informations.
Les entreprises du secteur audiovisuel ukrainien ont été les plus visées par les attaques DDoS au deuxième trimestre. Pour tout dire, les six secteurs les plus attaqués se situent tous dans le domaine des médias en ligne/Internet, de la publication et de l’audiovisuel.
À l’inverse, en Russie, les médias en ligne reculent de secteur le plus attaqué à la troisième place. Les entreprises du secteur de la banque, des assurances et des services financiers (BFSI, Banking, Financial Services and Insurance) russe se sont frayées un chemin vers la première place et ont été les plus attaquées au deuxième trimestre. Près de 50 % de l’ensemble des attaques DDoS sur la couche applicative ont ainsi visé le secteur des BFSI. Les entreprises russes du secteur des cryptomonnaies décrochent la deuxième place.

En savoir plus sur les mesures prises par Cloudflare pour maintenir la circulation des informations de l’Internet ouvert vers la Russie et empêcher les attaques de sortir de ce dernier.

Attaques DDoS avec demande de rançon

Nous avons observé une nouvelles vague d’attaques DDoS avec demande de rançon provenant d’entités se revendiquant du groupe Fancy Lazarus.
En juin 2022, les attaques DDoS avec demande de rançon ont atteint leur point culminant de l’année jusqu’ici : une personne interrogée sur cinq parmi celles qui affirment avoir subi une attaque DDoS ont signalé avoir fait les frais d’une attaque DDoS ou d’autres menaces accompagnées d’une demande de rançon
Au total, le pourcentage d’attaques DDoS avec demande de rançon a augmenté de 11 % au deuxième trimestre, par rapport au trimestre précédent.

Attaques DDoS sur la couche applicative

En 2022, les attaques DDoS sur la couche applicative ont augmenté de 44 % par rapport à l’année précédente.
Les entreprises établies aux États-Unis ont été les plus touchées, suivies par celles situées à Chypre, à Hong Kong et en Chine. Les attaques visant les entreprises basées à Chypre ont augmenté de 171 % par rapport au trimestre précédent.
Le secteur de l’aéronautique et de l’aérospatiale a été le plus visé au deuxième trimestre, suivi par les secteurs de l’Internet, des BFSI (banque, assurances et services financiers) et le secteur des jeux/jeux de hasard, qui se place en quatrième position

Attaques DDoS sur la couche réseau

En 2022, les attaques DDoS sur la couche réseau ont augmenté de 75% par rapport à l’année précédente. Les attaques de 100 Gb/s et plus ont augmenté de 19 % par rapport au trimestre précédent et les attaques d’une durée supérieure à 3 heures de 9 % sur la même période.
Les secteurs les plus touchés ont été ceux des télécommunications, des jeux/jeux de hasard, ainsi que celui des services et technologies de l’information.
Les entreprises situées aux États-Unis ont été les plus visées, suivies par celles basées à Singapour, en Allemagne et en Chine.

Ce rapport concerne les attaques DDoS automatiquement détectées et atténuées par les systèmes de protection contre les attaques DDoS de Cloudflare. Pour en apprendre plus sur leur fonctionnement, consultez cet article de blog détaillé.

Remarque concernant la manière dont nous mesurons les attaques DDoS observées sur notre réseau

Pour analyser les tendances en matière d’attaques, nous calculons le taux d’« activité DDoS », qui correspond au pourcentage de trafic hostile par rapport au trafic total (hostile et légitime) observé sur notre réseau mondial, dans un emplacement spécifique ou au sein d’une catégorie spécifique (p. ex. le secteur ou le pays de facturation). La mesure de ces pourcentages nous permet de normaliser les points de données et d’éviter les biais résultant de l’utilisation de chiffres absolus (par exemple, envers un datacenter Cloudflare qui reçoit un trafic plus important et connaît donc plus d’attaques).

Attaques avec demande de rançon

Nos systèmes analysent le trafic en permanence et déploient des mesures d’atténuation de manière automatique lorsque des attaques DDoS sont détectées. Nous invitons chaque client ayant subi une attaque DDoS à répondre à une enquête automatisée afin de nous aider à mieux comprendre la nature de l’attaque et le degré de réussite de l’atténuation.

Depuis plus de deux ans désormais, Cloudflare interroge les clients victimes d’attaques. Nous leur demandons notamment s’ils ont reçu des menaces ou une demande de rançon exigeant un paiement en échange de la promesse d’arrêter l’attaque DDoS en cours ou de ne pas lancer d’attaque DDoS.

Le nombre de personnes interrogées ayant signalé des demandes de rançon ou des menaces accompagnées d’une demande de rançon au deuxième trimestre a augmenté de 11 % par rapport à l’année et au trimestre précédents. Au cours du trimestre, nous avons atténué des attaques DDoS avec demande de rançon lancées par des entités prétendant appartenir au groupe de menaces persistantes avancées (Advanced Persistent Threat, APT) « Fancy Lazarus ». La campagne se concentre sur les institutions financières et les entreprises du secteur des cryptomonnaies.

L’analyse plus approfondie du deuxième trimestre montre qu’au mois de juin, une personne interrogée sur cinq a signalé avoir été menacée ou avoir fait les frais d’une attaque DDoS avec demande de rançon, une proportion qui fait du mois de juin le mois affichant le taux le plus élevé de signalements en la matière de l’année 2022, avec un niveau inégalé depuis décembre 2021.

Attaques DDoS sur la couche applicative

Les attaques DDoS sur la couche applicative (et plus spécifiquement les attaques DDoS HTTP) cherchent généralement à perturber le fonctionnement d’un serveur web en le rendant incapable de traiter les requêtes des utilisateurs légitimes. Si un serveur se trouve bombardé par plus de requêtes qu’il ne peut en gérer, il abandonne les requêtes légitimes et peut même finir dans certains cas par s’arrêter totalement, en entraînant ainsi une dégradation des performances ou une défaillance pour les utilisateurs légitimes.

Attaques DDoS sur la couche applicative, répartition mensuelle

Au deuxième trimestre, les attaques DDoS sur la couche applicative ont augmenté de 44 % par rapport à l’année précédente.

Au total, le volume d’attaques DDoS sur la couche applicative observé lors du deuxième trimestre a augmenté de 44 % par rapport à l’année précédente, mais a diminué de 16 % par rapport au trimestre précédent. Le mois de mai s’est avéré le plus actif du trimestre. Près de 47 % de l’ensemble des attaques DDoS sur la couche applicative ont eu lieu en mai, tandis que le mois de juin a connu le plus petit nombre d’attaques (18 %).

Attaques DDoS sur la couche applicative, répartition par secteur

Les attaques visant le secteur de l’aéronautique et de l’aérospatiale ont augmenté de 256 % par rapport au trimestre précédent.

Le secteur de l’aéronautique et de l’aérospatiale s’est révélé le plus visé par les attaques DDoS sur la couche applicative au deuxième trimestre. Il est suivi par celui de la banque, des assurances et des services financiers (BFSI), ainsi que le secteur des jeux/jeux de hasard, qui se positionne à la troisième place.

Le cyberespace russe et ukrainien

Les entreprises du secteur des médias et de la publication sont les plus visées en Ukraine.

Tandis que la guerre en Ukraine continue au sol, dans les airs et sur l’eau, elle se poursuit également dans le cyberespace. Les entités qui s’en prennent aux entreprises ukrainiennes semblent essayer de bâillonner l’information. Les six secteurs les plus attaqués en Ukraine se situent tous dans le domaine de l’audiovisuel, d’Internet, des médis en ligne et de la publication. Ces derniers totalisent près de 80 % de l’ensemble des attaques DDoS sévissant sur le territoire.

Dans le camp opposé (côté russe donc), ce sont les entreprises du secteur de la banque, des assurances et des services financiers (BFSI) qui ont connu le plus d’attaques. Près de 50 % de l’ensemble des attaques DDoS ont ainsi visé le secteur des BFSI. Le deuxième secteur le plus touché a été celui des cryptomonnaies, suivi du secteur des médias en ligne.

On constate que les attaques font preuve d’une forte distribution géographique dans les deux camps belligérants, un fait qui indique ainsi l’utilisation de botnets répartis sur l’ensemble du monde.

Attaques DDoS sur la couche applicative, répartition par pays d’origine

Les attaques provenant de Chine ont augmenté de 112 % au deuxième trimestre, tandis que les attaques issues des États-Unis ont diminué de 43 %.

Pour connaître l’origine des attaques HTTP, nous examinons la géolocalisation de l’adresse IP source du client à l’initiative des requêtes composant l’attaque HTTP. Contrairement aux attaques sur la couche réseau, les adresses IP ne peuvent pas être usurpées lors d’une attaque HTTP. Un pourcentage d’activité DDoS élevé dans un pays donné n’indique pas que ce dernier constitue la source des attaques, mais révèle plutôt la présence de botnets au sein de ce dernier.

Pour le deuxième trimestre consécutif, les États-Unis maintiennent leur première place en tant que source principale des attaques DDoS HTTP. La Chine détient la deuxième place après les États-Unis, tandis que l’Inde et l’Allemagne se placent respectivement en troisième et quatrième position. Même si les États-Unis ont conservé la première place, les attaques originaires de ce pays ont diminué de 43 % par rapport au trimestre précédent, tandis que les attaques issues d’autres régions sont en hausse. Les attaques en provenance de Chine ont ainsi augmenté de 112 %, les attaques originaires d’Inde de 89 % et les attaques lancées depuis l’Allemagne de 50 %.

Attaques DDoS sur la couche applicative, répartition par pays cible

Afin d’identifier les pays ciblés par le plus grand nombre d’attaques DDoS HTTP, nous décomposons l’activité des attaques DDoS en fonction du pays de facturation de nos clients et la représentons sous forme de pourcentage de l’ensemble des attaques DDoS.

Les attaques DDoS HTTP visant des entreprises situées aux États-Unis ont augmenté de 45 % par rapport au trimestre précédent. Ce chiffre replace ainsi les États-Unis à la première position en tant que source principale des attaques sur la couche applicative. Les attaques visant des entreprises chinoises ont baissé de 79 % par rapport au trimestre précédent, faisant ainsi chuter le pays de la première à la quatrième place; Les attaques sur les entreprises chypriotes ont connu une augmentation de 171 % et positionnent ainsi le pays à la deuxième place des pays les plus attaqués au deuxième trimestre. Après Chypre viennent ensuite Hong Kong, la Chine et la Pologne.

Attaques DDoS sur la couche réseau

Si les attaques au niveau de la couche applicative prennent pour cible l’application (la couche 7 du modèle OSI) exécutant le service auquel les utilisateurs finaux tentent d’accéder (HTTP/S dans notre cas), les attaques sur la couche réseau cherchent à surcharger l’infrastructure réseau (comme les routeurs et les serveurs internes), ainsi que la liaison Internet elle-même.

Attaques DDoS sur la couche réseau, répartition mensuelle

Au deuxième trimestre, les attaques DDoS sur la couche réseau ont augmenté de 75% par rapport à l’année précédente. De même, les attaques volumétriques de 100 Gb/s et plus ont augmenté de 19 % par rapport au trimestre précédent

Si le nombre total d’attaques DDoS sur la couche réseau observé lors du deuxième trimestre a augmenté de 75% par rapport à l’année précédente, il a néanmoins peu varié par rapport au trimestre précédent. Le mois d’avril s’est révélé le plus actif du trimestre, avec près de 40 % des attaques.

Attaques DDoS sur la couche réseau, répartition par secteur

Au deuxième trimestre, les attaques sur les entreprises de télécommunications ont augmenté de 45 % par rapport au trimestre précédent.

Pour le deuxième trimestre consécutif, le secteur des télécommunications a été le plus touché par les attaques DDoS sur la couche réseau. Les attaques sur les entreprises de télécommunications ont ainsi augmenté de 45 % par rapport au trimestre précédent. Le secteur des jeux arrive en deuxième place, suivi par celui des services et technologies de l’information

Attaques DDoS sur la couche réseau, répartition par pays cible

Les attaques sur les réseaux situés aux États-Unis ont augmenté de 70 % par rapport au trimestre précédent.

Les États-Unis demeurent le pays le plus attaqué au deuxième trimestre. Ils sont suivis de Singapour, qui se retrouve en seconde place après avoir occupé la quatrième lors du trimestre précédent. La troisième place est détenue par l’Allemagne, elle-même suivie par la Chine, les Maldives et la Corée du Sud.

Attaques DDoS sur la couche réseau, répartition par pays source de trafic entrant

Lors du deuxième trimestre, près d’un tiers du trafic observé par Cloudflare en Palestine et en Azerbaïdjan faisait partie d’une attaque DDoS sur la couche réseau.

Lorsque nous essayons de comprendre d’où les attaques DDoS sur la couche réseau proviennent, nous ne pouvons utiliser la même méthode que celle que nous employons pour l’analyse des attaques sur la couche applicative. Le lancement d’une attaque DDoS sur la couche applicative nécessite la réussite de certaines négociations entre le client et le serveur afin d’établir une connexion HTTP/S. Pour qu’une négociation puisse réussir, les attaques ne peuvent pas usurper leur adresse IP source. Si l’auteur de l’attaque peut tirer parti de botnets, de services de proxy et d’autres méthodes de dissimulation de son identité, l’emplacement de l’adresse IP source du client à l’origine de l’attaque représente avec suffisamment de précision la source des attaques DDoS sur la couche applicative.

D’un autre côté, le lancement d’attaques DDoS sur la couche réseau ne nécessite, dans la plupart des cas, aucune négociation. Les acteurs malveillants peuvent tout à fait usurper l’adresse IP source pour dissimuler la source de l’attaque et introduire un caractère aléatoire dans les propriétés de cette dernière. Le blocage des attaques par les systèmes de protection contre les attaques DDoS simples s’en trouve donc plus difficile. Par conséquent, si nous cherchons à déterminer le pays d’origine en nous fondant sur une adresse IP source usurpée, le résultat aboutira sur un pays usurpé.

C’est pour cette raison que lorsque nous analysons les sources des attaques DDoS sur la couche réseau, nous classons le trafic en fonction de l’emplacement des datacenters Cloudflare dans lequel le trafic a été ingéré et non de l’adresse IP (potentiellement) usurpée pour déterminer de quel endroit les attaques proviennent. Nous sommes en mesure de garantir la précision géographique de notre rapport dans la mesure où nous possédons des datacenters répartis dans plus de 270 villes à travers le monde. Toutefois, cette méthode n’est pas précise à 100 %, car le trafic peut faire l’objet d’une redirection (backhauling) et d’un routage via divers fournisseurs d’accès Internet et pays pour des raisons variables, qui vont de la réduction des coûts à la gestion des encombrements et des défaillances.

La Palestine passe de la seconde à la première place en tant que point d’implantation Cloudflare affichant le plus haut pourcentage d’attaques DDoS sur la couche réseau. L’Azerbaïdjan, la Corée du Sud et l’Angola lui emboîtent le pas.

Pour visualiser toutes les régions et tous les pays, consultez la carte interactive.

Vecteurs d’attaque

Les attaques DNS ont augmenté au deuxième trimestre, pour devenir le deuxième vecteur d’attaque le plus fréquent.

Le terme « vecteur d’attaque » désigne la méthode utilisée par le pirate pour lancer son attaque DDoS, c’est-à-dire le protocole IP, les attributs de paquets (comme les indicateurs TCP) et la méthode de saturation, parmi bien d’autres critères.

Lors du deuxième trimestre, 56 % de l’ensemble des attaques sur la couche réseau se composaient d’attaques de type SYN flood. Les SYN floods demeurent ainsi le vecteur d’attaque le plus populaire. Elles s’en prennent à la requête de connexion initiale de la négociation TCP avec état. Les serveurs ne disposent d’aucun contexte sur la connexion TCP pendant cette requête, car la connexion est en cours de création. Laissés sans protection, les serveurs peuvent ainsi éprouver des difficultés à atténuer un flood de requêtes de connexion initiale. Cette situation peut faciliter la consommation des ressources non protégées d’un serveur par un acteur malveillant.

Après les SYN floods viennent les attaques visant l’architecture DNS, les RST floods (qui s’attaquent eux aussi au processus de connexion TCP) et les attaques génériques via UDP.

Menaces émergentes

Les attaques lancées via CHARGEN, Ubiquiti et Memcached sont entrées au palmarès des principales menaces émergentes au deuxième trimestre.

L’identification des principaux vecteurs d’attaque permet aux entreprises de mieux comprendre le panorama des menaces. Cette opération peut également les aider à améliorer leur stratégie de sécurité afin de se protéger contre ces menaces. De même, si les nouvelles menaces émergentes ne constituent pas encore une partie substantielle des attaques, en apprendre plus à leur sujet peut contribuer à les atténuer avant qu’elles ne deviennent une force avec laquelle compter.

Au deuxième trimestre, les principales menaces émergentes comprenant les attaques par amplification abusant du protocole Character Generator (CHARGEN), les attaques par amplification réfléchissant le trafic destiné aux appareils Ubiquiti exposés et la tristement célèbre attaque Memcached.

Abuser du protocole CHARGEN pour lancer des attaques par amplification

Au deuxième trimestre, les attaques par amplification abusant du protocole CHARGEN ont augmenté de 378 % par rapport au trimestre précédent.

Initialement défini au sein de la RFC 864 (1983), le protocole Character Generator (CHARGEN) constitue un service de la suite de protocoles Internet. Il permet d’effectuer exactement ce que son nom indique, à savoir, générer des caractères de manière arbitraire et les envoyer en continu au client jusqu’à ce que ce dernier mette fin à la connexion. Développé à l’origine à des fins de tests et de débogage, il est rarement utilisé de nos jours, en raison de la facilité avec laquelle les attaques par amplification/réflexion peuvent en abuser.

Un acteur malveillant peut usurper l’adresse IP source de sa victime et tromper les serveurs de soutien implantés dans le monde entier afin qu’ils dirigent un flux de caractères arbitraires « en retour » vers les serveurs de la victime. Ce type d’attaque est désigné sous le nom d’attaque par amplification/réflexion. En présence d’un nombre suffisant de flux CHARGEN, les serveurs de la victime laissés sans protection se verraient submergés et incapables de faire face au trafic légitime. Cette situation entraînerait ainsi un événement de déni de service.

Attaques par amplification exploitant le protocole de découverte Ubiquiti

Au deuxième trimestre, les attaques lancées via Ubiquiti ont augmenté de 313 % par rapport au trimestre précédent.

Ubiquiti est une entreprise basée aux États-Unis. Elle fournit des services réseau et des appareils IdO (Internet des objets) aux consommateurs et aux entreprises. Les appareils Ubiquiti peuvent être identifiés sur un réseau à l’aide du protocole de découverte Ubiquiti, via le port UDP/TCP 10001.

Tout comme avec le vecteur d’attaque CHARGEN, les acteurs malveillants peuvent, là aussi, usurper l’adresse IP source afin qu’elle corresponde à l’adresse IP de la victime et ainsi affecter toutes les adresses IP dont le port 10001 est ouvert. Ces adresses répondent alors à la victime, qui se retrouve submergée une fois le volume suffisant atteint.

Attaque DDoS memcached

Au deuxième trimestre, les attaques DDoS Memcached ont augmenté de 281 % par rapport au trimestre précédent.

Memcached est un système de mise en cache de base de données conçu pour accélérer les sites web et les réseaux. Comme pour CHARGEN et Ubiquiti, les serveurs Memcached prenant en charge UDP peuvent être utilisés de manière abusive afin de lancer des attaques DDoS par amplification/réflexion. Dans ce cas précis, le pirate demande du contenu au système de mise en cache et usurpe l’adresse IP de la victime afin de l’utiliser en tant qu’IP source dans les paquets UDP. La victime est alors submergée sous les réponses Memcache, qui peuvent être amplifiées d’un facteur pouvant atteindre × 51 200.

Attaques DDoS sur la couche réseau, répartition par débit d’attaque

Les attaques volumétriques supérieures à 100 Gb/s ont augmenté de 19 % par rapport au trimestre précédent et les attaques d’une durée supérieure à 3 heures de 9 % sur la même période.

Il existe diverses manières de mesurer la taille d’une attaque DDoS sur la couche 3/4. L’une d’entre elles s’attache à son volume de trafic, mesuré en débit binaire (plus exactement, en térabits ou en gigabits par seconde). Une autre s’intéresse au nombre de paquets transmis, mesuré en termes de débit de paquets (plus spécifiquement, en millions de paquets par seconde).

Les attaques à haut débit binaire tentent de provoquer un événement de déni de service en encombrant la liaison Internet, tandis que les attaques à débit de paquets élevé essaient de surcharger les serveurs, les routeurs et les autres équipements physiques en ligne. Ces appareils consacrent une certaine quantité de mémoire et de puissance de calcul au traitement de chaque paquet. Par conséquent, lorsqu’il se trouve bombardé sous une multitude de paquets, l’appareil peut venir à manquer de ressources de traitement. Les paquets sont alors « abandonnés », c’est-à-dire que l’appareil se déclare incapable de les traiter. Pour les utilisateurs, ce constat se traduit par un événement de déni de service.

Répartition par débit de paquets

La majeure partie des attaques DDoS sur la couche réseau demeurent sous le seuil des 50 000 paquets par seconde. Si ce chiffre de 50 000 paquets par seconde se situe plutôt au bas de l’échelle du point de vue de Cloudflare, une telle attaque reste tout à fait capable d’abattre les propriétés Internet sans protection et d’entraîner des encombrements, même sur une connexion Gigabit Ethernet standard.

L’examen des changements au niveau de la taille des attaques nous permet de constater que les attaques volumineuses en termes de paquets (supérieures à 50 000 p/s) ont diminué au deuxième trimestre. Les attaques de petite taille n’ont ainsi augmenté que de 4 %.

Répartition en fonction du débit binaire

Au deuxième trimestre, la majorité des attaques DDoS sur la couche réseau sont restées sous le seuil des 500 Mb/s. S’il s’agit là aussi d’une goutte d’eau à l’échelle de Cloudflare, ces attaques demeurent capables de forcer très rapidement la mise hors ligne des propriétés Internet de moindre capacité laissées sans protection ou, au minimum, d’entraîner des encombrements, même sur une connexion Gigabit Ethernet standard.

Il est intéressant de noter que les attaques de grande capacité (entre 500 Mb/s et 100 Gb/s) ont diminué de 20 à 40 % par rapport au trimestre précédent, mais que les attaques volumétriques supérieures à 100 Gb/s ont augmenté de 8 %.

Attaques DDoS sur la couche réseau, répartition par durée

Les attaques d’une durée supérieure à 3 heures ont augmenté de 9 % au deuxième trimestre.

Nous mesurons la durée d’une attaque en enregistrant la différence entre l’instant auquel nos systèmes la détectent pour la première fois en tant qu’attaque et le dernier paquet porteur de cette signature d’attaque que nous observons en direction de cette cible spécifique.

Au cours du deuxième trimestre, 51 % des attaques DDoS sur la couche réseau ont duré moins de dix minutes. Les 41 % suivants ont duré entre 10 et 20 minutes. Les 8 % restants regroupent les attaques d’une durée comprise entre 20 minutes et plus de 3 heures.

L’un des éléments importants à garder à l’esprit repose sur le fait que si une attaque ne dure que quelques minutes, ses répercussions en cas de réussite peuvent durer bien plus longtemps que la période d’attaque initiale. Les membres des équipes informatiques qui répondent à une attaque réussie peuvent tout à fait passer des heures, voire des jours, à restaurer les services.

Si la plupart des attaques se révèlent en effet de courte durée, nous pouvons constater une augmentation de plus de 15 % des attaques comprises entre 20 et 60 minutes, ainsi qu’une augmentation de 12 % des attaques de plus de trois heures.

Les attaques de courte durée peuvent facilement passer inaperçues, notamment les attaques en rafale, qui bombardent une cible d’un nombre important de paquets, d’octets ou de requêtes en l’espace de quelques secondes. Dans ce cas précis, les services de protection contre les attaques DDoS qui reposent sur l’atténuation manuelle en fonction d’une analyse de sécurité n’ont aucune chance d’atténuer l’attaque à temps. Ils ne peuvent qu’en tirer des enseignements lors de l’analyse post-attaque, avant de déployer une nouvelle règle permettant de filtrer les empreintes numériques de l’attaque et d’espérer la repérer la prochaine fois. Dans le même esprit, l’utilisation d’un service « à la demande » (dans lequel l’équipe de sécurité redirige le trafic vers un fournisseur de services pendant l’attaque) se révèle également inefficace, car l’attaque sera déjà terminée avant la redirection du trafic vers le fournisseur de services anti-DDoS à la demande.

Nous recommandons aux entreprises d’avoir recours à des services de protection contre les attaques DDoS automatisés et actifs en permanence, capables d’analyser le trafic et de relever les empreintes numériques suffisamment vite pour bloquer les attaques de courte durée.

Résumé

Cloudflare s’est donné pour mission de construire un Internet meilleur, c’est-à-dire un Internet plus sécurisé, plus rapide et plus fiable pour chacun, même en cas d’attaques DDoS. Dans le cadre de notre mission, nous proposons gratuitement à tous nos clients une protection contre les attaques DDoS illimitée et sans surcoût lié à l’utilisation, et ce depuis 2017. Au fil des ans, il est devenu de plus en plus facile pour les pirates de lancer des attaques DDoS. Toutefois, malgré la simplicité de mise en œuvre de ces dernières, nous souhaitons nous assurer qu’il soit tout aussi facile et gratuit pour les entreprises de toutes les tailles de se protéger contre les attaques DDoS de tous types.
Vous n’utilisez pas encore Cloudflare ? Commencez dès maintenant à protéger vos sites web avec nos offres gratuite et Pro ou contactez-nous pour bénéficier d’une protection contre les attaques DDoS complète sur l’ensemble de votre réseau grâce à 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攻撃対策に関してお問い合わせください。

1947 Georgia Three Governors Crisis

2022-07-06 The History Guy: History Deserves to Be Remembered

Post Syndicated from The History Guy: History Deserves to Be Remembered original https://www.youtube.com/watch?v=aYHPbT8sAqM

Nikon’s Done it Again! 🤯 Firmware 2.1 is here

2022-07-06 Matt Granger

Post Syndicated from Matt Granger original https://www.youtube.com/watch?v=_-5tt6LqZq4

Meta-Alternating Current

2022-07-06

Post Syndicated from original https://xkcd.com/2642/

It's always bothered me that you can't cancel out an inverter by putting a second inverter after it.

2022 H1 IRAP report is now available on AWS Artifact

2022-07-06 Matt Brunker

Post Syndicated from Matt Brunker original https://aws.amazon.com/blogs/security/2022-h1-irap-report-is-now-available-on-aws-artifact/

We’re excited to announce that a new Information Security Registered Assessors Program (IRAP) report is now available on AWS Artifact. Amazon Web Services (AWS) successfully completed an IRAP assessment in May 2022 by an independent ASD (Australian Signals Directorate) certified IRAP assessor. The new IRAP report includes an additional nine AWS services that are now assessed at the PROTECTED classification under IRAP. This brings the total number of services assessed at PROTECTED to 132.

For a full list of these services, see the IRAP tab on the AWS Services in Scope page. The following services are the nine newly assessed services:

The IRAP documentation pack is developed in accordance with the Australian Cyber Security Centre (ACSC) Cloud Security Guidance and their Anatomy of a Cloud Assessment and Authorisation framework, which addresses guidance within the Australian Government Information Security Manual (ISM), the Attorney-General’s Protective Security Policy Framework (PSPF), and the Digital Transformation Agency (DTA) Secure Cloud Strategy.

The IRAP package on AWS Artifact also includes the AWS Consumer Guide and the whitepaper Reference Architectures for ISM PROTECTED Workloads in the AWS Cloud.

The IRAP documentation pack is developed to assist Australian government agencies and their partners to plan, architect, and assess risk for their workloads when they use AWS Cloud services. Reach out to your AWS representatives to let us know which additional services you would like to see in scope for upcoming IRAP assessments. We strive to bring more services into scope at the PROTECTED level to support your requirements.

If you have feedback about this post, submit comments in the Comments section below.

Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.

[$] An Ubuntu kernel bug causes container crashes

2022-07-05

Post Syndicated from original https://lwn.net/Articles/899420/

Some system administrators running Ubuntu 20.04 had a rough time on
June 8, when Ubuntu published kernel packages containing a particularly
nasty bug that was caused by an Ubuntu-specific
patch to the kernel. The bug led to a kernel panic whenever a Docker container
was started. Fixed packages were made available on June 10, but there
are questions about what went wrong
with handling the patch; in particular, it is surprising that kernel 5.13,
which has been beyond its end-of-life
for months, made it onto machines running Ubuntu 20.04, which is supposed
to be a long-term support release.

Configuring low latency connectivity between AWS Outposts rack and on-premises data using CoIP

2022-07-05 Sheila Busser

Post Syndicated from Sheila Busser original https://aws.amazon.com/blogs/compute/configuring-low-latency-connectivity-between-aws-outposts-rack-using-coip-and-on-premises-data/

This blog post is written by, Leonardo Azize Martins, Cloud Infrastructure Architect, Professional Services.

AWS Outposts rack enables applications that need to run on-premises due to low latency, local data processing, or local data storage needs by connecting Outposts rack to your on-premises network via the local gateway (LGW).

Each Outpost rack includes a local gateway to provide low latency connectivity between the Outpost and any local data sources, end users, local machinery and equipment, or local databases. If you have an Outpost rack, you can include a local gateway as the target in your VPC subnet route table where the destination is your on-premises network. Local gateways are only available for Outposts rack and can only be used in route tables where the VPC has been associated with an LGW.

In a previous blog post on connecting AWS Outposts to on-premises data sources, you learned the different use cases to use AWS Outposts connected with your local network. In this post, you will dive deep into local gateway usage and specific details about it. You will learn how to use Outpost local gateway when it is configured as Customer-owned IP addresses (CoIP) mode. You will also learn how to integrate it with your Amazon Virtual Private Cloud (Amazon VPC) and how different routes work regarding Amazon Elastic Compute Cloud (Amazon EC2) instances running on Outposts.

Overview of solution

The primary role of a local gateway is to provide connectivity from an Outpost to your local on-premises LAN. It also provides AWS Outposts connectivity to the internet through your on-premises network via the LGW, so you don’t need to rely on an internet gateway (IGW). The local gateway can also provide a data plane path back to the AWS Region. If you already have connectivity between your LAN and the Region through AWS Site-to-Site VPN or AWS Direct Connect, you can use the same path to connect from the Outpost to the AWS Region privately.

Outpost subnet

Public subnets and private subnets are important concepts to understand for Outposts networking. A public subnet has a route to an internet gateway. The same concept applies to Outpost subnets, when a public subnet exists on Outposts, it will have a route to an internet gateway, which will use a service link as a communication path between an Outpost and the internet gateway in the parent AWS Region.

A private subnet does not have a direct route to the internet gateway. It will only be local inside the VPC, or it could have a route to a Network Address Translation (NAT) gateway. In both cases, the communication between Outpost subnets and AWS Region subnets will be done via the service link.

Your subnet can be private and only be allowed to communicate with your on-premises network. You just need a route pointing to the LGW.

You can also provide internet connectivity to your Outpost subnets via LGW. In this case, it will not use the service link. As soon as it traverses the LGW and goes to your next hop, it will follow your routing flow to the internet.

Routing

By default, every Outpost subnet inherits the main route table from its VPC. You can create a custom route table and associate it with an Outpost subnet. You can include a local gateway as the target when the destination is your on-premises network. A local gateway can only be used in VPC and subnet route tables that are exclusively associated with an Outpost subnet. If the route table is associated with an Outpost subnet and a Region subnet, it will not allow you to add a local gateway as the target.

Local gateways are also not supported in the main route table.

The local gateway advertises Outpost IP address ranges to your on-premises network via BGP. In the other direction, from an on-premises network to the Outpost, it doesn’t use BGP, which means there is no propagation. You need to configure your VPC route table with static routes.

As of this writing, the LGW does not support jumbo frame.

Outposts IP addresses

Outposts can be configured in customer-owned IP (CoIP) mode.

Customer-owned IP

During the installation process, uses information that you provide about your on-premises network to create an address pool, which is known as a customer-owned IP address pool (CoIP pool). AWS then assigns it to the local gateway for use and advertises back to your on-premises network through BGP.

CoIP addresses provide local or external connectivity to resources in your Outpost subnets through your on-premises network. You can assign these IP addresses to resources on your Outpost, such as an EC2 instance, by allocating a new Elastic IP address from the customer-owned IP pool and then assigning this new Elastic IP address to your EC2 instance.

A local gateway serves as NAT for EC2 instances that have been assigned addresses from your customer-owned IP pool.

You can optionally share your customer-owned pool with multiple AWS accounts in your AWS Organizations using the AWS Resource Access Manager (RAM). After you share the pool, participants can allocate and associate Elastic IP addresses from the customer-owned IP pool.

Communication between your Outpost and on-premises network will use the CoIP Elastic IP addresses to address instances in the Outpost; the VPC CIDR range is not used.

Walkthrough

You will follow the steps required to configure your VPC to use LGW configured as CoIP, including:

Associate your VPC with the LGW route table.
Create an Outposts subnet.
Create and associate the VPC route table with the subnet.
Add a route to on-premises network with LGW as the target.

Prerequisites

For this walkthrough, you should have the following prerequisites:

An AWS account.
An Outpost that consists of one or more Outposts racks configured in CoIP mode.

Associate VPC with LGW route table

Use the following procedure to associate a VPC with the LGW route table. You can’t associate VPCs that have a CIDR block conflict.

Open the AWS Outposts console.
In the navigation pane, choose Local gateway route tables.
Select the route table and then choose Actions, Associate VPC.
For VPC ID, select the VPC to associate with the local gateway route table.
Choose Associate VPC.

Create an Outpost subnet

You can add Outpost subnets to any VPC in the parent AWS Region for the Outpost. When you do so, the VPC also spans the Outpost.

Open the AWS Outposts console.
On the navigation pane, choose Outposts.
Select the Outpost, and then choose Actions, Create subnet.
Select the VPC and specify an IP address range for the subnet.
Choose Create.

Create and associate VPC route table with the Outpost subnet

You can create a custom route table for your VPC using the Amazon VPC console. It is a best practice to have one specific route table for each subnet.

Open the Amazon VPC console.
In the navigation pane, choose Route Tables.
Choose Create route table.
For VPC, choose your VPC.
Choose Create.
On the Subnet associations tab, choose Edit subnet associations.
Select the check box for the subnet to associate with the route table and then choose Save associations.

Add a route to on-premises network with LGW as the target

You can add a route to a route table using the Amazon VPC console.

Open the Amazon VPC console.
In the navigation pane, choose Route Tables and select
Choose Actions, Edit routes.
Choose Add route. For Destination, enter the destination CIDR block, a single IP address, or the ID of a prefix list.
Choose Save routes.

Allocate and associate a customer-owned IP address

Open the Amazon EC2 console.
In the navigation pane, choose Elastic IPs.
Choose Allocate new address.
For Network Border Group, select the location from which the IP address is advertised.
For Public IPv4 address pool, choose Customer owned IPv4 address pool.
For Customer owned IPv4 address pool, select the pool that you configured.
Choose Allocate and close the confirmation screen.
In the navigation pane, choose Elastic IPs.
Select an Elastic IP address and choose Actions, Associate address.
Select the instance from Instance and then choose Associate.

For more information about Launch an instance on your Outpost, refer to the AWS Outposts User Guide.

Cleaning up

To avoid incurring future charges, delete the resources, like EC2 instances.

Conclusion

In this post, I covered how to use the Outposts rack local gateway to communicate with your on-premises network. You learned how a subnet route table can influence the connectivity of public or private Outpost instances.

To learn more, check out our Outposts local gateway documentation and the networking reference architecture.

Analyze logs with Dynatrace Davis AI Engine using Amazon Kinesis Data Firehose HTTP endpoint delivery

2022-07-05 Erick Leon

Post Syndicated from Erick Leon original https://aws.amazon.com/blogs/big-data/analyze-logs-with-dynatrace-davis-ai-engine-using-amazon-kinesis-data-firehose-http-endpoint-delivery/

This blog post is co-authored with Erick Leon, Sr. Technical Alliance Manager from Dynatrace.

Amazon Kinesis Data Firehose is the easiest way to reliably load streaming data into data lakes, data stores, and analytics services. With just a few clicks, you can create fully-managed delivery streams that auto scale on demand to match the throughput of your data. Customers already use Kinesis Data Firehose to ingest raw data from various data sources, including logs from AWS services. Kinesis Data Firehose now supports delivering streaming data to Dynatrace. Dynatrace begins analyzing incoming data within minutes of Amazon CloudWatch data generation.

Starting today, you can use Kinesis Data Firehose to send CloudWatch Metrics and Logs directly to the Dynatrace observability platform to perform your explorations and analysis. Dynatrace, an AWS Partner Network (APN) has provided full observability into AWS Services by ingesting CloudWatch metrics that are published by AWS services. Dynatrace ingests this data to perform root-cause analysis using the Dynatrace Davis AI engine.

In this post, we describe the Kinesis Data Firehose and related Dynatrace integration.

Prerequisites

For this walkthrough, you should have the following prerequisites:

AWS account.
Access to the CloudWatch and Kinesis Data Firehose with permissions to manage HTTP endpoints.
Dynatrace Intelligent Observability Platform account, or get a free 15 day trial here.
Dynatrace version 1.182+.
An updated AWS monitoring policy to include the additional AWS services.
To update the AWS Identity and Access Management (IAM) policy, use the JSON in the link above, containing the monitoring policy (permissions) for all supporting services.
Dynatrace API token: create token with the following permission and keep readily available in a notepad.

Figure 1 – Dynatrace API Token

How it works

Figure 2 – Amazon Kinesis Data Firehose HTTP endpoint delivery

Simply create a log stream for your Amazon services to deliver your context rich logs to the Amazon CloudWatch Logs service. Next, select your Dynatrace HTTP endpoint to enhance your logs streams with the power of the Dynatrace Intelligence Platform. Finally, you can also back up your logs to an Amazon Simple Storage Service (Amazon S3) bucket.

Setup instructions

To add a service to monitoring, follow these steps:

In the Dynatrace menu, go to Settings > Cloud and virtualization, and select AWS.
On the AWS overview page, scroll down and select the desired AWS instance. Select the Edit button.
Scroll down and select Add service. Choose the service name from the drop-down, and select Add service.
Select Save changes.

To process and deliver AWS CloudWatch Metrics to Dynatrace, follow these steps.

Figure 3 – AWS Console

On the Amazon Kinesis services page, select the radio button for Kinesis Data Firehose and select the Create delivery stream button.

Figure 4 – Amazon Kinesis

Choose the “Direct PUT” from the drop down, and from Destination drop down, choose “Dynatrace”.

Figure 5 – Amazon Kinesis Data Firehose

Delivery stream name – Give your stream a new name, for example: – “KFH-StreamToDynatrace”

Figure 6 – Delivery stream name

In the section “Destination settings”:

Figure 7 – Destination settings

HTTP endpoint name – “Dynatrace”.
HTTP endpoint URL – From the drop down, select “Dynatrace – US”.
API token – Enter Dynatrace API TOKEN created in the prerequisite section.
API URL – enter the Dynatrace URL for your tenant, for example: https://xxxxx.live.dynatrace.com
Back Up Settings – Either select an existing S3 bucket or create a new one and add details and select the Create delivery stream button.

Figure 8 – Backup settings

Once successful, your AWS Console will look like the following:

Figure 9 – Amazon Kinesis Data Firehose

The Dynatrace Experience

Once the initial setups are completed in both Dynatrace and the AWS Console, follow these steps to visualize your new KHF stream data in the Dynatrace console.

Log in to the Dynatrace Console, and on the left side menu expand the “infrastructure” section, and select “AWS”
From the screen, select the AWS account that you want to add the KFH stream to.
Next, you’ll see a virtualization of your AWS assets for the account selected. Select the box marked “Supporting Services”.
Next, press the “Configure services” button.
Next, select “Add service”.
From the drop down, select “Kinesis Data Firehose”.
Next, select the “Add metric” button, and select the metrics that you want to see for this stream. Dynatrace has a comprehensive list of metrics that can be selected from the UI. The list can be found in this link.

Troubleshooting

After configuration, load to the new KFH stream no data in the Dynatrace Console.
1. Check the Error Logs tab check to make sure that the Destination URL is correct for the Dynatrace Tenant.

Figure 10 – Destination error logs

Invalid or misconfigured Dynatrace API token or scope isn’t properly set.

Figure 11 – Destination error logs

Conclusion

In this post, we demonstrate the Kinesis Data Firehose and related Dynatrace integration. In addition, engineers can use CloudWatch Metrics to explore their production systems alongside events in Dynatrace. This provides a seamless, current view of your system (from logs to events and traces) in a single data store.

To learn more about CloudWatch Service, see the Amazon CloudWatch home page. If you have any questions, post them on the AWS CloudWatch service forum.

If you haven’t yet signed up for Dynatrace, then you can try out Kinesis Data Firehose with Dynatrace with a free Dynatrace trial.

About the Authors

Erick Leon is a Technical Alliances Sr. Manager at Dynatrace, Observability Practice Architect, and Customer Advocate. He promotes strong technical integrations with a focus on AWS. With over 15 years as a Dynatrace customer, his real-world experiences and lessons learned bring valuable insights into the Dynatrace Intelligent Observability Platform.

Shashiraj Jeripotula (Raj) is a San Francisco-based Sr. Partner Solutions Architect at AWS. He works with various independent software vendors (ISVs), and partners who specialize in cloud management tools and DevOps to develop joint solutions and accelerate cloud adoption on AWS.

How to tune TLS for hybrid post-quantum cryptography with Kyber

2022-07-05 Brian Jarvis

Post Syndicated from Brian Jarvis original https://aws.amazon.com/blogs/security/how-to-tune-tls-for-hybrid-post-quantum-cryptography-with-kyber/

We are excited to offer hybrid post-quantum TLS with Kyber for AWS Key Management Service (AWS KMS) and AWS Certificate Manager (ACM). In this blog post, we share the performance characteristics of our hybrid post-quantum Kyber implementation, show you how to configure a Maven project to use it, and discuss how to prepare your connection settings for Kyber post-quantum cryptography (PQC).

After five years of intensive research and cryptanalysis among partners from academia, the cryptographic community, and the National Institute of Standards and Technology (NIST), NIST has selected Kyber for post-quantum key encapsulation mechanism (KEM) standardization. This marks the beginning of the next generation of public key encryption. In time, the classical key establishment algorithms we use today, like RSA and elliptic curve cryptography (ECC), will be replaced by quantum-secure alternatives. At AWS Cryptography, we’ve been researching and analyzing the candidate KEMs through each round of the NIST selection process. We began supporting Kyber in round 2 and continue that support today.

A cryptographically relevant quantum computer that is capable of breaking RSA and ECC does not yet exist. However, we are offering hybrid post-quantum TLS with Kyber today so that customers can see how the performance differences of PQC affect their workloads. We also believe that the use of PQC raises the already-high security bar for connecting to AWS KMS and ACM, making this feature attractive for customers with long-term confidentiality needs.

Performance of hybrid post-quantum TLS with Kyber

Hybrid post-quantum TLS incurs a latency and bandwidth overhead compared to classical crypto alone. To quantify this overhead, we measured how long S2N-TLS takes to negotiate hybrid post-quantum (ECDHE + Kyber) key establishment compared to ECDHE alone. We performed the tests with the Linux perf subsystem on an Amazon Elastic Compute Cloud (Amazon EC2) c6i.4xlarge instance in the US East (Northern Virginia) AWS Region, and we initiated 2,000 TLS connections to a test server running in the US West (Oregon) Region, to include typical internet latencies.

Figure 1 shows the latencies of a TLS handshake that uses classical ECDHE and hybrid post-quantum (ECDHE + Kyber) key establishment. The columns are separated to illustrate the CPU time spent by the client and server compared to the time spent sending data over the network.

Figure 1: Latency of classical compared to hybrid post-quantum TLS handshake

Figure 2 shows the bytes sent and received during the TLS handshake, as measured by the client, for both classical ECDHE and hybrid post-quantum (ECDHE + Kyber) key establishment.

Figure 2: Bandwidth of classical compared to hybrid post-quantum TLS handshake

This data shows that the overhead for using hybrid post-quantum key establishment is 0.25 ms on the client, 0.23 ms on the server, and an additional 2,356 bytes on the wire. Intra-Region tests would result in lower network latency. Your latencies also might vary depending on network conditions, CPU performance, server load, and other variables.

The results show that the performance of Kyber is strong; the additional latency is one of the top contenders among the NIST PQC candidates that we analyzed in a previous blog post. In fact, the performance of these ciphers has improved during our latest test, because x86-64 assembly-optimized versions of these ciphers are now available for use.

Configure a Maven project for hybrid post-quantum TLS

In this section, we provide a Maven configuration and code example that will show you how to get started using our assembly-optimized, hybrid post-quantum TLS configuration with Kyber.

To configure a Maven project for hybrid post-quantum TLS

Get the preview release of the AWS Common Runtime HTTP client for the AWS SDK for Java 2.x. Your Maven dependency configuration should specify version 2.17.69-PREVIEW or newer, as shown in the following code sample.
```
<dependency>
    <groupId>software.amazon.awssdk</groupId>
    aws-crt-client
    <version>[2.17.69-PREVIEW,]</version>
</dependency>
```

Configure the desired cipher suite in your code’s initialization. The following code sample configures an AWS KMS client to use the latest hybrid post-quantum cipher suite.

// Check platform support
if(!TLS_CIPHER_PREF_PQ_TLSv1_0_2021_05.isSupported()){
    throw new RuntimeException(“Hybrid post-quantum cipher suites are not supported.”);
}

// Configure HTTP client   
SdkAsyncHttpClient awsCrtHttpClient = AwsCrtAsyncHttpClient.builder()
          .tlsCipherPreference(TLS_CIPHER_PREF_PQ_TLSv1_0_2021_05)
          .build();

// Create the AWS KMS async client
KmsAsyncClient kmsAsync = KmsAsyncClient.builder()
         .httpClient(awsCrtHttpClient)
         .build();

With that, all calls made with your AWS KMS client will use hybrid post-quantum TLS. You can use the latest hybrid post-quantum cipher suite with ACM by following the preceding example but using an AcmAsyncClient instead.

Tune connection settings for hybrid post-quantum TLS

Although hybrid post-quantum TLS has some latency and bandwidth overhead on the initial handshake, that cost is amortized over the duration of the TLS session, and you can fine-tune your connection settings to help further reduce the cost. In this section, you learn three ways to reduce the impact of hybrid PQC on your TLS connections: connection pooling, connection timeouts, and TLS session resumption.

Connection pooling

Connection pools manage the number of active connections to a server. They allow a connection to be reused without closing and reopening it, which amortizes the cost of connection establishment over time. Part of a connection’s setup time is the TLS handshake, so you can use connection pools to help reduce the impact of an increase in handshake latency.

To illustrate this, we wrote a test application that generates approximately 200 transactions per second to a test server. We varied the maximum concurrency setting of the HTTP client and measured the latency of the test request. In the AWS CRT HTTP client, this is the maxConcurrency setting. If the connection pool doesn’t have an idle connection available, the request latency includes establishing a new connection. Using Wireshark, we captured the network traffic to observe the number of TLS handshakes that took place over the duration of the application. Figure 3 shows the request latency and number of TLS handshakes as the maxConcurrency setting is increased.

Figure 3: Median request latency and number of TLS handshakes as concurrency pool size increases

The biggest latency benefit occurred with a maxConcurrency value greater than 1. Beyond that, the latencies were past the point of diminishing returns. For all maxConcurrency values of 10 and below, additional TLS handshakes took place within the connections, but they didn’t have much impact on median latency. These inflection points will depend on your application’s request volume. The takeaway is that connection pooling allows connections to be reused, thereby spreading the cost of any increased TLS negotiation time over many requests.

More detail about using the maxConcurrency option can be found in the AWS SDK for Java API Reference.

Connection timeouts

Connection timeouts work in conjunction with connection pooling. Even if you use a connection pool, there is a limit to how long idle connections stay open before the pool closes them. You can adjust this time limit to save on connection establishment overhead.

A nice way to visualize this setting is to imagine bursty traffic patterns. Despite tuning the connection pool concurrency, your connections keep closing because the burst period is longer than the idle time limit. By increasing the maximum idle time, you can reuse these connections despite bursty behavior.

To simulate the impact of connection timeouts, we wrote a test application that starts 10 threads, each of which activate at the same time on a periodic schedule every 5 seconds for a minute. We set maxConcurrency to 10 to allow each thread to have its own connection. We set connectionMaxIdleTime of the AWS CRT HTTP client to 1 second for the first test; and to 10 seconds for the second test.

When the maximum idle time was 1 second, the connections for all 10 threads closed during the time between each burst. As a result, 100 total connections were formed over the life of the test, causing a median request latency of 20.3 ms. When we changed the maximum idle time to 10 seconds, the 10 initial connections were reused by each subsequent burst, reducing the median request latency to 5.9 ms.

By setting the connectionMaxIdleTime appropriately for your application, you can reduce connection establishment overhead, including TLS negotiation time, to help achieve time savings throughout the life of your application.

More detail about using the connectionMaxIdleTime option can be found in the AWS SDK for Java API Reference.

TLS session resumption

TLS session resumption allows a client and server to bypass the key agreement that is normally performed to arrive at a new shared secret. Instead, communication quickly resumes by using a shared secret that was previously negotiated, or one that was derived from a previous secret (the implementation details depend on the version of TLS in use). This feature requires that both the client and server support it, but if available, TLS session resumption allows the TLS handshake time and bandwidth increases associated with hybrid PQ to be amortized over the life of multiple connections.

Conclusion

As you learned in this post, hybrid post-quantum TLS with Kyber is available for AWS KMS and ACM. This new cipher suite raises the security bar and allows you to prepare your workloads for post-quantum cryptography. Hybrid key agreement has some additional overhead compared to classical ECDHE, but you can mitigate these increases by tuning your connection settings, including connection pooling, connection timeouts, and TLS session resumption. Begin using hybrid key agreement today with AWS KMS and ACM.

If you have feedback about this post, submit comments in the Comments section below.

Want more AWS Security news? Follow us on Twitter.

UniFi Access Point Wifi 6 Extender

2022-07-05 Crosstalk Solutions

Post Syndicated from Crosstalk Solutions original https://www.youtube.com/watch?v=XWU7PHnGhxs

How William Hill migrated NoSQL workloads at scale to Amazon Keyspaces

2022-07-05 Kunal Gautam

Post Syndicated from Kunal Gautam original https://aws.amazon.com/blogs/big-data/how-william-hill-migrated-nosql-workloads-at-scale-to-amazon-keyspaces/

Social gaming and online sports betting are competitive environments. The game must be able to handle large volumes of unpredictable traffic while simultaneously promising zero downtime. In this domain, user retention is no longer just desirable, it’s critical. William Hill is a global online gambling company based in London, England, and it is the founding member of the UK Betting and Gaming Council. They share the mission to champion the betting and gaming industry and set world-class standards to make sure of an enjoyable, fair, and safe betting and gambling experience for all of their customers. In sports betting, William Hill is an industry-leading brand, awarded with prestigious industry titles like the IGA Awards Sports Betting Operator of the year in 2019, 2020, and 2022, and the SBC Awards Racing Sportsbook of the Year in 2019. William Hill has been acquired by Caesars Entertainment, Inc (NASDAQ: CZR) in April 2021, and it’s the largest casino-entertainment company in the US and one of the world’s most diversified casino-entertainment providers. At the heart of William Hill gaming platform is a NoSQL database that maintains 100% uptime, scales in real-time to handle millions of users or more, and provides users with a responsive and personalized experience across all of their devices.

In this post, we’ll discuss how William Hill moved their workload from Apache Cassandra to Amazon Keyspaces (for Apache Cassandra) with zero downtime using AWS Glue ETL.

William Hill was facing challenges regarding scalability, cluster instability, high operational costs, and manual patching and server maintenance. They were looking for a NoSQL solution which was scalable, highly-available, and completely managed. This let them focus on providing better user experience rather than maintaining infrastructure. William Hill Limited decided to move forward with Amazon Keyspaces, since it can run Apache Cassandra workloads on AWS using the same Cassandra application code and developer tools used today, without the need to provision, patch, manage servers, install, maintain, or operate software.

Solution overview

William Hill Limited wanted to migrate their existing Apache Cassandra workloads to Amazon Keyspaces with a replication lag of minutes, with minimum migration costs and development efforts. Therefore, AWS Glue ETL was leveraged to deliver the desired outcome.

AWS Glue is a serverless data integration service that provides multiple benefits for migration:

No infrastructure to maintain; allocates the necessary computing power and runs multiple migration jobs simultaneously.
All-in-one pricing model that includes infrastructure and is 55% cheaper than other cloud data integration options.
No lock in with the service; possible to develop data migration pipelines in open-source Apache Spark (Spark SQL, PySpark, and Scala).
Migration pipeline can be scaled fearlessly with Amazon Keyspaces and AWS Glue.
Built-in pipeline monitoring to make sure of in-migration continuity.
AWS Glue ETL jobs make it possible to perform bulk data extraction from Apache Cassandra and ingest to Amazon Keyspaces.

In this post, we’ll take you through William Hill’s journey of building the migration pipeline from scratch to migrate the Apache Cassandra workload to Amazon Keyspaces by leveraging AWS Glue ETL with DataStax Spark Cassandra connector.

For the purpose of this post, let’s look at a typical Cassandra Network setup on AWS and the mechanism used to establish the connection with AWS Glue ETL. The migration solution described also works for Apache Cassandra hosted on on-premises clusters.

Architecture overview

The architecture demonstrates the migration environment that requires Amazon Keyspaces, AWS Glue, Amazon Simple Storage Service (Amazon S3), and the Apache Cassandra cluster. To avoid a high CPU utilization/saturation on the Apache Cassandra cluster during the migration process, you might want to deploy another Cassandra datacenter to isolate your production from the migration workload to make the migration process seamless for your customers.

Amazon S3 has been used for staging while migrating data from Apache Cassandra to Amazon Keyspaces to make sure that the IO load on Cassandra serving live traffic on production is minimized, in case the data upload to Amazon Keyspaces fails and a retry must be done.

Prerequisites

The Apache Cassandra cluster is hosted on Amazon Elastic Compute Cloud (Amazon EC2) instances, spread across three availability zones, and hosted in private subnets. AWS Glue ETL is hosted on Amazon Virtual Private Cloud (Amazon VPC) and thus needs a AWS Glue Studio custom Connectors and Connections to be setup to communicate with the Apache Cassandra nodes hosted on the private subnets in the customer VPC. Thereby, this enables the connection to the Cassandra cluster hosted in the VPC. The DataStax Spark Cassandra Connector must be downloaded and saved onto an Amazon S3 bucket: s3://$MIGRATION_BUCKET/jars/spark-cassandra-connector-assembly_2.12-3.2.0.jar.

Let’s create an AWS Glue Studio custom connector named cassandra_connection and its corresponding connection named conn-cassandra-custom for AWS region us-east-1.

For the connector created, create an AWS Glue Studio connection and populate it with network information VPC, and a Subnet allowing for AWS Glue ETL to establish a connection with Apache Casandra.

Name: conn-cassandra-custom
Network Options
- VPC: vpc-XXXXEXAMPLE
- Subnet: subnet-ee1111d1EXAMPLE
- Security Group: sg-0f0f0f000000f000fSAMPLE

Let’s begin by creating a keyspace and table in Amazon Keyspaces using Amazon Keyspaces Console or CQLSH, and then create a target keyspace named target_keyspace and a target table named target_table.

CREATE KEYSPACE target_keyspace WITH replication = {'class': 'SingleRegionStrategy'};

CREATE TABLE target_keyspace.target_table (
    userid      uuid,
    level       text,
    gameid      int,
    description text,
    nickname    text,
    zip         text,
    email       text,
    updatetime  text,
    PRIMARY KEY (userid, level, gameid)
) WITH default_time_to_live = 0 AND CUSTOM_PROPERTIES = {
	'capacity_mode':{
		'throughput_mode':'PROVISIONED',
		'write_capacity_units':76388,
		'read_capacity_units':3612
	}
} AND CLUSTERING ORDER BY (level ASC, gameid ASC);

After the table has been created, switch the table to on-demand mode to pre-warm the table and avoid AWS Glue ETL job throttling failures. The following script will update the throughput mode.

ALTER TABLE target_keyspace.target_table 
WITH CUSTOM_PROPERTIES = {
	'capacity_mode':{
		'throughput_mode':'PAY_PER_REQUEST'
	}
}

Let’s go ahead and create two Amazon S3 buckets to support the migration process. The first bucket (s3://your-spark-cassandra-connector-bucket-name)should store the spark Cassandra connector assembly jar file, Cassandra, and Keyspaces configuration YAML files.

The second bucket (s3://your-migration-stage-bucket-name) will be used to store intermediate parquet files to identify the delta between the Cassandra cluster and the Amazon Keyspaces table to track changes between subsequent executions of the AWS Glue ETL jobs.

In the following KeyspacesConnector.conf, set your contact points to connect to Amazon Keyspaces, and replace the username and the password to the AWS credentials.

Using the RateLimitingRequestThrottler we can make sure that requests don’t exceed the configured Keyspaces capacity. The G1.X DPU creates one executor per worker. The RateLimitingRequestThrottler in this example is set for 1000 requests per second. With this configuration, and G.1X DPU, you’ll achieve 1000 request per AWS Glue worker. Adjust the max-requests-per-second accordingly to fit your workload. Increase the number of workers to scale throughput to a table.

datastax-java-driver {
  basic.request.consistency = "LOCAL_QUORUM"
  basic.contact-points = ["cassandra.us-east-1.amazonaws.com:9142"]
   advanced.reconnect-on-init = true
   basic.load-balancing-policy {
        local-datacenter = "us-east-1"
    }
    advanced.auth-provider = {
       class = PlainTextAuthProvider
       username = "user-at-sample"
       password = "S@MPLE=PASSWORD="
    }
    advanced.throttler = {
       class = RateLimitingRequestThrottler
       max-requests-per-second = 1000
       max-queue-size = 50000
       drain-interval = 1 millisecond
    }
    advanced.ssl-engine-factory {
      class = DefaultSslEngineFactory
      hostname-validation = false
    }
    advanced.connection.pool.local.size = 1
}

Similarly, create a CassandraConnector.conf file, set the contact points to connect to the Cassandra cluster, and replace the username and the password respectively.

datastax-java-driver {
  basic.request.consistency = "LOCAL_QUORUM"
  basic.contact-points = ["127.0.0.1:9042"]
   advanced.reconnect-on-init = true
   basic.load-balancing-policy {
        local-datacenter = "datacenter1"
    }
    advanced.auth-provider = {
       class = PlainTextAuthProvider
       username = "user-at-sample"
       password = "S@MPLE=PASSWORD="
    }
}

Build AWS Glue ETL migration pipeline with Amazon Keyspaces

To build reliable, consistent delta upload Glue ETL pipeline, let’s decouple the migration process into two AWS Glue ETLs.

CassandraToS3 Glue ETL: Read data from the Apache Cassandra cluster and transfer the migration workload to Amazon S3 in the Apache Parquet format. To identify incremental changes in the Cassandra tables, the job stores separate parquet files with primary keys with an updated timestamp.
S3toKeyspaces Glue ETL: Uploads the migration workload from Amazon S3 to Amazon Keyspaces. During the first run, the ETL uploads the complete data set from Amazon S3 to Amazon Keyspaces, and for the subsequent run calculates the incremental changes by comparing the updated timestamp across two subsequent runs and calculating the incremental difference. The job also takes care of inserting new records, updating existing records, and deleting records based on the incremental difference.

In this example, we’ll use Scala to write the AWS Glue ETL, but you can also use PySpark.

Let’s go ahead and create an AWS Glue ETL job named CassandraToS3 with the following job parameters:

aws glue create-job \
    --name "CassandraToS3" \
    --role "GlueKeyspacesMigration" \
    --description "Offload data from the Cassandra to S3" \
    --glue-version "3.0" \
    --number-of-workers 2 \
    --worker-type "G.1X" \
    --connections "conn-cassandra-custom" \
    --command "Name=glueetl,ScriptLocation=s3://$MIGRATION_BUCKET/scripts/CassandraToS3.scala" \
    --max-retries 0 \
    --default-arguments '{
        "--job-language":"scala",
        "--KEYSPACE_NAME":"source_keyspace",
        "--TABLE_NAME":"source_table",
        "--S3_URI_FULL_CHANGE":"s3://$MIGRATION_BUCKET/full-dataset/",
        "--S3_URI_CURRENT_CHANGE":"s3://$MIGRATION_BUCKET/incremental-dataset/current/",
        "--S3_URI_NEW_CHANGE":"s3://$MIGRATION_BUCKET/incremental-dataset/new/",
        "--extra-files":"s3://$MIGRATION_BUCKET/conf/CassandraConnector.conf",
        "--conf":"spark.cassandra.connection.config.profile.path=CassandraConnector.conf",
        "--class":"GlueApp"
    }'

The CassandraToS3 Glue ETL job reads data from the Apache Cassandra table source_keyspace.source_table and writes it to the S3 bucket in the Apache Parquet format. The job rotates the parquet files to help identify delta changes in the data between consecutive job executions. To identify inserts, updates, and deletes, you must know primary key and columns write times (updated timestamp) in the Cassandra cluster up front. Our primary key consists of several columns userid, level, gameid, and a write time column updatetime. If you have multiple updated columns, then you must use more than one write time columns with an aggregation function. For example, for email and updatetime, take the maximum value between write times for email and updatetime.

The following AWS Glue spark code offloads data to Amazon S3 using the spark-cassandra-connector. The script takes four parameters KEYSPACE_NAME, KEYSPACE_TABLE, S3_URI_CURRENT_CHANGE, S3_URI_CURRENT_CHANGE, and S3_URI_NEW_CHANGE.

To upload the data from Amazon S3 to Amazon Keyspaces, you must create a S3toKeyspaces Glue ETL job using the Glue spark code to read the parquet files from the Amazon S3 bucket created as an output of CassandraToS3 Glue job and identify inserts, updates, deletes, and execute requests against the target table in Amazon Keyspaces. The code sample provided takes four parameters: KEYSPACE_NAME, KEYSPACE_TABLE, S3_URI_CURRENT_CHANGE, S3_URI_CURRENT_CHANGE, and S3_URI_NEW_CHANGE.

Let’s go ahead and create our second AWS Glue ETL job S3toKeyspaces with the following job parameters:

aws glue create-job \
    --name "S3toKeyspaces" \
    --role "GlueKeyspacesMigration" \
    --description "Push data to Amazon Keyspaces" \
    --glue-version "3.0" \
    --number-of-workers 2 \
    --worker-type "G.1X" \
    --command "Name=glueetl,ScriptLocation=s3://amazon-keyspaces-backups/scripts/S3toKeyspaces.scala" \
    --default-arguments '{
        "--job-language":"scala",
        "--KEYSPACE_NAME":"target_keyspace",
        "--TABLE_NAME":"target_table",
        "--S3_URI_FULL_CHANGE":"s3://$MIGRATION_BUCKET/full-dataset/",
        "--S3_URI_CURRENT_CHANGE":"s3://$MIGRATION_BUCKET/incremental-dataset/current/",
        "--S3_URI_NEW_CHANGE":"s3://$MIGRATION_BUCKET/incremental-dataset/new/",
        "--extra-files":"s3://$MIGRATION_BUCKET/conf/KeyspacesConnector.conf",
        "--conf":"spark.cassandra.connection.config.profile.path=KeyspacesConnector.conf",
        "--class":"GlueApp"
    }'

Job scheduling

The final step is to configure AWS Glue Triggers or Amazon EventBridge depending on your scheduling needs to trigger S3toKeyspaces Glue ETL when the job CassandraToS3 has succeeded. If you want to run the CassandraToS3 based on the schedule and configure the schedule option, then the following example showcases how to schedule cassandraToS3 to run every 15 minutes.

Job tuning

There are Spark settings recommended to begin with Amazon Keyspaces, which can then be increased later as appropriate for your workload.

Use a Spark partition size (groups multiple Cassandra rows) smaller than 8 MBs to avoid replaying large Spark tasks during a task failure.
Use a low concurrent number of writes per DPU with a large number of retries. Add the following options to the job parameters: --conf spark.cassandra.query.retry.count=500 --conf spark.cassandra.output.concurrent.writes=3.
Set spark.task.maxFailures to a bounded value. For example, you can start from 32 and increase as needed. This option can help you increase a number of tasks reties during a table pre-warm stage. Add the following option to the job parameters: --conf spark.task.maxFailures=32
Another recommendation is to turn off batching to improve random access patterns. Add the following options to the job parameters:
spark.cassandra.output.batch.size.rows=1
spark.cassandra.output.batch.grouping.key=none spark.cassandra.output.batch.grouping.buffer.size=100
Randomize your workload. Amazon Keyspaces partitions data using partition keys. Although Amazon Keyspaces has built-in logic to help load balance requests for the same partition key, loading the data is faster and more efficient if you randomize the order because you can take advantage of the built-in load balancing of writing to different partitions. To spread the writes across the partitions evenly, you must randomize the data in the dataframe. You might use a rand function to shuffle rows in the dataframe.

Summary

William Hill was able to migrate their workload from Apache Cassandra to Amazon Keyspaces at scale using AWS Glue, without the needs to make any changes on their application tech stack. The adoption of Amazon Keyspaces has provided them with the headroom to focus on their Application and customer experience, as with Amazon Keyspaces there’s no need to manage servers, get performance at scale, highly-scalable, and secure solution with the ability to handle the sudden spike in demand.

In this post, you saw how to use AWS Glue to migrate the Cassandra workload to Amazon Keyspaces, and simultaneously keep your Cassandra source databases completely functional during the migration process. When your applications are ready, you can choose to cut over your applications to Amazon Keyspaces with minimal replication lag in sub minutes between the Cassandra cluster and Amazon Keyspaces. You can also use a similar pipeline to replicate the data back to the Cassandra cluster from Amazon Keyspaces to maintain data consistency, if needed. Here you can find the documents and code to help accelerate your migration to Amazon Keyspaces.

About the Authors

Nikolai Kolesnikov is a Senior Data Architect and helps AWS Professional Services customers build highly-scalable applications using Amazon Keyspaces. He also leads Amazon Keyspaces ProServe customer engagements.

Kunal Gautam is a Senior Big Data Architect at Amazon Web Services. Having experience in building his own Startup and working along with enterprises, he brings a unique perspective to get people, business and technology work in tandem for customers. He is passionate about helping customers in their digital transformation journey and enables them to build scalable data and advance analytics solutions to gain timely insights and make critical business decisions. In his spare time, Kunal enjoys Marathons, Tech Meetups and Meditation retreats.

How to Start Over Podcast: How to Forgive Yourself

2022-07-05 The Atlantic

Post Syndicated from The Atlantic original https://www.youtube.com/watch?v=SLdpOYCC3sc

Cloud Complexity Requires a Unified Approach to Assessing Risk

2022-07-05 Shalini Subbiah

Post Syndicated from Shalini Subbiah original https://blog.rapid7.com/2022/07/05/cloud-complexity-requires-a-unified-approach-to-assessing-risk/

Cloud Complexity Requires a Unified Approach to Assessing Risk

There has been an unprecedented acceleration in the shift to the cloud as a result of the COVID-19 pandemic. McKinsey experts estimate companies have moved to the cloud “24 times faster […] than they thought” over the past two years. As organizations move quickly to scale, drive innovation, and revamp the way they engage with their consumers by moving to the public cloud, there is an increasing need for a security strategy that aligns with the varied states of organizations’ maturity in their usage and adoption of the cloud.

Modern cloud environments are complex and require multiple areas of focus, including security, application modernization, reduction of infrastructure overhead, accelerating software delivery, maintaining compliance, and countless more. All of these are critical to realizing the end goals of cloud adoption: increased speed, flexibility, and performance. Rapid cloud adoption without the appropriate visibility and automated security controls will lead to imminent exposure and vulnerability.

Whose responsibility is cloud security?

When it comes to cloud environments, security and compliance are a shared responsibility between the cloud service provider (CSP) and the customer’s internal security team. In the typical shared responsibility model, cloud providers are responsible for the security OF the cloud. This essentially means they are on the hook to make sure the actual underlying resources you’re using – such as a storage bucket or a compute instance – or the physical hardware sitting in their data centers aren’t a security threat.

So, if the provider is responsible for security of the cloud itself, what falls to the customer? Customers are responsible for security IN the cloud, meaning they are responsible for making sure their own data – and their customers’ data – is properly secured. Generally speaking, this means keeping track of how various resources and services are configured properly; identifying and remediating exploitable vulnerabilities; managing identity and access management (IAM) policies to maintain least privilege access; and utilizing encryption for data, whether it’s at rest, in transit, or even in use.

Cloud Complexity Requires a Unified Approach to Assessing Risk

So why is it that such a large majority of breaches are the fault of the customer if the responsibility is shared? There are a few drivers behind this, but it’s primarily because the goal of most bad actors is to gain access to sensitive and potentially lucrative customer data, which falls outside of the responsibility of the cloud provider.

I know what you’re thinking: “The answer is simple – just don’t leave a cloud resource housing sensitive data exposed to the public internet.” That’s, of course, the intent of any well-meaning engineer. That said, mistakes are unfortunately quite common. As engineers and developers work at light speed to bring new products to market, it can be very easy for security and compliance to fall through the cracks, especially as powerful new cloud capabilities enable infrastructure to be implemented with the click of a mouse.

This is consistent with our own research in our 2022 Cloud Misconfigurations Report, in which we found the most commonly breached resources were those that were secure and private by default, such as a storage bucket. This suggests human error played a pivotal role in leaving data exposed.

Prioritizing risk requires a unified approach to cloud security

The scale and complexity of modern cloud environments make it impossible to respond to every alert and potential issue that arises. So, what can you and your team do to make sure you’re not vulnerable to attack?

The key is context.

It is imperative for organizations to think of cloud security holistically so that they can understand their true risk exposure. Organizations need to be able to easily prioritize the issues that are the most critical to fix right away from the flood of alerts and incidents that are calling for their teams’ attention.

The question that needs answering seems simple, yet can be quite complex: “What are the biggest threats to my cloud environment today, and how do I mitigate them?” As mentioned earlier, it is not sufficient anymore to look at an issue through a single lens. Without a unified approach to cloud security, you could be leaving your organization and the systems it relies on in jeopardy.

This means examining not just the risks associated with a workload itself, but a holistic mapping of all resource interdependencies across your environment to understand how one compromised resource may impact others. It means taking into consideration whether or not a given resource is connected to the public internet, or whether there is potential for improper access to potentially sensitive information. There is also business context that needs to be taken into account, where an understanding of resource ownership and accountability can highlight relevant stakeholders that need to be looped in for remediation or audits and provide color as to potential business impact.

See? Simple – yet complex.

Extend this concept across millions of resources spanning hundreds of cloud environments, architectures, and technologies, and you have the complexity of cloud security today. It is therefore a non-negotiable starting point to have a consolidated, weighted, and standardized view of risk to one’s cloud estate. This can only be accomplished by gathering and analyzing all of the relevant data in a single solution that helps you see the full context – and passing that context along to other teams like DevOps – so that organizations can start being more strategic about prioritizing and remediating risks in their environment.

While there are many cloud security tools and vendors that focus on various aspects of cloud security, such as misconfigurations, vulnerabilities, access permissions, and exposure to the internet, very few offer a holistic understanding of all of the above combined to provide a “true” understanding of risk.

A holistic approach to cloud security with InsightCloudSec

Maintaining visibility can only get you so far from a security perspective. Given the sheer volume of monitored resources, chances are without an effective strategy to prioritize the flood of alerts cloud environments produce, your teams won’t know where to start.

The cloud is here to stay, and it is ever-changing. As cloud security and technologies evolve, so do attempts by bad actors to breach it. It is crucial for organizations to invest in best practices and automated cloud security throughout the development lifecycle. Cloud architectures and initiatives must be built on solid risk detection, prioritization and management processes, and platforms that provide seamless and real-time visibility into the true risk posture of the organization.

Increasingly, organizations want to focus their efforts on activities that increase their bottom line and competitive advantage. They simply don’t have the time to sift through multiple lines of code, teams, and repositories to understand the breadth and depth of risks associated with their cloud estate. Cloud security has to be looked at holistically to understand its true impact and threat to the organization.

That’s the difference with InsightCloudSec. We go beyond providing visibility to help organizations uncover the most critical threats facing their cloud ecosystem and provide guidance toward prioritization and response based on the true, holistic risk across multiple security domains. With a higher signal-to-noise ratio, development teams will be able to detect, understand, prevent, prioritize, and respond to threats better and faster, enabling them to build safely and efficiently in a multi-cloud environment.

Interested in learning more? Don’t hesitate to request a free demo!

Additional reading:

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.