sexta-feira, 24 de maio de 2013

Garimpando logs do Apache

Devido a um surto de acessos, resolvi descobrir quem estava vasculhando meus sistemas.

Cada linha do log do Apache tem essa aparência:
  66.249.75.122 - - [24/May/2013:00:01:17 -0300] "GET /a.html HTTP/1.1" 403 213
Meu objetivo era obter uma lista de IPs organizados por números de acessos. Após lutar com os parâmetros de xargs e grep, descobri que algumas opções do sort e do uniq resolvem o problema.

A solução final foi esta:
  cat access_log | cut -d - -f 1 | sort | uniq -c | sort -nr
Os detalhes são estes:
  1. cat imprime o arquivo;
  2. cut -d - -f 1 corta cada linha em campos separados por "-" e extrai o primeiro deles;
  3. sort ordena as linhas
  4. uniq -c elimina as linhas repetidas e adiciona o número de linhas
  5. sort -nr ordena as linhas numericamente (usando o primeiro número em cada uma) em ordem decrescente.
As primeiras 3 linhas foram estas:
  3149 66.249.75.122
  3108 66.249.75.22
  2747 66.249.75.143
Para descobrir a quem pertencem esses IPs, posso usar o nslookup adicionando o seguinte:
  | sed -n '1,3p' | cut -d ' ' -f 5 | nslookup
As adições foram estas:
  1. sed -n '1,3p' imprime as 3 primeiras linhas (os 3 IPs com mais ocorrências no log);
  2. cut -d ' ' -f 5 recorta o IP (porque eles estão acompanhados do número de ocorrências);
  3. nslookup procura os nomes associados aos IPs.
E, como resultado, descobri que o maior usuário tem sido o Google. Talvez haja uma maneira mais simples, mas duvido que seja tão divertida.

quinta-feira, 9 de maio de 2013

Relato de uma travessia a um novo banco de dados

No qual narram-se os trabalhos e as dificuldades enfrentados por 60GB para alcançar um novo banco de dados. 

Neste ano do nosso Senhor de dois mil e treze, 60GB de dados empreenderam com grande valor uma mui laboriosa jornada até um novo banco de dados. Este que vos narra demonstra como as ferramentas do Linux contribuiram para amenizar os trabalhos e compensar a inexperiência da tripulação com as ferramentas da Oracle.

A jornada iniciou-se pelo porto de Toad, a partir do qual foram gerados arquivos ctl para as tabelas que transportariam os dados. Sendo estas naus mui frágeis, logo apresentaram problemas com as âncoras das colunas, sendo estas o conhecido ponto-e-vírgula. Ademais, muitos campos de texto possuíam aspas duplas; carácter este que serve também para delimitar os conteúdos.

Sendo assim, voltamos ao porto e buscamos novas naus, desta vez ancoradas com o tilde. Para as aspas, buscamos auxílio com uns comerciantes mouros que passavam com seus camelos.

  perl -pe "s/(?<=[^~])\"(?=[^~])/\"\"/g" dados.ctl > dados2.ctl

Essa singela expressão regular substitui as aspas que não estejam na vizinhança de um tilde por duas aspas e assim evitamos problemas com o SQL Loader da Oracle.

Infelizmente, os mouros estragaram os cabeçalhos. Nosso Senhor há de perdoar nossa falha e nunca voltaremos a negociar com esses infiéis. Ao menos, roubamos-lhes a sapiência a respeito dos operadores de lookahead (?=) e lookbehind (?<=) que, buscando revertê-los ao serviço de nosso Senhor, permitem procurar sem consumir a fonte. Essa habilidade nos é muito útil na presença de aspas separadas por um único carácter (este seria consumido pela expressão [^~] e impediria a segunda aspa de ser reconhecida).

Buscamos o cabeçalho original e recortamo-lo assim:

  $grep -n BEGINDATA dados.ctl
  66
  $sed -n '1,66p' dados.ctl > dados.cabecalho
  $sed '1,66d' dados2.ctl > dados3.ctl
  $cat dados.cabecalho dados3.ctl > dados4.ctl

E, com a graça de nosso Senhor, procedemos à carga, que obteve sucesso e muita riqueza tratará ao nosso reino.