Zucco Weblog

Além do HTTPS - Como (tentar) Aumentar a Segurança de seu Website e Aplicação Web

2015-08-22T10:44:00.001-03:00

Além do HTTPS - Como (tentar) Aumentar a Segurança de seu Website e Aplicação Web (Beyond HTTPS - How to (try) Improve security in Your Website). Segurança em websites é uma tarefa difícil. Apenas uma brecha em um erro de desenvolvimento ou uma configuração esquecida e mal feita e seu portal pode ser comprometido. Não basta mais somente implementar alguns controles ou ter alguns cuidados na hora da implementação de uma aplicação que será exposta para web. Essa palestra irá abordar como (tentar) aumentar a segurança se seu website através da implementação de alguns controles pró-ativos como: hardening TLS, HSTS, certificate and public key pinning, HTTP headers, XSS protections, Cookies protections, Content Security Policy, Hardening Web Server. Apresentação realizada na BHack 2015 e FISL 16.

Além do HTTPS - Como (tentar) Aumentar a Segurança de seu Website e Aplicação Web (Beyond HTTPS - How to (try) Improve security in Your Website) from Jeronimo Zucco

Validando a Segurança de Software

2015-08-22T10:42:00.000-03:00

Apresentação sobre segurança em desenvolvimento de software realizada na Terceira Jornada Acadêmica de Computação e Tecnologia da Informação da UCS:Tendências em TI - Outubro/2014.

Validando a Segurança de Software from Jeronimo Zucco

Segurança Através de Gerência de Configurações

2015-08-22T10:40:00.003-03:00

Segurança Através de Gerência de Configurações - Apresentação realizada no Tchelinux Caxias - Set/2014

Segurança Através de Gerência de Configurações from Jeronimo Zucco

OWASP Top 10 2013

2015-08-22T10:38:00.003-03:00

Apresentação realizada no Tchelinux Caxias do Sul 2013 - http://tchelinux.org/site/doku.php?id=evento_2013_08_cxs

Owasp top 10 2013 from Jeronimo Zucco

Segurança em Desenvolvimento de Software - ForTI Univattes - Maio/2013

2015-08-22T10:37:00.000-03:00

Apresentação realizada na ForTI (grupo de TI das universidades particulares gaúchas) em Maio/2013.

Segurança em desenvolvimento de software from Jeronimo Zucco

Web Application Firewalls - Tchelinux 2012

2012-10-12T22:57:00.000-03:00

Abaixo a minha apresentação que realizei no Tchelinux Caxias do Sul 2012 sobre Web Application Firewalls: ModSecurity + OWASP Broken Web Application Project.

Utilizei uma parte da minha apresentação sobre WAF que fiz ano passado no primeiro encontro OWASP, mas dessa vez tive mais tempo, e realizei algumas demonstrações utilizando o ModSecurity e uma VM com o BWA.

Introducao WAF Tchelinux 2012 from Jeronimo Zucco

ModSecurity Series 4 - SecRuleRemoveById

2012-08-27T13:18:00.002-03:00

Após habilitar o ModSecurity, uma das primeiras tarefas a serem realizadas é a de verificar por falso-positivos. Existem diversas maneiras de desabiltar uma regra do ModSecurity, vamos ver algumas delas nesse post:

- Desabilitar a regra no arquivo de rules: essa é a maneira mais simples, basta editar o arquivo onde a regra se encontra, e simplesmente excluí-la ou comentá-la com "#". Apesar de ser simples, isso não é recomendado, pois ao atualizar posteriormente os arquivos de regras, essa tarefa terá que ser feita novamente. Outra desvantagem é que nem sempre queremos desabilitar toda a regra, e sim somente para um determinado contexto do Apache, ou para um IP ou para uma url do site, e deixá-la habilitada para o resto.

- Desabilitar o ModSecurity para um endereço IP específico: Segue exemplo abaixo:

SecRule REMOTE_ADDR "@streq 192.168.1.1" \
phase:1,t:none,nolog,allow

- SecRuleRemoveById: - Como o próprio nome da regra diz, permite que uma regra seja desabilitada no ModSecurity somente passando o seu ID. A vantagem do seu uso é a simplicidade na sua aplicação, e além disso, o uso de contextos no apache. Seguem abaixo alguns exemplos:

- Desabilitar a regra com o ID 950007 (Blind SQL injection, cuja regras está no arquivo modsecurity_crs_41_sql_injection_attacks.conf da CRS), somente da URL /foo/bar :

<Location ^/foo/bar/>
SecRuleRemoveById 950007
</Location>

- Com o uso do Location do apache, é possível criar expressões regulares para liberação como nos exemplos abaixo:

<LocationMatch ^/foo/bar/[0-9]+/edit/$>
SecRuleRemoveById 950007
</LocationMatch>

<LocationMatch ^/foo/.+/bar/.+/edit/$>
SecRuleRemoveById 950007
</LocationMatch>

- Também é possível usar outras diretivas do Apache em conjunto com diretivas do ModSecurity, como por exemplo Virtualhost:

ServerAdmin webmaster@host.example.com

DocumentRoot /www/docs/host.example.com

ServerName host.example.com

ErrorLog logs/host.example.com-error_log

TransferLog logs/host.example.com-access_log

SecRuleEngine On

</VirtualHost>

ServerAdmin webmaster@host2.example.com

DocumentRoot /www/docs/host2.example.com

ServerName host2.example.com

ErrorLog logs/host2.example.com-error_log

TransferLog logs/host2.example.com-access_log

SecRuleEngine Off

</VirtualHost>

- Também é possível utilizar outros métodos para desabilitar as regras, como por exemplo: uso de variáveis transacionais, SecRuleRemoveByMsg, SecRuleRemoveByTag, SecRuleUpdateActionById, SecRuleUpdateTargetById (deprecated), SecRuleUpdateTargetByMsg, SecRuleUpdateTargetByTag, ctl:ruleRemoveById, ctl:ruleRemoveTargetById. Essas diretivas ficam para posts futuros.

ModSecurity Series 3 - SecRuleEngine

2012-08-10T16:43:00.003-03:00

Nesse post irei falar um pouco sobre o parâmetro SecRuleEngine:

Esse parâmetro, definido no arquivo modsecurity.conf (copiado de modsecurity.conf-recommended do código fonte do ModSecurity), define se as regras estão ativadas, desativadas, ou atuando no modo de somente detecção. Conforme a Wiki do ModSecurity:

SecRuleEngine

Descrição: Configura o mecanismo das regras.
Sintaxe: SecRuleEngine On|Off|DetectionOnly
Exemplo de uso: SecRuleEngine On
Escopo: Qualquer
Versão: 2.0.0
Padrão: Off

Os valores possíveis são:
On: processa as regras
Off: não processa as regras
DetectionOnly: processa as regras mas nunca executa nenhuma ação de bloqueio (block, deny, drop, allow, proxy and redirect)

No modsecurity.conf-recommended incluído no código fonte do ModSecurity e normalmente utilizado como base, esse parâmetro vem como DetectionOnly por padrão.

Um exemplo simples e prático: no post anterior, Instalando o ModSecurity 2.6.7 + CRS 2.2.5 no Debian Wheezy, o ModSecurity está instalado no Apache, mas como não foi alterada a sua configuração, o parâmetro SecRuleEngine está configurado como somente como deteção e não realizará nenhum tipo de bloqueio.

- Vamos criar um arquivo chamado test.cfg e publicar ele no Apache previamente instalado com o ModSecurity:

echo "TEST" > /var/www/test.cfg

- Acesse em um browser esse arquivo, e você poderá visualizar o seu conteúdo:

Isso não é bom, se você tiver alguma informação confidencial como credenciais de acesso ao banco de dados dentro desse arquivo, por exemplo...

Apesar de não ter sido bloqueado o acesso, o ModSecurity estava configurado no modo de detecção e registrou um alerta (warning) no log de erros do Apache:

[Fri Aug 10 13:24:19 2012] [error] [client X.X.X.X] ModSecurity: Warning. 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 "/etc/apache2/modsecurity/crs/activated_rules/modsecurity_crs_30_http_policy.conf"] [line "88"] [id "960035"] [msg "URL file extension is restricted by policy"] [data ".cfg"] [severity "CRITICAL"] [tag "POLICY/EXT_RESTRICTED"] [tag "WASCTC/WASC-15"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [hostname "test.domain.com"] [uri "/test.cfg"] [unique_id "UCU1s38AAQEAAFLrARoAAABA"]

Interpretando o log de erro acima, a regra com o ID 960035, que está na linha 88 do arquivo /etc/apache2/modsecurity/crs/activated_rules/modsecurity_crs_30_http_policy.conf, identificou que um arquivo com uma extensão não permitida foi acessado. Abaixo a regra que deu match:

SecRule REQUEST_BASENAME "\.(.*)$" "chain,capture,setvar:tx.extension=.%{tx.1}/,phase:2,t:none,t:urlDecodeUni,t:lowercase,block,msg:'URL file extension is restricted by policy', severity:'2',id:'960035',tag:'POLICY/EXT_RESTRICTED',tag:'WASCTC/WASC-15',tag:'OWASP_TOP_10/A7',tag:'PCI/6.5.10',logdata:'%{TX.0}'"
SecRule TX:EXTENSION "@within %{tx.restricted_extensions}" "t:none,setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.warning_anomaly_score},setvar:tx.policy_score=+%{tx.warning_anomaly_score},setvar:tx.%{rule.id}-POLICY/EXT_RESTRICTED-%{matched_var_name}=%{matched_var}"

Na verdade, se você for ver a regra 960035, verá que as extensões bloqueadas estão definidas na variável "tx.restricted_extensions", que está definido no arquivo modsecurity_crs_10_setup.conf da CRS. Caso desejar adicionar ou remover alguma extensão bloqueada, é nessa variável que isso deve ser feito, e não na regra.

A Core Rule Set também traz bastante documentação sobre cada regra, como a utilizada nesse exemplo: ela aponta para referências à:
- WASCTC/WASC-15: Application Misconfiguration
- OWASP_TOP_10/A7: Insecure Cryptographic Storage
- PCI/6.5.10: Insecure configuration management

Ok, então agora vamos então bloquear esse tipo de evento.Habilite o modo de bloqueio no ModSecurity:

SecRuleEngine On

Reinicie o Apache, e agora tente acessar o mesmo arquivo através do browser:

Mesmo o arquivo existindo no servidor web, o bloqueio foi realizado. O log do Apache registra o bloqueio:

Fri Aug 10 13:43:30 2012] [error] [client X.X.X.X] 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 "/etc/apache2/modsecurity/crs/activated_rules/modsecurity_crs_30_http_policy.conf"] [line "88"] [id "960035"] [msg "URL file extension is restricted by policy"] [data ".cfg"] [severity "CRITICAL"] [tag "POLICY/EXT_RESTRICTED"] [tag "WASCTC/WASC-15"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [hostname "test.domain.com"] [uri "/test.cfg"] [unique_id "UCU6Mn8AAQEAAFSeASsAAAAA"]

Esse é um exemplo de uma regra simples, mas é fácil de entender como funciona e como interpretar esses logs, o que dará base para interpretar posteriormente regras mais complexas. Até o próximo post!

ModSecurity Series 2 - Instalando o ModSecurity 2.6.7 + CRS 2.2.5 no Debian Wheezy

2012-08-10T14:20:00.001-03:00

Como não consegui postar na semana passada, essa semana terá 2 posts sobre o ModSecurity. Esse será sobre a instalação do ModSecurity 2.6.7 + o Core Rule Set 2.2.5 no Debian Wheezy (atualmente testing). A versão antiga desse post, voltado para o CentOS, está aqui: Installing ModSecurity 2.6.1-rc1 + CRS (Core Rule Set) 2.2.0 on CentOS 5.6

- Instalar as dependências:

apt-get install build-essential apache2-threaded-dev apache2 libpcre3-dev libpcre3 libxml2 libxml2-dev lua5.1 liblua5.1-dev libcurl3-dev

- Realizar o download do código fonte do ModSecurity:

cd /usr/local/src
wget http://www.modsecurity.org/download/modsecurity-apache_2.6.7.tar.gz
wget "http://downloads.sourceforge.net/project/mod-security/modsecurity-apache/2.6.7/modsecurity-apache_2.6.7.tar.gz.asc"

- Baixar o Core Rule Set:

wget "http://downloads.sourceforge.net/project/mod-security/modsecurity-crs/0-CURRENT/modsecurity-crs_2.2.5.zip"
wget "http://downloads.sourceforge.net/project/mod-security/modsecurity-crs/0-CURRENT/modsecurity-crs_2.2.5.zip.sig"

- Importar as chaves de assinatura em seu arquivo de chaves PGP:

# gpg --recv-keys 9624FCD2
gpg: porta-chaves `/root/.gnupg/secring.gpg' criado
gpg: requesting key 9624FCD2 from hkp server keys.gnupg.net
gpg: /root/.gnupg/trustdb.gpg: banco de dados de confiabilidade criado
gpg: key 9624FCD2: public key "Ryan Barnett (OWASP Core Rule Set Project Leader) " imported
gpg: Número total processado: 1
gpg: importados: 1 (RSA: 1)

# gpg --recv-keys 6980F8B0
gpg: requesting key 6980F8B0 from hkp server keys.gnupg.net
gpg: key 6980F8B0: public key "Breno Silva Pinto " imported
gpg: Número total processado: 1
gpg: importados: 1 (RSA: 1)

- Verificar a integridade dos arquivos:

# gpg --verify modsecurity-apache_2.6.7.tar.gz.asc
gpg: Signature made Qui 02 Ago 2012 19:49:04 BRT using RSA key ID 6980F8B0
gpg: Good signature from "Breno Silva Pinto "
gpg: AVISO: Esta chave não está certificada com uma assinatura confiável!
gpg: Não há indicação de que a assinatura pertence ao dono.
Impressão da chave primária: AB36 0F15 ACF8 D30F 806E 41D2 8050 C35A 6980 F8B0

# gpg --verify modsecurity-crs_2.2.5.zip.sig
gpg: Signature made Qui 14 Jun 2012 13:48:52 BRT using RSA key ID 9624FCD2
gpg: Good signature from "Ryan Barnett (OWASP Core Rule Set Project Leader) "
gpg: AVISO: Esta chave não está certificada com uma assinatura confiável!
gpg: Não há indicação de que a assinatura pertence ao dono.
Impressão da chave primária: D5B2 7FC9 BFD2 5BDD 57DB 7291 C976 607D 9624 FCD2

- Descompactar:

tar xvfz modsecurity-apache_2.6.7.tar.gz
unzip -x modsecurity-crs_2.2.5.zip

- Compilar o módulo do apache:

cd modsecurity-apache_2.6.7/
./configure
make
make install
# O módulo é instalado em /usr/lib/apache2/modules/mod_security2.so e ferramentas em /usr/local/modsecurity/bin

- Instalar a estrutura de regras do CRS:

mkdir -p /etc/apache2/modsecurity/crs
touch /etc/apache2/modsecurity/whitelist.conf
cp /usr/local/src/modsecurity-apache_2.6.7/modsecurity.conf-recommended /etc/apache2/modsecurity/modsecurity.conf
cp -a /usr/local/src/modsecurity-crs_2.2.5/* /etc/apache2/modsecurity/crs

cd /etc/apache2/modsecurity/crs
cp modsecurity_crs_10_setup.conf.example modsecurity_crs_10_setup.conf
for f in `ls base_rules/` ; do ln -s ../base_rules/$f activated_rules/$f ; done
for f in `ls experimental_rules/` ; do ln -s ../experimental_rules/$f activated_rules/$f ; done

# Se forem habilitadas as "experimental rules, alguns arquivos precisam ser configurados e personalizados: modsecurity_crs_11_proxy_abuse.conf, modsecurity_crs_16_scanner_integration.conf,modsecurity_crs_40_appsensor_detection_point_2.1_request_exception.conf, modsecurity_crs_42_csp_enforcement.conf, modsecurity_crs_55_response_profiling.conf, modsecurity_crs_56_pvi_checks.conf, modsecurity_crs_61_ip_forensics.conf

- Habilitar o mod_unique_id no apache:

# a2enmod unique_id

- Criar o arquivo /etc/apache2/mods-available/modsecurity.load com o seguinte conteúdo :

LoadFile /usr/lib/x86_64-linux-gnu/libxml2.so
LoadFile /usr/lib/x86_64-linux-gnu/liblua5.1.so
LoadModule security2_module /usr/lib/apache2/modules/mod_security2.so

- Criar o arquivo /etc/apache2/mods-available/modsecurity.conf com o seguinte conteúdo:

<IfModule security2_module>
Include modsecurity/modsecurity.conf
Include modsecurity/whitelist.conf
Include modsecurity/crs/modsecurity_crs_10_setup.conf
Include modsecurity/crs/activated_rules/*.conf
</IfModule>

- Habilitar o módulo modsecurity no apache:

# a2enmod modsecurity

- Testar a configuração:

# apache2ctl -t
Syntax OK

- Se tudo estiver ok, basta reiniciar o apache.No log do apache irá aparecer o seguinte:

[Fri Aug 10 14:02:44 2012] [notice] ModSecurity for Apache/2.6.7 (http://www.modsecurity.org/) configured.
[Fri Aug 10 14:02:44 2012] [notice] ModSecurity: APR compiled version="1.4.6"; loaded version="1.4.6"
[Fri Aug 10 14:02:44 2012] [notice] ModSecurity: PCRE compiled version="8.30 "; loaded version="8.30 2012-02-04"
[Fri Aug 10 14:02:44 2012] [notice] ModSecurity: LUA compiled version="Lua 5.1"
[Fri Aug 10 14:02:44 2012] [notice] ModSecurity: LIBXML compiled version="2.8.0"
[Fri Aug 10 14:02:45 2012] [notice] Apache/2.2.22 (Debian) configured -- resuming normal operations

O ModSecurity está instalado por padrão no modo de detecção, o que será explicado no próximo post. Até lá.

ModSecurity Series - Parte 1

2012-07-27T15:29:00.001-03:00

Click here to see this post in english:

Resolvi "copiar" a Série Snortando do meu amigo Rodrigo "Sp0oKeR" Montoro, e até mesmo por sugestão dele, e criar uma série de posts sobre o ModSecurity.

A idéia desses posts não é de ser um guia passo a passo ou um manual do ModSecurity, e sim o meu dia a dia de configurações e resoluções de problemas na sua utilização. Acredito que isso será muito útil para os demais, e até para mim, que estarei documentando alguns procedimentos que depois possa vir a esquecer. ;-)

Pretendo postar sempre uma versão em português e uma em inglês da mesma postagem, e a frequência de postagens será semanal. Você também pode usar os comentários para sugerir tópicos a serem abordados nas próximas postagens, com o os problemas que você enfrenta.

Inicio essa série falando um pouco sobre ModSecurity e WAF (Web Application Firewalls), se você desejar uma introdução sobre o que é WAF, pode ver a apresentação que fiz em março de 2011 no Primeiro Encontro OWASP Porto Alegre, que está disponível aqui:

Introducão a Web Applications Firewalls from Jeronimo Zucco

Uma excelente apresentação que aborda alguns conceitos de WAF foi feita pela Carolina Bozza na BHack Conference, e está disponível aqui: http://www.bhack.com.br/talks/Carolina/BHACK.pdf

Caso você ainda não tenha instalado o ModSecurity, eu criei uma postagem (que já está desatualizada, talvez eu venha atualizá-la aqui nessa série futuramente) de como instalar o ModSecurity 2.6.1-rc1 + CRS (Core Rule Set) 2.2.0

Atualmente, o ModSecurity está na versão 2.6.7 (stable), e o arquivo de regras CRS (Core Rule Set) está na versão 2.2.5.

Foi anunciado também que o ModSecurity foi portado para o IIS. Em breve também será portado para o Nginx, conforme anúncio da empresa Trustwave, através do seu time da SpiderLabs.

Aliás, a Trustwave atualmente é a empresa mantenedora do ModSecurity, onde Ryan Barnett e o brasileiro Breno Silva são os principais desenvolvedores do projeto.

A Trustwave, entre outros serviços na área de segurança, presta serviços de suporte e criação de um conjunto de regras comerciais que não são distribuídas no CRS para serem utilizadas no ModSecurity em seus clientes. Mais detalhes sobre os serviços prestados pela Trustwave com o ModSecurity pode ser visto aqui: Trustwave ModSecurity Rules and Support Services

Documentação do ModSecurity:

Existe muita documentação disponível na internet sobre o ModSecurity, em quase sua totalidade em inglês. Porém o projeto evoluiu muito nos últimos anos, e algumas vezes a documentação encontrada na internet é desatualizada e já não pode ser utilizada. Por isso existem algumas referências que eu recomendo:

- Documentação oficial do projeto, direto do repositório de versões: o repositório SVN do projeto possui uma área de documentação, e se uma nova funcionalidade for adicionada ou alterada, ela será primeiramente documentada ali. Mais atualizada que isso, impossível: http://mod-security.svn.sourceforge.net/viewvc/mod-security/m2/trunk/doc/. Esse manual de referência depois é disponibilizado no Wiki oficial do projeto

- Handbook do Ivan Ristik, que foi o autor do ModSecurity mas que não é mais desenvolvedor no projeto. Esse livro é muito bom principalmente porque o Ivan disponibiliza sua atualização constantemente, portanto ele não fica desatualizado. Vale muito a pena comprar esse livro se você deseja utilizar o ModSecurity, principalmente por essa política de atualização e distribuição digital.

- Listas de discussão Mod-security-users e Owasp-modsecurity-core-rule-set.

Essa postagem já ficou longa, e a intenção dessa série é que seja apenas postagens curtas. Então até a próxima! :-)

ModSecurity Series - Part 1 - english

2012-07-27T15:29:00.000-03:00

Clique aqui para ver esse post em português

I decided to copy the Série Snortando of my friend Rodrigo "Sp0oKeR" Montoro, and even at his suggestion, create a series of posts about ModSecurity.

The idea of these posts is not to be a step by step guide or a ModSecurity manual, but write about my day-by-day work in settings and resolutions of problems in its use. I think it will be useful for others, and even for me, I'll be documenting some procedures that might later forget. ;-)

I always intend to post a version in Portuguese and one in English of the same post, and the frequency of the posts will be weekly. You can also use the comments to suggest topics to be addressed in future posts, with your issues.

I start this series talking a little about ModSecurity and WAF (Web Application Firewalls), if you want an introduction about WAF, you can see the presentation I made in March 2011 in OWASP Porto Alegre First Meeting, which is available here (portuguese):

Introducão a Web Applications Firewalls from Jeronimo Zucco

An excellent presentation that covers some WAF concepts was made by Carolina Bozza in Hack Conference, and is available here:http://www.bhack.com.br/talks/Carolina/BHACK.pdf.

If you have not installed yet ModSecurity, I've created a post (which is already outdated, maybe I will update it here in this series in the future) on how to install ModSecurity 2.6.1-rc1 + CRS (Core Rule Set) 2.2.0.

Currently, ModSecurity version is 2.6.7 (stable), and CRS rules file (Core Rule Set) is at version 2.2.5.

It was also announced that the ModSecurity has been ported to IIS. It will be soon ported to Nginx as the Trustwave announcement through its SpiderLabs team.

In fact, Trustwave is currently the company maintains the ModSecurity, where Ryan Barnett and brazilian Breno Silva are the main developers of the project.

Trustwave, among other services in the area of security, provides support services and have a set of trade rules that are not distributed in the CRS for use in ModSecurity on their customers. More information about the services provided by Trustwave with ModSecurity can be seen here: Trustwave ModSecurity Rules and Support Services.

ModSecurity Documentation:

There are a lot of documentation available in internet about ModSecurity, almost entirely in English. But the project has considerably changed in recent years, and sometimes the documentation found in Internet is outdated and can no longer be used. So here are some references that I recommend:

- Official documentation of the project, straight from the version repository: SVN repository of the project have a documentation area, and whether a new functionality is added or changed, it will first be documented there. More updated is impossible: http://mod-security.svn.sourceforge.net/viewvc/mod-security/m2/trunk/doc/. This reference manual is available after in the official project Wiki.

- Handbook of Ivan Ristik, who was the ModSecurity author, but that is no longer developer of the project. This book is very good mainly because Ivan provides its update constantly, so it does not get outdated. It is worthwhile to buy this book if you want to use ModSecurity, mainly because this policy of updating and digital distribution.

- Mod-security-users e Owasp-modsecurity-core-rule-set mailing lists.

This post has been long, and the intention is that this series is just short posts. See you later! :-)

Encontro OWASP em Caxias do Sul dia 20/06 na UCS

2012-05-25T10:36:00.001-03:00

Third Annual Week of OSSEC

2011-10-26T13:30:00.005-02:00

O blog Immutable Security realiza a cada ano a "Semana do OSSEC. Esse é o terceiro ano, é interessante ler os posts dos demais anos: aqui e aqui.

Eu prestei um mini-curso de um dia sobre o OSSEC no GTS-16. A apresentação pode ser vista abaixo. Segue os links para download dos vídeos do mini-curso:

Vídeo parte 1 - Vídeo parte 2 - Vídeo parte 3

Implementing ossec

View more presentations from jczucco

OWASP AppSec Latin America 2011

2011-09-27T16:46:00.001-03:00

Programação da OWASP AppSec Latin América 2011

2011-09-04T22:06:00.004-03:00

OWASP AppSec Latin América 2011 - Inscrições Abertas

2011-08-30T14:41:00.002-03:00

Inscrições abertas para a OWASP AppSec Latin América 2011. Confira os valores e os treinamentos em http://t.co/2lancJi

Installing ModSecurity 2.6.1-rc1 + CRS (Core Rule Set) 2.2.0

2011-07-15T12:59:00.008-03:00

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.

Usando 2 fatores de autenticação no Google

2011-06-03T09:18:00.003-03:00

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.

Hardening de Sistemas Operacionais e Serviços

2011-04-24T21:31:00.005-03:00

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á!

Segurança Física e Proteção de Dados em um Datacenter do Google

2011-04-22T23:24:00.002-03:00

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:

Pesquisa sobre Treinamentos para a AppSec Latin America 2011

2011-04-16T14:20:00.004-03:00

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.

Introducão a Web Applications Firewalls

2011-04-05T23:05:00.001-03:00

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.

Primeiro encontro do Capítulo OWASP Porto Alegre

2011-03-11T15:38:00.002-03:00

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.

Guia de configuração segura para o Mac OS X 10.6 Snow Leopard

2011-03-01T13:50:00.005-03:00

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!

OWASP Appsec Tutorial Series - Episode 2: Injection Attacks

2011-02-10T10:50:00.000-02:00

http://www.youtube.com/watch?v=Ci_YtwOn150