Network Management

A couple weeks ago I upgraded Airwave to version 8.2.10.1. Couple days ago on Sunday March 22nd, Airwave started to nmap scan many devices causing the owners of those devices to panic. So far, Airwave has tried to ftp to UPS management cards, APC PDUs, and scanned for open ports to network switches.

I followed this instruction, but nmap did not stop, probably an outdated document: https://community.arubanetworks.com/t5/Monitoring-Management-Location/How-to-disbale-nmap-scans-done-by-Airwave-on-the-network/ta-p/234009

I also make sure no discovery is running.

TAC case opened, but if anyone has seen this or has any suggestions is appreciated.

Regards,

Can you enable compatibility mode in AMPCLI and check the status, login to AMPCLI and go to option 3 (configurations) >> Option 5 (SSHD) >> Option 2 (Use Compatible Ciphers)

Hi Pavan,

Thanks for the suggestion, but issue remains.  I'll have a session with TAC tomorrow and update the result. 

Regards,

• Can You share me error message your seeing in Aiwave? 

Logs from AirWave (I only masked out the IP addresses) 

Tue Mar 24 13:58:14 2020 System System NMAP Scan of "x.x.x.x" (x.x.x.x/255.255.255.255) using credentials "": started
Tue Mar 24 13:58:14 2020 System System NMAP Scan of "xxxx/255.255.255.255) using credentials "": completed: 1 probes in 74 seconds
Tue Mar 24 13:57:00 2020 System System NMAP Scan of "xxxx/255.255.255.255) using credentials "": started
Tue Mar 24 13:57:00 2020 System System NMAP Scan of "xxxx/255.255.255.255) using credentials "": completed: 1 probes in 34 seconds
Tue Mar 24 13:56:26 2020 System System NMAP Scan of "xxxx/255.255.255.255) using credentials "": started
Tue Mar 24 13:56:26 2020 System System NMAP Scan of "xxxx/255.255.255.255) using credentials "": completed: 1 probes in 76 seconds

.... and a lot more.

This is error from switch.  (others like UPS, it notifies admin that Airwave fail to FTP to the host)

2020 Mar 22 15:13:42 SWITCH1 %DAEMON-2-SYSTEM_MSG: fatal: Unable to negotiate with <AirWave IP add> port 63024: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1 - dcos_sshd[1831]

Airwave should not be NMAP scanning devices. The referred option also should only scan devices detected as rogue in order to get the OS. I'm on the same Airwave version, but don't see such scanning.

With 'Automatically Scan Rogue Devices' set to no, there should not be no scanning at all. If it was set to 'yes' before and you changed it to no, what you might do is to restart Airwave in order to make sure the settings are applied.

Do you see the devices that are scanned listed as rogue?

Did you change settings recently related to you rogue detection?

I checked our ticketing system an found only one case related to this issue and it referred to information in this Airheads thread. I also see that you asked for escalation yesterday and will have a call soon with an escalation engineer. Escalating the TAC case was the good thing to do, and I assume this engineer will be able to find the reason why this scanning happens and how to get around it.

Herman,

Answers to your questions:

Do you see the devices that are scanned listed as rogue? No, I am not sure how AMP pick the hosts to scan. It seems like AMP scans hosts in its own subnet first and move to next subnet.
Did you change settings recently related to you rogue detection? No change in rogue detection. (or any changes to AMP except adding APs)

Update after working with TAC: TAC accessed to AMP root, killed the NMAP process, but NMAP regenerated. Since my Cent-OS is version 6, they wanted me to migrate to 7. After migrating Cent-OS to 7,restored the backup, NMAP returned.

Waiting for TAC to get back with me.

Thanks,

So at least you are now on CentOS7

I do see many rogues, I don't see NMAP scans (but had the setting to scan rogue for OS probe disabled), and I don't see IP addresses for the rogues either.

Do you see in the rogue page IP addresses for the rogues?

I just enabled the OS probe setting in my lab to check if that will trigger NMAP scans. TAC should be able to find out what triggers the scan. Have you tried to correlate the start time of a scan with other events in Airwave?

Because rogue detection is complexity, switches and routers need to be in AMP, specially the core switches and routers, many false rogues are triggered so I do not configure AMP for rogue detection. I have only one rule is “rogue classified by AOS” so the number of rogues are small and manageable.
All of event logs fill with NMAP scanning, nothing correlate with other events which are not many.

Kudos to TAC Aruba Global Escalations engineer.  He is very helpful.  I am sure he will find the root cause. 

I will have a session today soon and update the outcome.  

Thanks,

Checked your case details, if issue still happening after centos7 migration then need to looks at tables if any scan entry still present in tables which causing this issue.

Had a word with my colleague, he will check this details on session.

I am happy report that session today succeeded. Kudos to Prasath from Aruba Global Escalations did the research and found the fix. He found and cleaned up residue from old discovery subnet. We are talking about many years old scanning and discovery subnet and even the original AMP IP address and device configurations many years ago still remain in the system.

Note that these cleanups can only be done by TAC with root elevation.

Thanks Pavan and Herman spent time to check and trying in the lab, researching the problem and advises.

Regards,