As ACL (Access Control List) são utilizadas para classificar tráfego para os mais diversos fins, como por exemplo, políticas de filtro de pacotes, QoS e PBR.
Uma ACL pode classificar um tráfego baseando-se no fluxo de dados que entram ou saem de uma interface (porta física, interface VLAN, VLAN, etc).
Na maioria dos casos uma ACL é utilizada para determinar se um pacote será permitido ou descartado em uma interface com as ações PERMIT ou DENY.
Até!
A utilização de listas de acesso (ACL) para limitar as redes que poderão efetuar o gerenciamento do Switch e/ou Roteador é uma técnica bastante utilizada para restringir os hosts que terão permissão de acesso o equipamento.
Os equipamentos com a versão 7 do Comware diferem um pouco na configuração de atribuição de uma ACL ao acesso Telnet e SSH.
#
acl basic 2000
rule 0 permit source 192.168.11.1 0
rule 5 permit source 192.168.11.12 0
rule 10 permit source 192.168.11.11 0
! ACL com os hosts com permissão de acesso
#
telnet server enable
telnet server acl 2000
! Habilitando o serviço Telnet e aplicando a ACL 2000
#
Para filtrar o acesso via SSH utilize a mesma lógica.
ssh server enable
ssh server acl 2000
Caso o seu switch/roteador não suportar os comandos citados, veja o script citado por esse mesmo blog no post: http://www.comutadores.com.br/acl-para-gerenciamento-telnet-ssh-snmp/
Até logo
A dica abaixo foi encontrada enquanto eu navegava no site http://abouthpnetworking.com/2015/02/09/comware7-routed-port-acl-packet-filter-applies-to-switched-traffic/
A configuração de uma ACL para o filtro de pacotes em uma interface VLAN em Switches com o Comware 7, mesmo que seja para fins de roteamento, poderá ter o comportamento de uma VACL (VLAN ACL), isto é, mesmo que o pacote não seja roteado entre VLANs (e o tráfego seja entre máquinas internas), o Switch validará o tráfego com a ACL e dependendo da construção das regras, o pacote poderá ser descartado indesejadamente.
Este comportamento poderá ser controlado com o comando “packet-filter filter route” dentro da interface VLAN. Isto permitirá que o administrador decida se o tráfego será filtrado somente para o tráfego roteado (L3) ou se deixará no modo default, que é o filtro do tráfego L2 + L3.
[HP] interface vlan 20
[HP-Vlan-interface20] packet-filter 3003 inbound
! Aplicando a ACL avançada na interface VLAN
[HP-Vlan-interface20] packet-filter filter route
! Configurando a ACL para somente filtrar o tráfego roteado
# Caso queira retornar para o modo routed+switched digite comando abaixo. [HP-Vlan-interface20] packet-filter filter all
Até logo.
As ACL (Access Control List) são utilizadas para classificar tráfego para os mais diversos fins, como por exemplo, políticas de filtro de pacotes, QoS e PBR.
Uma ACL pode classificar um tráfego baseando-se no fluxo de dados que entram ou saem de uma interface (porta física, interface VLAN, VLAN, etc).
Na maioria dos casos uma ACL é utilizada para determinar se um pacote será permitido ou descartado em uma porta com as ações PERMIT ou DENY.
Essas ações são seguidas das definições DO QUE se deve permitir (PERMIT) ou negar (DENY). Estas, basicamente, são as principais opções:
ANY (tudo)
[IP do host/rede]
[subrede no formato wildcard]
[protocolo]
Imaginando de maneira prática, os Roteadores e Switches também podem utilizar como referência para classificação de tráfego as informações de cabeçalho de camada 2 (como endereço MAC), camada 3 (campos de cabeçalho IP) e camada 4 ( portas TCP e UDP).
Para uma ACL é possível adicionar diversas regras. A leitura das regras pelo equipamento é efetuada linha por linha, de cima para baixo; e após a condição ser encontrada (match) o restante das regras não serão mais verificadas. A ordem para satisfazer uma condição, é lida na ordem em que as regras são configuradas.
O blog do CCNA faz o seguinte comentário para a utilização de uma ACL para filtro de pacotes (lembrando que uma ACL pode incluir diversas regras):
A regra básica diz que somente UMA ACL pode ser aplicada em uma mesma interface e direção, em um determinado router (ou switch). Ou seja, em uma mesma interface você até pode ter mais de uma ACL, desde que em sentidos opostos. Os sentidos possíveis são ilustrados no diagrama abaixo.
(IN) entrante —–> ROUTER ——> sainte (OUT)
Tipos de ACL
Os equipamentos baseados no Comware permitem três tipos de ACL:
Definindo a ACL
A definição do template para a configuração das Listas de Acesso é baseado pelos números,que a identificam:
ACL Básica
Baseia-se no endereço de rede de origem para filtrar ou permitir o tráfego.
Imaginando que você deseja filtrar quais máquinas podem efetuar efetuar Read and Write via SNMP em um Switch…
acl number 2100 ! Criando a ACL 2100 rule permit source 172.31.1.100 0.0.0.0 ! Criando a primeira regra na ACL 2000 permitindo a rede 172.31.1.100 ! com 32 bits (máscara de host para somente uma máquina gerenciar o Switch via SNMP) quit snmp-agent community write comutadores acl 2100 ! Vinculando a ACL 2100 na communty SNMP RW “comutadores”
A regra acima irá permitir o acesso SNMP somente ao host 172.31.1.100, o restante da rede terá o acesso negado para coleta SNMP nesse equipamento.
Obs: Apesar do exemplo acima ser bem simples, uma ACL básica também pode ser configurada para filtrar pacotes que entram ou saem do Roteador com a política baseada na rede de origem.
ACL Avançada
A diferença entre uma ACL básica e avançada é a forma de relacionamento com as informações no cabeçalho IP. A ACL avançada utiliza os campos de endereço IP de origem e destino, porta e número de protocolo diferenciando pacotes como TCP e UDP.
Alguns parâmetros especiais poderão ser utilizados na construção de uma ACL avançada:
Abaixo segue o exemplo de uma ACL avançada criada e aplicada em uma interface do Roteador HP 6600 para filtro de pacotes na entrada da interface Giga3/2/1
firewall enable slot 3 ! Habilitando o filtro de pacotes no slot3 do roteador firewall default deny slot 3 ! Habilitando uma regra de deny implícito após a configuração manual da última regra da ACL acl number 3030 name INTERNET-INBOUND ! Criando a ACL 3030 e atribuíndo o nome de "INTERNET-INBOUND" rule 10 permit icmp destination 200.200.200.0 0.0.0.255 ! permindo os pacotes com o ip dentro do range 200.200.200.0/24 no cabeçalho de destino com wildcard rule deny ip source 10.0.0.0 0.255.255.255 rule deny ip source 172.16.0.0 0.15.255.255 rule deny ip source 192.168.0.0 0.0.255.255 rule deny ip source 127.0.0.0 0.255.255.255 ! negando qualquer pacote com ip de origem dentro do range da RFC 1918 rule 60 deny ip source 0.0.0.0 0.255.255.255 ! negando qualquer pacote com ip de origem como 0.0.0.0 rule 9999 permit ip ! permitindo qualquer endereço IP de origem e destino quit # acl number 3040 name INTERNET-OUTBOUND rule deny ip source 10.0.0.0 0.255.255.255 rule deny ip source 172.16.0.0 0.15.255.255 rule deny ip source 192.168.0.0 0.0.255.255 rule deny ip destination 224.0.0.0 15.255.255.255 rule deny ip source 224.0.0.0 15.255.255.255 # interface GigabitEthernet3/2/1 port link-mode route firewall packet-filter name INTERNET-INBOUND inbound firewall packet-filter name INTERNET-OUTBOUND outbound ! Aplicando a ACL para filtro na entrada e saída de pacotes ip address 123.123.123.218 255.255.255.252 #
Segue um segundo exemplo de ACL avançada mas dessa vez em Switches do modelo 4800
acl number 3000
! Criando a ACL 3000
rule permit ip source 172.31.1.0 0.0.0.255 destination 192.168.1.0 0.0.0.255
! Criando a primeira regra na ACL 3000 permitindo a rede 172.31.1.0 com 24 bits (máscara
/24) efetuar comunicação IP com a rede 192.168.1.0/24
rule deny ip source any
! Criando a segunda regra na ACL 3000 negando qualquer rede de origem
quit
#
interface vlan 2
ip address 192.168
packet-filter 3000 inbound
!Aplicando a ACL 2000 para filtro na interface VLAN.
Obs: Para aplicarmos uma ACL em Portas físicas ou interface VLAN de um Switch é utilizado o comando packet-filter, já para roteadores, comando poderá ser incrementando com a sintaxe “firewall packet-filter….”
A regra acima irá permitir a comunicação IP, da rede 172.31.1.0/24 para a rede 192.168.1.0/24, o restante do tráfego terá o acesso negado.
Se precisarmos utilizar outros parâmetros para match da ACL podermos utilizar o caracter ? após o permit ou deny. Parâmetros como TCP, UDP, ICMP e etc poderão também ser utilizados
O exemplo abaixo exemplifica a utilização de parâmetros de portas TCP para criarmos a regra, como por exemplo permitir o acesso somente a serviços que realmente serão utilizados.
O restante do tráfego será negado, provendo maior segurança e escalabilidade pela utlilização de diversas VLANs.
[4800-acl-adv-3020] rule permit tcp source 172.31.1.0 0.0.0.255 destination 192.168.1.0 0.0.0.255 destination-port eq 80
ACL de camada 2
As ACL que utilizam parâmetros da camada de enlace do modelo de referencia OSI, poderão ser utilizadas para filtrar baseando-se em campos como ID da VLAN, mascara de endereços MAC (os primeiros bits são reservados para endereço dos fabricantes) , tipos de Protocolos,etc.
acl number 4999 rule 0 permit type 8868 ffff rule 1 permit source 00e0-bb00-0000 ffff-ff00-0000 rule 2 permit source 0003-6b00-0000 ffff-ff00-0000 rule 3 permit source 00e0-7500-0000 ffff-ff00-0000 rule 4 permit source 00d0-1e00-0000 ffff-ff00-0000 rule 5 permit source 0001-e300-0000 ffff-ff00-0000 rule 6 permit source 000f-e200-0000 ffff-ff00-0000 rule 7 permit source 0060-b900-0000 ffff-ff00-0000 rule 8 deny dest 0000-0000-0000 ffff-ffff-ffff
Obs: a configuração e o tipo de ACL disponivel em cada equipamento pode sofrer pequenas variações ou limitações na configuração. Sempre faça um teste antes de aplicar a ACL em um ambiente de produção.
Até logo.
Referência
http://blog.ccna.com.br/2007/10/21/tutorial-basico-acls-para-o-exame-ccna/
http://blog.ccna.com.br/2012/11/21/wildcards-x-mascaras-de-rede/
Leia também
Galera, segue um comunicado copiado do site da HP sobre a alteração no modelo de filtro de pacotes para VLAN. O documento foi publico em 29/09/2014 no endereço aqui .
DESCRIÇÃO
Foi introduzida uma alteração no software recente que modifica a maneira como as ACLs são implementadas quando estas são aplicadas a interfaces de VLAN.
Antes da alteração do software, uma ACL de filtro de pacote aplicada a uma interface de VLAN afetava apenas o tráfego que passava pela interface de VLAN entre a VLAN e outras VLANs/redes. Após a alteração do software, uma ACL aplicada a uma interface de VLAN também filtra os dados locais na própria VLAN.
Em particular, é possível que todo o tráfego local em uma VLAN fique bloqueado após a atualização para o software que implementa essa alteração. Por exemplo, se um cliente implementar uma ACL com uma regra padrão de “Negar IP” destinada a bloquear o acesso indesejável entre as redes, agora essa regra também bloqueará o tráfego dentro da mesma VLAN:
# Definir ACL acl number 3600 name test-acl-in hardware-count enable rule 10 permit ip destination 172.22.254.0 0.0.0.255 rule 20 deny ip #Aplicar ACL à interface de VLAN interface Vlan-interface600 ip address 10.90.32.1 255.255.255.0 packet-filter name test-acl-in inbound
Anteriormente, essa ACL teria permitido todo o tráfego na VLAN, bloqueando apenas o tráfego de IP não permitido que estivesse atravessando para outras VLANs. Após a atualização do software, a mesma regra bloqueia todo o tráfego de IP dentro da VLAN.
ABRANGÊNCIA
Essa alteração afeta vários produtos, definidos a seguir.
| Nome do produto | Versões de software com a alteração |
| Switches 5800/5820 | R1808P16 e posterior |
| Switches 5500HI | R5206P02 e posterior |
| Switches 5500EI/5500SI/5120EI | R2220P11 e posterior |
| Switches 3600 EI e SI V2 | R2108P10 e posterior |
| Switches 5900/5920 | R2307 e posterior |
| Switches 5830 | R1118P05 |
| Switches 10500 | R1208P06 e posterior |
| Switches 7500 | R6708P06 e posterior |
| Switches 11900 (V7) | R2105P05 e posterior |
| Switches 10500 (V7) | R2105P05 e posterior |
| Switches 12900 (V7) | R1005P01 e posterior |
RESOLUÇÃO
ANTES de atualizar para as versões de software afetadas, modifique as definições de ACL com regras para permitir especificamente o tráfego necessário dentro da VLAN.
Usando o exemplo acima, a ACL será modificada para permitir um certo tráfego de IP local usando uma regra adicional (15) na definição da ACL, da seguinte maneira:
acl number 3600 name test-acl-in hardware-count enable rule 10 permit ip destination 172.22.254.0 0.0.0.255 rule 15 permit ip source 10.90.32.11 24 destination 10.90.32.12 24 rule 20 deny ip
Agora, essa ACL permitirá a comunicação dentro da VLAN.
Plataformas de Hardware Afetadas: HP 10500 Switch Series, HP 3600 EI Switch Series, HP 3600 SI Switch Series, HP 5120 EI Switch Series, HP 5500 EI Switch Series, HP 5500 HI Switch Series, HP 5500 SI Switch Series, HP 5800 Switch Series, HP 5820 Switch Series, HP 5830 Switch Series, HP 5900 Switch Series, HP 5920 Switch Series, HP 7500 Switch Series, HP FlexFabric 11900 Switch Series, HP FlexFabric 12900 Switch Series
O Kleber Coelho, enviou a dica abaixo na qual ele precisou mexer em uma configuração sensível no Switch HP 7510 que poderia gerar a perda da gerencia do equipamento.
Inicialmente ele salvou a configuração atual do Switch. Após isso, agendou o reboot para 10 minutos (em caso de perda da gerencia, o Switch reiniciaria e voltaria a ultima configuração salva), aplicou a configuração e após o sucesso dos comandos aplicados, ele cancelou o reboot.
A configuração do schedule reboot deverá ser feita no modo “user-view”
Segue o email do Kleber:
Diego, boa tarde, tudo bem?
Recentemente precisei bloquear da divulgação do OSPF um IP de gerência local em um HP-A7510.
Se for útil para você colocar no blog, sinta-se à vontade!# salvando a configuração atual save force # gatilho de reboot para garantir a recuperação, # caso dê algo errado e perca o acesso schedule reboot delay 10 # criar ACL com redes bloqueadas system acl number 2500 name Remove_BOGON_OSPF # rule deny source <IP> <Wildcard> rule deny source 192.168.255.0 0.0.0.255 rule permit # aplicar ACL na instancia OSPF ospf 1 filter-policy 2500 export # Se der algo errado e perder acesso, # basta esperar o equipamento reiniciar em 10 minutos. # Se tudo der certo, salve e remova o agendamento de reboot. save force quit quit undo schedule reboot
Agradeço ao Kleber pela dica enviada. 🙂
A configuração de hierarchical CAR permite agregar inúmeras políticas de “limitação de banda” e compartilhar sobre uma única “grande” banda.
Dependendo do modo de configuração, a limitação de banda dos perfis (traffic classifier + traffic behavior) de “QoS” flutuará até atingir o limite do hierarchical CAR.
Imaginando que no cenário abaixo um Cliente quer limitar a banda de HTTP em 128Kbps e o “restante do tráfego” em 64Kbps. Como a banda contratada foi de 256Kbps, o trafego HTTP poderá usar 192Kbps caso o “restante do tráfego” esteja em 64kbps; ou o “restante do tráfego” poderá utilizar 128Kbps caso o HTTP não passe de 128Kbps.
Configuração
vlan 3 # qos car CLIENTE-A hierarchy cir 256 ! Configurando o hierarchy CAR como 256kbps # acl number 3001 name MATCH_WWW rule 0 permit tcp destination-port eq www ! Selecionando o tráfego HTTP como destino # traffic classifier MATCH_HTTP operator and if-match acl name MATCH_WWW ! Classificação do tráfego da ACL MATCH_WWW ! traffic classifier MATCH_ANY operator and if-match any ! Classificação para qualquer tipo de tráfego # traffic behavior 128kbps-BW car cir 128 hierarchy-car CLIENTE-A mode or ! Comportamento para limitar a banda em 128Kbps vinculado ao hierarchy-car traffic behavior 64kbps-BW car cir 64 hierarchy-car CLIENTE-A mode or ! Comportamento para limitar a banda em 64Kbps vinculado ao hierarchy-car # qos policy BW-CLIENTE-A classifier MATCH_WWW behavior 128kbps-BW classifier MATCH_ANY behavior 64kbps-BW ! Criando Policy para vincular os classifier + behavior # interface GigabitEthernet1/0/15 port link-mode bridge port access vlan 3 qos apply policy BW-CLIENTE-A inbound qos apply policy BW-CLIENTE-A outbound ! Aplicando a Policy à interface no sentido de entrada e saída
Para a verificação da banda e scripts utilizados use os comandos display qos car name [nome do hierchical car] ou display qos policy interface [nome da interface] [ inbound | outbound ]
Modos AND e OR
Por padrão, o hierarchical CAR funciona no modo OR no qual um fluxo pode passar o limite aplicado a ele desde que não ultrapasse o limite do hierarchical CAR. Como, por exemplo, o cenário dado nesse post.
Já o modo AND o fluxo não pode passar o limite aplicado e a soma dos 2 não pode passar o limite total do hierarchical CAR. Por exemplo, 2 fluxos configurados com 128Kbps e o hierarchical CAR configurado com 192kbps. Cada fluxo individualmente não poderá passar da banda total contratada (192Kbps) e caso haja banda disponível e o total de cada fluxo será de 128Kbps (se houver banda disponível).
Até logo! 😉
A aplicação de ACL para limitar as redes que poderão efetuar o gerenciamento do Switch e/ou Roteador é uma técnica bastante utilizada para restringir quais redes ou hosts de origem terão a permissão para gerenciar o equipamento via Telnet, SSH ou SNMP
Imaginando uma empresa com diversas sub redes, permitiremos no cenário abaixo o acesso ao Switch apenas da sub rede 172.31.1.0/24 (lembrando que a mascara para listas de acesso [ACL] são no formato de mascara curinga [wildcard mask])
acl number 2000
rule 0 permit source 172.31.1.0 0.0.0.255
rule 5 deny
#
user-interface vty 0 4
acl 2000 inbound
! Vinculando a ACL 2000 ao VTY
# snmp-agent community read 123abc acl 2000 snmp-agent community write aaa111 acl 2000 ! Vinculando a ACL 2000 às comunidades SNMP "123abc" e "aaa111"
Caso a interface de gerenciamento esteja dentro de uma VRF, ou a origem do acesso inicie de uma vpn-instance (VRF), a ACL deverá fazer referência a isso:
[H3C-acl-basic-2000]rule 1 permit source 172.31.1.0 0.0.0.255 vpn-instance ?
STRING<1-31> VPN-Instance name
Dúvidas? Deixe um comentário…
Até logo!
Para configurarmos as listas de acesso (ACL) e aplicarmos a uma interface física ou VLAN no Switch 7900 é necessário o vínculo a uma politica de QoS, aplicando a ACL indiretamente à Interface ou VLAN.
No script abaixo iremos negar a rede 192.168.1.0/24 de comunicar-se com a rede 172.31.1.0/24.
Configuração
vlan 192
vlan 172
#
interface Vlan-interface192
ip address 192.168.1.1 255.255.255.0
#
interface Vlan-interface172
ip address 172.31.1.1 255.255.255.0
#
acl number 3001
!criando a ACL avançada 3001
rule 0 deny ip source 192.168.1.0 0.0.0.255 destination 172.31.1.0 0.0.0.255
! regra 0 irá negar a origem 192.168.1.0/24 (é obrigatório a utilização de máscara curinga) de comunicar com a rede 172.31.1.0/24. Nesse caso poderíamos ter mais de uma regra!!
quit
traffic classifier rede_192 operator and
! Criando a classificação de tráfego com o nome rede_192
if-match acl 3001
! Efetuando match na ACL 3001
quit
#
traffic behavior rede_172
! Criando o comportamento com o nome rede_172
filter deny
! Criando o filtro negar (deny)
quit
#
qos policy proibe_rede_192_172
!Criando a policy com nome proibe_rede_192_172
classifier rede_192 behavior rede_172
! vinculo do classifier rede_192(ACL) com o behavior rede_172 (deny)
quit
qos vlan-policy proibe_192_172 vlan 192 inbound
! aplicando a politica de QoS na VLAN 192, proibindo a rede 192.168.1.0/24 de comunicar-se com a rede 172.31.1.0/24 no sentido de entrada do Switch
Para aplicarmos a sintaxe a uma porta física (GigabitEthernet) a sintaxe seria:
interface GigabitEthernet 2/0/9 qos apply policy proibe_192_172 inbound
A utilização do script acima para filtro de pacotes negará todas as regras que forem explicitamente escritas, nesse caso permitirá a comunicação da rede 192.168.1.0/24 com qualquer outra rede que não tenha referência nas linhas da ACL 3001 (não importando o permit ou deny da ACL).
Até logo 🙂
Publicado originalmente em 10 DE AGOSTO DE 2010
O Script de hoje é bastante simples e permite a criação de usuário e senha para acesso remoto, certificando o IP de origem da máquina do Técnico que fará o acesso remoto (conexão Telnet ou SSH) para gerenciamento do Switch.
Obs: certifique-se que o serviço SSH ou Telnet está habilitado no Switch
local-user diego !Criando o usuário diego password simple diego !Configurando a senha diego para o usuário diego, a linha password poderá ser substituída por "password cipher diego" que cifrará a senha no arquivo de configuração durante a visualização bind-attribute ip 172.31.1.4 ! efetuando o vinculo da máquina 172.31.1.4 com o usuário diego, isto é, se o usuário tentar efetuar a conexão telnet ou ssh no Switch de outra origem, o acesso do usuário será negado! authorization-attribute level 3 ! atribuindo o nível de administrador ao usuário. service-type ssh telnet ! permitindo acesso ssh e telnet pelo usuário diego
Obs:Certifique-se também a configuração da Interface vty 0 4 😉
user-interface vty 0 4 authentication-mode scheme