Ataques de injeção do MySQL? Erros Causando a URL Aleatória

Question

Nós apenas começamos a rodar nosso próprio servidor web há alguns meses na Rackspace (eles são ótimos). Eu uso NewRelic (também muito legal) para monitorar o uso do servidor e estou recebendo alertas de erro que me parecem ser ataques de injeção? Querendo saber se alguém pode mais insight ou conselhos sobre como impedir esses esforços e se livrar dos erros e notificações traquinas.

Sabemos que, de facto, estas não são chamadas ou pedidos que o nosso site disponibilizaria. Eu comecei indo para os logs de acesso e bloqueando os ip's fazendo a requisição, mas eles voltaram mais tarde em outro.

Heres é uma amostra "Erro do MySQL":

link '+ e + 999999.9) + UnIoN + AlL + SELeCt + 0x393133353134353632312e39,0x393133353134353632322e39,0x393133353134353632332e39 , 0x393133353134353632342e39,0x393133353134353632352e39,0x393133353134353632362e39,0x393133353134353632372e39,0x393133353134353632382e39,0x393133353134353632392e39,0x39313335313435363231302e39,0x39313335313435363231312e39,0x39313335313435363231322e39,0x39313335313435363231332e39,0x39313335313435363231342e39,0x39313335313435363231352e39,0x39313335313435363231362e39,0x39313335313435363231372e39,0x39313335313435363231382e39,0x39313335313435363231392e39,0x39313335313435363232302e39,0x39313335313435363232312e39,0x39313335313435363232322e39,0x39313335313435363232332e39,0x39313335313435363232342e39,0x39313335313435363232352e39,0x39313335313435363232362e39,0x39313335313435363232372e39,0x39313335313435363232382e39 , 0x39313335313435363232392e39 + e + '1' = '1

Esse URL deve ser apenas www (ponto) ourdomain (ponto) com / item.php? fetchitem = 46

Outro:

link '+ e (% 2f **% 2fsElEcT + 1 +% 2f **% 2ffRoM (% 2f **% 2fsElEcT + contagem (*),% 2f **% 2fcOnCaT ((% 2f **% 2fsElEcT (% 2f **% 2fsElEcT (% 2f **% 2fsElEcT +% 2f **% 2fcOnCaT (caractere (33,126,33), contagem (t.% 2f **% 2ftAbLe_nAmE), char (33,126,33)) +% 2f **% 2ffRoM + information_schema.% 2f **% 2fsChEmAtA + como + d + join + information_schema. % 2f **% 2ftAbLeS + como + t + em + t.% 2f **% 2ftAbLe_sChEmA + = + d.% 2f **% 2fsChEmA_NaMe + join + information_schema.% 2f **% 2fcOlUmNs + as + c + on + c % 2f **% 2ftAbLe_sChEmA + = + d.% 2f **% 2fsChEmA_NaMe + e + c.% 2f **% 2ftAbLe_nAmE + = + t.% 2f **% 2ftAbLe_nAmE +% 2f **% 2fwHeRe + não + c.% 2f **% 2ftAbLe_sChEmA + em (0x696e666f726d6174696f6e5f736368656d61,0x6d7973716c) + e + d.% 2f **% 2fsChEmA_NaMe + = +% 2f **% 2fdAtAbAsE () + e + c.% 2f **% 2fcOlUmN_NaMe + como + 0x25656d61696c6164647265737325)) +% 2f **% 2ffRoM + information_schema.% 2f **% 2ftAbLeS +% 2f **% 2flImIt + 0,1), andar (rand (0) * 2)) x +% 2f **% 2ffRoM + information_schema.% 2f **% 2ftAbLeS +% 2f **% 2fgRoUp% 2f **% 2fbY + x) a) + e + '1' = '1

Foi sugerido colocar um limite na porta 80 no iptables, mas tenho medo de bloquear possíveis usuários reais.

Todos os pensamentos e conselhos são apreciados! Obrigado!

    

Answer 1

Sim, é isso.

Eu recomendo detectar e bloquear esses ataques com o ModSecurity .

Exemplos de regras para detecção de injeção SQL do ModSecurity CRS (conjunto de regras Core):

link

Você pode ver claramente as regras que contêm palavras-chave "select", "union", "all", etc.

    

Answer 2

Sim, esse é um ataque clássico de injeção de SQL. Sua única defesa a longo prazo é proteger o aplicativo, embora você possa proibir IPs conforme necessário e há várias ferramentas disponíveis para tentar automatizar isso.

Em última análise, a menos que se torne um ataque DOS, eles devem ser relativamente inofensivos se o seu site for a prova de injeção. Porém, esse lado das coisas é mais StackOverflow.

    

Answer 3

sqli clássico - digitalização; conviva ou bloqueie (mas não manualmente):

Se você quiser se proteger de tentativas de injeção de SQL e precisar de uma solução leve, use nginx + naxsi , se você é capaz de instalar e executar um proxy reverso na frente do seu apache (mod_security pode retardar bastante o seu site)

razões para usar naxsi

• é muito mais leve que mod_security
• o core-ruleset é estável em sqli-protection
• escrever e manter regras não é como um PITA como com mod_security
• pode ser estendido para bloquear muitos scanners, skiddos e acesso indesejado (conjunto de regras estendido)
• modo de aprendizagem - > executá-lo em uma instância protegida e gerar regras de lista de permissões para sua configuração ao vivo
• você pode ter o poder nginx completo e usar os recursos proxy_cache e static - quando estiver no mesmo host

quando NÃO usa naxsi:

• se filtrar o tráfego de saída é necessário (eu prefiro snort aqui)
• se filtros de entrada de vários estágios forem necessários (prefiro snort aqui)