Servindo SSH com mais segurança em 4 passos

Nada de scanning, tampouco bruteforce. O negócio é 'segurar'.
Como melhorar, e muito, a segurança de um servidor ssh 4 passos (sem utilização de firewall)? Simples assim:

1. Desabilite o login da conta root. (PermitRootLogin no)
2. Desabilite logins baseados em usuário/senha. (PasswordAuthentication no) - Assim, a permissão de acesso ao servidor ssh será baseado em verificação de 'ssh keys'.
3. Coloque o serviço sshd para escutar em uma porta diferente da usual. (Port 9522, ex.)
4. Instale o DenyHosts!

O DenyHosts é uma ferramenta que bloqueia hosts que estão tentando efetuar
ataques de força bruta contra servidores SSH. Desenvolvido em Python por Phil Schwartz, o DenyHosts está atualmente na versão 2.6.

Pré-Requisitos (ambiente utilizado: Debian Etch - Kernel 2.6.18-4):

1.OpenSSH-Server compilado com suporte à TCP_WRAPPERS. Para saber se no seu caso o suporte foi habilitado, faça o seguinte teste:
Altere o arquivo /etc/hosts.deny e acrescente a seguinte linha no final do arquivo:
$ sshd: 127.0.0.1

Agora tente fazer uma conexão ssh em localhost, e se a resposta for algo como isto abaixo...:

[alberto@mybox:~]$ ssh localhost
ssh_exchange_identification: Connection closed by remote host
[alberto@mybox:~]$

...gotcha! Isso significa que o suporte à TCP_WRAPPERS está habilitado.

Ah, não se esqueça de remover a linha "sshd: 127.0.0.1" do arquivo /etc/hosts.deny!!!

2. Python v2.3 ou superior. (Eu usei a versão 2.4.4)


Instalando o DenyHosts

[alberto@mybox:~]$ wget http://ufpr.dl.sourceforge.net/sourceforge/denyhosts/DenyHosts-2.6.tar.gz
[alberto@mybox:~]$ tar zxvf DenyHosts-2.6.tar.gz

Dentro do diretório criado existe um arquivo chamado setup.py. Este script automatiza o processo de instalação fazendo com que os arquivos sejam alocados em /usr/share/denyhosts/. Sendo assim, faça o seguinte:

[alberto@mybox:~]$ cd DenyHosts-2.6 && python setup.py install

Agora é só configurar:

Vou utilizar o próprio arquivo de configuração de exemplo:

[alberto@mybox:~]$ cd /usr/share/denyhosts
[alberto@mybox:/usr/share/denyhosts]$ cp denyhosts.cfg-dist denyhosts.cfg

As únicas opções que eu precisei alterar foram o caminho do arquivo de log que a ferramenta vai ler e o caminho do lock file/PID do DenyHosts (caminhos para ambiente Debian):

SECURE_LOG = /var/log/auth.log
LOCK_FILE = /var/run/denyhosts.pid

Para que possamos utilizar p DenyHosts como daemon, iremos precisar do script daemon-control. Novamente utilizando o script de modelo como base:

[alberto@mybox:/usr/share/denyhosts]$ cp daemon-control-dist daemon-control

Certifique-se de que os valores das opções DENYHOSTS_BIN, DENYHOSTS_LOCK E DENYHOSTS_CFG estejam assim (valores para Debian):

DENYHOSTS_BIN = "/usr/bin/denyhosts.py"
DENYHOSTS_LOCK = "/var/run/denyhosts.pid"
DENYHOSTS_CFG = "/usr/share/denyhosts/denyhosts.cfg"

Não alterei nenhuma outra opção do script daemon-control.

Agora, altere algumas permições:

[alberto@mybox:/usr/share/denyhosts]$ chown root daemon-control && chmod 770 daemon-control

Para finalizar, crie o link para que o DenyHosts seja executado automaticamente durante o boot:

[alberto@mybox:/usr/share/denyhosts]$ ln -s daemon-control /etc/init.d/denyhosts
[alberto@mybox:/usr/share/denyhosts]$ update-rc.d denyhosts defaults

Agora, let's start:

[alberto@mybox:~]$ /etc/init.d/denyhosts start

Pronto! Seu DenyHosts está funcionando e bloqueando os hosts que estiverem tentando atacar seu servidor ssh por brute force.

Faça um teste: Tente se conectar localmente por ssh com algum usuário inexistente por umas 5 vezes (valor padrão de DENY_THRESHOLD_INVALID) e depois verifique o arquivo /etc/hosts.deny ou o log do DenyHosts (/var/log/denyhosts) para ver o que acontece.

O arquivo de configuração /usr/share/denyhosts.cfg é muito simples e bem comentado. Vale a pena dar uma lida e aprimorar as suas configurações.

Comente, sugira, critique ou corrija.

That's all folks!

CIGE - Centro Integrado de Guerra Eletrônica

Histórico

A 19 de março de 1984, foi criado o Núcleo de Implantação do Centro de Instrução de Guerra Eletrônica.

Instalado, em 10 de março de 1989, o então Centro de Instrução de Guerra Eletrônica (CIGE) especializou em Guerra Eletrônica (GE), naquele ano, as primeiras turmas de oficiais e sargentos.

Com a mudança de denominação para Centro Integrado de Guerra Eletrônica (CIGE), ocorrida em 30 de abril de 1998, a Unidade manteve a sigla tradicional e adotou uma denominação coerente com sua evolução.

A missão do CIGE é a formação de recursos humanos nos sistemas de GE. Para tal, faz uso dos seguintes vetores: ensino, tático, manutenção, suprimento e administração.

Principais Atividades

A Divisão de Ensino do CIGE, que materializa o vetor de ensino, ministra diversos cursos de especialização e extensão de GE para oficiais e sargentos do Exército e das Forças Singulares, atuando, inclusive, nos C Mil A, com estágios de área de GE. Fornece, ainda, subsídios ao EME para a elaboração e o aperfeiçoamento da doutrina de GE.

A 1ª Cia GE, que materializa o vetor tático, participa de manobras nos diferentes C Mil A, sob a coordenação do COTer, e, ainda, realiza demonstrações do emprego do seu material em cooperação de instrução proporcionada pelo CIGE.

A Divisão de Engenharia e Logística, que materializa o vetor de manutenção/suprimento, é responsável pela manutenção e suprimento do material de GE.

O CIGE atende, anualmente, cerca de 50 pedidos de cooperação de instrução oriundos das três Forças Armadas, os quais são realizados na própria OM, em exercícios no terreno ou na OM solicitante.

Atualmente:

O Boletim do Exército N. 06/2007 de 9 de Fevereiro de 2007, através da Portaria N. 063-DCT, de 31 de Janeiro de 2007 "Aprova as Instruções Reguladoras para Criação de Estágio Setorial de Guerra Cibernética (IR-1309)".

Fontes:
http://www.exercito.gov.br/06OMs/centros/cige/indice.htm
http://www.cige.eb.mil.br/

Nikto - Web Server Scanner

No post de hoje quero apresentar uma excelente ferramenta de segurança. Trata-se do Nikto - um scanner de vulnerabilidades para web servers escrito em Perl muito interessante, rápido e simples de usar.
Uma característica muito peculiar do Nikto é que ele possibilita a atualização da sua base de dados de vulnerabilidades, bem como a atualização de seu próprio código!

Ambiente utilizado para o teste:

Debian Etch kernel 2.6.18-4
Perl 5.8.8
Net_SSLeay.pm-1.30
Nikto 1.36
Apache 1.3.34

Antes de começar a brincar eu tive que instalar a extensão Net_SSLeay.pm-1.30 para que o Perl pudesse utilizar OpenSSL. Simples assim:

$tar -xzvf Net_SSLeay.pm-1.30.tar.gz
$cd ./Net_SSLeay.pm-1.30
$perl Makefile.PL
$make
$make install

Agora, 'instalando' o Nikto:

$tar zxvf nikto-1.36.tar.gz
$cd nikto-1.36

A instalação basicamente se resume a isso. Todos os arquivos que o Nikto utiliza estão dentro dessa pasta, portanto, não faz diferença nenhuma a localização da mesma.

Antes de iniciarmos a utilização é interessante que façamos uma atualização, simples assim:

$./nikto.pl -update

E agora sim:

alberto@mybox:~$./nikto.pl -h localhost
---------------------------------------------------------------------------
- Nikto 1.36/1.39 - www.cirt.net
+ Target IP: 127.0.0.1
+ Target Hostname: localhost
+ Target Port: 80
+ Start Time: Fri May 25 02:49:13 2007
---------------------------------------------------------------------------
- Scan is dependent on "Server" string which can be faked, use -g to override
+ Server: Apache/1.3.34 (Debian)
+ Allowed HTTP Methods: GET, HEAD, OPTIONS, TRACE
+ HTTP method ('Allow' Header): 'TRACE' is typically only used for debugging--it should be disabled. Note, this does not mean the server is vulnerable to XST. OSVDB-877.
+ Apache/1.3.34 appears to be outdated (current is at least Apache/2.2.3). Apache 1.3.33 is still maintained and considered secure.
+ / - TRACE option appears to allow XSS or credential theft. See http://www.cgisecurity.com/whitehat-mirror/WhitePaper_screen.pdf for details (TRACE)
+ / - TRACK option ('TRACE' alias) appears to allow XSS or credential theft. See http://www.cgisecurity.com/whitehat-mirror/WhitePaper_screen.pdf for details (TRACK)
+ 2673 items checked - 2 item(s) found on remote host(s)
+ End Time: Fri May 25 02:49:19 2007 (6 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested
alberto@mybox:~$

Lembre-se que nem todos os items encontrados são problemas de segurança, pois alguns podem ser só avisos sobre algo que nem o administrador do web server (no caso VOCÊ) sabe que está presente no servidor. Mesmo assim, a maioria dos itens SÂO PROBLEMAS DE SEGURANÇA SIM! Eheh.

Conclusão

Rápido, customizável, atualizável e 100% software livre. Recomendo!

Happy Scanning!!

THC Hydra - Brute Force a rolé!

Dia desses revolvi desligar meu DenyHosts para ver o que acontecia. Depois disso fui dar uma olhada no meu /var/log/auth.log. A surpresa:

May 20 10:51:07 admin sshd[8236]: Did not receive identification string from 61.152.162.183
May 20 11:28:36 admin sshd[8301]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=61.152.162.183 user=root
May 20 11:28:38 admin sshd[8301]: Failed password for root from 61.152.162.183 port 47342 ssh2
May 20 11:28:38 admin sshd[8302]: Received disconnect from 61.152.162.183: 11: Bye Bye
May 20 11:28:41 admin sshd[8303]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=61.152.162.183 user=ftp
May 20 11:28:43 admin sshd[8303]: Failed password for ftp from 61.152.162.183 port 47666 ssh2
May 20 11:28:43 admin sshd[8304]: Received disconnect from 61.152.162.183: 11: Bye Bye

Num momento de ira! resolvi contra-atacar o tal "61.152.162.183", eheh. Saí buscando algo para fazer o 'talzinho' provar do próprio veneno. Foi quando encontrei a ferramenta THC - Hydra, desenvolvida por Van Hauser do THC.
O THC-Hydra pode ser classificado como um network logon cracker multiplataforma que faz ataques de força bruta contra uma gama considerável de serviços. Atualmente, na versão 5.4, os serviços suportados são:

SSH2, TELNET, FTP, HTTP, HTTPS, HTTP-PROXY, SMB, SMBNT, MS-SQL, MYSQL, REXEC, RSH, RLOGIN, CVS, SNMP, SMTP-AUTH, SOCKS5, VNC, POP3, IMAP, NNTP, PCNFS, ICQ, SAP/R3, LDAP2, LDAP3, Postgres, Teamspeak, Cisco auth, Cisco enable, LDAP2, Cisco AAA

Tem versões para Windows (Win32/Cywin), iPaq e Zaurus (handhelds com processadores ARM rodando Linux) e, claro, seu código fonte pode ser compilado em 'todas' as plataformas 'UNIX based'.
Minha aventura se desenrolou num Debian Etch, com Kernel 2.6.18-4, e o roteiro de instalação foi o seguinte:

- Pacotes Utilizados:

• *libssl0.9.6 (requisito para o pacote libssh0.11)

# Repositório para o apt:
# deb http://tinkerbell.dyndns.biz/debian woody main contrib non-free non-US

$apt-get update
$apt-get install libssl0.9.6

• *libssh0.11

http://0xbadc0de.be/libssh/libssh-0.11.tgz

$tar zxvf libssh-0.11.tgz
$cd libssh-0.11
$./configure && make && make install

• *Hydra 5.4

hydra-5.4-src.tar.gz
Encontrei alguns probleminhas na hora de compilar o Hydra, especialmente pq o Makefile não encontrava a biblioteca libssh.so e apresentava um crash no módulo Postgres. Resolvi alterando algumas variávies do Makefile produzido pelo ./configure e deixando assim:

(...)
XDEFINES= -DLIBOPENSSL -DLIBSSH
XLIBS= -lssl -lssh -lcrypto
XLIBPATHS=-L/usr/lib -L/usr/local/lib -L/lib -L/usr/lib -L/var/lib -L/lib -L /usr/include -L/usr/include/libssh
(...)

..depois disso:

$make && make install

Aí foi partir para o abraço. Olha o testdrive:

alberto@mybox:~$ hydra 127.0.0.1 -L file.txt -P file.txt ssh2
Hydra v5.4 (c) 2006 by van Hauser / THC - use allowed only for legal purposes.
Hydra (http://www.thc.org) starting at 2007-05-23 01:13:00
[DATA] 4 tasks, 1 servers, 4 login tries (l:2/p:2), ~1 tries per task
[DATA] attacking service ssh2 on port 22
[STATUS] attack finished for 127.0.0.1 (waiting for childs to finish)
[22][ssh2] host: 127.0.0.1 login: admin password: mypass
Hydra (http://www.thc.org) finished at 2007-05-23 01:13:08
alberto@mybox:~$

Onde:
hydra 127.0.0.1 -> Meu alvo (eu mesmo)
-L file.txt -> Wordlist de usuários que eu usei
-P file.txt -> Wordlist de senhas que eu usei
ssh2 -> Serviço atacado.

Lembrando que um 'hydra -h' apresenta um help bem didático com todas as opções.
Agora é com você. Use para fins didáticos e não siga meu exemplo de contra-atacar seus atacantes, eheh.

Conclusão
O THC-Hydra é a melhor ferramenta para ataques de força bruta que eu tive acesso até hoje. Desempenho satisfatório, multiplataforma, váááárias opções interessantes, desenvolvimento constante e código 100% aberto.
Aprenda a usar e use...antes que alguém o faça em seus servidores por você.

Start

$init 5