Em arquiteturas clássicas, o ADC fica em um dispositivo, o firewall em outro, e as regras de roteamento e NAT existem em ainda outra camada operacional. Essa separação parece organizada à primeira vista, mas em produção cada mudança se torna um problema de coordenação. Um novo vService é aberto e a regra de firewall é esquecida. Um DNAT muda e a rota não é atualizada. Um segmento de backend muda e a regra FORWARD fica obsoleta.
Em ambientes multi-namespace ou multi-tenant o problema cresce. Quando cada tenant tem seu próprio espaço de IP, suas próprias interfaces e suas próprias regras NAT, uma única tabela de firewall global não é suficiente. O mesmo CIDR pode ser usado em diferentes namespaces; nesse caso o firewall também deve ser separado por namespace.
Usar um dispositivo de firewall separado não é apenas um ônus de gerenciamento extra — a auditoria e o failover também se fragmentam. Um operador não consegue responder "quem abriu esse tráfego?", "qual regra automática veio de qual vService?" ou "em qual namespace esse DNAT está ativo?" de um único painel. Durante um incidente, logs do ADC, logs do firewall e estado de roteamento devem ser inspecionados separadamente.
A segurança de aplicação de regras é outro problema. Em rule sets de firewall tradicionais, uma única linha com falha pode fazer toda a operação de carregamento falhar. Em produção a consequência é grave: regras corretas também não são aplicadas, o tráfego é interrompido ou a política de segurança fica inativa.
O TR7 ADC trata o firewall como uma parte natural do ADC: rule sets por namespace, controle por interface, regras automáticas ADC/GTM/NAT, diretivas DDoS, um pipeline test-apply e isolamento de regras com falha são combinados em um único modelo de gerenciamento.
A abordagem de firewall do TR7 não é um dispositivo de segurança separado parafusado — é uma camada de controle L3/L4 embutida no modelo de tráfego, roteamento e namespace do ADC.
Cada namespace tem seu próprio gerenciador de firewall. Uma regra dentro de um namespace não toca o tráfego em outro namespace. Esse modelo fornece isolamento seguro em cenários multi-tenant, CIDR sobreposto e route table separada.
O novo conteúdo de firewall é testado primeiro e depois aplicado. Se uma linha falhar, todo o rule set não é cancelado — a linha com falha é automaticamente desabilitada e as regras saudáveis são reexecutadas. Isso evita que um único erro derrube todo o rule set durante uma mudança de produção.
As regras IPv4 e IPv6 são gerenciadas em arquivos separados, com validação separada, em paralelo. Uma falha em uma família de IP não afeta a outra. Em serviços dual-stack, a política de segurança é aplicada de forma consistente para ambas as famílias.
Quando um pool ADC, L4 NAT, DNAT inline, redirecionamento DNS GTM, acesso de gerenciamento ou marcador de backend é configurado, as regras de firewall podem ser geradas automaticamente. Operadores que abrem um vService não precisam lembrar do lado de segurança separadamente.
O Firewall Integrado combina controle clássico L3/L4 com geração automática de regras nativa do ADC, mitigação DDoS, quarentena e isolamento de namespace.
Cada namespace opera com um rule set de firewall independente. Um DNAT definido no namespace do Tenant A não afeta o mesmo bloco CIDR no Tenant B. Essa estrutura fornece a separação de segurança fundamental para cenários multi-tenant e de espaço de IP sobreposto.
As regras IPv4 e IPv6 são produzidas e aplicadas como rule sets separados. Em serviços dual-stack, o lado IPv6 não é esquecido depois; controles de allow, deny, forward, NAT e rate-limit podem ser escritos para ambas as famílias de IP.
As regras podem ser definidas não apenas no nível de namespace, mas também no nível de interface. Políticas diferentes podem ser aplicadas à interface de gerenciamento, interface de sincronização, interface de tenant ou interface de serviço. Esse modelo controla o tráfego de acordo com o ponto real de ingresso/egresso.
As operações principais de firewall são gerenciadas em um único modelo. Permitir, bloquear, permitir passagem de trânsito ou excluir tráfego específico do trânsito podem ser todos definidos nas chains INPUT e FORWARD.
O DNAT pode ser aplicado para redirecionar tráfego de entrada para um IP de destino diferente; o SNAT altera o IP de origem do tráfego de saída. Publicação inline, redirecionamento de serviço L4 e cenários de múltiplos segmentos de backend são gerenciados com essas regras.
A correspondência de IP de origem pode ser realizada contra conjuntos de países. É possível criar allowlist de certos países, bloquear países específicos ou descartar rapidamente regiões de alto risco durante um ataque. A operação baseada em sets preserva o desempenho em escala.
IP/CIDR, endereço MAC e lógica de "excluir" são suportados. Por exemplo, uma sub-rede inteira pode ser bloqueada enquanto IPs específicos são isentados. Essa estrutura é usada tanto para allowlists operacionais quanto para regras temporárias de resposta a incidentes.
Múltiplas portas ou intervalos de porta podem ser definidos em uma única regra. Políticas de acesso amplas ou estreitas podem ser escritas para portas de DNS, RADIUS, SIP, API e gerenciamento.
Descarte de pacotes inválidos, limite de novas conexões TCP, limite de conexões totais, limite de flood UDP, limite de flood DNS/NTP, limite de reset TCP, descarte de fragmentos, MSS suspeito, detecção de ataque LAND e bloqueio de UDP de zero byte podem ser todos habilitados sob uma única política.
Fontes que excedem um limite são adicionadas a conjuntos de quarentena temporários. Quando o período de quarentena expira, a entrada é removida automaticamente. Conjuntos de whitelist podem ser excluídos das regras de quarentena para que fontes confiáveis nunca sejam afetadas acidentalmente.
Connection marks e listas recentes podem ser usados para vincular tráfego de cliente específico ao mesmo backend em serviços L4. Isso é importante para continuidade de sessão em cenários de UDP ou intervalo de porta.
Tipos de regra automática são suportados para permitir uma porta de serviço quando um pool é aberto, gerar L4 SNAT/DNAT, criar uma regra DNAT inline, redirecionar o acesso DNS GTM ou adicionar uma regra de deny local.
Quando uma linha falha durante a aplicação do rule set, ela é detectada, comentada e as regras restantes são reexecutadas. Uma única regra com falha não pode parar toda a sincronização do firewall.
As regras podem ser configuradas para produzir entradas de log. Comportamentos de drop, allow, DNAT ou quarentena podem ser incluídos na cadeia de auditoria. Após um incidente, qual regra afetou qual tráfego pode ser rastreado.
O tráfego de gerenciamento e sincronização de cluster é tratado de forma especial pelo sistema. Interfaces críticas são protegidas com comportamento de allow automático para evitar perda acidental de acesso operacional.
A camada de firewall integrada não é apenas uma tela de escrita de regras — ela trabalha em conjunto com testes, sincronização, isolamento de erros, geração automática de regras e gerenciamento de ciclo de vida de namespace.
O conteúdo de firewall IPv4 e IPv6 para cada namespace é armazenado em arquivos de configuração separados. A última configuração combinada também é retida, tornando o rastreamento de mudanças e a depuração diretos.
A sincronização do firewall opera dentro de limites de timeout definidos. O processo primeiro atinge um estado pronto; depois as etapas de teste e aplicação são executadas. Uma operação longa ou travada é limitada pelo sistema.
Quando muitos namespaces estão presentes, a sincronização do firewall roda em lotes em paralelo. Isso torna operacionalmente gerenciável que cada namespace tenha seu próprio rule set em ambientes multi-tenant.
Tipos de regra automáticos como pool-tcp-udp, ftp-allow, l4-snat, l4-any-dnat, l4-any-snat, inline-dnat, fw-access-allow, fw-access-dnat, gtm-dns-dnat, gtm-access-dnat, local-deny e be-mark podem ser gerados a partir de objetos ADC.
Fluxos de retorno para tráfego RELATED e ESTABLISHED são reconhecidos automaticamente. Isso reduz a necessidade de escrever regras manuais separadas para cada pacote de retorno em serviços com estado.
Limites de taxa por fonte e limites de conexão são suportados. Conexões excessivas, pacotes de reset, pacotes ICMP, floods UDP de DNS/NTP ou novas tentativas de conexão TCP do mesmo IP podem ser todos limitados.
Bloquear ICMP completamente pode prejudicar funções de rede fundamentais como IPv6 e Path MTU Discovery. O TR7 lida com as políticas ICMP com granularidade; as mensagens de descoberta e controle necessárias podem ser gerenciadas com segurança.
Após as regras com falha serem comentadas, o rule set final é gravado de volta no disco. Os operadores podem ver qual linha foi desabilitada e corrigi-la. O sistema produz um resultado visível e acionável em vez de uma falha silenciosa.
As conexões SSH à interface de gerenciamento são limitadas com um limite por fonte. Se o mesmo IP exceder o limite definido, é temporariamente colocado em quarentena. A superfície de brute-force é reduzida enquanto o acesso de gerenciamento permanece aberto.
Apenas o tráfego de países selecionados é permitido; todos os demais são descartados. Isso fornece um controle rápido para conformidade baseada em país e redução de risco em sistemas financeiros, do setor público ou de saúde.
Enquanto o DNAT 1.2.3.4 → 10.0.0.5 é aplicado no namespace do Tenant A, o Tenant B pode usar o mesmo CIDR interno com uma regra diferente. O isolamento de namespace garante que as políticas NAT dos dois tenants não conflitem.
Flood UDP de zero byte, flood DNS/NTP, TCP anormal, fragmentos e comportamentos de flood de conexão são mitigados com mecanismos de hashlimit, connlimit e quarentena. A proteção básica L3/L4 é aplicada sem um dispositivo de scrubbing separado.
Quando tráfego de trânsito é necessário entre dois segmentos de backend, a passagem controlada é estabelecida com regras FORWARD. Qual fonte pode alcançar qual destino em qual porta é definido com precisão.
Um IP de backend é publicado pelo TR7 e o tráfego de entrada é entregue ao backend relevante via DNAT inline. A camada de segurança e roteamento do TR7 é inserida sem alterar a aplicação ou o plano de IP do backend.
Isolamento de namespace, diretivas DDoS, DNAT/SNAT e geração automática de regras — deixe-nos percorrer uma configuração ao vivo no seu próprio ambiente.