Informática Numaboa - Tutoriais e Programação
A praga dos spammeiros
Sex 27 Fev 2009 16:01 |
- Detalhes
- Categoria: Joomla
- Atualização: Segunda, 02 Julho 2012 19:42
- Autor: vovó Vicki
- Acessos: 8626
Observando o hábito dos spammeiros
Analisando as "sujeiras" que estavam escapando do crivo do Honey Pot, descobri que havia mais uma porção de ataques. Relato aqui algumas das "pérolas" que encontrei e como coloquei estes IPs fora de combate.
Injeções PHP
Notei que ainda havia uma porção de linhas no log do Apache com coisas do tipo
122.36.116.147 - - [26/Feb/2009:14:25:40 -0300] "GET /index.php?option=http://babycaleb.fortunecity.co.uk/index.htm? HTTP/1.1" 301 1415 78.42.64.169 - - [26/Feb/2009:15:15:56 -0300] "GET /index.php?option=http://schoolpapers.hostinginfive.com/bike.htm? HTTP/1.1" 301 1415
Que eu saiba, pedir um GET de uma página qualquer (index.php) seguida por um sinal de interrogação (?) é uma chamada PHP com passagem de parâmetros. Se o parâmetro passado é um endereço da web, é claro que só pode se tratar de uma injeção PHP. Antes de tomar alguma atitude mais drástica, dei uma pensada: "existe algum endereço no meu site que chama uma página da web com "http://"? É claro que não! Então é treta :fear:
Estava na hora de dar um pé na b... destes palhaços. O que fiz foi inaugurar um trecho de código que analisasse os IPs que haviam escapado do banco de dados do Honey Pot, ou seja, logo depois da linha 92:
Criei a variável $uri que guarda a solicitação. Caso nesta string de requisição exista 'http://', então o IP deve ser banido. Decidi pela resposta '127.0.50.15' para tentar dizer o seguinte: 127 - resposta positiva; 0 - ataque ocorrido há 0 dias; 50 - nível arbitrário de perigo e 15 - uma classificação acima da fornecida pelo Honey Pot.
A classificação 15 não foi arbitrária, foi usada para que em
ela pudesse ser bloqueada. Como $block pode variar de 0 a 7, para que $responce[3] & block dê um resultado positivo precisamos usar um byte com os últimos três bits setados (15 em binário é 1111).
Como eu queria saber se estava conseguindo bloquear este tipo de ataque, dei mais uma caprichada. Já que havia criado um log "particular", usei este log para registrar minhas capturas particulares, inclusive com o tipo de requisição, além da data e da hora:
Para minha alegria e gáudio, não demorou muito e comecei a caçar alguns dos malfeitores de plantão tentando injetar PHP no meu site. Todos foram parar no iptables
O bacana desta história é que acabei pegando por tabela alguns dos ataques mais comuns a sites Joomla:
mosConfig_absolute_path=http://bmwmotoclubkw.com//administrator/components/com_freechat/test.txt?? com_remository&Itemid=298&func=fileinfo&id=http://piap.msb.gob.pe/preventorioweb//modules/mod_gcalendar_upcoming/languages/test.txt??
e algumas coisinhas mais. Novamente
Injeção PHP 2
Minha segunda constatação foi que havia um caminhão de chamadas para os primeiros links apresentados na página inicial (home page). O interessante é que a maior parte do lixo era colocado no link identificado como /destaque e que a tranqueira sempre aparecia depois de um /destaque?texto=. Ficou claro para mim que se tratava de uma nova treta :fear:
Segunda constatação, segunda providência tomada. Era só acrescentar mais uma linha nas minhas capturas particulares:
Para identificar o agressor, usei o próximo valor com os três últimos bits setados (23 em binário é 0001 0111). Aqui vai uma dica: para criar novas classificações é só ir acrescentando 8 aos valores previamente determinados (7 + 8 = 15 + 8 = 23 + 8 = 31...).
Foi mais uma baita de uma limpada e a coisa começou a acalmar pro meu lado. É claro que cada site é único e que os tipos de ataques dependem do que os panacas (ou os programinhas criados por estes panacas) encontram pela frente. Dei dois exemplos do que fiz só para ilustrar o texto. Procure no seu contexto analisando o arquivo de log e o arquivo de erros do Apache, mas cuidado...
Cuidados ao criar regras
Não invente de criar regras a torto e a direito só porque a situação está preta. Por pior que esteja, uma boa análise antes de decidir o que fazer é primordial. Digo isto por experiência própria, porque criei algumas regras que, depois de uma observação mais detalhada, se mostraram absolutamente equivocadas, ou seja, eu estava excluindo visitantes do meu site que não tinham culpa no cartório :blush:
O iptables
Depois de brigar alguns dias com os spammeiros lembrei-me que, se eu rebootasse o servidor, toda minha coleção de IPs bichados iria pro espaço. Resolvi mudar meu "log particular" de lugar (um pouco antes de inserir uma nova regra no iptables) e alterar um pouco o formato para que pudesse ser usado como shell script na hora de levantar o servidor. Além disto, também resolvi capinar todo o código que o autor do plugin havia previsto para o componente JSecure porque ele não seria mais necessário e isto daria uma enxugada no código. Veja como ficou a minha versão semifinal do plugin - digo semifinal porque ainda posso adicionar mais algumas regras.