Monthly Archives: March 2012

An example of the Unified NAT Table on Cisco ASA

On our series of articles about ASA NAT, we mentioned that version 8.3 introduced a complete new model for address translation. The main characteristics associated with this new philosophy are summarized in the following:

  • NAT is not mandatory anymore (as opposed to the nat-control model).
  • NAT table is organized in 03 distinct sections: one for auto-NAT and two for manual NAT (or twice NAT).
  • Translation rules that involve source and destination simultaneously are now defined in a single nat statement (using a manual NAT rule). These are the cases of Dual NAT and all the variants of Policy NAT.
  • Starting on version 8.3, the Access Control Entries (ACEs) refer to the Real IP Address of the host and not to the translated address.

The figure brings a practical example of an ASA Unified NAT Table that contains rules in each of the three sections. Remember that:

  • Object NAT Rules are inserted into section 2
  • By default, manual NAT rules are created within section 1. If you want to insert a nat statement into section 3 you will need to use the after-auto parameter.
  • The sections in the NAT table are processed in order.

An example of the ASA Unified NAT Table

** Topics for Study:

** Related Posts:

1 Comment

Filed under English, Firewalls, Security

Protocolos Seguros para gerenciar sua Rede LAN

Nas comunidades de TI e Telecom é bem comum que se propague a idéia de que as disciplinas de gerenciamento e segurança de Redes são inconciliáveis (e mutuamente excludentes). Em vez de formar algum juízo de valor, entendo ser conveniente buscar soluções que mostrem que tal pessimismo não pode se perpetuar. Afinal, as redes precisam ser gerenciadas… E, se por um lado Segurança não pode ser um entrave para o gerenciamento, este último não deve inserir vulnerabilidades.

O objetivo do presente artigo é apresentar resumidamente as áreas de gerência que tipicamente estão presentes em uma rede LAN e, quando possível, mostrar versões seguras para os protocolos de Rede envolvidos (dos quais o SNMPv3, Simple Network Management Protocol versão 3, é apenas um exemplo).  Admitiremos em nossa análise o caso mais simples, isto é, o uso de um switch nível 2 na camada de acesso.

Acesso seguro à linha de comando (Command Line Interface = CLI) para fins de configuração e monitorização:

  • Usar cliente Secure Shell versão 2 (SSH) em substituição ao Telnet
  • Configurar o switch para que não aceite acesso terminal que não seja SSH
  • Usar no mínimo criptografia DES mas, se possível, optar por 3DES-168 (ou AES).
  • Controlar os comandos que podem ser executados via SSH e console física por meio do protocolo TACACS+ (autenticação, autorização e accounting de comandos).

Se você confiar as atividades de configuração e monitorização a uma interface gráfica (Graphical User Interface = GUI), convém que sejam observadas as seguintes orientações:

  • Usar HTTPS e não HTTP.
  • Definir os algoritmos criptográficos aceitáveis para a garantia de confidencialidade da sessão HTTPS. Usar no mínimo DES mas, preferencialmente, 3DES-168 (ou AES).
  • Exigir autenticação de usuário administrativo seguida de autorização e accounting dos comandos através do protocolo TACACS+.

Para transferência segura de arquivos (imagens de sistema e arquivos de configuração, por exemplo) é recomendável que se opte por SCP (Secure Copy) ou SFTP (Secure FTP) em lugar de FTP e TFTP.

Após esta breve descrição das opções de configuração e acesso a arquivos, voltemos ao SNMP…

A versão 3 do protocolo SNMP (SNMPv3) foi criada com o propósito de eliminar a visão histórica de que o significado da sigla era Security is Not My Problem. O novo modelo inclui não só autenticação individualizada (por usuário) mas também criptografia dos dados transmitidos. Lembrando que há operações do SNMP que permitem até mesmo alteração da configuração do equipamento, é fácil perceber que não convém que os dados (e muito menos a senha de acesso) sejam transferidos em claro.

Vale, no entanto, um alerta: a RFC 3414 (SNMPv3) prevê três modos possíveis de operação do protocolo, os quais são representados na Figura 1. Desses, apenas o AuthPriv contempla simultaneamente autenticação e criptografia, significando que é o único que atende nosso objetivo de gerenciar com Segurança a rede. Desta forma, se você está pensando em utilizar SNMPv3, deve verificar tanto do lado das soluções de gerência como dos elementos gerenciados, se existe suporte ao modo AuthPriv e, neste caso, quais os algoritmos criptográficos disponíveis. (Imagine um produto que suporta criptografia… Mas com chave de 5 bits… )

Figura 1: Modos de operação e exemplo de pacote SNMPv3 AuthPriv

Uma outra área relevante de gerência de Redes é o controle de sincronismo entre os equipamentos. Para se ter uma idéia da importância de se dispor de uma referência única (e confiável) de relógio, listamos algumas aplicações em que a informação de tempo é utilizada:

  •  Coerência das informações de gerenciamento
  •  Coerência do accounting de utilização dos serviços de rede (normalmente controlados via RADIUS)
  •  Coerência do accounting de acesso administrativo a equipamentos de Rede (função clássica do TACACS+)
  •  Verificação da validade de Certificados Digitais
  •  Definição de políticas de acesso baseadas em horário
  •  Verificação da validade de licenças de software vinculadas a horário
  •  Subsídio para medição confiável de parâmetros de SLA
  •  Subsídio para auditoria (desde que o processo utilizado para sincronização seja seguro…)

O protocolo clássico de sincronismo é o Network Time Protocol (NTP), o qual em sua versão 3 (RFC 1305, datada de 1997) já especificava o uso de autenticação do servidor pelo cliente através de hash MD5. Diante das aplicações que acabamos de listar para a informação de sincronismo, surge naturalmente a pergunta:  – Você, na condição de administrador de Redes ou Segurança, se sentiria confortável se os seus equipamentos de Rede aceitassem qualquer informação de tempo que lhes fosse passada ?

Diante disso, vale advertir que existe uma versão simplificada do NTP, denominada SNTP (Simple NTP), que não inclui autenticação e que, portanto, não é adequada para ambientes em que é preciso comprovar comprometimento com minimização do risco operacional e disponibilizar informações para fins de auditoria. Mais detalhes são providos na Figura 2.

Figura 2: Autenticação entre cliente e servidor NTP

O presente texto é uma tentativa de caracterizar um primeiro passo na busca do objetivo maior de se construir redes LAN mais seguras. Isso porque, apesar de existirem  várias funcionalidades específicas de Segurança de LAN (802.1x, Port Security, Private VLANs, etc), se o gerenciamento não for conduzido de forma segura, todo o resto do esforço poderá ser perdido.

** Sumário de Recomendações:

  • Acesso Remoto Seguro a CLI: SSHv2
  • Acesso Remoto via Interface Gráfica: HTTPS
  • Transferência Segura de arquivos: SCP (Secure Copy) ou SFTP (Secure FTP)
  • Monitorização e Alertas: SNMPv3 no modo AuthPriv
  • Sincronismo Seguro: NTPv3 (no mínimo) com autenticação MD5 por parte do cliente (equipamento)
  • Controle de Acesso Administrativo (autorização e accounting de comandos): TACACS+

** Notas:

  • Já existe o NTP versão 4 mas muitos produtos ainda não o implementam. Enquanto a disponibilidade do novo protocolo não se amplia, o mínimo aceitavél é o suporte à versão 3.
  • As considerações aqui feitas para um switch L2 também se aplicam a elementos que operam em camada 3 (switches L3 e roteadores).
  • Há um interessante guia de hardening de switches Cisco produzido pela NSA (National Security Agency), cuja leitura é altamanente incentivada: (http://www.nsa.gov/ia/_files/switches/switch-guide-version1_01.pdf)

** Artigos Relacionados:

5 Comments

Filed under Português, Redes, Segurança

Routing Basics: Administrative Distance in action

[  "The distance is nothing; it is only the first step that is difficult." - Mme Du Deffand ]

In a previous article, Quick Review of IP Routing, we presented the complementary concepts of building the routing table (related to the control plane) and using the table to forward packets (data plane). The current post focuses on the influence of the Administrative Distance (AD) parameter on selecting a route (a control plane task) that will be added to the routing table.

There are multiple routing protocols and each of them uses different units to evaluate how distant a certain destination is. For example, EIGRP costs employs a combination of delay and bandwidth, whereas OSPF bases its calculations solely on bandwidth. RIP, a protocol from the early days of internetworking, selects routes based on a very limited criterion called hop count.

A little reflection on the topic will show that it is not adequate to directly compare routes from different protocols. To somehow take into account the nature of each protocol and to produce a measure of how precise they are, the Administrative Distance concept was introduced.  For instance, the default point of view of a Cisco router is to consider EIGRP better than OSPF, which in turn takes precedence over RIP.

Some important aspects to keep in mind to better understand the Administrative Distance:

  • AD is only taken into account by a router to compare two equal length network prefixes available to a certain destination. Prefixes of distinct lengths are not comparable. For example, a router that knows the prefix 10.10.10.128/25 via OSPF and 10.10.10.0/24 via EIGRP will install both… (why ?)
  • AD is evaluated before any metric information. While AD establishes a comparison between routing protocols, the metric value (or cost) is used to contrast the routes of a certain protocol. This is emphasized by the fact that the AD is the first number inside the brackets that follow the prefix (Figure 1).

In the scenario of Figure 1, the CENTRAL router initially has an OSPF route (through R1) to 192.168.30.0/24. Figure 2, in turn, illustrates what happens when a second route to the same destination gets to be known by CENTRAL.

Figure 1: Initial Situation - Route known via OSPF

Figure 2 depicts a situation in which a new router (R2) started advertising an alternate path to the 192.168.30.0/24, originally reachable via OSPF. Upon receipt of this alternate route, the CENTRAL router detects the lower AD value (90 for EIGRP internal versus 110 for OSPF) and the original route is replaced. The information about this new route is also visible in the figure.

Figure 2: Route with lower Admin Distance becomes available

** Notes:

  • It is important not to confuse the activities of installing the routes in the routing table and using them to forward packets. If you have two routes installed, 10.10.10.0/24 and 10.10.10.128/25, the most specific (for a given destination) will be used. A packet destined to 10.10.10.200/32, for example, will be forwarded using the second route whereas a packet bound to 10.10.10.100 will use the first. ( - Can you explain why ? )
  • EIGRP was designed to support a composite metric that includes delay, bandwidth, reliability, load and MTU but, by default, uses only the first two. The EIGRP metric is deemed more precise because it refers to the minimum bandwidth and to the sum of delays along the path from the router to the destination.
  • As a reference, the default values for the Administrative Distance parameter for the main types of routes are presented in the following table:

    Type of Route

    (Default) Administrative Distance

    Connected (C)

    0

    Static (S)

    1

    eBGP (B)

    20

    EIGRP (D)

    90

    OSPF (O)

    110

    IS-IS (i)

    115

    RIP (R)

    120

    EIGRP External (D EX)

    170

    iBGP (B)

    200

 

** Related Posts:

Leave a comment

Filed under English, Routing

Dealing with Identity NAT on ASA: pre and post 8.3 configuration models

Continuing our series of articles about Network Address Translation (NAT) on Cisco ASA, we will now examine the behavior of Identity NAT.

When the nat-control model is in place (for ASA releases older than 8.3), an explicit answer regarding NAT must be provided to the ASA algorithm, even if this answer is do not translate ( “no nat“). Among the NAT exemption techniques supported by ASA, there is one called Identity NAT, which is typically used when most of the addresses are being translated and you need to avoid translation for just a specific set of hosts.

Starting on 8.3 version,  there is no such concept of nat-control, meaning that NAT Exemption is not necessary anymore and the nat 0 (nat zero) configurations are completely banned.

The reference topology shown in the figure was conceived to illustrate NAT Exemption syntaxes for both the current and old (pre 8.3) models. In our environment, hosts belonging to the 10.10.10.128/26 subnet are excluded from translation rules, irrespectively of the destination being accessed. Although the intention here is to keep some source addresses from being translated, the behaviors of the configurations are slightly different:

  • The nat zero construction that refers directly to the IP address (instead of an ACL) is unidirectional in essence and is not suited for address publishing. This means that the 10.10.10.128/26 stations will be able to start outbound connections but will not be accessible from the out interface (even if you configure a permission within an ACL).
  • Identity Static (static from X to X) is bidirectional and, as such, may be used for address publishing. (You will still need to add a permission so that the real address can be reached from the out interface).
  • The NAT flags are distinct: both options have the identity flag set but nat zero is deemed dynamic. (And that reinforces its unidirectional nature).

Identity NAT on ASA: configuration models

** Notes:

  • Considering that we are dealing with a source-only translation rule, we employed Object NAT for the 8.3 case. By revisiting the previous posts on the NAT series, can you build an equivalent configuration with Manual NAT ?
  • The show commands registered in the figure help characterize that NAT exemption is in place. Can you explain that ?

** Related Posts

2 Comments

Filed under English, Firewalls, Security

Projetos Multilayer de Redes LAN: por que usar switches nível 2 na camada de acesso ?

Quando vejo os altos números de desempenho dos atuais switches de acesso, é difícil não me lembrar que no início de minha carreira na área de Redes, o switch de núcleo da Cisco oferecia 3,6 Gbps de backplane (valor considerado alto, à época, pois as portas de usuários eram de 10Mbps). O tempo passa, a tecnologia amadurece ( tendendo a diminuir de preço) e hoje estamos em um estágio em que é bem comum que as portas de acesso (Ethernet) nos novos projetos sejam de 1Gbps (apesar de que 100Mbps por porta continuam sendo mais do que suficientes para a grande maioria dos casos).

Tudo isso é bom mas convém ter o cuidado com a armadilha dos grandes números… Digo isso, pois noto em minhas conversas com clientes uma demasiada valorização de aspectos quantitativos (dentro daquela perspectiva cômoda do “quanto mais, melhor”), em detrimento de uma análise mais criteriosa de funcionalidades que fazem a diferença no projeto como um todo.

Percebo também uma tendência a simplificar excessivamente o assunto, provavelmente influenciada pela idéia errônea de que “para montar uma LAN é só ligar o switch e conectar os cabos“… (Antes de tirar uma tal conclusão, lembre-se que “um cabo errado pode ser a origem de um loop”…)

Existe ainda a percepção histórica de que um core L2 é rápido e uma opção correspondente com L3 seria lenta, apesar de possuir mais funcionalidades. No que concerne a uma tal visão , vale dizer que, apesar de ter sido correta muitos anos atrás (vide Figura 1), os equipamentos evoluíram de modo a tornar as taxas de encaminhamento (pps) em L2 e L3 virtualmente indiscerníveis (mas, certamente, com um custo maior associado ao último). E, graças a este progresso tecnológico, é possível agora usar L2 ou L3 conforme sejam mais adequadas para um determinada área da rede (este é o chamado design multilayer, ilustrado na Figura 2).

Figura 1: Modelos Históricos de Redes LAN

Bem, se há a intenção de produzir projetos mais consistentes, é importante um melhor entendimento do modelo de camadas (acesso, distribuição e núcleo) ou, eventualmente a combinação das duas últimas, no caso de redes menores. A orientação básica pode ser resumida na adoção de L3 para conexão da distribuição ao núcleo e L2 para ligar a distribuição ao acesso (Figura 2). Isso garante a disponibilidade, convergência rápida e isolamento providos pelo L3, sem perder a mobilidade e simplicidade do acesso L2.

Figura 2: Modelo Multilayer de Projetos de LAN

As principais motivações para adotar uma abordagem multilayer são listadas a seguir:

  • Separação funcional: cada camada desempenha um papel bem definido no conjunto da solução
  • Modularidade: há blocos de projeto bem definidos, o que facilita o entendimento da topologia lógica (incluindo plano de endereçamento e esquema de numeração de VLANs).
  • Facilidade de expansão:  quando há necessidade de acrescentar portas para usuários, não é necessário fazer um novo projeto. Se a organização em camadas foi utilizada desde o início, fica bem mais fácil acrescentar um novo bloco de acesso e prover as portas necessárias
  • Padrões de tráfego determinísticos: dado que os servidores estão centralizados e que as estações de usuários se conectam a swiches de acesso, é mais fácil prever os fluxos de aplicações e planejar a utilização dos uplinks.
  • Criação de pequenos domínios de falha: a demarcação clara da função de cada camada facilita o isolamento e a resolução de problemas.
  • Equilíbrio entre recursos L2 e L3: isso permite extrair o melhor de cada uma das tecnologias.
  • A utilização de roteamento (L3) entre distribuição e núcleo, permite balanceamento de carga, convergência rápida e maior nível de controle (limitação da topologia L2).

Algumas características relevantes da camada de acesso (nível 2):

  • Ponto de ingresso na Rede : PCs, telefones IP, impressoras, etc.
  • Controle de acesso por porta à rede deve começar aqui (IEEE 802.1x/NAC): Autenticação, Autorização e Accounting para usuários e equipamentos.
  • Funcionalidades de Segurança integradas à Rede : Port security, DHCP Snooping, Dynamic ARP Inspection, IP Source Guard, Private VLANs, apenas para citar algumas.
  • Idealmente com uplinks duplicados para a camada de distribuição (alta disponibilidade).
  • Por ser um processo fim-a-fim, QoS deve começar aqui: e deve contemplar parâmetros de nível 2 (CoS), nível 3 (DSCP) e nível 4 (portas TCP e UDP).
  • Supressão de broadcast, multicast e unknown unicast
  • IGMP Snooping, de modo a evitar que portas físicas que não contém “receivers” para um determinado grupo, recebam desnecessariamente tráfego Multicast (otimização de IP Multicast na rede de switches nível 2)
  • Otimização de Spanning Tree (IEEE 802.1D, IEEE 802.1w, IEEE 802.1S)
  • Mapeamento entre VLANs (L2) e sub-redes IP (L3). O default-gateway para os hosts em um determinada VLAN fica na camada de distribuição ou distribuição/core (no caso de um design usando o conceito de “collapsed backbone”)
  • Capacidade de identificação automática de “endpoints”, principalmente os de multimídia (LLDP e LLDP-MED)

Algumas características importantes da camada de distribuição:

  • Agregação de vários switches de acesso (para criar um “bloco de acesso” em que há mobilidade dentro de uma VLAN/subnet)
  • Uplinks para o CORE a partir de um bloco de acesso (switch de distribuição) em vez de uplinks partindo de cada switch de acesso
  • Recomenda-se o uso de “Layer 3 switching” para esta camada
  • Evita que o CORE tenha que estabelecer múltiplas adjacências e o isola em relação a problemas na camada de acesso.
  • Funcionalidades de proteção do protocolo Spanning tree (definição de STP Root Bridge, evitar que switches de acesso tentem se tornar a Root Bridge)
  • Sumários de Roteamento, convergência rápida, load sharing através de caminhos redundantes
  • HSRP (Hot Standby Router Protocol) ou VRRP (Virtual Router Redundancy Protocol) ou GLBP (Gateway Load Balancing Protocol) para redundância de “default gateway”
  • Disponibilidade e load balancing (Rapid Per-VLAN Spanning Tree, Per-VLAN 802.1w)
  • Roteamento Multicast usando protocolos PIM e IGMP (interação host <> router)
  • Listas de controle de acesso para controlar a conexão entre subnets IP.

Alguns aspectos importantes a considerar na camada de CORE :

  • Sinônimo de camada 3 no conceito multilayer
  • Representa o backbone da Rede:  interconexão dos blocos de distribuição e ligação com a WAN e o Data Center.
  • Em redes grandes, a camada de CORE é normalmente usada para evitar “full-mesh” dos switches de distribuição
  • Foco em Desempenho e Estabilidade versus complexidade— “less is more in the core
  • Camada de CORE separada ajuda a prover expansibilidade para crescimento futuro.
  • Vale a pena fazer um design de CORE que seja independente da tecnologia de conexão (GigEtherntet, 10GigEthernet, CWDM, Sonet, Dynamic Packet Transport, etc.)

Tendo discutido as características dos projetos multilayer, listamos a seguir uma série de benefícios associados ao uso de switches nível 2 na camada de acesso. Além das grandes vantagens de preço trazidas por esta opção, (particularmente pelo número de switches de acesso em um projeto ser bem maior que os das demais camadas), vale mencionar:

  • Facilidade de conexão de novos usuários ( tornando o acesso plug and play)
  • Aumento da mobilidade de usuários entre switches (isso é particularmente importante em ambientes que empregam 802.1x/NAC para atribuição dinâmica de VLAN). Aliás, o design de NAC torna-se muito mais complexo quando o acesso é L3.
  • Roteamento fora da camada de acesso. Esta função é exercida pelo switch de distribuição ou CORE. Isso diminui o número de adjacências de protocolos de roteamento e aumenta a expansibilidade da Rede.
  • O fato de não se ter roteamento no acesso também contribui para a estabilidade da rede: menor número de mudanças na topologia de roteamento e redução de recálculos por parte dos protocolos dinâmicos.
  • Multicast para os usuários é controlado via IGMP Snooping (seleção de portas físicas que vão receber tráfego multicast em uma dada subnet) e não via roteamento Multicast (o que obrigaria a criação de adjacências do protocolo PIM em cada switch de acesso). Mais uma vez, ressalte-se aqui a preocupação em reduzir complexidade e aumentar estabilidade.
  • As atividades de filtragem (através de listas de controle de acesso) se concentram um nível acima (distribuição), tornando-se, portanto, muito mais facilmente gerenciáveis.
  • Particularmente no que concerne à segregação de voz e dados, é muito mais simples fazer o controle na camada de distribuição (em vez de configurar ACLs em cada switch de acesso).

Concluímos o breve texto ressaltando que, apesar de nível 2 no acesso significar que não se usa roteamento IP em tal camada,vários  outros recursos que vão muito além do nível 2 continuam disponíveis:

  • Os switches L2 modernos dispõem de capacidade de filtragem (por meio de ACLs) que levam em conta campos do cabeçalho IP e combinações de portas de serviço (TCP/UDP).
  • As tarefas de classificação de pacotes (no contexto de Qualidade de Serviço – QoS) podem ser feitas com base em critérios como DSCP (L3), endereços IP de origem/destino, portas TCP/UDP.
  • É possível gerenciar os switches via IPv6 (sem necessidade de rotear IPv6).
  • Muitos dos switches L2 atuais podem ser configurados para responder a probes de validação de SLA (Service Level Agreement) que permitem testar operações TCP, UDP e ICMP.
  • Há vários modelos de switches L2 que permitem fácil diferenciação (e separação lógica) entre telefones IP e computadores, através do recurso de Voice VLAN.

** Artigos Relacionados:

7 Comments

Filed under Português, Redes

Migrating to ASA 8.3, 8.4 or higher ? Don’t rely blindly on the automatic NAT migration script

As explained in a series of previous posts, it is indispensable to understand the NAT philosophy change introduced by ASA 8.3 in order to profit from the new features (available in 8.3 and higher). While the other articles focused on explaining the correspondence between the pre and post 8.3 models, the current one will demonstrate the automatic migration script in action when you upgrade ASA software on a 8.2 box that already contains NAT rules.

The Static Policy NAT and Static NAT configurations for the reference topology of Figure 1 are described below:

  • The dmz client 10.10.10.150 is mapped to 172.18.18.150 when the destination is  172.16.16.200.
  • For other out destinations, the same dmz client is statically translated to 172.16.16.150.

Figure 1: ASA NAT - Migration Example 1

If you carefully look at the figure, you will notice that the IP addresses used in the ACL and static rules of the 8.2-style configuration are converted to network objects, which are later employed within the nat statements that characterize 8.3.

Although the migration script may be helpful for simple topologies that contains few categories of NAT, it is really critical that you understand how to manually convert from the original model to the new one. There are situations, such as those registered in Figure 2, in which the script may not work. So do not rely blindly on it. I think it is really advisable to invest some time on getting familiar with building the manual correspondence.

Figure 2: Sample messages from the NAT automatic migration script

** Notes:

  • If you plan to use the automatic migration script, it is really recommended that you remove the nat-control command from your pre-8.3 configuration. This will avoid the creation of many network objects during the conversion process.
  • From 7.0 to 8.2 the default ASA operation mode is to consider NAT an optional feature. This is accomplished with the no nat-control command, which is not displayed in the show running-config listing. If you want to make sure that no nat-control is in place, issue the show running-config all nat-control command.

** Related Posts:

5 Comments

Filed under English, Firewalls, Security

Handling dual NAT on ASA: concurrent translation of source and destination addresses

[ "What is actual is actual only for one time. And only for one place." - T. S. Elliot ]

As a follow on to our analysis of ASA NAT, the current post examines another important use case scenario: how to simultaneously translate source and destination addresses on a certain connection through your firewall ? As usual, both the pre-8.3 and post-8.3 configurations are covered so that you can use them to help on your migration tasks (in case your are still using 8.2 or earlier releases).

One remarkable difference between the old and new syntaxes resides in the fact that from 8.3 on you just need a single nat statement to produce the dual NAT effect. This is an improvement with reference to the classic model, which required two rules (for instance two static commands) to achieve the same result.

Some other key advantages of the model introduced by ASA 8.3 are listed below:

  • When using manual NAT, the use of the sequence number (SEQ#) parameter enables the precise control of the order in which translation rules are inserted in the Unified NAT Table. This renders NAT processing much more predictable than the original implementation.
  • The capability of specifying source and destination mappings at once, makes ASA NAT logic more similar to other vendors’, thus facilitating migration from competitive offerings.

Handling dual NAT on ASA: before and after 8.3

** Topics for Study:

** Notes:

  • It is very important that you get familiar with the order in which the real and mapped addresses are defined in the nat and static commands.
  • Remember that starting on 8.3, ASA ACLs refer to the real IP of the destination host (as opposed to 8.2 and older versions, which use the translated IP).
  • The ability to use global ACLs, introduced by version 8.3, is another factor that may decrease the efforts when migrating from other vendors’ firewalls to ASA.
  • If you need a detailed coverage of the NAT precedence rules (very important on pre-8.3), please refer to Chapter 08 of the Cisco Firewalls title on the Cisco Press security collection. For information about 8.3 NAT, consult the Appendix, NAT and ACL changes in ASA 8.3, of the same book.

** Related Posts:

Leave a comment

Filed under English, Firewalls, Security

Configuring Dynamic Policy PAT on ASA: current and legacy models

This post builds upon the previous discussions on the ASA NAT series to exemplify yet another category of address translation: Dynamic Policy PAT. In this type of scenario, a set of source addresses get mapped into a single global address when they need to reach specific destinations.

In our reference topology, those dmz stations belonging to the 10.10.10.128/27 subnet are port address translated to 172.16.16.125/32 when the destination is the out host 172.16.16.200. For different out hosts, the source IPs are not translated. Some important points to highlight:

  • It is important to observe that we are not translating the destination address. We are just using the destination criteria to influence translation of the source addresses.
  • In the pre-8.3 CLI the number “1” is the NAT_ID, which creates the relationship between the nat and global commands.
  • The original syntax (pre-8.3) employs an Access Control List (ACL) in conjunction with the nat command to insert the destination-based rule.
  • In the new model introduced by release 8.3, we use manual NAT to create any rules that concurrently involve source and destination. This is the case for Policy NAT, Policy PAT and Dual NAT. Unless you use the after-auto argument in the nat command, manual translations are inserted in Section 1 of the Unified NAT Table.

Dynamic Policy PAT on ASA

** Notes:

  • As in the basic PAT case (which does not take destination addresses into account), ASA combines the global address (172. 16.16.125 in this case) with a source port to correctly identify each internal host and deliver the return packets accordingly.
  • Manual NAT allows you to add a sequence number to each manual nat statement, so that you can directly control the order of processing of the translation rules (irrespectively of the NAT category in place). This is a major difference when comparing to releases up to 8.2, for which you needed to know the intrinsic NAT precedence rules.

** Topics for Study:

** Related Posts:

Leave a comment

Filed under English, Firewalls, Security

Dynamic NAT on ASA: before and after release 8.3

["All appeared new, and strange at first, inexpressibly rare and delightful and beautiful. I was a little stranger, which at my entrance into the world was saluted and surrounded with innumerable joys." - Thomas Traherne]

After reading the article “NAT Evolution within Cisco ASA software” and applying that knowledge to build static translations on ASA, it is now time to implement dynamic rules. As we did before, to make life easier on migration tasks, the two configuration modes (pre and post-8.3) are presented.

The figure below brings not only the old-style syntax but also the new options for a simple topology, in which the internal addresses belonging to the 10.10.10.128/25 subnet are translated to the range 172.16.16.129-172.16.16.254. In this arrangement, some facts deserve special mention:

  • In the legacy CLI the number “2” is the NAT_ID, which is used to establish the link between the nat and global commands.
  • For source-only translations, the nat statement (configured under the network object definition) automatically places the rule in Section 2 of the Unified NAT Table.
  • Given that manual NAT allows the creation of rules that simultaneously specify translation of source and destination addresses, manual NAT can be “simplified” to create source-only (or destination-only) rules. In this case the rule will be part of Section 1 and there will be no reference to network object. Considering that the sections in the NAT table are sequentially processed, the equivalent construction with manual NAT takes precedence over Object NAT. (The exception is when you employ the after-auto parameter in the nat command, thus sending the manual rule to Section 3).

Dynamic NAT on Cisco ASA

** Topics for Study:

** Related Posts:

Leave a comment

Filed under English, Firewalls, Security

Voz sobre IP, Telefonia IP e Colaboração

O transporte de voz sobre uma rede de dados que se apóia no IP como protocolo de camada 3 é uma alternativa para o sistema de comutação de circuitos, tradicionalmente empregado pelas companhias telefônicas. Considerando que grande parte das empresas já realizaram investimentos significativos na criação de uma infraestrutura para comunicação de dados baseada em IP e lembrando que o custo mensal das linhas de dados é (na maioria dos casos) fixo, torna-se bastante intuitivo perceber que se conseguirmos efetuar o transporte de voz sobre tal estrutura poderemos ter uma redução expressiva nos gastos com contas telefônicas e com manutenção.

Em um mundo onde a Internet ganha mais e mais relevância no que se refere à realização de negócios e aumento de produtividade e que, inclusive por isso, vem promovendo a onipresença do protocolo IP, tal perspectiva de economia com custos de operação (cada vez mais importante para manutenção da competitividade das empresas) se mostra suficientemente convidativa para que dediquemos atenção às tecnologias de Voz sobre IP e Telefonia IP.

Cumpre salientar, no entanto, que a possibilidade de tornar real o sonho de integração das redes de voz e dados em uma plataforma multisserviços está condicionada ao fato de que se atendam algumas exigências específicas do tráfego de voz. Sendo respeitadas as restrições intrínsecas a este, como, por exemplo, a necessidade de redução dos atrasos de propagação e manipulação, a uniformização dos atrasos e a reserva de uma largura de banda, pode-se obter qualidade praticamente indiferenciável daquela a que estamos habituados no processo convencional de transporte. Interessante ainda é notar que enquanto no “velho mundo” das comunicações se exigia uma banda de 64 Kbps para um canal de voz, a nova abordagem permite o uso de cerca 16 Kbps por canal, fato este que já traz em si uma exemplificação da eficiência que pode ser obtida ao se transportar voz sobre uma rede IP.

O tratamento dado pela Cisco às soluções de VoIP e Telefonia IP faz parte de um conjunto mais amplo de recomendações que visa promover a convergência dos tráfegos de dados, voz e vídeo em uma infraestrutura de rede única e desta forma contribuir para materializar o conceito de Colaboração.

Para um melhor entendimento deste ( e de outros textos correlatos) vamos começar por definir alguns termos:

  • Voice over IP (VoIP): ao utilizar a denominação Voz sobre IP, ou resumidamente VoIP, estamos nos referindo à solução conhecida como toll-bypass, em que centrais telefônicas convencionais podem ser conectadas através da rede IP, o que se torna particularmente atrativo sob o ponto de vista econômico para ligações do tipo DDD e DDI. Para este cenário faz-se necessária a adição de placas de voz aos roteadores existentes. Note-se aqui que a voz é simplesmente transportada sobre a rede IP e que as tarefas de codificação e compressão da voz são executadas pelos roteadores com placa de voz, que neste ambiente operam como gateways entre o mundo da telefonia tradicional, representado pelos PABXs, e o mundo IP, associado aos roteadores.
  • IP Telephony (IPT): quando falamos em Telefonia IP, estamos nos referindo à implementação dos já bastante difundidos serviços e funcionalidades da telefonia tradicional, com a diferença primordial de que todo o tráfego de controle, assim como a voz propriamente dita, são transportados através de uma infraestrutura de comunicação baseada em IP. Neste novo teatro passam a figurar como atores principais os Call Managers , responsáveis pelas tarefas de processamento de chamadas, e os telefones IP (IP Phones), que se apresentam como a principal interface do usuário com a rede convergente.
  • Colaboração IP: Arquitetura centrada em viabilizar a interação entre pessoas ( e assim contribuir para o compartilhamento de informações e experiências) através de aplicações tais como webex, Cisco Jabber e Telepresença. O uso de Telefonia IP é um passo natural no caminho para a Colaboração IP.

A Figura 1 traz uma comparação visual entre os serviços VoIP e Telefonia IP.

Com base no que aqui foi exposto, podemos concluir que as soluções de Telefonia IP e VoIP são complementares e, numa análise mais cuidadosa, que a implementação de VoIP é um caminho natural de migração da telefonia tradicional para aquela baseada em IP. Isto porque os roteadores com placas de voz empregados no cenário de toll-bypass podem ser utilizados para conexão direta à PSTN no momento em que se promover a eliminação do PABX de uma dada localidade. Tal situação pode ser visualizada na Figura 2, que ilustra a coexistência das soluções de VoIP e Telefonia IP.

Figura 2: Coexistência entre VoIP e Telefonia IP

** Notas:

  1. Promovendo-se uma analogia simples com o modelo de telefonia tradicional, poder-se-á facilmente associar as funções essenciais do Call Manager àquelas do PABX convencional, devendo-se ressaltar, no entanto, que ao deslocar o plano operacional de um sistema proprietário para uma estrutura de comunicação baseada no protocolo universal IP, ganha-se notável flexibilidade. E isto de imediato se traduz na possibilidade de implementação de um número virtualmente infinito de serviços adicionais. (Afinal, a telefonia passou a ser mais uma aplicação IP…)
  2. É vital destacar que o tráfego de voz gerado pelos telefones IP é “nativamente IP”, o que equivale a dizer que após passar pelos processos iniciais de codificação e compressão (internamente aos telefones), a voz é encapsulada em datagramas IP para que possa ser então transportada através da rede.

** Artigos Relacionados:

** Para saber mais sobre o conceito de Colaboração:

http://www.cisco.com/go/collaboration

2 Comments

Filed under Português, Redes