Ir para o conteúdo
ou

Software livre Brasil

Tela cheia
 Feed RSS

Alexos Core Labs

27 de Maio de 2009, 0:00 , por Software Livre Brasil - | Ninguém está seguindo este artigo ainda.
Licenciado sob GNU FDL

Habilitando o HSTS no Apache e Nginx

26 de Novembro de 2012, 0:00, por Software Livre Brasil - 0sem comentários ainda

O HTTP Strict Transport Security ou HSTS (RFC 6797) é um novo padrão de segurança SSL aprovado recentemente pelo IETF. Ele traz diversas melhorias para o SSL como forçar a utilização do HTTPS impedindo que sites sejam acessados usando o protocolo HTTP ou que partes do código de um site que está usando HTTPS seja executado em servidores usando o HTTP entre outras.

Este protocolo já é utilizado pelo Google,Paypal,Twitter e outros sites, porém necessita da adoção em massa para se tornar um padrão de fato. Ativá-lo é muito simples e ele substitui a utilização do redirecionamento forçado do HTTP para HTTPS.

No Apache

Adicione o seguinte parâmetro no VHOST do site

Header add Strict-Transport-Security “max-age=15768000″

ou

Strict-Transport-Security: max-age=15768000 ; includeSubDomains

O parâmetro max-age define para o navegador o período de validade em segundos que o HTTPS será forçado, nesse caso serão 6 meses.
O parâmetro includeSubDomains indica que esta regra valerá para os subdominios.

No Nginx

Adicione o seguinte parâmetro no arquivo de configuração do Nginx

add_header Strict-Transport-Security max-age=15768000;

Referências

Owasp HTTP Strict Transport Security

Novo padrão promete aumentar proteção de sites seguros

Firefox 4: HTTP Strict Transport Security (force HTTPS)

Protecting your users from phishing with Apache rules and HSTS



Servidores Linux com Nginx são alvos de rootkit

21 de Novembro de 2012, 0:00, por Software Livre Brasil - 0sem comentários ainda

Semana passada ( 13/nov ) foi divulgado na lista Full-disclosure um novo rootkit que tem como alvos servidores Linux usando o webserver Nginx.

Segundo stack trace, vítima do ataque, o malware adiciona um iFrame malicioso na resposta HTTP enviada pelo servidor web. Após o comprometimento o servidor passa a encaminhar as requisições para outros sites maliciosos, além disso um Blackhole varre o host do visitante a procura de falhas no Java, Flash entre outras aplicações rodando na máquina cliente.

Foi descoberto até o momento um módulo especifico para o kernel 2.6.32-5-amd64, presente no Debian Linux. Pesquisadores da Karpersky Labs nomearam o malware como Rootkit.Linux.Snakso.a, outra análise bastante interessante é do pesquisador Georg Wicherski da CrowdStrike, ele considerou o rootkit como parte da operação do cybercrime e que pelas técnicas adotadas foi desenvolvido por programador russo sem muito conhecimento do kernel.

Medidas Preventivas:

Realmente não existe mágica na proteção contra novos malwares porém posso sugerir algumas recomendações básicas:

- Manter uma rotina de varredura de antivirus mesmo em servidores Linux;
- Utilizar um IDS ou um WAF e monitorá-lo diariariamente;
- Utilizar um HIDS alertando sobre modificações das páginas hospedadas no servidor.
- Utilizar camadas de segurança de kernel como SELinux,GRsecurity ou Tomoyo ;
- Identificando comportamentos anormais no servidor ou site usar comandos para identificar atividades maliciosas como strace ( e.g. strace -fp PID ) e lsof ( e.g. lsof -i )
- Sempre que identificar um servidor ou site comprometido bloquear os acessos imediatamente.



[Oportunidade] Analista de Desenvolvimento

23 de Outubro de 2012, 0:00, por Software Livre Brasil - 0sem comentários ainda

Objetivo: Desenvolvimento de código Java, J2EE e suporte a sistemas

Número de vagas: 02

Nível: Pleno / Sênior

Requisitos técnicos e pessoais: Java/J2EE/Linux/JBOSS, desenvolvimento de aplicações via Hybernate e Struts. Demonstrar atenção, Paciência, Iniciativa, Trabalhar em equipe, Flexibilidade, Senso de organização, Capacidade de observação, Dinamismo, Raciocínio sintético e analítico, comunicação.

Formação: Superior completo em Sistemas de Informação, Ciência da Computação, Análise de Sistemas, Engenharia da Computação.

Salário: À combinar

Local de trabalho: Salvador

Enviar o currículo para itjobbahia@gmail.com com assunto Analista Desen. Java



Implementando uma cloud privada usando o Owncloud

26 de Setembro de 2012, 0:00, por Software Livre Brasil - 0sem comentários ainda

O conceito de computação em nuvem ( cloud computing ) vêm se expandido e permitindo que diversos serviços sejam ofertados na internet de forma gratuita ou por um baixo custo.

Mesmo existindo todo um conceito de segurança baseado nas melhores práticas, que nem sempre são seguidas diga-se de passagem, não é muito recomendado manter dados confidencias ou estratégicos dentro de nuvens públicas.

A grande questão é:

Porque não manter seus dados dentro de sua própria nuvem, garantindo assim a segurança dos dados?

O Owncloud é um sistema opensource multiplataforma que permite a criação de nuvens privadas de forma muito simples através dos diversos recursos disponíveis.

Instalação

sudo aptitude install apache2 php5 php-pear php-xml-parser php5-sqlite php5-json sqlite php5-mysql mp3info curl libcurl3 libcurl3-dev php5-curl zip php5-gd

ANTES DE CONTINUAR NÂO ESQUEÇA DE FAZER O HARDENING!!!

wget -c http://owncloud.org/releases/owncloud-latest.tar.bz2

sudo tar xvf owncloud-latest.tar.bz2 -C /var/www/

cd /var/www/ && sudo chown -R www-data. owncloud && sudo chmod -R 755 owncloud

sudo apache2ctl restart

Acesse o endereço http://IP_SERVIDOR/owncloud e crie um usuário e senha administrativa.

Agora o Owncloud está pronto para uso!



Testando a ferramenta de proteção multi-tarefa Artillery

21 de Setembro de 2012, 0:00, por Software Livre Brasil - 0sem comentários ainda

Lançado em Outubro de 2011 por Dave Rel1k ,também criador do Social-Engineer Toolkit (SET) ,o Artillery foi desenvolvido com o objetivo de funcionar como ferramenta de monitoramento, honeypot e proteção.

A versão 0.6.1 disponibiliza os seguintes módulos:

* File System Monitoring
* Hardening
* Honeypot
* Anti-DoS
* Anti SSH Brute Force

Ele também é responsável por alimentar um feed com informações dos ataques para a empresa do Rel1k a Trustedsec.

Estes módulos podem ser utilizados em conjunto ou individualmente, para entender melhor suas funcionalidades eles foram testados separadamente.

Instalação

A instalação do Artillery é muito simples bastando somente clonar o repositório svn e executar o arquivo setup.py

svn co http://svn.trustedsec.com/artillery artillery/

cd artillery

./setup.py

Welcome to the Artillery installer. Artillery is a honeypot, file monitoring, and overall security
tool used to protect your nix systems.

Written by: Dave Kennedy (ReL1K)

Do you want to install Artillery and have it automatically run when you restart [y/n]: y

Do you want to keep Artillery updated? (requires internet) [y/n]: y

[*] Finished. If you want to update Artillery go to /var/artillery and type ‘svn update’

Would you like to start Artillery now? [y/n]: n

Configuração

Todas as funcionalidades são habilitadas por padrão, para os testes editei o arquivo de configuração deixando somente um módulo habilitado.

No exemplo abaixo habilitei somente o módulo File System Monitor, adicionei o diretório /tmp no monitoramento desabilitando os outros módulos.

DICA: Mesmo informando o NO ou OFF recomendo comentar as linhas referentes as portas, o sistema não é muito obediente e abre as portas mesmo com o honeypot desabilitado.

OBS: Não foi necessário utilizar o envio de alertas por email, todas as informações necessárias foram gravadas no arquivo de log alerts.log.

MONITOR=YES

MONITOR_FOLDERS=”/var/www”,”/etc/”,”/tmp”

MONITOR_FREQUENCY=60

HONEYPOT=NO

HONEYPOT_BAN=NO

WHITELIST_IP=127.0.0.1,localhost

#PORTS=”135,445,22,1433,3389,8080,21,5900,25,53,110,1723,1337,10000,5800,44443″

EMAIL_ALERTS=OFF

SSH_BRUTE_MONITOR=OFF

SSH_BRUTE_ATTEMPTS=4

AUTO_UPDATE=ON

ANTI_DOS=OFF

ANTI_DOS_PORTS=80,443

ANTI_DOS_THROTTLE_CONNECTIONS=50

ANTI_DOS_LIMIT_BURST=200

ACCESS_LOG=/var/log/apache2/access.log

ERROR_LOG=/var/log/apache2/error.log

BIND_INTERFACE=”"

THREAT_INTELLIGENCE_FEED=ON

THREAT_FEED=”https://www.trustedsec.com/banlist.txt”

THREAT_SERVER=”OFF”

THREAT_LOCATION=”/var/www/”

Após a configuração, é só executar o arquivo artillery.py.

./artillery.py &

Para parar o serviço recomendo usar o kill porque o script de inicialização é muito fraco, ele só foi criado para inciar o serviço.

pgrep artillery

25556

kill -9 2556

Hardening

Responsável por varrer o sistema criando alertas no arquivo /var/artillery/logs/alerts.log com dicas de hardening do sistema.

cat /var/artillery/logs/alerts.log

[!] Insecure configuration detect on filesystem: Issue identified: /etc/ssh/sshd_config allows RootLogin. An attacker can gain root access to the system if password is guessed. Recommendation: Change RootLogin yes to RootLogin no

Issue identified: /etc/ssh/sshd_config. SSH is running on the default port 22. An attacker commonly scans for these type of ports. Recommendation: Change the port to something high that doesn’t get picked up by typical port scanners.

Issue identified: /var/www/site/includes/configure.php permissions are not set to root. If an attacker compromises the system and is running under the Apache user account, could view these files. Recommendation: Change the permission of /var/www/site/includes/configure.php to root:root. Command: chown root:root /var/www/site/includes/configure.php

File System Monitor

Este módulo é responsável por monitorar os diretórios informados no arquivo de configuração (/var/www, /etc/ e /tmp ), emitindo alertas se algum arquivo for modificado. Uma base de dados é criada em /var/artillery/database/integrity.database com o checksum de todos os arquivos.

cat /var/artillery/database/integrity.database

/etc/group:c598ff5224a5380a49546b7e1f4b045d72795c73a2bf72a23f041881ce9682b057a25df880cb2e5807a6fc407c6beab09273e423b2f188950d4e0eca7e4aac5b

/etc/profile.d/bash_completion.sh:1d93a773191eea24d2df194239e0e9f16adc6210ecada55f6e499705be0cc98a61665f2f2646b2e4af6413fe97424c980f1961820eab7534383938f4458f1c62

Honeypot

Este módulo pode ser configurado para bloquear ou não a tentativa de exploração do pseudo-serviço.

# DO YOU WANT TO TURN ON THE HONEYPOT
HONEYPOT=ON
#
# DO YOU WANT TO AUTOMATICALLY BAN ON THE HONEYPOT
HONEYPOT_BAN=OFF
#
# WHITELIST IP ADDRESSES, SPECIFY BY COMMAS ON WHAT IP ADDRESSES YOU WANT TO WHITELIST
WHITELIST_IP=127.0.0.1,localhost
#
# PORTS TO SPAWN HONEYPOT FOR
PORTS=”135,445,22,1433,3389,8080,21,5900,25,53,110,1723,1337,10000,5800,44443″

netstat -nat
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:5800 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:37864 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:36074 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:5900 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:110 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:10000 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:1337 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:1433 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:1723 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:44443 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:46044 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:3389 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:2049 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:135 0.0.0.0:* LISTEN
tcp6 0 0 :::22 :::* LISTEN
tcp6 0 0 ::1:25 :::* LISTEN

Testando

nc 192.168.0.6 5800

O sistema informa que a tentativa de conexão foi bloqueada, porém como a resposta automática foi desabilitada somente um alerta é criado no arquivo de log.

cat /var/artillery/logs/alerts.log

2012-09-20 23:21:55.623614 [!] Artillery has blocked (and blacklisted the IP Address: 192.168.0.2 for connecting to a honeypot restricted port

Após habilitar a resposta automática e tentar conectar o pseudo-serviço novamente, o sistema grava o ip de origem em /var/artillery/banlist.txt e cria uma regra no iptables.

SSH Brute Force Monitor

Módulo responsável por monitorar e bloquear ataques de SSH Brute Force.

Testando

Ataque

hydra -l root -P passlist.txt 192.168.0.6 ssh

Hydra (http://www.thc.org/thc-hydra) starting at 2012-09-21 19:59:34
[DATA] 16 tasks, 1 server, 3157 login tries (l:1/p:3157), ~197 tries per task
[DATA] attacking service ssh on port 22
[22][ssh] host: 192.168.0.6 login: root password: password
[STATUS] attack finished for 192.168.0.6 (waiting for children to finish)
1 of 1 target successfuly completed, 1 valid password found
Hydra (http://www.thc.org/thc-hydra) finished at 2012-09-21 19:59:48

Proteção

Artillery has blocked (blacklisted) the following IP for SSH brute forcing violations: 192.168.0.2

Anti-DOS

Módulo responsável por monitorar e “proteger” contra ataques de DoS nas portas 80 e 443. Este módulo simplesmente cria a seguinte regra do iptables:

iptables -A ARTILLERY -p tcp –dport %s -m limit –limit %s/minute –limit-burst %s -j ACCEPT

As váriveis são preechidas de acordo com as seguintes linhas do arquivo de configuração:

ANTI_DOS_PORTS=80,443

ANTI_DOS_THROTTLE_CONNECTIONS=50

ANTI_DOS_LIMIT_BURST=200

Durante os testes as ferramenta controlou alguns testes com o Pyloris e HULK, isso não significa que ele resistirá a um ataque massivo de DoS.

Conclusões

Durante os testes conclui facilmente que o Artillery precisa melhorar muito comparado a outras ferramentas mais maduras como o Honeyd, Ossec, Samhain, AIDA, Fail2ban, Modsecurity entre outras.

No meu ponto de vista ele ainda não está preparado para ser utilizado em ambientes de produção ou de alta criticidade por possui falhas na implementação, destaco abaixo algumas delas:

O script de inicialização simplesmente não para nem incia o serviço durante o boot.

cat /etc/init.d/artillery

#!/bin/sh
cd /var/artillery
sudo python artillery.py &
echo “Starting Artillery, it may take a few moments for it to come online…”

Automaticamente a ferramenta cria regras de bloqueio no iptables usando os 10416 ips existentes no arquivo /var/artillery/banlist.txt. O grande problema é que ele mantém as regras na memória e após alguns bloqueios, sucessivos erros ocorrem e novas regras não são criadas.

Não existe um tempo limite para a remoção da regra, então todas elas precisam ser removidas manualmente. O script remove_ban.py responsável por esta tarefa falha em alguns momentos.

O envio de email falha mesmo configurando os dados corretamente no arquivo de configuração.

Como informei anteriormente as portas do honeypot são habilitadas mesmo com o módulo desativado.

O tempo de resposta da detecção ao bloqueio durante os testes de brute force foi muito grande.

Recomendo o uso do Artillery como ferramenta de aprendizado da linguagem Python, pois os códigos dos módulos são bastante simples e intuitivos.

Referências

https://www.trustedsec.com/downloads/artillery/

http://thehackernews.com/2012/02/confusing-attackers-with-artillery-by.html



Tags deste artigo: linux security free software segurança hardening hacking sysadmin