Gerenciamento invasor em uma rede sem fio unificada
Contents
Introduction
Este documento fornece informações sobre detecção e mitigação de invasores em redes sem fio da Cisco.
As redes wireless estendem redes com fio e aumentam a produtividade dos trabalhadores e acessam às informações. Contudo, uma rede wireless não autorizada apresenta uma camada adicional de preocupação de segurança. Além disso, ela é colocada na segurança das portas em redes com fio, tendo as redes wireless como uma extensão simples de redes com fio. Portanto, um funcionário que leve seu próprio ponto de acesso (Cisco ou não Cisco) para uma infraestrutura sem fio ou com fio bem segura e permita que usuários não autorizados acessem essa rede segura, de outra forma, pode facilmente comprometer uma rede segura.
A detecção de invasores permite que o administrador de rede monitore e elimine essa preocupação com a segurança. O Cisco Unified Network Architecture fornece métodos para detecção de invasores que permitem uma solução completa de identificação e contenção de invasores sem a necessidade de redes e ferramentas de sobreposição caras e difíceis de justificar.
Prerequisites
Requirements
A Cisco recomenda que você tenha conhecimento destes tópicos:
- Controladores De Rede Local Sem Fio Da Cisco.
- Cisco Prime Infrastructure.
Componentes Utilizados
As informações neste documento são baseadas nestas versões de software e hardware:
-
Controladores de LAN sem fio Cisco Unified (séries 5520, 8540 e 3504) que executam a versão 8.8.120.0.
-
APs de onda 2 séries 1832, 1852, 2802 e 3802.
- APs de onda 1 séries 3700, 2700 e 1700.
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. All of the devices used in this document started with a cleared (default) configuration. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Visão geral invasora
Qualquer dispositivo que compartilhe seu espectro e não seja gerenciado por você pode ser considerado um invasor. Um invasor torna-se perigoso nestes cenários:
-
Quando configurado para usar o mesmo SSID (Service Set Identifier, Identificador do conjunto de serviços) da sua rede (honeypot).
-
Quando for detectado na rede com fio.
-
Roubos ad-hoc.
-
Configuração por um forasteiro, na maioria das vezes, com intenção mal-intencionada.
A melhor prática é usar a detecção de invasores para minimizar os riscos de segurança, por exemplo, em um ambiente corporativo. No entanto, há alguns cenários em que a detecção de invasores não é necessária, por exemplo, na implantação do Office Extend Access Point (OEAP), em toda a cidade e em ambientes externos. Com o uso de APs de malha externa para detectar invasores forneceriam pouco valor enquanto usariam recursos para analisar. Por fim, é fundamental avaliar (ou evitar totalmente) a contenção automática desonesta, pois há possíveis problemas legais e responsabilidades se restar para operar automaticamente.
Há três fases principais de gerenciamento de dispositivos invasores na solução Cisco Unified Wireless Network (UWN):
-
Detecção - A verificação do Radio Resource Management (RRM) é usada para detectar a presença de dispositivos invasores.
-
Classificação - O Protocolo de Identificação de Localização Invasiva (RLDP - Rogue Location Discovery Protocol), os Detectores de Invasão (somente APs de Onda 1) e o rastreamento de porta do switch são usados para identificar se o dispositivo invasor está conectado à rede com fio. As regras de classificação não conformes também contribuem para a filtragem dos invasores em categorias específicas baseadas nas suas características.
-
Mitigação - O bloqueio de porta do switch, o local invasor e a contenção de invasores são usados para rastrear sua localização física e para anular a ameaça do dispositivo invasor.
Detecção de invasores
Um invasor é essencialmente qualquer dispositivo que compartilha seu espectro, mas não está no seu controle. Isso inclui pontos de acesso não autorizados, roteador sem fio, clientes invasores e redes ad-hoc invasoras. O Cisco UWN usa vários métodos para detectar dispositivos invasores baseados em Wi-Fi, como varreduras fora do canal e recursos do modo de monitor dedicado. O Cisco Spectrum Expert também pode ser usado para identificar dispositivos invasores não baseados no protocolo 802.11, como bridges Bluetooth.
Varredura fora do canal
Essa operação é executada por APs de modo Local e Flex-Connect (no modo conectado) e utiliza uma técnica de divisão de tempo que permite a verificação de canal e serviço de cliente com o uso do mesmo rádio. Com a mudança para o canal desligado por um período de 50 ms a cada 16 segundos, o AP, por padrão, gasta apenas uma pequena porcentagem de seu tempo para não atender clientes. Além disso, observe que há um intervalo de alteração de canal de 10ms que ocorrerá. No intervalo de verificação padrão de 180 segundos, cada canal FCC de 2,4 GHz (1-11) é verificado pelo menos uma vez. Para outros domínios regulatórios, como o ETSI, o AP ficará fora do canal por uma porcentagem de tempo um pouco maior. A lista de canais e o intervalo de verificação podem ser ajustados na configuração do RRM. Isso limita o impacto do desempenho a um máximo de 1,5% e a inteligência é integrada ao algoritmo para suspender a varredura quando quadros de QoS de alta prioridade, como voz, precisam ser entregues.
Este gráfico é uma representação do algoritmo de digitalização fora do canal para um AP em modo local na banda de frequência de 2,4 GHz. Uma operação semelhante é feita em paralelo no rádio de 5 GHz se o AP tiver um presente. Cada quadrado vermelho representa o tempo gasto no canal residencial dos APs, enquanto cada quadrado azul representa o tempo gasto em canais adjacentes para fins de digitalização.
Verificação do modo de monitor
Esta operação é executada por APs de modo de monitor e modo de monitor wIPS adaptativo que utilizam 100% do tempo do rádio para verificar todos os canais em cada banda de frequência respectiva. Isso permite uma maior velocidade de detecção e permite que mais tempo seja gasto em cada canal individual. Os APs de modo de monitor também são muito superiores na detecção de clientes invasores, pois têm uma visão mais abrangente da atividade que ocorre em cada canal.
Este gráfico é uma representação do algoritmo de digitalização fora do canal para um AP de modo de monitor na banda de frequência de 2,4 GHz. Uma operação semelhante é feita em paralelo no rádio de 5 GHz se o AP tiver um presente.
Comparação entre modo local e modo de monitor
Um AP de modo local divide os ciclos entre o serviço de clientes WLAN e a verificação de canais em busca de ameaças. Como resultado, um AP de modo local leva mais tempo para percorrer todos os canais e gasta menos tempo na coleta de dados em qualquer canal específico para que as operações do cliente não sejam interrompidas. Consequentemente, os tempos de detecção de invasores e ataques são mais longos (de 3 a 60 minutos) e uma faixa menor de ataques aéreos pode ser detectada do que com um AP de modo de monitor.
Além disso, a detecção de tráfego em surtos, como clientes invasores, é muito menos determinística porque o AP precisa estar no canal do tráfego ao mesmo tempo em que o tráfego é transmitido ou recebido. Isto torna-se um exercício em probabilidades. Um AP de modo de monitor passa todos os seus ciclos na varredura de canais para procurar ataques de invasão e invasores. Um AP de modo de monitor pode ser usado simultaneamente para wIPS adaptável, serviços de localização (contextuais) e outros serviços de modo de monitor.
Quando os APs do modo de monitor são implantados, os benefícios são menor tempo de detecção. Quando os APs do modo de monitor são configurados adicionalmente com o wIPS adaptável, uma gama mais ampla de ameaças e ataques aéreos pode ser detectada.
| APs de modo local |
APs de modo de monitor |
| Serve clientes com verificação fora do canal com divisão de tempo |
Varredura dedicada |
| Escuta 50 ms em cada canal |
Escuta 1,2 s em cada canal |
| Configurável para digitalização:
|
Verifica todos os canais |
Identificação de invasor
Se a resposta da sonda ou os beacons de um dispositivo invasor forem ouvidos por APs no modo local, de conexão flexível ou de monitor, essas informações serão comunicadas via CAPWAP à controladora Wireless LAN (WLC) para o processo. Para evitar falsos positivos, vários métodos são usados para garantir que outros APs gerenciados baseados na Cisco não sejam identificados como um dispositivo invasor. Esses métodos incluem atualizações de grupos de mobilidade, pacotes de vizinhos de RF e APs amigáveis de lista permitidos via Prime Infrastructure (PI).
Registros invasores
Embora o banco de dados do controlador de dispositivos invasores contenha apenas o conjunto atual de invasores detectados, o PI também inclui um histórico de eventos e registros invasores que não são mais vistos.
Detalhes do invasor
Um AP CAPWAP fica fora do canal por 50 ms para ouvir clientes invasores, monitorar ruído e interferência de canal. Qualquer cliente invasor detectado ou APs são enviados ao controlador, que coleta estas informações:
-
O endereço MAC do AP invasor
-
Nome do invasor detectado pelo AP
-
O endereço MAC do(s) cliente(s) conectado(s) invasor(s)
-
Política de segurança
-
O preâmbulo
-
A razão sinal-ruído (SNR)
-
O indicador de intensidade do sinal do receptor (RSSI)
-
Canal de detecção de invasor
-
Rádio em que o invasor é detectado
-
SSID invasor (se o SSID invasor for transmitido)
-
Endereço IP invasor
-
Primeira e última vez que o invasor é relatado
-
Largura do canal
Para exportar eventos invasores
Para exportar eventos invasores para um Network Management System (NMS) de terceiros para arquivamento, a WLC permite a adição de receptores adicionais de interceptação SNMP. Quando um invasor é detectado ou removido pelo controlador, uma armadilha que contém essas informações é comunicada a todos os receptores de interceptação SNMP. Um problema com a exportação de eventos via SNMP é que se vários controladores detectarem o mesmo invasor, eventos duplicados são vistos pelo NMS como correlação é feita somente no PI.
Tempo limite do registro invasor
Depois que um AP invasor for adicionado aos registros da WLC, ele permanecerá lá até que não seja mais visto. Depois de um tempo limite configurável pelo usuário (padrão de 1200 segundos), um invasor na categoria _não classificada é ultrapassado.
Invasores em outros estados, como _Contained_e _Friendly_persistirão para que a classificação apropriada seja aplicada a eles se eles reaparecerem.
Há um tamanho máximo de banco de dados para registros invasores que é variável em plataformas de controlador:
-
3504 - Detecção e contenção de até 600 APs invasores e 1500 clientes invasores
- 5520 - Detecção e contenção de até 24.000 APs invasores e 3.2000 clientes invasores
- 8540 - Detecção e contenção de até 24.000 APs invasores e 3.2000 clientes invasores
AP de Detector de Invasão
Um AP de detector não autorizado tem como objetivo correlacionar informações não autorizadas ouvidas sobre o ar com informações ARP obtidas da rede com fio. Se um endereço MAC é ouvido no ar como um AP invasor ou cliente e também é ouvido na rede com fio, o invasor é determinado como estando na rede com fio. Se o invasor for detectado na rede com fio, a gravidade do alarme desse AP invasor será aumentada para _crítico_. Deve-se observar que um AP de detector não autorizado não é bem-sucedido na identificação de clientes não autorizados por trás de um dispositivo que usa NAT.
Essa abordagem é usada quando o AP invasor tem alguma forma de autenticação, WEP ou WPA. Quando uma forma de autenticação é configurada em AP invasor, o AP Lightweight não pode se associar porque não sabe o método de autenticação e as credenciais configuradas no AP invasor.
Considerações sobre escalabilidade
Um AP de detector não autorizado pode detectar até 500 invasores e 500 clientes invasores. Se o detector invasor for colocado em um tronco com muitos dispositivos invasores, esses limites podem ser excedidos, o que causa problemas. Para evitar que isso ocorra, mantenha os APs detectores não autorizados na camada de distribuição ou de acesso da sua rede.
RLDP
O objetivo do RLDP é identificar se um AP invasor específico está conectado à infraestrutura com fio. Esse recurso usa essencialmente o AP mais próximo para se conectar ao dispositivo invasor como um cliente sem fio. Após a conexão como um cliente, um pacote é enviado com o endereço de destino da WLC para avaliar se o AP está conectado à rede com fio. Se for detectado que o invasor está na rede com fio, a gravidade do alarme desse AP invasor será elevada para crítico.
O algoritmo de RLDP está listado aqui:
-
Identifique o AP unificado mais próximo do invasor usando os valores de intensidade do sinal.
-
Em seguida, o AP se conecta ao invasor como um cliente WLAN, tenta três associações antes que o tempo limite seja excedido.
-
Se a associação for bem-sucedida, o AP usará DHCP para obter um endereço IP.
-
Se um endereço IP foi obtido, o AP (que atua como um cliente WLAN) envia um pacote UDP para cada um dos endereços IP do controlador.
-
Se o controlador receber até um dos pacotes RLDP do cliente, esse invasor será marcado como on-wire com uma gravidade crítica.
Caveats do RLDP
-
O RLDP só funciona com APs invasores abertos que transmitem seu SSID com autenticação e criptografia desativadas.
-
O RLDP exige que o AP gerenciado que atua como um cliente possa obter um endereço IP via DHCP na rede invasora
-
O RLDP manual pode ser usado para tentar e rastrear o RLDP em um invasor várias vezes.
-
No processo de RLDP, o AP é incapaz de atender clientes. Isso afetará negativamente o desempenho e a conectividade dos APs no modo local.
-
O RLDP não tenta se conectar a um AP invasor que opera em um canal DFS de 5 GHz.
Rastreamento de porta do switch
O rastreamento de porta de switch é uma técnica de atenuação de AP invasora. Embora o rastreamento de porta do switch seja iniciado no PI, ele utiliza as informações de CDP e SNMP para rastrear um invasor até uma porta específica na rede.
Para que o rastreamento de porta do switch seja executado, todos os switches na rede devem ser adicionados ao PI com credenciais SNMP. Embora as credenciais somente leitura funcionem para identificar a porta em que o invasor está, as credenciais de leitura e gravação permitem que o PI também encerre a porta, portanto ela contém a ameaça.
No momento, esse recurso funciona somente com os switches Cisco que executam IOS com CDP ativado, e o CDP também deve ser ativado nos APs gerenciados.
O algoritmo para o rastreamento de porta do switch está listado aqui:
-
O PI encontra o AP mais próximo, que detecta o AP invasor no ar, e recupera seus vizinhos CDP.
-
Em seguida, o PI usa o SNMP para examinar a tabela CAM dentro do switch vizinho; ele procura uma correspondência positiva para identificar o local inválido.
-
Uma correspondência positiva é baseada no endereço MAC invasor exato, +1/-1 o endereço MAC invasor, qualquer endereço MAC de cliente invasor ou uma correspondência de OUI com base nas informações de fornecedor inerentes a um endereço MAC.
-
Se não for encontrada uma correspondência positiva no switch mais próximo, o PI continuará a pesquisa em switches vizinhos a até dois saltos de distância (por padrão).
Classificação invasora
Por padrão, todos os invasores detectados pelo Cisco UWN são considerados não classificados. Como mostrado neste gráfico, os rogues podem ser classificados em vários critérios que incluem RSSI, SSID, tipo de segurança, rede ativa/desligada e número de clientes:
Regras de classificação invasoras
Regras de classificação invasoras, permitem definir um conjunto de condições que marcam um invasor como mal-intencionado ou amigável. Essas regras são configuradas no PI ou no WLC, mas são sempre executadas no controlador quando novos rogues são descobertos.
Leia o documentoRule Based Rogue Classification in Wireless LAN Controllers (WLC) and Prime Infrastructure (PI) para obter mais informações sobre regras invasoras nas WLCs.
Fatos de HA
Se você mover manualmente qualquer dispositivo invasor para o estado contido (qualquer classe) ou amigável, essas informações serão armazenadas na memória flash do Cisco WLC em standby; no entanto, o banco de dados não é atualizado. Quando ocorre o switchover de HA, a lista invasora da memória flash do Cisco WLC em standby anterior é carregada.
Em um cenário de alta disponibilidade, se o nível de segurança de detecção de invasão estiver definido como Alto ou Crítico, o temporizador invasor no controlador de standby será iniciado somente após o tempo de estabilização da taxa de detecção de invasão, que é de 300 segundos. Portanto, as configurações ativas no controlador de standby são refletidas somente após 300 segundos.
Fatos Flex Connect
Um AP FlexConnect (com detecção de invasão ativada) no modo conectado recebe a lista de contenção do controlador. Se o SSID de contenção automática e o adhoc de contenção automática estiverem definidos no controlador, essas configurações serão definidas para todos os APs FlexConnect no modo conectado e o AP o armazenará em sua memória.
Quando o AP FlexConnect se move para um modo autônomo, as próximas tarefas são executadas:
-
A contenção definida pelo controlador continua.
-
Se o AP FlexConnect detectar qualquer AP invasor que tenha o mesmo SSID do infra SSID (SSID configurado no controlador ao qual o AP FlexConnect está conectado), a contenção será iniciada se o SSID contém automaticamente tiver sido ativado do controlador antes de se mover para o modo autônomo.
-
Se o AP FlexConnect detectar qualquer invasor adhoc, a contenção será iniciada se o adhoc de contenção automática tiver sido ativado do controlador quando estiver no modo conectado.
Quando o AP FlexConnect autônomo volta ao modo conectado, as tarefas a seguir são executadas:
-
Toda a contenção é limpa.
-
A contenção iniciada pelo controlador assumirá o controle.
Mitigação invasora
Contenção de Rogue
Contenção é um método que usa pacotes over-the-air para interromper temporariamente o serviço em um dispositivo invasor até que ele possa ser fisicamente removido. A contenção funciona com a falsificação de pacotes de não autenticação com o endereço de origem falsificado do AP invasor para que todos os clientes associados sejam desligados.
Detalhes do Rogue Containment
Uma contenção iniciada em um AP invasor sem clientes usará somente quadros de não autenticação enviados ao endereço de broadcast:
Uma contenção iniciada em um AP invasor com cliente(s) usará quadros de não autenticação enviados ao endereço de broadcast e ao endereço do(s) cliente(s):
Os pacotes de contenção são enviados no nível de potência do AP gerenciado e na menor taxa de dados habilitada.
A contenção envia um mínimo de 2 pacotes a cada 100ms:
-
Um dispositivo invasor individual pode ser contido por 1 a 4 APs gerenciados que trabalham em conjunto para atenuar a ameaça temporariamente.
-
A contenção pode ser realizada pelo uso de APs de modo local, modo de monitor e modo de conexão flexível (conectado). Para o modo local de APs de conexão flexível, um máximo de três dispositivos invasores por rádio podem ser contidos. Para APs de modo de monitor, um máximo de seis dispositivos invasores por rádio podem ser contidos.
Contenção automática
Além do início manual da contenção em um dispositivo invasor via PI ou GUI da WLC, também há a capacidade de iniciar automaticamente a contenção em determinados cenários. Essa configuração é encontrada na seção Generalin the Rogue Policy do PI ou da interface do controlador. Cada um desses recursos é desabilitado por padrão e só deve ser habilitado para anular as ameaças que podem causar mais danos.
-
Rogue on Wire - Se um dispositivo invasor for identificado para ser conectado à rede com fio, ele será automaticamente colocado sob contenção.
-
Uso de nosso SSID - Se um dispositivo invasor usa um SSID que é igual ao configurado no controlador, ele é automaticamente contido. Este recurso tem como objetivo abordar um ataque de doação antes que cause danos.
-
Cliente válido no AP inválido - Se um cliente listado no servidor Radius/AAA for encontrado associado a um dispositivo invasor, a contenção será iniciada somente contra esse cliente, ela impedirá a associação a qualquer AP não gerenciado.
-
AdHoc Rogue AP - Se uma rede ad-hoc for descoberta, ela será automaticamente contida.
Caveats de Contenção Rogue
-
Como a contenção usa uma parte do tempo de rádio do AP gerenciado para enviar os quadros de desautenticação, o desempenho para os clientes de dados e voz é afetado negativamente por até 20%. Para os clientes de dados, o impacto é a redução do throughput. Para clientes de voz, a contenção pode causar interrupções em conversas e qualidade de voz reduzida.
-
A contenção pode ter implicações legais quando lançada contra redes vizinhas. Certifique-se de que o dispositivo invasor esteja dentro da sua rede e apresente um risco à segurança antes de iniciar a contenção.
Porta do switch fechada
Quando uma porta do switch é rastreada pelo uso de SPT, há uma opção para desativar essa porta no PI. O administrador precisa fazer este exercício manualmente. Uma opção está disponível para ativar a porta do switch através do PI se o invasor for fisicamente removido da rede.
Configurar
Configurar a detecção de invasores
Por padrão, a detecção de invasores é habilitada no controlador.
Para configurar várias opções, navegue paraSegurança > Políticas de proteção sem fio > Políticas de invasão > Geral. Como exemplo:
Etapa 1. Altere o tempo limite para APs não autorizados.
Etapa 2. Habilite a detecção de redes invasoras ad-hoc.
Na CLI:
(Cisco Controller) >config rogue ap timeout ? <seconds> The number of seconds<240 - 3600> before rogue entries are flushed (Cisco Controller) >config rogue adhoc enable/disable
Configurar a varredura de canal para detecção de invasão
Para um AP de modo local/Flex-Connect/Monitor, há uma opção na configuração do RRM que permite ao usuário escolher quais canais são verificados para invasões. Depende da configuração, o AP verifica todos os canais de canal/país/canal DCA para invasões.
Para configurar isso a partir da GUI, navegue paraWireless > 802.11a/802.11b > RRM > General, conforme mostrado na imagem.
Na CLI:
(Cisco Controller) >config advanced 802.11a monitor channel-list ? all Monitor all channels country Monitor channels used in configured country code dca Monitor channels used by automatic channel assignment
Configurar classificação invasora
Classificar manualmente um AP invasor
Para classificar um AP invasor como amigável, mal-intencionado ou não classificado, navegue para Monitor > Rogue > Unclassify APs e clique no nome específico do AP invasor. Escolha a opção na lista suspensa, conforme mostrado na imagem.
Da CLI:
(Cisco Controller) >config rogue ap ? classify Configures rogue access points classification. friendly Configures friendly AP devices. rldp Configures Rogue Location Discovery Protocol. ssid Configures policy for rogue APs advertsing our SSID. timeout Configures the expiration time for rogue entries, in seconds. valid-client Configures policy for valid clients using rogue APs.
Para remover manualmente uma entrada invasora da lista invasora, navegue para Monitor > Rogue > Unclassification APs e clique emRemover, como mostrado na imagem.
Para configurar um AP invasor como um AP amigável, navegue paraSecurity > Wireless Protection Policies > Rogue Policies > Friendly Roguese adicione o endereço MAC invasor.
As entradas invasoras amigáveis adicionadas podem ser verificadas em Monitor > Rogues > Friendly Roguepage, como mostrado na imagem.
Configurar um AP de Detector de Invasão
Para configurar o AP como um detector invasor através da GUI, navegue paraWireless > Todos os APs. Escolha o nome do AP e altere o modo AP como mostrado na imagem.
Da CLI:
(Cisco Controller) >config ap mode rogue AP_Managed Changing the AP's mode will cause the AP to reboot. Are you sure you want to continue? (y/n) y
Configurar a porta de switch para um AP de detecção de invasão
interface GigabitEthernet1/0/5 description Rogue Detector switchport trunk native vlan 100 switchport mode trunk
Configurar RLDP
Para configurar o RLDP na GUI do controlador, navegue paraSegurança > Políticas de proteção sem fio > Políticas invasoras > Geral.
APs do modo de monitor - Permite que somente APs no modo de monitor participem no RLDP.
Todos os APs - APs de modo Local/Flex Connect/Monitor participam do processo RLDP.
Desativado - O RLDP não é disparado automaticamente. No entanto, o usuário pode disparar o RLDP manualmente para um endereço MAC específico através da CLI.
Da CLI:
(Cisco Controller) >config rogue ap rldp enable ?
alarm-only Enables RLDP and alarm if rogue is detected
auto-contain Enables RLDP, alarm and auto-contain if rogue is detected.
(Cisco Controller) >config rogue ap rldp enable alarm-only ?
monitor-ap-only Perform RLDP only on monitor AP
O agendamento RLDP e o gatilho manual são configuráveis somente por meio do prompt de comando. Para iniciar o RLDP manualmente:
(Cisco Controller) >config rogue ap rldp initiate ?
<MAC addr> Enter the MAC address of the rogue AP (e.g. 01:01:01:01:01:01).
Para programação de RLDP:
(Cisco Controller) >config rogue ap rldp schedule ? add Enter the days when RLDP scheduling to be done. delete Enter the days when RLDP scheduling needs to be deleted. enable Configure to enable RLDP scheduling. disable Configure to disable RLDP scheduling. (Cisco Controller) >config rogue ap rldp schedule add ? fri Configure Friday for RLDP scheduling. sat Configure Saturday for RLDP scheduling. sun Configure Sunday for RLDP scheduling. mon Configure Monday for RLDP scheduling. tue Configure Tuesday for RLDP scheduling. wed Configure Wednesday for RLDP scheduling. thu Configure Thursday for RLDP scheduling.
As novas tentativas de RLDP podem ser configuradas com o comando:
(Cisco Controller) >config rogue ap rldp retries ? <count> Enter the no.of times(1 - 5) RLDP to be tried per Rogue AP.
Configurar a mitigação de invasores
Configurar a contenção manual
Para conter um AP invasor manualmente, navegue paraMonitor > Rogues > Unclassification, como mostrado na imagem.
Da CLI:
(Cisco Controller) >config rogue client ?
aaa Configures to validate if a rogue client is a valid client using AAA/local database.
alert Configure the rogue client to the alarm state.
contain Start containing a rogue client.
delete Delete rogue Client
mse Configures to validate if a rogue client is a valid client using MSE.
(Cisco Controller) >config rogue client contain 11:22:33:44:55:66 ?
<num of APs> Enter the maximum number of Cisco APs to actively contain the rogue client [1-4].
Contenção automática
Para configurar a contenção automática, vá paraSegurança > Políticas de proteção sem fio > Políticas invasoras > Geral e habilite todas as opções aplicáveis para a sua rede.
Se você deseja que o Cisco WLC contenha automaticamente determinados dispositivos invasores, marque as caixas de seleção abaixo. Caso contrário, deixe as caixas de seleção desmarcadas, que é o valor padrão.
Estes são os parâmetros de contenção automática:
| Parâmetro |
Descrição |
|---|---|
| Nível de Contenção Automática |
Lista suspensa na qual você pode escolher o nível de contenção automática invasor de 1 a 4. Você pode escolher até quatro APs para contenção automática quando um invasor é movido para um estado contido por meio de qualquer uma das políticas de contenção automática. Você também pode escolher Automático para a seleção automática do número de APs usados para contenção automática. O Cisco WLC escolhe o número necessário de APs com base no RSSI para uma contenção efetiva. O valor de RSSI associado a cada nível de contenção é o seguinte:
|
| Contenção automática somente para APs de modo de monitor |
Marque a caixa de seleção que você pode selecionar para ativar os APs do modo de monitor para contenção automática. O padrão é o estado desativado. |
| Contenção automática no FlexConnect independente |
Marque a caixa de seleção que você pode selecionar para ativar a contenção automática em APs FlexConnect no modo autônomo. O padrão é o estado desativado. Quando os APs FlexConnect estão no modo autônomo, você pode habilitar somente as políticas de contenção automática de APs invasores AdHoc ou SSID. A contenção pára depois que o AP autônomo se conecta de volta ao Cisco WLC. |
| Rogue no cabo |
Marque a caixa de seleção que você habilita para conter automaticamente os invasores detectados na rede com fio. O padrão é o estado desativado. |
| Usando nosso SSID |
Marque a caixa de seleção que você habilita para conter automaticamente os invasores que anunciam o SSID da sua rede. Se você deixar esse parâmetro desmarcado, o Cisco WLC gerará um alarme apenas quando um invasor for detectado. O padrão é o estado desativado. |
| Cliente válido no AP inválido |
Marque a caixa de seleção que você habilita para conter automaticamente um ponto de acesso invasor ao qual os clientes confiáveis estão associados. Se você deixar esse parâmetro desmarcado, o Cisco WLC gerará um alarme apenas quando um invasor for detectado. O padrão é o estado desativado. |
| AP invasor AdHoc |
Marque a caixa de seleção que você habilita para conter automaticamente redes ad-hoc detectadas pelo Cisco WLC. Se você deixar esse parâmetro desmarcado, o Cisco WLC somente gerará um alarme quando tal rede for detectada. O padrão é o estado desativado. |
Clique em Apply para enviar dados ao Cisco WLC, mas os dados não são preservados durante um ciclo de alimentação; esses parâmetros são armazenados temporariamente na RAM volátil.
Da CLI:
(Cisco Controller) >config rogue adhoc ?
alert Stop Auto-Containment, generate a trap upon detection of the
adhoc rogue.
auto-contain Automatically containing adhoc rogue.
contain Start containing adhoc rogue.
disable Disable detection and reporting of Ad-Hoc rogues.
enable Enable detection and reporting of Ad-Hoc rogues.
external Acknowledge presence of a adhoc rogue.
(Cisco Controller) >config rogue adhoc auto-contain ?
(Cisco Controller) >config rogue adhoc auto-contain
Warning! Using this feature may have legal consequences
Do you want to continue(y/n) :y
Com a infraestrutura Prime
O Cisco Prime Infrastructure pode ser usado para configurar e monitorar um ou mais controladores e APs associados. O Cisco PI tem ferramentas para facilitar o monitoramento e o controle de sistemas grandes. Quando você usa o Cisco PI em sua solução sem fio da Cisco, os controladores determinam periodicamente o cliente, trapaceiro ponto de acesso, trapaceiro cliente do ponto de acesso, localização da etiqueta RFID (radio frequency ID, ID de radiofrequência) e armazenamento dos locais no banco de dados Cisco PI.
O Cisco Prime Infrastructure suporta classificação baseada em regras e usa as regras de classificação configuradas no controlador. O controlador envia armadilhas para o Cisco Prime Infrastructure após estes eventos:
-
Se um ponto de acesso desconhecido se mover para o estado Amigo pela primeira vez, o controlador enviará uma armadilha para a infraestrutura Cisco Prime somente se o terogustez estiver alerta. Ele não envia uma armadilha se o terogustro for Interno ou Externo.
-
Se a entrada de arogueentry for removida após o tempo limite expirar, o controlador enviará uma interceptação para pontos de acesso Cisco Prime Infrastructurefrogueque classificados como mal-intencionados (Alerta, Ameaça) ou não classificados (Alerta). O controlador não remove entradas oguecom os eroguestados: Contida, Contida Pendente, Interna e Externa.
Verificar
Para localizar detalhes de invasão em um controlador na interface gráfica, navegue para Monitor > Rogues, como mostrado na imagem.
Nesta página, estão disponíveis classificações diferentes para invasores:
-
APs amigáveis - APs marcados como amigáveis pelo administrador.
-
APs mal-intencionados - APs que são identificados como mal-intencionados por meio de RLDP ou AP de detector de invasor.
- APs personalizados - APs que são classificados como Personalizados por Regras invasoras.
-
APs não classificados - Por padrão, APs não autorizados serão mostrados como lista não classificada no controlador.
-
Clientes invasores - Clientes conectados a APs invasores.
-
Rogues Ad-hoc - Clientes invasores Ad-hoc.
-
AP invasor ignora a lista - conforme listado por PI.
Clique em uma entrada invasora específica para obter os detalhes do invasor. Aqui está um exemplo de um Rogue detectado em uma rede com fio:
Da CLI:
(Cisco Controller) >show rogue ap summary
Rogue Detection Security Level................... custom
Rogue Pending Time............................... 180 secs
Rogue on wire Auto-Contain....................... Disabled
Rogue using our SSID Auto-Contain................ Disabled
Valid client on rogue AP Auto-Contain............ Disabled
Rogue AP timeout................................. 1200
Rogue Detection Report Interval.................. 10
Rogue Detection Min Rssi......................... -90
Rogue Detection Transient Interval............... 0
Rogue Detection Client Num Threshold............. 0
Validate rogue AP against AAA.................... Enabled
Rogue AP AAA validation interval................. 0 secs
Total Rogues(AP+Ad-hoc) supported................ 600
Total Rogues classified.......................... 12
MAC Address Class State #Det #Rogue #Highest RSSI #RSSI #Channel #Second Highest #RSSI #Channel
Aps Clients det-Ap RSSI Det-Ap
----------------- ------------ -------------------- ---- ------- ----------------- ------ --------------- ----------------- ------ ---------------
00:a3:8e:db:01:a0 Unclassified Alert 1 0 00:27:e3:36:4d:a0 -16 13
00:a3:8e:db:01:a1 Unclassified Alert 1 0 00:27:e3:36:4d:a0 -16 13
00:a3:8e:db:01:a2 Unclassified Alert 1 0 00:27:e3:36:4d:a0 -16 13
00:a3:8e:db:01:b0 Malicious Threat 2 1 00:27:e3:36:4d:a0 -27 40 00:27:e3:36:4d:a0 -37 40
00:a3:8e:db:01:b1 Unclassified Alert 2 0 00:27:e3:36:4d:a0 -28 40 00:27:e3:36:4d:a0 -36 40
00:a3:8e:db:01:b2 Unclassified Alert 2 0 00:27:e3:36:4d:a0 -28 40 00:27:e3:36:4d:a0 -37 40
50:2f:a8:a2:0a:60 Malicious Threat 1 2 00:27:e3:36:4d:a0 -66 1
50:2f:a8:a2:0d:40 Unclassified Alert 1 0 00:27:e3:36:4d:a0 -65 11
9c:97:26:61:d2:79 Unclassified Alert 1 0 00:27:e3:36:4d:a0 -89 6
ac:22:05:ea:21:26 Unclassified Alert 1 0 00:27:e3:36:4d:a0 -89 (1,5)
c4:e9:84:c1:c8:90 Unclassified Alert 1 0 00:27:e3:36:4d:a0 -89 (6,2)
d4:28:d5:da:e0:d4 Unclassified Alert 1 0 00:27:e3:36:4d:a0 -85 13
(Cisco Controller) >show rogue ap detailed 50:2f:a8:a2:0a:60
Rogue BSSID...................................... 50:2f:a8:a2:0a:60
Is Rogue on Wired Network........................ Yes
Classification................................... Malicious
Classification change by......................... Auto
Manual Contained................................. No
State............................................ Threat
State change by.................................. Auto
First Time Rogue was Reported.................... Tue Jun 4 13:06:55 2019
Last Time Rogue was Reported..................... Wed Jun 5 08:25:57 2019
Reported By
AP 1
MAC Address.............................. 00:27:e3:36:4d:a0
Name..................................... tiagoAPcb.98E1.3DEC
Radio Type............................... 802.11n2.4G
SSID..................................... buterfly
Channel.................................. 1
RSSI..................................... -64 dBm
SNR...................................... 29 dB
Security Policy.......................... WPA2/FT
ShortPreamble............................ Disabled
Last reported by this AP................. Wed Jun 5 08:25:57 2019
Troubleshoot
Se O Invasor Não For Detectado
Verifique se a detecção de invasores está habilitada no AP. Na GUI:
Na CLI:
(Cisco Controller) >show ap config general tiagoAPcb.98E1.3DEC Cisco AP Identifier.............................. 13 Cisco AP Name.................................... tiagoAPcb.98E1.3DEC [...] Administrative State ............................ ADMIN_ENABLED Operation State ................................. REGISTERED Mirroring Mode .................................. Disabled AP Mode ......................................... Local Public Safety ................................... Disabled AP SubMode ...................................... Not Configured Rogue Detection ................................. Enabled Remote AP Debug ................................. Disabled Logging trap severity level ..................... informational KPI not configured .............................. Logging syslog facility ......................... kern S/W Version .................................... 8.8.120.0 Boot Version ................................... 1.1.2.4 [...] Power Type/Mode.................................. PoE/Full Power Number Of Slots.................................. 3 AP Model......................................... AIR-AP3802I-I-K9 AP Image......................................... AP3G3-K9W8-M IOS Version...................................... 8.8.120.0 Reset Button..................................... Enabled AP Serial Number................................. FGL2114A4SU [...]
A detecção de invasores pode ser habilitada em um AP com este comando:
(Cisco Controller) >config rogue detection enable ? all Applies the configuration to all connected APs. <Cisco AP> Enter the name of the Cisco AP.
Um AP de modo local verifica apenas canais de países/canais de DCA e depende da configuração. Se o invasor estiver em qualquer outro canal, o controlador não poderá identificar o invasor se você não tiver APs de modo de monitor na rede. Execute esse comando para verificar:
(Cisco Controller) >show advanced 802.11a monitor Default 802.11a AP monitoring 802.11a Monitor Mode........................... enable 802.11a Monitor Mode for Mesh AP Backhaul...... disable 802.11a Monitor Channels....................... Country channels 802.11a RRM Neighbor Discover Type............. Transparent 802.11a RRM Neighbor RSSI Normalization........ Enabled 802.11a AP Coverage Interval................... 90 seconds 802.11a AP Load Interval....................... 60 seconds 802.11a AP Monitor Measurement Interval........ 180 seconds 802.11a AP Neighbor Timeout Factor............. 20 802.11a AP Report Measurement Interval......... 180 seconds
-
O AP invasor não pode transmitir o SSID.
-
Certifique-se de que o endereço MAC do AP invasor não seja adicionado na lista invasora amigável ou permitido listado através do PI.
-
Os beacons do AP invasor podem não ser acessíveis ao AP que detectou invasores. Isso pode ser verificado pela captura dos pacotes com um farejador próximo ao invasor do detector de AP.
-
Um AP de modo local pode levar até 9 minutos para detectar um invasor (3 ciclos 180x3).
-
Os APs da Cisco não são capazes de detectar rogues em frequências como o canal de segurança pública (4,9 GHz).
-
Os APs da Cisco não são capazes de detectar invasores que funcionam no FHSS (Frequency Hopping Spread Spectrum).
Debugs úteis
(Cisco Controller) >debug client
(Cisco Controller) >debug dot11 rogue enable (Cisco Controller) >*emWeb: Jun 05 08:39:46.828: Debugging session started on Jun 05 08:39:46.828 for WLC AIR-CT3504-K9 Version :8.8.120.0 SN :FCW2245M09Y Hostname tiagoWLCcb *iappSocketTask: Jun 05 08:39:57.104: 00:27:e3:36:4d:a0 Posting Rogue AP Iapp Report from AP for processing Payload version:c1, slot:0 , Total Entries:5, num entries this packet:5 Entry index :0, pakLen:285 *apfRogueTask_2: Jun 05 08:39:57.104: 00:27:e3:36:4d:a0 fakeAp check: slot=0, entryIndex=0, (Radio_upTime-now)=152838 *apfRogueTask_2: Jun 05 08:39:57.105: 00:27:e3:36:4d:a0 entries 5 slotId 0 bssid b0:72:bf:93:e0:d7 src b0:72:bf:93:e0:d7 channel 1 rssi -59 ssid SMA1930072865 *apfRogueTask_2: Jun 05 08:39:57.105: 00:27:e3:36:4d:a0 entries 5 slotId 0 bssid 50:2f:a8:a2:0a:60 src 50:2f:a8:a2:0a:60 channel 1 rssi -63 ssid buterfly *apfRogueTask_2: Jun 05 08:39:57.105: 00:27:e3:36:4d:a0 entries 5 slotId 0 bssid 00:a3:8e:db:01:a1 src 00:a3:8e:db:01:a1 channel 13 rssi -16 ssid *apfRogueTask_2: Jun 05 08:39:57.105: 00:27:e3:36:4d:a0 entries 5 slotId 0 bssid 00:a3:8e:db:01:b0 src a4:c3:f0:cf:db:18 channel 40 rssi -26 ssid blizzard *apfRogueTask_1: Jun 05 08:39:57.105: 00:a3:8e:db:01:b2 New RSSI report from AP 00:27:e3:36:4d:a0 rssi -28, snr 61 wepMode 81 wpaMode 82, detectinglradtypes :30 *apfRogueTask_2: Jun 05 08:39:57.105: 00:27:e3:36:4d:a0 entries 5 slotId 0 bssid 00:a3:8e:db:01:b2 src 00:a3:8e:db:01:b2 channel 40 rssi -28 ssid *apfRogueTask_3: Jun 05 08:39:57.105: 00:a3:8e:db:01:a1 Found Rogue AP: 00:a3:8e:db:01:a1 on slot 0 *apfRogueTask_1: Jun 05 08:39:57.105: 00:a3:8e:db:01:b2 Rogue SSID timestmap expired. last update at 0 Detecting lrad: 00:27:e3:36:4d:a0 *apfRogueTask_2: Jun 05 08:39:57.105: 00:27:e3:36:4d:a0 fakeAp check: knownApCount=0, totalNumOfRogueEntries=5, #entriesThisPkt=5, #totalEntries=5 *apfRogueTask_3: Jun 05 08:39:57.105: 00:a3:8e:db:01:a1 New RSSI report from AP 00:27:e3:36:4d:a0 rssi -16, snr 76 wepMode 81 wpaMode 82, detectinglradtypes :28 *apfRogueTask_2: Jun 05 08:39:57.105: 00:27:e3:36:4d:a0 fakeAp check: avgNumOfRogues[0]/10=4, rogueAlarmInitiated[0]=0 *apfRogueTask_1: Jun 05 08:39:57.105: 00:a3:8e:db:01:b2 SYNC for Channel (new/old : 40/0) or channel width (new/old :0/0) change detected on Detecting lrad: 00:27:e3:36:4d:a0 *apfRogueTask_3: Jun 05 08:39:57.105: 00:a3:8e:db:01:a1 Rogue SSID timestmap expired. last update at 0 Detecting lrad: 00:27:e3:36:4d:a0 *apfRogueTask_1: Jun 05 08:39:57.105: 00:a3:8e:db:01:b2 rg changed rssi prev -28, new -28 *apfRogueTask_3: Jun 05 08:39:57.105: 00:a3:8e:db:01:a1 SYNC for Channel (new/old : 13/0) or channel width (new/old :0/0) change detected on Detecting lrad: 00:27:e3:36:4d:a0 *apfRogueTask_1: Jun 05 08:39:57.105: 00:a3:8e:db:01:b2 Updated AP report 00:27:e3:36:4d:a0 rssi -28, snr 61 *apfRogueTask_3: Jun 05 08:39:57.105: 00:a3:8e:db:01:a1 Updated AP report 00:27:e3:36:4d:a0 rssi -16, snr 76 *apfRogueTask_1: Jun 05 08:39:57.105: 00:a3:8e:db:01:b2 RadioType: 3 lradInfo->containSlotId = 1 ReceiveSlotId = 0 ReceiveBandId = 1 *apfRogueTask_1: Jun 05 08:39:57.105: 00:a3:8e:db:01:b2 Rogue before Rule Classification : Class unclassified, Change by Default State Alert Change by Default *apfRogueTask_2: Jun 05 08:39:57.105: b0:72:bf:93:e0:d7 Created rogue client table for Rogue AP at 0xfff0617238 *apfRogueTask_1: Jun 05 08:39:57.105: 00:a3:8e:db:01:b2 Rogue is Rule candidate for : Class Change by Default State Change by Default *apfRogueTask_2: Jun 05 08:39:57.105: b0:72:bf:93:e0:d7 Added Rogue AP: b0:72:bf:93:e0:d7 *apfRogueTask_1: Jun 05 08:39:57.105: 00:a3:8e:db:01:b2 Applying Rogue rule to this MAC *apfRogueTask_2: Jun 05 08:39:57.105: b0:72:bf:93:e0:d7 Looking for Rogue b0:72:bf:93:e0:d7 in known AP table *apfRogueTask_2: Jun 05 08:39:57.105: b0:72:bf:93:e0:d7 Rogue AP b0:72:bf:93:e0:d7 is not found either in AP list or neighbor, known or Mobility group AP lists *apfRogueTask_1: Jun 05 08:39:57.105: 00:a3:8e:db:01:b2 Rogue After Rule Classification : Class unclassified, Change by Default State Alert Change by Default *apfRogueTask_1: Jun 05 08:39:57.105: 00:a3:8e:db:01:b2 Manual Contained Flag = 0, trustlevel = 2 *apfRogueTask_2: Jun 05 08:39:57.105: b0:72:bf:93:e0:d7 Scheduled pending Time 184 and expiry time 1200 for rogue AP b0:72:bf:93:e0:d7 *apfRogueTask_1: Jun 05 08:39:57.105: 00:a3:8e:db:01:b2 ssidLen = 0 min = 0 00:a3:8e:db:01:b2 *apfRogueTask_2: Jun 05 08:39:57.105: b0:72:bf:93:e0:d7 Change state from 0 to 1 for rogue AP b0:72:bf:93:e0:d7 *apfRogueTask_1: Jun 05 08:39:57.105: 00:a3:8e:db:01:b2 This rogue is not using my ssid. Rogue ssid= *apfRogueTask_2: Jun 05 08:39:57.105: b0:72:bf:93:e0:d7 rg change state Rogue AP: b0:72:bf:93:e0:d7 *apfRogueTask_1: Jun 05 08:39:57.105: 00:a3:8e:db:01:b2 Rogue AP: 00:a3:8e:db:01:b2 autocontain = 2 Mode = 2 *apfRogueTask_3: Jun 05 08:39:57.105: 00:a3:8e:db:01:a1 Rogue detected by AP: 00:27:e3:36:4d:a0 *apfRogueTask_1: Jun 05 08:39:57.105: 00:a3:8e:db:01:b2 Checking Impersonation source 00:a3:8e:db:01:b2 detected by 00:27:e3:36:4d:a0, FailCnt 0, mode 2, apAuthEnabled on mac 0, ptype -155740480 mfp_supported 1 *apfRogueTask_3: Jun 05 08:39:57.105: 00:a3:8e:db:01:a1 RadioType: 3 lradInfo->containSlotId = 2 ReceiveSlotId = 0 ReceiveBandId = 0 *apfRogueTask_2: Jun 05 08:39:57.105: b0:72:bf:93:e0:d7 New RSSI report from AP 00:27:e3:36:4d:a0 rssi -59, snr 36 wepMode 81 wpaMode 83, detectinglradtypes :20 *apfRogueTask_3: Jun 05 08:39:57.105: 00:a3:8e:db:01:a1 Rogue is Rule candidate for : Class Change by Default State Change by Default *apfRogueTask_2: Jun 05 08:39:57.105: b0:72:bf:93:e0:d7 Send Rogue Info Notificaiton for AP report 00:27:e3:36:4d:a0 Rogue ssid change from to SMA1930072865 *apfRogueTask_3: Jun 05 08:39:57.105: 00:a3:8e:db:01:a1 Applying Rogue rule to this MAC *apfRogueTask_2: Jun 05 08:39:57.105: b0:72:bf:93:e0:d7 Rogue SSID timestmap set to 1559723997. Detecting lrad: 00:27:e3:36:4d:a0 *apfRogueTask_2: Jun 05 08:39:57.105: b0:72:bf:93:e0:d7 rg send new rssi -59 *apfRogueTask_3: Jun 05 08:39:57.105: 00:a3:8e:db:01:a1 Rogue After Rule Classification : Class unclassified, Change by Default State Alert Change by Default *apfRogueTask_2: Jun 05 08:39:57.105: b0:72:bf:93:e0:d7 Updated AP report 00:27:e3:36:4d:a0 rssi -59, snr 36 *apfRogueTask_3: Jun 05 08:39:57.105: 00:a3:8e:db:01:a1 Manual Contained Flag = 0, trustlevel = 2 *apfRogueTask_2: Jun 05 08:39:57.105: b0:72:bf:93:e0:d7 Rogue detected by AP: 00:27:e3:36:4d:a0 *apfRogueTask_3: Jun 05 08:39:57.105: 00:a3:8e:db:01:a1 ssidLen = 0 min = 0 00:a3:8e:db:01:a1 *apfRogueTask_2: Jun 05 08:39:57.105: b0:72:bf:93:e0:d7 RadioType: 3 lradInfo->containSlotId = 2 ReceiveSlotId = 0 ReceiveBandId = 0 *apfRogueTask_3: Jun 05 08:39:57.105: 00:a3:8e:db:01:a1 This rogue is not using my ssid. Rogue ssid= *apfRogueTask_2: Jun 05 08:39:57.105: b0:72:bf:93:e0:d7 Rogue before Rule Classification : Class unconfigured, Change by Default State Pending Change by Default *apfRogueTask_3: Jun 05 08:39:57.105: 00:a3:8e:db:01:a1 Rogue AP: 00:a3:8e:db:01:a1 autocontain = 2 Mode = 2 *apfRogueTask_2: Jun 05 08:39:57.105: b0:72:bf:93:e0:d7 Rogue state is pending or lrad, cannot apply rogue rule *apfRogueTask_2: Jun 05 08:39:57.105: b0:72:bf:93:e0:d7 Rogue doesnt qualify for rule classification : Class unconfigured, Change by Default State Pending Change by Default *apfRogueTask_3: Jun 05 08:39:57.105: 00:a3:8e:db:01:a1 Checking Impersonation source 00:a3:8e:db:01:a1 detected by 00:27:e3:36:4d:a0, FailCnt 0, mode 2, apAuthEnabled on mac 0, ptype -155740480 mfp_supported 1 *apfRogueTask_2: Jun 05 08:39:57.105: b0:72:bf:93:e0:d7 Manual Contained Flag = 0, trustlevel = 1 *apfRogueTask_3: Jun 05 08:39:57.105: 00:a3:8e:db:01:a1 Known AP 0 mfp global 0 AP Auth Global 0 mfp Impersonation 0 ids flags 6 *apfRogueTask_2: Jun 05 08:39:57.105: b0:72:bf:93:e0:d7 Checking Impersonation source b0:72:bf:93:e0:d7 detected by 00:27:e3:36:4d:a0, FailCnt 0, mode 1, apAuthEnabled on mac 0, ptype 318505456 mfp_supported 1 *apfRogueTask_2: Jun 05 08:39:57.105: b0:72:bf:93:e0:d7 Known AP 0 mfp global 0 AP Auth Global 0 mfp Impersonation 0 ids flags 2 *apfRogueTask_3: Jun 05 08:39:57.105: 00:a3:8e:db:01:b0 Found Rogue AP: 00:a3:8e:db:01:b0 on slot 0 *apfRogueTask_2: Jun 05 08:39:57.105: b0:72:bf:93:e0:d7 rg new Rogue AP: b0:72:bf:93:e0:d7 *apfRogueTask_3: Jun 05 08:39:57.105: 00:a3:8e:db:01:b0 New RSSI report from AP 00:27:e3:36:4d:a0 rssi -26, snr 61 wepMode 81 wpaMode 82, detectinglradtypes :32 *apfRogueTask_3: Jun 05 08:39:57.105: 00:a3:8e:db:01:b0 Rogue SSID timestmap set to 1559723997. Detecting lrad: 00:27:e3:36:4d:a0 *apfRogueTask_2: Jun 05 08:39:57.105: 50:2f:a8:a2:0a:60 New RSSI report from AP 00:27:e3:36:4d:a0 rssi -63, snr 5 wepMode 81 wpaMode 86, detectinglradtypes :20 *apfRogueTask_3: Jun 05 08:39:57.105: 00:a3:8e:db:01:b0 SYNC for Channel (new/old : 40/0) or channel width (new/old :0/0) change detected on Detecting lrad: 00:27:e3:36:4d:a0 *apfRogueTask_2: Jun 05 08:39:57.105: 50:2f:a8:a2:0a:60 Rogue SSID timestmap set to 1559723997. Detecting lrad: 00:27:e3:36:4d:a0 *apfRogueTask_3: Jun 05 08:39:57.105: 00:a3:8e:db:01:b0 rg changed rssi prev -28, new -26 *apfRogueTask_2: Jun 05 08:39:57.105: 50:2f:a8:a2:0a:60 SYNC for Channel (new/old : 1/0) or channel width (new/old :0/0) change detected on Detecting lrad: 00:27:e3:36:4d:a0 *apfRogueTask_3: Jun 05 08:39:57.105: 00:a3:8e:db:01:b0 Updated AP report 00:27:e3:36:4d:a0 rssi -26, snr 61 *apfRogueTask_2: Jun 05 08:39:57.105: 50:2f:a8:a2:0a:60 rg changed rssi prev -65, new -63 *apfRogueTask_3: Jun 05 08:39:57.105: 00:a3:8e:db:01:b0 Rogue detected by AP: 00:27:e3:36:4d:a0 *apfRogueTask_2: Jun 05 08:39:57.105: 50:2f:a8:a2:0a:60 Updated AP report 00:27:e3:36:4d:a0 rssi -63, snr 5 *apfRogueTask_3: Jun 05 08:39:57.105: 00:a3:8e:db:01:b0 RadioType: 3 lradInfo->containSlotId = 1 ReceiveSlotId = 0 ReceiveBandId = 1 *apfRogueTask_2: Jun 05 08:39:57.105: 50:2f:a8:a2:0a:60 Rogue detected by AP: 00:27:e3:36:4d:a0 *apfRogueTask_2: Jun 05 08:39:57.105: 50:2f:a8:a2:0a:60 RadioType: 3 lradInfo->containSlotId = 2 ReceiveSlotId = 0 ReceiveBandId = 0 *apfRogueTask_3: Jun 05 08:39:57.105: 00:a3:8e:db:01:b0 Manual Contained Flag = 0, trustlevel = 7 *apfRogueTask_2: Jun 05 08:39:57.105: 50:2f:a8:a2:0a:60 Rogue before Rule Classification : Class malicious, Change by Auto State Threat Change by Auto *apfRogueTask_3: Jun 05 08:39:57.105: 00:a3:8e:db:01:b0 ssidLen = 8 min = 8 00:a3:8e:db:01:b0 *apfRogueTask_2: Jun 05 08:39:57.105: 50:2f:a8:a2:0a:60 Manual Contained Flag = 0, trustlevel = 7 *apfRogueTask_3: Jun 05 08:39:57.105: 00:a3:8e:db:01:b0 This rogue is not using my ssid. Rogue ssid=blizzard *apfRogueTask_2: Jun 05 08:39:57.105: 50:2f:a8:a2:0a:60 ssidLen = 8 min = 8 50:2f:a8:a2:0a:60 *apfRogueTask_3: Jun 05 08:39:57.105: 00:a3:8e:db:01:b0 Rogue AP: 00:a3:8e:db:01:b0 autocontain = 2 Mode = 7 *apfRogueTask_2: Jun 05 08:39:57.105: 50:2f:a8:a2:0a:60 This rogue is not using my ssid. Rogue ssid=buterfly *apfRogueTask_2: Jun 05 08:39:57.105: 50:2f:a8:a2:0a:60 Rogue AP: 50:2f:a8:a2:0a:60 autocontain = 2 Mode = 7 *apfRogueTask_3: Jun 05 08:39:57.105: 00:a3:8e:db:01:b0 Known AP 0 mfp global 0 AP Auth Global 0 mfp Impersonation 0 ids flags 2 *apfRogueTask_2: Jun 05 08:39:57.105: 50:2f:a8:a2:0a:60 Checking Impersonation source 50:2f:a8:a2:0a:60 detected by 00:27:e3:36:4d:a0, FailCnt 0, mode 7, apAuthEnabled on mac 0, ptype 318505456 mfp_supported 1 *apfRogueTask_2: Jun 05 08:39:57.105: 50:2f:a8:a2:0a:60 Known AP 0 mfp global 0 AP Auth Global 0 mfp Impersonation 0 ids flags 2 *apfRogueTask_3: Jun 05 08:39:57.105: a4:c3:f0:cf:db:18 APF processing Rogue Client: on slot 0 *apfRogueTask_3: Jun 05 08:39:57.105: a4:c3:f0:cf:db:18 Rogue Client IPv6 addr: Not known *apfRogueTask_2: Jun 05 08:39:57.105: b4:82:fe:54:b3:14 APF processing Rogue Client: on slot 0 *apfRogueTask_3: Jun 05 08:39:57.105: 00:a3:8e:db:01:b0 Rogue Client ssid: blizzard *apfRogueTask_2: Jun 05 08:39:57.105: b4:82:fe:54:b3:14 Rogue Client IPv6 addr: Not known *apfRogueTask_2: Jun 05 08:39:57.105: 50:2f:a8:a2:0a:60 Rogue Client ssid: buterfly *apfRogueTask_3: Jun 05 08:39:57.105: a4:c3:f0:cf:db:18 New AP report 00:27:e3:36:4d:a0 rssi -37, snr 50 *apfRogueTask_3: Jun 05 08:39:57.105: a4:c3:f0:cf:db:18 rgc change from -38 RSSI -37 *apfRogueTask_2: Jun 05 08:39:57.105: b4:82:fe:54:b3:14 rgc change from -39 RSSI -39 *apfRogueTask_3: Jun 05 08:39:57.105: a4:c3:f0:cf:db:18 Updated AP report 00:27:e3:36:4d:a0 rssi -37, snr 50 *apfRogueTask_2: Jun 05 08:39:57.105: b4:82:fe:54:b3:14 Updated AP report 00:27:e3:36:4d:a0 rssi -39, snr 43 *apfRogueTask_2: Jun 05 08:39:57.105: b0:72:bf:93:e0:d7 APF processing Rogue Client: on slot 0 *apfRogueTask_2: Jun 05 08:39:57.105: b0:72:bf:93:e0:d7 Rogue Client IPv6 addr: Not known *apfRogueTask_2: Jun 05 08:39:57.105: 50:2f:a8:a2:0a:60 Rogue Client ssid: buterfly *apfRogueTask_2: Jun 05 08:39:57.105: b0:72:bf:93:e0:d7 New AP report 00:27:e3:36:4d:a0 rssi -62, snr 32 *apfRogueTask_2: Jun 05 08:39:57.105: b0:72:bf:93:e0:d7 rgc change from -61 RSSI -62 *apfRogueTask_2: Jun 05 08:39:57.105: b0:72:bf:93:e0:d7 Updated AP report 00:27:e3:36:4d:a0 rssi -62, snr 32 *apfRogueTask_2: Jun 05 08:39:57.105: b0:72:bf:93:e0:d7 Looking for Rogue b0:72:bf:93:e0:d7 in known AP table *apfRogueTask_2: Jun 05 08:39:57.105: b0:72:bf:93:e0:d7 Rogue AP b0:72:bf:93:e0:d7 is not found either in AP list or neighbor, known or Mobility group AP lists *apfRogueTask_2: Jun 05 08:39:57.105: b0:72:bf:93:e0:d7 Change state from 1 to 2 for rogue AP b0:72:bf:93:e0:d7 *apfRogueTask_2: Jun 05 08:39:57.105: b0:72:bf:93:e0:d7 rg change state Rogue AP: b0:72:bf:93:e0:d7 *apfRogueTask_2: Jun 05 08:39:57.106: b0:72:bf:93:e0:d7 rg change state Rogue AP: b0:72:bf:93:e0:d7 *apfRogueTask_2: Jun 05 08:39:57.106: b0:72:bf:93:e0:d7 Deleting Rogue AP: b0:72:bf:93:e0:d7 *apfRogueTask_2: Jun 05 08:39:57.106: b0:72:bf:93:e0:d7 Freed rogue client table for Rogue AP at 0xfff0617238 *apfRogueTask_2: Jun 05 08:39:57.106: b0:72:bf:93:e0:d7 rg delete for Rogue AP: b0:72:bf:93:e0:d7
Logs de interceptação esperados
Depois que um invasor for detectado/removido da lista de invasores:
| 0 | Qua Jun 5 09:01:57 2019 | Cliente invasor: b4:c0:f5:2b:4f:90 é detectado por 1 APs Rogue Client Bssid: a6:b1:e9:f0:e8:41, Estado: Alerta, última detecção de AP:00:27:e3:36:4d:a0 Rogue Client gateway mac 00:00:02:02:02. |
| 1 | Qua Jun 5 09:00:39 2019 | AP invasor: 9c:97:26:61:d2:79 removido do rádio base MAC : 00:27:e3:36:4d:a0 Interface no:0(802.11n(2,4 GHz)) |
| 2 | Qua Jun 5 08:53:39 2019 | AP invasor: 7c:b7:33:c0:51:14 removido do rádio base MAC: 00:27:e3:36:4d:a0 Interface no:0(802.11n(2,4 GHz)) |
| 3 | Qua Jun 5 08:52:27 2019 | Cliente invasor: fc:3f:7c:5f:b1:1b é detectado por 1 APs Rogue Client Bssid: 50:2f:a8:a2:0a:60, Estado: Alerta, última detecção de AP:00:27:e3:36:4d:a0 Rogue Client gateway mac 00:26:44:73:c5:1d. |
| 4 | Qua Jun 5 08:52:17 2019 | AP invasor: d4:28:d5:da:e0:d4 removido do rádio base MAC : 00:27:e3:36:4d:a0 Interface no:0(802.11n(2,4 GHz)) |
Recomendações
-
Configure a análise de canal para todos os canais se suspeitar de possíveis problemas na rede.
-
O número e a localização dos APs detectores não autorizados podem variar de um andar para um por edifício e depende do layout da rede com fio. É aconselhável ter pelo menos um AP detector não autorizado em cada andar de um prédio. Como um AP de detector invasor requer um tronco para todos os domínios de broadcast de rede da camada 2 que devem ser monitorados, a colocação depende do layout lógico da rede.
Se o invasor não for classificado
Verifique se as regras invasoras estão configuradas corretamente.
Debugs úteis
(Cisco Controller) >debug dot11 rogue rule enable
(Cisco Controller) >*emWeb: Jun 05 09:12:27.095:
Debugging session started on Jun 05 09:12:27.095 for WLC AIR-CT3504-K9 Version :8.8.120.0 SN :FCW2245M09Y Hostname tiagoWLCcb
(Cisco Controller) >
*apfRogueTask_1: Jun 05 09:12:57.135: 00:a3:8e:db:01:a0 Rogue Rule Classify Params: rssi=-16, maxRssiLrad = 00:27:e3:36:4d:a0 ,client=0, duration=154623, wep=1, ssid=blizzard slotId = 0 channel = 13 snr = 76 dot11physupport =
*apfRogueTask_3: Jun 05 09:12:57.135: 00:a3:8e:db:01:a1 Rogue Rule Classify Params: rssi=-15, maxRssiLrad = 00:27:e3:36:4d:a0 ,client=0, duration=154683, wep=1, ssid= slotId = 0 channel = 13 snr = 77 dot11physupport = 3
*apfRogueTask_1: Jun 05 09:12:57.135: ac:22:05:ea:21:26 Rogue Rule Classify Params: rssi=-89, maxRssiLrad = 00:27:e3:36:4d:a0 ,client=0, duration=5790, wep=1, ssid=NOWO-A2121 slotId = 0 channel = 1 snr = 4 dot11physupport = 3
*apfRogueTask_1: Jun 05 09:13:27.135: ac:22:05:ea:21:26 Rogue Rule Classify Params: rssi=-89, maxRssiLrad = 00:27:e3:36:4d:a0 ,client=0, duration=5820, wep=1, ssid=NOWO-A2121 slotId = 0 channel = 1 snr = 4 dot11physupport = 3
*apfRogueTask_3: Jun 05 09:13:27.135: 50:2f:a8:a2:0d:40 Rogue Rule Classify Params: rssi=-62, maxRssiLrad = 00:27:e3:36:4d:a0 ,client=0, duration=154353, wep=1, ssid=buterfly slotId = 0 channel = 11 snr = 30 dot11physupport =
*apfRogueTask_3: Jun 05 09:13:27.135: 50:2f:a8:a2:0d:40 Rogue Classification:malicious, RuleName:TestRule, Rogue State:Containment Pending
*apfRogueTask_3: Jun 05 09:13:27.136: 00:a3:8e:db:01:a1 Rogue Rule Classify Params: rssi=-15, maxRssiLrad = 00:27:e3:36:4d:a0 ,client=0, duration=154713, wep=1, ssid= slotId = 0 channel = 13 snr = 77 dot11physupport = 3
*apfRogueTask_1: Jun 05 09:13:57.136: 00:a3:8e:db:01:a0 Rogue Rule Classify Params: rssi=-16, maxRssiLrad = 00:27:e3:36:4d:a0 ,client=0, duration=154683, wep=1, ssid=blizzard slotId = 0 channel = 13 snr = 76 dot11physupport =
*apfRogueTask_3: Jun 05 09:13:57.136: 50:2f:a8:a2:0d:40 Rogue Classification:malicious, RuleName:TestRule, Rogue State:Containment Pending
*apfRogueTask_3: Jun 05 09:13:57.136: 00:a3:8e:db:01:a1 Rogue Rule Classify Params: rssi=-15, maxRssiLrad = 00:27:e3:36:4d:a0 ,client=0, duration=154743, wep=1, ssid= slotId = 0 channel = 13 snr = 77 dot11physupport = 3
Recomendações
Se você tiver entradas invasoras conhecidas, adicione-as na lista amigável ou habilite a validação com AAA e certifique-se de que as entradas conhecidas do cliente estejam lá no banco de dados de Autenticação, Autorização e Contabilidade (AAA).
RLDP não localiza invasores
- Se o invasor estiver no canal DFS, o RLDP não funcionará.
- O RLDP funciona apenas se a WLAN do invasor estiver aberta e o DHCP estiver disponível.
- Se o AP do modo local servir ao cliente no canal DFS, ele não participará do processo RLDP.
- O RLDP não é suportado nos AP modelos 1800i, 1810 OEAP, 1810W, 1815, 1830, 1850, 2800 e 3800 Series APs.
Debugs úteis
(Cisco Controller) >debug dot11 rldp enable
!--- RLDP not available when AP used to contain only has invalid channel for the AP country code
*apfRLDP: Jun 05 12:24:41.291: 50:2f:a8:a2:0a:61 Received request to detect Rogue
*apfRLDP: Jun 05 12:24:41.291: 50:2f:a8:a2:0a:61 Entering apfFindClosestLrad
*apfRLDP: Jun 05 12:24:41.292: Rogue detected slot :0 Rogue containingSlotId :2
*apfRLDP: Jun 05 12:24:41.292: 50:2f:a8:a2:0a:61 Invalid channel 1 for the country IL for AP 00:27:e3:36:4d:a0
*apfRLDP: Jun 05 12:24:41.292: 50:2f:a8:a2:0a:61 Cannot find any AP to perform RLDP operation
*apfRLDP: Jun 05 12:24:41.292: 50:2f:a8:a2:0a:61 Exiting apfFindClosestLrad
*apfRLDP: Jun 05 12:24:41.292: Waiting for ARLDP request
!--- ROGUE detected on DFS channel
*apfRLDP: Jun 05 12:43:16.659: 50:2f:a8:a2:0d:4e Received request to detect Rogue
*apfRLDP: Jun 05 12:43:16.659: 50:2f:a8:a2:0d:4e Entering apfFindClosestLrad
*apfRLDP: Jun 05 12:43:16.660: Rogue detected slot :1 Rogue containingSlotId :1
*apfRLDP: Jun 05 12:43:16.660: 50:2f:a8:a2:0d:4e Our AP 00:27:e3:36:4d:a0 detected this rogue on a DFS Channel 100
*apfRLDP: Jun 05 12:43:16.660: 50:2f:a8:a2:0d:4e Cannot find any AP to perform RLDP operation
*apfRLDP: Jun 05 12:43:16.660: 50:2f:a8:a2:0d:4e Exiting apfFindClosestLrad
*apfRLDP: Jun 05 12:43:16.660: Waiting for ARLDP request
!--- RLDP is not supported on AP model 1800i, 1810 OEAP, 1810W, 1815, 1830, 1850, 2800, and 3800 Series APs
*apfRLDP: Jun 05 12:52:41.980: 9e:97:26:a2:a1:1a Received request to detect Rogue
*apfRLDP: Jun 05 12:52:41.980: 9e:97:26:a2:a1:1a Entering apfFindClosestLrad
*apfRLDP: Jun 05 12:52:41.980: 9e:97:26:a2:a1:1a Skipping RLDP on AP 94:d4:69:f5:f7:e0 AP Model: AIR-AP1852I-E-K9
*apfRLDP: Jun 05 12:52:41.980: 9e:97:26:a2:a1:1a Cannot find any AP to perform RLDP operation
*apfRLDP: Jun 05 12:52:41.980: 9e:97:26:a2:a1:1a Exiting apfFindClosestLrad
*apfRLDP: Jun 05 12:52:41.980: Waiting for ARLDP request
!--- Association TO ROGUE AP
*apfRLDP: Jun 05 15:02:49.602: 50:2f:a8:a2:0a:61 Received request to detect Rogue *apfRLDP: Jun 05 15:02:49.602: 50:2f:a8:a2:0a:61 Entering apfFindClosestLrad *apfRLDP: Jun 05 15:02:49.602: 50:2f:a8:a2:0a:61 Skipping RLDP on AP 94:d4:69:f5:f7:e0 AP Model: AIR-AP1852I-E-K9 *apfRLDP: Jun 05 15:02:49.602: Rogue detected slot :0 Rogue containingSlotId :0 *apfRLDP: Jun 05 15:02:49.602: 50:2f:a8:a2:0a:61 Monitor Mode AP found b4:de:31:a4:e0:30 with RSSI -61 *apfRLDP: Jun 05 15:02:49.602: 50:2f:a8:a2:0a:61 found closest monitor AP b4:de:31:a4:e0:30 slot = 0, channel = 1 *apfRLDP: Jun 05 15:02:49.602: 50:2f:a8:a2:0a:61 Exiting apfFindClosestLrad *apfRLDP: Jun 05 15:02:49.602: 50:2f:a8:a2:0a:61 Found RAD: 0xffd682b5b8, slotId = 0, Type=1 *apfRLDP: Jun 05 15:02:50.102: 50:2f:a8:a2:0a:61 AP b4:de:31:a4:e0:30 Client b4:de:31:a4:e0:31 Slot = 0 *apfRLDP: Jun 05 15:02:50.102: 50:2f:a8:a2:0a:61 WARNING!!!!! mscb already exists! *apfRLDP: Jun 05 15:02:50.102: b4:de:31:a4:e0:31 In rldpSendAddMobile:724 setting Central switched to TRUE *apfRLDP: Jun 05 15:02:50.302: 50:2f:a8:a2:0a:61 rldp started association, attempt 1 *apfRLDP: Jun 05 15:02:55.346: 50:2f:a8:a2:0a:61 RLDP could not finish the association in time. RLDP State(2) *apfRLDP: Jun 05 15:02:55.346: 50:2f:a8:a2:0a:61 rldp started association, attempt 2 *apfRLDP: Jun 05 15:03:00.390: 50:2f:a8:a2:0a:61 RLDP could not finish the association in time. RLDP State(2) *apfRLDP: Jun 05 15:03:00.390: 50:2f:a8:a2:0a:61 rldp started association, attempt 3 *apfOpenDtlSocket: Jun 05 15:03:00.608: apfRoguePreamble = 0 mobile b4:de:31:a4:e0:31. *apfOpenDtlSocket: Jun 05 15:03:00.808: 50:2f:a8:a2:0a:61 RLDP state RLDP_ASSOC_DONE (3). *apfRLDP: Jun 05 15:03:00.870: 50:2f:a8:a2:0a:61 Successfully associated with rogue: 50:2F:A8:A2:0A:61
!--- Attempt to get ip from ROGUE
*apfRLDP: Jun 05 15:03:00.870: 50:2f:a8:a2:0a:61 Starting dhcp *apfRLDP: Jun 05 15:03:00.870: 50:2f:a8:a2:0a:61 Initializing RLDP DHCP for rogue 50:2f:a8:a2:0a:61 *apfRLDP: Jun 05 15:03:00.870: 50:2f:a8:a2:0a:61 RLDP DHCPSTATE_INIT for rogue 50:2f:a8:a2:0a:61 *apfRLDP: Jun 05 15:03:00.870: b4:de:31:a4:e0:31 BOOTP[rldp] op: REQUEST *apfRLDP: Jun 05 15:03:00.870: b4:de:31:a4:e0:31 htype: Ethernet *apfRLDP: Jun 05 15:03:00.870: b4:de:31:a4:e0:31 hlen: 6 *apfRLDP: Jun 05 15:03:00.870: b4:de:31:a4:e0:31 hops: 1 *apfRLDP: Jun 05 15:03:00.870: b4:de:31:a4:e0:31 xid: 0x3da1f13 *apfRLDP: Jun 05 15:03:00.870: b4:de:31:a4:e0:31 secs: 0 *apfRLDP: Jun 05 15:03:00.870: b4:de:31:a4:e0:31 flags: 0x0 *apfRLDP: Jun 05 15:03:00.870: b4:de:31:a4:e0:31 hw_addr: B4:DE:31:A4:E0:31 *apfRLDP: Jun 05 15:03:00.870: b4:de:31:a4:e0:31 client IP: 0.0.0.0 *apfRLDP: Jun 05 15:03:00.870: b4:de:31:a4:e0:31 my IP: 0.0.0.0 *apfRLDP: Jun 05 15:03:00.870: b4:de:31:a4:e0:31 server IP: 0.0.0.0 *apfRLDP: Jun 05 15:03:00.870: b4:de:31:a4:e0:31 gateway IP: 0.0.0.0 *apfRLDP: Jun 05 15:03:00.870: b4:de:31:a4:e0:31 options: *apfRLDP: Jun 05 15:03:00.870: b4:de:31:a4:e0:31 DHCP message: 1 DISCOVER *apfRLDP: Jun 05 15:03:00.870: DHCP option: 39/57.2: (2) *apfRLDP: Jun 05 15:03:00.870: [0000] 02 40 *apfRLDP: Jun 05 15:03:00.870: b4:de:31:a4:e0:31 host name: RLDP *apfRLDP: Jun 05 15:03:00.870: 50:2f:a8:a2:0a:61 Sending DHCP packet through rogue AP 50:2f:a8:a2:0a:61 *apfRLDP: Jun 05 15:03:00.870: 50:2f:a8:a2:0a:61 RLDP DHCP SELECTING for rogue 50:2f:a8:a2:0a:61 *apfRLDP: Jun 05 15:03:10.877: 50:2f:a8:a2:0a:61 Initializing RLDP DHCP for rogue 50:2f:a8:a2:0a:61 *apfRLDP: Jun 05 15:03:10.877: 50:2f:a8:a2:0a:61 RLDP DHCPSTATE_INIT for rogue 50:2f:a8:a2:0a:61 *apfRLDP: Jun 05 15:03:10.877: b4:de:31:a4:e0:31 BOOTP[rldp] op: REQUEST *apfRLDP: Jun 05 15:03:10.877: b4:de:31:a4:e0:31 htype: Ethernet *apfRLDP: Jun 05 15:03:10.877: b4:de:31:a4:e0:31 hlen: 6 *apfRLDP: Jun 05 15:03:10.877: b4:de:31:a4:e0:31 hops: 1 *apfRLDP: Jun 05 15:03:10.877: b4:de:31:a4:e0:31 xid: 0x3da1f13 *apfRLDP: Jun 05 15:03:10.877: b4:de:31:a4:e0:31 secs: 0 *apfRLDP: Jun 05 15:03:10.877: b4:de:31:a4:e0:31 flags: 0x0 *apfRLDP: Jun 05 15:03:10.877: b4:de:31:a4:e0:31 hw_addr: B4:DE:31:A4:E0:31 *apfRLDP: Jun 05 15:03:10.877: b4:de:31:a4:e0:31 client IP: 0.0.0.0 *apfRLDP: Jun 05 15:03:10.877: b4:de:31:a4:e0:31 my IP: 0.0.0.0 *apfRLDP: Jun 05 15:03:10.878: b4:de:31:a4:e0:31 server IP: 0.0.0.0 *apfRLDP: Jun 05 15:03:10.878: b4:de:31:a4:e0:31 gateway IP: 0.0.0.0 *apfRLDP: Jun 05 15:03:10.878: b4:de:31:a4:e0:31 options: *apfRLDP: Jun 05 15:03:10.878: b4:de:31:a4:e0:31 DHCP message: 1 DISCOVER *apfRLDP: Jun 05 15:03:10.878: DHCP option: 39/57.2: (2) *apfRLDP: Jun 05 15:03:10.878: [0000] 02 40 *apfRLDP: Jun 05 15:03:10.878: b4:de:31:a4:e0:31 host name: RLDP *apfRLDP: Jun 05 15:03:10.878: 50:2f:a8:a2:0a:61 Sending DHCP packet through rogue AP 50:2f:a8:a2:0a:61 *apfRLDP: Jun 05 15:03:10.878: 50:2f:a8:a2:0a:61 RLDP DHCP SELECTING for rogue 50:2f:a8:a2:0a:61 *apfRLDP: Jun 05 15:03:20.885: 50:2f:a8:a2:0a:61 Initializing RLDP DHCP for rogue 50:2f:a8:a2:0a:61 *apfRLDP: Jun 05 15:03:20.885: 50:2f:a8:a2:0a:61 RLDP DHCPSTATE_INIT for rogue 50:2f:a8:a2:0a:61 *apfRLDP: Jun 05 15:03:20.885: b4:de:31:a4:e0:31 BOOTP[rldp] op: REQUEST *apfRLDP: Jun 05 15:03:20.885: b4:de:31:a4:e0:31 htype: Ethernet *apfRLDP: Jun 05 15:03:20.885: b4:de:31:a4:e0:31 hlen: 6 *apfRLDP: Jun 05 15:03:20.885: b4:de:31:a4:e0:31 hops: 1 *apfRLDP: Jun 05 15:03:20.885: b4:de:31:a4:e0:31 xid: 0x3da1f13 *apfRLDP: Jun 05 15:03:20.885: b4:de:31:a4:e0:31 secs: 0 *apfRLDP: Jun 05 15:03:20.885: b4:de:31:a4:e0:31 flags: 0x0 *apfRLDP: Jun 05 15:03:20.885: b4:de:31:a4:e0:31 hw_addr: B4:DE:31:A4:E0:31 *apfRLDP: Jun 05 15:03:20.885: b4:de:31:a4:e0:31 client IP: 0.0.0.0 *apfRLDP: Jun 05 15:03:20.885: b4:de:31:a4:e0:31 my IP: 0.0.0.0 *apfRLDP: Jun 05 15:03:20.885: b4:de:31:a4:e0:31 server IP: 0.0.0.0 *apfRLDP: Jun 05 15:03:20.885: b4:de:31:a4:e0:31 gateway IP: 0.0.0.0 *apfRLDP: Jun 05 15:03:20.885: b4:de:31:a4:e0:31 options: *apfRLDP: Jun 05 15:03:20.885: b4:de:31:a4:e0:31 DHCP message: 1 DISCOVER *apfRLDP: Jun 05 15:03:20.885: DHCP option: 39/57.2: (2) *apfRLDP: Jun 05 15:03:20.885: [0000] 02 40 *apfRLDP: Jun 05 15:03:20.885: b4:de:31:a4:e0:31 host name: RLDP *apfRLDP: Jun 05 15:03:20.885: 50:2f:a8:a2:0a:61 Sending DHCP packet through rogue AP 50:2f:a8:a2:0a:61
!--- RLDP DHCP fails as there is no DHCP server providing IP address
*apfRLDP: Jun 05 15:03:20.885: 50:2f:a8:a2:0a:61 RLDP DHCP FAILED state for rogue 50:2f:a8:a2:0a:61 *apfRLDP: Jun 05 15:03:20.885: 50:2f:a8:a2:0a:61 DHCP failed *apfRLDP: Jun 05 15:03:20.885: Waiting for ARLDP request
Recomendações
-
Inicie o RLDP manualmente em entradas invasoras suspeitas.
-
Programe o RLDP periodicamente.
- O RLDP pode ser implantado em APs de modo local ou de monitor. Para a maioria das implantações escaláveis e para eliminar qualquer impacto no serviço do cliente, o RLDP deve ser implantado em APs de modo de monitor quando possível. No entanto, essa recomendação exige que uma sobreposição de AP no modo de monitor seja implantada com uma proporção típica como um AP no modo de monitor para cada 5 APs no modo local. Os APs no modo de monitor Adaptive wIPS também podem ser aproveitados para esta tarefa.
AP de Detector de Invasão
Uma entrada invasora em um detector invasor pode ser vista com esse comando no console do AP. Para invasores com fio, o sinalizador move-se para definir o status.
tiagoAP.6d09.eff0#show capwap rm rogue detector LWAPP Rogue Detector Mode Current Rogue Table: Rogue hindex = 0: MAC 502f.a8a2.0a61, flag = 0, unusedCount = 1 Rogue hindex = 0: MAC 502f.a8a2.0a60, flag = 0, unusedCount = 1 Rogue hindex = 7: MAC 502f.a8a2.0d41, flag = 0, unusedCount = 1 Rogue hindex = 7: MAC 502f.a8a2.0d40, flag = 0, unusedCount = 1 !--- once rogue is detected on wire, the flag is set to 1
Comandos de depuração úteis em um console AP
Rogue_Detector#debug capwap rm rogue detector *Jun 05 08:37:59.747: ROGUE_DET: Received a rogue table update of length 170 *Jun 05 08:37:59.747: ROGUE_DET: Got wired mac 0023.ebdc.1ac4 *Jun 05 08:37:59.747: ROGUE_DET: Got wired mac 0023.ebdc.1ac5
*Jun 05 08:37:59.747: ROGUE_DET: Got wired mac 0023.ebdc.1aca
*Jun 05 08:37:59.747: ROGUE_DET: Got wired mac 0023.ebdc.1acb
*Jun 05 08:37:59.747: ROGUE_DET: Got wired mac 0023.ebdc.1acc
*Jun 05 08:37:59.747: ROGUE_DET: Got wired mac 0023.ebdc.1acd
*Jun 05 08:37:59.747: ROGUE_DET: Got wired mac 0023.ebdc.1acf
*Jun 05 08:37:59.747: ROGUE_DET: Got wired mac 0024.1431.e9ef
*Jun 05 08:37:59.747: ROGUE_DET: Got wired mac 0024.148a.ca2b
*Jun 05 08:37:59.748: ROGUE_DET: Got wired mac 0024.148a.ca2d
*Jun 05 08:37:59.748: ROGUE_DET: Got wired mac 0024.148a.ca2f
*Jun 05 08:37:59.748: ROGUE_DET: Got wired mac 0024.14e8.3570
*Jun 05 08:37:59.748: ROGUE_DET: Got wired mac 0024.14e8.3574
*Jun 05 08:37:59.748: ROGUE_DET: Got wired mac 0024.14e8.357b
*Jun 05 08:37:59.748: ROGUE_DET: Got wired mac 0024.14e8.357c
*Jun 05 08:37:59.749: ROGUE_DET: Got wired mac 0024.14e8.357d
*Jun 05 08:37:59.749: ROGUE_DET: Got wired mac 0024.14e8.357f
*Jun 05 08:37:59.749: ROGUE_DET: Got wired mac 0024.14e8.3dcd
*Jun 05 08:37:59.749: ROGUE_DET: Got wired mac 0024.14e8.3ff0
*Jun 05 08:37:59.749: ROGUE_DET: Got wired mac 0024.14e8.3ff2
*Jun 05 08:37:59.774: ROGUE_DET: Got wired mac 0040.96b9.4aec
*Jun 05 08:37:59.774: ROGUE_DET: Got wired mac 0040.96b9.4b77
*Jun 05 08:37:59.774: ROGUE_DET: Flushing rogue entry 0040.96b9.4794
*Jun 05 08:37:59.774: ROGUE_DET: Flushing rogue entry 0022.0c97.af80
*Jun 05 08:37:59.775: ROGUE_DET: Flushing rogue entry 0024.9789.5710
*Jun 05 08:38:19.325: ROGUE_DET: Got ARP src 001d.a1cc.0e9e
*Jun 05 08:38:19.325: ROGUE_DET: Got wired mac 001d.a1cc.0e9e
*Jun 05 08:39:19.323: ROGUE_DET: Got ARP src 001d.a1cc.0e9e
*Jun 05 08:39:19.324: ROGUE_DET: Got wired mac 001d.a1cc.0e9e
Contenção de Rogue
Depurações esperadas
*apfRogueTask_3: Jun 06 13:25:11.840: 00:a3:8e:db:01:b0 Updated AP report b4:de:31:a4:e0:30 rssi -33, snr 59
*apfRogueTask_3: Jun 06 13:25:11.840: 00:a3:8e:db:01:b0 Looking for Rogue 00:a3:8e:db:01:b0 in known AP table
*apfRogueTask_3: Jun 06 13:25:11.840: 00:a3:8e:db:01:b0 Rogue AP 00:a3:8e:db:01:b0 is not found either in AP list or neighbor, known or Mobility group AP lists
*apfRogueTask_3: Jun 06 13:25:11.840: 00:a3:8e:db:01:b0 Rogue in same state as before : 6 ContainmentLevel : 4 level 4
*apfRogueTask_3: Jun 06 13:25:11.840: 00:a3:8e:db:01:b0 Rogue detected by AP: b4:de:31:a4:e0:30
*apfRogueTask_3: Jun 06 13:25:11.840: 00:a3:8e:db:01:b0 RadioType: 2 lradInfo->containSlotId = 1 ReceiveSlotId = 1 ReceiveBandId = 1
*apfRogueTask_3: Jun 06 13:25:11.840: 00:a3:8e:db:01:b0 Rogue before Rule Classification : Class malicious, Change by Auto State Contained Change by Auto
*apfRogueTask_3: Jun 06 13:25:11.840: 00:a3:8e:db:01:b0 Rogue doesnt qualify for rule classification : Class malicious, Change by Auto State Contained Change by Auto
*apfRogueTask_3: Jun 06 13:25:11.840: 00:a3:8e:db:01:b0 Manual Contained Flag = 0, trustlevel = 6
*apfRogueTask_3: Jun 06 13:25:11.840: 00:a3:8e:db:01:b0 Rogue AP: 00:a3:8e:db:01:b0 autocontain = 1 Mode = 6
*apfRogueTask_3: Jun 06 13:25:11.840: 00:a3:8e:db:01:b0 apfRogueMode : 6 apfRogueContainmentLevel : 4 lineNumber : 8225 apfRogueManualContained : 0 function : apfUpdateRogueContainmentState
*apfRogueTask_3: Jun 06 13:25:11.840: 00:a3:8e:db:01:b0 Trying Containment on 1 band for rogue
*apfRogueTask_3: Jun 06 13:25:11.840: 00:a3:8e:db:01:b0 Skipping xor radio for 1 band and cont slotid 1
*apfRogueTask_3: Jun 06 13:25:11.840: 00:a3:8e:db:01:b0 Found 0 channels to try containment for rogue
*apfRogueTask_3: Jun 06 13:25:11.840: 00:a3:8e:db:01:b0 Trying Containment on 2 band for rogue
*apfRogueTask_3: Jun 06 13:25:11.840: 00:a3:8e:db:01:b0 Rogue detected on detected slot 0 containing slot 1 for detecting lrad 00:27:e3:36:4d:a0.
*apfRogueTask_3: Jun 06 13:25:11.840: 00:a3:8e:db:01:b0 Found 1 channels to try containment for rogue
*apfRogueTask_3: Jun 06 13:25:11.840: 00:a3:8e:db:01:b0 RSSI SORTED AP MAC 00:27:e3:36:4d:a0 RSSI = -28
*apfRogueTask_3: Jun 06 13:25:11.840: 00:a3:8e:db:01:b0 RSSI SORTED AP MAC 00:27:e3:36:4d:a0 RSSI = -31
*apfRogueTask_3: Jun 06 13:25:11.840: 00:a3:8e:db:01:b0 RSSI SORTED AP MAC b4:de:31:a4:e0:30 RSSI = -33
*apfRogueTask_3: Jun 06 13:25:11.840: 00:a3:8e:db:01:b0 Detecting AP MAC 00:27:e3:36:4d:a0 RSSI = -28 totClientsDetected = 2
*apfRogueTask_3: Jun 06 13:25:11.840: 00:a3:8e:db:01:b0 Detecting AP MAC 00:27:e3:36:4d:a0 RSSI = -31 totClientsDetected = 2
*apfRogueTask_3: Jun 06 13:25:11.840: 00:a3:8e:db:01:b0 Detecting AP MAC b4:de:31:a4:e0:30 RSSI = -33 totClientsDetected = 1
*apfRogueTask_3: Jun 06 13:25:11.840: 00:a3:8e:db:01:b0 Rogue already contained by AP 00:27:e3:36:4d:a0. Containment mode 1
*apfRogueTask_3: Jun 06 13:25:11.840: 00:a3:8e:db:01:b0 Rogue already contained by AP 00:27:e3:36:4d:a0. Containment mode 1
*apfRogueTask_3: Jun 06 13:25:11.840: 00:a3:8e:db:01:b0 Rogue already contained by AP b4:de:31:a4:e0:30. Containment mode 1
*apfRogueTask_3: Jun 06 13:25:11.840: 00:a3:8e:db:01:b0 Containing rogue using 3 container AP(s).Requested containment level : 4
*apfRogueTask_3: Jun 06 13:25:11.840: 00:a3:8e:db:01:b0 Checking Impersonation source 00:a3:8e:db:01:b0 detected by b4:de:31:a4:e0:30, FailCnt 0, mode 6, apAuthEnabled on mac 0, ptype 318505456 mfp_supported 1
*apfRogueTask_3: Jun 06 13:25:11.840: 00:a3:8e:db:01:b0 Known AP 0 mfp global 0 AP Auth Global 0 mfp Impersonation 0 ids flags 3
Recomendações
-
O AP do modo local/Flex Connect pode conter 3 dispositivos de cada vez por rádio, e o AP do modo de monitor pode conter 6 dispositivos por rádio. Como resultado, verifique se o AP ainda não contém o número máximo de dispositivos permitidos. Neste cenário, o cliente está em um estado de contenção pendente.
-
Verifique as regras de contenção automática.
Conclusão
A detecção e contenção de invasores na solução de controlador centralizado da Cisco é o método mais eficaz e menos intrusivo do setor. A flexibilidade fornecida ao administrador de rede permite um ajuste mais personalizado que pode acomodar quaisquer requisitos de rede.
Informações Relacionadas
- Guia de configuração do Cisco Wireless Controller, Versão 8.8 - Gerenciamento invasor
- Práticas recomendadas de configuração do Cisco Wireless LAN Controller (WLC)
- Guia de implantação do WLC 3504 versão 8.5
- Guia de implantação do Cisco 5520 Wireless LAN Controller
- Notas de versão para Cisco Wireless Controllers e Lightweight Access Points, Cisco Wireless versão 8.8.120.0
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)