Seja o primeiro a comentar

Por André Ortega, 18/02/2010 10:23

A Cisco anunciou ontem, dia 17, uma lista de vulnerabilidades que afetam o ASA, PIX, o módulo FWSM (para 6500 e 7600) e ainda o CSA – Cisco Security Agent. Todos os problemas podem ser evitados com a atualização do software, já disponível (menos para o PIX).

Todos os clientes podem atualizar seus softwares, para corrigir estes problemas, mesmos os que não estejam cobertos pelo Smartnet. Para isso é necessário entrar em contato com o TAC, informar o número de série e fornecer a URL do anúncio das vulnerabilidades (que estão abaixo).

Ainda não há registros de uso mal intencionado destas vulnerabilidades, sendo os problemas encontrados pela própria Cisco.

ASA

Todos os modelos do ASA são afetados, dependendo da versão do software, mais ou menos problemas são encontrados. E as falhas não são interdependentes, de forma que uma release pode ser afetada por uma vulnerabilidade, e por outra não.

Veja os detalhes do anúncio, produtos afetados, workarounds e demais informações aqui.

FWSM

No módulo FWSM o problema ocorre quando um pacote SCCP mal formado é processado. Este erro pode fazer o módulo reiniciar.

Apenas a versão 4.0 é afetada, e a correção é encontrada no software a partir da versão 4.0 (8).

Mais informações no anúncio oficial, aqui.

CSA

O CSA, que vem instalado em diversos produtos, como Call Manager, IPCC Express, Unity, ACS e outros, sofre com problemas de DoS, SQL Injection e Directory Traversal.

No quadro abaixo as versões afetadas e as opções para correção.

Outras informações sobre as vulnerabilidades do CSA aqui.

PIX

Os firewall da família PIX também são afetados pelas vulnerabilidades listadas abaixo.

• TCP Connection Exhaustion Denial of Service Vulnerability
• SIP Inspection Denial of Service Vulnerabilities
• SCCP Inspection Denial of Service Vulnerability
• Crafted IKE Message Denial of Service Vulnerability
• NTLMv1 Authentication Bypass Vulnerability

Porém, como já estão com o End Of Software Maintenance (desde 28 de julho de 2009) não foram desenvolvidas correções para estes problemas.

Para minimizar o problema alguns workaround estão disponíveis. Veja aqui como proceder.

Até a próxima.

Seja o primeiro a comentar

Por André Ortega, 26/01/2010 10:21

Já foi o tempo em que a ameaça vinha de fora… Com as botnets, além de nos preocuparmos com possíveis ataques, também precisamos garantir que não estamos “atacando” ninguém.

Botnets são rede de computadores infectados, que passam a ser controladas pelo botmaster. Uma botnet pode ter computadores espalhados pelo mundo, e seu controlador a utiliza, sem que os verdadeiros donos dos PCs percebam, para enviar spam e fazer ataques, entre outros.

Segundo estimativa do FBI, existem entre 1 e 5 milhões de hosts infectados nos Estados Unidos e uma botnet pode ser “alugada” por até 50 mil dólares por dia.

Para evitar estes tipo de problema o Cisco ASA, com a licença apropriada, pode fazer a verificação dinâmica, através de URL ou IP, e identificar a comunicação entre um host infectado e seu controlador.

Após habilitar a verificação, quando um host interno tenta acessar uma URL, o ASA consulta o DNS para transformar a URL em IP e então compara com sua base de dados, que é constantemente atualizado pelo Cisco Security Intelligence Operations (trabalha com reputação, como o Senderbase e o Ironport). Caso este IP esteja na base de dados, ele é adicionado no DNS Reverse Lookup Cache, que é consultado quando a conexão é realizada. Assim, todas vez que um host se conectar a este IP é gerando um log, para que o administrador possa tomar as medidas cabíveis.

Também é possível criar sua própria blacklist e whitelist.

Configurando o ASA para detectar botnets

1°) Configure o DNS no ASA, para que as URLs (nomes) possam ser convertidos para IP.

dns domain-lookup outside
dns server-group DefaultDNS
name-server 8.8.8.8
domain-name brainwork.com.br

2°) Habilite o dynamic-filter updater-client, para baixar as atualizações do SIO.

dynamic-filter updater-client enable

3°) Configure o ASA para utilizar o banco de dados (também podemos configurar para usar black list).

dynamic-filter use-database

4°) Habilite a filtragem para todos os protocolos.

access-list dynamic-filter_acl extended permit ip any any

5°) Aplique a filtragem na interface de saída, neste caso a outside.

dynamic-filter enable interface outside classify-list dynamic-filter_acl

6°) Agora habilite o DNS snooping na interface outside, que fará a inspeção nas consultas DNS.

class-map dynamic-filter_snoop_class
match port udp eq domain
policy-map dynamic-filter_snoop_policy
class dynamic-filter_snoop_class
inspect dns dynamic-filter-snoop
service-policy dynamic-filter_snoop_policy interface outside

7°) (Opcional) Adicione entradas na black e white lists.

dynamic-filter blacklist
name exemploblack1.com.br
name exemploblack2.com.ru
address 200.20.20.1 255.255.255.255
dynamic-filter whitelist
name exemplowhite1.com.br
name exemplowhite2.com
address 200.30.1.1 255.255.255.255

Bloqueando a botnet

Após as configurações o ASA passará a gerar logs quando um host tentar acessar um IP com má reputação.

Exemplo de log

ASA-4-338002: Dynamic Filter permitted black listed TCP traffic from inside:10.1.1.45/6798 (209.165.201.1/7890) to outside:209.165.202.129/80 (209.165.202.129/80), destination 209.165.202.129 resolved from dynamic list: bad.example.com

Após verificar o log, devemos impedir que o host infectado tenha acesso a rede.

1°) Crie uma access-list.

access-list bloquear_botnet extended deny ip host 10.1.1.45 host 209.165.202.129
access-list bloquear_botnet extended permit ip any any

2°) Aplique a access-list na interface outside.

access-group bloquear_botnet out interface outside

No site da Cisco também tem um vídeo tutorial, mostrando como fazer esta configuração via ASDM.

Até a próxima.

Seja o primeiro a comentar

Por André Ortega, 09/09/2009 22:19

Por razões de segurança, o ASA/PIX não aparece quando fazemos um tracert (ou traceroute). Ele fica “invisível” para este tipo de tráfego deixando o pacote passar sem decrementar o TTL.

Exemplo: Com a configuração padrão o usuário não consegue ver o ASA como um dos “hops”.

C:\>tracert 200.221.11.100

Rastreando a rota para brahms.uol.com.br [200.221.11.100]
com no máximo 30 saltos:

1     1 ms    <1 ms    <1 ms  200.1.1.1  <—- O roteador é o primeiro “hop”
2     *        *        *     Esgotado o tempo limite do pedido.
3     *        *        *     Esgotado o tempo limite do pedido.
4     *          27 ms    28 ms  201.0.5.121
5    60 ms    57 ms    59 ms  201.63.253.154
6    84 ms   121 ms   152 ms  201.63.253.182
7    27 ms   47 ms    60 ms  189.109.69.74]
8    28 ms    26 ms    28 ms  200.221.136.102
9    26 ms    25 ms    26 ms  brahms.uol.com.br [200.221.11.100]

Rastreamento concluído.

C:\>

Apesar deste ser o comportamento padrão do firewall, muitas vezes precisamos que todos os “hops” do caminho sejam identificados. Para isso é necessário configurar o ASA/PIX para que ele passe a decrementar o TTL, e assim ser identificado no tracert.

Nas versões mais recentes (a partir da versão 8.0 (3)) basta entrar no policy-map padrão, depois na class-default e colocar o comando set connection decrement-ttl.

Configuração: Decrementando TTL no tráfego layer 3 que passa pelo ASA/PIX.

BrainFW01# conf t
BrainFW01(config)# policy-map global_policy
BrainFW01(config-pmap)# class class-default
BrainFW01(config-pmap-c)# set connection decrement-ttl
BrainFW01(config-pmap-c)# end
BrainFW01#

Com a configuração acima o ASA/PIX começará a “aparecer” no tracert.

C:\>tracert 200.221.11.100

Rastreando a rota para brahms.uol.com.br [200.221.11.100]
com no máximo 30 saltos:

1     1 ms    <1 ms    <1 ms  200.1.1.2    <—- IP da outside do ASA
2    <1 ms     *       <1 ms  200.1.1.1
3     *        *        *     Esgotado o tempo limite do pedido.
4     *        *        *     Esgotado o tempo limite do pedido.
5     *           28 ms    28 ms  201.0.5.121
6    60 ms    57 ms    59 ms  201.63.253.154
7    84 ms   101 ms   152 ms  201.63.253.182
8    27 ms   101 ms    27 ms  189.109.69.74]
9    28 ms    26 ms    28 ms  200.221.136.102
10    26 ms    25 ms    26 ms  brahms.uol.com.br [200.221.11.100]

Rastreamento concluído.

C:\>

Além desta configuração, para que o ASA/PIX aceite o tracert, é preciso liberar o ICMP nas access-lists aplicadas nas interfaces outside e inside (caso exista uma).

Mais detalhes neste link, e até a próxima.

(2) Comentários

Por André Ortega, 23/07/2009 09:34

Existe apenas um hardware e um software para cada modelo de ASA. Ou seja, para todo ASA 5510 é o mesmo hardware e software (claro que existem as versões, mas toda versão 8.0 é igual…), assim como para o ASA5505, ASA5520 e demais modelos. Podemos dizer que todo ASA é “k8” por padrão.

O "k9" no nome do equipamento, indica especificamente o uso de uma licença adicional e GRATUITA que habilita, unicamente, o algoritmo de criptografia 3DES (mais seguro, já que utiliza 168 bit, ao invés dos 56 do DES) normalmente utilizado para configuração de VPN.

Podemos confirmar isso conectando em um equipamento ASA "k9" e dar o comando dir. Observe que vai aparecer o nome do software por ele utilizado com a indicação “k8” (algo do tipo asa821-k8.bin).

Qual a diferença de comprar o ASA “k9” e o ASA “k8”?

Quando você adquiri o ASA “k9” ele já vem da Cisco com a licença para criptografia 3DES inclusa. Já o “k8” vem apenas com o DES habilitado, e você, se quiser, tem que adicionar o licença. Para isso, com o equipamento em mãos basta entrar no site da Cisco (www.cisco.com/go/license) e baixar a licença,  transformando o ASA “k8” em “k9” (leia-se habilitar a criptografia 3DES).

Já que é gratuito e mais seguro, por que não usar apenas o “k9” direto?

O governo americano controla rigidamente a exportação de produtos que utilizam criptografia avançada, como é o caso do 3DES, para o nosso país (parece que não somos vistos com bons olhos… ).

Uma das normas desse controle impede que os distribuidores/revendas armazenem produtos com este protocolo de criptografia, já que eles só podem sair do EUA quando o cliente final é conhecido.

Assim só existe em estoque o produto “k8” e quando é vendido, o próprio cliente ou a revenda realiza o cadastro do cliente no site do fabricante e baixa a licença, transformando o equipamento em “k9”.

Como saber se o ASA é “k8” ou “k9”?

Para saber se o dispositivo é "k8" ou "k9" digite show version e verifique se o 3DES está habilitado. Se tiver é "k9".

Se você comprar um ASA, mesmo que seja k8 pode pedir para o vendedor a licença 3DES, ou fazer a “transformação” sozinho.

Até a próxima.

Só um comentário

Por André Ortega, 01/07/2009 03:41

O NTP – Network Time Protocol, é um protocolo que permite a sincronização do relógio dos equipamentos na rede. Esta funcionalidade é extremamente importante, pois apenas com os relógios marcando a hora certa podemos analisar incidentes de forma correta. Do que adiantaria ter um log e não saber quando o problema ocorreu?

Para habilitar esta funcionalidade utilizamos quatro comando, como ilustrado abaixo. Observe que é obrigatório a autenticação do servidor, antes da sincronização do time.

Topologia: O Servidor NTP está na rede interna, e tem o IP 172.16.1.9

Configuração:

! Crie uma chave (3 neste caso) e defina a senha para autenticação (cisco)
ntp authentication-key 3 md5 cisco
! Configure a chave criada como confiável
ntp trusted-key 3
! Especifique o IP do servidor, a chave que será usada e a interface por onde ele será alcançado
ntp server 172.16.1.9 key 3 source inside prefer
! Habilite a autenticação para o NTP
ntp authenticate

Todo pacote NTP enviado pelo servidor deverá conter o identificar 3 na chave para que o ASA os aceite.

Até a próxima.