Tag Archives: linkedin

Autenticação, Autorização e Accounting: Conceitos Fundamentais

O presente artigo é o primeiro de uma série que discute a utilização do conceito de identidade para a criação de regras de controle de acesso. Por ser um texto introdutório, começaremos justamente pelos conceitos mais básicos. Por exemplo:  – o que é identidade ?

Identidade pode ser definida como “um conjunto de características próprias e exclusivas de um sujeito”. (Vale registrar que, no universo de Redes e Segurança, o sujeito mais comum ainda é o username). Mas para que os processos de diferenciação entre os usuários possam ser iniciados, é necessário primeiramente validar a identidade apresentada. E, para entender como isso acontece, é fundamental conhecer a terminologia a seguir:

  • Autenticação: processo de verificação de uma identidade alegada, por meio de comparação das credenciais apresentadas pelo sujeito com outras pré-definidas. A combinação username/password é muito comum mas vários outros métodos estão disponíveis (certificados digitais, biometria, etc).
  • Autorização: processo que ocorre após a autenticação e que tem a função de diferenciar os privilégios atribuídos ao sujeito autenticado. Os atributos de autorização normalmente são definidos em grupos mantidos em um base de dados centralizada. (Cada sujeito herda as características do grupo a que pertence…)
  • Accounting: processo por meio do qual um equipamento de Rede que implementa uma política de acesso (accounting client), coleta informações sobre a atividade do elemento autenticado e as envia ao servidor de autenticação.

Balrog

A arquitetura AAA (Autenticação, Autorização e Accounting) define uma forma estruturada para integração dessas três funcionalidades.  Talvez seja mais fácil visualizar o papel de cada um dos componentes se os associarmos às questões que eles foram projetados para responder:

  • Autenticação: trata de responder a questão “quem é o usuário ?”
  • Autorização: tem a função de definir “o que um usuário (já autenticado) tem permissão de fazer” ?
  • Accounting: está relacionada com a questão “o que o usuário fez?”. Através desse processo o cliente de autenticação (equipamento de rede), coleta os dados de atividade do usuário e os envia ao servidor de accounting (o qual, normalmente, contempla todos os elementos AAA).

Listamos abaixo alguns cenários de uso dos conceitos AAA para controle de acesso a serviços de Rede.

  • Controle de acesso em ambientes LAN: permite habilitar o acesso (Layer 2) à porta física (no caso de switches) ou ao segmento áereo (no caso Wi-fi). Para viabilizar tal validação, foi criado o padrão IEEE 802.1X, disponível em Wireless APs e switches LAN modernos. Um cuidado a se tomar é que a expressão “suportar 802.1X” significa basicamente controlar o status “up/down” da porta após autenticação, o que é muito pouco diante das possibilidades da solução. Para ter os benefícios é vital especificar detalhadamente todas as funções AAA desejadas.
  • Controle de acesso em ambientes VPN de acesso remoto (client-to-site): verifica-se inicialmente o direito de montar o túnel e, a seguir, são validadas as credenciais daquele usuário (extended authentication).
  • Controle de acesso através de firewalls: podem ser citados como exemplo as funcionalidades Authentication Proxy (Cisco IOS) e Cut-through Proxy (Cisco ASA). Nesses casos, o firewall intercepta as requisições e aplica regras dinâmicas conforme permissões informadas pelo servidor AAA.
  • Controle de Acesso avançado através de Firewalls: especificamente para a família ASA, existem as possibilidades de criação de políticas de acesso baseadas em usuários/grupos da estrutura de diretório corporativo bem como o uso do atributo avançado “Security Group Tag”. (Mas esse tema certamente merece outro post).
  • Controle de acesso à Internet num ambiente corporativo, definindo políticas aceitáveis de uso conforme o grupo ao que o usuário pertença (por exemplo: funcionários regulares, sub-contratados e visitantes).

Outra aplicação importante da arquitetura AAA está relacionada ao controle de acesso administrativo aos equipamentos de Rede, tarefa essa para o qual o protocol o TACACS+ é otimizado. Recomando fortemente a leitura do texto “RADIUS e TACACS+: dois protocolos complementares“, para saber mais detalhes sobre o tema.

Bem, esse foi apenas um texto inicial. Em breve teremos outros posts tratando de usos específicos dos conceitos aqui discutidos.

** Notas:

  • Apesar de no mundo de TI o sujeito clássico ser um username, tem se tornado cada vez mais freqüente a utilização do termo identidade para definir elementos tais como: dispositivo (ou tipo de dispositivo) de onde partiu o acesso, localidade em que o usuário se encontra (rede corporativa, VPN, ou rede externa) ou aplicação solicitando acesso a um determinado recurso ou processo.
  • Dentre as opções existentes para obtenção do username, podemos citar o uso de um prompt apresentado por alguma aplicação ou a extração direta da algum atributo de um certificado digital.

** Artigos Relacionados:

Alguns cenários práticos de uso do conceito de Identidade: https://alexandremspmoraes.wordpress.com/tag/identity/

Para entender sobre a evolução do controle de acesso baseado em Identidade nos Firewalls, veja o seguinte artigo:

http://wp.me/p1loe7-l2

 

** Agradecimentos:

Registro aqui os agradecimentos ao meu grande amigo Andrey Lee por gentilmente ter produzido (e cedido) a ilustração usada nesse post (espero que se lembrem do filme 1 de “O Senhor dos Anéis”…)

5 Comments

Filed under Português, Segurança

Múltiplas camadas de defesa: A complementaridade do Firewall e do IPS

Não há muita discussão no que diz respeito à possibilidade de um Sistema de Prevenção de Intrusão (IPS) complementar o trabalho realizado por um firewall stateful. No entanto, é bem comum que se presenciem discussões de cunho quase filosófico sobre o posicionamento relativo de tais elementos em uma topologia de rede. O propósito do presente artigo é discutir as duas opções clássicas e caracterizar porque uma delas se mostra a mais natural. (Não que você precise concordar comigo… :-))

As duas disposições tradicionais são representadas na Figura 1, na qual os conceitos de “antes” e “depois” estão relacionados com o sentido de criação da conexão de uma máquina cliente para um servidor que se deseja proteger.

  • No primeiro arranjo, apenas o tráfego permitido pelo firewall é passado ao IPS, o qual, por sua vez, tem função de promover uma inspeção mais detalhada. Imagine, por exemplo, que se tente fazer um telnet, a partir de uma máquina externa, a um servidor web localizado na DMZ. O firewall poderia bloquear tal acesso sem necessidade de uso de qualquer funcionalidade mais elaborada do IPS.
  • Já no segundo modelo, todos os pacotes passariam inicialmente pelo IPS antes de chegarem à interface outside do firewall. Em algumas situações cheguei a ouvir que a razão de se ter o IPS na rede outside era permitir que ele “protegesse” o firewall ou que limitasse as novas conexões para tal dispositivo…

Figura 1: Posicionamento Relativo de Firewall e IPS

Refletindo por um instante sobre a atuação dos equipamentos de rede no contexto do modelo de camadas TCP/IP, podemos perceber que a complexidade de operação ( e conseqüente impacto em recursos tais como CPU) aumenta na seguinte ordem: Switch LAN (L2) < Roteador < Firewall < IPS.

Os sistemas IPS concentram seus recursos de análise nas camadas de rede, transporte e aplicação. Além disso mantém informação de estado (stateful pattern matching), realizam detecção de anomalias e, após tais tarefas, ainda precisam encaminhar os pacotes permitidos (na camada de enlace). Tantas atribuições acabam significando que a mais alta performance atingida por um IPS (num dado momento) é aproximadamente 4 ordens de grandeza menor que a do maior switch ou roteador da época e cerca de 1/10 da performance do maior firewall disponível. A última comparação é ainda mais favorável ao firewall se as métricas de conexões por segundo (CPS) e pacotes por segundo (pps) forem levadas em conta, conforme já discutido no artigo “Considerações sobre desempenho de Firewalls” (http://wp.me/p1loe7-15).

Uma outra forma de avaliar o cenário é pensar que se fosse possível construir um IPS com a mesma performance do maior roteador disponível, o custo por Gbps protegido pelo IPS seria certamente muito maior do que o custo por Gbps encaminhado pelo roteador. (Não há mágica aqui… Toda a capacidade de análise de padrões e contexto de um IPS exige módulos de hardware e software complexos, o que naturalmente acarreta custos extras).

Mas de onde vem a (eventual) percepção de que um IPS teria maior desempenho que o Firewall ? (– Seria natural ter o IPS antes do Firewall ?) Enxergo duas possíveis explicações:

  • Em um grande número de empresas a solução de IPS foi comprada (ou implementada) bem depois que o firewall já estava em uso. Essa diferença de fase entre os projetos de Firewall e IPS pode ter contribuído para que o IPS fosse selecionado entre as ofertas mais modernas do mercado ao passo que o firewall era um pouco antigo (no que diz respeito a desempenho).
  • Os parâmetros utilizados para análise provavelmente foram restritos a throughput (Gbps), de modo que foi negligenciado o fato de que um IPS tem natureza stateful. ( Conforme já mencionado, CPS é um atributo chave na avaliação de qualquer elemento stateful).

Uma opção que pode ser interessante para prover visibilidade adicional é representada na Figura 2. O IPS está localizado depois do firewall e um IDS (Intrusion Detection System) foi acrescentado à rede externa (em modo passivo, sem bloqueio de conexões). Desta forma pode-se obter informação sobre tentativas de ataque (inclusive direcionados a alvos entre o roteador e o firewall). O desafio é justamente ter uma equipe (tipicamente um Grupo de Resposta a Incidentes) que possa tirar proveito dos dados coletados.

Figura 2: Combinando Firewall, IPS e IDS

Se você ainda não está convencido sobre qual seria a opção mais natural, imagine a alegoria proposta na Figura 3. Considerando que o controle de passaporte (ou mesmo o check-in) corresponde ao firewall e que o sistema de raio-X represente o IPS, apenas quem teve acesso concedido ao portão de embarque será submetido à inspeção avançada. Lembre-se de sua experiência em aeroportos e considere a inversão dos processos: todos que chegam ao terminal passam inicialmente pelo raio-X, independentemente de terem viagem marcada…

Figura 3: Ilustrando a relação entre Firewall e IPS

O modelo que emprega o Sistema de Prevenção de Intrusão após o firewall é adequado tanto em projetos em que os equipamentos são distintos quanto naqueles em que o IPS consiste em um módulo do firewall. Na segunda opção é ainda comum que o firewall selecione os tipos de tráfego que serão direcionados ao IPS (em vez de se fazer o espelhamento completo), ação esta que também contribui para um melhor uso dos recursos de IPS.

** Artigos Relacionados:

** Recursos Adicionais:

1 Comment

Filed under Português, Segurança

Hello World: Simple LAN-to-LAN Flex VPN configuration

Having discussed the motivations behind FLEX VPN (http://wp.me/p1loe7-fJ) and presented information about positioning of Cisco IOS VPN solutions (http://wp.me/p1loe7-gy), it’s now time to jump to some practical scenarios.

Our site-to-site topology consists of two ISR G2 routers connected by a GRE interface, as depicted in Figures 1. The Integrated Services Routers rely on static routes to direct traffic to the tunnel and reach the protected networks (10.200.101.0/24 on the HUB1 site and 10.200.201.0/24 on SPOKE1 site). Authentication is performed by Pre-shared Keys (PSK) defined within a crypto ikev2 keyring. The main settings for this  environment are summarized for HUB1 and SPOKE1 on Figures 1 and 2, respectively.

This sample configuration is also useful to illustrate the overall structure of a FLEX VPN policy. The main building blocks are:

  • IKEv2 profile: basically defining how authentication is handled and what identities to consider. Settings such as the keyring (for PSK) and crypto trustpoint (for rsa-sig) are established here. The complete set of parameters contained in the IKEv2 profile are displayed with the show crypto ikev2 profile command.
  • IPSec Profile: determines the transform-set for IKE phase 2 (IPSec SA) and points to the IKEv2 profile. This type of profile is tied to the interface (similar to what we did for a crypto-map) by means of the tunnel protection ipsec profile command.

Other important entities (not shown in the configuration) are:

  • IKEv2 proposal: specifies the algorithms used to secure the IKE phase 1 SA. Take a look at Figure 3 and use the show crypto ikev2 proposal command to obtain more information about this policy component.
  • IKEv2 policy:  selects the IKEv2 proposal and VRFs where to place the VPN packets. Figure 4 registers the settings for the default IKEv2 policy.

Figure 1: Main Configs on router HUB1

It’s interesting to observe that FLEX provides extra flexibility with regards to the authentication process (that can even be asymmetric). Some possibilities are listed below:

  • The HUB can use a pre-shared key with all the spokes (which is not the ideal) but still have an individual key to authenticate each of the remotes. In previous models if the HUB had to share a key with all the spokes, that key would be known to all the routers involved. (And therefore it would be easy for spokes to spoof one another).
  • Digital certificates (rsa-sig method) can be used to authenticate both sides.
  • You can use digital certificates to authenticate the hub and PSK for the spokes.
  • There is also support for the Elliptic Curve Digital Signature Algorithm (ecdsa-sig) and for the Extensible Authentication Protocol (EAP).
  • Although you can configure only one local authentication method, multiple remote authentication methods are allowed, so that you can cope with different types of peers connecting to a certain router (normally the central element in your topology).

Figure 2: Main configs on router SPOKE1

Figure 3 provides visibility about the IKEv2 and IPSec SAs corresponding to our configuration. Notice that the show crypto session detail command is particularly useful to obtain summarized information about the Security Associations in place, interfaces in use for protected traffic and even encrypted/decrypted packets. The command also characterizes that the IPSec flow is protecting GRE packets (protocol 47) between HUB1 (172.20.20.11) and SPOKE1 (172.20.20.1).

Figure 3: Information about the IKEv2 and IPSec Security Associations

Figure 4 allows us to gain additional insight about this basic deployment. For instance, it reveals:

  • The default IKEv2 policy and how it binds to the default proposal (not shown in the configuration)
  • Some characteristics of the tunnel interface (source/destination, GRE-based, MTU and attached IPSec profile).
  • Another quick way of displaying encrypted and decrypted packets.

Figure 4: IKEv2 Policy, Tunnel Interface and Encrypted Packets

This is the very first article covering sample configurations… So stay tuned for more !

** Related Posts:

** Additional Reading:

Leave a comment

Filed under English, Security, VPN

GET VPN or Flex VPN…? Do I need both ?

– How Flex is GET ? – What do you get from FLEX ?

On two recent posts we summarized the concepts and motivations pertaining to Flex VPN and GET VPN, two important IPSec-based solutions offered by Cisco. But the availability of these two VPN paradigms may eventually generate some confusion: – Which way to go ? – Do I need both… ?

The figure below provides the backdrop for our current discussion. The two technologies are actually complementary:

  • GET VPN is designed for use within environments that do not have the public/private addressing issue and is well suited for materializing what I frequently name the Secure Intranet Service. FLEX is more flexible in that sense because it allows you to deal with either Intranet or Internet-related scenarios.
  • GET VPN is tunnel-less in nature and aims at scenarios in which the trust level is shared by VPN participants. An attractive by-product of not using tunnels: GET is very adequate to encrypt multicast, because the same distribution tree built in the WAN to forward the clear text multicast packets is equally available for ciphered ones. (Remember the IP Header Preservation inherent to GET…)
  • FLEX is tunnel-based and is able to handle environments involving dynamic (on demand) tunnel setup between spokes, EasyVPN style deployments (when the remote behaves as a hardware client) and many more.
  • GET VPN employs group-based Security Associations (SAs), as opposed to the point-to-point SAs that appear on tunnel-based VPNs (including the FLEX VPN framework). Again, this is possible as a result of the trust level parity that characterizes remote sites on INTRANET-only deployments. This is not a limitation of FLEX, which was conceived to cover a broader spectrum of VPN styles ( for which you cannot assume the same trust level for every site).
  • GET VPN is used for site-to-site only, whereas FLEX VPN is able to work with site-to-site and Remote Access (RA VPN) deployments at once.
  • GET VPN was designed to take advantage of the inherent full-mesh capabilities of MPLS networks. Of course FLEX can be employed on any-to-any clouds but, given that it is tunnel-based, its logical configuration possibilities will be hub-and-spoke and spoke-to-spoke.
  • FLEX VPN requires IKEv2 while GET VPN currently supports only IKEv1. (Of course there are plans to add IKEv2 to the GET VPN side of life at some point in time… :-)) The key information to remember: immediate IKEv2 support is less critical for GET (which presupposes private transport) than for FLEX VPN, a technology aimed at tunnel-based scenarios that involve Internet-based transport.

Flex VPN or GET VPN: quick comparison

The good news: if you have a security license on your Cisco ISR G2, the two options are available simultaneously allowing you to select the option that better fits the needs of your specific environment (eventually you will end up employing both). Some general guidelines are presented below:

  • For INTRANET-only site-to-site scenarios, GET may prove very appealing. Policy distribution and key management tasks are centralized and the Group SA concept is really convenient. The other key differentiator (associated with its tunnel-less nature) is encrypted multicast.
  • On the other hand, for any environment that includes external connections (INTERNET, EXTRANETS and the like), go FLEX. It provides an unified and structured approach for VPN creation and can handle so many connectivity options. And, remember, it relies on IKEv2 for SA negotiation (much more secure than its v1 counterpart).
  • If you want to stick to a single way of dealing with all VPNs (site-to-site and Remote Access), FLEX is the answer. Although not offering the Group SA, it covers everything. As discussed in the FLEX article, you can end up with a single block of configuration at the hub and be prepared to terminate any VPN connection.
  • If necessary, you can still leverage both technologies at the same router (GET for INTRANET site-to-site interconnection) and FLEX for all the rest.

** Notes:

** Related Posts:

Leave a comment

Filed under English, VPN

Building secure and scalable INTRANETS with GET VPN

The term Virtual Private Network (VPN) is employed to define technologies designed to reproduce the characteristics of a private network even when traffic is being transported over a shared infrastructure. The common motivation behind the various VPN options are to extend the reach of corporate networks in a secure and inexpensive manner.

But the word security has a broad meaning and may represent very distinct resources when considered from the standpoint of each of the VPN technologies. For instance, two of the main categories of VPNs (IPSec and MPLS-VPN) are optimized to solve complementary problems and present challenges that are also complementary.  A brief summary is presented below:

  • The IPSec Framework provides answers for questions such as data confidentiality, integrity, peer authentication and management of cryptographic keys. And, interesting enough, all of these tasks are accomplished by means of standardized protocols and algorithms, a fact that contributed to render IPSec almost omnipresent when the subject is VPN. On the other hand, classic IPSec uses point-to-point negotiations between the communicating parties, which brings significant challenges, mainly in terms of routing, when deployed on a large network.
  • The MPLS-VPN service, by its own nature, provides logical segmentation of the transport network and optimized routing (any-to-any) but establishes no definition in what refers to the typical problems solved by IPSec (confidentiality, integrity and the like).

Keeping in mind the capabilities just presented, let’s consider the demand of building the Intranet of a large company that uses Unified Communications among its sites (the traffic nature is any-to-any) and that, in order to comply with market regulations, is supposed to take advantage of the services beneath the IPSec umbrella.

In an initial analysis, two simple-minded solutions could be provided:

  • Build IPSec Security Associations (SAs) between each remote entity and HQ. Well, this approach would not be satisfactory because it could compromise the acceptable end-to-end delay budget for voice traffic (150 ms). Moreover we would be giving up the full-mesh appeal of MPLS networks.
  •  Create sessions betwen each pair of remote sites, so that you keep inter-branch traffic from crossing HQ. Besides being almost unmanageable from a configuration point of view, such a scenario would require that each VPN gateway in the remote location (typically a router) supported a very large of concurrent tunnels, thus impacting the cost.

If the mere superimposition of IPSec on MPLS does not meet the specified project goals, would it be possible to develop a new technology that could benefit from the IPSec security services without losing the optimized connectivity provided by MPLS ?

As a matter of fact, this was exactly what Cisco did. Building upon RFC 3507 (Group Domain of Interpretation – GDOI) and assuming that on Intranets you don’t need to worry about the private/public address issue, the Group Encrypted Transport VPN (GET VPN) came to existence. The main charateristics of GET VPN are listed in the following:

  • Definition of group-based Security Associations instead of the traditional point-to-point SAs. This choice is justifiable because we are dealing with Intranets, in which the same degree of trustworthiness can be assumed for the remote routers.
  • The access control function, which allows a VPN gateway (Group Member or GM in the GET VPN context) to be accepted in a given group, is performed by an element called the Key Server (KS). The KS is also responsible for centrally distributing the cipher keys and encryption policies that will be used by the GMs.
  • IP Header Preservation in the encrypted packet, without changing the standard ESP format. This means that a GET VPN packet is a particular case of IPSec and, therefore, the algorithms and hardware in place can be reused.

GET VPN: IP Header Preservation

Some direct results of the basic GET VPN definitions:

  1. IP Header preservation ensures that the encrypted packets use the same routing table available for the clear text traffic, thus avoiding the creation of a new layer of routing for the VPN packets.
  2. The DSCP information is automatically copied to the external IP header and your Quality of Service (QoS) investments (classification and marking) remain valid for the VPN traffic.
  3. It is possible to account for network utilization on a per-user basis, irrespectively of packets being encrypted. This represents an advance in terms of visibility when compared to classic IPSec.
  4. Because Group Members (GMs) own the the key to decrypt the packets sent by any member of the group, the distribution of encrypted multicast traffic becomes natural ( in an identical manner that would be employed for clear text). It is important to highlight that GET VPN is the first technology to truly deliver on the promise of encrypting IP multicast (without requiring any tunneling artifice such as GRE).
  5. The management of encryption policies becomes much easier because it is centrally conducted by the Key Server. This is particularly relevant for Service Providers that will not need to configure VPN tunnels and interesting traffic definitions in hundreds of devices anymore.

Relationships between GET VPN elements

An important aspect to keep in mind is that a router enabled for GET VPN still comes with the classic IPSec solutions provided by Cisco. For example, you can leverage GET VPN to securely build your Intranet and traditional IPSec to establish a VPN connection though the Internet. Another fact to be aware of is that the same router may participate in multiple distinct groups, thus providing a simple solution to isolate departments within the same company.

** Additional Reading:

** Related Posts:

Leave a comment

Filed under English, VPN

Flex VPN: A new paradigm for IPSec deployment on Cisco Routers

Virtual Private Networks (VPNs) are a classic resource designed to securely and inexpensevely extend the reach of corporate networks. Several options available are built on top of IPSec, a framework that deals with the tasks of ensuring Confidentiality, Integrity, Authentication of origin and secure key distribution for VPNs.

Some of the notable strengths of IPSec are its independence of the transport (UDP, TCP or raw IP) and the provision for easy replacement of one or more of its components (such as the hash functions and cryptographic algorithms) so that it can keep up with hardware evolution and what it means in terms of feasibility of brute force attacks.

If you are familiar with Cisco IOS software, you probably heard terms such as Classic IPSec, IPSec/GRE, Virtual Tunnel Interface (VTI), EasyVPN, Dynamic Multipoint VPN (DMVPN)… But, which of these site-to-site VPN options available on Cisco IOS software should you select ? Well, I will start by saying that each of the technologies was developed to solve specific problems:

  • Crypto Maps are the initial/legacy solution that was devised before IPsec was even an RFC. Although the services available are very basic they do help on interoperability.
  • VTI brings a logical interface to IPSec deployments without the need of using Generic Routing Encapsulation (GRE).
  • EasyVPN allows branch routers (or other types of VPN appliances) to behave as hardware clients that are centrally configured by a VPN concentrator.
  • DMVPN provides the capability of dynamically establishing tunnels between spokes on a hub-and-spoke scenario.

The good news is that Cisco now offers a unified way of dealing with all these options, allowing your network to be prepared to simultaneously handle the different VPN models. The new approach is called Flex VPN and, as the name suggests, is really flexible in terms of configuration possibilities:

  • A router implementing Flex VPN may be configured to expect connections in any of these site-to-site forms: VTI, EasyVPN, GRE/IPSec, DMVPN (and even Classic IPSec tunnels, in case you need to guarantee interoperability with other vendors or older Cisco routers).
  • Flex VPN can deal with remote access either using the Windows 7 native client or a dedicated client such as Cisco AnyConnect.
  • Flex VPN supports both IPv4 and IPv6 implementations.
  • Authentication and Authorization may be performed by means of a local database or using RADIUS (more convenient for Service Provider environments, which typically require multi tenancy).

A critical point in which Flex VPN does not allow flexibility, though, is for Security Association (SA) negotiation and establishment. Flex VPN requires the use of the version 2 of the Internet Key Exchange protocol (IKEv2), a more secure option than the original implementation (IKEv1). But, instead of getting frustrated with the obligation of moving to IKEv2, I hope that you become motivated to start learning Flex VPN. After all, the return on investment is significant: you will not only have a much better control plane protocol in place but also will have just one VPN to support !

It is relevant to emphasize that IKEv2, by design, is not backward compatible with IKEv1. And, as such, if you want to benefit from the increased security in IKEv2, you will need to reconfigure your IPSec VPNs anyway…

To finish this quick post, I present a figure that shows some possibilities associated with the Flex VPN approach. Future articles will cover specific deployment scenarios… Stay tuned !

Summary of Flex VPN Options

** Notes:

  • Backward compatibility may sound attractive for network protocols (remember the example of RIPv1/RIPv2) but for security features it is rather questionable. If IKEv2 was allowed to interoperate with its v1 counterpart, you would be giving up the flexibility and security that v2 provides.
  • Even though it is not possible to enable IKEv1 as part of the Flex VPN framework, you can gradually migrate your IKEv1 configurations (crypto isakmp syntax) to IKEv2/FlexVPN.

** Further Reading:

1 Comment

Filed under English, Security, VPN

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

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

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

3 Comments

Filed under Português, Redes

RADIUS e TACACS+: dois protocolos complementares

Além de mostrar que os protocolos RADIUS e TACACS+ são complementares (e não concorrentes), o presente texto tem a intenção de esclarecer alguns erros conceituais envolvendo tais protocolos.

Diante da confusão clásssica, resolvi montar uma espécie de sessão “fatos e mitos” para facilitar o entendimento:

  • O protocolo TACACS (RFC 1492) já não é mais utilizado em implementações práticas, pois não oferece nenhuma vantagem significativa em relação ao RADIUS. O TACACS+ é uma evolução do TACACS que, dentre outras coisas, utiliza transporte TCP (em vez de UDP, como é o caso do TACACS). Desta forma não faz sentido solicitar “TACACS”, pensando-se em obter os benefícios do TACACS+.
  • Apesar de ter sido criada pela Cisco, a especificação do TACACS+ (que data de 1997 !) está documentada  sob a forma de ‘draft’ no site do IETF, permitindo que vários outros fabricantes desenvolvam o suporte a tal protocolo. E isso de fato aconteceu. Muitos fabricantes de dispositivos de redes (tais como roteadores, switches e firewalls) declaram em seus data sheets o suporte a TACACS+.
  • Alguns fabricantes criaram uma implementação inspirada no TACACS+ que foi batizada como HWTACACS. A despeito do novo nome, os clientes HWTACACS suportam as mesmas características do TACACS+ e são, inclusive, compatíveis com o servidor TACACS+ mais  usado no mercado (Cisco Secure Access Control System – CS ACS).
  • O protocolo RADIUS foi desenvolvido e otimizado para fazer controle de acesso a serviços de Rede. É bem natural para o RADIUS, por exemplo, diferenciar os perfis de acesso à Rede em ambientes dial-up, VPNs de acesso remoto (tais como IPSec e SSL VPN) e redes sem fio (ou cabeadas) que usam 802.1X.
  • Por não separar os processos de Autenticação e Autorização (dentro da arquitetura AAA), o RADIUS é mais adequado para atribuir um perfil de autorização (authorization profile) que permaneça ativo no equipamento de rede durante todo o tempo de conexão do usuário. O RADIUS não é usado para tarefas interativas de autorização durante a sessão.
  • Exemplos de perfis atribuídos com RADIUS são: enquanto usuários do Grupo 1 têm acesso a FTP e Telnet, usuários pertencentes ao Grupo 2 podem usar web (HTTP) e e-mail (SMTP).
  • O TACACS+ separa os processos de Autenticação e Autorização e foi otimizado para controle de comandos de configuração e monitorização ( e até dos argumentos desses comandos). Este tipo de cenário de aplicação do TACACS+ costuma ser chamado Controle de Acesso Administrativo a Equipamentos de Rede (em oposição a controle de acesso a serviços de rede).
  • Cada comando disponível em um equipamento que suporte cliente TACACS+ é autorizado individualmente pelo servidor antes que possa ser executado. Imagine a alternativa (nada flexível e gerenciável) de fazer um download de todas as possíveis combinações de comandos e argumentos sob a forma de um authorization profile... (Especialmente em equipamentos que possuam uma miríade de funcionalidades tais como os roteadores ISR da Cisco).
  • Todas as definições de comandos de administração dos equipamentos são efetuadas de forma centralizada no servidor TACACS+. Isso é particularmente importante em redes com grande número de ativos de rede. (Considere, por outro lado, a opção de definir os comandos em cada equipamento de Rede…)
  • Com TACACS+ é possível permitir, por exemplo, que um grupo de usuários tenha acesso de configuração aos comandos relativos a Telefonia IP em um conjunto de equipamentos e que possa apenas visualizar as informações de rede em um segundo conjunto. A flexibilidade é total ! ( E você não está mais sujeito a soluções do tipo “tudo ou nada”.)
  • Se você deseja dispor de toda a capacidade de controle de acesso administrativo provida pelo TACACS+, é necessário deixar claro, em uma eventual RFP, que devem ser implementadas integralmente as funções de AAA para tal protocolo (especificamente no âmbito de autorização e accounting de comandos). Falar simplesmente que um equipamento “deve suportar TACACS+” não garante que os serviços AAA de interesse sejam fornecidos.

Após essa breve compilação sobre as características dos protocolos, gostaria de enfatizar alguns pontos:

  • A grande maioria dos equipamentos de Rede suportam simultaneamente os clientes RADIUS e TACACS+. Em vez de tentar encará-los como concorrentes, convém entender as aplicações para as quais são otimizados e fazer a seleção correta. É perfeitamente normal (e aconselhável), por exemplo, usar RADIUS num ambiente 802.1X para controlar o acesso de qualquer usuário  a uma porta física do switch e um processo TACACS+, separado, para controlar os comandos que os usuários com privilégio de administrador de rede podem executar no switch (para configurá-lo e operá-lo).
  • O servidor AAA mais difundido do mercado, CS-ACS, suporta a operação simultânea como servidor RADIUS e TACACS+. Isso permite que o CS-ACS seja usado tanto para as funções de controle de acesso a serviços de rede como para as tarefas de controle de acesso administrativo a equipamentos de rede.

Para facilitar a obtenção de informações adicionais sobre o assunto, listo a seguir uma coletânea de links úteis:

  1. TACACS+ and RADIUS Comparison (http://www.cisco.com/en/US/tech/tk59/technologies_tech_note09186a0080094e99.shtml)
  2. TACACS+ Protocol Version 1.78 (http://tools.ietf.org/html/draft-grant-tacacs-02)
  3. Original TACACS RFC (http://tools.ietf.org/html/rfc1492)
  4. Além da discussão teórica sobre a arquitetura AAA (incluindo os cenários mais adequados para o uso de RADIUS e TACACS+), o capítulo 14 do livro Cisco Firewalls (Identity on Cisco Firewalls) traz inúmeros exemplos práticos de uso de AAA em roteadores e Firewalls Cisco http://www.ciscopress.com/bookstore/product.asp?isbn=1587141094

** Artigos Relacionados:

Leave a comment

Filed under Português, Segurança