Este documento fornece uma visão geral dos passos para instalação e configuração do TRAIRA, uma ferramenta desenvolvida pelo CERT.Bahia para auxiliar os CSIRTs no tratamento de incidentes de segurança. Para uma descrição detalha do TRAIRA, motivação, fundamentação e arquitetura, recomendamos a leitura do artigo TRAIRA: Tratamento de Incidentes de Rede Automatizado.
Os seguintes passos serão necessários para implantação da ferramenta em uma instituição:
Os passos abaixo foram realizados em uma máquina executando o Debian Squeeze, já com servidor web configurado (Apache2) e também com o SGBD PostgreSQL 8.4 em funcionamento.
Para implantação do TRAIRA os seguintes pré-requisitos devem ser satisfeitos:
Suporte à logging no dispositivos de NAT
O TRAIRA já foi testado com o ASA/Cisco (firewall comercial da Cisco) e com IPTables/Netfilter
(firewall nativo do Kernel do Linux). Caso você utilize outro firewall, temos todo o interesse em
integrar o TRAIRA com essa ferramenta. Assim, por favor, entre em contato conosco.
Servidor de gerência
É recomendado que o TRAIRA seja instalado no servidor de gerencia da rede, pois geralmente o acesso
a esse servidor é mais controlado e, por outro lado, ele tem acesso à maioria dos equipamentos ativos
de rede da instituição. Sobre as características de hardware do servidor, não existe uma recomendação
sobre qual tecnologia deve ser usada ou em que quantidade, porém o uso de hardware com poder de
processamento maior irá refletir no tempo de resposta do tratamento de um incidente. Nesse sentido, um
recurso que merece atenção especial é o armazenamento do servidor: a depender de por quanto tempo
deseja-se salvaguadar os logs das traduções NAT, deve-se dimensionar o disco da máquina em concordância;
além disso, a velocidade de leitura/escrita do disco influi diretamente no desempenho das consultas aos logs
(realizadas com muita frequência).
Banco de dados
Tanto o RT quanto o L2M requerem a utilização de um banco de dados para armazenar suas
informações. O RT pode funcionar com diversos bancos. Já o L2M suporta apenas PostgreSQL. Dessa forma,
recomenda-se a utilização do PostgreSQL para diminuir a mão de obra de manutenção de duas SGBDs distintos.
Como pode-se ver acima, o TRAIRA possui pré-requisitos simples de serem satisfeitos, viabilizando sua implantação em ambientes diversos.
Passo-a-passo para instalação do RT no Debian Squeeze
Passo-a-passo para instalação do L2M
Geralmente o dispositivo responsável por realizar a Tradução de Endereços de Rede (NAT) é o equipamento de firewall (filtro de pacotes). É necessário que esse equipamento possa registrar em arquivos de logs as traduções realizadas, principalmente as seguintes informações:
Dessa maneira, consulte a documentação do firewall que você utiliza, a fim de obter o passo-a-passo necessário para habilitar o logging das traduções NAT. Abaixo apresentamos os passos necessários para realizar essa configuração no IPTables/Netfilter, o firewall nativo do GNU/Linux.
NFCT-SNATLOG: habilitando o logging das traduções NAT do IPTables/Netfilter
Os passos abaixo mostram como instalar e configurar o TRAIRA (uma extensão do RT) na máquina de gerência (na qual os requisitos acima já foram cumpridos) que será usada no processo de tratamento de incidentes de segurança.
Faça o download do pacote do TRAIRA:
wget http://www.pop-ba.rnp.br/files/sw/traira/TRAIRA-rt3.8.tgz
Descompacte o TRAIRA no diretório raiz do RT. No exemplo abaixo vamos supor que o RT foi instalado em “/usr/share/request-tracker3.8” (instalação Debian típica):
tar -xzf TRAIRA-rt3.8.tgz -C /
chown -R root.root /usr/share/request-tracker3.8
É necessário reiniciar o apache para que o perl recarregue seus objetos (o Mason, usado para a interface do RT faz cache dos objetos):
/etc/init.d/apache2 restart
Caso o TRAIRA tenha sido instalado corretamente, você terá uma nova opção nos menus do RT,
conforme pode ser visto na imagem abaixo.
O TRAIRA estará acessível no menu principal do RT (menu à esquerda) ou através de
Ferramentas > TRAIRA. As configurações necessárias serão listadas abaixo.
O primeiro passo é criar um fila que será usada para o tratamento de incidentes. Para isso, acesse o menu Configuração > Filas > Criar e informe as seguintes informações (valores sugeridos, você deve adaptá-los à sua instituição):
Além de criar a fila, gostaríamos de permitir a criação de chamados via e-mail. Para isso, precisaremos editar o arquivo /etc/aliases no servidor em que o RT está configurado e acrescentar o seguinte (remove as entradas anteriores referentes ao alias security caso existam):
security: "| /usr/bin/procmail -a Security -a correspond"
security-comment: "| /usr/bin/procmail -a Security -a comment"
Não esqueça de executar o newalias para gerar os aliases acima:
newaliases
OBS: atente-se para o domínio do e-mail que será criado. Você provavelmente precisará definir algum meio de transporte para essa conta no servidor de e-mail de sua instituição. Porém essa configuração está fora do escopo desse tutorial (se tiver dificuldade, não hesite em nos contactar).
Perceba que na configuração de aliases acima, a mensagem é repassada ao procmail. Isso permite definirmos alguns filtros para restringir a criação de chamados de incidente de segurança na fila do RT. É possível, por exemplo, filtrar para que apenas as origens A e B possam abrir chamados na fila de segurança criada acima; dentre outros filtros.
# mais informacoes: procmailrc(5) LOGFILE=/var/log/procmail.log DEBUG=yes FILA="$1" ACAO="$2" :0 * FILA ?? Security * ACAO ?? (correspond|comment) #* ^From:.*(incidentes@pop-ba.rnp.br|security@ufba.br) | /usr/bin/rt-mailgate --timeout 0 --queue ${FILA} --action ${ACAO} --url https://localhost/rt/
Na configuração acima, pode-se restringir a criação de chamados apenas para os e-mails e Veja, entretanto, que essa configuração não está ativa, pois a linha está comentada (a linha começa com “#”).
O próximo passo é dar permissão para que qualquer usuário possa criar chamados nessa fila (um controle de acesso mais restritivo pode ser feito no procmail). Para isso, acesse o menu Configuração > Filas > Segurity > Direitos de Acesso do Grupo, no grupo “Todos” adicione a permissão “CriarTiquete” (basta selecionar essa opção e clicar em Salvar no rodapé da página).
Em seguida, vamos informar as configurações básicas do TRAIRA, para isso acesse o menu Ferramentas > TRAIRA > Configuracao e preencha os seguintes campos:
Com os parâmetros acima, já termos uma configuração funcional do TRAIRA. O próximo passo é criar os parsers por tipo de notificação. Abaixo vamos ilustrar a criação de um parser para notificações do CERT.Bahia, que se assemelham ao e-mail abaixo:
From: CERT.BahiaTo: security@instituicao.dominio.tld Subject: Ataque ssh-brute force com origem em 192.168.88.34 Prezados senhores, O CERT.Bahia detectou tentativas de ataque de força bruta no serviço SSH oriundos hosts da faixa de endereçamento sob sua responsabilidade. Solicitamos que o incidente seja investigado e as medidas cabíveis sejam tomadas. Solicitamos ainda que nos respondam a essa notificação com informações sobre o tratamento realizado. A lista de tuplas abaixo contém o ASN de origem, IP de origem, porta de origem e data/hora em que o incidente ocorreu, todos eles separados pelo caractere pipe ("|"). 53164 | 192.168.88.34 | srcport 4246 | 2012-01-20 12:01:26 (GMT-3) 53164 | 192.168.88.34 | srcport 4248 | 2012-01-20 12:01:26 (GMT-3) 53164 | 192.168.88.34 | srcport 1135 | 2012-01-20 12:01:55 (GMT-3) 53164 | 192.168.88.34 | srcport 1148 | 2012-01-20 12:01:55 (GMT-3) 53164 | 192.168.88.34 | srcport 2855 | 2012-01-20 12:05:10 (GMT-3) 53164 | 192.168.88.34 | srcport 2853 | 2012-01-20 12:05:10 (GMT-3) 53164 | 192.168.88.34 | srcport 1267 | 2012-01-20 12:06:25 (GMT-3) 53164 | 192.168.88.34 | srcport 1751 | 2012-01-20 12:06:42 (GMT-3) 53164 | 192.168.88.34 | srcport 2148 | 2012-01-20 12:06:59 (GMT-3) 53164 | 192.168.88.34 | srcport 2623 | 2012-01-20 12:09:25 (GMT-3) 53164 | 192.168.88.34 | srcport 1242 | 2012-01-20 12:17:23 (GMT-3) 53164 | 192.168.88.34 | srcport 3323 | 2012-01-20 12:18:30 (GMT-3) 53164 | 192.168.88.34 | srcport 1513 | 2012-01-20 12:21:45 (GMT-3) 53164 | 192.168.88.34 | srcport 1852 | 2012-01-20 12:22:00 (GMT-3) 53164 | 192.168.88.34 | srcport 2379 | 2012-01-20 12:22:14 (GMT-3) -- Atenciosamente, Grupo de Resposta a Incidentes de Seguranca da Bahia/Brasil http://certbahia.pop-ba.rnp.br Tel.: +55 71 3283-6098 / 3283-5693 E-mail: certbahia@pop-ba.rnp.br Chave GPG: http://www.pop-ba.rnp.br/files/certbahia.asc
Vamos então criar um parser para tratar as notificações do tipo acima. Para isso, acesse o menu Ferramentas > TRAIRA > Parsers e preencha os seguintes campos em “Criar/Editar/Remover um parser”:
my $SPC = '[[:space:]]'; my $IP = '[09.]{7,15}'; my $DATE = '[09]{10}'; my $TIME = '[09:]{8}'; my $PORT = '[09]+'; if ($line =~ /^53164$SPC\|$SPC($IP)$SPC\|${SPC}srcport$SPC($PORT)$SPC\|$SPC($DATE)$SPC($TIME)\b.*$/ ) { my ($date, $time) = $self>AdjustTimezone($3, $4, '0300'); return ($date, $time, $1, $2); } return undef;
Configuração do bloqueio automático
Uma possibilidade de configuração no TRAIRA é o bloqueio automático de hosts identificados como responsáveis por um incidente de segurança. Para entender melhor como esse bloqueio funciona, recomendamos a leitura do artigo “Tratamento Automatizado de Incidentes de Segurança da Informação em Redes de Campus”, seção 3.3 (veja aqui).
Para habilitar o bloqueio automático, acesse o menu Ferramentas > TRAIRA > Acoes e na seção de “Contencao” marque a opção “Bloquear Host”.
Testando a configuração
Para validar a configuração acima, você precisará gerar um tráfego para algum dispositivo externo à sua rede e que você possa monitorar as conexões. Então, sumarizar as conexões a esse host em um e-mail e submetê-lo ao TRAIRA (no formato TCPDUMP, por exemplo — lembre-se também de criar um parser para tal notificação), a fim de testar se ele consegue identificar a máquina interna que gerou de fato aquele tráfego (e se ela será bloqueada automaticamente, caso você tenha habilitado essa opção).