Feature do Cisco IOS introduzida na versão 11.3, tem a capacidade de filtrar o tráfego baseada nas informações da camada de sessão do modelo OSI, e não somente portas TCP/UDP e endereço IP; ou seja, se os comunicantes alterarem as portas de comunicação durante a conexão, as informações da sessão permitem o tráfego, e associam dinamicamente as portas a esta access-list.
O administrador a nomeia e a destina a inspecionar o tráfego definido em uma lista de acesso de para tráfego outbound (tráfego de resposta, seja TCP, UDP, ICMP, etc.), suplementar a lista em sentido inbound aplicada a uma interface. Então, a lista reflexiva é indicada nesta lista inbound, para que as informações de sessão/conexão sejam consideradas, e o fluxo de dados não pare.
Pré-Requisitos de seu funcionamento:
– As ACLs devem ser IP;
– Deve ser do tipo extendida e nomeada.
No exemplo seguinte, implementaremos uma regra que limita o tráfego entre dois hosts somente via TFTP/UDP. A sessão poderá ser iniciada somente pelo host BrainRT01 (200.20.20.1), e a lista de accesso será aplicada na interface 200.20.20.2 de BrainRT02.
Configuração:
! criando a access-list que define o tráfego entre os dois hosts
ip access-list extended TFTP_Only
permit udp host 200.20.20.1 host 172.30.1.10 eq tftp
! definindo a lista de acesso reflexiva que esta lista consultará para inspecionar a sessão
evaluate TFTP_Reflect
! tornando explícito o “deny all”
deny ip any any
! criando a access-list em que será definido o tipo tráfego, neste caso UDP, entre os dois hosts
! no sentido outbound, e que será lida pela access-list reflexiva “TFTP_Reflect”
ip access-list extended TFTP_Return
permit udp host 172.30.1.10 host 200.20.20.1 reflect TFTP_Reflect
! estabelecendo o timeout das conexões inspecionadas
ip reflexive-list timeout 120
interface Serial0
ip access-group TFTP_Only in
ip access-group TFTP_Return out
Após ser implementada, BrainRT01 não poderá acessar de nenhuma forma, a não ser via TFTP o servidor 172.30.1.10. Para analisarmos seu funcionamento, tentamos dar um ping no servidor TFTP por BrainRT01, e BrainRT02 responde com “Destination Unreachable” (U). Porém o tráfego TFTP ocorre normalmente. Observe os counters das ACL e o log do servidor com atenção.
Access-list com os contadores zerados
BrainRT02#show access-list
Extended IP access list TFTP_Only
10 permit udp host 200.20.20.1 host 172.30.1.10 eq tftp
20 evaluate TFTP_Reflect
30 deny ip any any
Reflexive IP access list TFTP_Reflect
Extended IP access list TFTP_Return
10 permit udp host 172.30.1.10 host 200.20.20.1 reflect TFTP_Reflect
BrainRT02#
Teste de ping de BrainRT01 ao servidor TFTP
BrainRT01#ping 172.30.1.10Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.30.1.10, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)
BrainRT01#
Contadores da access-list após o ping
BrainRT02#show access-list
Extended IP access list TFTP_Only
10 permit udp host 200.20.20.1 host 172.30.1.10 eq tftp
20 evaluate TFTP_Reflect
30 deny ip any any (11 matches)
Reflexive IP access list TFTP_Reflect
Extended IP access list TFTP_Return
10 permit udp host 172.30.1.10 host 200.20.20.1 reflect TFTP_Reflect
BrainRT02#
Acesso de BrainRT01 ao servidor TFTP
BrainRT01#copy running-config tftp:
Address or name of remote host []? 172.30.1.10
Destination filename [brainrt01-confg]?
!!
737 bytes copied in 4.240 secs (174 bytes/sec)
BrainRT01#
Contadores da access-list após o acesso TFTP
BrainRT02#show access-list
Extended IP access list TFTP_Only
10 permit udp host 200.20.20.1 host 172.30.1.10 eq tftp (5 matches)
20 evaluate TFTP_Reflect
30 deny ip any any (11 matches)
Reflexive IP access list TFTP_Reflect
permit udp host 200.20.20.1 eq 64158 host 172.30.1.10 eq 2275 (5 matches) (time left 85)
permit udp host 200.20.20.1 eq 63651 host 172.30.1.10 eq 2273 (5 matches) (time left 55)
Extended IP access list TFTP_Return
10 permit udp host 172.30.1.10 host 200.20.20.1 reflect TFTP_Reflect (9 matches)
BrainRT02#
Observe que acima aparecem duas regras na ACL TFTP_Reflect, que indicam as portas que os hosts usaram para se comunicar, e o time left, que representa o tempo que o router considera para manter a conexão. Após este tempo se exceder, as regras dinâmicas são removidas da ACL, e seus contadores são zerados.
Agora compare os logs acima com os do servidor TFTP e observe a correlação com a ACL reflexiva.
Espero que tenha ajudado. Até breve!
