Uma novidade bem legal da versão 7 do Comware (Sistema Operacional de Switches e Roteadores HP) é o suporte para scripts TCL e Python.
Um grupo de HPN criou um repositório dos scripts no GITHUB https://github.com/networkingdvi/HPN-Scripting#hpn-scripting
O repositório é totalmente free e para ter contato com a galera, acesse: http://abouthpnetworking.com/2014/06/22/hpn-scripting-on-github/
abração
Os switches Aruba usam botões Reset e Clear no painel frontal para permitir que os usuários reiniciem (reset) a configuração do switch para o padrão de fábrica ou para redefinir a senha do console (clear). Esses recursos criam um risco de segurança e para ambientes não controlados ao switch. Recomenda-se que os administradores desabilitem esses recursos.
É importante entender que desativar esses recursos restringe severamente as opções da equipe de TI para recuperar um switch em cenários que não se possui as credenciais de acesso.
Esses botões permitem que um simples clip de papel possa limpar as senhas (clear). O botão clear não apaga a configuração e não desliga o switch, apenas apaga as senhas.
switch(config)# no front-panel-security password-clear switch(config)# no front-panel-security factory-reset
Observações
– Pressionar o botão Clear por um segundo redefine a(s) senha(s) configurada(s) no switch.
– Pressionar o botão Reset sozinho por um segundo faz com que o switch seja reinicializado.
– Você também pode usar o botão Reset junto com o botão Clear (Reset + Clear) para restaurar o padrão de fábrica configuração do switch.
– Para validar utilize show front-panel-security
Referências
ArubaOS-Switch Hardening Guide for 16.06
Aruba 2930F / 2930M Access Security Guide for ArubaOS-Switch
Os ataques à rede local do tipo man-in-the-middle, ou comumente conhecido como MITM, permitem ao atacante posicionar-se no meio da comunicação entre duas partes. Este ataque é útil para conduzir outros ataques, como sniffing (captura das informações) e session hijacking (sequestro de sessão).
A ferramenta arpspoof falsifica mensagems ARP reply com o intuido de direcionar o tráfego da máquina alvo para a máquina do atacante.
A ferramenta SSLStrip, escrita por Moxie Marlinspike, é bastante utilizada em um ataque man-in-the-middle para SSL Hijacking. O SSLStrip fecha uma sessão HTTP com a vítima e uma sessão HTTPS com a página web, capturando assim as informações que deveriam ser criptografadas.
A feature port isolate permite ao administrador isolar portas do Switch dentro de um grupo para impossibilitar a comunicação das máquinas pertencentes ao grupo, de uma maneira fácil e prática. A comunicação das interfaces do Switch configuradas com port isolation group ocorrerá somente com as portas que não possuem o comando aplicado.
O Switch HP v1910 suporta apenas um único grupo de isolamento (até o momento) que é criado automaticamente pelo sistema como grupo 1. Não é possível remover o grupo e nem criar outros grupos de isolamento.
Não há nenhuma restrição no número de portas atribuídos a um port isolation group .
Por exemplo, se você possui 3 servidores de diferentes cliente em um mesmo Switch na porta Giga1/0/2, Giga1/0/3 e Giga1/0/4 e em uma mesma VLAN, mas não quer permitir a conexão entre eles,configure as portas 2 , 3 e 4 do Switch como port isolation group para limitar a comunicação entre os servidores.
Imaginando nesse mesmo exemplo que o roteador esteja na porta Giga1/0/1 do Switch (porta não configurada como port isolation group), a comunicação das máquinas com esse roteador /firewall ocorrerá normalmente.
Para configurar via web selecione Security > Port Isolate Group e clique em Modify…
Uma das grandes vantagens dos Access Point Aruba é a utilização do mesmo equipamento em diversos cenários, como os APs trabalhando de modo independente, ou em cluster, gerenciado por uma Controladora física, Controladora virtual ou mesmo em nuvem. Agora os Access Point podem também serem chamados de UAP (Unified Access Point) e configurados de diversas maneiras e com funções especificas dentro da arquitetura WLAN, como por exemplo:
– Campus AP (CAP): também chamado de CAP, é um típico Access Point que será conectado a uma controladora, que fará o seu gerenciamento.
– Mesh APs: São APs para Campus que usam a interface de rádio como uplink. O Mesh Portal (AP) tem uma conexão física para rede corporativa. O Mesh Point (AP) utiliza seu rádio para acesso à rede corporativa.
– Air monitors (AMs): Efetuam a varredura da rede Wifi para coletar informações de RF e IDS
– Spectrum APs (SA): São Access Points configurados (de forma temporária ou permanente) para capturar sinais de rádio para análise, como por exemplo em cenários de interferência, documentação e/ou mapeamento.
– Remote AP (RAP): Atuam de forma similar ao Campus AP, mas normalmente acessam a Internet para comunicação com a controller através de um túnel VPN. Um RAP pode também ser configurado como um Remote Mesh portal, que é basicamente um RAP com funções de Mesh portal.
– Instant APs (IAPs): não necessitam de uma controladora. Todos os IAPs na mesma sub rede irão comunicar-se e formar uma Virtual Controller (VC) então eles podem operar de forma independente de uma controladora física.
Um ponto de atenção: tome cuidado ao converter seu Access Point em ambiente de produção. Pesquise, faça testes e alterações em ambientes de laboratório, antes de coloca-lo na rede operacional.
Referências
Aruba Certified Design Professional_ Official Certification Study Guide ( HPE6-A47)
https://blogs.arubanetworks.com/solutions/aruba-unified-ap-platform/
A Aruba lançou uma linha de Access Point para pequenas empresas chamada de Instant On, oferecendo visibilidade e estabilidade no acesso . O hardware utilizado é tão robusto quanto o dos IAP (ou atualmente chamados UAP), mas possui um firmware próprio dedicado para a serie. É muito importante não confundir os APs Aruba Instant On com os APs Aruba Instant. O Aruba Instant é uma solução corporativa com muitas opções e recursos avançados, além de licenças adicionais necessárias para gerenciamento através da nuvem com o Aruba Central ou Controladora on-premises, enquanto o serviço do portal para gerenciamento do Aruba Instant On é um recurso incluso, sem custo adicional.
O Aruba Instant On é destinado a organizações menores, com menos de 100 usuários. Como o Aruba Instant On foi desenvolvido para simplificar a implementação da rede sem fio as configurações complexas para WLAN não estão disponíveis. As documentações da Aruba indicam o Instant On como ideal para o varejo, pequenos hotéis, hostels e escritórios.
A configuração dos APs é bem intuitiva e o administrador só precisa fornecer os nomes da rede, os números da VLAN (se houver) e as chaves pré-compartilhadas (PSK). Para os cenários com autenticação 802.1X , os APs Instant On também oferecem suporte à funcionalidade.
Um grande atrativo é a facilidade para implementação e gerenciamento – além do custo dos APs. Todo o gerenciamento é executado em nuvem através de um app ou um portal, sem licenciamento ou necessidade de controller externa (mesmo para um grupo de access points).
Entre as principais funcionalidades temos, o controle de RF (largura de canal, seleção de canal e banda 2.4Ghz e/ou 5Ghz), visibilidade/controle sobre os apps, suporte a PPPoE, Guest, Captive portal, suporte a alta disponibilidade e RADIUS proxy.
Configurando o Instant On através do App
Pronto! Já é possível gerenciar e administrar os APs através do app ou portal web https://portal.arubainstanton.com/
Referências
https://www.arubainstanton.com/products/indoor/
Em uma rede que oferece DHCP ao AP InstantOn o provisionamento é bem intuitivo e basicamente você necessita apenas utilizar o app ou efetuar o provisionamento através do portal web: http://www.comutadores.com.br/aruba-instant-on-configuracao-atraves-do-app/
Para a configuração do AP para estabelecer a conexão com o provedor atraves do PPPoE é necessário efetuar um procedimento diferente com alguns pontos de atenção:
1. A configuração do PPPoE deverá ser executada antes da integração do AP com a nuvem. Caso o AP já esteja integrado com a nuvem, a configuração do PPPoE não estará mais disponivel para modificações.
2. No entanto, se o AP perder a conectividade com a nuvem e forem detectadas falhas de PPPoE, você poderá acessar a WebUI local e atualizar as configurações novamente.
Configurando InstantOn com PPPoE
Siga as etapas abaixo para configurar o PPPoE na sua rede:
1. O Instant On AP deve estar conectado ao modem fornecido pelo provedor, mas não possui um endereço IP fornecido pelo servidor DHCP.
2. Quando o LED do AP ficar laranja sólido, o AP transmitirá um SSID InstantOn-AB:CD:EF aberto, após aproximadamente um minuto – em que AD: CD: EF corresponderá aos três últimos octetos do endereço MAC do AP.
3. Conecte seu notebook ou celular ao SSID e acesse o servidor da Web local em https://connect.arubainstanton.com. A página de configuração local da WebUI é exibida.
4. Em Endereçamento IP, selecione o botão de opção PPPoE.
5. Digite o nome de usuário e a senha do PPPoE fornecidos pelo seu provedor, nos respectivos campos.
6. Clique em Aplicar. O AP será reiniciado assim que a configuração do PPPoE for aplicada.
7. Aguarde as luzes LED piscarem em verde e laranja. Isso indica que o link PPPoE está ativo e estável. Você verá o status de integração do dispositivo agora com a mensagem ” Waiting to be onboarded.. “. Esta etapa pode levar mais cinco minutos, se o AP atualizar seu firmware durante o processo de reinicialização.
Referências
https://www.arubainstanton.com/techdocs/en/content/get-started/pppoe.htm
A utilização de VRFs (Virtual Routing and Forwarding ou vpn-instance na linguagem HP) em Roteadores permite a criação de tabelas de roteamentos virtuais que trabalham de forma independente da tabela de roteamento “normal”, protegendo os processos de roteamento de cada cliente de forma individual.
Como nós explicamos anteriormente no post http://www.comutadores.com.br/roteamento-entre-vrfs-com-mp-bgp-em-roteadores-hp-h3c/ o rotemento entre VRFs (quando necessário) pode ser efetuado com a manipulação do route-targets (RT) com o processo MP-BGP ativo no Roteador.
Há também cenários em que é necessário a troca seletiva de prefixos de rede entre as tabelas de roteamento virtuais, escolhendo quais redes devem ser exportardas ou não entre as VRFs. Lembrando que os valores vpn-target (route-target) trabalham com as Extended community do BGP para troca de prefixos entre VRFs, é possível manipular o processo via route-policy (route-map), configurando a “comunidade estendida” para o prefixo e utilizando o comando export dentro da VRF.
Relembrando…
No diagrama abaixo há 2 VRFs já configuradas (com o processo MP-BGP ativo) e com seus respectivos prefixos.
Como os valores para import/export das VRFs não são os mesmos, não há roteamento entre as VRFs (cada VRF tem o seu roteamento isolado).
comutadores.com.br
# Roteamento Seletivo entre VRFs (1º exemplo)
!
ip vpn-instance Client_A
route-distinguisher 65000:1
vpn-target 65000:1 export-extcommunity
vpn-target 65000:1 import-extcommunity
#
ip vpn-instance Client_B
route-distinguisher 65000:2
vpn-target 65000:2 export-extcommunity
vpn-target 65000:2 import-extcommunity
#
!
interface Loopback1
ip address 1.1.1.1 255.255.255.255
!
bgp 65000
undo synchronization
#
ipv4-family vpn-instance Client_A
network 192.168.1.0
network 192.168.2.0
network 192.168.3.0
#
ipv4-family vpn-instance Client_B
network 172.16.1.0 255.255.255.0
network 172.16.2.0 255.255.255.0
network 172.16.3.0 255.255.255.0
#
#
ip route-static vpn-instance Client_A 192.168.1.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_A 192.168.2.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_A 192.168.3.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_B 172.16.1.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_B 172.16.2.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_B 172.16.3.0 255.255.255.0 NULL0
#
#
[R1]display ip routing-table vpn-instance Client_A
Routing Tables: Client_A
Destinations : 5 Routes : 5
Destination/Mask Proto Pre Cost NextHop Interface
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
192.168.1.0/24 Static 60 0 0.0.0.0 NULL0
192.168.2.0/24 Static 60 0 0.0.0.0 NULL0
192.168.3.0/24 Static 60 0 0.0.0.0 NULL0
[R1]display ip routing-table vpn-instance Client_B
Routing Tables: Client_B
Destinations : 5 Routes : 5
Destination/Mask Proto Pre Cost NextHop Interface
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
172.16.1.0/24 Static 60 0 0.0.0.0 NULL0
172.16.2.0/24 Static 60 0 0.0.0.0 NULL0
172.16.3.0/24 Static 60 0 0.0.0.0 NULL0
No exemplo abaixo, caso manipulassemos o import/export, teríamos as 2 tabelas de roteamento compartilhadas…
# comutadores.com.br
# Roteamento Seletivo entre VRFs (2º exemplo)
!
#
ip vpn-instance Client_A
route-distinguisher 65000:1
vpn-target 65000:1 export-extcommunity
vpn-target 65000:1 65000:2 import-extcommunity
#
ip vpn-instance Client_B
route-distinguisher 65000:2
vpn-target 65000:2 export-extcommunity
vpn-target 65000:2 65000:1 import-extcommunity
#
!
interface Loopback1
ip address 1.1.1.1 255.255.255.255
!
bgp 65000
undo synchronization
#
ipv4-family vpn-instance Client_A
network 192.168.1.0
network 192.168.2.0
network 192.168.3.0
#
ipv4-family vpn-instance Client_B
network 172.16.1.0 255.255.255.0
network 172.16.2.0 255.255.255.0
network 172.16.3.0 255.255.255.0
#
#
ip route-static vpn-instance Client_A 192.168.1.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_A 192.168.2.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_A 192.168.3.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_B 172.16.1.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_B 172.16.2.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_B 172.16.3.0 255.255.255.0 NULL0
#
#
[R1]display ip routing-table vpn-instance Client_A
Routing Tables: Client_A
Destinations : 8 Routes : 8
Destination/Mask Proto Pre Cost NextHop Interface
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
172.16.1.0/24 BGP 130 0 0.0.0.0 NULL0
172.16.2.0/24 BGP 130 0 0.0.0.0 NULL0
172.16.3.0/24 BGP 130 0 0.0.0.0 NULL0
192.168.1.0/24 Static 60 0 0.0.0.0 NULL0
192.168.2.0/24 Static 60 0 0.0.0.0 NULL0
192.168.3.0/24 Static 60 0 0.0.0.0 NULL0
[R1]display ip routing-table vpn-instance Client_B
Routing Tables: Client_B
Destinations : 8 Routes : 8
Destination/Mask Proto Pre Cost NextHop Interface
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
172.16.1.0/24 Static 60 0 0.0.0.0 NULL0
172.16.2.0/24 Static 60 0 0.0.0.0 NULL0
172.16.3.0/24 Static 60 0 0.0.0.0 NULL0
192.168.1.0/24 BGP 130 0 0.0.0.0 NULL0
192.168.2.0/24 BGP 130 0 0.0.0.0 NULL0
192.168.3.0/24 BGP 130 0 0.0.0.0 NULL0
Mas imaginem que a VRF Client_B, por questões de segurança no roteamento, não precissasse ensinar os prefixos 172.16.2.0/24 e 172.16.3.0/24 para a VRF Client_A mas somente o prefixo 172.16.1.0/24…. Nesse caso precisaríamos configurar o roteamento seletivo para que a VRF Client_A aprenda somente os prefixos necessários.
Ja a VRF Client_A exportará todos os prefixos sem filtros para a Client_B
Utilizaremos no exemplo o valor da Extended Community 65000:12 para exportar o prefixo 172.16.1.0/24.
ip ip-prefix Client_B_prefixo index 5 permit 172.16.1.0 24
! Selecionando o prefixo via prefix-list
!
route-policy Client_B_export permit node 10
if-match ip-prefix Client_B_prefixo
apply extcommunity rt 65000:12 additive
#
! Configurando a community estendida via Route-map
!
ip vpn-instance Client_B
export route-policy Client_B_export
quit
! Configurando o export seletivo de prefixo
end
!
#
ip ip-prefix Client_B index 5 permit 172.16.1.0 24
#
route-policy Client_B permit node 10
if-match ip-prefix Client_B
apply extcommunity rt 65000:12 additive
#
ip vpn-instance Client_A
route-distinguisher 65000:1
vpn-target 65000:1 export-extcommunity
vpn-target 65000:1 65000:12 import-extcommunity
#
ip vpn-instance Client_B
route-distinguisher 65000:2
export route-policy Client_B
vpn-target 65000:2 export-extcommunity
vpn-target 65000:2 65000:1 import-extcommunity
#
!
interface Loopback1
ip address 1.1.1.1 255.255.255.255
!
bgp 65000
undo synchronization
#
ipv4-family vpn-instance Client_A
network 192.168.1.0
network 192.168.2.0
network 192.168.3.0
#
ipv4-family vpn-instance Client_B
network 172.16.1.0 255.255.255.0
network 172.16.2.0 255.255.255.0
network 172.16.3.0 255.255.255.0
#
#
ip route-static vpn-instance Client_A 192.168.1.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_A 192.168.2.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_A 192.168.3.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_B 172.16.1.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_B 172.16.2.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_B 172.16.3.0 255.255.255.0 NULL0
#
#
[R1]disp ip routing-table vpn-instance Client_A
Routing Tables: Client_A
Destinations : 6 Routes : 6
Destination/Mask Proto Pre Cost NextHop Interface
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
172.16.1.0/24 BGP 130 0 0.0.0.0 NULL0
192.168.1.0/24 Static 60 0 0.0.0.0 NULL0
192.168.2.0/24 Static 60 0 0.0.0.0 NULL0
192.168.3.0/24 Static 60 0 0.0.0.0 NULL0
[R1]display ip routing-table vpn-instance Client_B
Routing Tables: Client_B
Destinations : 8 Routes : 8
Destination/Mask Proto Pre Cost NextHop Interface
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
172.16.1.0/24 Static 60 0 0.0.0.0 NULL0
172.16.2.0/24 Static 60 0 0.0.0.0 NULL0
172.16.3.0/24 Static 60 0 0.0.0.0 NULL0
192.168.1.0/24 BGP 130 0 0.0.0.0 NULL0
192.168.2.0/24 BGP 130 0 0.0.0.0 NULL0
192.168.3.0/24 BGP 130 0 0.0.0.0 NULL0
Obs: O mesmo controle pode ser feito para os prefixos de entrada, utilizando o “import map”
Dúvidas , deixe um comentário
A agregação de diversas interfaces Ethernet (portas físicas) para a utilização de uma única porta lógica com o intuito de prover redundância e aumento de banda é uma atividade muito comum em redes de médio e grande porte . No vídeo abaixo, fazemos uma breve descrição sobre a configuração para Link-Aggregation.
A feature DHCP Relay permite ao Switch L3 ou Roteador encaminhar as mensagens DHCP em broadcast em unicast para determinado servidor, possibilitando assim utilização de um único servidor DHCP para toda a LAN.
Devido ao fato das solicitações de endereço IP ao servidor DHCP ocorrerem em broadcast, o Switch L3/Roteador configurado com a feature DHCP Relay encaminhará as mensagens ao Servidor DHCP em Unicast ( que está em uma VLAN diferente do host) .
O servidor DHCP entregará ao cliente o escopo correto baseado na interface IP de origem (alterada e inserida no cabeçalho DHCP).
Para o administrador do servidor DHCP bastará apenas criar os escopos no servidor.
Configurando o DHCP Relay
<SwitchA>system-view
[SwitchA] dhcp enable
! Ativando o DHCP
[SwitchA] dhcp relay server-group 1 ip 10.1.1.1
! Adicionando o servidor DHCP 10.1.1.1 dentro do grupo 1.
[SwitchA] interface vlan-interface 2
[SwitchA-Vlan-interface2] ip address 10.1.1.254 255.255.255.0
[SwitchA-Vlan-interface2] quit
[SwitchA] interface vlan-interface 40
[SwitchA-Vlan-interface40] ip address 10.2.2.254 255.255.255.0
[SwitchA-Vlan-interface40] dhcp select relay
!Ativando o DHCP relay agent na VLAN-interface 40
[SwitchA-Vlan-interface40] dhcp relay server-select 1
! Correlacionando a VLAN-interface 40 para o grupo DHCP 1
Obs: as configurações de DHCP Relay podem variar dependendo do modelo do Switch. A configuração acima foi executada em um Switch HP modelo 4800.
COMUTADORES 