DDoS Curour Sourced: Como detectá-lo e como parar?

Question

Ok, um servidor Ubuntu que eu gerencio foi vítima de um ataque DDoS hoje. Normalmente, isso é desagradável, mas não é grande coisa. Alguns momentos de alta carga no servidor & então passa. Hoje foi claramente diferente. Para o registro, eu tenho anos de cicatrizes de ataque do servidor. Mas hoje senti diferente. Leia em.

A solução foi resolvida reativando uma regra de ModSecurity que impede o acesso curl por meio de uma chamada para um endereço IP puro. Isso significa que se um nome de host for mygreatsite.com e o endereço IP for 123.456.78.90 e eu tiver um host virtual para mygreatsite.com & que está ativado. E ModSecurity está ativo com a regra que impede curl acessar por meio de uma chamada para um endereço IP puro, então um visitante obterá o conteúdo adequado quando visitar mygreatsite.com , mas será bloqueado pelo ModSecurity com 403: Forbidden if eles tentam acessar o site via 123.456.78.90 . Ótimo problema resolvido!

Mas enquanto o ataque estava acontecendo, três coisas estavam claras:

1. Processos Apache pelo telhado: O carregamento do processo Apache, conforme refletido em Munin , foi feito através do telhado & consistentemente 3x acima do normal.
2. Nenhum tráfego da Web correspondente Registrado: Não houve tráfego correspondente registrado por meio do Apache & refletido no AWStats. Este foi o caso por algumas horas. Isso está em todos os logs em todos os hosts virtuais no servidor, incluindo o host virtual padrão que seria conectado a um endereço IP simples.
3. A carga do servidor era moderadamente alta, mas não típica Nível de ataque: Embora a carga geral do servidor fosse alta, era apenas nos dígitos simples - 4, 5, 6, 7, etc ... - e não em um DDoS típico onde as cargas podem dobrar e até triplicar o dígito como 20, 30 & até 120 (!!!).

Para mim, o item número 3 foi a parte mais incomum desse ataque. Eu não experimentei um DDoS onde a carga do servidor era basicamente equivalente a um dia de tráfego pesado & não uma carga de servidor insana conectada ao ataque.

Além disso, a execução de elinks para buscar o Apache server-status a partir da linha de comando mostrou o preenchimento do conjunto de conexões como louco em minutos após a reinicialização:

elinks http://localhost/server-status?refresh=1

E depois disso, eu notei um patch de segurança do Ubuntu hoje especificamente para curl problemas. E esta questão específica despertou meu interesse:

libcurl incorrectly validates wildcard SSL certificates containing literal IP addresses.

Então, aqui está a pergunta: O que diabos aconteceu? Eu sei que reativar uma regra de ModSecurity parou o ataque, mas poderia de alguma forma ter sido conectado ao libcurl issue ? E se sim, como posso detectar ou provar isso? E, passado, se o problema fosse com libcurl - que, presumo, viria de clientes armados usando a falha -, isso significa que alguém pode simplesmente manter uma versão antiga hackeada de curl em torno de DDoS novamente? E escrevendo isso, qualquer hacker pode simplesmente baixar o código fonte & consertá-lo para cortar então porque o dilúvio hoje?

Meu palpite é que o patch para curl deixou mais pessoas cientes da falha & o “entusiasmo” das crianças do script ao redor do mundo trouxe uma enxurrada louca de varredura em torno de horas após a exploração ser encontrada? Mas, novamente, isso me confunde porque está no cliente curl install, correto? Não consigo imaginar curl do lado do servidor seria vítima disso.