Fazia algum tempo que não utilizava esse excelente scanner de vulnerabilidades. Resolvi instalar a versão mais atual (3.0.6), e daí a começar a brincar com a Nessus Attack Scripting Language – NASL – foi um pulo. A linguagem é parecida com Ce já possui uma série de bibliotecas e funções prontas para uso, e com ótimo suporte à expressões regulares.

Criei um script que checa se o servidor apache2 está fornecendo mais informações do que deveria. Por exemplo, a instalação padrão no etch forneceria as seguintes informações:

#lynx -dump -head http://alvo.com.br | grep Server
Server: Apache/2.2.3 (Debian) PHP/5.2.0-8+etch7

Dessa forma já saberíamos qual a versão do apache, qual o S.O, e a versão do php instalada. Isso diminui drasticamente o número de exploits que um possível invasor teria que testar.

Um servidor bem configurado deveria exibir pouquíssimas informações:

lynx -dump -head http://alvo.com.br | grep Server
Server: Apache

Seria um gnu/linux? Um BSD? Windows? E qual versão? Teria php habilitado?

Você pode baixar o plugin aqui. Basta adicioná-lo na pasta de plugins do nessus (/opt/nessus/lib/nessus/plugins/), e iniciar o nessusd com a opção -t, para que ele reescaneie a pasta (nessusd -t -D).

Pretendo criar alguns plugins para checar minha rede interna, mas vou publicando-os aqui a medida que estiverem disponíveis, até porque os mesmos são licenciados sobre GPL. 

O terceiro vídeo chama-se Spam e mostra desde a origem desta palavra até os tipos mais atuais de lixo virtual, como spim (Spam via instant messenger) e até mesmo spit (spam via telefonia ip).

Já o quarto vídeo, A Defesa, mostra a importância da proteção na internet, com o uso de firewall pessoais, antivirus e sistemas antispam. Também alerta ao usuário sobre a questão da atualização dos programas: de nada adianta um antivirus se ele está desatualizado. É até pior, pois dá uma falsa sensação de segurança. Além disso, dá algumas dicas sobre privacidade na internet e melhores práticas de navegação.

Os vídeos estão disponíveis no formato wmv e mov, mas infelizmente em nenhum formato livre. Além disso, são três resoluções diferentes para download: 320×240, 480×360 e 640×480.

Já enviei um email ao grupo de trabalho antispam do CGI.br sugerindo que eles também liberem tais vídeos em ogg theora. Aproveite e também faça esta sugestão.

Sucesso total. Na verdade, fiquei impressionado. Apesar dos problemas técnicos que levaram ao atraso da palestra em 20 minutos, a sala estava completamente lotada. Inclusive os corredores laterais, com as pessoas sentando no chão. Alguns amigos inclusive me reclamaram depois dizendo que não conseguiram ver a palestra porque o segurança não deixou, devido a quantidade de gente na sala. Que bom que o tema despertou tanta atenção.
Ela também foi transmitida pela internet via TV Software Livre, e pelo que algumas pessoas me disseram, nessa hora o streaming estava funcionando e elas conseguiram ver.

A gravação deverá estar pronta e liberada pela organização em alguns meses. Quando eu a tiver, liberarei aqui também.
Falando um pouco da palestra, minha intenção foi traçar um paralelo entre as orientações feita por Sun Tzu no livro A arte da guerra e as atividades de um Administrador de Sistemas. Segue a descrição que costumo dar, ao submeter a palestra ou ser convidado para algum evento:

Ao escrever no Sec IV A.C A Arte da Guerra, Sun Tzu visava instruir sobre como o Estado poderia prosperar através da guerra. Nos dias de hoje, as citações de Sun Tzu deixaram de atuar apenas na esfera militar, passando a atuar também em uma guerra diferente, mas igualmente perigosa: a guerra na internet.

Esta palestra tem por objetivo – através da filosofia contida na Arte da Guerra – descrever como Administradores de Sistemas podem vencer suas batalhas diárias na internet construindo ambientes seguros utilizando Software Livre.

Enquanto não sai o vídeo, estou disponibilizando os slides da palestra. Para baixá-los, basta clicar no link abaixo. A licença de utilização é a Gnu FDL, sem seções invariantes.

A arte da guerra para Administradores de Sistemas

Se você a assistiu alguma vez, deixe seu comentário! Ele poderá ser aproveitado na próxima vez que eu der esta palestra, ou mesmo em outra apresentação.

A lista conta com uma explicação sobre cada ferramenta, mostrando o porquê de sua escolha.

O destaque fica por conta do projeto brasileiro OSSEC HIDS, seguido pelo já conhecido Snort.

Nosso primeiro artigo irá tratar de um dos serviços mais usados pelos sysadmins em seu dia-a-dia: O serviço SSH. Geralmente presente em todas as instalações de sistemas operacionais livres, o serviço ssh é responsável por permitir acesso remoto e criptografado a servidores geograficamente distribuídos.

Muitos administradores, contudo, acham que por se tratar de um serviço que utiliza criptografia tanto na autenticação do usuário quanto em todo o trafégo não seja necessário realizar nenhuma configuração adicional. Ledo engano. Desde ataques de força bruta em senha a coisas mais sofisticadas como “homem no meio”. Vejamos algumas medidas simples – mas eficientes – de prevenção.

Iremos implementar as seguintes funcionalidades:

• proibir o login como super-usuário;
• Utilizar apenas a versão 2(mais segura) do protocolo SSH;
• Alterar a porta padrão (22) para uma outra qualquer;
• Aplicar restrições de login: tempo de inatividade, utilização de PAM, etc;
• Liberar acesso apenas para usuários específicos. Assim, você pode se certificar que apenas os administradores conseguirão logar no servidor;
• Verificação de DNS;
• Permitir login apenas de certos hosts de origem;
• Bloquear as demais conexões;

Fase 1: configuração do daemon ssh

Abra com o seu editor preferido o arquivo de configuração do serviço ssh. No Debian, ele se encontra em /etc/ssh/sshd_config.
Adicione ou altere as seguintes linhas:

#proibir login como root
PermitRootLogin no

#Usar apenas o protocolo versão 2.
Protocol 2

#alterar a porta padrão para 444
Port 444

#restringir o endereco de escuta
ListenAddress #(endereço ip a ser utilizado para requisições ssh)

# restrições de login
LoginGraceTime 1m
PasswordAuthentication no
UsePAM yes
AllowUsers (usuario_ssh1) (usuario_ssh2)

PrintMotd no
UseDNS yes

Fase 2: Liberar apenas hosts de origem específicos

No arquivo /etc/hosts.allow, devemos liberar apenas os hosts que deverão ter acesso ao serviço ssh. Acrescente a seguinte linha, substituindo os valores para o endereço ip e a máscara do host a ser liberado:

sshd: ip/mascara

No arquivo /etc/hosts.deny, iremos bloquear as demais conexões. Acrescente a seguinte linha:

sshd: ALL

Fase 3: Alterando a porta padrão

Para que o tcp wapper reconheça a nova porta do ssh (no caso, alteramos para 444), devemos editar o arquivo /etc/services
e alterar a seguinte linha:

ssh 444/tcp

Fase 4: Aplicando as alterações

Para que as alterações tenham efeito, é necessário reiniciar o daemon ssh, com o comando:
/etc/init.d/ssh restart

Pronto! Seu servidor SSH agora está bem mais seguro. Caso você conheça alguma outra funcionalidade que possamos implementar, deixe seu comentário!

Na próxima semana teremos um artigo sobre os principais pontos a serem observados durante a instalação de um servidor. Fique ligado!

O Tor é um framework para navegação anônima, desenvolvido pela Eletronic Frontier Foundation, que permite a pessoas e a organizações aumentar a sua privacidade na Internet.

Como o pacote tor está disponível apenas para a versão sid do Debian, neste artigo veremos como gerar nosso próprio pacote para o Etch, a partir dos fontes.

• Obtendo os arquivos necessários

Baixe os seguintes arquivos:

- tor_0.1.1.26-1.dsc

- tor_0.1.1.26.orig.tar.gz

- tor_0.1.1.26-1.diff.gz

Para satisfazer as dependências, será necessário instalar alguns pacotes:
aptitude install debhelper tsocks fakeroot libssl-dev dpatch zlib1g-dev libevent-dev tetex-bin tetex-extra transfig gs binutils

• Gerando o pacote

Feito isso, digite:
dpkg-source -x tor_0.1.1.26-1.dsc
cd tor-0.1.1.26
dpkg-buildpackage -rfakeroot -uc -us

Será então gerado um pacote chamado tor_0.1.1.26-1_i386.deb . Instale-o com o comando:
dpkg -i tor_0.1.1.26-1_i386.deb

• Configurações necessárias

Adicionalmente iremos precisar instalar um proxy chamado privoxy. Faça isso com o comando:
aptitude install privoxy

Edite o arquivo /etc/privoxy/config, acrescentando a seguinte linha no início do arquivo:
forward-socks4a / 127.0.0.1:9050 .

Atenção para o ponto no final da linha, que é necessário.

reinicie o privoxy e o tor com o comando:
/etc/inti.d/privoxy restart
/etc/inti.d/tor restart

• Configurando aplicações para utilizarem o tor

Firefox

Para configurar o firefox, instale a extensão Torbutton. Ela irá exibir um botão no canto inferior direito, permitindo habilitar ou desabilitar o recurso, sem necessidade de reiniciar o navegador.

Importante: A velocidade de navegação no firefox ficará bem mais lenta. Nos meus testes, com um link de 8MB, ficou parecendo uma conexão de 56k discada. Com uotros aplicativos texto, como o gaim e o xchat, não tive problemas com velocidade.
Xchat

Acesse o menu Configurações/Preferências/Rede/configuração de Rede. Na seção Servidor proxy, informe os seguintes parâmetros:
Host: 127.0.0.1
Porta: 9050
Tipo: Socks5

Para verificar como configurar outras aplicações, acessa essa lista.

• Resumo

Para quem tem necessidade de navegar anonimamente na internet, esta é uma excelente solução. Para quem tem necessidade de ocultar seu ip de olhares curiosos também. Porém não compensa utilizá-la para ler o seu bloglines, por exemplo. Aproveito para agradecer ao Enerv pela ajuda com a construção do pacote. Faça seus testes, e poste um comentário sobre!

Iremos dar um passo à frente, utilizando o smartcard para autenticar em nossos servidores, via ssh. Este procedimento aumenta sobremaneira a segurança, acrescentando o elemento “o que eu tenho” como camada de validação.

É possível inclusive configurar o servidor SSH para aceitar apenas conexões que possuam determinada chave, além de acrescentar uma “passphrase” para cada chave.

• Configurando o gpg-agent

crie o arquivo /etc/X11/xsession.d/90gpg-agent com o seguinte conteúdo:

: ${GNUPGHOME=$HOME/.gnupg}fsfe fellowcard
GPGAGENT=/usr/bin/gpg-agent
PID_FILE=”/tmp/gpg-agent-info-$(hostname)-$USER”
if grep -qs ‘^use-agent’ “$GNUPGHOME/gpg.conf” “$GNUPGHOME/options” &&
test -x $GPGAGENT &&
{ test -z “$GPG_AGENT_INFO” || ! $GPGAGENT 2>/dev/null; }; then
if [ -r "$PID_FILE" ]; then
. “$PID_FILE”
fi
# Invoking gpg-agent with no arguments exits successfully if the agent
# is already running as pointed by $GPG_AGENT_INFO
if ! $GPGAGENT 2>/dev/null; then
$GPGAGENT –pinentry-program /usr/bin/pinentry-gtk-2 –default-cache-ttl 43200 –enable-ssh-support –write-env-file $HOME/.gpg-agent-info –daemon –sh >”$PID_FILE”
. “$PID_FILE”
fi
fi

Será necessário finalizar o gpg-agent e reiniciar o X. Em seguida, verifique se o agent está rodando com suporte a ssh, com o comando:
$ps xau | grep agent

A saída deve ser parecida com essa:

ederm 4139 0.0 0.1 2568 696 ? Ss Oct30 0:00 /usr/bin/gpg-agent –pinentry-program /usr/bin/pinentry-gtk-2 –default-cache-ttl 43200 –enable-ssh-support –write-env-file /home/ederm/.gpg-agent-info –daemon ?sh

• Importando a chave para os servidores

Iremos agora exportar a chave armazenada em nosso smartcard para os servidores, de modo que possamos realizar a autenticação via chaves/passphrase.

Para listar sua chave, digite:
$ssh-add -l
gere o arquivo de exportação com o comando:
$ssh-add -L > ~/.ssh/id_rsa.pub

Vamos agora exportar nossa chave para os servidores. Para isso, digite o comando:
$ssh-copy-id -i ~/.ssh/id_rsa.pub usuario@servidor

Informe a senha do usuário. A saída do comando deverá ser parecida com a abaixo:
Password:
Now try logging into the machine, with “ssh ‘frolic@crux’”, and check in:
.ssh/authorized_keys
to make sure we haven’t added extra keys that you weren’t expecting

Quando você tentar logar novamente o servidor irá solicitar o seu PIN através do programa pinentry. O programa gpg-agent se encarregará de deixar o seu PIN em memória (protegida), para que não seja necessário fornecer o PIN toda vez que você logar.
E assim implementamos um sistema de autenticação seguro e prático.

Gostaria de agradecer novamente a Nanda pela ajuda com os problemas que apareceram, até que a solução funcionasse a contento.

Leia também: Configurando o gpg para suporte a smartcards no Debian

Configuração da leitora de cartões

Iremos utilizar a leitora de cartões SCM SRC335 usb, bem suportada pelo gnupg. Como o sistema udev do Debian Sarge é muito antigo, vamos utilizar o Etch, que está bem próximo de ser lançado com estável. Abaixo segue a lista de pacotes utilizados:

• Kernel 2.6.18-3-686;
• udev (0.103-1)
• gnupg (1.4.6);
• gnupg-agent (2.0.0-5.2);
• gnupg2 (2.0.0-5.2);
• gpgsm ( 2.0.0-5.2);
• pinentry-curses ( 0.7.2-3);
• pinentry-gtk2 ( 0.7.2-3);

logado como root, crie um arquivo chamado gnupg-ccid.rules, dentro de /etc/udev/, com o seguinte conteúdo:

# GPG SmartCard Reader Support
ACTION!=”add”, GOTO=”gnupg-ccid_rules_end”
# USB SmartCard Readers
## SCM readers (SCR335, SPR532, & Co)
ACTION==”add”, SUBSYSTEM==”usb_device”, SYSFS{idVendor}==”04e6″, SYSFS{idProduct}==”e001″, GROUP=”scard”, MODE=”0660″
ACTION==”add”, SUBSYSTEM==”usb_device”, SYSFS{idVendor}==”04e6″, SYSFS{idProduct}==”e003″, GROUP=”scard”, MODE=”0660″
ACTION==”add”, SUBSYSTEM==”usb_device”, SYSFS{idVendor}==”04e6″, SYSFS{idProduct}==”5115″, GROUP=”scard”, MODE=”0660″
# PCMCIA SmartCard Readers
## Omnikey CardMan 4040
SUBSYSTEM==”cardman_4040″, GROUP=”scard”, MODE=”0660″
LABEL=”gnupg-ccid_rules_end”

Em seguida, crie um link simbólico para este arquivo com o comando:

#ln -s /etc/udev/gnupg-ccid.rules /etc/udev/rules.d/gnupg-ccid.rules

Precisamos agora criar um grupo chamado scard:

#addgroup scard

#addgroup scard (substitua por seu usuário)

Pronto! Seu smartcard está configurado!

Configurando o gnupg

Agora vamos configurar o gnupg para utilizar o smartcard. Edite o arquivo gpg.conf, dentro do diretório $HOME/.gnupg, e ensira a seguinte linha:

use agent

É necessário reiniciar a sessão do usuário, para que as modificações entrem em vigor. Para testar, execute o seguinte comando:

$gpg –card-status

A saída deve parecer com isso:
card reader
Application ID …: D4760001234101010001000101E70101
Version ……….: 1.1
Manufacturer …..: PPC Card Systems
Serial number ….: 000004B2
…

Criando as subchaves

Esta parte você pode acompanhar passo-a-passo aqui. Atente principalmente para o processo de criação dos “stubs”. Enquanto não traduzimos para pt-br a documentação oficial do gnupg, essa será o sua fonte de pesquisa principal.

Utilizando seu smartcard

Tenha em mente o seu PIN number, e seu ADMIN PIN. Ao errar três vezes seu PIN, este só poderá ser desbloqueado com o ADMIN PIN. Caso este seja informado erroneamente três vezes, seu smartcard ficará inutilizável.

O programa pinentry ficará responsável por solicitar o PIN quando formos utilizar o cartão.

Gostaria de agradecer ao Georg Greve a Fernanda Weiden pela ajuda com a configuração, que realmente deu um pouco de trabalho.

Veja a parte 2 deste artigo: configurando suporte a SSH no gnupg via Smartcard