Tipos de Monitoramento de Segurança de Rede

Antes de iniciar este post, gostaria de retomar uma discussão frequente e uma resposta que tenho a esta questão: "O que uma empresa ou órgão deve fazer para estar preparado a responder incidentes de segurança (do ponto de vista de soluções/produtos)?":

Meu posicionamento/resposta diante desta pergunta:

I - Uma infra-estrutura de "Network Forensics" que seja capaz de reconstruir e fazer o "replay" dos pacotes relacionados ao ataque (ex: NetWitness NextGen / NikSun / Infinistream / NetIntercept )

II - Uma solução de SIEM/SEM para correlacionamento em near-real time dos logs (firewall, roteadores, servidor comprometido, ids/ips, dhcp, dns, aplicações internas) (ex: ArcSight / ISM Intellitatics / Symantec SIM)

III - Uma solução (idealmente enterprise) de forense computacional que possibilite a análise de dados voláteis (incluindo memória) e de disco (ex: Encase Enterprise / F-Response / AccessData Enterprise )

IV - Uma ferarmenta de monitoração de atividade de desktops (ex: SpectorCNE, WorkExaminer) [item incluído em 18/10/2009]

Com relação a primeira das soluções listadas acima, o Richard Bejtlich (CSO da General Eletric e autor de vários livros - todos recomendados) é uma referência mundial no que diz respeito à Segurança e Monitoramento de Rede, já o utilizei de referência/links em vários assuntos abordados aqui no nosso blog.

Ele postou há alguns dias atrás um artigo muito interessante sobre tipos de aplicações de monitoração de segurança de rede e eu fiquei esperando ter um tempinho para atualizar o blog com este excelente material e discussão.

São elencados por ele seis "data types" (maltraduzindo: tipos de dados) possíveis em uma ferramenta que lida com monitoração de rede (tradução livre minha):

1. Alertas: julgamento e detecção e/ou bloqueio feito por um produto ("Port scan!" ou "Buffer overflow!");
2. Estatísticas: descrição high-level de atividades (percentual de protocolos, tendências, etc.);
3. Sessões: comunicações entre hosts ("A conversou com B na 6a-feira por 61 segundos enviando 1234 bytes");
4. Conteúdo Completo (Full Content): todos os pacotes trafegados (no cabo/ar);
5. Extração de Conteúdo: reconstrução de elementos de uma sessão e extração de metadados;
6. Transações: geração de logs baseado em tráfego do tipo requisição-resposta (request-reply) como DNS, HTTP, etc.

Depois disto, ele produziu uma interessante tabela de referência contendo as categorias de produtos de Monitoramento de Segurança de Rede e os tipos de data types suportados por cada uma (genericamente). Esta foi a melhor abordagem comparativa de tecnologias de Segurança de Rede do ponto de resposta a incidentes que já vi.

Na minha opinião, a tabela mostra claramente porque uma organização que se preocupa com segurança precisa possuir ou desenvolver pelo menos uma das duas últimas categorias de produtos (NetWork Forensic Appliance ou Custom NSM Appliance) e não se satisfazer com soluções tradicionais (ex: IDS/IPS).

Apresento abaixo uma análise da tabela apresentada, algumas opiniões próprias (*) e nomes de aplicações e produtos que o autor do post citado preferiu não incluir.

(1) Produto IDS/IPS: Alerta ou Bloqueio OK; Estatísticas de Alertas OK; Sem Sessões; Sem Conteúdo Completo; Sem Extração de Conteúdo; Sem Transações. [ * Minha opinião: melhor opção comercial: SourceFire, melhor opção free: Snort / pouquíssimas vezes tive a oportunidade de ver um IDS/IPS bem gerenciado/"tunado"* ]

(2) Produto NBAD (Network Bahavioral Anomaly Device): Alerta baseados na análise de flows; Bons dados estatísticos; Bons dados de sessão; Conteúdo Completo somente para alguns flows; Sem Extração de Conteúdo; Sem Transações.

(3) Network Forensic Appliance: Sem alertas (* O NextGen da NetWitness possui alertas *); Bons dados estatísticos; Dados de sessão não podem ser manipulados imediatamente (*O NextGen da NetWitness permite que dados de sessão que possam ser manipulados imediatamente * ); Conteúdo Completo (propósito deste tipo de solução); Extração de Dados (alguns appliances possuem); Bons dados de Transações.

(4) Custom NSM Appliance *ou faça você mesmo com ferramentas de código aberto*: Alertas: Snort, Bro; Estatísticas: MRTG, Ntop; Sessões: auto-contidas ou aceitam Netflow; Conteúdo Completo: Dumpcap/Wireshark, Daemonlogger/Snort; Extração de sessão: requer desenvolvimento próprio (* tcpxtract, Networkminer *) ; Transações: Bro, Httpry.

Extendendo a resposta dada no início deste post no que diz respeito à monitoração de rede com objetivo de resposta a incidentes:

Se você possui budget para investimento, o ideal é buscar uma solução de Forense de Rede (opção 3 acima - que também é a que traz resultados mais rápidos)

No caso de não ter dinheiro mas possuir uma equipe numerosa e qualificada em segurança e open-source para dispor no desenvolvimento de uma solução customizada, o melhor (porém mais demorado) caminho é a opção 4 (Custom NSM Appliance).

Sei que este tipo de discussão costuma gerar debates interessantes... Comentários?

Falha no protocolo DNS descoberta / patches

2008-08-06 - Atualização:

Finalmente, a apresentação na BlackHat:

http://www.doxpara.com/DMK_BO2K8.ppt


2008-07-26 - Atualização:

Melhoria das Regras para IDS (Snort):

http://www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/CURRENT_EVENTS/CURRENT_DNS_Poisoning?rev=1.20;content-type=text%2Fplain

#by many very smart people
# This may be a high load sig. Take time and seriously consider
# that your dns_servers var is set as narrowly as possible
alert udp any 53 -> $DNS_SERVERS any (msg:"ET CURRENT_EVENTS Excessive DNS Responses with 1 or more RR's (100+ in 10 seconds) - possible Cache Poisoning Attempt"; byte_test:2,>,0,6; byte_test:2,>,0,10; threshold: type both, track by_src, count 100, seconds 10; classtype:bad-unknown; sid:2008446; rev:8;)

#this will catch large numbers of nxdomain replies, a sign that someone may be trying to poison you
#alert udp any 53 -> $HOME_NET any (msg:"ET CURRENT_EVENTS Excessive NXDOMAIN responses - Possible DNS Poisoning Attempt Backscatter"; byte_test:1,&,128,2; byte_test:1,&,1,3; byte_test:1,&,2,3; threshold: type both, track by_src, count 100, seconds 10; classtype:bad-unknown; sid:2008470; rev:2;)
#by Greg Martin at Econet
alert udp any 53 -> $HOME_NET any (msg:"ET CURRENT_EVENTS DNS Query Responses with 3 RR's set (50+ in 2 seconds) - possible NS RR Cache Poisoning Attempt"; content: "|85 00 00 01 00 01 00 01|"; offset: 2; within: 8; threshold: type both, track by_src,count 50, seconds 2; classtype:bad-unknown; reference:url,infosec20.blogspot.com/2008/07/kaminsky-dns-cache-poisoning-poc.html; sid:2008447; rev:4;)
alert udp any 53 -> $HOME_NET any (msg:"ET CURRENT_EVENTS DNS Query Responses with 3 RR's set (50+ in 2 seconds) - possible A RR Cache Poisoning Attempt"; content: "|81 80 00 01 00 01 00 01|"; offset: 2; within: 8; threshold: type both, track by_src, count 50, seconds 2; classtype:bad-unknown; reference:url,infosec20.blogspot.com/2008/07/kaminsky-dns-cache-poisoning-poc.html; sid:2008475; rev:1;)

2008-07-24 - Atualização:

Exploits disponíveis.

E adivinhe? Quase 4.000 DNS's (Mais de 50% dos grandes servidores DNS brasileiros) estão vulneráveis no momento - segundo o registro.br (via Caprino).

2008-07-22 - Atualização:

Patch Now. Detalhes sobre a vulnerabilidade DNS descrita abaixo vazaram.

Para verificar rapidamente se um DNS Server está vulnerável - (/dev/random):

Teste no Site do Dan Kaminski

ou

“dig +short porttest.dns-oarc.net TXT ”

Resposta Com patch:

$ dig +short porttest.dns-oarc.net TXT
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
"88.191.254.6 is GOOD: 26 queries in 3.9 seconds from 26 ports with std dev 19554.27"

Resposta SEM PATCH:

$ dig +short porttest.dns-oarc.net TXT
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
"212.35.96.66 is POOR: 35 queries in 4.3 seconds from 1 ports with std dev 0.00"

Mãos à obra!


2008-07-07:

Dan Kaminski é um ninja do TCP/IP que já contribuiu com a comunidade de segurança com seu memorável "Paketto Keiretsu" e uma interessantíssima análise de eventos como o RootKit da Sony.

Hoje foi divulgado que em março deste ano ele descobriu uma vulnerabilidade que facilita muito ataques de cache poisoning - utilizando birthday attacks no protocolo DNS - que afeta tanto servidores quanto clientes DNS. Veja o resumo executivo da descoberta.

Múltiplos fabricantes trabalharam em conjunto para solucionar o problema em suas implementações e um advisory do CERT foi publicado (.DOC) .

Para verificar se o seu DNS está vulnerável, teste-o no site do Dan Kaminski: doxpara.com

Há também uma entrevista interessante com o Dan Kaminsky sobre o tema.

Simplificando, apesar da especificação do protocolo DNS definir um campo de 16 bits para o campo "transaction" do cabeçalho - adivinhe... não é o que as implementações fazem (utilizam bem menos bits para isto). As soluções são expostas no .DOC acima.

Segundo o Dan Kaminsky, maiores detalhes técnicos serão expostos em 6 de Agosto, na DEFCON.

De cá pra lá, é bom ficar de olho para correções disponíveis do(s) fabricante(s) de DNS que você utiliza.

update (2008-07-08): Assinaturas de IDS para detecção (parcial) dos ataques descritos: http://www.snort.org/vrt/docs/ruleset_changelogs/changes-2008-07-08.html