Este artigo é o terceiro de uma série de artigos “Como assumir o controle de sua infraestrutura de rede”. O conteúdo de todos os artigos da série e links podem ser encontrados aqui.

Não faz sentido falar em eliminar completamente os riscos de segurança. Em princípio, não podemos reduzi-los a zero. Também precisamos de compreender que à medida que nos esforçamos para tornar a rede cada vez mais segura, as nossas soluções estão a tornar-se cada vez mais caras. Você precisa encontrar um equilíbrio entre custo, complexidade e segurança que faça sentido para sua rede.

É claro que o design de segurança está organicamente integrado na arquitectura global e as soluções de segurança utilizadas afectam a escalabilidade, fiabilidade, capacidade de gestão, ... da infra-estrutura de rede, que também deve ser tida em conta.

Mas deixe-me lembrar que agora não estamos falando em criar uma rede. De acordo com o nosso condições iniciais já escolhemos o design, selecionamos os equipamentos e criamos a infraestrutura, e nesta fase, se possível, devemos “viver” e encontrar soluções no contexto da abordagem previamente escolhida.

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

Auditoria de segurança de rede

Se a sua organização implementou processos ISO 27k, então as auditorias de segurança e as mudanças de rede devem se encaixar perfeitamente nos processos gerais dentro desta abordagem. Mas esses padrões ainda não tratam de soluções específicas, nem de configuração, nem de design... Não existem conselhos claros, nem padrões ditando em detalhes como deve ser sua rede, 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 equipamento (endurecimento)
• auditoria de projeto de segurança
• auditoria de acesso
• auditoria de processo

Auditoria de configuração de equipamentos (endurecimento)

Parece que na maioria dos casos este é 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 produz 80% do resultado, e os 80% restantes do esforço produzem apenas 20% do resultado).

O resultado final é que geralmente temos recomendações de fornecedores sobre “melhores práticas” de segurança ao configurar equipamentos. Isso é chamado de “endurecimento”.

Muitas vezes você também pode encontrar um questionário (ou criar você mesmo) com base nessas recomendações, que o ajudará a determinar até que ponto a configuração do seu equipamento está em conformidade com essas “melhores práticas” e, de acordo com o resultado, fazer alterações em sua rede . Isso permitirá que você reduza significativamente os riscos de segurança com bastante facilidade e praticamente sem nenhum custo.

Vários exemplos para alguns sistemas operacionais Cisco.

Proteção de configuração do Cisco IOS
Proteção de configuração do Cisco IOS-XR
Proteção de configuração do Cisco NX-OS
Lista de verificação de segurança básica da Cisco

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

Desta forma, podem ser criados arquivos de configuração para diferentes tipos de equipamentos ativos em sua infraestrutura de rede. A seguir, manualmente ou usando automação, você pode “carregar” esses arquivos de configuração. Como automatizar esse processo será discutido detalhadamente em outra série de artigos sobre orquestração e automação.

Auditoria de projeto de segurança

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

• DC (Data Center de serviços públicos DMZ e intranet)
• Acesso à Internet
• VPN de acesso remoto
• Borda WAN
• Ramo
• Campus (Escritório)
• núcleo

Títulos retirados de Cisco SEGURO modelo, mas não é necessário, evidentemente, estar ligado precisamente a estes nomes e a este modelo. Mesmo assim, quero falar sobre a essência e não me prender a formalidades.

Para cada um destes segmentos, os requisitos de segurança, os riscos e, consequentemente, as soluções serão diferentes.

Vejamos cada um deles separadamente para identificar os problemas que você pode encontrar do ponto de vista do design de segurança. Claro, repito mais uma vez que este artigo não pretende de forma alguma ser completo, o que não é fácil (se não impossível) de conseguir neste tema verdadeiramente profundo e multifacetado, mas reflete a minha experiência pessoal.

Não existe uma solução perfeita (pelo menos ainda não). É sempre um compromisso. Mas é importante que a decisão de utilizar uma abordagem ou outra seja tomada de forma consciente, com uma compreensão dos seus prós e contras.

Data Center

O segmento mais crítico do ponto de vista da segurança.
E, como sempre, também não existe uma solução universal aqui. Tudo depende muito dos requisitos da rede.

Um firewall é necessário ou não?

Parece que a resposta é óbvia, mas nem tudo é tão claro como pode parecer. E sua escolha pode ser influenciada não só preço.

Exemplo 1. Atrasos.

Se a baixa latência for um requisito essencial entre alguns segmentos de rede, o que é verdade, por exemplo, no caso de uma troca, então não poderemos utilizar firewalls entre esses segmentos. É difícil encontrar estudos sobre latência em firewalls, mas poucos modelos de switch podem fornecer latência menor ou da ordem de 1 mksec, então acho que se microssegundos são importantes para você, então os firewalls não são para você.

Exemplo 2. Atuação.

A taxa de transferência dos principais switches L3 é geralmente uma ordem de magnitude maior que a taxa de transferência dos firewalls mais poderosos. Portanto, no caso de tráfego de alta intensidade, você provavelmente também terá que permitir que esse tráfego contorne os firewalls.

Exemplo 3. Confiabilidade.

Firewalls, especialmente NGFW (Next-Generation FW) modernos, são dispositivos complexos. Eles são muito mais complexos que os switches L3/L2. Eles oferecem um grande número de serviços e opções de configuração, por isso não é surpreendente 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 com um firewall ou a simplicidade de uma rede construída em switches (ou vários tipos de malhas) usando ACLs regulares.

No caso dos exemplos acima, você provavelmente (como sempre) terá que encontrar um meio-termo. Procure as seguintes soluções:

• se você decidir não usar firewalls dentro do data center, precisará pensar em como limitar o acesso ao redor do perímetro tanto quanto possível. Por exemplo, você pode abrir apenas as portas necessárias da Internet (para o tráfego do cliente) e o acesso administrativo ao data center somente a partir de hosts de salto. Em hosts jump, execute todas as verificações necessárias (autenticação/autorização, antivírus, registro, ...)
• você pode usar uma partição lógica da rede do data center em segmentos, semelhante ao esquema descrito em PSEFABRIC exemplo p002. Neste caso, o roteamento deve ser configurado de forma que o tráfego sensível a atrasos ou de alta intensidade passe “dentro” de um segmento (no caso de p002, VRF) e não passe pelo firewall. O tráfego entre diferentes segmentos continuará a passar pelo firewall. Você também pode usar o vazamento de rota entre VRFs para evitar o redirecionamento do tráfego através do firewall
• Você também pode usar um firewall em modo transparente e somente para aquelas VLANs onde esses fatores (latência/desempenho) não são significativos. Mas você precisa estudar cuidadosamente as restrições associadas ao uso deste mod para cada fornecedor
• você pode considerar o uso de uma arquitetura de cadeia de serviços. Isso permitirá que apenas o tráfego necessário passe pelo firewall. Parece bom em teoria, 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 “grosseira”.

Nível de proteção

Agora você precisa responder à pergunta sobre 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 arquivos (bloqueio de tipos de arquivos)
• dos proteção

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

• Quanto mais funções de firewall acima você usar, mais caro será naturalmente (licenças, módulos adicionais)
• o uso de alguns algoritmos pode reduzir significativamente o rendimento do firewall e também aumentar os atrasos, veja por exemplo aqui
• como qualquer solução complexa, o uso de métodos de proteção complexos pode reduzir a confiabilidade de sua solução, por exemplo, ao usar firewall de aplicativo, encontrei o bloqueio de alguns aplicativos funcionais bastante padrão (dns, smb)

Como sempre, você precisa encontrar a melhor solução para sua rede.

É impossível responder definitivamente à questão de quais funções de proteção podem ser necessárias. Em primeiro lugar, porque claro que depende dos dados que você está transmitindo ou armazenando e tentando proteger. Em segundo lugar, na realidade, muitas vezes a escolha de ferramentas de segurança é uma questão de fé e confiança no fornecedor. Você não conhece os algoritmos, não sabe quão eficazes eles são e não pode testá-los totalmente.

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

Segmentação

Estamos falando da segmentação lógica da rede do data center. Por exemplo, o particionamento em VLANs e sub-redes também é uma segmentação lógica, mas não a consideraremos devido à sua obviedade. Segmentação interessante tendo em conta entidades como zonas de segurança FW, VRFs (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 do design de data center atualmente em demanda é dado em p002 do projeto PSEFABRIC.

Tendo definido as partes lógicas da sua rede, você poderá então descrever como o tráfego se move entre os diferentes segmentos, em quais dispositivos a filtragem será realizada e por quais meios.

Se a sua rede não possui uma partição lógica clara e as regras de aplicação de políticas de segurança para diferentes fluxos de dados não estão formalizadas, isso significa que ao abrir este ou aquele acesso, você é forçado a resolver este problema, e com grande probabilidade você vai resolver isso cada vez de forma diferente.

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

• quais zonas de segurança você precisa
• que nível de proteção você deseja aplicar a cada uma dessas zonas
• o tráfego intrazona 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

Um problema comum é a insuficiência de TCAM (Ternary Content Addressable Memory), tanto para roteamento quanto para acessos. IMHO, esta é uma das questões mais importantes na escolha do equipamento, então você precisa tratar esta questão com o cuidado adequado.

Exemplo 1. Tabela de encaminhamento TCAM.

Vamos considerar Palo Alto 7k firewall
Vemos que o tamanho da tabela de encaminhamento IPv4* = 32K
Além disso, este número de rotas é comum para todos os VSYSs.

Vamos supor que de acordo com seu projeto você decida usar 4 VSYS.
Cada um desses VSYSs é conectado via BGP a dois PEs MPLS da nuvem que você usa como BB. Assim, 4 VSYS trocam todas as rotas específicas entre si e possuem 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), então cada rota recebida via MPLS possui 2 NH e, consequentemente, 2 entradas FIB na Tabela de Encaminhamento. Se assumirmos que este é o único firewall no data center e deve conhecer todas as rotas, isso significará 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), então para resolver o problema de roteamento, devemos usar rotas de host . Mas isso significa que para 2 data centers não teremos mais do que 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 que usam switches L3, por exemplo, Cisco ACI), ao escolher o equipamento você deve prestar atenção ao TCAM ACL.

Suponha que você queira controlar o acesso nas interfaces SVI do Cisco Catalyst 4500. Então, como pode ser visto em este artigo, para controlar o tráfego de saída (bem como de entrada) nas interfaces, você pode usar apenas 4096 linhas TCAM. Que ao usar TCAM3 lhe dará cerca de 4000 mil ACEs (linhas ACL).

Se você se depara com o problema de TCAM insuficiente, então, antes de tudo, é claro, você precisa considerar a possibilidade de otimização. Portanto, caso haja algum problema com o tamanho da Tabela de Encaminhamento, é necessário considerar a possibilidade de agregar rotas. Em caso de problema com o tamanho do TCAM para acessos, auditar os acessos, remover registros desatualizados e sobrepostos, e possivelmente revisar o procedimento de abertura de acessos (será discutido detalhadamente no capítulo sobre auditoria de acessos).

High Availability

A questão é: devo usar HA para firewalls ou instalar duas caixas independentes “em paralelo” e, se uma delas falhar, rotear o tráfego pela segunda?

Parece que a resposta é óbvia - use HA. A razão pela qual esta questão ainda surge é que, infelizmente, os 99 teóricos e publicitários e várias percentagens decimais de acessibilidade na prática revelam-se longe de ser tão animadores. HA é logicamente algo bastante complexo e, em equipamentos diferentes e com fornecedores diferentes (não houve exceções), detectamos problemas, bugs e interrupções de serviço.

Se você usar HA, terá a oportunidade de desligar nós individuais, alternar entre eles sem interromper o serviço, o que é importante, por exemplo, ao fazer atualizações, mas ao mesmo tempo você tem uma probabilidade longe de zero de que ambos os nós irá quebrar ao mesmo tempo, e também que na próxima atualização não ocorrerá tão bem 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 falha dupla seus riscos são muito menores (já que você tem 2 firewalls independentes), mas desde... Se as sessões não forem sincronizadas, toda vez que você alternar entre esses firewalls, você perderá tráfego. Você pode, é claro, usar firewall sem estado, mas o objetivo de usar um firewall será praticamente perdido.

Portanto, se como resultado da auditoria você descobriu firewalls solitários e está pensando em aumentar a confiabilidade da sua rede, então o HA, claro, é uma das soluções recomendadas, mas você também deve levar em consideração as desvantagens associadas com esta abordagem e, talvez, especificamente para a sua rede, outra solução seria mais adequada.

Capacidade de gerenciamento

Em princípio, HA também trata de controlabilidade. Em vez de configurar 2 caixas separadamente e lidar com o problema de manter as configurações sincronizadas, você as gerencia como se tivesse um dispositivo.

Mas talvez você tenha muitos data centers e muitos firewalls, então essa questão surge em 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
• exploração madeireira

E tudo isto pode ser resolvido por sistemas de gestão centralizados.

Então, por exemplo, se você estiver usando firewalls Palo Alto, então panorama é essa solução.

Para ser continuado.

Fonte: habr.com