Computação & Tecnologia
Segurança
10 coisas que você deve fazer antes de conectar seu Linux à Internet
10/04/09
Este texto é uma tradução. O texto original está disponível no site http://www.builderau.com.au/program/linux/soa/10_things_you_should_do_to…?feed=rss
Não coloquei algumas partes do texto nas quais o autor focava muito no Mandriva. Tentei deixar o texto um pouco generalizado, podendo ser usado para qualquer distribuição que você queira.
Finalidade
O Linux, assim como o Windows, é apenas um sistema operacional. Quando falo com colegas que estão usando o Linux pela primeira vez, esta é a primeira coisa que deixo clara. O Linux não é uma varinha de condão que pode ser utilizada para resolver todos os problemas da informática. O Linux tem vários problemas, assim como o Windows. Não há um sistema operacional perfeito ou completamente seguro. Essa máquina vai ser um servidor ou uma estação de trabalho? Pensando nisso, vários problemas são evitados.
Instalação
Diferente do Windows, o Linux não tem uma versão específica para servidores, outra para estações de trabalho, etc. Durante uma instalação típica, a escolha sobre quais softwares serão instalados é sua. Portanto, de acordo com os softwares que você instala, você define o papel da máquina: servidor ou estação de trabalho. Por isso, você deve saber muito bem quais são os pacotes que o instalador da sua distribuição está instalando para você. Por exemplo, algumas distribuições irão instalar e configurar um servidor Samba ou um servidor de email como parte da instalação básica. Dependendo da finalidade do seu computador e do nível de segurança que você quer, esses serviços podem ser desnecessários ou indesejados. Tirando um tempinho para se familiarizar com o instalador da sua distribuição pode evitar muitas dores de cabeça e reinstalações.
Instalar e configurar um firewall
Um firewall provê uma camada a mais de segurança em qualquer rede. Estes softwares permitem que você filtre o tráfego que chega no seu PC, evitando problemas. O software Shorewall (que utiliza o IPTables/Netfilter como backend) simplifica a configuração de um firewall pessoal (um outro pacote bastante interessante é o KMyFirewall, que utiliza o Qt). Instalando e configurando firewalls para sua estação o quanto antes, você pode restringir ou bloquear determinados tipos de tráfego, tanto entrando quanto saindo do seu PC.
Bloquear ou permitir determinados tipos de tráfego da rede é apenas uma camada de segurança, mas como você pode adicionar mais segurança (além das regras do firewall) para um serviço que você realmente precisa que usuários da internet ou intranet utilizem no seu computador? Segurança baseada em hosts é mais uma camada de segurança.
Configurando os arquivos /etc/hosts.deny e /etc/hosts.allow
Na seção anterior, vimos como configurar um firewall para permitir conexões de outros hosts aos serviços que a nossa máquina está provendo utilizando um firewall. Para aumentar a segurança contra tráfego indesejado ou atacantes, podemos limitar os hosts que se conectam a determinados serviços. Os arquivos /etc/hosts.deny e /etc/hosts.allow nos permitem fazer isso.
Quando um computador tenta acessar um serviço como o SSH, por exemplo, os arquivos /etc/hosts.deny e /etc/hosts.allow são processados e o acesso será permitido ou negado de acordo com as regras destes arquivos. Geralmente, se você esta instalando uma estação de trabalho, é útil se colocar a seguinte linha no /etc/hosts.deny:
ALL:ALL
Isso vai negar o acesso de qualquer host a qualquer serviço. Parece muito restritivo à primeira vista, mas depois disso você pode adicionar hosts no arquivo /etc/hosts.allow para permitir o acesso aos serviços. Abaixo você encontra um exemplo que permite a alguns hosts conectar ao SSH:
sshd: 192.168.0.1 #permite o host 192.168.0.1 acessar o SSH
sshd: foo.bar.com #permite o acesso do host foo.bar.com ao SSH
Estes dois arquivos oferecem uma filtragem muito boa baseada em hosts.
Desabilite ou remova serviços não utilizados
Assim como no Windows, no seu Linux podem haver serviços rodando em background que você não tem conhecimento ou que não queria que estivesse lá. Utilizando o comando chkconfig (em distribuições baseadas em Red Hat) ou entrando no diretório /etc/rc.d (no Slackware), você pode verificar quais serviços são inicializados e que você não quer e desabilitá-los. Serviços que não estão rodando não oferecem riscos à segurança e não consomem recursos da máquina.
Aumente a segurança de serviços necessários
Se a sua máquina tem alguns serviços que devem receber conexões da Internet, tenha certeza de que você conhece muito bem todas as opções de configuração destes serviços. Por exemplo, se você precisa utilizar o SSH, tenha certeza de que você verificou todos os detalhes do arquivo /etc/ssh/sshd_config antes de habilitar o serviço. O mínimo que você deve fazer é desabilitar o login do root. Toda máquina Linux tem um usuário root que pode logar via SSH, quando você desabilita este usuário, você inibe ataque de brute force pois o atacante ainda não sabe qual usuário é valido nessa máquina. Se você deixar o login remoto do root habilitado, o atacante só vai precisar descobrir a senha.
Configure as opções de rede do kernel
O prórpio kernel Linux pode oferecer algumas opções de segurança para a rede. Se familiarize com as opções disponíveis no arquivo /etc/sysctl.conf e as configure conforme necessário. As opções deste arquivo controlam, por exemplo, que tipo de informações sobre a rede são logadas nos logs do sistema.
Conecte o PC a um roteador
Um roteador (mesmo que doméstico) é um hardware bem comum hoje em dia. Ele é a primeira camada de segurança para qualquer rede, seja ela doméstica ou corporativa e permite que vários computadores utilizem o mesmo endereço IP para o acesso à Internet. Isso geralmente dificulta a ação de um atacante ou programa malicioso pois ele bloqueia qualquer tráfego que você não permitiu. Roteadores domésticos são apenas versões mais enxutas de roteadores corporativos que empresas utilizam para separar sua rede da Internet.
Atualize
Sempre mantenha o software do seu computador atualizado com os últimos patches de segurança seja qual for o sistema operacional que você está utilizando. A sua distribuição irá sempre lançar patches de segurança regularmente e estes devem sempre ser aplicados. Como no Windows, esta deve ser a sua primeira tarefa do dia
.
Outros softwares
Você também deve instalar outros softwares que aumentem a segurança do seu sistema.
Bastille-Linux (http://www.bastille-linux.org/) é um programa que pode ser usado para aumentar a segurança de certos aspectos do Linux. Ele desenvolve uma política de segurança que é aplicada ao sistema e produz relatórios sobre potenciais problemas de segurança. Além disso, é uma ótima ferramenta para se aprender sobre detalhes da segurança do seu Linux.
O Tripwire (http://sourceforge.net/projects/tripwire) é um software que monitora os binários do seu sistema procurando por modificações não autorizadas. Frequentemente um hacker modifica os binários do seu sistema para dificultar a detecção de uma intrusão. Os programas modificados lhe fornecem informações falsas permitindo que o hacker mantenha o controle sobre seu sistema sem que você perceba.
Honeypots
10/04/09
Autor: Pedro Augusto de O. Pereira / http://augusto.pedro.googlepages.com/
Introdução aos honeypots
Honeypots são uma forma barata e simples de detectar atividades ilícitas na sua rede. Sua principal função é ser atacado (por pessoas, por vírus, por worms, etc), scaneado ou invadido para assim adquirir informações para que você consiga se proteger de forma mais eficiente conhecendo como seus hosts podem ser atacados. O conceito é simples: um honeypot não tem nenhum propósito de produção (não tem nenhum serviço real, não deve receber nenhuma conexão, ninguém deve interagir com ele), portanto qualquer interação com um honeypot é possivelmente uma atividade ilícita (proposital ou não). Por esse motivo, os honeypots tem um baixo número de falso-positivo e geram pouco log, facilitando a leitura e fazendo com que o administrador detecte ataques com mais facilidade.
Com ele você consegue agir pró-ativamente em relação à segurança. Tenha em mente que honeypots não vão consertar os problemas de segurança da sua rede e têm pouco valor se usados sozinhos (num ambiente ideal, eles são usados com ferramentas como NIDS). Eles são uma ferramenta para que você consiga capturar informações sobre potenciais problemas de segurança e tomar providências antes que eles se tornem problemas maiores. Veja bem: quem vai consertar os problemas identificados é você e não o software de honeypot.
É um conceito relativamente novo, tendo como um de seus maiores estudiosos Lance Spitzner.
Os honeypots podem ser divididos em 2 tipos: os de produção e os de pesquisa.
Honeypots de produção
O papel de um honeypot de produção é ajudar a mitigar prejuízos causados por falhas de segurança em uma organização, adicionando valor à solução de segurança. Seu papel é detectar atividades maliciosas e avisar o administrador de redes sobre isso (e não impedir que atacantes não cheguem à sua rede). Geralmente são honeypots de baixa interatividade, ou seja, o atacante não consegue “invadir” o honeypot pois o software não deixa, o que ele faz é emular um serviço ou shell (por exemplo, ele pode emular uma máquina Windows XP e sofrer ataques de vírus e worms destinados à esse sistema, mostrando outras máquinas infectadas na sua rede), e obter informações um pouco limitadas sobre os dados trocados e um pouquinho da interação do atacante com o host. Consegue também guardar informações sobre este ataque e sua origem (informações extremamente úteis). Geralmente são posicionados dentro da rede interna da empresa.
Eles funcionam emulando vários serviços para enganar o atacante enquanto loga em arquivos as informações que consegue capturar, fornecendo uma visão do que está acontecendo. Com ele você facilmente consegue pegar um micro infectado por um vírus, um usuário malicioso, etc.
Lembre-se sempre: qualquer interação com um honeypot é uma interação não-autorizada (ninguém deve saber que existe o honeypot e ninguém tem motivos para tentar estabelecer uma conexão com um), portanto é possivelmente uma interação maliciosa (gerada por um humano ou por um micro infectado por um vírus ou worm).
Honeypots de pesquisa
Honeypots de pesquisa são geralmente de alta-interatividade, ou seja, ela é uma máquina mal configurada que possui várias ferramentas para monitoração (como keyloggers) que verifica o que o atacante fez para conseguir invadir e o que fez depois que conseguiu o acesso. Nela o atacante interage com o Sistema Operacional da máquina e não com um software que emula shells e sistemas. Geralmente se usa um servidor de logs com este tipo pois não se pode confiar nos logs presentes no host já que o atacante pode alterá-los.
Este tipo de honeypot consegue captar mais informações (como dados trocados, consegue identificar novas ferramentas e capturar o que foi digitado pelo atacante), porém aumenta sifgnificativamente o risco da rede. Por isso geralmente não é colocado dentro de uma rede empresarial: é utilizado somente em institutos de pesquisa em redes que são monitoradas o tempo todo para que não sejam lançados ataques à partir deste host, entre outras ameaças. Essas soluções são bem complexas de serem implementadas exigindo bastante experiência do analista, porém capturam muito mais informações que os honeypots de produção.
As duas soluções expostas acima vão te ajudar a melhorar a segurança da sua rede. Você deve escolher qual usar se baseando no que você quer monitorar e descobrir sobre seu atacante. Leve também em consideração os ponteciais riscos aos quais você está expondo a sua rede.
Vantagens dos honeypots
Os honeypots trazem grandes vantagens, abaixo exponho algumas delas:
- Poucos dados são capturados, porém são dados muito importantes: Os honeypots, ao contrário de várias outras ferramentas, capturam pouquíssimos dados. Porém os dados capturados são muito importantes para o administrador de sistemas. Ao invés de capturar Gigabytes de dados (sendo que a grande parte é inútil) o honeypot vai capturar apenas alguns Megabytes de informações extremamente importantes, também não são gerados milhares de alertas por dia (assim diminui a ocorrência de falso-positivo aumentando a credibilidade da ferramenta. Lembra da história do menino que sempre enganava os outros gritando “Socorro! Socorro!”??). Além disso, gerando poucos dados, é mais provável que o administrador cheque esses dados mais frequentemente (vai me dizer que você nunca ficou com preguiça de ler os logs infinitos que são gerados por algumas ferramentas?), aumentando as chances de identificar um ataque rapidamente. Além disso, por analisar poucos dados, não perde pacotes importantes para a análise como uma ferramenta de IDS perderia se começassem a chegar muitos pacotes da rede em um determinado momento.
- Descobertas de novas ferramentas e de novas táticas: Utilizando os honeypots você consegue ver como o atacante agiu, que ferramentas usou e como se proteger delas. Se as ferramentas (ou exploits) usados para invadir o seu honeypot nunca foram usadas antes (conhecidas como 0 day), você conseguirá descobrir e em pouco tempo já conseguirá se proteger delas, ficando vulnerável por menos tempo.
- Uso mínimo de recursos: Os honeypots são extremamente econômicos nos requisitos mínimos para sua execução. Como só analisam o tráfego direcionado a eles, usam pouquíssima banda da sua rede e como são softwares bem leves, exigem o mínimo do hardware, fazendo com que aquela sua máquina PII com 64MB de RAM consiga monitorar uma rede com um desempenho razoavelmente bom.
- Dados criptografados: Ao contrário de outras ferramentas, os honeypots conseguem trabalhar com os dados criptografados que são direcionados à ele.
- Simplicidade: Honeypots são extremamente simples: sem algoritmos complexos, sem tabelas de informações para manter, etc. Sendo tão simples assim, é bem menos provável que alguém cometa um erro ao implantá-las em suas redes.
Desvantagens dos honeypots
Todas as ferramentas tem desvantagens, por isso honeypots não trabalham sozinhos: eles complementam outras ferramentas.
- “Alcance” limitado: Honeypots só conseguem analisar os dados que são direcionados à eles. Se nenhum pacote chegar para ele analisar, não será gerado nenhum dado e não se terá o que analisar para melhorar a segurança da sua rede. Para mitigar este problema, se usam ferramentas que monitoram a rede como um NIDS (um exemplo deste tipo de software seria o Snort).
- Risco: Todo software adiciona riscos à rede. Os honeypots não são diferentes de nenhum outro software. O seu honeypot, por exemplo, corre o risco de ser invadido por alguém (dependendo do nível de interação, como dito anteriormente) e, à partir dele, lançar ataques a outros hosts ou até redes.
O projeto “Brazilian Honeypots Alliance”
O Brasil tem um projeto muito bom relacionado aos Honeypots, é o Brazilian Honeypots Alliance. Este projeto é formado por estudiosos de segurança de institutos como o INPe. O objetivo é formar uma grande honeynet no espaço de endereços do Brasil para analisar e divulgar resultados coletados por honeypots espalhados pelo país.
Neste projeto são utilizados honeypots de baixa interatividade. Você pode conhecer mais sobre este projeto acessando a URL http://www.honeynet.org.br.
Conclusão
Honeypots são uma ferramenta extremamente útil para auxiliar na melhoria da segurança da sua rede ou para aprender novos recursos e ataques utilizados por seus inimigos. O principal objetivo deste texto foi te dar uma visão bem básica e sem muitos detalhes da teoria de honeypots. Muitos textos com sugestões de softwares para usar, análises mais profundas de softwares, entre outros, podem ser encontrados aos montes na Internet (geralmente em inglês). Qualquer dúvida, entre em contato comigo!
Configurando e instalando o Honeyd
10/04/09
Autor: Pedro Augusto de O. Pereira / http://augusto.pedro.googlepages.com/
Introdução
Neste artigo, temos uma boa quantidade de teoria em relação aos honeypots (como aplicação, tipos, história…) porém sem focar em qualquer ferramenta para implementação do honeypot. Aqui, irei focar na implantação de um honeypot utilizando OpenBSD e HoneyD. Vamos criar alguns hosts Windows e Linux.
O Honeyd
O Honeyd é um daemon desenvolvido por Niels Provos para ser utilizado tanto em Windows quanto *nix.
Ele funciona criando “hosts virtuais” os quais podem ser configurados para emular vários serviços diferentes como e-mail, SSH, Telnet, DNS, backdoors como o MyDoom, etc. Além de emular serviços, o Honeyd também pode enganar scanners de rede fingindo ser outro sistema operacional. Por exemplo, você consegue emular um roteador Cisco, um Windows XP, Windows 2000, Windows Server 2003, Cisco IOS, OS/400, entre vários outros. Ele consegue isso utilizando o banco de dados de fingerprints do NMap (http://www.insecure.org/nmap). Para que você possa emular vários sistemas operacionais com maior veracidade, o Honeyd também permite que você utilize vários endereços IP e associe cada “host virtual” com um endereço IP diferente.
A melhor característica do Honeyd é ser software livre licensiado sob a GPL, ou seja, use à vontade para qualquer finalidade. Ele também é utilizado bastante pelo Honeynet.BR Project (entidade brasileira de pesquisa de honeypots).
Se você quiser conhecer mais sobre o projeto, visite o website oficial http://www.honeyd.org. Aproveite e dê uma ajuda ao desenvolvedor!
Instalação do Honeyd
A instalação do Honeyd é bem simples. Se você estiver usando algum BSD, utilize o ports para instalar e poupe um pouco de tempo não precisando resolver as dependências na mão.
Se você vai compilar o Honeyd, o procedimento também não é muito complicado, mas é um pouco demorado. Faça o seguinte:
- Acesse o site do Honeyd e baixe os sources mais recentes: http://www.citi.umich.edu/u/provos/honeyd/honeyd-1.5b.tar.gz
- O Honeyd precisa de algumas bibliotecas para ser compilado com sucesso. Você precisa do Python, do Perl, da libevent (http://www.monkey.org/~provos/libevent/), da libdnet (http://libdnet.sourceforge.net/) e da libpcap (http://www.tcpdump.org/). A instalação dessas dependências é extremamente simples (em quase todas se resumindo a ./configure, make, make install), por isso não vou entrar em detalhes aqui.
- Instale o arpd (http://www.citi.umich.edu/u/provos/honeyd/arpd-0.2.tar.gz)
- Agora já é possível compilar o Honeyd.
Configuração
O ambiente que eu usei para fazer a configuração do meu honeypot foi usando um OpenBSD com o Honeyd instalado através dos ports, assim a localização dos arquivos mostrada aqui é a localização padrão no OpenBSD. Se você estiver usando algum outro sistema, utilize o find ou o locate para procurar pelo nome dos diretórios mostrados aqui.
O arquivo de configuração principal é o /etc/honeyd.conf. Nele você irá definir as máquinas que serão emuladas, quais serão os IP’s, os serviços, etc. O arquivo nmap.prints tem os fingerprints de todos os sistemas operacionais que podem ser emulados pelo Honeyd (sempre mantenha esse arquivo atualizado com a última versão disponibilizada pelo time do NMap para garantir que seu honeypot continuará enganando o NMap e outros scanners). No OpenBSD, o nmap.prints fica localizado em /usr/local/share/honeyd/nmap.prints. O Honeyd usa scripts (Perl e Shell script) para emular os serviços que você quer no seu honeypot. Esses scripts ficam localizados em /usr/local/share/honeyd/scripts. Você também pode desenvolver ou baixar esses scripts de outros sites na Internet, um exemplo é o site http://www.honeyd.org/contrib.php. Existem também várias ferramentas muito úteis para o Honeyd, como essas: http://www.honeyd.org/tools.php.
Agora que você já tem um conhecimento básico para “se virar” utilizando o Honeyd, vamos partir para a configuração.
Aqui, vou te mostrar como criar uma máquina Windows XP Professional SP1 e um Linux 2.4.16. Com essas máquinas você já vai conseguir capturar coisas interessantes.
Abra o arquivo /etc/honeyd.conf para criarmos os hosts. Ele já vem com alguns modelos de host, comente todas as linhas desses exemplos mas não comente o profile “default”.
Vamos criar uma máquina Windows XP Professional SP1 que estará infectada com o backdoor MyDoom. Para isso, adicione as linhas abaixo no seu honeyd.conf:
create windowsxp-mydoom
set windowsxp-mydoom personality “Microsoft Windows XP Professional SP1?
set windowsxp-mydoom uptime 2314219
set windowsxp-mydoom default tcp action reset
set windowsxp-mydoom default udp action reset
set windowsxp-mydoom default icmp action open
set windowsxp-mydoom uid 32767 gid 32767
add windowsxp-mydoom tcp port 1080 “perl scripts/mydoom.pl -l /root/logs-honeypot/mydoom/mydoom.log”
add windowsxp-mydoom tcp port 3127 “perl scripts/mydoom.pl -l /root/logs-honeypot/mydoom/mydoom.log”
add windowsxp-mydoom tcp port 3128 “perl scripts/mydoom.pl -l /root/logs-honeypot/mydoom/mydoom.log”
add windowsxp-mydoom tcp port 10080 “perl scripts/mydoom.pl -l /root/logs-honeypot/mydoom/mydoom.log”
bind 192.168.0.1
Pronto, a máquina já está criada e associada ao IP 192.168.0.1. Segue uma explicação dos parâmetros:
- create windowsxp-mydoom: define que criaremos o host windowsxp-mydoom
- set windowsxp-mydoom personality “Microsoft Windows XP Professional SP1?: define a personalidade a ser usada para esse host
- set windowsxp-mydoom uptime 2314219: define qual vai ser o uptime da máquina
- set windowsxp-mydoom default tcp action reset & set windowsxp-mydoom default udp action reset & set windowsxp-mydoom default icmp action open: definem a ação padrão das portas TCP, UDP e ICMP.
- set windowsxp-mydoom uid 32767 gid 32767: define qual será o UID e o GID a ser usado para esse script
- add windowsxp-mydoom tcp port 1080 “scripts/mydoom.pl -l /root/logs-honeypot/mydoom/mydoom.log”: é aqui que definimos que o Honeyd deverá simular o MyDoom na porta 1080 (o mesmo acontece nas outras 3 linhas). 1080 é a porta que vai escutar por tráfego, “scripts/mydoom.pl…” define que script ficará sendo executado naquela porta. No caso desse script (mydoom.pl), é interessante que se defina o log que ele vai gerar com o tráfego que recebe. Para isso utilizamos a opção -l e o caminho para o log (o caminho obviamente já deve existir).
- bind 192.168.0.1: define que esta máquina atenderá as requisições de IP que forem destinadas a 192.168.0.1
Como você pode ver, é extremamente fácil definir os hosts no Honeyd. Como outro exeplo, vou criar um servidor de email Linux utilizando kernel 2.4:
create linux
set linux personality “Linux 2.4.16 – 2.4.18?
set linux default tcp action reset
set linux default udp action reset
set linux uptime 3284460
add linux tcp port 110 “sh scripts/pop3.sh”
add linux tcp port 25 “sh scripts/smtp.sh”
add linux tcp port 22 “sh scripts/test.sh $ipsrc $dport”
bind 192.168.0.2 linux
No geral, esta configuração é muito parecida com a máquina Windows. O que difere bastante são os scripts utilizados para emular serviços:
- pop3.sh: emula um serviço POP3 na porta 110
- smtp.sh: emula um serviço de SMTP na porta 25
- teste.sh $ipsrc $dport: emula o SSH, logando o IP de origem (de quem se conectou ao script) e em qual porta.
Para qualquer outra máquina que você quiser criar, é só seguir essa mesma lógica que demonstrei nos exemplos. Só preste bastante atenção para não configurar por engano o IIS numa máquina Linux, isso faria o atacante desconfiar (faria qualquer um desconfiar
). Para você verificar quais sistemas operacionais você vai poder emular usando o Honeyd, é só executar o seguinte comando:
# grep “^Fingerprint” nmap.prints | less
A lista é bem grande, por isso fica melhor para você escolher se redirecionar a saída desse comando para um arquivo.
Configurando o firewall
A configuração do firewall no honeypot é importante pois se você não configurar sua máquina para aceitar conexões para os IP’s que definiu para os hosts virtuais (lembre-se que esses endereços devem ser reais na sua rede e não podem ser usados por nenhuma outra máquina), seu Honeyd não funcionará.
Garantir a segurança do honeypot é muito importante, por isso preste bastante atenção no que está fazendo aqui.
Inicializando o Honeyd
Antes de inicializar o Honeyd e partir para a ação, tenha certeza de que você vai ter algum tráfego sendo redirecionado para o seu honeypot. Para fazer isso, você pode usar o arpd para o seu honeypot responder pelos endereços desocupados da sua rede (o que pode fazer um servidor DHCP travar). Do modo que mostrei na configuração acima, só será logado o tráfego que realmente for direcionado para o honeypot.
Para você utilizar o ARPd, você só precisa especificar a rede que ele vai ouvir. Quando ele ouvir alguma requisição ARP passando pela rede, ele irá checar se alguém tem o IP, se ninguém tiver, ele responderá como se fosse o IP requisitado. Para iniciar o ARPd:
# arpd < rede a ser monitorada >
Por exemplo,
# arpd 192.168.0.0/24
Quando você usa o ARPd, o profile de host que irá responder é o “default” (lembre-se, para usar o ARPd você não pode usar a cláusula “bind” para o host que você criar no honeyd.conf). Esse profile já vem criado no honeyd.conf quando você instala o Honeyd. Se você criar outras profiles e definir um IP para elas utilizando a cláusula “bind” no honeyd.conf, o Honeyd irá responder com o profile default para todos os IP’s da rede menos para o IP que você configurou para o host utilizando o “bind”. Simples não?
Com tudo o que foi explicado e resolvido, podemos iniciar o Honeyd:
# honeyd -p nmap.prints -f /etc/honeyd.conf 192.168.0.0/24
Assim, os seus hosts virtuais que têm IP definido, responderão normalmente e o profile default que não tem um IP definido, responderá por todos os endereços que não são utilizados na sua rede.
Ferramentas complementares
O Honeyd tem algumas ferramentas complementares que aumentam a funcionalidade dele. Um bom exemplo desse tipo de ferramenta é o Honeydsum.
Ele é um analisador de Logs desenvolvido pelo time brasileiro da Honeynet-Alliance. Com ele você pode filtrar os logs do Honeyd procurando por endereços IP, portas, protocolos ou redes além de poder relacionar os eventos logados em vários honeypots diferentes. Veja mais aqui: http://www.honeynet.org.br/tools/.
O Honeycomb também é outra ferramenta extremamente útil. Com ela você consegue gerar assinaturas para software de detecção de intrusão como o Snort. É especialmente útil para criar assinaturas de worms. Foi este software que criou as assinaturas para o Slammer e Code Red. Você pode encontrá-lo neste link http://www.cl.cam.ac.uk/~cpk25/honeycomb/.
Dois sites com ferramentas para o Honeyd são http://www.honeyd.org/tools.php e http://www.honeynet.org.br/tools/. Com certeza você encontrará mais ferramentas em outros sites da Internet, é só procurar no Google.
Conclusão
O Honeyd não é uma ferramenta complexa, mas deve ser implantada na rede da forma correta para que consiga ajudar de forma efetiva o administrador a monitorar tráfego malicioso e tomar providências. Claro que o Honeyd sozinho não vai ser de grande ajuda. Você precisa utilizar outras ferramentas para complementar o trabalho dele. Um exemplo é o Snort, um detector de intrusos. Utilizando os 2 em conjunto, você irá ter uma solução para monitoramento de tráfego extremamente eficiente sem gastar quase nada.
VPN com FreeS/WAN
10/04/09
Autor: Pedro Augusto de O. Pereira / http://augusto.pedro.googlepages.com/
Introdução
O FreeS/WAN é uma das várias implementações do IPSec (Internet Protocol Security) e IKE (Internet Key Exchange) para GNU/Linux.
Utilizando estes dois serviços, você pode fazer um túnel seguro entre duas redes distantes com seus dados passando por redes inseguras (como a Internet). O IPSec consegue fazer com que os dados trafeguem de modo seguro através de uma rede insegura, pois tudo o que passará por este túnel é criptografado pelo gateway com IPSec instalado e só é descriptografado na outra ponta. No gateway que conhece a chave para realizar a descriptografia. Assim, você consegue estabelecer uma VPN (Virtual Private Network) entre vários locais diferentes, utilizando a Internet, de forma bastante segura.
Para descrever como estabelecer um túnel VPN criptografado, neste documento vou me basear na versão 2.06 do FreeS/WAN.
Instalação
Para que você consiga usar o FreeS/WAN a partir dos RPM’s, você tem que necessariamente ter os pacotes freeswan-userland-xxx.rpm e freeswan-module-xxx.rpm. Você pode encontrar esses pacotes no seguinte site:
http://www.freeswan.org/download.html
Então, para instalar o FreeS/WAN a partir dos pacotes RPM, faça o seguinte:
# rpm -ivh freeswan-userland-xxx.rpm
# rpm -ivh freeswan-module-xxx.rpm
Depois de instalar os dois pacotes, serão criados (entre outros) dois arquivos no seu diretório /etc: o ipsec.conf e o ipsec.secrets. Veremos mais adiante para que cada um deles serve.
Gerando as chaves RSA – utilizando o arquivo ipsec.secrets
Antes de começar a configurar o serviço propriamente dito, vamos gerar as chaves para a autenticação dos nossos gateways. Para isso é só usar o comando ipsec_newhostkey. Por padrão, a chave gerada com este comando deve ir para o arquivo /etc/ipsec.secrets, porém você pode mudar o arquivo para qualquer um que você queira.
Então, vamos gerar a nossa chave:
# ipsec_newhostkey –output /etc/ipsec.secrets –bits 128 –hostname gateway_1
Com o comando acima, nós geramos a chave de autenticação do host gateway_1 de 128 bits e a guardamos no arquivo ipsec.secrets. Esse processo deve ser feito para o outro gateway que estabelecerá o túnel VPN com este gateway.
Tenha certeza absoluta de que o nome da máquina que você forneceu ao gerar a chave é o correto. Se este nome estiver errado, a chave será gerada de forma errônea e você não conseguirá estabelecer um túnel entre os gateways.
Como você já deve ter percebido, no arquivo ipsec.secrets só deve haver a chave do gateway que você está configurando. Por exemplo, se eu estou configurando o gateway gateway_1, no meu arquivo ipsec.secrets só deverá existir a chave deste host. Quando eu for configurar o gateway_2, no ipsec.secrets deste só deverá haver a chave do gateway_2.
Configurando o serviço IPSec – utilizando o arquivo ipsec.conf
Depois que você gerou todas as chaves necessárias em todos os hosts, é hora de editar o arquivo ipsec.conf para configurar como será a nossa VPN.
Vou tentar deixar claro para que servem todas as opções neste arquivo (que não são muitas).
interfaces=%defaultroute
Essa opção necessariamente tem que estar certa sempre, ou praticamente nada irá dar certo!
Se o seu gateway for o caminho certo para a VPN, então pode deixar exatamente como está. Se não, altere para a placa de rede que terá a comunicação com a outra ponta da VPN. Por exemplo, se a VPN for estabelecida via a placa de rede eth0, então a linha deverá ficar:
interfaces=”ipsec0=eth0?
A opção interfaces=”ipsec0=eth0? vai ser o suficiente se a sua VPN for bem simples.
klipsdebug=none
plutodebug=none
Estas opções geralmente são mais necessárias quando a sua VPN está com algum problema. Elas “medem” o nível de informação que será logado pelo serviço IPSec. Se você quiser o máximo de informações possível, é só mudar “none” para “all”.
uniqueids=yes
Esta opção faz com que uma conexão antiga seja encerrada quando uma nova, com a mesma ID, apareça.
Nas opções acima, será muito difícil você ter que alterar alguma coisa, a não ser que a sua VPN seja um caso um pouco mais específico.
keyingtries=0
Esta opção indica a quantidade de tentativas que devem ser feitas para se negociar uma conexão antes de desistir. Esta opção só tem efeito localmente, ou seja, o outro lado não precisa necessariamente ter o mesmo número de tentativas especificadas nesta opção. Para fazer com que o serviço não desista nunca, deixe com o “0? ou substitua por %forever (é recomendado que se deixe o “0? mesmo).
disablearrivalcheck=no
Habilita ou desabilita a checagem dos pacotes que acabam de chegar do túnel. É recomendado que você nunca desabilite esta opção, pois ela aumenta a segurança e confiabilidade do túnel e não atrapalha em nada.
authby=rsasig
Define como os gateways participantes da VPN irão autenticar-se. As opções são:
- secret, para senhas;
- rsasig, para assinaturas RSA (o padrão e melhor opção);
- secret|rsasig, para usar ambas as opções ou never, usado se você nunca for querer estabelecer a conexão ou não for aceitá- la.
Como já foi dito anteriormente, a melhor opção é usar assinaturas RSA (rsasig).
leftrsasigkey=%dns
rightrsasigkey=%dns
Define como será encontrada a chave RSA. Os valores que podem ser usados são:
- %none = é o mesmo que não especificar um valor;
- %dnsondemand = é o valor padrão. Significa que a chave será lida do DNS quando for necessária;
- %dnsonload = com esta opção, a chave RSA será lida do DNS quando a conexão for ativada. Nas versões mais atuais do FreeS/WAN, esta opção será tratada como %none se right=%any ou %opportunistic;
- %dns = é tratado como %dnsonload.
-
- tunnel = define uma conexão host a host, host a sub-rede ou sub-rede a sub-rede. Esta é a opção padrão;
- passthrough = define que o IPSec não deve ser usado para estabelecer a conexão;
- drop = define que todos os pacotes devem ser descartados;
- reject = define que os pacotes devem ser descartados.
- start = define que a conexão será iniciada assim que o serviço IPSec for iniciado;
- add = define que a conexão será feita manualmente. Para que se consiga estabelecer a conexão manualmente, deve- se usar o comando ipsec auto –up nome_da_conexão.
- Os arquivos ipsec.conf devem ser iguais nas duas pontas do túnel;
- Os arquivos ipsec.secrets devem sempre ser diferentes, cada um com a chave de seu respectivo host;
- Um gateway não pinga outro gateway;
- Uma estação não ping um gateway;
- Uma estação pode pingar outra estação.
conn sampleAqui começam as configurações dos túneis que serão estabelecidos. A linha “conn sample” é o nome da conexão. Você poderia mudá-la para qualquer nome, como “conn campinas”. Lembre-se que você não pode mudar o “conn”, apenas o nome que segue.
type=tunnel
Define o tipo da conexão a ser estabelecida. Você pode colocar os seguintes valores aqui:
left=210.xxx.xxx.xxx
right=200.xxx.xxx.xxxDefine qual será a ponta left (ou right) do seu túnel VPN. O FreeS/WAN trabalha do seguinte modo: cada host participante do túnel pode ser left ou right. Não importa qual seja o tipo da VPN a ser estabelecida, você sempre deve definir quem será o left e quem será o right. Nesta opção, deve ser definido o IP do host que você definiu que será o left. Não tem muita importância um host ser left ou right (na verdade, isso praticamente não importa) desde que você seja consistente na sua escolha, ou seja, se você definiu o host gateway1 como left, referencie- se a ele sempre como left.
leftsubnet=192.168.0.0/24
rightsubnet=192.168.0.0/24Aqui é definido qual é o endereço da sub-rede (da rede que está “atrás”) do host. No exemplo é 192.168.0.0, que é um endereço de classe C. Se usássemos um endereço de classe A, deveríamos colocar /8; caso fosse classe B seria /16.
leftrsasigkey=0s$Pa%6…
rightrsasigkey=$#1@psoeKe~…Aqui você deve colocar a chave RSA do host left para que o túnel seja estabelecido com sucesso. A chave que deve ser colocada aqui, é a chave que está no arquivo ipsec.secrets, mais especificamente a chave que está na linha “pubkey=…”, que foi gerada com o comando ipsec_newhostkey explicado anteriormente. O mesmo vale para a opção rightrsasigkey encontrada mais adiante no ipsec.conf.
leftnexthop=200.xxx.xxx.xxx
rightnexthop=200.xxx.xxx.xxxAqui deve ser definido qual o endereço IP do gateway usado pelo host. Esta opção só tem importância localmente, ou seja, não necessariamente deve ser igual nas duas pontas do túnel.
auto=start
Define quando a conexão referenciada por esta opção será ativada. Alguns valores que podem ser colocados aqui são:
Testando os túneis
Agora que nós já configuramos o serviço IPSec, podemos começar nossos testes. Alguns detalhes devem sempre ser observados:Tendo observado estes detalhes, tente pingar uma estação que esteja na sub-rede da outra ponta. Se tudo estiver correto, a outra estação irá responder a todos os pings.
Troubleshooting – corrigindo os inevitáveis erros
Caso você não esteja conseguindo pingar as máquinas da sub-rede da outra ponta do túnel e o serviço IPSec tenha inicializado sem erro nenhum, verifique se as portas 500 do protocolo UDP estão abertas tanto para entrada quanto para saída (para o IKE) e as portas 50 também estejam abertas para entrada e saída. Deixar estas portas fechadas geralmente impede o IPSec de passar da primeira fase da negociação da conexão.Se você está tendo problemas ao iniciar o serviço IPSec, é bom que você entenda as etapas da negociação das conexões.
As negociações do IKE possuem duas fases: Main Mode, STATE_MAIN.
As negociações do IPSec também possuem duas fases: Quick Mode, STATE_QUICK.Quando os passos anteriores são realizados com sucesso, serão mostradas as mensagens:
“nome_da_conexão” STATE_MAIN_I4 (ISAKMP SA established…)
“nome_da_conexão” STATE_QUICK_I2 (sent QI2, IPSec SA established…)Quando você não consegue estabelecer o túnel de forma correta, geralmente estes passos não são atingidos. Assim, o comando:
# ipsec auto –status
Será muito útil, pois ele te mostrará o último estado da negociação que foi alcançado, mas não informa o estado atual, porém você pode deduzir qual o estado atual verificando se o último passo mostrado pelo comando foi finalizado com sucesso.
Para que o IPSec mostre mais mensagens de erro para facilitar o troubleshoot, você pode usar o comando:
# ipsec auto –verbose –up nome_da_conexão
Assim ele irá mostrar mensagens sobre todos os passos da negociação da conexão especificada.
É sempre bom lembrar que também é muito útil que se olhe os logs do seu sistema. Porém o nível de detalhes que serão logados dependerá do que você colocou nas opções “klipsdebug” e “plutodebug” do arquivo ipsec.conf. Se tiver problemas, coloque pelo menos uma delas para “all” para que você tenha uma base melhor para descobrir onde está o erro.
Outro comando que também pode ajudar muito na hora de achar o erro de alguma conexão do FreeS/WAN é o barf. Ele imprime na tela várias informações relevantes sobre a encriptação e autenticação do IPSec. O uso dele é o seguinte:
# ipsec barf
Assim ele já imprime várias informações muito úteis. Porém, é melhor que se passe essas informações para um arquivo para que se possa observá-las com mais calma:
# ipsec barf >> conexão_com_problema.txt
Bom, estas são algumas dicas básicas para que você consiga resolver os problemas que por ventura apareçam por aí.
Fontes e conclusão
Site oficial, com uma documentação extremamente detalhada:* http://www.freeswan.org. Tutorial muito bom sobre o assunto:* http://www.linuxman.pro.br/vpn
Esta foi só uma olhada básica no serviço IPSec, que é extremamente útil em muitos casos. Espero que tenha sido de alguma ajuda para você.
-
Sandcat – Scanner de vulnerabilidades de sistemas e servidores web
10/04/09
Autor: Pedro Augusto de O. Pereira / http://augusto.pedro.googlepages.com/
Considere o Sandcat um NMap especializado em varrer servidores web (como IIS ou Apache) e aplicações web (o seu site!). Isso facilita muito, pois você pode testar um determinado site ou servidor procurando por vários tipos de falhas como SQL Injection, Blind SQL Injection, XSS, XPath Injection, etc.
Existem várias opções para este tipo de aplicativo, a que mais gosto e uso regularmente é o scanner da Acunetix, chamado Web Vulnerability Scanner. Uma outra opção que tenho usado há alguns dias e gostado bastante é o Sandcat, da empresa Syhunt.
Ela é gratuita para ser utilizada e bem completa (bem próxima do nível do Web Vulnerability Scanner, da Acunetix). Ele checa por, aproximadamente, 260 vulnerabilidades conhecidas (utilizando o ranking de várias entidades como OWASP, OWASP PHP, CVE, CWE, etc), detecta falhas de XSS (Cross Site Scripting), testas sistemas IDS, consegue explorar sistemas web desenvolvidos utilizando AJAX, descobre e analisa a configuração utilizada no servidor automaticamente para descobrir quais testes são necessários, etc.
Além de checar o que pode ser explorado na sua aplicação web, ele também analisa o que pode ser explorado no seu servidor web. No website oficial do produto, é declarado que ele tem compatibilidade total com o Microsoft IIS. Porém já li opiniões e testei pessoalmente o programa utilizando Apache e também tive bons resultados.
Sem dúvida é um download recomendado, porém até agora só há opção para Windows (95, 98, Me, NT, 2000, 2003, XP e Vista). Faça o download aqui.
