Friday, April 13, 2012

As dificuldades na Monitoração da Segurança de Rede


Este artigo tem como objetivo tentar desmistificar a monitoração de segurança de rede, especialmente aquela relacionada ao uso de ferramentas de proteção como Intrusion Prevention Systems (IPS). São vários os desafios enfrentados pelos profissionais que monitoram as redes, tanto por parte de profissionais da própria empresa, quanto por aqueles que trabalham em empresas terceirizadas (serviço conhecido como MSS – Managed Security Services).

O desafio começa no volume de dados a serem inspecionados. Até um tempo atrás, o tráfego de 1 Gbps (efetivamente inspecionado) era considerado um volume bastante alto. Hoje em dia, especialmente em bancos e grandes operadoras, 10 Gbps pode ser considerado um volume médio. Já existe, inclusive, a tendência para redes de 40 Gbps e 100 Gbps. Tudo isso motivado, é claro, pelo uso cada vez mais intenso de links de internet rápida e pelos novos serviços disponibilizados. Quem utilizava conexões discadas, proporcionadas por placas de fax modem, com velocidades de 56 Kbps (as mais modernas para aquele momento) e agora utiliza links de 10 Mbps em casa, certamente imagina para onde estamos caminhando.

Voltando ao IPS, como é possível dar conta de um volume tão grande de dados? Certamente a resposta não é simples e envolve principalmente o conhecimento do ambiente a ser monitorado.

Sob o ponto de vista da rede, os principais detalhes que devem ser observados são:

1. Topologia da rede, incluindo todas as interconexões com outras redes, fornecedores e filiais: O objetivo principal é identificar todos os perímetros existentes para não corrermos o risco de utilizarmos um cobertor curto. Existem redes que possuem uma característica de estrela, onde todo o tráfego de rede obrigatoriamente deve passar pela matriz antes de ser encaminhado para as filiais (esse tipo de interconectividade é um pouco mais fácil de ser monitorarada). O difícil mesmo é quando todas as filiais conversam entre si, sem obrigatoriamente passarem pela matriz. Nesse caso, cada filial deve ser considerada uma rede autônoma, com medidas independentes de segurança (Firewall, IPS, etc).

2. Conhecimento dos serviços disponibilizados nos diversos segmentos de rede: Parece óbvio, mas é impressionante a quantidade de empresas que simplesmente desconhecem qual o perfil de tráfego/serviços disponibilizados. Isso normalmente ocorre devido ao crescimento rápido. Não dá para proteger uma rede sem conhecer o seu perfil de tráfego. Ponto. Quer um exemplo? Se um determinado segmento de rede refere-se a uma DMZ (zona desmilitarizada) e deve possuir somente tráfego HTTP, podemos muitas vezes identificar a ocorrência de um ataque pela simples identificação de um tráfego de rede anômalo, como TFTP, FTP, IRC. Às vezes, a simples tentativa de conexão ao mundo externo, a partir de um servidor localizado na DMZ, já pode ser considerado um tráfego suspeito. E tudo isso sem sequer levar em consideração a existência de uma assinatura para o ataque em questão.

3. Identificação dos Sistemas Operacionais e Serviços disponibilizados nos segmentos de rede: Exemplo: A DMZ possui somente sistemas Linux Debian, com serviços HTTP (Apache), DNS (Bind) e FTP (Proftpd). Essa identificação é fundamental para um correto correlacionamento dos ataques, bem como para permitir a ativação de assinaturas pertinentes. Para que eu vou habilitar assinaturas relativas ao ambiente Microsoft Windows, se eu só tenho servidores Linux? Isto permite reduzir sensivelmente a quantidade de falsos-positivos e aumentar a performance do IPS. Um inventário da rede e dos serviços é fundamental neste caso e, ao contrário da tecnologia de antivírus, uma maior quantidade de assinaturas habilitadas não representa, necessariamente, maior proteção.

4. Preparação da equipe: Não basta conhecer o produto e saber configurá-lo. É muito importante ter um conhecimento dos ataques e entender sua mecânica. Desta forma fica muito mais fácil a análise dos eventos e identificação de falsos-positivos. Este aprimoramento é constante e permite a retroalimentação do IPS com assinaturas melhor customizadas ao ambiente da empresa.

Os itens elencados acima certamente permitem melhorar a performance do IPS, possibilitando assim o uso mais inteligente dos recursos computacionais do equipamento utilizado para análise (normalmente appliances). De qualquer maneira, a tarefa não é simples e deve ser repetida continuamente, até para que seja possível a adaptação a novos serviços, servidores, etc.

Wednesday, March 28, 2012

Reflections about the RDP (MS12-020) Vulnerability

It is no longer news to anyone, involved with information security, that a critical vulnerability was identified in the Remote Desktop Protocol service (RDP - 3389/tcp). This vulnerability was reported in the famous "super tuesday" of Microsoft, in March 2012. Basically, it's a vulnerability that allows remote exploitation of the server/desktop (more details here: http://technet.microsoft.com/en-us/security/bulletin/ms12-020).
There already exists a tool that causes denial of service on a vulnerable system. It's just a matter of time until we have a fully active worm exploiting this vulnerability and spreading in an uncontrolled manner. Uncontrolled? But after all, isn't this service disabled by default


Yes, but... 


As usual, we have some sins on firewall configurations. Want an example? Just remember Slammer... Why the hell someone enabled (and still enables) direct access to a database from the internet? If this is REALLY necessary, why not to restrict the access from specific IP addresses? The same question obviously also applies to RDP access, with the aggravating factor that this service is not enabled by default (ie, we have to consciously enable it).
It's really important to adopt a secure architecture, regardless of the existence of a vulnerability. 
Zerodays are always a reality ...


Additional information:


http://aluigi.org/adv/termdd_1-adv.txt
http://seclists.org/nmap-dev/2012/q1/att-691/rdp-ms12-020.nse
http://www.metasploit.com/modules/auxiliary/dos/windows/rdp/ms12_020_maxchannelids
http://www.f-secure.com/weblog/archives/00002338.html
http://samsclass.info/123/proj10/rdp-honeypot.htm
http://blog.snort.org/2012/03/vrt-rule-release-for-03222012-ms12-020.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Snort+%28Snort%29