Pesquisar neste blog

Mostrando postagens com marcador Apache. Mostrar todas as postagens
Mostrando postagens com marcador Apache. Mostrar todas as postagens

terça-feira, 17 de abril de 2012

ModSecurity: Open Source Web Application Firewall - Segurança no Apache

ModSecurity Instalação e Configuração


O ModSecurity é um firewall de aplicação de código livre que roda como um módulo do servidor Web Apache e possui versões para Linux e Windows. O firewall de aplicação, também conhecido como WAF (Web Application Firewall) tem por objetivo bloquear diversos tipos de ataques, como o Cross-Site Scripting (XSS), SQL Injection, Command Injection, ASP e PHP Injection, Trojans & Backdoors Detection, dentre outros, que variam de acordo com as regras existentes.

Apesar do conjunto de regras pre-existentes no ModSecurity ser funcional, a OWASP mantém um projeto que possui um conjunto de regras mais elaboradas e atualizadas, o ModSecurity Core Rule Set Project. Também é possível fazer o download de outras regras na Internet, sites de segurança ou ainda criar suas próprias regras e alterar as já existentes.

Nesse tutorial será descrito como efetuar uma completa instalação da versão 2.5.12 do Modsecurity de modo que não haja erros durante a instalação.

Para instalar o ModSecurity, você deve ter o Apache instalado. Se não tiver, você deve instalá-lo, conforme a seguir:

# sudo apt-get –f install apache2

É importante configurar a opção -f no apt-get para o aplicativo já procurar e tentar instalar as possíveis dependências do Apache2. Depois verifique se o Apache está rodando corretamente com o comando:

# /etc/init.d/apache2 status

E inicie o serviço, caso não esteja rodando:

# /etc/init.d/apache2 start

Agora, vamos criar uma página php vulnerável para podermos testar o comportamento da aplicação antes e o depois do ModSecurity.

# vi /var/www/index.php



Para salvar e sair do vi: (ESC : x)

Agora, faça a requisição para a página criada usando seu navegado, curl ou links, com a seguinte sintaxe:

http://localhost/index.php?secret_file=/etc/passwd


Observe que ao invés de mostrar o conteúdo da página, a requisição traz o conteúdo do arquivo de senhas (passwd), isso porque no arquivo que criamos inserimos propositalmente uma vulnerabilidade que permite apontar para qualquer arquivo do sistema operacional por meio da variável “secret_file”.

Agora, vamos partir para a instalação do ModSecurity para ver se a mesma vulnerabilidade poderá ser explorada com o Firewall de aplicação instalado:


Instalação do ModSecurity

Agora que temos o Apache rodando, vamos fazer o download do ModSecurity.

# wget http://www.modsecurity.org/download/modsecurity-apache_2.5.12.tar.gz

Descompacte o arquivo e entre no diretório criado:

# tar zxvf modsecurity-apache_2.5.12.tar.gz

# cd modsecurity-apache_2.5.12/apache2

ATENÇÃO: Essa parte é muito importante, pois o ModSecurity necessita de uma ferramenta, o apxs ou apxs2 (APache eXtension Tool) para sua perfeita instalação. Antes de prosseguir, verifique se ele existe:

# find / -name apxs*

Se já existir ótimo, já é possível começar a instalar o ModSecurity. Caso não exista, teremos que instalar alguns pacotes que trazem o apxs:

# sudo apt-get -f install libxml2-dev liblua5.1-0 lua5.1 apache2-threaded-dev

Agora já podemos instalar o ModSecurity!

# sudo ./configure && make && make install

Após a instalação, deverá aparecer a seguinte mensagem:

See any operating system documentation about shared libraries for

more information, such as the ld(1) and ld.so(8) manual pages.

----------------------------------------------------------------------

Altere a permissão do arquivo abaixo e reinicie o sistema.

# chmod 644 /usr/lib/apache2/modules/mod_security2.so

Quando o sistema subir, iremos alterar o arquivo de configuração de módulos do Apache para carregar os módulos do ModSecurity:

# sudo vi /etc/apache2/mods-available/mod-security2.load

E adicionamos as seguintes linhas:

LoadFile /usr/lib/libxml2.so

LoadFile /usr/lib/liblua5.1.so.0

LoadModule security2_module /usr/lib/apache2/modules/mod_security2.so

Salve e feche o arquivo.

Agora, vamos ativar os módulos adicionados:

# sudo a2enmod mod-security2

# sudo a2enmod unique_id

Deve aparecer a seguinte mensagem para ambos os comandos, mas ainda não há necessidade de reiniciar o serviço.

Run '/etc/init.d/apache2 restart' to activate new configuration!


Configuração

Vamos configurar o ModSecurity:

# sudo vi /etc/apache2/conf.d/mod-security2.conf

# Include /etc/modsecurity2/*.conf

Salve e feche o arquivo.

Vamos criar um diretório para o ModSecurity e copiar as regras de detecção para o diretório criado:

# sudo mkdir /etc/modsecurity2

# sudo cp modsecurity-apache_2.5.12/rules/*.conf /etc/modsecurity2/

# sudo cp rules/base_rules/*.conf /etc/modsecurity2/

Precisamos criar também o diretório e arquivos de log e debug:

# mkdir /var/log/modsecurity2

# touch /var/log/modsecurity2/modsec_audit.log

# touch /var/log/modsecurity2/modsec_debug.log

E atualizar a localização desses arquivos no arquivo de configuração:

#sudo vi /etc/modsecurity2/modsecurity_crs_10_config.conf

Adicione o seguinte script no meio do arquivo.

#++++ Configure ModSecurity +++++

SecDebugLog /var/log/modsecurity2/modsec_debug.log

SecAuditLog /var/log/modsecurity2/modsec_audit.log

Salve e feche o arquivo.

Agora, vamos verificar se a configuração do Apache está correta com o comando:

# sudo apache2ctl configtest

Deverá retornar a mensagem “Syntax OK”

E, por último, vamos reiniciar o Apache:

# sudo /etc/init.d/apache2 restart

Verifique se o ModSecurity está rodando junto com o Apache:

# sudo cat /var/log/apache2/error.log | grep ModSecurity

Pronto! Se aparecer a mensagem abaixo seu ModSecurity está rodando!

[Mon Apr 26 08:47:07 2010] [notice] ModSecurity for Apache/2.5.12 (http://www.modsecurity.org/) configured

Agora, vamos realizar o teste novamente para ver se conseguimos explorar a vulnerabilidade testada anteriormente.



Como podemos observar pela mensagem retornada “403 Forbidden – You don’t have permission to Access /índex.php on this server”, o ModSecurity bloqueou o acesso ao arquivo índex.php, uma vez que por trás dele havia uma função maliciosa (ler o arquivo de senhas “passwd”).

Este é só um exemplo de como um firewall de aplicação pode ajudar a “tapar buracos” de uma aplicação mal desenvolvida, enquanto se providencia um código seguro, com os devidos controles de segurança e livre de vulnerabilidades.

Isso é tudo pessoal, até a próxima!


quinta-feira, 29 de abril de 2010

Criando uma autenticação para a página do MSN-PROXY

Olá pessoal, algumas amigos me perguntaram sobre como colocar uma autenticação na página do msn-proxy, que no caso é um método de segurança a um conteúdo muito restrito e não pode cair em mãos erradas, ainda mais se a empresa não deixa ciente seus funcionários que eles estejam sendo monitorados, isso pode levar a empresa a um grande processo por invasão de privacidade.


Bom, para ativar esse recurso no apache devemos seguir alguns passos como demonstrados abaixo:


Nota: esses passos são para quem usa centOS e apache httpd.


 1)  Editar o arquivo do apache

# vim /etc/httpd/conf/httpd.conf

encontre no arquivo o parametro "AllowOverride none" e altere o parâmetro para: "AllowOverride AuthConfig"

Essa diretiva no apache permite você usar autenticação por meio do arquivo .htaccess.

Nota: Desconsidere o "\" nas diretivas abaixo, coloquei isso proque o blogspot estava identificando como uma tag html e não esta exibindo.

Antes:

<\Directory />
Options FllowSymLinks
AllowOverride none
<\/Directory>



Depois

<\Directory />
Options FllowSymLinks
AllowOverride AuthConfig
<\/Directory>

2) Agora feche o arquivo e saia, vamos ao próximo passo que é criar o arquivo .htaccess, esse arquivo deve ser criado dentro da pasta /var/www/html/msn-proxy, ou no diretório que queira restringir o acesso.

Agora vamos editá-lo:
# vim /var/www/html/msn-proxy/.htaccess

Adicione o seguinte conteúdo neste arquivo:

AuthType Basic
AuthName "Msn-Proxy"
AuthUserFile /var/www/html/msn-proxy/usuarios.txt
Require valid-user

Salve e feche o arquivo.

3) Feito isso agora vamos criar um usuário que poderá se autenticar para acessar a página do msn-proxy usando o seguinte comando abaixo:

# htpasswd -c /var/www/html/msn-proxy/usuarios.txt login_do_usuario

Logo será solicitado uma senha, e repita a mesma e pronto, agora é só reiniciar o apache e testar a autenticação tentando abrir a página do msn-proxy.

Abraço.

quinta-feira, 21 de janeiro de 2010

Autenticação mod_authnz_ldap com Apache 2.2

Olá pessoal,
aqui segue uma informação e uma dica de configuração. Para quem usava o apache 2.0 a autenticação ldap era referenciada da seguinte maneira como mostrado abaixo:

AuthName "Acesso Restrito "
AuthType Basic
AuthLDAPEnabled on
AuthLDAPURL ldap://ldapserver.dominio.net:389/ou=usuarios,dc=ipaimec,dc=net??base?(objectClass=*)
require valid-user

Com a versão 2.2 do apache, algumas alterações foram feitas no módulo mod_authnz_ldap e podemos fazer a autenticação usando os seguintes parâmetros:

AuthName "Acesso Restrito "
AuthType Basic
AuthLDAPURL ldap://ldapserver.dominio.net:389/ou=usuarios,dc=ipaimec,dc=net??base?(objectClass=*)
AuthBasicProvider ldap
AuthzLDAPAuthoritative off
require valid-user

quinta-feira, 30 de outubro de 2008

Prevenindo Ataques web com Apache - (Preventing Web Attacks with Apache)

Distro: CentOS 4.6
Apache: httpd 2.0.52
Módulo usado mod_proxy

Essa semana me deparei com uma série de acessos estranhos quando analisava os logs do cluster de servidores web. Porque ou que um tipo de conexão "CONNECT login.icq.com:443 HTTP/1.0" estaria sendo logada nos servidores web? Então fui-me a pesquisar na internet e me deparei com uma vulnerabilidade.

Alguém estava explorando uma vulnerabilidade dos servidores web, mais especificamente no módulo mod_proxy usado para habilitar um recurso de proxy reverso que permite que você conecte-se a outros servidores internos da sua rede usando um único endereço.


Abaixo vou mostrar como evitar isso e alguns exemplos (Antes e Depois)

Testar se as conexões estão sendo aceitas pelo proxy-reverso

[root@vmware01 scripts]# nc www.meuserverweb.com.br 80
CONNECT login.icq.com:443 HTTP/1.0
Host:login.icq.com:443

HTTP/1.0 200 Connection Established
Proxy-agent: Apache/2.0.52 (CentOS)
*}E
[root@vmware01 scripts]#

Se der a mensagem acima você está vulnerável, podem estar usando seu servidor web como
servidor proxy para navegar em outros sites, enviar spams, etc...


Configuração do apache antes


ProxyRequests On
ProxyPass /site1 http://10.1.2.1/site1
ProxyPass /site2 http://10.1.2.1/site2
ProxyPassReverse /site1 http://10.1.2.1/site1
ProxyPassReverse /site2 http://10.1.2.1/site2
ProxyVia On


Logs do apache antes

96.229.41.9 - - [28/Oct/2008:13:44:22 -0200] "CONNECT login.icq.com:443 HTTP/1.0" 200 - "-" "-"
96.229.41.9 - - [28/Oct/2008:13:44:22 -0200] "CONNECT login.icq.com:443 HTTP/1.0" 200 - "-" "-"
96.229.41.9 - - [28/Oct/2008:13:44:43 -0200] "CONNECT login.icq.com:443 HTTP/1.0" 200 - "-" "-"
96.229.41.9 - - [28/Oct/2008:13:44:43 -0200] "CONNECT login.icq.com:443 HTTP/1.0" 200 - "-" "-"
96.229.41.9 - - [28/Oct/2008:13:44:50 -0200] "CONNECT login.icq.com:443 HTTP/1.0" 200 - "-" "-"
96.229.41.9 - - [28/Oct/2008:13:45:03 -0200] "CONNECT login.icq.com:443 HTTP/1.0" 200 - "-" "-"
96.229.41.9 - - [28/Oct/2008:13:45:17 -0200] "CONNECT login.icq.com:443 HTTP/1.0" 200 - "-" "-"



Configuração do apache depois

Altere o parametro ProxyRequests para Off evitando o uso pelos spammers


ProxyRequests Off
ProxyPass /site1 http://10.1.2.1/site1
ProxyPass /site2 http://10.1.2.1/site2
ProxyPassReverse /site1 http://10.1.2.1/site1
ProxyPassReverse /site2 http://10.1.2.1/site2
ProxyVia Off


Logs do Apache depois

96.229.41.9 - - [30/Oct/2008:06:20:22 -0200] "CONNECT login.icq.com:443 HTTP/1.0" 302 - "-" "-"
96.229.41.9 - - [30/Oct/2008:06:20:22 -0200] "CONNECT login.icq.com:443 HTTP/1.0" 302 - "-" "-"
96.229.41.9 - - [30/Oct/2008:06:20:28 -0200] "CONNECT login.icq.com:443 HTTP/1.0" 302 - "-" "-"
96.229.41.9 - - [30/Oct/2008:06:20:28 -0200] "CONNECT login.icq.com:443 HTTP/1.0" 302 - "-" "-"




Teste do acesso depois

[root@vmware01 scripts]# nc www.meuserverweb.com.br 80
CONNECT login.icq.com:443 HTTP/1.1
Host:login.icq.com:443

HTTP/1.1 302 Found
Date: Thu, 30 Oct 2008 07:53:30 GMT
Server: Apache/2.0.52 (CentOS)
X-Powered-By: PHP/4.4.7
Set-Cookie: PHPSESSID=
f77b4da01d008ef668e4102a504d1300; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
location: http://www.meuserverweb.com.br/
Content-Length: 0
Connection: close
Content-Type: text/html; charset=iso-8859-1

[root@vmware01 scripts]#

Conexão fechada

consulte os livros on-line de segurança

Fonte: http://my.safaribooksonline.com/0321321286/ch10lev1sec15

Comandos usados para filtrar e obter estatísticas top 10
>>Top Ten Attacker IP Addresses
# cat access_log | awk '{print $7}' | sort | uniq -c | sort -rn | head –10

# cat access_log | awk '{print $1}' | sort | uniq -c | sort -rn | head –10

Extraindo os ips

# for f in `cat access_log | awk '{print $1}' | sort | uniq -c | sort -rn | head -10 |
awk '{print $2}'`; do grep $f access_log | head –1 ; done


Serviços para checagem de proxy

http://www.google.com/search?hl=en&ie=UTF-8&oe=UTF-8&q=proxy+check
http://www.checker.freeproxy.ru/checker/
http://www.ip-adress.com/Proxy_Checker/


Observações
Module Name Description Security RiskRecommend
Mod_proxyThis module turns the apache web server into a web proxy server.Care should be taken with the configuration of proxy servers, as if the intent is to facilitate internal organization access to external web sites, there is a risk that the reverse could be enabled, allowing Internet users to potentially browse internal web servers.If this server is a normal web server, then this module is not required for the normal operation and it should be disabled. If this server is being used as a proxy or a reverse proxy, then this module must be enabled.





Algumas informações sobre o módulo
http://httpd.apache.org/docs/2.0/mod/mod_proxy.html
Descubra a localização de quem está realizando um ataque:
http://www.maxmind.com/