The Shazzam probe is used to try to get some initial information about all of the IP's we are trying to scan, so it would be helpful if there were some ways to make this run a little faster. You can save time and effort running the Shazzam probe with the use of Discovery Behaviors.
When creating a new Discovery Schedule, you will have two options for how you want to run the Discovery scan.
Typically, you can just choose a MID Server in the "MID Server" field and this will signify that you want this scan to be run by the MID Server you have selected.
However, a more advanced and effective option is to choose a "Behavior".
A Discovery Behavior is useful not only for being able to choose what MID Server (or MID Servers) you want to use for this schedule, but you can also control what port probes you want to specify for this scan and even when to run them.Some of the scenarios for using Discovery Behaviors are mentioned in our product documentation, such as Load Balancing, running in multiple domains, and getting past ACL's.
However, there are also some simple and practical benefits from using a Behavior for almost any Schedule you want to create.
Reduce Unneeded Port Probes
By default, when running a "Quick discovery" or if you choose the "MID Server" option for your Discovery Schedule, we will use the following port probes for each IP we try to scan.
- http (443)
- slp (427)
- wins (137)
- dns (53)
- ssh (22)
- wbem (5988/5989)
- wmi (135)
- vmapp (5480)
- snmp (161)
While this may be effective, especially if you are unsure of what devices you are scanning initially, once you know what devices are linked to certain IP's, you likely will not need to run all these port probes in subsequent scans of this device.
For example, below is the results of a "Quick discovery" Shazzam probe that I ran on my local Windows VM machine.
As you can see, for this machine I am getting results from 7 of these different port probes, but 5 of them coming back as "refused" or "unresolved".
The only ports that come back with valid results are "wmi" (port 135) and "wins" (port 137), which are used to trigger the "Windows — Classify" probe to identify my device.
In the future, if I wanted to run another scan against this computer (assuming the IP is statically assigned), I would only need to use these wmi and wins port probes.
I wouldn't need to waste any time and effort scanning these other ports (snmp, ssh, etc.). This is where the concept of "Discovery Behaviors" can be very effective.By using a Schedule with a Behavior for the subsequent times I wanted to scan this device, I can choose to only use the wmi and wins port probes.
Now, this will not have much effect only for scanning one device, as the amount of effort and time for each port probe is minimal.
However, if I was scanning a /24 range of these Windows machines (up to 256 devices) or even a /16 range (up to 65536 devices), this could potentially add up to hundreds of thousands of wasted port probe calls and even though most of these calls may only take milliseconds to process, it can certainly add up over time and especially if you decide to scan multiples ranges.
Prevent running Incorrect Classify probes
Sometimes you may have a device, like a Switch or a Router, which may have multiple ports open. For example, if you scan a Router and it comes back and shows that port 22 is open, our default process will be at first to try to run a "Unix — Classify" against this device.
Now, this device is likely not intended for being able to login via SSH, so this Unix - Classify probe will run and fail. Eventually, we should run the "SNMP — Classify" probe, as long as the snmp port is open, however, we just wasted running an additional probe and sensor against this Router that was unnecessary.
By using Discovery Behavior, we could have specified when running a Discovery Schedule against this Router (or perhaps against a set of Routers) that we don't want SSH to be used for this Schedule. This way, we only need to see that SNMP is open and we can prevent wasting the time and effort of running unneeded Unix - Classify probes.
Overall, while using Behaviors may not be practical for every scenario, there are likely some Schedules you can create where this can be useful. The more you can utilize these Behaviors with your Discovery scans, the less time and effort it will take your MID servers to process this Shazzam probe and proceed to the next activities.
4 Comments
