Posts com a tag: PIX
PIX QoS Policies: configurando Rate Limiting
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.

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.
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”.
![]()
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.



