Análise de logs
De acordo com Ivan Ristic (RISTIC,2005), usar uma única ferramenta para detecção de intrusão não é insuficiente, boa parte dos detectores de intrusão, os IDS, IPS e outros atuam sobre a pilha TCP/IP e embora atuem bem para o que foram destinados não podem proteger plenamente os servidores Web, pois a Web é baseada em torno do protocolo HTTP, que é um vocabulário completamente novo. Ele possui seu próprio conjunto de problemas e desafios, que são diferentes da pilha TCP / IP.
O Formato Dos Log
O apache possui alguns tipos de logs. Os principais são o logs de acesso, onde todas as requisições são registradas, e os logs de erros, que registram eventos não esperados (falhas, erros). Existem também alguns Logs de alguns módulos específicos.
Logs de erro
Diferente do log de acesso o log de erro não possui uma forma determinada, mas informações muito importantes podem ser obtidas nas entradas de logs de erro, observe uma mensagem típica:
[Wed Oct 11 14:32:52 2000] [error] [client 127.0.0.1] client denied by server configuration: /export/home/live/ap/htdocs/test
A primeira parte contém a data detalhada com minuto e segundo de quando ocorreu a mensagem. A segunda parte mostra a importância do erro que está sendo reportado. A diretiva de nível de log “LogLevel” mostra os tipos de erros que são enviados para o log de erro, observe a tabela 3, a terceira parte informa o endereço IP do cliente que gerou o erro, e por último a mensagem de propriamente dita, que neste caso indica que o servidor tenha sido configurado para negar o acesso do cliente.
Uma ampla variedade de mensagens diferentes pode aparecer no log de erro. A maioria com aspecto semelhante ao exemplo acima. O log de erro irá conter também a saída da depuração de scripts CGI. Qualquer informação escrita por um script CGI será copiado diretamente para o log de erro.
| Nível | Descrição | Exemplo |
| emerg | Emergência sistema inutilizável. | “Child cannot open lock file. Exiting” |
| alert | Tomar medidas imediatamente. | “getpwuid: couldn’t determine user name from uid” |
| crit | Condição crítica. | “socket: Failed to get a socket, exiting child” |
| error | Erro. | “Premature end of script headers” |
| warn | Condição de aviso. | “child process 1234 did not exit” |
| notice | Normal, mas significativa. | “httpd: caught SIGBUS, attempting to dump core in …” |
| info | Informativa. | “Server seems busy” |
| debug | Mensagens de nível de depuração | “Opening config file …” |
Tabela 3 – Níveis de erro servidor apache (APACHE,2010)
Log acesso.
Já os logs de acesso são totalmente configuráveis, o primeiro parâmetro é uma seqüência de formato, indicando as informações a serem incluídas em um arquivo de log e o formato em que deve ser escrito, o segundo parâmetro dá a seqüência de formato de um nome disponível, a sintaxe básica do formato de um log padrão do apache segue a seguinte:
LogFormat <formato do log> <nome definido em CustomLog>
LogFormat “% h% l% u \ t%”% r \ “>% s% b” comum
Os símbolos inscritos no formato do log podem ser entendidos com a tabela abaixo que foi retirada e traduzida a partir da documentação de referência do Apache
| Format String | Description |
| %% | O sinal de porcentagem |
| %…a | Endereço IP remoto |
| %…A | Endereço IP local |
| %…B | Bytes enviados (excluindo os cabeçalhos) |
| %…b | Bytes enviados (excluindo os headers); um traço (-) em vez de 0 |
| %…{Foobar}C | O conteúdo do nome do cookie |
| %…D | Tempo gasto para atender a solicitação, microssegundos |
| %…{FOOBAR}e | O conteúdo da variável de ambiente |
| %…f | Nome do arquivo |
| %…h | host remoto |
| %…H | protocolo do pedido |
| %…{Foobar}i | O conteúdo do nome do cabeçalho do pedido |
| %…l | Nome de registro remoto (de identd) |
| %…m | método Request |
| %…{Foobar}n | Conteúdo da nota Nome |
| %…{Foobar}o | Conteúdo do nome do cabeçalho de resposta |
| %…p | Canonical porta do servidor |
| %…P | Processo de identificação |
| %…{format}P | Dependendo do formato, ID de processo (PID) ou thread ID (TID) |
| %…q | Query string |
| %…r | Pedido de linha |
| %…s | status de resposta |
| %…t | Tempo, em formato de registro comum |
| %…{format}t | Tempo, em formato personalizado |
| %…T | Tempo gasto para atender a solicitação, em segundos |
| %…u | usuário remoto |
| %…U | A URL, excluindo a seqüência de consulta |
| %…v | Canonical nome do servidor |
| %…V | Nome do servidor de acordo com a directiva UseCanonicalName |
| %…X | O status da conexão no final do pedido |
| “X” para abortaos | |
| “+” para persistente | |
| “-” para fechado | |
| %…I | Bytes received, including request and headers, cannot be zero. |
| %…O | Bytes sent, including headers, cannot be zero. |
Tabela 4 Descrição siglas de log do apache.
(APACHE, Logs Acesso)
Para o entendimento de leitura de um log, vamos analisar um ex de log de um servidor web, no caso o do apache, o arquivo de log mais relevante para a segurança é o arquivo chamado error.log.
Os Log de Erros
Ao contrario de um arquivo de acesso, o ideal ao ler um arquivo de erro são apenas mensagens de Start e Stop comandadas ao servidor, qualquer outra mensagem é indesejada.
[Sat May 22 22:35:32 2010] [notice] caught SIGTERM, shutting down
[Sat May 22 22:37:57 2010] [notice] SELinux policy enabled; httpd running as context root:system_r:httpd_t:s0
[Sat May 22 22:37:57 2010] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Sat May 22 22:37:58 2010] [notice] Digest: generating secret for digest authentication …
[Sat May 22 22:37:58 2010] [notice] Digest: done
[Sat May 22 22:37:58 2010] [notice] Apache/2.2.3 (CentOS) configured — resuming normal operations
Um exemplo, seria uma mensagem de “Arquivo não Encontrado” este erro possivelmente significa que existe um site contendo um link para seu servidor cujo endereço não exista, poderemos observar um log de entrada como segue:
[Sat May 22 22:39:23 2010] [error] [client 189.72.220.73] File does not exist: /var/www/html/link_quebrado.
O procedimento neste caso seria avisar o responsável pelo site com o link inexistente e ou redirecionando para sua página inicial.
Manter os logs de erro o mais sucinto possível ajuda na detecção de tentativas de ataques ou pedidos maliciosos ao servidor, já que boa parte das tentativas de exploração são identificadas através do error.log
Um outro exemplo seria o seguinte:
merc [httpd @ localhost] $ grep-i access_log formmail
[Sun 29 de setembro 06:16:00 2003] [error] [client 66.50.34.7]
script não foi encontrado ou não fazer stat: / extra / httpd / cgi-bin / formmail.pl
merc [httpd @ localhost] $
Para evitar de expor um e-mail de contato e ser vítima de Spam, é comum utilizar um script para criar um formulário para recebimento de mensagem ocultando assim o e-mail, mas este script chamado formmail , abre uma série de brechas principalmente de segurança, uma delas curiosamente permite o uso do formulário para o envio de spam.
Logs graves como falha de segmentação pode indicar falha de algum módulo do apache ou ataque DOS ou buffering veja exemplo log de falha de segmentação:
[Sun Sep 29 06:16:00 2002] [error] [notice] child pid 1772
exit signal Segmentation fault (11)
Verificar os logs de acesso (access.log) no horário em que ocorreu o erro pode dar uma pista da causa do problema.
Através dos logs também é possível verificar ataques a sistemas operacionais, veja a seqüência do log abaixo que mostra nas entradas tipos de ataque ao Windows vista, apenas observe a seqüência exe no log de acesso, veja exemplo:
[root@localhost logs]# tail –f
200.216.141.59 – - [29/Sep/2003:06:25:22 +0200] “GET /_vti_bin/shtml.exe HTTP/1.0″ 404 288
200.216.141.59 – - [29/Sep/2003:06:31:33 +0200] “GET /_vti_bin/shtml.exe HTTP/1.0″ 404 288
193.253.252.93 – - [02/Oct/2003:02:17:53 +0200] “GET /scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir+c:\ HTTP/1.1″ 404 319
151.4.241.194 – - [02/Oct/2002:02:34:46 +0200] “GET /scripts/..%255c%255c../winnt/system32/cmd.exe?/c+dir” 404 –
Uma dificuldade em encontrar anomalias nos logs é a técnica de uso de URLs codificadas, esta técnica substitui o caractere pelo seu código ASCII equivalente.
| Tabela conversão principais caracteres para ASCII | |||||||
| Caracter | Código | Caracter | Código | Caracter | Código | Caracter | Código |
| (espaço) | 20% | ? | %3f | & | 26% | % | 25% |
| # | 23% | / | %2f | < | %3c | > | %3e |
| : | %3a | / | %2f | | | %7c | ; | %3b |
Tabela 5 – Fonte (E-PLANING,2010).
Veja um exemplo de como pode ser escrito:
Em caractere:
151.4.241.194 – - [02/Oct/2002:02:34:46 +0200] “GET /scripts/..%255c%255c../winnt/system32/cmd.exe?/c+dir” 404 –
Em código ASCII:
151.4.241.194 – - [02/Oct/2003:02:34:46 +0200] “GET
/scripts/..%255c%255c../winnt/system32/cmd.%65x%65?/c+dir” 404 –
Quando codificados desta forma, esta URL passaria despercebido aos olhos ou mesmo a um filtro grep. Para que uma busca seja eficaz, é necessário decodificar todas as URLs dos arquivos de log, existem diversos scripts e programas, feito isto é possível comparar e identificar os logs suspeitos.


Os três aesquerda são programadores PHP , os três a direita são programadores Ruby, e no meio Java, que ficou na desvantagem tanto de contingente quanto de numero de alfinetadas..hehe, foi faisca para todo lado.

