Kali Linux Network Scanning Cookbook para download

O pessoal do foxebook liberou para consulta o livro Kali Linux Network Scanning Cookbook.

As 400 páginas do livro são dividas nos seguintes capítulos:

Chapter 1: Getting Started
Chapter 2: Discovery Scanning
Chapter 3: Port Scanning
Chapter 4: Fingerprinting
Chapter 5: Vulnerability Scanning
Chapter 6: Denial of Service
Chapter 7: Web Application Scanning
Chapter 8: Automating Kali Tools

Leitura mais do que recomendada para aqueles que desejam aprender um pouco mais sobre segurança

P.S.: Para facilitar a vida da galera, segue o link para download do livro

Tem um link alternativo na academia.edu

Fonte: CorujadeTI

Sem categoria

Entendendo a estrutura de diretórios do Linux

A estrutura de diretórios do Linux é completamente diferente da estrutura presente no Windows, chegando ao ponto de não apresentar semelhança alguma com aquele sistema operacional. Porém, tal estrutura é bastante semelhante à da maioria dos outros sistemas *nix que você vai encontrar pela frente. Por estas e outras razões é muito importante que você saiba o papel exato de cada um dos diretórios e os use de acordo.

O objetivo deste post é dar uma breve explicação sobre o papel de cada um deles para que você tenha uma ideia do que vai encontrar neles ou mesmo para saber onde colocar os arquivos.

O diretório /

O diretório / (diz-se diretório “root”, mas não tem nada a ver com o usuário “root”) é o topo da hierarquia de diretórios do Linux. Todos os outros diretórios ficam abaixo dele e apenas o usuário root pode criar diretórios neste nível.

O diretório /bin

O diretório /bin contém os comandos essenciais do sistema, que podem ser utilizados tanto pelo root quanto por qualquer outro usuário não-privilegiado. Aqui você vai encontrar os comandos que mais vai usar como o ls, cat, chown, cp, date, mkdir, etc.

Este diretório contrasta com o /sbin, que contém comandos que podem ser usados apenas pelos administradores do sistema, com permissões elevadas.

O diretório /boot

Se alguma coisa é necessária durante o boot do sistema, ela será armazenada neste diretório. Da imagem do kernel ao arquivo de configuração do GRUB, tudo fica armazenado neste diretório que sempre deve estar na mesma partição do /. Qualquer coisa não-essencial para que o sistema inicialize está disponível ou em /bin ou em /sbin.

Não recomendo que você altere as coisas aqui a não ser que tenha a mais absoluta certeza do que está fazendo. Se o sistema não inicializar, vai ser bem complicado resolver o problema!

O diretório /dev

Tudo no Linux é um arquivo. Tudo, mas tudo mesmo, inclusive os dispositivos que estão conectados na sua máquina! Seja placa de som, rede, vídeo, partição do HD, teclado, mouse, pendrive enfim, tudo é um arquivo. E os arquivos de sistema que representam os dispositivos estão todos armazenados no diretório /dev.

Atualmente, você raramente precisa entrar neste diretório pra fazer alguma coisa já que tudo é tratado automaticamente pelo Linux. Mas, pra conferir se um dispositivo realmente foi reconhecido pelo sistema e está pronto para operar, você pode ver se o arquivo relacionado a ele foi criado neste diretório.

NOTA: Tome muito cuidado ao fazer alterações em qualquer arquivo ou link no diretório /dev. Fazer alguma coisa errada aqui pode fazer um dispositivo parar de funcionar corretamente!

O diretório /etc

Você já deve ter ouvido falar nos famosos “arquivos de configuração” do Linux. Estão todos (em um sistema bem configurado) presentes neste diretório e subdiretórios. Seja um software do sistema ou um programa que você mesmo instalou, toda a configuração é feita através de um arquivo texto puro (não um binário ou executável, um arquivo texto simples).

Por exemplo, neste diretório você encontra o arquivo de configuração do SSH (dentro do subdiretório /etc/ssh), do sudo(/etc/sudoers), do Apache, etc. Enfim, se você precisa mudar a configuração de um serviço do sistema é muito provável que você vá editar um arquivo dentro do /etc.

O diretório /home

A esta altura você já deve saber que o Linux é um sistema multi-usuário. Para o monte de usuários (e seus respectivos arquivos) que um sistema Linux pode ter organizados, foi criado o diretório /home.

Este é o diretório pessoal de cada usuário criado junto com a conta. Neste diretório o dono pode fazer o que quiser: colocar seus arquivos pessoais, instalar programas, criar seus próprios arquivos de configuração personalizados para algum programa, etc.

Como você pode imaginar, o /home pode acabar ficando muito grande. Por isso, em alguns sistemas o administrador define quotas para garantir que os diretórios não passem de um determinado tamanho. O /home também pode ser montado através de NFS e ficar armazenado em uma outra máquina da rede.

O diretório /lib

No /lib você encontra todas as bibliotecas que são necessárias para que os outros programas do sistema sejam executados corretamente. Pense nos arquivos presentes dentro do /lib como as DLLs do Windows. Se elas não estiverem no lugar certo, na versão certa na hora da execução do programa as coisas não vão funcionar como deveriam.

Minha recomendação é que você não altere os arquivos presentes neste diretório. Deixe que o sistema faz tudo sozinho!

O diretório /mnt

O diretório /mnt foi criado com o intuito de ser um ponto de montagem para sistemas de arquivos externos ao sistema. Por exemplo, nele você pode montar um CD-ROM, um pendrive, um HD removível, etc. e usá-lo normalmente para armazenar arquivos.

Atualmente, este diretório já não é mais tão utilizado como antigamente. Distribuições Linux mais modernas têm preferido usar o diretório /media para montar estes tipos de dispositivos. Este diretório funciona da mesma maneira que o /mnt e tem a mesma finalidade.

O diretório /proc

O /proc não é um diretório criado no seu disco rígido. Ele é uma estrutura de dados criada na memória RAM da sua máquina.

Dentro deste diretório você vai encontrar informações sobre o sistema como um todo. Por exemplo, informações sobre o processador, memória RAM, dispositivos montados, quais processos estão sendo executados no momento (inclusive os argumentos de linha de comando utilizados para iniciá-los), entre várias outras coisas. Alguns comandos do sistema simplesmente leem os arquivos presentes neste diretório para apresentar as informações na tela para você. Exemplos destas ferramentas são lsmod, lsusb e lspci

O diretório /opt

Aqui devem ficar os arquivos de qualquer software que não faça parte da distribuição básica. Ou pelo menos era assim quando ele foi criado!

Hoje em dia, a maioria dos pacotes de software distribuidos para vários sistemas Linux diferentes simplesmente não usam o /opt. Portanto, geralmente este diretório fica vazio.

O diretório /root

Assim como todos os outros usuários do sistema, o usuário root também tem o seu próprio diretório pessoal. Porém, ao invés de ficar no /home, o diretório pessoal do usuário root fica diretamente abaixo do diretório root em /root. Este diretório pode ser acessado apenas pelo root e, por padrão, as quotas definidas para o sistema não se aplicam aqui. Além disso, 5% do espaço da partição ficam reservados para o /root.

O principal motivo para o /root não ficar embaixo de /home é que o /home não necessariamente fica na mesma partição do “/”. Portanto, se algum problema ocorrer e a partição /home não puder ser montada (e isso acontece, acredite em mim!) o root não poderia acessar o seu próprio diretório, causando problemas chatos de se resolver no sistema.

O diretório /sbin

Em contraste com o /bin, que armazena ferramentas essenciais que podem ser utilizados por qualquer usuário, o /sbin contém ferramentas que apenas usuários com privilégios mais altos (ou através do sudo) podem usar. Se algum comando administrativo não está presente aqui, ele terá sido armazenado em /usr/sbin.

Exemplos de comandos que você encontra aqui são ifconfig, fdisk, init, etc.

O diretório /tmp

O /tmp é simplesmente um diretório temporário para que alguma aplicações (ou você mesmo) crie e use arquivos que serão úteis apenas por um curto período de tempo. Todos os usuários do sistema podem escrever neste diretório e todo o conteúdo é removido sempre que o sistema é reiniciado.

NOTA: Veja que o diretório /tmp tem todo o seu conteúdo removido quando o sistema é reiniciado. Por isso, nunca deixe nada de importante lá se não você vai perdê-lo!

O diretório /usr

Este é o diretório que sem dúvidas vai ocupar mais espaço no seu disco rígido. Originalmente, dentro do /usr armazenava-se tudo relacionado ao usuário (inclusive o diretório home, ou seja, não se usava o /home). Hoje em dia a ideia deste diretório é mais armazenar dados e programas que são utilizados por usuários normais (não-privilegiados) do sistema.

O /usr geralmente é montado na sua própria partição, separado do /.

 

Dentro deste diretório, entre outras coisas, você encontra o X Window System. Alguns dos subdiretórios mais importantes são o /usr/include (que contém os headers de desenvolvimentos das bibliotecas. Bastante necessário quando se compila um programa do zero), /usr/info (contém os arquivos de ajuda usados pelo comando info) e /usr/man (que contém as man pages, usadas pelo comando man).

O diretório /var

Como o nome indica, este diretório contém todo tipo de informações que variam (mudam) com o tempo. Arquivos de log,e-mail, spool de impressão, etc. todos estão presentes aqui. O /var não pode ser compartilhado com outras máquinas pois as informações que ele contém são relevantes apenas para a máquina local. Também é interessante que o /var seja montado em uma partição à parte, diferente da partição do /.

Alguns subdiretórios importantes são /var/log (que contém os arquivos de log do sistema), /var/mail (e-mails internos), /var/cache (é aqui onde as aplicações armazenam informações de cache), /var/backups (que contém backups de vários arquivos importantes do sistema, como /etc/shadow).

Sem categoria

Confundindo Scanners (spiders) na sua aplicação Web

Texto do Pedro Pereira

Aplicações WEB geralmente são desenvolvidas por profissionais que não têm o conhecimento adequado de segurança para conseguir proteger estas aplicações. Em outros casos, existe o problema de “deadlines”, onde o desenvolvimento deve ser finalizado em uma determinada data não importa o que aconteça. Nestes casos, a segurança fica sempre em segundo plano.

Por isso, tudo o que você puder fazer para atrapalhar o atacante e tomar providências antes que ele consiga extrair informações úteis ou mesmo antes que ele consiga comprometer a aplicação vai te ajudar bastante. Neste aspecto, o WebLayrinth pode ser uma mão na roda.

Continue lendo para entender o problema que ele resolve, como ele resolve e como configurá-lo para começar a ajudar você a manter tudo seguro – como deveria ser.

O problema

O primeiro passo de qualquer atacante (pelo menos dos atacantes inteligentes) é fazer o reconhecimento da aplicação. Descobrir qual linguagem foi usada para desenvolvê-la, qual o servidor web está hospedando a página, frameworks, etc. No meio desse reconhecimento, também é muito importante que o hacker verifique quais são os diretórios que formam a hierarquia da página ou mesmo qualquer outro que não faça parte da aplicação mas que esteja acessível.

 

Aí você pensa: “Mas que coisa idiota! Pra quê perder tempo com isso?” Eu te explico.

Muitos administradores de servidores acham que ninguém consegue ver os diretórios que não fazem parte da aplicação principal. Por isso, acabam armazenando lá arquivos extremamente sensíveis e também diretórios com informações às quais ninguém nunca deveria ter acesso! Procurar por estes diretórios é um passo importante no reconhecimento da aplicação e geralmente é feito por um scanner, comumente chamado de spider.

O papel do spider é seguir todos os links e registrar todas as URLs válidas daquela aplicação. E isso vai ajudar a encontrar arquivos com senhas, dumps de bancos de dados, áreas administrativas da aplicação/site, etc. Nunca subestime esse tipo de scan! Ele vai ajudar você a encontrar muita informação útil para conseguir atacar a aplicação mais facilmente!

Infelizmente, não é muito fácil se “defender” deste tipo de vazamento de informação. A principal ação a ser tomada, obviamente, é não armazenar informações sensíveis no servidor web de maneira alguma – por mais que você use senha. Faça isso somente em último caso.

A outra maneira é através de pequenas aplicações desenvolvidas para gerar um “labirinto” infinito de diretórios, que impede – ou pelo menos dificulta bastante – a vida do hacker quando ele tentar identificar quais destes diretórios são válidos. Existem vários scripts que fazem isso, um deles é o Weblabyrinth que vamos analisar neste post.

Uma possível solução com WebLabyrinth

O WL propõe uma solução bem criativa para o problema. Através de um link escondido nas suas páginas (os usuários não têm a necessidade de vê-lo) o scanner/crawler vai cair dentro de uma hierarquia de diretórios falsos infinita criada dinamicamente pelo WebLaryrinth. Essa hierarquia vai fazer com que o scanner nunca pare de encontrar novos caminhos dentro do seu site e demore muito para conseguir concluir o scan – alguns podem chegar até a travar de vez. Como resultado no lado do hacker, haverão milhões de diretórios falsos que vão acabar ofuscando os diretórios válidos da sua aplicação que você não queria que ele visse.

Esta solução atrasa bastante o atacante e te dá tempo para detectar o ataque, entender o que está acontecendo e quais são as melhores atitudes a serem tomadas para mitigar o efeito dele. Porém, nem tudo é alegria e você precisa tomar os seguintes cuidados para que a instalação do WebLabyrinth não acabe sendo um tiro no pé:

  • * Deixe o link que leva para o WebLabyrinth escondido dos usuários para que eles não entrem no labirinto por engano. Você também precisa esconder este link do Google para evitar uma possível punição por parte deles. Use o parâmetro “nofollow” no link, assim:
    <a href=”/weblabyrinth” rel=”nofollow”>labirinto</a>

    O Google (e outros sistemas de busca) não indexa links com “nofollow” e por isso o crawler dele não vai cair lá dentro do buraco negro, preservando o seu site no ranking do Google – o que é importantíssimo para qualquer empresa hoje em dia.

  • Também adicione o link para o labirinto ao robots.txt. Crawlers legítimos sempre obedecem o robots.txt. Crawlers que possivelmente estão sob o controle de um hacker, sempre lêem o robots.txt atrás de diretórios interessantes para scanear.

Sempre que você receber um e-mail do WebLabyrinth, fique alerta! É um possível scan hostil e você deve analisar com muito cuidado o que está acontecendo! Ou seja, é importante ter sempre em mente que o WL não vai bloquear um ataque. Ele vai atrasar o atacante para que você tome as ações para proteger a sua infraestrutura contra um possível ataque. Nunca se esqueça disso!

A meu ver, o principal ponto positivo do WL é que tanto a instalação quanto a configuração do software para funcionar no seu servidor são extremamente simples. Você não vai penar nem um segundo durante o processo e depois que tudo estiver concluído, vai ter um ambiente mais bem monitorado.

Dependências

Antes de partirmos para a instalação, resolvi colocar este tópico aqui para que você fique atento às dependências que o WebLabyrinth tem para conseguir funcionar direito.

Você vai precisar do seguinte:

  • Apache
  • mod_rewrite
  • PHP
  • SQLite
  • Extensão SQLite para PHP
  • Suporte à função mail() no PHP

Depois que tudo isso tiver sido instalado corretamente no servidor onde você vai configurar o WebLabyrinth, podemos partir para a configuração da aplicação em si. Você vai ver que não é nenhum bicho de sete cabeças e vai querer fazer isso em todos os seus servidores! 😀

Instalação

A instalação é um pouco longa, porém não é difícil. Vamos lá, primeiro baixe a versão mais recente do Weblabyrinth de weblabyrinth.googlecode.com e coloque em um diretório temporário qualquer. Depois descompacte:
# tar xzvf weblabyrinth-0.3.2.tar.gz

Agora coloque os arquivos dentro de um diretório onde o servidor web possa acessá-los:
# cp weblabyrinth-0.3.2 /var/www/labyrinth/

Entre no diretório do software e renomeie o arquivo /var/www/labyrinth/EXAMPLE.htaccess para .htaccess:
# mv EXAMPLE.htaccess .htaccess

Agora, crie um banco de dados do SQLite e dê as permissões para o usuário do servidor web:
# mkdir /opt/weblabyrinth
# cat /var/www/labyrinth/labyrinth.sql | sqlite /opt/weblabyrinth/labyrinth.db
# chown -R www-data:www-data /opt/weblabyrinth

Agora, vamos editar o arquivo de configuração /var/www/labyrinth/config.inc.php e fazer as seguintes alterações:
‘alert_levels_deep’ => 3, -> Esta opção vai definir a quantidade de níveis que um crawler deve descer antes de gerar um alerta para você.

‘alert_email‘ => array(
‘enabled’ => ‘true’,
‘address’ => ‘pedro@pedropereira.net’
), -> Aqui você define se avisos por e-mail deverão ser enviados através da primeira opção e, caso você sete isto para true, para qual email as mensagens devem ser enviadas.

‘alert_ids’ => array(
‘enabled’ => ‘true’,
‘text’ => ‘pedropereirapedropereira’
) -> Esta opção vai fazer com que o Weblabyrinth sempre envie a palavra definida em “text” quando algum cliente pedir as páginas dele. Assim, você pode escrever uma assinatura de Snort por exemplo que detecte tráfego com esta palavra-chave e dispare um alerta para você. Neste caso, você poderia bloquear o IP de origem da conexão que está dentro do labirinto.

Agora, vamos definir alguns aliases de diretórios que são geralmente procurados por crawlers, para aumentarmos as chances de pegá-los e jogá-los dentro do labirinto facilitando a sua detecção. Onde fazer isso vai depender bastante da configuração do seu Apache, mas geralmente você vai fazer isso em /etc/apache2/httpd.conf. Alguns aliases de sugestão para você:
Alias /admin /var/www/labyrinth/
Alias /secret /var/www/labyrinth/
Alias /pdc-only /var/www/labyrinth/
Alias /private /var/www/labyrinth/
Alias /phpmyadmin /var/www/labyrinth/
Alias /pma /var/www/labyrinth/
Alias /dbadmin /var/www/labyrinth/
Alias /phppgadmin /var/www/labyrinth/
Alias /myadmin /var/www/labyrinth/
Alias /db /var/www/labyrinth/
Alias /mysql /var/www/labyrinth/
Alias /mysqladmin /var/www/labyrinth/
Alias /phpmyadmin /var/www/labyrinth/
Alias /scripts /var/www/labyrinth/
Alias /sqlweb /var/www/labyrinth/
Alias /web /var/www/labyrinth/
Alias /webadmin /var/www/labyrinth/
Alias /webdb /var/www/labyrinth/
Alias /websql /var/www/labyrinth/

Lembre-se de não colocar aliases para diretórios que você realmente usa ou você vai sempre cair dentro do labirinto. Se você usa algum nome que está acima, simplesmente não adicione a linha no seu httpd.conf.

Pronto, tudo instalado agora é só esperar a primeira vítima cair no seu labirinto e você pegar o hacker com as calças na mão! 🙂

Conclusão

Como dito no post, o WebLabyrinth não é uma solução para proteger a sua infraestrutura contra ataques, ele não vai bloquear um ataque como um IPS faria: o objetivo é atrasar o atacante enquanto você toma providências para se proteger. Com os alertas que ele envia, você fica sabendo na hora o que está acontecendo, ganhando um ambiente mais bem monitorado como recompensa.

Ao usar uma solução como esta, é importantíssimo que você tome muito cuidado para não acabar prejudicando a sua empresa com o Google. Sempre tenha certeza de que está usando “nofollow” no link que leva ao WL e também que você adicionou a URL dele ao robots.txt. Também tenha certeza de que não está deixando qualquer usuário ver o link para a aplicação para evitar que ele entre no labirinto sem querer – arruinando a experiência dele com a sua aplicação.

Sem categoria

Confundindo Scanners (spiders) na sua aplicação Web

Texto do Pedro Pereira

Aplicações WEB geralmente são desenvolvidas por profissionais que não têm o conhecimento adequado de segurança para conseguir proteger estas aplicações. Em outros casos, existe o problema de “deadlines”, onde o desenvolvimento deve ser finalizado em uma determinada data não importa o que aconteça. Nestes casos, a segurança fica sempre em segundo plano.

Por isso, tudo o que você puder fazer para atrapalhar o atacante e tomar providências antes que ele consiga extrair informações úteis ou mesmo antes que ele consiga comprometer a aplicação vai te ajudar bastante. Neste aspecto, o WebLayrinth pode ser uma mão na roda.

Continue lendo para entender o problema que ele resolve, como ele resolve e como configurá-lo para começar a ajudar você a manter tudo seguro – como deveria ser.

O problema

O primeiro passo de qualquer atacante (pelo menos dos atacantes inteligentes) é fazer o reconhecimento da aplicação. Descobrir qual linguagem foi usada para desenvolvê-la, qual o servidor web está hospedando a página, frameworks, etc. No meio desse reconhecimento, também é muito importante que o hacker verifique quais são os diretórios que formam a hierarquia da página ou mesmo qualquer outro que não faça parte da aplicação mas que esteja acessível.

 

Aí você pensa: “Mas que coisa idiota! Pra quê perder tempo com isso?” Eu te explico.

Muitos administradores de servidores acham que ninguém consegue ver os diretórios que não fazem parte da aplicação principal. Por isso, acabam armazenando lá arquivos extremamente sensíveis e também diretórios com informações às quais ninguém nunca deveria ter acesso! Procurar por estes diretórios é um passo importante no reconhecimento da aplicação e geralmente é feito por um scanner, comumente chamado de spider.

O papel do spider é seguir todos os links e registrar todas as URLs válidas daquela aplicação. E isso vai ajudar a encontrar arquivos com senhas, dumps de bancos de dados, áreas administrativas da aplicação/site, etc. Nunca subestime esse tipo de scan! Ele vai ajudar você a encontrar muita informação útil para conseguir atacar a aplicação mais facilmente!

Infelizmente, não é muito fácil se “defender” deste tipo de vazamento de informação. A principal ação a ser tomada, obviamente, é não armazenar informações sensíveis no servidor web de maneira alguma – por mais que você use senha. Faça isso somente em último caso.

A outra maneira é através de pequenas aplicações desenvolvidas para gerar um “labirinto” infinito de diretórios, que impede – ou pelo menos dificulta bastante – a vida do hacker quando ele tentar identificar quais destes diretórios são válidos. Existem vários scripts que fazem isso, um deles é o Weblabyrinth que vamos analisar neste post.

Uma possível solução com WebLabyrinth

O WL propõe uma solução bem criativa para o problema. Através de um link escondido nas suas páginas (os usuários não têm a necessidade de vê-lo) o scanner/crawler vai cair dentro de uma hierarquia de diretórios falsos infinita criada dinamicamente pelo WebLaryrinth. Essa hierarquia vai fazer com que o scanner nunca pare de encontrar novos caminhos dentro do seu site e demore muito para conseguir concluir o scan – alguns podem chegar até a travar de vez. Como resultado no lado do hacker, haverão milhões de diretórios falsos que vão acabar ofuscando os diretórios válidos da sua aplicação que você não queria que ele visse.

Esta solução atrasa bastante o atacante e te dá tempo para detectar o ataque, entender o que está acontecendo e quais são as melhores atitudes a serem tomadas para mitigar o efeito dele. Porém, nem tudo é alegria e você precisa tomar os seguintes cuidados para que a instalação do WebLabyrinth não acabe sendo um tiro no pé:

  • * Deixe o link que leva para o WebLabyrinth escondido dos usuários para que eles não entrem no labirinto por engano. Você também precisa esconder este link do Google para evitar uma possível punição por parte deles. Use o parâmetro “nofollow” no link, assim:
    <a href=”/weblabyrinth” rel=”nofollow”>labirinto</a>

    O Google (e outros sistemas de busca) não indexa links com “nofollow” e por isso o crawler dele não vai cair lá dentro do buraco negro, preservando o seu site no ranking do Google – o que é importantíssimo para qualquer empresa hoje em dia.

  • Também adicione o link para o labirinto ao robots.txt. Crawlers legítimos sempre obedecem o robots.txt. Crawlers que possivelmente estão sob o controle de um hacker, sempre lêem o robots.txt atrás de diretórios interessantes para scanear.

Sempre que você receber um e-mail do WebLabyrinth, fique alerta! É um possível scan hostil e você deve analisar com muito cuidado o que está acontecendo! Ou seja, é importante ter sempre em mente que o WL não vai bloquear um ataque. Ele vai atrasar o atacante para que você tome as ações para proteger a sua infraestrutura contra um possível ataque. Nunca se esqueça disso!

A meu ver, o principal ponto positivo do WL é que tanto a instalação quanto a configuração do software para funcionar no seu servidor são extremamente simples. Você não vai penar nem um segundo durante o processo e depois que tudo estiver concluído, vai ter um ambiente mais bem monitorado.

Dependências

Antes de partirmos para a instalação, resolvi colocar este tópico aqui para que você fique atento às dependências que o WebLabyrinth tem para conseguir funcionar direito.

Você vai precisar do seguinte:

  • Apache
  • mod_rewrite
  • PHP
  • SQLite
  • Extensão SQLite para PHP
  • Suporte à função mail() no PHP

Depois que tudo isso tiver sido instalado corretamente no servidor onde você vai configurar o WebLabyrinth, podemos partir para a configuração da aplicação em si. Você vai ver que não é nenhum bicho de sete cabeças e vai querer fazer isso em todos os seus servidores! 😀

Instalação

A instalação é um pouco longa, porém não é difícil. Vamos lá, primeiro baixe a versão mais recente do Weblabyrinth de weblabyrinth.googlecode.com e coloque em um diretório temporário qualquer. Depois descompacte:
# tar xzvf weblabyrinth-0.3.2.tar.gz

Agora coloque os arquivos dentro de um diretório onde o servidor web possa acessá-los:
# cp weblabyrinth-0.3.2 /var/www/labyrinth/

Entre no diretório do software e renomeie o arquivo /var/www/labyrinth/EXAMPLE.htaccess para .htaccess:
# mv EXAMPLE.htaccess .htaccess

Agora, crie um banco de dados do SQLite e dê as permissões para o usuário do servidor web:
# mkdir /opt/weblabyrinth
# cat /var/www/labyrinth/labyrinth.sql | sqlite /opt/weblabyrinth/labyrinth.db
# chown -R www-data:www-data /opt/weblabyrinth

Agora, vamos editar o arquivo de configuração /var/www/labyrinth/config.inc.php e fazer as seguintes alterações:
‘alert_levels_deep’ => 3, -> Esta opção vai definir a quantidade de níveis que um crawler deve descer antes de gerar um alerta para você.

‘alert_email‘ => array(
‘enabled’ => ‘true’,
‘address’ => ‘pedro@pedropereira.net’
), -> Aqui você define se avisos por e-mail deverão ser enviados através da primeira opção e, caso você sete isto para true, para qual email as mensagens devem ser enviadas.

‘alert_ids’ => array(
‘enabled’ => ‘true’,
‘text’ => ‘pedropereirapedropereira’
) -> Esta opção vai fazer com que o Weblabyrinth sempre envie a palavra definida em “text” quando algum cliente pedir as páginas dele. Assim, você pode escrever uma assinatura de Snort por exemplo que detecte tráfego com esta palavra-chave e dispare um alerta para você. Neste caso, você poderia bloquear o IP de origem da conexão que está dentro do labirinto.

Agora, vamos definir alguns aliases de diretórios que são geralmente procurados por crawlers, para aumentarmos as chances de pegá-los e jogá-los dentro do labirinto facilitando a sua detecção. Onde fazer isso vai depender bastante da configuração do seu Apache, mas geralmente você vai fazer isso em /etc/apache2/httpd.conf. Alguns aliases de sugestão para você:
Alias /admin /var/www/labyrinth/
Alias /secret /var/www/labyrinth/
Alias /pdc-only /var/www/labyrinth/
Alias /private /var/www/labyrinth/
Alias /phpmyadmin /var/www/labyrinth/
Alias /pma /var/www/labyrinth/
Alias /dbadmin /var/www/labyrinth/
Alias /phppgadmin /var/www/labyrinth/
Alias /myadmin /var/www/labyrinth/
Alias /db /var/www/labyrinth/
Alias /mysql /var/www/labyrinth/
Alias /mysqladmin /var/www/labyrinth/
Alias /phpmyadmin /var/www/labyrinth/
Alias /scripts /var/www/labyrinth/
Alias /sqlweb /var/www/labyrinth/
Alias /web /var/www/labyrinth/
Alias /webadmin /var/www/labyrinth/
Alias /webdb /var/www/labyrinth/
Alias /websql /var/www/labyrinth/

Lembre-se de não colocar aliases para diretórios que você realmente usa ou você vai sempre cair dentro do labirinto. Se você usa algum nome que está acima, simplesmente não adicione a linha no seu httpd.conf.

Pronto, tudo instalado agora é só esperar a primeira vítima cair no seu labirinto e você pegar o hacker com as calças na mão! 🙂

Conclusão

Como dito no post, o WebLabyrinth não é uma solução para proteger a sua infraestrutura contra ataques, ele não vai bloquear um ataque como um IPS faria: o objetivo é atrasar o atacante enquanto você toma providências para se proteger. Com os alertas que ele envia, você fica sabendo na hora o que está acontecendo, ganhando um ambiente mais bem monitorado como recompensa.

Ao usar uma solução como esta, é importantíssimo que você tome muito cuidado para não acabar prejudicando a sua empresa com o Google. Sempre tenha certeza de que está usando “nofollow” no link que leva ao WL e também que você adicionou a URL dele ao robots.txt. Também tenha certeza de que não está deixando qualquer usuário ver o link para a aplicação para evitar que ele entre no labirinto sem querer – arruinando a experiência dele com a sua aplicação.

Sem categoria

Recuperaçao de arquivos apagados no Linux

Texto do famate, do http://segurancaimporta.blogspot.com.br/

Somente quem ja passou por isso sabe como é.
De um momento para o outro seus dados sumiram.
Recuperação de arquivos em Linux ( ext2, ext3, ext4, etc ) sempre foi tarefa dificil.

Passei por um situação onde, durante uma migração de servidores, um amigo meu  inverteu os parametros de origem e destino e …. copiou o HD limpo para o HD com os dados.
O processo foi parado alguns segundos após o início, porem o desastre já tinha ocorrido.

Levei para a empresa o kit basico com HD limpo, bloqueador de escritas e o bom BackTrack.
Pensavamos como fazer a recuperação. Necessitavamos de uns 80 GB de dados. Tinhamos alguns arquivos antigos para verificar a estrutura, porem alguns arquivos eram grandes, com mais de 2 GB de tamanho e acabando com varios zeros, o que dificultava o uso de ferramentas de carvin, como o foremost e o scalpel.

Após alguns buscas apareceu o software que parecia ser a solução . Extundelete ( http://sourceforge.net/projects/extundelete/ )

Efetuamos um teste e o Extundelete foi capaz de recuperar diretórios completos e nomes de arquivos.
Colocamos ele para fazer a recuperação e o mesmo recuperou 90% do que necessitavamos.

O programa é leve e faz o que se propõe. (A ferramenta é MAGICA, e funciona !!!!)

Alguns arquivos muito grandes, por algum motivo desconhecido, não foram recuperados corretamente.
Durante a recuperação, o arquivo apagado aparecia, crescendo de tamanho (sendo recuperado), porem quando a recuperação acabava o mesmo estava com 10% do tamanho original esperado.  ( não se pode ganhar todas)
Teve tambem alguns arquivos que não foram recuperados. :-/

Gostariamos de agradecer o desenvolvedor, mas sentimos falta de uma coisa …  um link para fazer uma doação .

Se voce trabalha com Linux/ Unix e para voce Segurança Importa, tenha a mão Extundelete.

Sem categoria