terça-feira, setembro 27, 2011
domingo, setembro 04, 2011
terça-feira, agosto 30, 2011
OWASP AppSec Latin América 2011 - Inscrições Abertas
Inscrições abertas para a OWASP AppSec Latin América 2011. Confira os valores e os treinamentos em http://t.co/2lancJi
sexta-feira, julho 15, 2011
Installing ModSecurity 2.6.1-rc1 + CRS (Core Rule Set) 2.2.0

This post will help you how to install and configure ModSecurity Web Application Firewall in your system, with the Core Rule Set 2.2.0. The operations system base is CentOS 5.6.
- Install dependencies:
# yum install gcc openssl-devel openssl apr-util-devel apr-devel pcre pcre-devel libjpeg-devel gd-devel libpng-devel libjpeg gd libpng gettext gettext-devel libmcrypt-devel libmcrypt libxml2 libxml2-devel bison zlib zlib-devel bzip2 bzip2-devel libtool libtool-ltdl readline readline-devel ncurses ncurses-devel curl curl-devel
- Get the source codes:
- Apache: http://httpd.apache.org/download.cgi
- Lua: http://www.lua.org/ftp/lua-5.1.4.tar.gz
- ModSecurity: http://www.modsecurity.org/download/modsecurity-apache_2.6.1-rc1.tar.gz
- Core Rule Set: http://sourceforge.net/projects/mod-security/files/modsecurity-crs/0-CURRENT/
- Check the integrity of sources with md5sum or sha1sum
- Install Apache from source:
# ./configure --prefix=/var/www --enable-auth-digest --enable-mime-magic --enable-usertrack --enable-ssl --enable-http --disable-cgi --enable-vhost-alias --disable-userdir --enable-so --enable-unique-id --enable-rewrite --with-z --disable-dav --disable-proxy --enable-deflate --enable-expires --with-pcre=/usr/bin/pcre-config
# make
# make install
- Compile Lua:
# tar xvfz lua-5.1.4.tar.gz
# cd lua-5.1.4
# make all linux
# make install INSTALL_TOP=/usr/local/lua-5.1.4
# cd src
# rm -f lua.o luac.o print.o && gcc -shared -Wall -O2 -o liblua5.1.so *.o
# cp liblua5.1.so /usr/local/lua-5.1.4/lib
# ln -s /usr/local/lua-5.1.4 /usr/local/lua
# echo "/usr/local/lua/lib" >> /etc/ld.so.conf
# ldconfig
- Compile ModSecurity:
# tar xvfz modsecurity-apache_2.6.1-rc1.tar.gz
# cd modsecurity-apache_2.6.1-rc1
# ./configure --with-apxs=/var/www/bin/apxs --with-lua=/usr/local/lua
# make
# make install
- Install and configure Core Rule Set:
# mkdir /var/www/conf/modsecurity
# mkdir /var/www/conf/modsecurity/crs
# cp modsecurity-apache_2.6.1-rc1/modsecurity.conf-recommended /var/www/conf/modsecurity/modsecurity.conf
# touch /var/www/conf/modsecurity/whitelist.conf
# tar xvfz modsecurity-crs_2.2.0.tar.gz
# cp -a modsecurity-crs_2.2.0/* /var/www/conf/modsecurity/crs
# cd /var/www/conf/modsecurity/crs
# for f in `ls base_rules/` ; do ln -s ../base_rules/$f activated_rules/$f ; done
# cp modsecurity_crs_10_config.conf.example modsecurity_crs_10_config.conf
# ln -s ../modsecurity_crs_10_config.conf activated_rules/
# ls -l activated_rules/ /* Check simbolic links */
- Configure Apache (httpd.conf)
LoadFile /usr/lib/libxml2.so.2
LoadFile /usr/local/lua/lib/liblua5.1.so
LoadModule security2_module modules/mod_security2.so
# CRS
<IfModule security2_module>
Include conf/modsecurity/modsecurity.conf
Include conf/modsecurity/whitelist.conf
Include conf/modsecurity/crs/modsecurity_crs_10_config.conf
Include conf/modsecurity/crs/activated_rules/*.conf
</IfModule>
- Edit modsecurity.conf:
SecRuleEngine On
SecAuditLog logs/modsec_audit.log
- Start Apache and check error_log:
[warn] Init: Session Cache is not configured [hint: SSLSessionCache]
[notice] ModSecurity for Apache/2.6.1-rc1 (http://www.modsecurity.org/) configured.
[notice] ModSecurity: APR compiled version="1.2.7"; loaded version="1.2.7"
[notice] ModSecurity: PCRE compiled version="6.6"; loaded version="5.0 13-Sep-2004"
[notice] ModSecurity: LUA compiled version="Lua 5.1"
[notice] ModSecurity: LIBXML compiled version="2.6.26"
[notice] Digest: generating secret for digest authentication ...
[notice] Digest: done
- Test your ModSecurity:
Access one url with a blocked estension, like: http://server/test.sql
You will see in apache error_log:
[error] [client 127.0.0.1] ModSecurity: Access denied with code 403 (phase 2). String match within ".asa/ .asax/ .ascx/ .axd/ .backup/ .bak/ .bat/ .cdx/ .cer/ .cfg/ .cmd/ .com/ .config/ .conf/ .cs/ .csproj/ .csr/ .dat/ .db/ .dbf/ .dll/ .dos/ .htr/ .htw/ .ida/ .idc/ .idq/ .inc/ .ini/ .key/ .licx/ .lnk/ .log/ .mdb/ .old/ .pass/ .pdb/ .pol/ .printer/ .pwd/ .resources/ .resx/ .sql/ .sys/ .vb/ .vbs/ .vbproj/ .vsdisco/ .webinfo/ .xsd/ .xsx/" at TX:extension. [file "/var/www/conf/modsecurity/crs/activated_rules/modsecurity_crs_30_http_policy.conf"] [line "88"] [id "960035"] [msg "URL file extension is restricted by policy"] [data ".alq"] [severity "CRITICAL"] [tag "POLICY/EXT_RESTRICTED"] [tag "WASCTC/WASC-15"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [hostname "localhost"] [uri "/test.SQL"] [unique_id "Th8c038AAAEAAGugG2kAAAAD"]
Now, your work is just in the begining. Now you have to test your application for false positives and false negatives.
If you use Wordpress, joomla, phpbb, etc, check the slr_rules directory. You have to enable it in httpd.conf.
sexta-feira, junho 03, 2011
Usando 2 fatores de autenticação no Google
Devido aos recentes acontecimentos com contas do Google, resolvi contribuir na divulgação do uso de 2 fatores de autenticação, conforme explicado no vídeo (em inglês). Para quem não sabe o que é fator de autenticação, pode escutar esse podcast ou ler o texto abaixo:
Fatores de autenticação
Os fatores de autenticação para humanos são normalmente classificados em três casos:
- Aquilo que o usuário é (impressão digital, padrão retinal, sequência de DNA, padrão de voz, reconhecimento de assinatura, sinais elétricos unicamente identificáveis produzidos por um corpo vivo, ou qualquer outro meio biométrico).
- Aquilo que o usuário tem (cartão de identificação, security token, software token ou telefone celular)
- Aquilo que o usuário sabe (senha, frase de segurança, PIN)
Frequentemente é utilizada uma combinação de dois ou mais métodos. Um banco, por exemplo, pode requisitar uma "frase de segurança" além da senha, neste caso o termo "autenticação de dois fatores" é utilizado.Também pode ser chamado de autenticação forte.
Fatores de autenticação
Os fatores de autenticação para humanos são normalmente classificados em três casos:
- Aquilo que o usuário é (impressão digital, padrão retinal, sequência de DNA, padrão de voz, reconhecimento de assinatura, sinais elétricos unicamente identificáveis produzidos por um corpo vivo, ou qualquer outro meio biométrico).
- Aquilo que o usuário tem (cartão de identificação, security token, software token ou telefone celular)
- Aquilo que o usuário sabe (senha, frase de segurança, PIN)
Frequentemente é utilizada uma combinação de dois ou mais métodos. Um banco, por exemplo, pode requisitar uma "frase de segurança" além da senha, neste caso o termo "autenticação de dois fatores" é utilizado.Também pode ser chamado de autenticação forte.
domingo, abril 24, 2011
Hardening de Sistemas Operacionais e Serviços
Quer deixar seu sistema mais seguro e não sabe por onde começar ?
Existem diversos guias/checklists disponíveis na internet para lhe ajudar nessa tarefa:
- NIST National Checklist Program Repository docs by OS - http://web.nvd.nist.gov/view/ncp/repository

- NSA Security Configuration Guides: http://www.nsa.gov/ia/guidance/security_configuration_guides/current_guides.shtml

- CIS Security Configuration Benchmarks: http://cisecurity.org

Como você pode ver, há bastante trabalho a ser feito. Baixe os guias/checklists e comece já!
Existem diversos guias/checklists disponíveis na internet para lhe ajudar nessa tarefa:
- NIST National Checklist Program Repository docs by OS - http://web.nvd.nist.gov/view/ncp/repository

- NSA Security Configuration Guides: http://www.nsa.gov/ia/guidance/security_configuration_guides/current_guides.shtml

- CIS Security Configuration Benchmarks: http://cisecurity.org

Como você pode ver, há bastante trabalho a ser feito. Baixe os guias/checklists e comece já!
sexta-feira, abril 22, 2011
Segurança Física e Proteção de Dados em um Datacenter do Google
Muito bom esse vídeo sobre os controles de acesso e segurança de dados dos datacenters do google. É possível habilitar as legendas e a tradução automática para português:
sábado, abril 16, 2011
Pesquisa sobre Treinamentos para a AppSec Latin America 2011

A OWASP Global AppSec Latin América 2011 irá acontecer no Brasil na cidade de Porto Alegre, estado do Rio Grande do Sul nos dias 04 à 07 de outubro de 2011. Ocorrerão cursos no dias 4 e 5 de outubro, e as sessões plenárias nos dias 6 e 7 de outubro.
Está sendo realizada uma pesquisa sobre os temas para treinamentos. Você pode ajudar, respondendo a pesquisa no seguinte endereço:
http://www.surveymonkey.com/s/3RCZ9RR
Em breve serão anunciados os Call for Papers e Call for Trainings. Acompanhe através do site http://www.appseclatam.org ou pelo twitter AppSecLatam.
terça-feira, abril 05, 2011
Introducão a Web Applications Firewalls
Apresentação realizada no dia 31/março/2011 no primeiro encontro do grupo OWASP Porto Alegre - http://www.owasp.org/index.php/Porto_Alegre
Introducao a Web Applications Firewalls
View more presentations from jczucco.
Marcadores:
apresentações,
modsecurity,
waf
sexta-feira, março 11, 2011
Primeiro encontro do Capítulo OWASP Porto Alegre

ANÚNCIO: Primeiro encontro do Capítulo OWASP Porto Alegre
DATA: 31 de março de 2011, às 19:30 hs - Entrada gratuita a todos embora o estacionamento seja pago.
LOCAL: Unisinos - Auditório Sergio Gomes ( Google Maps )
PROGRAMAÇÂO:
19:30 - 19:40: Recepção
19:40 - 20:20: OWASP na luta em pról de um mundo mais seguro - L. Gustavo C. Barbato
20:20 - 21:00: Introdução a Web Applications Firewalls - Jerônimo Zucco
21:00 - 21:20: Intervalo
21:20 - 22:00: Os Desafios da Segurança no Desenvolvimento com Métodos Ágeis - Rafael Dreher
22:00 - 22:20: Perguntas e Respostas
Agradecemos à UNISINOS por ceder a infraestrutura para a realização da reunião do capítulo.
terça-feira, março 01, 2011
Guia de configuração segura para o Mac OS X 10.6 Snow Leopard

A Apple é conhecida por disponibilizar muita documentação e diversos vídeos demonstrando as funcionalidades de seus aplicativos e sistemas. Mas um que eu sempre recomendo, pois considero muito importante e uso como referência é o Guia de configuração segura para o Mac OS X 10.6 Snow Leopard (em inglês), disponibilizado para download no endereço http://images.apple.com/support/security/guides/docs/SnowLeopard_Security_Config_v10.6.pdf
Este guia fornece uma visão geral dos recursos do Mac OS X que você pode usar para manter o seu Mac seguro, tarefa também conhecida como hardening.
O documento é destinado principalmente aos profissionais de segurança ou usuários com uma certa experiência no sistema, pois as técnicas e funcionalidades expostas podem não ser apropriadas para alguns usuários ou ambientes.
O documento não é destinado para sistemas servidores, para esses ambientes a Apple disponibiliza um outro guia separado, o Mac OS X Server Security Configuration Guide, disponível para download em http://images.apple.com/support/security/guides/docs/SnowLeopard_Server_Security_Config_v10.6.pdf
O Guia possui os seguintes capítulos:
Capítulo 1 - Introdução à arquitetura de segurança do Mac OS X: Discute as camadas de segurança e infra-estrutura do Mac OS X.
Capítulo 2 - Instalando o Mac OS X: descreve como instalar o Mac OS X e também como instalar as atualizações de software explicando as permissões e como consertar problemas referente às permissões.
Capítulo 3 - Securança de sistema e hardware: Explica como proteger fisicamente seu hardware e protegê-lo de ataques," hardware. Este capítulo também explica como proteger as configurações que afetam usuários do computador.
Capítulo 4 - Configurações globais de segurança do sistema: Descreve algumas configurações de segurança globais no firmware e inicialização do Mac OS X Snow Leopard. Mostra também como habilitar os logs do sistema para monitoramento dos eventos.
Capítulo 5 - Preferências de segurança do sistema: Mostra as configurações recomendadas do sistema para aumentar a segurança do Mac OS X.
Capítulo 6 - Segurança de contas de usuário: Demonstra como configurar uma conta de usuário de forma segura. Isso inclui a proteção da conta administrador do sistema, usando o Open Directory, e usando a autenticação forte.
Capítulo 7 - Segurança de dados e uso de criptografia: Descrever como cifrar dados através do uso de criptografia e como usar o método de deleção segura para verificar se os dados apagados são completamente removidos.
Capítulo 8 - Protegendo Aplicativos: Descreve como proteger seus dados ao usar aplicativos da Apple.
Capítulo 9 - Configurando de forma segura serviços de rede: o título já é auto-explicativo.
Capítulo 10 - Gerência avançada de segurança: mostra como realizar auditorias de segurança no sistema para validar a integridade do seu computador e dados.
Apêndice A - Checklist de segurança: Fornece uma lista de verificação para proteger seu sistema.
Apêndice B - Scripts de segurança: Fornece um modelo para criação de scripts para proteger o seu computador.
Nota: Como a Apple lança periodicamente novas versões e atualizações do software, as imagens mostradas neste livro pode ser diferente do que você vê em sua tela.
Caso você possua as versões mais antigas do Mac OS (Leopard, Tiger ou Panther), existem outros documentos disponíveis em http://www.apple.com/support/security/guides/ (em inglês).

Boa leitura, e fique seguro!
quinta-feira, fevereiro 10, 2011
terça-feira, fevereiro 08, 2011
quarta-feira, fevereiro 02, 2011
O fim do IP conforme nós conhecemos
Alerta do CAIS (Centro de Atendimento a Incidentes de Seguranca) de 01 de fevereiro de 2011:
http://www.rnp.br/cais/alertas/rss.xml
Prezados,
O CAIS está repassando uma notícia publicada pelo ISC (Internet Storm Center) intitulada "The End Of IP As We Know It", que trata do esgotamento de endereçamento IPv4 disponível.
No dia 01 de fevereiro de 2011 a IANA (Internet Assigned Numbers Authority), responsável pela coordenação global dos endereços IP, DNS raíz e pelo registro de protocolos de Internet anunciou a distribuição de mais duas classes de endereçamento IPv4 /8 à APNIC (Asia Pacific Network Information Centre).
Como resultado, restaram somente 5 classes /8 à IANA, que colocou em prática uma política especial de distribuí-las à cada um dos registros regionais (RIR): AFRNIC (África), APNIC (Ásia Pacifico), ARIN (América do Norte), LACNIC (América Latina) e RIPE (Europa).
Para esclarecer possíveis dúvidas sobre o esgotamento do endereçamento IPv4 disponível, o ISC preparou um FAQ sobre o tema. O FAQ segue traduzido ao final deste alerta.
A IANA fornece endereçamentos IPs aos RIRs em blocos /8, repassando-os aos provedores de internet, que, por sua vez, os alocam aos usuários finais.
1 - A Internet vai parar de funcionar?
Não. Na verdade, é improvável que a Internet IPv4 vá parar tão cedo. É provável que ela coexista pacificamente ao lado da Internet IPv6. Já existem alguns mecanismos de transição entre as duas versões. Apesar de não ser uma solução elegante, as duas "internets" podem falar entre si através de proxies e túneis.
2 - Por que os endereços foram extintos?
Com IPv4 é possível alocar cerca de 4 bilhões de endereços. Há cerca de 6 bilhões de pessoas no mundo, imagine quantos endereços você precisa (telefone de casa, trabalho ...)? É uma questão simples de matemática, agravado pelo fato de que para ter um roteamento eficiente, não é possível
alocar todos os endereços.
3 - Vários endereços IPv4 ainda não são utilizados. Por que não
utilizá-los de forma mais eficaz?
O problema não é somente o fato de esgotarem os endereços, ainda que este seja o motivo principal, a atribuição de endereços de forma mais eficaz implicaria em alocações menores, o que tornaria mais complexas as tabelas de roteamento. Para fazer isto, seria necessário "re-numerar" a Internet, e ainda assim, ficaríamos sem endereços disponíveis em algum momento.
4 - E sobre a alocação de espaço IPv4 legada? A Apple realmente precisa
de um /8?
No início da Internet, espaço de endereçamento IPv4 foi entregue de uma forma muito liberal. Lembre-se que a Internet era apenas uma experiência! Alguns dos participantes originais ainda têm grandes alocações IPv4 e não as utilizam de forma eficiente. No entanto, mesmo se todos eles
entregassem seus espaços de volta, atrasaria o problema por apenas 1 ou 2 anos e implicaria em um grande custo para as empresas afetadas (e estas possuem contratos dando-lhes o direito de usar o espaço de endereço). Algumas "alocações legadas" foram devolvidas no passado.
5 - O que eu preciso fazer hoje?
Não precisa se desesperar. Nada vai acontecer tão rápido. Os RIRs (Regional Internet Registries) ainda possuem endereços alocáveis por alguns meses e, dependendo da região, por um ano. Quando estas alocações se esgotarem é que vai ficar mais complicado. Ficará mais difícil obter
espaço de endereços IPv4. Eventualmente, os ISP (Internet Service Providers) poderão solicitar de volta espaços alocados a clientes, visto que eles não terão como obter novos endereços com o RIR. Ao longo do tempo, alocação de espaço IPv4 vai ficar mais cara que IPv6.
6 - Então, eu posso apenas esperar e não fazer nada?
Não. O que você deve fazer amanhã (talvez hoje?) é configurar um laboratório de testes para se familiarizar com o IPv6. É fácil para começar. Pergunte ao seu ISP se ele já suporta IPv6 (ou quando suportará), ou configure um túnel com um provedor gratuito como o túnel Hurricane
Electric [2] ou SixXS [3] (existem outros). Você precisa de um planejamento para saber como lidar com esta nova tecnologia. Mesmo que você não precise de IPv6, talvez seus parceiros de negócios podem começar a utilizá-lo e você precisará conectá-los via IPv6.
7 - Não posso simplesmente ignorá-lo?
Lembre-se, porque você está usando o IP em primeiro lugar? Ele permite que você se conecte com clientes, fornecedores, filiais etc. Em suma: te mantém no negócio. Assim que estes parceiros começarem a migrar para conectividade IPv6, você provavelmente terá que mudar também. É como
qualquer outra tecnologia, no fim ela tem que dar suporte ao negócio (e bem... também é muito divertido!).
8 - O que vai mudar a partir de um ponto de vista da segurança?
Tudo e nada. A mudança mais importante de IPv4 para IPv6 é provavelmente o fato de que o NAT (Network Address Translation) vai se tornar menos importante. Proteção ao usuário final e firewalls bem configurados se tornarão mais importantes. A detecção passiva de recurso se tornará mais importante em relação à varredura ativa. Há um monte de artefatos de segurança que você possui e que provavelmente faz um péssimo trabalho ao lidar com IPv6. Eu mencionei que isto requer um planejamento e teste?
MAIS INFORMAÇÕES
. The End Of IP As We Know It
http://isc.sans.edu/diary.html?storyid=10342
. IANA IPv4 Address Space Registry
http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml
. Leading Global Internet Groups make Significant Announcement about the Status of the IPv4 Address Pool
http://www.apnic.net/publications/news/2011/leading-global-internet-groups-make-significant-announcement-about-the-status-of-the-ipv4-address-pool
. IPv6.BR
http://www.ipv6.br/
Os Alertas do CAIS também são oferecidos no formato RSS/RDF e no Twitter:
http://www.rnp.br/cais/alertas/rss.xml
Siga @cais_rnp.
Atenciosamente,
################################################################
# CENTRO DE ATENDIMENTO A INCIDENTES DE SEGURANCA (CAIS) #
# Rede Nacional de Ensino e Pesquisa (RNP) #
# #
# cais@cais.rnp.br http://www.cais.rnp.br #
# Tel. 019-37873300 Fax. 019-37873301 #
# Chave PGP disponivel http://www.rnp.br/cais/cais-pgp.key #
################################################################
================================================================
http://www.rnp.br/cais/alertas/rss.xml
Prezados,
O CAIS está repassando uma notícia publicada pelo ISC (Internet Storm Center) intitulada "The End Of IP As We Know It", que trata do esgotamento de endereçamento IPv4 disponível.
No dia 01 de fevereiro de 2011 a IANA (Internet Assigned Numbers Authority), responsável pela coordenação global dos endereços IP, DNS raíz e pelo registro de protocolos de Internet anunciou a distribuição de mais duas classes de endereçamento IPv4 /8 à APNIC (Asia Pacific Network Information Centre).
Como resultado, restaram somente 5 classes /8 à IANA, que colocou em prática uma política especial de distribuí-las à cada um dos registros regionais (RIR): AFRNIC (África), APNIC (Ásia Pacifico), ARIN (América do Norte), LACNIC (América Latina) e RIPE (Europa).
Para esclarecer possíveis dúvidas sobre o esgotamento do endereçamento IPv4 disponível, o ISC preparou um FAQ sobre o tema. O FAQ segue traduzido ao final deste alerta.
A IANA fornece endereçamentos IPs aos RIRs em blocos /8, repassando-os aos provedores de internet, que, por sua vez, os alocam aos usuários finais.
1 - A Internet vai parar de funcionar?
Não. Na verdade, é improvável que a Internet IPv4 vá parar tão cedo. É provável que ela coexista pacificamente ao lado da Internet IPv6. Já existem alguns mecanismos de transição entre as duas versões. Apesar de não ser uma solução elegante, as duas "internets" podem falar entre si através de proxies e túneis.
2 - Por que os endereços foram extintos?
Com IPv4 é possível alocar cerca de 4 bilhões de endereços. Há cerca de 6 bilhões de pessoas no mundo, imagine quantos endereços você precisa (telefone de casa, trabalho ...)? É uma questão simples de matemática, agravado pelo fato de que para ter um roteamento eficiente, não é possível
alocar todos os endereços.
3 - Vários endereços IPv4 ainda não são utilizados. Por que não
utilizá-los de forma mais eficaz?
O problema não é somente o fato de esgotarem os endereços, ainda que este seja o motivo principal, a atribuição de endereços de forma mais eficaz implicaria em alocações menores, o que tornaria mais complexas as tabelas de roteamento. Para fazer isto, seria necessário "re-numerar" a Internet, e ainda assim, ficaríamos sem endereços disponíveis em algum momento.
4 - E sobre a alocação de espaço IPv4 legada? A Apple realmente precisa
de um /8?
No início da Internet, espaço de endereçamento IPv4 foi entregue de uma forma muito liberal. Lembre-se que a Internet era apenas uma experiência! Alguns dos participantes originais ainda têm grandes alocações IPv4 e não as utilizam de forma eficiente. No entanto, mesmo se todos eles
entregassem seus espaços de volta, atrasaria o problema por apenas 1 ou 2 anos e implicaria em um grande custo para as empresas afetadas (e estas possuem contratos dando-lhes o direito de usar o espaço de endereço). Algumas "alocações legadas" foram devolvidas no passado.
5 - O que eu preciso fazer hoje?
Não precisa se desesperar. Nada vai acontecer tão rápido. Os RIRs (Regional Internet Registries) ainda possuem endereços alocáveis por alguns meses e, dependendo da região, por um ano. Quando estas alocações se esgotarem é que vai ficar mais complicado. Ficará mais difícil obter
espaço de endereços IPv4. Eventualmente, os ISP (Internet Service Providers) poderão solicitar de volta espaços alocados a clientes, visto que eles não terão como obter novos endereços com o RIR. Ao longo do tempo, alocação de espaço IPv4 vai ficar mais cara que IPv6.
6 - Então, eu posso apenas esperar e não fazer nada?
Não. O que você deve fazer amanhã (talvez hoje?) é configurar um laboratório de testes para se familiarizar com o IPv6. É fácil para começar. Pergunte ao seu ISP se ele já suporta IPv6 (ou quando suportará), ou configure um túnel com um provedor gratuito como o túnel Hurricane
Electric [2] ou SixXS [3] (existem outros). Você precisa de um planejamento para saber como lidar com esta nova tecnologia. Mesmo que você não precise de IPv6, talvez seus parceiros de negócios podem começar a utilizá-lo e você precisará conectá-los via IPv6.
7 - Não posso simplesmente ignorá-lo?
Lembre-se, porque você está usando o IP em primeiro lugar? Ele permite que você se conecte com clientes, fornecedores, filiais etc. Em suma: te mantém no negócio. Assim que estes parceiros começarem a migrar para conectividade IPv6, você provavelmente terá que mudar também. É como
qualquer outra tecnologia, no fim ela tem que dar suporte ao negócio (e bem... também é muito divertido!).
8 - O que vai mudar a partir de um ponto de vista da segurança?
Tudo e nada. A mudança mais importante de IPv4 para IPv6 é provavelmente o fato de que o NAT (Network Address Translation) vai se tornar menos importante. Proteção ao usuário final e firewalls bem configurados se tornarão mais importantes. A detecção passiva de recurso se tornará mais importante em relação à varredura ativa. Há um monte de artefatos de segurança que você possui e que provavelmente faz um péssimo trabalho ao lidar com IPv6. Eu mencionei que isto requer um planejamento e teste?
MAIS INFORMAÇÕES
. The End Of IP As We Know It
http://isc.sans.edu/diary.html?storyid=10342
. IANA IPv4 Address Space Registry
http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml
. Leading Global Internet Groups make Significant Announcement about the Status of the IPv4 Address Pool
http://www.apnic.net/publications/news/2011/leading-global-internet-groups-make-significant-announcement-about-the-status-of-the-ipv4-address-pool
. IPv6.BR
http://www.ipv6.br/
Os Alertas do CAIS também são oferecidos no formato RSS/RDF e no Twitter:
http://www.rnp.br/cais/alertas/rss.xml
Siga @cais_rnp.
Atenciosamente,
################################################################
# CENTRO DE ATENDIMENTO A INCIDENTES DE SEGURANCA (CAIS) #
# Rede Nacional de Ensino e Pesquisa (RNP) #
# #
# cais@cais.rnp.br http://www.cais.rnp.br #
# Tel. 019-37873300 Fax. 019-37873301 #
# Chave PGP disponivel http://www.rnp.br/cais/cais-pgp.key #
################################################################
================================================================
domingo, janeiro 30, 2011
Servidor VPN L2TP/IPSec
Redes wi-fi abertas disponíveis ao público já são comuns de encontrar em eventos, bares, shoppings. Mas como navegar de maneira segura através das redes públicas?
A solução para isso é uso de VPNs (Virtual Private Network, ou Rede Privada Virtual). Conforme definição na wikipedia:
Rede Privada Virtual é uma rede de comunicações privada normalmente utilizada por uma empresa ou um conjunto de empresas e/ou instituições, construída em cima de uma rede de comunicações pública (como por exemplo, a Internet). O tráfego de dados é levado pela rede pública utilizando protocolos padrão, não necessariamente seguros.
VPNs seguras usam protocolos de criptografia por tunelamento que fornecem a confidencialidade, autenticação e integridade necessárias para garantir a privacidade das comunicações requeridas. Quando adequadamente implementados, estes protocolos podem assegurar comunicações seguras através de redes inseguras.
Deve ser notado que a escolha, implementação e uso destes protocolos não é algo trivial, e várias soluções de VPN inseguras são distribuídas no mercado. Adverte-se os usuários para que investiguem com cuidado os produtos que fornecem VPNs. Por si só, o rótulo VPN é apenas uma ferramenta de marketing.

O PROBLEMA:
Possuo um smartphone com o sistema operacional Android, e por diversas vezes preciso utilizar as redes wifi públicas para acessar alguns serviços da internet, e gostaria de fazer isso de forma segura e simples. Já que precisaria implantar um servidor de VPN, estabeleci alguns requisitos:
- Simples de configurar nos clientes VPN
- Uso de criptografia forte
- Tenha clientes multiplataforma (Smartphones Android, IPhone, sistemas operacionais Mac OS, Linux, Windows, BSD)
- Tenha cliente nativo em Android, sem necessidade de procedimento de root
- Cliente nativo para Mac OS, para utilizar a VPN no notebook
- Como vou utilizar um servidor Linux (em um provedor fora do país), utilizar pacotes disponíveis na distribuição Debian
A SOLUÇÃO:
Verificando os requisitos acima, cheguei até a opção de servidor VPN L2TP/IPSec (alguém tem alguma outra sugestão?). Para facilitar a configuração, a VPN vai ser através do uso de uma chave pré-compartilhada (PSK - Pre-shared key) e uma autenticação de usuário e senha. Simples e eficiente. É possível fazer a configuração utilizando certificados digitais, porém sua configuração dos clientes é mais complicada.
O servidor utilizado é um Linux Debian Lenny, utilizando sempre softwares instalados através do gerenciador de pacotes do repositório oficial. Alguns sites de referência que utilizei foram esses:
http://www.jacco2.dds.nl/networking/openswan-macosx.html
http://riobard.com/blog/2010-04-30-l2tp-over-ipsec-ubuntu/
http://tools.ietf.org/html/rfc3193
http://tools.ietf.org/html/rfc2661
Passo 1: Instalar os pacotes
# apt-get install openswan xl2tpd ppp
Passo 2: Configurar o IPSec
Editar o arquivo /etc/ipsec.conf e colocar o seguinte conteúdo:
version 2.0
config setup
nat_traversal=yes
virtual_private=%v4:10.0.0.0/8 <-- Mude os IPs da VPN conforme necessidade
protostack=netkey
conn L2TP-PSK-NAT
rightsubnet=vhost:%priv
also=L2TP-PSK-noNAT
conn L2TP-PSK-noNAT
authby=secret
pfs=no
auto=add
keyingtries=3
rekey=no
ikelifetime=8h
keylife=1h
type=transport
left=IP.SEU.SERVIDOR <-- Mude para o IP do seu servidor VPN
leftprotoport=17/1701
right=%any
rightprotoport=17/%any
# 'include' this file to disable Opportunistic Encryption.
# See /usr/share/doc/openswan/policygroups.html for details.
#
# RCSID $Id: no_oe.conf.in,v 1.2 2004-10-03 19:33:10 paul Exp $
conn block
auto=ignore
conn private
auto=ignore
conn private-or-clear
auto=ignore
conn clear-or-private
auto=ignore
conn clear
auto=ignore
conn packetdefault
auto=ignore
Editar o arquivo /etc/ipsec.secrets:
IP.SEU.SERVIDOR %any: PSK "SuaSenhaCompartilhada"
Passo 3: Configurar o L2TP
O L2TP (Layer 2 Tunneling Protocol) fornece um túnel para enviar dados. Ele não fornece criptografia e autenticação, porém, é por isso que precisamos usá-lo em conjunto com o IPSec. Curiosamente, tanto a Apple quanto a Microsoft costumam se referir ao L2TP como a tecnologia VPN segura, mas ignoram totalmente o fato de que a segurança é fornecida pelo IPSec.
Edite o arquivo /etc/xl2tpd/xl2tpd.conf:
[global]
ipsec saref = yes
[lns default]
ip range = 10.1.2.2-10.1.2.255 <-- Modifique de acordo com o número de clientes
local ip = 10.1.2.1 <-- IP do servidor VPN no túnel (lado esquerdo)
refuse chap = yes
refuse pap = yes
require authentication = yes
ppp debug = yes
pppoptfile = /etc/ppp/options.xl2tpd
length bit = yes
Passo 4: Configuração do PPP
Edite o arquivo /etc/ppp/options.xl2tpd:
require-mschap-v2
ms-dns 8.8.8.8 <-- Coloquei aqui os servidores DNS públicos do google
ms-dns 8.8.4.4
asyncmap 0
auth
crtscts
lock
hide-password
modem
debug
name l2tpd
proxyarp
lcp-echo-interval 30
lcp-echo-failure 4
Edite o arquivo /etc/ppp/chap-secrets para cadastrar os usuários e senhas:
# user server password ip
test l2tpd testpassword *
Passo 5: Prepare a rede conforme necessidade
Eu criei um script de start de todos os serviços, já configurando a rede para a VPN e realizando NAT:
#!/bin/bash
for each in /proc/sys/net/ipv4/conf/*
do
echo 0 > $each/accept_redirects
echo 0 > $each/send_redirects
done
/etc/init.d/ipsec start
/etc/init.d/xl2tpd start
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Nesse site tem as configurações do cliente VPN em smartphones Android:https://12vpn.com/wiki/index.php?title=Android_1.6_L2TP/IPSec_PSK_instructions
Pronto. A configuração de clientes para Android e para Mac OS é bem simples e é nativo, não é necessário instalar nenhum programa para configuração. Agora você já pode utilizar as redes públicas abertas de forma segura.
A solução para isso é uso de VPNs (Virtual Private Network, ou Rede Privada Virtual). Conforme definição na wikipedia:
Rede Privada Virtual é uma rede de comunicações privada normalmente utilizada por uma empresa ou um conjunto de empresas e/ou instituições, construída em cima de uma rede de comunicações pública (como por exemplo, a Internet). O tráfego de dados é levado pela rede pública utilizando protocolos padrão, não necessariamente seguros.
VPNs seguras usam protocolos de criptografia por tunelamento que fornecem a confidencialidade, autenticação e integridade necessárias para garantir a privacidade das comunicações requeridas. Quando adequadamente implementados, estes protocolos podem assegurar comunicações seguras através de redes inseguras.
Deve ser notado que a escolha, implementação e uso destes protocolos não é algo trivial, e várias soluções de VPN inseguras são distribuídas no mercado. Adverte-se os usuários para que investiguem com cuidado os produtos que fornecem VPNs. Por si só, o rótulo VPN é apenas uma ferramenta de marketing.

O PROBLEMA:
Possuo um smartphone com o sistema operacional Android, e por diversas vezes preciso utilizar as redes wifi públicas para acessar alguns serviços da internet, e gostaria de fazer isso de forma segura e simples. Já que precisaria implantar um servidor de VPN, estabeleci alguns requisitos:
- Simples de configurar nos clientes VPN
- Uso de criptografia forte
- Tenha clientes multiplataforma (Smartphones Android, IPhone, sistemas operacionais Mac OS, Linux, Windows, BSD)
- Tenha cliente nativo em Android, sem necessidade de procedimento de root
- Cliente nativo para Mac OS, para utilizar a VPN no notebook
- Como vou utilizar um servidor Linux (em um provedor fora do país), utilizar pacotes disponíveis na distribuição Debian
A SOLUÇÃO:
Verificando os requisitos acima, cheguei até a opção de servidor VPN L2TP/IPSec (alguém tem alguma outra sugestão?). Para facilitar a configuração, a VPN vai ser através do uso de uma chave pré-compartilhada (PSK - Pre-shared key) e uma autenticação de usuário e senha. Simples e eficiente. É possível fazer a configuração utilizando certificados digitais, porém sua configuração dos clientes é mais complicada.
O servidor utilizado é um Linux Debian Lenny, utilizando sempre softwares instalados através do gerenciador de pacotes do repositório oficial. Alguns sites de referência que utilizei foram esses:
http://www.jacco2.dds.nl/networking/openswan-macosx.html
http://riobard.com/blog/2010-04-30-l2tp-over-ipsec-ubuntu/
http://tools.ietf.org/html/rfc3193
http://tools.ietf.org/html/rfc2661
Passo 1: Instalar os pacotes
# apt-get install openswan xl2tpd ppp
Passo 2: Configurar o IPSec
Editar o arquivo /etc/ipsec.conf e colocar o seguinte conteúdo:
version 2.0
config setup
nat_traversal=yes
virtual_private=%v4:10.0.0.0/8 <-- Mude os IPs da VPN conforme necessidade
protostack=netkey
conn L2TP-PSK-NAT
rightsubnet=vhost:%priv
also=L2TP-PSK-noNAT
conn L2TP-PSK-noNAT
authby=secret
pfs=no
auto=add
keyingtries=3
rekey=no
ikelifetime=8h
keylife=1h
type=transport
left=IP.SEU.SERVIDOR <-- Mude para o IP do seu servidor VPN
leftprotoport=17/1701
right=%any
rightprotoport=17/%any
# 'include' this file to disable Opportunistic Encryption.
# See /usr/share/doc/openswan/policygroups.html for details.
#
# RCSID $Id: no_oe.conf.in,v 1.2 2004-10-03 19:33:10 paul Exp $
conn block
auto=ignore
conn private
auto=ignore
conn private-or-clear
auto=ignore
conn clear-or-private
auto=ignore
conn clear
auto=ignore
conn packetdefault
auto=ignore
Editar o arquivo /etc/ipsec.secrets:
IP.SEU.SERVIDOR %any: PSK "SuaSenhaCompartilhada"
Passo 3: Configurar o L2TP
O L2TP (Layer 2 Tunneling Protocol) fornece um túnel para enviar dados. Ele não fornece criptografia e autenticação, porém, é por isso que precisamos usá-lo em conjunto com o IPSec. Curiosamente, tanto a Apple quanto a Microsoft costumam se referir ao L2TP como a tecnologia VPN segura, mas ignoram totalmente o fato de que a segurança é fornecida pelo IPSec.
Edite o arquivo /etc/xl2tpd/xl2tpd.conf:
[global]
ipsec saref = yes
[lns default]
ip range = 10.1.2.2-10.1.2.255 <-- Modifique de acordo com o número de clientes
local ip = 10.1.2.1 <-- IP do servidor VPN no túnel (lado esquerdo)
refuse chap = yes
refuse pap = yes
require authentication = yes
ppp debug = yes
pppoptfile = /etc/ppp/options.xl2tpd
length bit = yes
Passo 4: Configuração do PPP
Edite o arquivo /etc/ppp/options.xl2tpd:
require-mschap-v2
ms-dns 8.8.8.8 <-- Coloquei aqui os servidores DNS públicos do google
ms-dns 8.8.4.4
asyncmap 0
auth
crtscts
lock
hide-password
modem
debug
name l2tpd
proxyarp
lcp-echo-interval 30
lcp-echo-failure 4
Edite o arquivo /etc/ppp/chap-secrets para cadastrar os usuários e senhas:
# user server password ip
test l2tpd testpassword *
Passo 5: Prepare a rede conforme necessidade
Eu criei um script de start de todos os serviços, já configurando a rede para a VPN e realizando NAT:
#!/bin/bash
for each in /proc/sys/net/ipv4/conf/*
do
echo 0 > $each/accept_redirects
echo 0 > $each/send_redirects
done
/etc/init.d/ipsec start
/etc/init.d/xl2tpd start
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Nesse site tem as configurações do cliente VPN em smartphones Android:https://12vpn.com/wiki/index.php?title=Android_1.6_L2TP/IPSec_PSK_instructions
Pronto. A configuração de clientes para Android e para Mac OS é bem simples e é nativo, não é necessário instalar nenhum programa para configuração. Agora você já pode utilizar as redes públicas abertas de forma segura.
domingo, dezembro 12, 2010
Impacto das Redes Sociais na Segurança da Informação
Apresentação realizada no evento ISSA Day Regional – Porto Alegre em 08 de dezembro de 2010 - http://www.issabrasil.org/2010/12/04/issa-day-regional-porto-alegre
Implementando o OSSEC HIDS
Tutorial realizado no GTS 16 em 25 de novembro de 2010. Em breve o vídeo será disponibilizado.
http://gter.nic.br/reunioes/gter-30/programa
http://gter.nic.br/reunioes/gter-30/programa
Implementing ossec
View more presentations from jczucco.
quarta-feira, novembro 03, 2010
Tutorial de OSSEC no GTER/GTS em São Leopoldo
Irá ocorrer nos dias 25, 26 e 27 de novembro de 2010 o GTER - Grupo de Trabalho de Engenharia e Operação de Redes - 30ª Reunião e o GTS - Grupo de Trabalho em Segurança de Redes - 16ª Reunião, na Unisinos em São Leopoldo. O evento é gratuito e as inscrições estão abertas e podem ser feitas pelo site http://gter.nic.br/reunioes/gter-30/
Estarei ministrando no primeiro dia um tutorial de 8 horas sobre Implantação do OSSEC HIDS. Abaixo segue a programação do tutorial:
Descrição:
Esse curso tem por objetivo apresentar de forma prática a implantação e uso do HIDS (Host-based intrusion detection system) de código aberto OSSEC - http://www.ossec.net - criado pelo brasileiro Daniel Cid e muito utilizado para monitoramento de servidores.
Sumário:
- Introdução
- Arquitetura
- Análise de logs
- Monitoramento de integridade
- Detecção de rootkits
- Auditoria de políticas
- Alertas
- Active Response
- Instalação de servidor e agentes
- Configuração
- Arquivos de regras
- Personalização de regras: falso positivos e negativos
- Monitoramento e alertas
Abaixo a programção dos demais dias do evento:
25/11/2010 - Tutoriais
08:00 - 17:00 Implementando o OSSEC HIDS
Jerônimo Zucco - Universidade de Caxias do Sul
08:00 - 17:00 BGP para provedores de serviço
26/11/2010 - GTER 30
08:00 - 08:50 Recepção
08:50 - 09:00 Abertura
09:00 - 09:20 De onde vem o spam? Seis meses de funcionamento de um 'spamtrap'
Danton Nunes - Internexo
09:20 - 10:00 Boas práticas para peering no PTTMetro
Luís Balbinot - Commcorp Telecom
10:00 - 10:30 DNSSEC - Provisionamento e reassinatura automática usando BIND
David Robert Camargo de Campos e Wilson Rogério Lopes - Nic.br
10:30 - 11:00 Coffee Break
11:00 - 11:30 Relato da entrada do servidor DNS raiz "I" em Porto Alegre
Leandro Bertholdo e Liane Tarouco - UFRGS
11:30 - 12:30 DNS Root Signing HowTo, Lessons Learned, and Future Impact
Richard Lamb - ICANN
12:30 - 14:00 Almoço
14:00 - 14:50 Ferramentas para coexistência e transição IPv4 e IPv6
Antonio M. Moreiras - Nic.br
14:50 - 15:10 ASN 32bits - Seu uso na Internet BR
Ricardo Patara - Nic.br
15:10 - 15:40 Coffee Break
15:40 - 16:00 IPv6 - Análise sobre seu uso na Internet BR
Ricardo Patara - Nic.br
16:00 - 16:30 IPv6 sobre Redes Metropolitanas. Estudo de Caso: MetroPoa
Cesar Loureiro, Leandro Bertholdo e Liane Tarouco - UFRGS
16:30 - 17:30 BIND 10 - The architecture of the next generation DNS server
Shane Kerr - ISC
27/11/2010 - GTS 16
08:00 - 08:50 Recepção
08:50 - 09:00 Abertura
09:00 - 09:40 Secure Application Development for the Enterprise : Practical,
Real-world Tips
Luiz Gustavo Cunha Barbato, Mauricio Westendorff Pegoraro e
Rafael Dreher - Dell
09:40 - 10:20 Coleta, Identificação e Extração de Dados (Data Carving)
em Mídias e em Redes
Ricardo Kléber Martins Galvão - IFRN
10:20 - 10:50 Coffee Break
10:50 - 11:30 Apresentação convidada (a definir)
11:30 - 12:10 Resposta a incidentes: Diagnosticos equivocados e finais felizes
Nelson Murilo - DTE
12:10 - 14:00 Almoço
14:00 - 14:40 Usando visualização para documentação rápida de incidentes
de segurança
Gabriel Dieterich Cavalcante e Paulo Lício de Geus - IC/UNICAMP
14:40 - 15:20 Análise Comportamental de Malware
André Grégio, Dario Fernandes, Vitor Afonso e
Paulo Lício de Geus - CTI/MCT e UNICAMP
15:20 - 15:50 Coffee Break
15:50 - 16:30 Estudos de Caso
Reinaldo de Medeiros - Entropia Security
16:30 - 17:10 Segurança em Passaportes Eletrônicos
Ivo de Carvalho Peixinho - Polícia Federal
17:10 - 17:20 Encerramento
Estarei participando do evento nos dias 25 e 26, pois no dia 27 estarei indo à São Paulo participar da Sétima Edição da Hackers to Hackers Conference - H2HC. Pena que não vou conseguir participar do GTS, que também vai ser muito bom.
Nos encontramos lá.
quarta-feira, outubro 27, 2010
Três alternativas para se proteger do Firesheep
Alternativa 1: Utilizar o plugin NoScript no Firefox e configurar:
NoScript->Options->Advanced->HTTPS
Force the following sites to use secure (HTTPS) connections:
twitter.com
*.twitter.com
google.com
*.google.com
facebook.com
*.facebook.com

Alternativa 2: Instalar o plugin HTTPS Everywhere no Firefox;
Alternartiva 3: Não usar twitter, facebook, gmail e qualquer serviço que não utilize sempre canal seguro para comunicação em redes públicas, ou sempre verificar se o seu acesso é sempre via https ou através de VPN.
Apresentação sobre o Firesheep realizada na Toorcon aqui.
O ataque do Firesheep não é novidade, apenas facilitou com poucos cliques o que já era possível fazer a mão e escancarou o problema. E o Firesheep também não é único, também existe a ferramenta Idiocy, feita em python.
Para os desenvolvedores Web:
- Todos os cookies das aplicações devem estar com a flag "Secure" especificada.
- Outro cuidado é também especificar a flag "HTTPOnly" nos cookies, para evitar ataques do tipo XSS (cross-site scripting).
Para maiores referências, verifiquem a página da OWASP: http://www.owasp.org/index.php/Testing_for_cookies_attributes_%28OWASP-SM-002%29
quinta-feira, outubro 21, 2010
Assinar:
Postagens (Atom)


