Você sabe uma que é uma ACL temporizada ou Time-Based ACL?
No artigo de hoje vamos ver, de uma forma bem simples, como utilizar ACLs em roteadores Cisco para criar regras de bloqueio/permissão que levem em consideração o período de tempo. Essas são as chamadas “Time-Based ACL“. Lembramos que esse conceito não é pré-requisito para a certificação CCNA, mas que pode ser muito útil em situações reais.
Time-Based ACL
Uma time-based ACL deve ser utilizada quando você desejar restringir o tráfego na rede baseado em períodos específicos do dia. Por exemplo, se você deseja conceder acesso a Internet aos usuários de uma rede somente em horários específicos do dia ou deseja restringir o acesso telnet aos seus roteadores fora do horário comercial as time-based ACL podem ser utilizadas. As time-based ACL foram introduzidas no Cisco IOS Software Release 12.0.1.T e permitem controlar o acesso baseado no dia/horário. Basicamente a configuração é feita criando-se um time-range e o aplicando em uma ACL.
Vamos verificar o uso desse recurso em dois exemplos bem simples.
Cenário 01: Você trabalha como administrador de rede Cisco e seu chefe lhe passa a seguinte tarefa.
“Precisamos permitir o acesso ao servidor web (ip 192.168.1.254) aos funcionários da empresa somente no horário comercial (9h – 18h / Seg-Sex). Fora do horário comercial, nenhum usuário da rede poderá acessar esse servidor. Os demais tipos de tráfegos devem ser permitidos.”
Num primeiro momento você poderia pensar em resolver dessa forma:
time-range HORARIO-COMERCIAL
periodic weekdays 9:00 to 18:00
!
ip access-list extend DENY-WEB
permit tcp any host 192.168.1.254 eq www time-range HORARIO-COMERCIAL
permit ip any any
Você definiu um time-range chamado HORARIO-COMERCIAL onde configurou o horário da 9am as 18pm nos dias da semana. Em seguida definiu uma ACL chamada DENY-WEB permitindo o tráfego tcp destinado ao servidor e aplicou o time-range na regra. Mas será que isso vai funcionar? Vamos examinar mais de perto as regras.
Suponha que um usuário tentou acessar o servidor segunda-feira as 11h da manhã. A primeira regra da ACL irá dar o match e deixar o tráfego passar. Ótimo, era o que queríamos.
Mas agora vamos supor que o mesmo usuário tentou acessar o servidor na segunda-feira as 07h da manhã, ou seja, fora do horário especificado. A primeira regra não dá match, legal!!! Mas, como podemos perceber, a segunda regra vai permitir passar (permit ip any any) e o tráfego será permitido.
Agora examine a configuração abaixo.
time-range HORARIO-COMERCIAL
periodic weekdays 9:00 to 18:00
!
ip access-list extend DENY-WEB
permit tcp any host 192.168.1.254 eq www time-range HORARIO-COMERCIAL
deny tcp any host 192.168.1.254 eq www
permit ip any any
Viram só…agora sim, muito melhor dessa forma. Repare que agora quando a primeira regra não der match, só será permitido o tráfego que não for direcionado ao servidor 192.168.1.254, pois a segunda regra bloqueia o tráfego destinado a esse endereço.
Cenário 02: Agora seu chefe lhe passou a seguinte tarefa.
“Nossos usuários deverão ter acesso a Internet, durante o horário comercial, somente através do servidor de proxy cujo endereço é 192.168.1.254 porta 3128. Fora do horário comercial os usuários terão acesso liberado. No horário comercial o único acesso liberado será o servidor de proxy. Além do mais, queremos que seja criado apenas um time-range nessa ACL.”
time-range HORARIO-COMERCIAL
periodic weekdays 9:00 to 18:00
!
ip access-list extend DENY-WEB
permit tcp any host 192.168.1.254 eq 3128 time-range HORARIO-COMERCIAL
permit ip any any
Vamos analisar mais de perto as linhas acima. Vamos supor que seja segunda-feira as 10am. Um usuário tenta acessar o site “dltec.com.br” diretamente, sem o proxy. A primeira regra da ACL não dará match. O período de tempo está dentro do time-range mas o endereço de destino não é o do proxy. Mas a segunda regra irá dar acesso ao site (permit ip any any) e o usuário irá conseguir o site sem ser pelo servidor de proxy.
Bem, uma segunda tentativa poderíamos tentar as regras abaixo.
time-range HORARIO-NAO-COMERCIAL
periodic weekend 0:00 to 23:59
periodic weekdays 0:00 to 8:59
periodic weekdays 18:01 to 23:59
!
time-range HORARIO-COMERCIAL
periodic weekdays 9:00 to 18:00
!
ip access-list extend DENY-WEB
permit tcp any host 192.168.1.254 eq 3128 time-range HORARIO-COMERCIAL
permit ip any any time-range HORARIO-NAO-COMERCIAL
Perceba que dessa forma funciona. Segunda-feira as 10am se um usuário tentar acessar diretamente o endereço “dltec.com.br” não será permitido, pois a primeira regra nega o acesso. Da mesma forma, a segunda regra não permite o acesso, pois o horário está fora do time-range HORARIO-NAO-COMERCIAL. O pacote será dropado, exatamente como desejávamos, mas nessa solução utilizamos 2 time-range e fugimos do requisito da tarefa.
Agora veja a ACL abaixo.
time-range HORARIO-NAO-COMERCIAL
periodic weekend 0:00 to 23:59
periodic weekdays 0:00 to 8:59
periodic weekdays 18:01 to 23:59
!
ip access-list extend DENY_WEB
permit ip any any time-range HORARIO-NAO-COMERCIAL
permit tcp any host 192.168.1.254 eq 3128
Agora temos uma ACL que permite o tráfego IP apenas no horário definido no time-range HORARIO-NAO-COMERCIAL. Durante o horário comercial os usuários só terão acesso ao servidor de proxy localizado no endereço 192.168.1.254 porta 3128. Todo o resto será bloqueado. E com isso conseguimos atingir nosso objetivo.
Espero que esse artigo lhe seja útil e que você possa utilizar esses conceitos no seu dia-a-dia.
Acesse o curso de “CCNA CCENT e CCNA ICND-2 Online” em nossa área Premium.
Prepare-se para o CCNA e aprenda várias tecnologias fundamentais para área de Redes como ACL, STP, RSTP, OSPF, OSPFv3, troubleshooting e muito mais.
Clique aqui para ativar o curso e inciar seus estudos em nossa área de membros premium!
Não é membro premium? Clique aqui e saiba mais sobre a DlteC Premium.
Fonte: Esse artigo foi baseado e traduzido do blog ArdenPackeer.com