Posts com a tag: PIX

Integrando o PIX com o AD – acesso administrativo

Por , 15/06/2010 07:00

Fala galera!!! Neste post em flash, estarei mostrando como autenticar os usuários que acessam o console, SSh, telnet, e HTTP do PIX, através do IAS (Internet Authentication Service) do Windows, integrado com o AD (Active Directory).

 

 

PIX QoS Policies: configurando Rate Limiting

Por , 01/06/2010 07:00

Nesta semana publiquei um post sobre limitação de banda nos switches 3750, e agora vou mostrar um exemplo da mesma configuração em um Cisco PIX firewall 515E, versão 8.0(4).

Através de políticas de QoS, conseguimos implementar limitação de banda no PIX/ASA, para tráfego outbound, em determinada interface. Os passos para esta configuração são os mesmo do IOS em switches, apenas alguns comandos mudam.

Como podemos ver, há uma rede outside e uma inside somente, com um host cada um. Usei para realizar os testes, o software NetMeter.

Configuração do PIX

O PIX está pré-configurado para este lab da seguinte forma:

interface Ethernet0
nameif inside
security-level 100
ip address 172.16.1.10 255.255.255.0
!
interface Ethernet1
nameif outside
security-level 0
ip address 192.168.10.10 255.255.255.0
!
access-list acl_inside extended permit ip any any
access-list acl_inside extended permit icmp any any
access-list acl_outside extended permit ip any any
access-list acl_outside extended permit icmp any any
!
access-group acl_outside in interface outside
access-group acl_inside in interface inside

Como podemos observar, qualquer tráfego está permitido, nas duas interfaces, mas apenas para efeito de teste.

Agora vamos definir a configuração a ser aplicada.

1. Classificando o tráfego

Uma ACL define o tráfego selecionado…

access-list 700k_outside extended permit ip any any

… e um class-map, irá referenciá-la, para definir qual tráfego receberá determinada política.

class-map map_700k_outside
description 700k outbound interface outside
match access-list 700k_outside

2. Criar o Policy-Map

O policy-map aplica ao tráfego definido por class-maps, as suas respectivas ações. Neste caso, ao class-map map_700k_outside será aplicado uma política de taxa de output de 700Kbps.

policy-map pmap_700k_outside
class map_700k_outside
police output 700000 10500

O parâmetro 700000 significa a taxa de output em bits, e 10500 é o burst, em bytes.

3. Aplicando as políticas

Agora o último passo é aplicar a política à interface, em sentido outbound, com o comando ‘service-policy’. Neste caso, na interface outside.

service-policy pmap_700k_outside interface outside

Vamos aos testes…

Antes de mostrar os testes, uma coisa é importante dizer: estas configurações não serão aplicadas a conexões já existentes, como você poderá perceber a seguir…

Observe o gráfico abaixo:

À esquerda, podemos ver o tráfego normal entre os dois hosts, e do lado direito, o tráfego após aplicadas as configurações. O host 192.168.10.2 está copiando um arquivo de aproximadamente 4,7GB do host 172.16.1.2.

Conforme dito anteriormente, as políticas somente são aplicadas a novas conexões… por isso, após aplicar as configurações, usei o comando ‘clear conn’ para fechar todas elas… então comecei novamente a cópia do arquivo.

A nova conexão mostrada no output do PIX já está no ar com a nova política de tráfego aplicada.

É isso então! Espero ter ajudado…

Dúvidas?! Sugestões?! Críticas?! Todas serão bem vindas!! É só mandar nos comentários… valeu!

PIX upgrade via Monitor

Caríssimo leitor… faz um tempinho que não posto nada… mas eu não abandonei o blog!! Bom, vamos ao que interessa…

Certo dia estava fazendo um upgrade de OS em um PIX 525, e quando tinha acabado de apagar a memória flash dele… acabou a energia!!! Mas eu não me abalei e resolvi ver o lado bom disso: pesquisei como fazê-lo via monitor e aproveitei pra fazer este post.

Ao ligar o PIX, o prompt irá dar ao usuário 10 segundos para escolher a opção de boot.

Use BREAK or ESC to interrupt flash boot.
Use SPACE to begin flash boot immediately.
Flash boot interrupted.

Se for pressionado espaço ou esperar expirar o tempo, o PIX irá procurar uma imagem .bin na memória flash para carregar, e se não encontrar, ele reinicia e repete este processo. No meu caso, como não havia OS na flash, pressionei ESC e entrei em modo monitor, que exibia o prompt da seguinte forma:

Use ? for help.
monitor>

A seguir está um passo-a-passo de todos os processos para fazer o upgrade.

1º) Inicializar uma interface

Conecte um cabo UTP na interface Ethernet 0 ou 1, entre com o comando “interface x”, onde “x” é o número da interface Ethernet conectada ao switch, ou diretamente ao PC por cabo crossover. É necessário que fisicamente o link esteja “up”. Usei a interface Eth1.

monitor> interface 1
0: i8255X @ PCI(bus:0 dev:14 irq:10)
1: i8255X @ PCI(bus:0 dev:13 irq:11)
Using 1: i82557 @ PCI(bus:0 dev:13 irq:11), MAC: 000d.bc0b.a899

2º) Configurar o IP do PIX

Com o comando “address” configura-se o IP que o PIX irá usar para acessar o servidor TFTP.

monitor> address 192.168.10.1
address 192.168.10.1

3º) OPCIONAL – Com o comando “gateway” configura-se o IP do default-gateway. Ex.:

monitor> gateway 192.168.10.100
gateway 192.168.100.1

4º) Especificar o servidor

Com o comando “server”, especificamos o servidor TFTP.

monitor> server 192.168.10.20
server 192.168.10.20

5º) Especificar o nome do arquivo

Com o comando “file”, especificamos o nome do arquivo de imagem.

monitor> file pix804.bin
file pix804.bin

6º) OPCIONAL – Um ping para testar a conectividade…

monitor> ping 192.168.10.20
Sending 5, 100-byte 0×4018 ICMP Echoes to 192.168.10.20, timeout is 4 seconds:
!!!!
Success rate is 80 percent (4/5)

7º) Download da imagem

Para finalizar, entramos com o comando “tftp”, para o PIX baixar a imagem do servidor, e dar boot com ela.

monitor> tftp
tftp pix804.bin@192.168.10.20…………………………………………………………

Pronto? Não… o PIX somente carrega este OS na RAM, para dar boot uma única vez. Após o boot, é necessário copiar a imagem para a flash.

pixfirewall# copy tftp: flash:

Address or name of remote host []? 192.168.10.20

Source filename []? pix804.bin

Destination filename [pix804.bin]?

Accessing tftp://192.168.10.20/pix804.bin…!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Writing file flash:/pix804.bin…

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
7538688 bytes copied in 101.590 secs (74640 bytes/sec)
pixfirewall# boot system flash:/pix804.bin
pixfirewall# wr

Agora sim está terminado. Mas aconteceu uma outra coisa comigo… no próximo post você irá saber!!!

Mais informações aqui!

Até mais… qualquer dúvida mande comentários!

Vulnerabilidades no Cisco ASA, PIX, FWSM e CSA

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.

vulnerabilidades no asa

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.

Versões afetadas

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.

Fazendo o ASA aparecer em um tracert/traceroute

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”.

image

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.

Tema Brainwork 0.2(beta)