Firewall filter no Junos: proteger o Routing Engine pela lo0

Um roteador de borda responde a muita coisa que não deveria: tentativas de SSH vindas da internet inteira, varredura de SNMP, ping em rajada, sessões TCP na porta 179 de quem não é vizinho BGP. Tudo isso chega ao Routing Engine, a parte do equipamento que roda os protocolos. O firewall filter no Junos aplicado na interface lo0 é a forma de dizer ao roteador quem pode falar com ele e com que intensidade.

É o equivalente Junos do CoPP no Cisco IOS-XE, com uma diferença prática: no Junos, um filtro de entrada na lo0 vale para todo tráfego destinado ao próprio roteador, venha pela interface que vier. Este guia monta um filtro completo em laboratório, num roteador chamado r1, com endereços de documentação, e mostra como aplicar sem perder o acesso.

Resposta rápida: firewall filter no Junos em cinco passos

1. Crie prefix-lists com apply-path para vizinhos BGP, servidores NTP e clientes SNMP, e uma lista fixa com a rede de gerência.
2. Defina policers para limitar SSH, SNMP e ICMP.
3. Escreva um term por protocolo (BGP, OSPF, SSH, SNMP, NTP e ICMP), com origem, protocolo e porta, e termine com um term DESCARTE que conta, registra e descarta o resto.
4. Aplique com set interfaces lo0 unit 0 family inet filter input.
5. Valide com commit check, aplique com commit confirmed 5, teste de outra sessão e só então confirme.

Por que o firewall filter no Junos vai na lo0

O Junos separa o equipamento em dois planos. O Packet Forwarding Engine encaminha o tráfego que passa pelo roteador. O Routing Engine roda BGP, OSPF, SSH, SNMP e NTP, e recebe só o tráfego destinado ao próprio roteador. Pela lógica do Junos, a interface lo0 representa o Routing Engine. Um filtro de entrada nela é avaliado para os pacotes que vão subir até ele, não para o tráfego de trânsito.

Isso traz duas vantagens. Você escreve a política uma vez só, sem repetir em cada interface física. E o filtro é executado no hardware de encaminhamento, então o pacote indesejado é descartado antes de consumir CPU do Routing Engine.

O outro lado é que um erro no filtro da lo0 afeta tudo que o roteador conversa. Esqueceu o term de BGP e as sessões caem quando o hold time vence. Esqueceu o de SSH e a sua sessão é a próxima. Por isso, o commit confirmed e rollback no Junos é parte obrigatória do procedimento, e não um detalhe.

Prefix-lists com apply-path no firewall filter no Junos

O jeito mais comum de um firewall filter no Junos envelhecer mal é a lista de endereços escrita à mão: entra um vizinho BGP novo, ninguém lembra do filtro e a sessão não sobe. O apply-path resolve isso. Em vez de listar endereços, você aponta para um caminho da própria configuração, e o Junos monta a lista sozinho a cada commit.

set policy-options prefix-list GERENCIA 203.0.113.0/24
set policy-options prefix-list BGP-PEERS apply-path "protocols bgp group <*> neighbor <*.*.*.*>"
set policy-options prefix-list NTP-SERVERS apply-path "system ntp server <*.*>"
set policy-options prefix-list SNMP-CLIENTS apply-path "snmp community <*> clients <*>"

• GERENCIA é a única lista fixa: a rede do NOC, de onde sai o SSH.
• BGP-PEERS pega todo neighbor de todo grupo BGP. O <*.*.*.*> restringe a endereços IPv4, como mostra a documentação da Juniper. Sem isso, vizinhos IPv6 entrariam numa lista usada num filtro family inet.
• NTP-SERVERS segue os servidores IPv4 configurados em system ntp server; o <*.*> deixa de fora os IPv6.
• SNMP-CLIENTS segue os endereços em clients das comunidades SNMP. Se as suas comunidades não restringem clientes, essa lista fica vazia, e o term de SNMP não aceita nada.

A regra do apply-path é simples: o curinga entre sinais de menor e maior só pode vir depois de um container da configuração, nunca depois de uma folha. Confira o que a lista virou de fato antes de usar no filtro. O comando e uma saída de exemplo:

show configuration policy-options prefix-list BGP-PEERS | display inheritance

##
## apply-path was expanded to:
##     192.0.2.1/32;
##     198.51.100.9/32;
##
apply-path "protocols bgp group <*> neighbor <*.*.*.*>";

Os comentários com ## mostram a expansão. Se aparecer um endereço que você não esperava, ou se a lista sair vazia, corrija antes de seguir. O commit do filtro vai usar exatamente essa expansão.

Policers do firewall filter no Junos: quanto cada protocolo pode mandar

Aceitar um protocolo não significa aceitar qualquer volume dele. Um policer descarta o que passar de uma taxa. Os valores abaixo seguem a ordem de grandeza do exemplo oficial da Juniper de proteção contra flood de TCP e ICMP:

set firewall policer PL-GERENCIA filter-specific
set firewall policer PL-GERENCIA if-exceeding bandwidth-limit 2m
set firewall policer PL-GERENCIA if-exceeding burst-size-limit 30k
set firewall policer PL-GERENCIA then discard
set firewall policer PL-ICMP filter-specific
set firewall policer PL-ICMP if-exceeding bandwidth-limit 1m
set firewall policer PL-ICMP if-exceeding burst-size-limit 15k
set firewall policer PL-ICMP then discard

• bandwidth-limit é a taxa média permitida, em bits por segundo. 1m é 1 Mbit/s.
• burst-size-limit é a rajada tolerada acima da média, em bytes.
• then discard descarta o excesso. O pacote dentro do limite segue para a ação do term.
• filter-specific faz o policer ser um balde só para o filtro inteiro. Como PL-GERENCIA é usado nos terms de SSH e SNMP, os dois dividem os mesmos 2 Mbit/s. Sem essa opção, cada term ganharia a própria instância.

BGP fica sem policer de propósito. Os vizinhos já estão restritos por endereço, e limitar a sessão que traz a tabela de rotas atrasa a convergência. Ajuste os valores de SSH e SNMP ao seu caso: um Zabbix que coleta muitas interfaces a cada minuto precisa de mais folga.

Os terms do firewall filter no Junos

O firewall filter no Junos é avaliado de cima para baixo. O primeiro term que casa decide o destino do pacote, e os seguintes nem são olhados. Por isso a ordem importa: protocolos de controle primeiro, gerência depois, descarte no fim. Se a sintaxe de set e da candidate ainda é nova, veja os comandos Junos básicos.

Terms BGP e OSPF

set firewall family inet filter PROTEGE-RE term BGP from source-prefix-list BGP-PEERS
set firewall family inet filter PROTEGE-RE term BGP from protocol tcp
set firewall family inet filter PROTEGE-RE term BGP from port bgp
set firewall family inet filter PROTEGE-RE term BGP then count CT-BGP
set firewall family inet filter PROTEGE-RE term BGP then accept
set firewall family inet filter PROTEGE-RE term OSPF from protocol ospf
set firewall family inet filter PROTEGE-RE term OSPF then count CT-OSPF
set firewall family inet filter PROTEGE-RE term OSPF then accept

from port bgp casa a porta 179 na origem ou no destino. Isso cobre os dois lados da sessão: quando o vizinho abre a conexão para o seu roteador e quando o seu roteador abre para ele. O contador CT-BGP não muda nada no tráfego, mas mostra se o term está sendo usado. O OSPF não usa TCP nem UDP: é o protocolo IP 89, e o term casa com protocol ospf. Se o roteador não roda OSPF, apague esse term.

Terms de gerência: SSH, SNMP e NTP

set firewall family inet filter PROTEGE-RE term SSH from source-prefix-list GERENCIA
set firewall family inet filter PROTEGE-RE term SSH from protocol tcp
set firewall family inet filter PROTEGE-RE term SSH from destination-port ssh
set firewall family inet filter PROTEGE-RE term SSH then policer PL-GERENCIA
set firewall family inet filter PROTEGE-RE term SSH then accept
set firewall family inet filter PROTEGE-RE term SNMP from source-prefix-list SNMP-CLIENTS
set firewall family inet filter PROTEGE-RE term SNMP from protocol udp
set firewall family inet filter PROTEGE-RE term SNMP from destination-port snmp
set firewall family inet filter PROTEGE-RE term SNMP then policer PL-GERENCIA
set firewall family inet filter PROTEGE-RE term SNMP then accept
set firewall family inet filter PROTEGE-RE term NTP from source-prefix-list NTP-SERVERS
set firewall family inet filter PROTEGE-RE term NTP from protocol udp
set firewall family inet filter PROTEGE-RE term NTP from source-port ntp
set firewall family inet filter PROTEGE-RE term NTP then accept

• SSH só da rede de gerência e com destino na porta 22 do roteador.
• SNMP só dos clientes declarados nas comunidades, em UDP com destino na porta snmp.
• NTP é o caso inverso. O roteador é cliente, então o que chega são as respostas dos servidores, com porta de origem ntp. Por isso o term usa source-port.

Term ICMP e o descarte final

set firewall family inet filter PROTEGE-RE term ICMP from protocol icmp
set firewall family inet filter PROTEGE-RE term ICMP then policer PL-ICMP
set firewall family inet filter PROTEGE-RE term ICMP then count CT-ICMP
set firewall family inet filter PROTEGE-RE term ICMP then accept
set firewall family inet filter PROTEGE-RE term DESCARTE then count CT-DESCARTE
set firewall family inet filter PROTEGE-RE term DESCARTE then log
set firewall family inet filter PROTEGE-RE term DESCARTE then syslog
set firewall family inet filter PROTEGE-RE term DESCARTE then discard

O ICMP fica aberto para qualquer origem, porque ping e traceroute ajudam no diagnóstico e no cálculo de MTU, mas passa pelo policer de 1 Mbit/s. O term DESCARTE não tem from, então casa com tudo que chegou até ele. As ações:

• count CT-DESCARTE soma pacotes e bytes descartados.
• log guarda os últimos pacotes num buffer em memória, que você lê com show firewall log.
• syslog manda o registro para o syslog, útil para ver tentativas de acesso ao longo do tempo. Em roteador de borda o volume é alto; se o servidor de log sofrer, deixe só count e log.
• discard descarta em silêncio, sem mandar ICMP de volta. A alternativa reject responde ao remetente, o que só ajuda quem está varrendo a rede.

Aplicar o firewall filter no Junos com commit confirmed

set interfaces lo0 unit 0 family inet filter input PROTEGE-RE

Até aqui, tudo está só na candidate. O firewall filter não guarda estado: se o term de SSH estiver errado, ele derruba também a sessão que já está aberta, inclusive a sua. Tenha à mão um acesso que não dependa do filtro, como a console, e conte com o rollback automático do commit confirmed.

user@r1# show | compare
user@r1# commit check
configuration check succeeds
user@r1# commit confirmed 5
commit complete

O show | compare mostra exatamente o que vai mudar. O commit check valida a sintaxe e as referências, como um policer ou uma prefix-list com nome errado. O commit confirmed 5 aplica, imprime o aviso commit confirmed will be automatically rolled back in 5 minutes unless confirmed antes do commit complete e começa a contar.

show bgp summary
show ntp associations
show firewall filter PROTEGE-RE
show firewall log

Confira se todas as sessões BGP continuam Established, se o NTP segue sincronizado e se os contadores do filtro estão andando. Se tudo estiver certo, confirme dentro do prazo:

user@r1# commit
commit complete

Se você perdeu o acesso, não faça nada: quando o prazo acabar, o Junos volta para a configuração anterior sozinho.

Como ler os contadores do firewall filter no Junos

O show firewall filter PROTEGE-RE mostra contadores e policers do filtro. Saída de exemplo, com colunas encurtadas:

Filter: PROTEGE-RE
Counters:
Name                              Bytes          Packets
CT-BGP                           884213             9120
CT-DESCARTE                      412880             6310
CT-ICMP                           38216              412
CT-OSPF                          121904             1544
Policers:
Name                              Bytes          Packets
PL-GERENCIA                                            0
PL-ICMP                                               27

• CT-BGP crescendo indica sessões ativas passando pelo term certo.
• CT-DESCARTE alto em roteador de borda é normal: é a internet batendo na porta. O que importa é se tem algo legítimo ali dentro.
• Os pacotes contados em PL-ICMP são os descartados pelo policer, ou seja, o excesso.

Para descobrir o que está caindo no descarte, use o log. Saída de exemplo, resumida:

Time      Filter Action Interface   Protocol Src Addr      Dest Addr
07:41:12  pfe    D      ge-0/0/1.0  TCP      198.51.100.77 192.0.2.254
07:41:11  pfe    D      ge-0/0/1.0  UDP      198.51.100.80 192.0.2.254

A coluna Action com D indica descarte. Se aparecer como origem o IP de um servidor seu, como um coletor SNMP novo ou um servidor NTP trocado, é sinal de que falta ajustar a configuração de origem, e não o filtro. Para revisar o filtro inteiro, use:

show configuration firewall family inet filter PROTEGE-RE

Erros comuns com firewall filter no Junos

• Term de descarte antes do fim. Um term novo adicionado com set entra no fim da lista, depois do DESCARTE, e nunca é avaliado. Use insert ... before term DESCARTE para pôr no lugar certo.
• Protocolo esquecido. BFD, VRRP, LDP, DNS para o próprio roteador, RADIUS ou TACACS de login: tudo que o Routing Engine usa precisa de um term. Antes de aplicar, liste os protocolos que o roteador realmente roda.
• Só IPv4 protegido. O filtro family inet não vale para IPv6. É preciso um filtro family inet6 separado na mesma lo0, e ele precisa aceitar a descoberta de vizinhos ICMPv6, senão o IPv6 para de funcionar.
• Lista vazia sem perceber. Um apply-path que não expande deixa o term sem origem válida. Confira sempre com display inheritance.
• Policer apertado demais. Coleta SNMP lenta ou falhando depois do filtro costuma ser policer, não ACL. Olhe os contadores do policer antes de mexer nos terms.
• Sem commit confirmed. Aplicar filtro na lo0 com commit direto é a forma mais rápida de precisar de alguém no POP com cabo de console.

O filtro da lo0 protege o roteador. Para proteger a internet do tráfego falsificado que sai da sua rede, o assunto é outro: BCP38 com uRPF.

Perguntas frequentes

O firewall filter no Junos na lo0 afeta o tráfego dos clientes que passa pelo roteador?

Não. O filtro de entrada na lo0 só é avaliado para pacotes destinados ao próprio roteador. O tráfego de trânsito segue pelo Packet Forwarding Engine sem passar por ele.

Qual a diferença entre discard e reject no firewall filter no Junos?

O discard descarta em silêncio. O reject descarta e manda uma mensagem ICMP para a origem. Na proteção do Routing Engine, o discard é o mais indicado, porque não dá informação a quem está varrendo.

Preciso atualizar o filtro quando adiciono um vizinho BGP?

Não, se a prefix-list usa apply-path apontando para protocols bgp group. O Junos refaz a lista a cada commit, e o vizinho novo entra junto com a configuração dele.

Como proteger o IPv6 do Routing Engine?

Com um segundo filtro em family inet6 aplicado na mesma lo0, com uma prefix-list de vizinhos usando neighbor <*:*:*>. Lembre de aceitar o ICMPv6 de descoberta de vizinhos.

O que significa filter-specific no policer?

Que o policer é uma instância única para o filtro inteiro. Todos os terms que usam aquele policer dividem o mesmo limite. Sem a opção, cada term que referencia o policer ganha um limite próprio.

Conclusão

Um bom firewall filter no Junos para a lo0 é curto: listas que se mantêm sozinhas com apply-path, um term por protocolo que o roteador realmente usa, policers onde faz sentido e um descarte final que conta e registra. O trabalho maior está antes do commit, levantando o que o equipamento conversa, e logo depois, lendo os contadores.

Aplique sempre com commit confirmed, teste de uma sessão nova e só confirme quando BGP, NTP e SNMP estiverem normais. Depois, repita o mesmo raciocínio para o IPv6 e revise o filtro a cada protocolo novo que entrar no roteador.