Roubo de senhas SSH
6 de Maio de 2010, 0:00 - sem comentários ainda
Esta semana estive estudando alguma vulnerabilidades conhecidas e me deparei com uma técnica muito usada em redes locais, que é o roubo de credenciais de SSH. Apesar do SSH ser um protocolo criptografado, ainda existe a possibilidade de um servidor "falso" se passar por verdadeiro e receber as conexões em seu lugar.
A técnica funciona colocando uma máquina no meio da conexão (man-in-the-middle) através de ataques de DNS Spoof ou Arp Spoof combinados, onde a intenção é forçar que as conexões SSH venham direto para o servidor falso ao invés do servidor verdadeiro. Após esse passo o cracker vai precisar de um software que emule o ambiente verdadeiro (SSH honeypot) para que o usuário digite a senha pensando que está digitando no servidor correto.
Vou descrever algumas técnicas/ferramentas aqui e no final vou postar um vídeo demonstrativo.ARP SPOOF
Muitos Sysadmins acham que o fato de terem um switch no lugar de um hub torna a rede completamente invulnerável, contudo esta técnica demonstra que de fato ainda existem problemas de segurança neste modelo. Existem um pacote cracker chamado dsniff, com uma série de ferramentas interessantíssimas e uma delas é a arpspoof.
A ferramenta funciona enviando ao computador da vítima (Sysadmin da empresa) respostas ARP informando que o endereço MAC do IP do gateway (roteador) é o endereço MAC do atacante .Depois de algum tempo o computador da vítima vai acreditar e faz uma entrada errada em seu cache ARP. Da próxima vez que a vítima enviar um pacote para o IP do gateway, mandará para o atacante.
A sintaxe é simples:
arpspoof -i [interface de rede]-t [ip da vítima] [gateway]
Não esqueça de ativar o ip_forward para a vítima não perder a conectividade
echo "1" > /proc/sys/net/ipv4/ip_forward
DNS SPOOF
É muito comum que o Sysadmins tentem conectar aos seus servidores remotos usando nomes, sendo assim, é interessante também forjar respostas de DNS e redirecionar qualquer nome para o seu próprio endereço. Isso é possível com outra ferramenta que vem no pacote cracker que mencionamos anteriormente e seria o binário dnsspoof. Caso o usuário tente conectar no servidor www.exemplo.com.br na porta 22 o DNS SPOOF do atacante vai informar ao computador da vítima que o ip deste domínio é o ip que foi definido por ele mesmo, no caso do nosso exemplo 192.168.1.156.
A utilização é muito simples, primeiro o atacante adiciona uma entrada como esta no arquivo de hosts:
192.168.1.156 *.*
Depois ativa o dnsspoof apontando para o arquivo hosts alterado:
dnsspoof -f /etc/hosts
SSH honeypot
Antes de tudo precisamos entender o conceito de Honeypot, segue:
SSH honeypot
Antes de tudo precisamos entender o conceito de Honeypot, segue:
[Ing.] (Pote de mel) Armadilha destinada à atrair intrusos que tentam invadir um sistema. Consiste em configurar um computador de modo a deixá-lo vulnerável a invasões. Um programa especial instalado monitora as ações do invasor apontando os pontos falhos do sistema que ele tenta explorar. As informações colhidas podem ajudar a identificar o intruso.
Apesar dos Honeypots serem usados pelos "Hackers do bem" visando estudar o comportamento dos crakers dentro de um servidor 0wnado, nada impede da utilização deste mesmo tipo de conceito para o mal. Para o exemplo didático podemos citar o Kippo, que é um mediador de interação SSH idealizado para logar bruteforce ataques e que pode ser utilizado para este fim. Não vamos descrever a instalação e configuração deste software pois no site official explica tudo:
Para ver o funcionamento instale a ferramenta, suba o daemon numa porta qualquer (no exemplo do vídeo está na porta 2222) e aponte o tráfego de SSH da vítima para o seu Honeypot através do iptables. Segue abaixo um exemplo de regra:
iptables -t nat -A PREROUTING -p tcp -s 0/0 --dport 22 -j DNAT --to 192.168.1.156:2222
Pronto! Quando o Sysadmin tentar acessar o servidor remoto www.exemplo.com.br:22 automaticamente vai aparecer um prompt idêntico ao servidor verdadeiro para ele digitar o login e a senha, contudo, estará digitando no seu pote de mel. ;)
Como se proteger?
Para se proteger desse ataque específico passe a utlizar a autenticação do SSH por meio de chaves criptografadas, além disso técnicas de port knocking tornam ainda mais difícil a tarefa do nosso inimigo! A implementação do SSH com chaves é simples e demasiadamente documentada na web, vou colocar o link que explica bem o assunto:
http://www.vivaolinux.com.br/artigo/SSH-Autenticando-atraves-de-chaves?pagina=2
no ubuntu:
http://ubuntu.no.sapo.pt/ssh_com_chaves.html
Vídeo demonstrativo:
Espero que tenham gostado!
;)
HTTPS no Load Balance de Link
6 de Maio de 2010, 0:00 - sem comentários ainda
Felizmente a resolução deste problema é simples! Basta marcar através do iptables os pacotes da porta 443 (https) para que eles passem sempre pelo mesmo link, adicionando eles na nova tabela de roteamento criada anteriormente para tornar possível o load balance. Vamos usar apenas uma regra de iptables e outra de iproute, assumindo que seus clientes já estão navegando e as regras de FORWARD e NAT já estão corretas.
OBS1: Estou utilizando o exemplo do HTTPS, contudo caso tenha problemas com outros serviços, as mesmas regras se aplicam a outros protocolos.
Mão na massa!
Em primeiro lugar precisamos escolher por qual dos links todo o tráfego SSL vai passar, faça isso escolhendo uma das tabelas de roteamento criadas no arquivo rt_tables.
cat /etc/iproute2/rt_tables
#
# reserved values
#
255 local
254 main
253 default
0 unspec
#
# local
#
#1 inr.ruhep
10 LINK_A
20 LINK_B
No meu caso eu criei as tabelas LINK_A e LINK_B onde escolhi a segunda opção para trafegar os pacotes criptografados do https. Sabendo qual tabela vamos usar, vamos criar a regra de firewall que vai marcar os pacotes para que possamos manipulá-los livremente.
iptables -A PREROUTING -t mangle -p tcp -m tcp --dport 443 -j MARK --set-mark 0x1
Com esta regra, estamos dizendo que todos os pacotes TCP com destino a porta 443 vão ser marcados com o valor 0x1.
OBS: A única tabela que permite este tipo de marcação é a mangle, não vamos abordar aqui as tabelas do iptables mas asseguro que existe muita documentação sobre o assunto.
Vamos agora dizer que todos os pacotes marcados com o valor 0x1 vão ser direcionados para tabela escolhida, para isto basta digitar uma linha de comando:
ip rule add prio 11 fwmark 0x1 table LINK_B
Pronto! Basta limpar o cache das rotas e aproveitar.
ip route flush cache
;)
Cluster de servidores web com SQUID
30 de Abril de 2010, 0:00 - sem comentários ainda
- Round-robin de requisições;
- Failover (Remover automaticamente o servidor down do cluster);
- Controle de acessos através de ACL`s;
- Cache de objetos;
- Definição de "peso" para cada servidor.
É um proxy que geralmente fica na frente de servidores web recebendo as requisições vindas da internet, tratando-as e entregando a um ou mais servidores internos.
OBS1: Todas as requisições que chegarem nos servidores web internos vão chegar com o ip do servidor proxy, contudo, existe um patch para o kernel e para o próprio squid chamado tproxy que possibilita a total transparência das requisições. Segue um link que trata de forma mais profunda o assunto:
http://www.balabit.com/support/community/products/tproxy/
OBS2: É importante ter um servidor de DNS interno para que o squid possa consultar e fazer o round-robin, principalmente se você hospedar vários sites. Basta criar vários Hosts do tipo A iguais, mas com os ips diferentes ex:
www IN A 192.168.0.1
www IN A 192.168.0.2
www IN A 192.168.0.3
A implantação é muito simples e funcionará assim:
Instalação do Squid
Eu particularmente gosto de usar o squid 2.7, é realmente muito estável e performático:
wget http://www.squid-cache.org/Versions/v2/2.7/squid-2.7.STABLE9.tar.gz
Depois:
./configure --enable-delay-pools --enable-arp-acl --enable-htcp --enable-cache-digests --enable-cachemgr-hostname=localhost --enable-digest-auth-helpers=password --enable-epoll --enable-external-acl-helpers=ip_user,ldap_group,unix_group,wbinfo_group --enable-ident-lookups --with-large-files --enable-linux-netfilter --enable-auth=ntlm,basic --enable-basic-auth-helpers=multi-domain-NTLM,SMB --enable-ntlm-fail-open --enable-ntlm-auth-helpers=SMB,fakeauth --enable-referer-log --enable-removal-policies=heap,lru --enable-snmp --enable-storeio=aufs,diskd,null,ufs --enable-useragent-log --enable-wccpv2 --with-aio --with-dl --with-pthreads --enable-follow-x-forwarded-for --prefix=/usr/local/squid2_7
Depois:
make && make install
Configuração do Squid
Segue abaixo um arquivo de configuração completo e comentado nos pontos mais importantes, não vou comentar todos os parâmetros pois existe uma vasta documentação sobre eles no próprio site oficial:
http://www.squid-cache.org/Doc/config/
# Coloque o site principal, vai ser a direção default do squid
http_port 80 vhost defaultsite=www.exemplo.com.br
icp_port 0
hierarchy_stoplist cgi-bin ?
acl QUERY urlpath_regex cgi-bin \?
no_cache deny QUERY
cache_mem 1 GB
cache_swap_low 90
cache_swap_high 95
# Aqui você define a partição de cache e a forma de armazenamento,
# particularmente uso o diskd pois é mais performático que o ufs
# e suporta mais requisições por segundo.
# http://oreilly.com/catalog/squid/chapter/ch08.pdf
# Além disso aconselho a partição de cache
# com o filesystem ReiserFS.
cache_dir diskd /cache 1024 64 256 Q1=64 Q2=72
cache_access_log /var/log/squid/access.log
cache_log none
cache_store_log none
#Usuário que o squid vai rodar, não esqueça de adicioná-lo no sistema adduser
cache_effective_user squid
cache_effective_group squid
memory_pools on
memory_pools_limit 32 MB
maximum_object_size 4 MB
minimum_object_size 0 KB
maximum_object_size_in_memory 64 KB
fqdncache_size 1024
mime_table /usr/local/squid2_7/etc/mime.conf
log_mime_hdrs off
log_fqdn off
check_hostnames off
allow_underscore on
# Servidor de DNS que o squid vai usar para resolver as requisições, muito importante!
dns_nameservers 127.0.0.1
request_header_max_size 1 MB
quick_abort_min 50 KB
quick_abort_max 50 KB
quick_abort_pct 85
connect_timeout 60 seconds
peer_connect_timeout 30 seconds
read_timeout 15 minutes
request_timeout 1 minutes
persistent_request_timeout 1 minute
client_lifetime 1 day
pconn_timeout 30 seconds
ident_timeout 10 seconds
half_closed_clients off
forward_timeout 3 minutes
shutdown_lifetime 30 seconds
refresh_pattern -i \.jpg$ 0 50% 21600 reload-into-ims
refresh_pattern -i \.gif$ 0 50% 21600 reload-into-ims
refresh_pattern -i \.png$ 0 50% 21600 reload-into-ims
refresh_pattern -i \.jpeg$ 0 50% 21600 reload-into-ims
refresh_pattern -i \.bmp$ 0 50% 21600 reload-into-ims
refresh_pattern -i \.tif$ 0 50% 21600 reload-into-ims
refresh_pattern -i \.tiff$ 0 50% 21600 reload-into-ims
refresh_pattern -i \.swf$ 0 50% 21600 reload-into-ims
refresh_pattern -i \.html$ 0 20% 1440
refresh_pattern -i \.htm$ 0 20% 1440
refresh_pattern -i \.shtml$ 0 20% 1440
refresh_pattern -i \.shtm$ 0 20% 1440
refresh_pattern -i \.mov$ 2880 80% 21600 reload-into-ims
refresh_pattern -i \.avi$ 2880 80% 21600 reload-into-ims
refresh_pattern -i \.mpg$ 2880 80% 21600 reload-into-ims
refresh_pattern -i \.mpeg$ 2880 80% 21600 reload-into-ims
refresh_pattern -i \.qtm$ 2880 80% 21600 reload-into-ims
refresh_pattern -i \.flv$ 2880 80% 21600 reload-into-ims
refresh_pattern -i \.wav$ 1440 100% 4320 reload-into-ims
refresh_pattern -i \.au$ 1440 100% 4320 reload-into-ims
refresh_pattern -i \.mid$ 1440 100% 4320 reload-into-ims
refresh_pattern -i \.mp3$ 2880 100% 21600 reload-into-ims
refresh_pattern -i \.zip$ 7200 50% 21600 reload-into-ims
refresh_pattern -i \.gz$ 0 50% 10080 reload-into-ims
refresh_pattern -i \.arj$ 0 50% 4320 reload-into-ims
refresh_pattern -i \.lha$ 0 50% 4320 reload-into-ims
refresh_pattern -i \.lzh$ 0 50% 4320 reload-into-ims
refresh_pattern -i \.rar$ 7200 50% 21600 reload-into-ims
refresh_pattern -i \.tgz$ 0 50% 21600 reload-into-ims
refresh_pattern -i \.tar$ 0 50% 21600 reload-into-ims
refresh_pattern -i \.Z$ 0 50% 4320 reload-into-ims
refresh_pattern -i \.sit$ 0 50% 4320 reload-into-ims
refresh_pattern -i \.pdf$ 7200 50% 10080 reload-into-ims
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern . 0 20% 4320
acl all src 0.0.0.0/0.0.0.0
acl localhost src 127.0.0.1/255.255.255.255
acl to_localhost dst 127.0.0.0/8
acl SSL_ports port 443 563
acl Safe_ports port 9876
acl Safe_ports port 80 # http
acl Safe_ports port 81
acl Safe_ports port 8081
acl Safe_ports port 8082
acl Safe_ports port 8083
acl Safe_ports port 82 #
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 563 # https, snews
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl Safe_ports port 23000
acl tam port 444
acl CONNECT method CONNECT
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_reply_access allow all
reply_header_max_size 10 KB
httpd_suppress_version_string on
tcp_recv_bufsize 0 bytes
forwarded_for on
follow_x_forwarded_for allow all
http_access allow all
icp_access allow all
detect_broken_pconn on
pipeline_prefetch on
ie_refresh on
relaxed_header_parser on
client_persistent_connections on
server_persistent_connections on
persistent_connection_after_error off
reload_into_ims on
# Aqui é a parte mais importante do balanceamento de carga, onde dizemos quais são os servidores
# que fazem parte do cluster e caso necessário o weight (peso) para cada servidor.
# Isto é importante caso você tenha servidores com hardware diferentes e queira destinar mais # conexões para as máquinas mais robustas. No nosso caso vou colocar três vezes mais conexões # para o primeiro servidor
cache_peer 192.168.0.1 parent 80 0 no-query originserver round-robin no-digest weight=3
cache_peer 192.168.0.2 parent 80 0 no-query originserver round-robin no-digest weight=1
cache_peer 192.168.0.3 parent 80 0 no-query originserver round-robin no-digest weight=1
visible_hostname www.exemplo.com.br
cache_mgr contato@exemplo.com.br
Pronto!
Você já tem um balanceamento de carga web ;)
Load Balance com o Linux
30 de Abril de 2010, 0:00 - sem comentários ainda Resumindo, o que vamos fazer é criar mais duas tabelas de roteamento com dois gateways diferentes e configurar o linux para fazer uma espécie de "round-robin" de pacotes entre esses gateways, onde podemos definir peso entre essas rotas default e até implementar um failover.
Precisaremos de pelo menos três placas de rede no servidor, onde uma seria para a rede interna e as outras duas seriam para os links.
LoadBalance
Em primeiro lugar vamos adicionar as duas novas tabelas no arquivo /etc/iproute2/rt_tables
#
# reserved values
#
255 local
254 main
253 default
0 unspec
#
# local
#
#1 inr.ruhep
10 LINK_A # Operadora A
20 LINK_B # Operadora B
Agora vamos ao script comentado:
#!/bin/bash
ip route add [REDE A] dev eth0 src [IP DA PLACA A] table LINK_A
ip route add default [GATEWAY DA REDE A] table LINK_A
ip route add [REDE B] dev eth1 src [IP DA PLACA B] table LINK_B
ip route add default via [GATEWAY DA REDE B] table LINK_B
ip rule add from [IP DA PLACA A] table LINK_A
ip rule add from [IP DA PLACA B] table LINK_B
ip route add default scope global nexthop via [GATEWAY DA REDE A] dev eth0 weight 1 nexthop via [GATEWAY DA REDE B] dev eth1 weight 1
Os comandos acima estão adicionando rotas para as novas tabelas que criamos que no caso foram duas, onde o parâmetro nexthop na ultima linha do script é fundamental para o load balance. É ele que vai fazer a alternação entre os links de internet, além disso tem o parâmetro weight que é responsável por definir o peso de cada rota, quanto maior o peso, mais pacotes vão por ela, observe que coloquei os pesos iguais.
Para facilitar a sua vida, vou repetir o script com alguns exemplos de IP`s:
#!/bin/bash
ip route add 200.232.30.8/29 dev eth0 src 200.232.30.9 table LINK_A
ip route add default 200.232.30.10 table LINK_A
ip route add 189.130.231.8/29 dev eth1 src 189.130.231.9 table LINK_B
ip route add default via 189.130.231.10 table LINK_B
ip rule add from 200.232.30.9 table LINK_A
ip rule add from 189.130.231.9 table LINK_B
ip route add default scope global nexthop via 200.232.30.10 dev eth0 weight 1 nexthop via 189.130.231.10 dev eth1 weight 1
Para testar direcione o ping pelas interfaces que estão no load balance:
[root@Owner scripts]# ping www.google.com.br -I eth0
PING www.l.google.com (64.233.163.104) from 200.232.30.9 eth0: 56(84) bytes of data.
64 bytes from bs-in-f104.1e100.net (64.233.163.104): icmp_seq=1 ttl=53 time=52.9 ms
64 bytes from bs-in-f104.1e100.net (64.233.163.104): icmp_seq=2 ttl=53 time=51.1 ms
e depois:
[root@Owner scripts]# ping www.google.com.br -I eth1
PING www.l.google.com (64.233.163.104) from 189.130.231.9 eth2: 56(84) bytes of data.
64 bytes from bs-in-f104.1e100.net (64.233.163.104): icmp_seq=1 ttl=52 time=73.6 ms
64 bytes from bs-in-f104.1e100.net (64.233.163.104): icmp_seq=2 ttl=54 time=49.3 ms
FailOver
Para implementarmos o failover baixe o script feito por outro blogueiro (Let's share the code) no endereço abaixo:
http://blog.taragana.com/wp-content/upload/gwping
- Mude a permissão do arquivo para virar um executável (chmod 755 gwping) e coloque-o no diretório /usr/bin/
- Altere os seguintes parâmetros:
- Interfaces de rede externas
EXTIF1=eth0
EXTIF2=eth1
- IP`s das interfaces
IP1=200.232.30.9
IP2=189.130.231.9
- Gateways das redes
GW1=200.232.30.10
GW2=189.130.231.10
- Peso das rotas
W1=1
W2=1
- Nome das tabelas de roteamento
NAME1=LINK_A
NAME2=LINK_B
- Quantidade de vezes a testar antes de mudar as rotas
SUCCESSREPEATCOUNT=4
FAILUREREPEATCOUNT=2
Pronto! Basta colocar no final do script esta linha:
nohup /usr/sbin/gwping &
OBS1: Lembre-se de colocar no arquivo rc.local uma menção ao seu script para que ele seja executado todas as vezes que a máquina ligar;
OBS2: Você pode ter problemas com sites HTTPS, para solucionar basta apenas colocar uma rota estática.
Sites relacionados:
FreeBSD
Script para apagar mensagens antigas no Qmail/Vpopmail
27 de Abril de 2010, 0:00 - sem comentários ainda
Decidi fazer um pequeno script que automatizasse tal tarefa, e como de costume, vou compartilhar descrevendo cada trecho de código.
OBS1: Vamos apagar as mensagens do vpopmail, quem usa IMAP (Courier por exemplo) precisa de algumas implementações de código tendo em vista que o usuário de pode criar pastas no servidor através do cliente. Tem uma constante logo no início do código onde você diz quais são as pastas que serão verificadas dentro do laço de repetição.
OBS2: Lembro que estamos usando o vpopmail com Maildir e autenticação cdb, sendo assim, este script não vai funcionar para quem usa MySQL/vpopmail.
Segue abaixo:
#!/bin/bash
############################################
# Script para apagar mensagens no vpopmail #
# -----------------------------------------#
# Autor: Toronto Garcez de Meneses Vercosa #
# Data: 23.04.201 #
############################################
#
# Constantes
#
DOMINIO=$1
PATH_DOMAINS=/var/qmail/vpopmail/domains/ #Pastas dos dominios
DIRS="cur new tmp"
DAYS="90" # Qt. de dias para um mensagem ser considerada antiga - 3 meses pra mim
# Main
if [ $DOMINIO <> " " ]
then
if [ ! -e $PATH_DOMAINS$DOMINIO/vpasswd ]
then
echo "Este dominio nao existe!"
else
cat $PATH_DOMAINS$DOMINIO/vpasswd |grep -v "Postmaster"|awk -F":" '{print $6}' |while read LINHAS
do
# Para cada pasta colocada na constante DIRS eh feita uma varredura
for DIR in $DIRS
do
find $LINHAS/Maildir/$DIR -mtime +$DAYS -exec rm {} \;
done
done
fi
fi
Basta executar esse script passando como parâmetro o nome do domínio que você quer limpar.
Ex:
[root@XFSr00t ~]# ./script.sh exemplo.com.br
;)
