Explorar E-books
Categorias
Explorar Audiolivros
Categorias
Explorar Revistas
Categorias
Explorar Documentos
Categorias
www.linuxforce.com.br
NIDS
A norma diz no item 10.10.2, que deve haver um controle das tentativas de acesso
a rede. Portanto, caso haja esse tipo de tentativa indevida, será gerado um relatório
para uma suposta análise.
Podemos usar o Snort que é a mais popular ferramenta de NIDS. No caso, vamos
3
Linux Force – www.linuxforce.com.br
trabalhar com Snort com suporte a MySQL. Pois o Snort pode gravar os logs dele
em arquivos texto, que é muito complicado para se analisar, ou ele pode gravar em
um base de dados, para usarmos uma ferramenta Web para analisar os Logs, que é
muito mais viável.
2 - Pré-processadores - São partes do Snort, que são responsáveis por fazer uma
pré análise do pacote, para tentar diminuir os falsos positivos. O Snort tem muitos
pré-processadores, vamos ver alguns depois, mas uma referencia completa, pode
ser vista no site oficial:
http://www.snort.org/docs/snort_htmanuals/htmanual_283/node49.html
Existem algumas coisas que dificultam a implantação, uma delas, e saber onde po-
sicionar o Snort na rede, e outra é como tratar os falsos-positivos, que acontecem
muito.
Vamos olhar a figura e ver onde o snort poderia ser posicionado na rede.
No Hub, quando uma máquina manda um pacote para outra, esse pacote é divulgado
para todas as portas do Hub, onde somente a máquina destino o recebe.
Com o Switch, o pacote só é enviado para a máquina destino, ou seja, o pacote não
é divulgado para todas as portas do Switch.
Se tivermos uma rede só com HUB’s, fica tudo tranquilo, pois é só eu ligar a máquina
com Snort em uma das portas e pronto, ele vai ouvir tudo o que passa nada rede.
No caso, o switch vai precisar ter suporte a Port Mirror, também conhecida como
Porta Espelho, é uma porta que quando configurada, recebe toda informação de
todas as outras portas. Essa função de Port Mirror, é encontrada em Switch’s geren-
ciáveis.
Olhando o slide, vamos analisar como fica a questão desse snort posicionado entre
o Firewall e o roteador.
Nesse caso, podemos usar o Snort com uma bridge(ponte), é muito simples fazer
isso. Nesse caso a máquina com snort tem que ter 3 placas, 2 que vão formar a
bridge e não vão ter IP’s, e uma terceira com IP para pode administrar a máquina.
1 # netstat - nlpt
O usuário root do MySQL vem por padrão sem senha, então, temos que definir uma
senha para esse usuário root do MySQL:
1 # mysql -u root -p
Na instalação, aparecerão duas telas de configuração, que podemos ver nos sli-
des:
No segundo vai perguntar se deseja configurar uma base de dados para o snort-
mysql gravar os logs. Podem responder SIM.
A base de dados foi criada. Agora precisamos criar as tabelas da base de dados,
quando instalamos o snort, ele traz o modelo das tabelas. Está no seguinte diretó-
rio:
Após isso, vocês podem conectar no MySQL e ver se as tabelas foram criadas:
1 # mysql -u root -p
1 # cd / etc / snort
2 # ls -l
Da linha 1 até a linha 13, nós temos as variáveis que Snort criar. Essa variáveis não
são usadas nesse arquivo, são usadas nas regras que vamos ver depois.
Nós temos que mudar a variável da linha 1, a HOME NET, ela não pode ficar como
any, isso causa muito falso-positivo, temos que definir qual é a nossa rede. Ficaria
assim:
Outra que precisamos mudar, é a da linha 2, a EXTERNAL_NET, ela sim pode ficar
com any:
Nas linhas 65 e 66, temos as regras de OUTPUT, a primeira, é para ele gravar os
logs nos formatos binários e textos, a segunda, nós precisamos completar ela, para
o Snort gravar na base de dados.
1 - O ideal que quando forem fazer o snort com mysql, que vocês criem um usuário
para fazer isso e não usem o usuário root do MySQL.
Da linha 67 até o final, é onde o Snort inseri as regras que ele vai utilizar, se a regra
não estiver dentro desse arquivo, ele não vai utilizar ela.
DEBIAN_SNORT_HOME_NET="192.168.200.0/24"
DEBIAN_SNORT_INTERFACE="eth0"
A primeira é a sua rede, e a segunda, é a interface que o Snort vai ouvir, isso tem
que estar configurado corretamente.
Após isso, podemos dar uma olhada nas regras dos snort:
1 # cd rules
2 # ls
Aqui estão as regras do Snort, depois vocês podem dar uma olhada nelas, elas são
bem fáceis de entender. No prepara-se antes da aula, tem um exemplo de como
criar uma regra para o Snort.
Quando vocês instalaram o Snort, ele não configurou a base de dados, logo ele
criou um arquivo chamado db-pending-config dentro de /etc/snort. Agora que a base
já está configurada, vocês podem apagar esse arquivo e iniciar o Snort:
1 # rm db - pending - config
2 # / etc / init . d snort start
3 # ps ax | grep snort
Para administrar o Snort, nós vamos usar uma ferramenta web chamada AcidBase,
para isso, vamos precisar instalar o Apache2 com suporte ao PHP5.
Instalem o Apache2:
O FQDN (Full Qualify Domain Name), é o nome do domínio ou IP que o Apache vai
trabalhar.
http://192.168.200.X
Agora vamos ver alguns procedimentos básicos, para deixar o Apache2 um pouco
mais seguro. Mas um dica muito importante. Se quiserem fazer um boa segurança
no Apache2, estudem o mod_security do Apache.
1 # cd / var / www
2 # rm -rf apache2 - default
3 http ://192.168.200. X / icons /
Vamos retirar a opção de Indexes para o diretório padrão do Apache2 e outros que
forem interessantes.
A opção Indexes, é a opção que mostra toda a estrutura de diretório da pasta, caso
não exista um arquivo index.html. Veja um exemplo no slide:
Retirem a opção:
Reparem que quando o site não tem um index.html, ou a página da algum erro, o
Apache mostra o banner dele, que contém qual é a versão dele, do sistema e outras
coisas.
Para desativar o banner, temos que mudar a seguinte opção no arquivo default:
1 ServerSignature Off
Mas isso não desativa o banner de um varredura com nmap por exemplo.
Após essas modificações, podemos reiniciar o apache e ver como fica a página no
browser:
Como a ferramenta que vamos usar é em PHP, vamos precisar instalar o PHP5 no
sistema, e o suporte ao PHP no Apache2.
1 extension = mysql . so
Ainda nesse arquivo, podemos mudar alguns parâmetros, para ajudar na prevenção
contra ataques de PHP Injection:
1 safe_mode = On
2 safe_mode_gid = On
AcidBase
O AcidBase é a ferramenta que será utilizada para visualizar os eventos de alerta que
serão gerados pelo Snort e gravados dentro do MySQL. Para funcionar, o Acidbase
depende do Apache com PHP que já foram instalados na aula passada.
Aparecerão algumas telas de configuração, como podem observar nos slides a se-
guir:
Ainda poderemos aumentar ainda mais a segurança desse arquivo. Para isso iremos
novamente mudar a permissão do arquivo para 400, onde só o root vai conseguir
ler.
Pessoal, com isso, qualquer máquina da rede vai poder acessar. O que podemos
fazer para criar uma certa segurança no acesso a essa página, ou a qualquer outra
página que consideramos importante em nosso servidor web?
Podemos usar o htaccess para criar uma página de autenticação, liberando usuário
e senha para quem precisar acessar. Postei mais um documento sobre htaccess no
preparando-se para aula.
Para que o apache consiga trabalhar com o AcidBase, vamos ter que criar um link
simbólico para dentro da pasta conf.d do Apache2:
http://192.168.200.X/acidbase
Temos que clicar na opção Setup page, pois faltam alguns procedimentos para o
AcidBase começa funcionar.
Quando clicarmos em Setup page, nós vamos para um página onde será necessário
criar novas tabelas para o AcidBase, temos que clicar no botão Create BASE Ag,
igual ao slide:
Após isso vai aparecer que as tabelas foram criadas com sucesso.
Nessa página podemos ver que Snort já está capturando pacotes, que já está re-
gistrando informações. No Acibase podemos ver todos os eventos do Snort, e fazer
filtros por datas, horário, IP que estão atacando e vários outros tipos. É uma ferra-
menta que da para perder um bom tempo mexendo nela.
Reparem no Total Number of Alerts. Ali são todos os alertar que ele gerou até agora.
Se clicarmos no número, ele vai nos levar para uma página detalhando os eventos,
como está que está no slide:
Em cada uma dessas linhas nos temos o ID, que é o número que identifica o pa-
cote recebido, o signature que é a assinatura conforme a regra do snort ou o pré-
processador, o TimeStamp que é o horário que aconteceu o evento, IP’s de origem e
destino e por último o protocolo tipo TCP, UDP ou qualquer outro.
O bacana do signature, é que quando o evento foi gerado pelo pré- processador, ele
identifica que foi por ele. Como no exemplo:
snort - Se clicado, direciona para o site do snort. Não é muito bom, mas traz algumas
informações.
local - Nesse momento, elas não vão funcionar se clicarmos, só vamos ter elas,
depois que atualizarmos as regras do Snort, vamos fazer isso depois. Mas elas
trazem boas informações, inclusive quando pode ser falso-positivo.
nessus - Se clicado, leva para o site do nessus, que é uma outra ferramenta que
vamos ver. A ferramenta é muito boa, mas as referencias do site não.
BID (Bugtrack ID) - Se clicado, leva para o site do securityfocus.org. Essas são
referencias muito boas, bem explicadas. O diferencial desse site, é que se existe um
exploit para explorar deterimada falha, ele traz também.
CVE/CAN - Se clicado, leva para o site cve.mitre.org, onde também traz boas infor-
macões sobre as vulnerabilidades.
Os dois últimos são os que trazem as melhores informações. Tudo isso é para nos
deixar informados sobre as vulnerabilidades.
A melhor coisa a se fazer quando instala o Snort, é deixar ele capturando os pa-
cotes da rede por um dia. Depois disso, analisar os eventos, e comecar a verificar
se são possíveis falsos positivos ou não, para depois fazer alguns ajustes nos pré-
processadores ou nas regras.
Você está usando autenticação via htaccess no Apache2, pois você só quer que
algumas pessoas tenham acesso ao AcidBase. E em outro servidor, você tem o
servidor de webmail que também tem autenticação, mas não htaccess. Mas existe
um grande problema de segurança aqui:
O grande problema é que a porta 80 http trafega tudo em Clear Text (Texto Claro),
ou seja, tudo que for capturado por um sniffer nessa comunicação, será mostrado as
claras, usuários, senhas, tudo.
Quando vamos trabalhar com SSL, precisamos ter uma Chave Privada, e um Cer-
tificado. Se a sua empresa é uma instituição que vai liberar algum serviço para os
clientes, é muito importante que ela tenha um certificado assinado por uma empresa
Certificadora como a Verisign (http://www.verisign.com.br/), pois é uma certificadora
reconhecida em todos os browsers.
Mas como vamos fazer algo que para os funcionários da empresa, nós mesmos
1 # apache2ctl -M
1 # a2emod ssl
Quando o SSL está ativado, o apache precisa trabalhar na porta 443. Ele pode
trabalhar na 80 e na 443 ao mesmo tempo, mas vamos deixá-lo somente na 443.
Para gerar o nosso certificado e nossa chave privada, precisamos instalar o pacote
openssl:
Estamos criando uma chave com a criptografia RSA, no nome dela vai ser minhah-
chave.key, poderia ter qualquer nome, e ela vai ter 1024 bits.
Agora nós precisamos criar a requisição do certificado. Esse é o que deve ser envi-
ado para a empresa Certificadora, para ela assinar com a chave dela.
Como falei, não vamos usar uma empresa Certificadora, nós mesmos vamos assinar
para criarmos o nosso certificado:
Aqui estamos gerando a nossa requisição, que vai ser chamar requisica.csr, ela po-
deria ter qualquer nome.
Nesse momento, serão feitos algumas perguntas, no caso vocês podem preencher
com os dados de sua organização.
Nesse momento, precisamos fazer com que o apache trabalhe com o SSL.
1 # netstat - nlpt
Agora ele está rodando na porta 443. Para acessar nossa página no browser:
https://192.168.200.X/acidbase