A migração de firewalls pode ser uma tarefa complexa, muitas vezes envolvendo políticas complexas, aplicativos críticos e a necessidade de uma transição perfeita. Esta postagem resume os principais insights de arquitetos experientes sobre as práticas recomendadas para qualquer migração de firewall e, em seguida, aprofunda as considerações exclusivas ao migrar da Palo Alto Networks para os Cisco Subsequent-Technology Firewalls.
Seção 0: O pano de fundo
A liderança do cliente decidiu migrar do PAN para a Cisco. Esta foi uma decisão empresarial baseada no aumento de preços por parte do PAN. Ao contrário de muitos projetos de migração de firewall suportados pelo CX, esse envolvimento teve os seguintes fatores complicadores:
- Falta de documentação do estado atual.
- Falta de compreensão da solução de identidade atual. Mais especificamente, identificamos (com esforço) que havia uma necessidade de fazer a Cisco e a PAN coexistirem devido a muitos casos de aplicação de firewall baseada em identidade.
- Falta de compreensão do histórico do firewall (ou seja, POR QUE existe um firewall aqui/quais segmentos de rede precisam de isolamento).
- Falta de compreensão/documentação dos aplicativos e como/onde a política de firewall oferece suporte aos aplicativos.
- Ambiente 24 horas por dia, 7 dias por semana: Não existe “após o expediente”, portanto cada esforço de migração exigiu um planejamento significativo.
Seção 1: Melhores práticas gerais de migração de firewall
Uma migração de firewall bem-sucedida depende de planejamento meticuloso, execução completa e atividades diligentes pós-migração. Não existe ferramenta que substitua as boas práticas e o objetivo desta seção é preparar um engenheiro com as habilidades necessárias para salvar a sanidade:
1. Trabalho de preparação abrangente:
- Limpeza e otimização pré-migração: Antes mesmo de pensar em mudar, limpe o firewall existente. Isso inclui analisar contagens de ocorrências de regras e NAT para identificar políticas não utilizadas ou redundantes e executar a desduplicação de objetos para simplificar as configurações. Você mudaria de casa sem primeiro organizar e jogar o lixo fora? Se não, por que você moveria uma política de firewall obsoleta ou irrelevante? Uma boa prática recomendada é tornar isso algo pelo qual o cliente é responsável. Assim como na mudança, você não pode organizar indefinidamente, portanto, certifique-se de que haja um cronograma pelo qual o cliente seja responsabilizado.
- Gestão de Mudanças: O superb é implementar um congelamento de configuração no firewall de origem. Se não for possível, estabeleça um rastreamento robusto de alterações para replicar quaisquer novas regras ou modificações nos firewalls antigos e novos.
- Envolvimento das partes interessadas: Identifique todos os aplicativos de missão crítica e seus principais interessados. A sua contribuição é essential para compreender os fluxos de tráfego e validar a funcionalidade pós-migração.
- A documentação é rei:
- Desenvolva um detalhado Método de Procedimento (MOP): descreva cada etapa, inclusive se você executará uma transição “forte” ou uma migração incremental/em fases. Inclua objetivos de tempo claros.
- Conduta Avaliações de pares: Tenha vários olhos em seu MOP e nas configurações.
- Crie um Plano de teste completo: Não se trata apenas de testar aplicativos; trata-se de testar seu plano de teste em si. Certifique-se de que cobre todas as funcionalidades críticas e casos extremos.
- Projete um Plano de reversão: Tenha sempre uma estratégia clara para voltar ao estado anterior caso surjam problemas.
2. Execução de migração perfeita:
- Conduza um ‘ensaio’: Se possível, simule a migração em um ambiente de teste para identificar possíveis problemas antes da transferência actual.
- Validar tabelas ARP: Verifique as tabelas ARP antes e depois da migração para garantir a conectividade de rede adequada.
- Otimize o tráfego crítico: Desenvolva pré-filtros ou regras de ‘caminho rápido’ para aplicativos críticos para garantir que seu desempenho não seja afetado.
- Ferramentas de monitoramento pré-estágio: Put together pesquisas personalizadas e capturas de pacotes com antecedência para diagnosticar problemas rapidamente durante a migração.
- Suporte de plantão: Tenha testadores e proprietários de aplicativos prontamente disponíveis ou em uma chamada dedicada durante a janela de migração. Nota importante: NÃO PODEM ser as mesmas pessoas. Freqüentemente, recebíamos testadores que não entendiam como o aplicativo funcionava. Certifique-se de que esteja bem documentado onde essa experiência ocorre. IPs de origem/destino e portas L4 – quem conhece esses detalhes de baixo nível?
3. Atividades pós-migração para estabilidade e otimização:
- Revise os relatórios pós-migração: Analise minuciosamente todos os relatórios gerados pelas ferramentas de migração para identificar e resolver problemas persistentes.
- Atualizar documentação: Certifique-se de que todos os diagramas de rede, documentos de política e procedimentos operacionais estejam atualizados para refletir a nova configuração do firewall.
- Monitoramento Contínuo: Implemente monitoramento robusto para rastrear desempenho, eventos de segurança e possíveis anomalias.
- Treinamento e suporte: Eduque sua equipe de operações sobre a nova plataforma e seu gerenciamento.
- Otimização contínua: As políticas de firewall não são estáticas. Revise e otimize regularmente as regras para manter a eficiência e a postura de segurança.
Procedimento de migração ponta a ponta (etapas gerais):
- Baixe e inicie a ferramenta de migração.
- Exporte o arquivo de configuração do firewall de origem.
- Revise o relatório de pré-migração.
- Mapeie interfaces, zonas de segurança e grupos de interfaces.
- Mapeie configurações com aplicativos.
- Especifique os parâmetros de destino e selecione recursos para migração.
- Otimize, revise e valide a configuração migrada.
- Envie a configuração migrada para o centro de gerenciamento do novo firewall (por exemplo, FMC).
- Implante a configuração no firewall.
- Baixe e revise o relatório pós-migração.
- Configure quaisquer itens manuais adicionais.
Seção 2: Principais diferenças e estratégias de migração de Palo Alto para firewalls de próxima geração da Cisco
A migração da Palo Alto Networks para o Cisco Safe Firewall traz seu próprio conjunto de nuances, principalmente no que diz respeito à integração de identidade, conversão de políticas e recursos específicos da plataforma.
- Coexistência de identidade durante a migração:
Um desafio significativo é garantir que os mapeamentos de identidade do usuário (por exemplo, “Lisa é 10.14.10.7”) sejam consistentes nos firewalls Palo Alto e Cisco durante o período de migração provisória.
- O problema: A Cisco precisa estar ciente dos mapeamentos de usuário para IP que os agentes Consumer-ID ou gateways VPN de Palo Alto já conhecem. Sem isso, o tráfego de usuários identificados poderá ser negado pelo firewall Cisco porque não possui o contexto necessário.
- Soluções exploradas:
- Implantação ISE-PIC dedicada: Embora tentado, usar uma implantação ISE existente para essa finalidade pode ser problemático, especialmente porque o PassiveID é incompatível com a autenticação de máquina 802.1x. Nota: O ISE-PIC atingiu o fim da vida útil.
- Encaminhamento de Syslog: Uma estratégia viável envolve configurar o firewall VPN de Palo Alto para encaminhar mensagens Syslog contendo mapeamentos de usuário para IP para o Cisco ISE.
- Agentes do Lively Listing: A implantação de agentes em servidores Lively Listing ou servidores de terminal pode ajudar ambas as plataformas a coletar informações de identidade.
Ao incluir uma combinação de encaminhamento de syslog no firewall PAN VPN e novos agentes Cisco nos servidores AD do cliente, conseguimos migrar um firewall PAN downstream para a Cisco.
Caso os usuários venham do native (autenticação passiva) ou by way of VPN de acesso remoto, o firewall da Cisco terá um mapeamento de usuário->IP para garantir que a política de firewall apropriada esteja sendo correspondida.
A partir do Firewall Administration Middle 7.6, a funcionalidade de ID passiva está disponível diretamente sem a necessidade de ISE-PIC (que entrou em EOL em 05/05/2025).
2. Conversão de políticas com a ferramenta de migração segura de firewall:
A ferramenta de migração do Cisco Safe Firewall foi projetada para ajudar nessa transição, mas é elementary compreender seus recursos e limitações.
- Extração e Combinação: A ferramenta pode extrair e combinar configurações de Palo Alto, identificando elementos como regras de controle de acesso, objetos de rede/porta, interfaces, rotas e aplicações.
- Seleção de recursos: Você pode selecionar quais componentes da configuração (por exemplo, Interfaces, Rotas, Controle de Acesso) serão migrados.
- Mapeamento de aplicativos: É essential resolver quaisquer mapeamentos de aplicativos em branco ou inválidos. Em alguns casos, poderá ser necessário adicionar equivalentes baseados em portas se um mapeamento direto de aplicativo não estiver disponível. Recursos como Cisco AppID e Applipedia de Palo Alto podem ajudar.
- Ações e otimização em massa: A ferramenta facilita ações em massa e permite a otimização de ACL, mas lembre-se de pré-preparar políticas de arquivo e IPS no Cisco Firepower Administration Middle (FMC).
3. Limitações de configuração de Palo Alto para migração:
- Versão PAN-OS: O firewall Palo Alto de origem deve estar executando o software program PAN-OS versão 8.0 ou superior para que a ferramenta de migração funcione corretamente.
- Migração VSYS: A ferramenta suporta a migração de configurações simples ou multi-vsys, que normalmente são mescladas com VRFs para obter segmentação no Cisco FTD.
- Configuração do sistema: Configurações críticas do sistema, como políticas de plataforma (por exemplo, NTP, acesso SSH) no FTD, são geralmente não migrados pela ferramenta e requerem configuração guide.
4. Desafios Específicos e Configurações Manuais:
Vários elementos requerem atenção guide ou possuem implementações diferentes entre as duas plataformas:
- NAT IP e excesso de assinatura de porta: Palo Alto pode lidar com níveis mais altos de excesso de assinatura de NAT (por exemplo, reutilização 1x, 2x, 4x, 8x do mesmo endereço/porta). Ao migrar para a Cisco, muitas vezes você precisa aumentar o tamanho do pool PAT para acomodar isso.
- Curingas de URL: Palo Alto usa caracteres como * ou ^ para curingas de URL, enquanto a Cisco normalmente oferece suporte à correspondência de substring (por exemplo, cisco.com em vez de *.cisco.com). Estes precisam de ajuste.
- Grupos de objetos aninhados: Grupos de objetos de rede e portas aninhados com mais de 10 níveis não são suportados no Cisco FMC e precisarão de nivelamento.
- Integração do domínio de identidade/Lively Listing: Embora as versões mais recentes da ferramenta de migração (FMT 7.7+) suportem a integração AD/Realm, muitas vezes você precisará adicionar identidade manualmente às regras aplicáveis e pré-preparar as configurações de Realm e AD no FMC.
- Substituição da fonte NAT: Substitua manualmente a origem NAT nas regras da Política de Controle de Acesso (ACP) pelo destino NAT (ou seja, troque o endereço traduzido pelo destino authentic).
- Itens não migrados que requerem configuração guide:
- Regras de controle de acesso baseadas em tempo. Cisco não atualmente suporte a regras de controle de acesso baseadas em tempo.
- Regras de controle de acesso baseadas em identidade: Você precisará associar explicitamente grupos de identidades ou identidades individuais.
- Objetos FQDN: Especialmente aqueles que começam ou contêm caracteres especiais. Os FQDNs curinga geralmente precisam de substituição ou atualizações.
- Políticas de filtragem de URL: Adicione as respectivas categorias, pois as políticas que usam filtragem de URL podem não ser traduzidas diretamente.
- Mapeamento de aplicativos: Se uma regra em Palo Alto usasse “aplicativo padrão” para serviço, ela provavelmente será migrada como “qualquer” serviço na Cisco, exigindo refinamento guide. Em alguns casos, adicionamos equivalentes baseados em portas.
- Negar regras: A lógica de “permitir X, mas excluir Y” de Palo Alto precisa ser traduzida em regras explícitas de “negação” no FTD. Cisco não atualmente apoiar regras de negação. Isto foi conseguido simplesmente implementando uma regra de ‘negação’ no FTD.
- Roteamento Dinâmico: Requer configuração guide. Isso não será portado por meio da ferramenta de migração.
- Refletor de rota: Adicione o FTD como um peer eBGP manualmente. Mais especificamente, Atualmente, a Cisco não oferece suporte (até o momento desta postagem no weblog) à configuração do refletor de rota iBGP. Isso foi superado configurando manualmente um novo número autônomo de eBGP para o firewall. Isso também exigiu a configuração adicional de ‘permitir entrada’, pois houve casos em que a propagação de rotas prendeu o firewall.
5. Itens parcialmente suportados, ignorados ou desativados:
Esteja ciente de que determinadas configurações não são totalmente suportadas ou são ignoradas durante a migração:
- Configurações de gerenciamento (como acesso NTP, SSH).
- Roteamento Dinâmico Syslog.
- Políticas de serviço (muitas vezes traduzidas em FlexConfig no FTD).
- Endereços IP reservados de VPN de acesso remoto (exigem soluções alternativas by way of ISE ou AD).
- Configurações de VPN web site a web site específicas do dispositivo.
- Configurações de registro de conexão.
Ao aderir às melhores práticas gerais e compreender essas diferenças específicas ao migrar de Palo Alto para os Cisco Subsequent-Technology Firewalls, as organizações podem alcançar uma transição mais tranquila, segura e eficiente.