Existem inúmeras vulnerabilidades nos switches Ethernet e as ferramentas de ataque para explorá-los existem há mais de uma década. Um atacante pode desviar qualquer tráfego para seu próprio PC para quebrar a confidencialidade, privacidade ou a integridade desse tráfego.
A maioria das vulnerabilidades são inerentes aos protocolos da Camada 2 e não somente aos switches. Se a camada 2 estiver comprometida, é mais fácil criar ataques em protocolos das camadas superiores usando técnicas comuns como ataques de man-in-the-middle (MITM) para coleta e manipulação do conteúdo.
Para explorar as vulnerabilidades da camada 2, um invasor geralmente deve estar mesma rede local do alvo. Se o atacante se utilizar de outros meios de exploração, poderá conseguir um acesso remoto ou até mesmo físico ao equipamento. Uma vez dentro da rede, a movimentação lateral do atacante torna-se mais fácil para conseguir acesso aos dispositivos ou tráfego desejado.
No vídeo descrevemos as 8 (oito) principais funcionalidades de segurança para switches que todo administrador de redes deveria saber..
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.
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.
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
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:
Camada 2: Especificam regras baseadas em endereços MAC de origem, destino, VLAN e tipos de protocolo Ethernet.
Camada 3(básica): Especificam regras baseadas em endereços IP e rede de origem.
Camada 3 (Avançada): Especificam regras baseadas em protocolos de camada 3, redes de origem e destino; e portas de origem e destino.
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: número 2000 a 2999
ACL Avançada: número de 3000 a 3999
ACL de camada 2: número de 4000 a 4999
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:
Endereço IP de origem
Endereço IP de destino
Porta de origem
Porta de destino
Tipo de pacote ICMP
Parâmetro SYN do TCP
Valor IP Precedence
Valor DSCP
Valor TOS
Fragmentos
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.
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.
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.
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
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).
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:
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:
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).
