Este artigo é o terceiro de uma série de artigos intitulados "Como colocar a infraestrutura de rede sob seu controle". O conteúdo de todos os artigos da série e os links podem ser encontrados aqui .



Não faz sentido falar sobre a eliminação completa dos riscos à segurança. Em princípio, não podemos reduzi-los a zero. Você também precisa entender que, à medida que nos esforçamos para tornar a rede cada vez mais segura, nossas soluções se tornam cada vez mais caras. Você precisa encontrar um compromisso razoável para sua rede entre preço, complexidade e segurança.

Obviamente, o design de segurança é organicamente integrado à arquitetura geral e as soluções de segurança usadas afetam a escalabilidade, confiabilidade, capacidade de gerenciamento, ... infraestrutura de rede, que também devem ser levadas em consideração.

Mas lembro que agora não estamos falando sobre a criação de uma rede. De acordo com nossas condições iniciais , já escolhemos um projeto, selecionamos equipamentos e criamos uma infraestrutura e, nesse estágio, devemos, se possível, “viver” e encontrar soluções no contexto da abordagem escolhida anteriormente.

Nossa tarefa agora é identificar os riscos associados à segurança no nível da rede e reduzi-los a um valor razoável.

Auditoria de segurança de rede

Se sua organização implementou processos ISO 27k, as auditorias de segurança e as alterações de rede devem ser organicamente integradas nos processos gerais, como parte dessa abordagem. Mas esses padrões ainda não são sobre soluções específicas, nem sobre configuração, nem sobre design ... Não há dicas definidas, não existem padrões que determinam detalhadamente o que sua rede deve ser; essa é a complexidade e a beleza dessa tarefa.

Eu destacaria várias possíveis auditorias de segurança de rede:

• auditoria de configuração de equipamentos (proteção)
• projeto de auditoria de segurança
• auditoria de acesso
• auditoria de processo

Auditoria de configuração de hardware (proteção)

Na maioria dos casos, esse parece ser o melhor ponto de partida para auditar e melhorar a segurança da sua rede. IMHO, esta é uma boa demonstração da lei de Pareto (20% do esforço fornece 80% do resultado, e os 80% restantes do esforço representam apenas 20% do resultado).

O ponto principal é que geralmente temos recomendações de fornecedores sobre as "melhores práticas" de segurança ao configurar o equipamento. Isso é chamado de endurecimento.

Você também pode frequentemente encontrar um questionário (ou compor você mesmo) com base nessas recomendações, que o ajudarão a determinar como sua configuração de hardware corresponde a essas "melhores práticas" e a fazer alterações na sua rede de acordo com o resultado. Isso permitirá que você reduza facilmente os riscos de segurança, praticamente sem nenhum custo.

Alguns exemplos para alguns sistemas operacionais da Cisco.

Endurecimento da configuração do Cisco IOS
Endurecimento da configuração do Cisco IOS-XR
Endurecimento da configuração do Cisco NX-OS
Lista de verificação de segurança da linha de base da Cisco

Com base nesses documentos, uma lista de requisitos de configuração para cada tipo de equipamento pode ser criada. Por exemplo, para um Cisco N7K VDC, esses requisitos podem ser assim.

Assim, os arquivos de configuração para diferentes tipos de equipamentos ativos da sua infraestrutura de rede podem ser criados. Além disso, manualmente ou usando a automação, você pode "enviar" esses arquivos de configuração. Como automatizar esse processo será discutido em detalhes em outra série de artigos sobre orquestração e automação.

Design de auditoria de segurança

Normalmente, uma rede corporativa de uma forma ou de outra contém os seguintes segmentos:

• DC (DMZ de serviços públicos e datacenter da intranet)
• Acesso à Internet
• VPN de acesso remoto
• Wan edge
• Branch
• Campus (escritório)
• Core

Os nomes são retirados do modelo Cisco SAFE , mas não é necessário, é claro, vincular-se a esses nomes e a este modelo. Ainda assim, quero falar sobre a essência e não ficar atolado em formalidades.

Para cada um desses segmentos, os requisitos para o nível de segurança, riscos e, consequentemente, decisões serão diferentes.

Consideraremos cada um deles individualmente para problemas que você pode encontrar em termos de design de segurança. É claro, repito novamente que este artigo não afirma estar completo, o que neste tópico realmente profundo e multifacetado não é fácil de alcançar (se possível), mas reflete minha experiência pessoal.

Não há solução perfeita (pelo menos por enquanto). É sempre um compromisso. Mas é importante que a decisão de aplicar essa ou aquela abordagem seja tomada conscientemente, com o entendimento de seus prós e contras.

Data center

O segmento de segurança mais crítico.
E, como sempre, também não há solução universal. Tudo depende dos requisitos de rede.

Um firewall é necessário ou não?

Parece que a resposta é óbvia, mas nem tudo está tão claro quanto parece. E sua escolha pode ser afetada não apenas pelo preço .

Exemplo 1. Atrasos.

Se entre alguns segmentos da rede a baixa latência for um requisito essencial, o que, por exemplo, é verdadeiro no caso de uma troca, entre esses segmentos não poderemos usar firewalls. É difícil encontrar estudos sobre atrasos nos firewalls, mas apenas alguns modelos de comutador podem fornecer atrasos inferiores ou aproximadamente a 1 mksec; portanto, acho que se os microssegundos são importantes para você, os firewalls não são para você.

Exemplo 2. Desempenho.

A largura de banda dos principais switches L3 é geralmente uma ordem de magnitude maior que a largura de banda dos firewalls mais produtivos. Portanto, no caso de tráfego de alta intensidade, você provavelmente também precisará permitir que esse tráfego desvie de firewalls.

Exemplo 3. Confiabilidade.

Os firewalls, especialmente os modernos NGFW (Next-Generation FW), são dispositivos complexos. Eles são significativamente mais complexos que os switches L3 / L2. Eles fornecem um grande número de serviços e opções de configuração, portanto, não é de surpreender que sua confiabilidade seja muito menor. Se a continuidade do serviço for crítica para a rede, talvez seja necessário escolher o que levará a uma melhor disponibilidade - segurança do firewall ou a simplicidade de uma rede construída em switches (ou vários tipos de fábricas) usando ACLs comuns.

No caso dos exemplos acima, você provavelmente (como de costume) precisará encontrar um compromisso. Olhe para as seguintes soluções:

• se você decidir não usar firewalls dentro do datacenter, precisará considerar como limitar o acesso ao perímetro o máximo possível. Por exemplo, você pode abrir apenas as portas necessárias da Internet (para tráfego do cliente) e o acesso administrativo ao datacenter apenas dos hosts de salto. Nos hosts de salto, execute todas as verificações necessárias (autenticação / autorização, antivírus, registro em log, ...)
• você pode usar o particionamento lógico da rede do datacenter em segmentos, semelhante ao esquema descrito no exemplo PSEFABRIC p002 . Nesse caso, o roteamento deve ser configurado para que o tráfego sensível a atrasos ou tráfego de alta intensidade "entre" em um segmento (no caso de p002, VRF-a) e não passe pelo firewall. O tráfego entre diferentes segmentos ainda passará pelo firewall. Você também pode usar o vazamento de rota entre VRFs para evitar o redirecionamento de tráfego através do firewall.
• Você também pode usar o firewall no modo transparente e apenas para as VLANs em que esses fatores (atraso / desempenho) não são significativos. Mas você precisa estudar cuidadosamente as limitações associadas ao uso desse mod para cada fornecedor
• você pode considerar aplicar uma arquitetura da cadeia de serviços. Isso permitirá que você direcione apenas o tráfego necessário através do firewall. Teoricamente, parece bonito, mas nunca vi essa solução em produção. Testamos a cadeia de serviços do Cisco ACI / Juniper SRX / F5 LTM há cerca de 3 anos, mas naquela época essa solução nos parecia "bruta"

Nível de proteção

Agora você precisa responder à pergunta de quais ferramentas deseja usar para filtrar o tráfego. Aqui estão alguns dos recursos que geralmente estão presentes no NGFW (por exemplo, aqui ):

• firewall com estado (padrão)
• firewall de aplicativos
• prevenção de ameaças (antivírus, anti-spyware e vulnerabilidade)
• Filtragem de URL
• filtragem de dados (filtragem de conteúdo)
• bloqueio de arquivo (bloqueio de tipos de arquivo)
• proteção dos

E também nem tudo está claro. Parece que quanto maior o nível de proteção, melhor. Mas você também precisa considerar que

• quanto mais funções de firewall acima você usar, mais naturalmente será mais caro (licenças, módulos adicionais)
• o uso de certos algoritmos pode reduzir significativamente a taxa de transferência do firewall, bem como aumentar os atrasos, veja, por exemplo, aqui
• Como qualquer solução complexa, o uso de métodos complexos de proteção pode reduzir a confiabilidade da sua solução, por exemplo, ao usar o firewall do aplicativo, deparei-me com o bloqueio de alguns aplicativos de trabalho bastante padrão (dns, smb)

Você, como sempre, precisa encontrar a melhor solução para sua rede.

É impossível responder inequivocamente à pergunta sobre quais funções de proteção podem ser necessárias. Primeiro, porque é claro que depende dos dados que você transfere ou armazena e está tentando proteger. Em segundo lugar, na realidade, muitas vezes a escolha dos remédios é uma questão de fé e confiança no fornecedor. Você não conhece os algoritmos, não sabe a eficácia deles e não pode testá-los completamente.

Portanto, em segmentos críticos, uma boa solução pode ser usar ofertas de diferentes empresas. Por exemplo, você pode ativar o antivírus em um firewall, mas também usar a proteção antivírus (de outro fabricante) localmente nos hosts.

Segmentação

Essa é uma segmentação lógica da rede do datacenter. Por exemplo, dividir em VLANs e sub-redes também é uma segmentação lógica, mas não a consideraremos devido à sua obviedade. A segmentação é interessante, considerando entidades como zonas de segurança FW, VRF (e seus análogos em relação a vários fornecedores), dispositivos lógicos (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, ...), ...

Um exemplo dessa segmentação lógica e o design do data center atualmente necessário é dado na p002 do projeto PSEFABRIC .

Depois de definir as partes lógicas da sua rede, você pode descrever melhor como o tráfego flui entre diferentes segmentos, em quais dispositivos a filtragem será realizada e de que maneira.

Se sua rede não possui um particionamento lógico claro e as regras para a aplicação de políticas de segurança para diferentes fluxos de dados não são formalizadas, isso significa que, quando você abre um ou outro acesso, é forçado a resolver esse problema e, com uma alta probabilidade, sempre o resolve. de maneiras diferentes.

Geralmente, a segmentação é baseada apenas nas zonas de segurança do FW. Então você precisa responder às seguintes perguntas:

• de quais zonas de segurança você precisa
• qual nível de proteção você deseja aplicar a cada uma dessas zonas
• se o tráfego dentro da zona será permitido por padrão
• caso contrário, quais políticas de filtragem de tráfego serão aplicadas em cada zona
• quais políticas de filtragem de tráfego serão aplicadas para cada par de zonas (origem / destino)

TCAM

Muitas vezes, há o problema de TCAM (memória endereçável de conteúdo ternário) insuficiente, tanto para roteamento quanto para acessos. IMHO, essa é uma das questões mais importantes na escolha do equipamento, portanto, você precisa tratar essa questão com o grau adequado de precisão.

Exemplo 1. Tabela de Encaminhamento TCAM.

Vamos dar uma olhada no firewall de Palo Alto 7k .
Vemos que o tamanho da tabela de encaminhamento IPv4 * = 32K
Ao mesmo tempo, esse número de rotas é comum para todos os VSYS.

Suponha que você decida usar 4 VSYSs de acordo com o seu design.
Cada um desses VSYSs do BGPS é conectado a dois PEs da nuvem MPLS que você usa como BB. Assim, 4 VSYSs trocam todas as rotas específicas entre si e têm uma tabela de encaminhamento com aproximadamente os mesmos conjuntos de rotas (mas NHs diferentes). Porque cada VSYS possui 2 sessões BGP (com as mesmas configurações); cada rota recebida via MPLS possui 2 NH e, consequentemente, 2 entradas FIB na Tabela de encaminhamento. Se assumirmos que esse é o único firewall no data center e ele deve saber sobre todas as rotas, isso significa que o número total de rotas em nosso data center não pode ser superior a 32K / (4 * 2) = 4K.

Agora, se assumirmos que temos 2 data centers (com o mesmo design) e queremos usar VLANs "esticadas" entre data centers (por exemplo, para vMotion), para resolver o problema de roteamento, devemos usar rotas de host, mas isso significa que, para dois data centers, não teremos mais de 4096 hosts possíveis e, é claro, isso pode não ser suficiente.

Exemplo 2. ACL TCAM.

Se você planeja filtrar o tráfego em switches L3 (ou outras soluções usando switches L3, por exemplo, Cisco ACI), preste atenção às ACLs do TCAM ao escolher o equipamento.

Suponha que você queira controlar o acesso nas interfaces Cisco Catalyst 4500 SVI. Como você pode ver neste artigo , você pode usar apenas 4096 linhas de TCAM para controlar o tráfego de saída (e de entrada) nas interfaces. O que ao usar o TCAM3 fornecerá cerca de 4000 mil ACEs (linhas ACL).

Se você se deparar com o problema de TCAM insuficiente, primeiro, é claro, é necessário considerar a possibilidade de otimização. Portanto, no caso de um problema com o tamanho da tabela de encaminhamento, é necessário considerar a possibilidade de agregar rotas. No caso de um problema com o tamanho do TCAM para acessos - auditoria de acessos, exclusão de registros obsoletos e sobrepostos, bem como, possivelmente, uma revisão do procedimento de abertura de acessos (será discutido em detalhes no capítulo sobre auditoria de acesso).

Alta disponibilidade

A questão é se deve usar HA para firewalls ou colocar duas caixas independentes "em paralelo" e no caso de uma delas travar o tráfego de rota pela segunda?

Parece que a resposta é óbvia - use HA. A razão pela qual essa pergunta surge, no entanto, é que, infelizmente, os teóricos e os anúncios 99 e alguns nove após o ponto decimal da porcentagem de acessibilidade na prática se mostram muito menos positivos. O HA é logicamente algo bastante complicado, e em equipamentos diferentes e com diferentes fornecedores (não houve exceções), detectamos problemas e bugs e desligamos o serviço.

No caso de usar HA, você poderá desativar os nós individuais, alternar entre eles sem interromper o serviço, o que é importante, por exemplo, ao atualizar, mas você não tem a menor chance de os dois nós se romperem ao mesmo tempo e também que os próximos A atualização não será tão tranquila quanto o fornecedor promete (esse problema pode ser evitado se você tiver a oportunidade de testar a atualização em equipamentos de laboratório).

Se você não usa HA, então, do ponto de vista de dano duplo, seus riscos são muito menores (já que você possui 2 firewalls independentes), mas porque Como as sessões não são sincronizadas, sempre que ocorre a alternância entre esses firewalls, você perde tráfego. Você pode, é claro, usar firewall sem estado, mas o significado do uso de um firewall é amplamente perdido.

Portanto, se como resultado de uma auditoria você encontrar firewalls solitários e pensar em aumentar a confiabilidade de sua rede, o HA, é claro, é uma das soluções recomendadas, mas você deve levar em conta as desvantagens associadas a essa abordagem e, talvez, apenas para seus outra solução seria mais apropriada.

Conveniência em gerenciamento (gerenciabilidade)

Em princípio, o HA também é sobre gerenciamento. Em vez de configurar 2 caixas individualmente e resolver o problema de sincronizar configurações, você as gerencia de várias maneiras, como se tivesse um dispositivo.

Mas talvez você tenha muitos datacenters e muitos firewalls, então essa questão chega a um novo nível. E a questão não é apenas sobre configuração, mas também sobre

• configurações de backup
• atualizações
• atualizações
• monitoramento
• registro

E tudo isso pode ser resolvido por sistemas de gerenciamento centralizados.

Por exemplo, se você usa os firewalls da Palo Alto, o Panorama é uma solução.

Para ser continuado.