Alexos Core Labs

[Atualizado] [Alerta] Repositório debian-multimedia.org desativado!

O dominio debian-multimedia.org foi desativado[1], ele pertencia ao projeto Debian-multimedia e expirou meses atrás. De acordo o com o Whois[2] ele pertence agora a Mikhail Dashkel da Ucrânia e pode estar sendo utilizado para disseminação de malware.

Por ser um projeto não suportado pelo upstream do Debian GNU/Linux é recomendado a remoção deste repositório do source.list urgentemente, com o lançamento da versão 7.0 Wheezy o uso de repositórios de terceiros para este fim torná-se desnecessário.

[UPDATE]

O domínio foi modificado para deb-multimedia[3], a recomendação da wiki Debian Multimedia[4] é baixar os pacotes e instalá-los manulamente devido aos riscos na utilização de repositórios não oficiais.

Existem alguns mirros no Brasil que podem ser utilizados para baixar os principais pacotes de multimidia não existentes nos repositórios oficiais como w32codecs, w64codecs e libdvdcss2.

deb http://www.las.ic.unicamp.br/pub/debian-multimedia/ stable main
deb-src http://www.las.ic.unicamp.br/pub/debian-multimedia/ stable main

deb http://linorg.usp.br/debian-marillat/ stable main
deb-src http://linorg.usp.br/debian-marillat/ stable main

deb ftp://linorg.usp.br/debian-marillat/ stable main
deb-src ftp://linorg.usp.br/debian-marillat/ stable main

deb http://ftp.br.debian.org/debian-multimedia stable main
deb-src http://ftp.br.debian.org/debian-multimedia stable main

deb ftp://ftp.br.debian.org/debian-multimedia stable main
deb-src ftp://ftp.br.debian.org/debian-multimedia stable main

Referências

[1] http://bits.debian.org/2013/06/remove-debian-multimedia.html

[2] https://www.networksolutions.com/whois/results.jsp?domain=debian-multimedia.org

[3] http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2012-May/thread.html#26678

[4] http://wiki.debian.org/MultimediaCodecs

by alexos Posted on 06/13/2013

Posted in Uncategorized | Tagged deb-multimedia, debian, debian multimedia, desativado, malware | Comments Off

Vulnerabilidade no Linux kernel permite escalação de privilégio

No inicio do mês de maio foi divulgada uma vulnerabilidade no kernel do linux versões 3.2.41 e anteriores (CVE-2013-2094) que permite a escalação de privilégio local por um usuário não privilegiado. A causa foi um erro na conversão de números inteiros que impactou na validação de usuários devido a um commit feito no upstream git.

Quem utiliza proteções extras para o kernel como SELinux, AppArmor entre outras, não pode se sentir imune já que a equipe da GrSecurity divulgou recentemente no twitter um exploit capaz de fazer o ‘bypass’ sem gerar nenhum tipo de log.

A RedHat informou que as versão 5 e 6.0 do RHES não foram afetadas pois não houve backport deste commit, patchs de correção foram disponibilizados pelo Ubuntu, RedHat, Debian e demais distribuições.

Referências

CVE-2013-2094

Debian Security Tracker

RedHat SystemTrap Mitigation

Red Hat Security Advisory

Debian Security Advisory

Ubuntu Security Advisory

by alexos Posted on 05/26/2013

Posted in Uncategorized | Tagged apparmor, backport, CVE-2013-2094, grsecurity, kernel, linux, security, securityguys, seguranca, selinux, vulnerabilidade | Leave a comment

Alta disponibilidade e segurança com Nginx e Naxsi

Além de servir como um servidor web leve e versátil o Nginx é muito poderoso como proxy-reverso. Também podemos utilizá-lo como um sistema de balanceamento de carga de excelente performance.

Neste post mostrarei como criar um ambiente não só de balanceamento de carga com failover, como também irei incrementá-lo com uma camada de segurança usando o WAF Naxsi.

Instalação

aptitude install nginx-naxsi

Habilitar o balanceamento de carga é muito simples bastando para isso incluir a diretiva upstream no vhost do site. Ele possibilita diversos tipos de configurações:

Esse é caso mais simples onde os backends serão tratados como um único host.

upstream acme {
        server 192.168.0.2;
        server 192.168.0.3;
        server 192.168.0.4; 
        }

A entidade acme agora será tratada como upstream servindo de referência para o parâmetro proxy_pass como mostra o exemplo abaixo:

server {
  listen acme:80;
  access_log /var/log/nginx/nginx.log;
  
  location / {
    proxy_pass http://acme;
  }
}

Para o cliente sempre manter a conexão no mesmo backend utiliza-se o parâmetro hash_ip.

upstream acme {
        hash_ip;
        server 192.168.0.2;
        server 192.168.0.3;
        server 192.168.0.4; 
        }

Prioridade e Failover

Para definir a prioridade de cada backend utiliza-se o parâmetro weight o valor padrão é 1. No exemplo abaixo as 3 primeiras requisições serão enviadas para o servidor 192.168.0.2, a 4a e 5a para o 192.168.0.3 e a 6a. para o 192.168.0.4.

upstream acme {
        hash_ip;
        server 192.168.0.2 weight=3;
        server 192.168.0.3 weight=2;
        server 192.168.0.4; 
        }

O failover é habilitando usando os parâmetros max_fails define o total de falhas na requisição e fail_timeout define o intervalo de tempo entre as falhas a partir dai a requisição é enviada para o próximo backend.

upstream acme {
        hash_ip;
        server 192.168.0.2 max_fails=3  fail_timeout=30s;
        server 192.168.0.3;
        server 192.168.0.4; 
        server 192.168.0.5 down;
        }

O parâmetro down é utilizado quando um backend está inacessível.

Naxsi

O Naxsi é um Web Application Firewall para o Nginx criado pelo Thibault Koechlin. Uma das grandes vantagens é que ele segue o modelo positivo de segurança aprendendo como a aplicação funciona e criando regras baseadas no comportamento (whitelist-based), ele não utiliza assinatura dos ataques (blacklist-based) como um AV por exemplo.

Habilitar esse WAF é muito simples bastando apenas adicionar a seguinte linha no arquivo nginx.conf:


include /etc/nginx/naxsi_core.rules;

E no arquivo do vhost

 location / {
     include    /etc/nginx/naxsi.rules;
     proxy_pass  http://acme/;
     ...
     }

#Naxsi Learning Mode 

  location /RequestDenied {
   proxy_pass http://127.0.0.1:4242;
   }

A opção Learning Mode permite ao Naxsi aprender o funcionamento da aplicação criando novas regras de whitelist.

Outra ferramenta bastante útil é o nx_util, ele é um parser que lê o arquivo de erro dos sites, atualiza uma base de dados sqlite, gera novas regras de whitelist e exporta os dados para a tela ou para um arquivo html muito bacana.

wget https://naxsi.googlecode.com/files/nx_util-0.3.tgz

tail /var/log/nginx/acme.error.log | nx_util.py -d naxsi_ui -l -i -o -H /var/www/acme.html

naxsi_ui

Visualizando os dados na console

tail /var/log/nginx/naxsi.error.log | nx_util.py -d naxsi_ui -l -i -o

Using stdin.
Committing to db ...
########### Optimized Rules Suggestion ##################
# total_count:1 (50.0%), peer_count:1 (100.0%) | simple quote
BasicRule wl:1306 "mz:$URL:/vulnerabilities/sqli/|$ARGS_VAR:id";
# total_count:1 (50.0%), peer_count:1 (100.0%) | simple quote
BasicRule wl:1013 "mz:$URL:/vulnerabilities/sqli/|$ARGS_VAR:id";

OBS1: Para acessar o html utilizei o lighttpd configurando-o na porta 8080.

OBS2: Para evitar problemas com o WordPress existem regras específicas que podem ser encontradas neste blog

Abaixo seguem os arquivos de configuração completos:

Nginx

/etc/nginx/nginx.conf

user  nginx;
worker_processes  4;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;


events {
    worker_connections  1024;
}


http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;

    tcp_nodelay on;

    gzip  on;
    gzip_disable "MSIE [1-6]\.(?!.*SV1)";

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;

# Protecao contra DoS
    client_body_buffer_size 1K;
    client_header_buffer_size 1k;
    client_max_body_size 2M;
    large_client_header_buffers 2 1k;
    client_body_timeout 10;
    client_header_timeout 10;
    keepalive_timeout 5 5;
    send_timeout 10;

    server_tokens off;

    proxy_set_header   Host             $host;
    proxy_set_header   X-Real-IP        $remote_addr;
    proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;

    proxy_max_temp_file_size 0;

    proxy_connect_timeout      90;
    proxy_send_timeout         90;
    proxy_read_timeout         90;

    proxy_buffer_size          4k;
    proxy_buffers              4 32k;
    proxy_busy_buffers_size    64k;
    proxy_temp_file_write_size 64k;
    proxy_cache_methods GET HEAD POST;

# Naxsi WAF

    include /etc/nginx/naxsi_core.rules;

}

Vhost

/etc/nginx/sites-available/acme

upstream acme {
        hash_ip;
        server 192.168.0.2 weight=5;
        server 192.168.0.3 max_fails=3  fail_timeout=30s;
        server 192.168.0.4; 
        }

server {
    listen       80;
    server_name  acme;

    access_log  /var/log/nginx/acme.access.log  main;
    error_log  /var/log/nginx/acme.error.log;

    location / {
     include    /etc/nginx/naxsi.rules;
     proxy_pass  http://acme/;
     proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
     proxy_redirect off;
     proxy_buffering off;
     proxy_set_header        Host            $host;
     proxy_set_header        X-Real-IP       $remote_addr;
     proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;	
}

#Naxsi Learning Mode 

  location /RequestDenied {
   proxy_pass http://127.0.0.1:4242;
   }
}

by alexos Posted on 05/04/2013

Posted in Uncategorized | Tagged alta disponibilidade, balanceamento de carga, failover, HA, loadbalance, naxsi, nginx, nx_util, owasp, security, securityguys, seguranca, sysadmin, waf | Comments Off

Criando regras para ips dinâmicos no iptables

Uma boa prática de segurança é limitar o acesso a consoles administrativas ou conteúdo privado para origens específicas, mas como fazer isso no iptables quando seu ip é dinâmico?

Existe um patch que amplia o suporte do iptables até a camada de aplicação, só é que necessário recompilar o kernel o que dá um certo trabalho.

Passei pelo mesmo problema e encontrei uma solução que vem funcionando muito bem.

Usando os scripts abaixo as regras do iptables serão atualizadas sempre que houver mudança no ip de origem.

RedHat e derivados

Crie o arquivo /usr/bin/dynamic_iptables.py com o conteúdo abaixo. Ele será responsável por verificar se o ip foi modificado e irá reiniciar o iptables.

Altere o valor da variável home_dyndns com o nome do host criado no seu serviço de DNS dinâmico ( e.g. no-ip ou dyndns )

#!/usr/bin/python

import os

def gettextoutput(cmd):
    """Return (status, output) of executing cmd in a shell."""
    pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r')
    pipe = os.popen(cmd + ' 2>&1', 'r')
    text = pipe.read()
    if text[-1:] == '\n': text = text[:-1]
    return text

home_dyndns = "acme.no-ip.org"
log_dyndns = "/tmp/iptables_noip_update.log"
last_dyndns = gettextoutput("cat " + log_dyndns)
cur_dyndns = gettextoutput("host " + home_dyndns)

print "Log: "+ last_dyndns
print "Cur: "+ cur_dyndns

if last_dyndns == cur_dyndns:
    print "IPs match, no restart necessary"
else:

    print "Updating last IP with current"
    os.system("echo '" + cur_dyndns + "' > " + log_dyndns)
    print "Restarting iptables to update"
    os.system("/etc/init.d/iptables restart")

Crie o arquivo /usr/bin/update_rules.sh que será responsável pela atualização das regras do iptables com o novo endereço de origem.

Altere o valor da variável HOSTNAME com o nome do host criado no seu serviço de DNS dinâmico ( e.g. no-ip ou dyndns )

#!/bin/bash

HOSTNAME=acme.no-ip.org
LOGFILE=/tmp/iptables_noip_update.log

Current_IP=$(host $HOSTNAME | cut -f4 -d' ')

if [ $LOGFILE = "" ] ; then
iptables -I INPUT -i eth0 -s $Current_IP -j ACCEPT
echo $Current_IP > $LOGFILE
else

Old_IP=$(cat $LOGFILE)

if [ "$Current_IP" = "$Old_IP" ] ; then
echo "IP address has not changed"
else
iptables -D INPUT -i eth0 -s $Old_IP -j ACCEPT
iptables -I INPUT -i eth0 -s $Current_IP -j ACCEPT
echo $Current_IP > $LOGFILE
echo "iptables have been updated"
fi

No Redhat as regras do iptables são armazenadas no arquivo /etc/sysconfig/iptables criado usando o comando iptables-save. Quando o serviço for reiniciado as regras contidas neste arquivo serão reaplicadas.

Debian e derivados

Para rodar no Debian foi preciso fazer pequenas adaptações nos scripts.

Crie o arquivo /usr/bin/dynamic_iptables.py com o conteúdo abaixo.

Altere o valor da variável home_dyndns com o nome do host criado no seu serviço de DNS dinâmico ( e.g. no-ip ou dyndns )

#!/usr/bin/python
import os

def gettextoutput(cmd):
    """Return (status, output) of executing cmd in a shell."""
    pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r')
    pipe = os.popen(cmd + ' 2>&1', 'r')
    text = pipe.read()
    if text[-1:] == '\n': text = text[:-1]
    return text

home_dyndns = "acme.no-ip.org"
log_dyndns = "/tmp/iptables_noip_update.log"
last_dyndns = gettextoutput("cat " + log_dyndns)
cur_dyndns = gettextoutput("host " + home_dyndns)

print "Log: "+ last_dyndns
print "Cur: "+ cur_dyndns

if last_dyndns == cur_dyndns:
    print "IPs match, no restart necessary"
else:
    print "Updating last IP with current"
    os.system("echo '" + cur_dyndns + "' > " + log_dyndns)

Crie o arquivo /usr/bin/update_rules.sh.

Altere o valor da variável HOSTNAME com o nome do host criado no seu serviço de DNS dinâmico ( e.g. no-ip ou dyndns )

#!/bin/bash

HOSTNAME=acme.no-ip.org
LOGFILE=iptables_noip_update.log

Current_IP=$(host $HOSTNAME | cut -f4 -d' ')

if [ $LOGFILE = "" ] ; then
iptables -I INPUT -i eth0 -s $Current_IP -j ACCEPT
echo $Current_IP > $LOGFILE
else

Old_IP=$(cat $LOGFILE)

iptables -D INPUT -i eth0 -s $Old_IP -j ACCEPT
iptables -I INPUT -i eth0 -s $Current_IP -j ACCEPT
echo $Current_IP > $LOGFILE
echo "iptables have been updated"
fi

Agendamento

Para automatizar o processo de atualização crie agendamentos no /etc/crontab ou no crontab do usuário root usando o comando sudo crontab -e

* 8 * * * /usr/bin/dynamic_iptables.py > /tmp/dynamic_iptables.log
* * * * * /usr/bin/update_rules.sh > /tmp/dynamic_rules.log

Referências

Using IPTables with Dynamic IP hostnames like dyndns.org

L7-filter Kernel Version HOWTO

by alexos Posted on 04/23/2013

Posted in Uncategorized | Tagged dyndns, firewall, ip dinâmico, iptables, L7, no-io, rules, security, securityguys, seguranca | Comments Off

Otimizando a detecção de ataques de SQLi com evasão do Ossec HIDS

SQL injection é uma das vulnerabilidades mais difundidas e exploradas em aplicações Web, não é muito difícil encontrar esta falha em diversos CMSs, plugins e códigos de sites espalhados pela internet.

Ferramentas de proteção como WAFs e IDS/IPS possuem regras que alertam ou bloqueiam este tipo de ataque, porém existem diversas técnicas evasivas que permitem o concretização do ataque como:

White Space Manipulation;
URL encoding;
Unicode/UTF-8;
Hex Encoding;
char() function;
Comment Exploitation;
Concatenation, etc.

O SQLmap, uma das melhores ferramentas para este tipo de ataque, possui um pool de scripts de evasão ( tamper ) bastante interessante.

Aproveitei o laboratório da apresentação que farei no Flisol para melhorar a detecção destes ataques e acabei criando algumas regras que otimizaram o tempo de identificação e o bloqueio. As regras atuais conseguem identificar o ataque, porém o delay entre a identificação e o bloqueio é um pouco alto, usando mais de um tamper e outras opções como o aumento do intervalo das requisições por exemplo piora ainda mais detecção.

Estas novas regras foram aprovadas pelo upstream do Ossec HIDS estando disponíveis no repositório do projeto e serão publicadas no novo release que está na versão alfa.

Quem estiver interessado em utilizar ou testar apenas adicione as linhas abaixo no arquivo /var/ossec/rules/local_rules.xml.

<if_sid>31100</if_sid>

<description>SQL injection attempt.</description>

</rule>

<if_sid>31100</if_sid>

<description>SQL injection attempt.</description>

</rule>

</group>

Sugestões e melhorias serão sempre bem vindas! =P

by alexos Posted on 04/19/2013

Posted in Uncategorized | Tagged defense, defesa, evasão, Flisol 2013, IDS/IPS, ossec hids, protecao, rules, security, securityguys, sql injection, SQLi, waf | 1 Comment

Linode Pwned!

Hoje o Linode anunciou que seu ambiente de administração de servidores foi invadido. O cracker “ryan” que se diz do grupo HTP ( Hack the Planet ) assumiu a autoria do ataque com o objetivo obter informações de cartões de crédito e senhas de acesso.

Segundo o anúncio os dados dos cartões são mantidos criptografados usando chave pública e privada dentro do banco de dados e as chaves públicas são auto-encriptadas com senhas complexas. Além destas informações o cracker obteve acesso nos servidores web e “parte” do código-fonte das aplicações do Linode.

A falha explorada do Adobe ColdFusion ( CVE-2013-1387, CVE-2013-1388) foi recentemente divulgada e corrigida, ela permite o ‘bypass’ da autenticação na console administrativa.

Para os usuários deste datacenter é recomendando acompanhar as informações do cartão de crédito cadastrado, trocar a senha de acesso da dashboad usando senhas complexas, monitorar o consumo de recursos do servidor e rezar.

Para os usuários do ColdFusion é de extrema importância a atualização do ambiente, já que após explorado o servidor poderá ser utilizado para práticas criminosas ( Spam, botnet, etc ).

Não fico surpreso com esta notícia, já que a gestão de vulnerabilidades é quase que totalmente negligenciada por todos, seja ele um grande ou pequeno provedor.

Referências:

CVE-2013-1387

CVE-2013-1388

Hackers Claim to Have Gained Access to Linode Customer Passwords, Credit Cards

Blog Linode – Security Incident Update

Adobe Security Bulletin

by alexos Posted on 04/16/2013

Posted in Uncategorized | Tagged Adobe, ColdFusion, CVE-2013-1387, CVE-2013-1388, HTP, Linode, securityguys | Comments Off

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

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 Proto Recv-Q Send-Q Local Address tcp 0 0 0.0.0.0:5800 tcp 0 0 0.0.0.0:37864 tcp 0 0 0.0.0.0:36074 tcp 0 0 0.0.0.0:5900 tcp 0 0 0.0.0.0:110 tcp 0 0 0.0.0.0:111 tcp 0 0 0.0.0.0:8080 tcp 0 0 0.0.0.0:10000 tcp 0 0 0.0.0.0:53 tcp 0 0 0.0.0.0:21 tcp 0 0 0.0.0.0:22 tcp 0 0 0.0.0.0:1337 tcp 0 0 0.0.0.0:1433 tcp 0 0 127.0.0.1:25 tcp 0 0 0.0.0.0:1723 tcp 0 0 0.0.0.0:44443 tcp 0 0 0.0.0.0:46044 tcp 0 0 0.0.0.0:445 tcp 0 0 0.0.0.0:3389 tcp 0 0 0.0.0.0:2049 tcp 0 0 0.0.0.0:135 tcp6 0 0 :::22 tcp6 0 0 ::1:25 (servers and established)
Foreign Address State
0.0.0.0:* LISTEN
0.0.0.0:* LISTEN
0.0.0.0:* LISTEN
0.0.0.0:* LISTEN
0.0.0.0:* LISTEN
0.0.0.0:* LISTEN
0.0.0.0:* LISTEN
0.0.0.0:* LISTEN
0.0.0.0:* LISTEN
0.0.0.0:* LISTEN
0.0.0.0:* LISTEN
0.0.0.0:* LISTEN
0.0.0.0:* LISTEN
0.0.0.0:* LISTEN
0.0.0.0:* LISTEN
0.0.0.0:* LISTEN
0.0.0.0:* LISTEN
0.0.0.0:* LISTEN
0.0.0.0:* LISTEN
0.0.0.0:* LISTEN
0.0.0.0:* LISTEN
:::* LISTEN
:::* 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.

Enfim 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

by alexos Posted on 09/21/2012

Posted in Uncategorized | Tagged aida, artillery, fail2ban, file system integrity, hardening, honeypot, modsecurity, ossec, pyloris, security, securityguys, set | Comments Off

Software Freedom Day (SFD) 2012 – Salvador

O Software Freedom Day (SFD) é uma celebração mundial do Software Livre e do Código Aberto (Free and Open Source Software – FOSS).

O SFD têm como objetivo educar o público em todo o mundo
sobre os benefícios do uso de software livre de alta qualidade na
educação, no governo, em casa, e nos negócios.

Em Salvador este evento ocorrerá dia 15/09 ( sábado ) na Faculdade FTC Paralela.

Maiores informações:
Software Freedom Day Salvador

by alexos Posted on 08/29/2012

Posted in Uncategorized | Tagged 2012, eventos, Free Software, OpenSource, salvador, sfd, software freedom day, software livre | Comments Off

SSH!

ssh

by alexos Posted on 08/14/2012

Posted in Uncategorized | Tagged securityguys, ssh | Comments Off

Archives