Discovery Ports "respond" vs "open"

[Ronald Lucas]

Using Istanbul...

If you search documentation for "Include alive" which is an option when creating a discovery schedule, it states:

"Select this check box to include alive devices, which are devices that have at least one port that responds to the scan, but no open ports."

What is the difference between a "port that responds" vs "open"?

When I troubleshoot discovery, I use telnet from the MID server to test a port on my target IP address.

When using telnet to test ports, if it is successful, is telnet telling me the port is responding, is open, or both?

Sometimes when I troubleshoot a failed Windows server discovery, the shazzam input payload doesn't mention trying port 135.   I see other ports, but not 135.   See below.

<result active="false" alive="true" ip_address="xxx.xxx.xxx.xxx">

    <scanner name="BannerTCP" port="22" portprobe="ssh" protocol="tcp" result="refused" service="ssh"/>

    <scanner name="BannerTCP" port="5480" portprobe="vmapp" protocol="tcp" result="refused" service="vmapp_https"/>

    <scanner name="BannerTCP" port="9443" portprobe="vmapp" protocol="tcp" result="refused" service="vmapp6_https"/>

    <scanner name="GenericTCP" port="5989" portprobe="wbem" protocol="tcp" result="refused" service="wbem_https"/>

    <scanner name="SLP" port="427" portprobe="slp" protocol="udp" result="refused" service="slp"/>

</result>

Why do I sometimes see port 135 not attempted in my shazzam input payload?

Thanks,

Ron

[Ronald Lucas]

Hi.

I appreciate everyone's responses so far, thank you.

I still have an issue though, and that is sometimes the Shazzam input payload doesn't reference port 135.   It doesn't say it was refused, it's just not there.   See below.

<scanner name="BannerTCP" port="22" portprobe="ssh" protocol="tcp" result="refused" service="ssh"/>

<scanner name="BannerTCP" port="5480" portprobe="vmapp" protocol="tcp" result="refused" service="vmapp_https"/>

<scanner name="BannerTCP" port="9443" portprobe="vmapp" protocol="tcp" result="refused" service="vmapp6_https"/>

<scanner name="GenericTCP" port="5989" portprobe="wbem" protocol="tcp" result="refused" service="wbem_https"/>

<scanner name="SLP" port="427" portprobe="slp" protocol="udp" result="refused" service="slp"/>

I can confirm port 135 is open using telnet from the same MID server performing discovery.

Then I stumbled on the Shazzam probe setting GenericTCP_waitForConnectMS.   Looks like the default is 1000 (or 1 second).   When this value is 1000, I almost never get port 135 to show up in the Shazzam input payload.   If I set it to 3000, then sometimes 135 shows up.   If I set it to 5000, I get 135 all the time.

However, leaving this setting at 5000 significantly increases the run time of my discovery schedules.   So leaving this at 5000 seems to solve (or mask) one problem while creating another one.

When I ping the target Windows IP address, I get 1ms response time which indicates the target Windows server is close to the MID server.   So I'm not sure why GenericTCP_waitForConnectMS at the default value of 1000 (or 1 second) isn't adequate.  

Any suggestions on why I need this value so high to get consistent response from some target Windows servers I'm discovering?

Thanks,

Ron

[Ronald Lucas]

I just used PowerShell to test port 135 to the target Windows computer from the MID server using the following commands:

test-netconnection

measure-command

Here are the results using test-netconnection:

PS C:\> test-netconnection -ComputerName xxx.xxx.xxx.xxx -Port 135

ComputerName                     : xxx.xxx.xxx.xxx

RemoteAddress                   : xxx.xxx.xxx.xxx

RemotePort                         : 135

InterfaceAlias                 : Ethernet

SourceAddress                   : xxx.xxx.xxx.xxx

PingSucceeded                   : True

PingReplyDetails (RTT) : 0 ms

TcpTestSucceeded             : True

So this tells me test-netconnection sees port 135 open on the target IP address.

And then I measured the time of test-netconnection using measure-command:

PS C:\> measure-command {test-netconnection -ComputerName xxx.xxx.xxx.xxx -Port 135}

Days                           : 0

Hours                         : 0

Minutes                     : 0

Seconds                     : 0

Milliseconds           : 92

Ticks                         : 927247

TotalDays                 : 1.0732025462963E-06

TotalHours               : 2.57568611111111E-05

TotalMinutes           : 0.00154541166666667

TotalSeconds           : 0.0927247

TotalMilliseconds : 92.7247

And when I run the above command several times, I get results from 90ms to 200ms which are well below the default 1000ms for the setting GenericTCP_waitForConnectMS.

I guess this demonstrates good network connectivity between the MID server and the target Windows computer regarding port 135, but it doesn't help me determine why GenericTCP_waitForConnectMS needs to be above 1000 in order for the Shazzam probe to see port 135 open.

[karmeng]

Hi Ron,

Your testing looks reasonable. I suspect the way how Powershell connect and MID server connect are different might play a role on why it needs to take longer time. (just my wild guess)

From following KB:

ServiceNow KB: Troubleshooting the Classification Phase in Discovery (KB0535236)

There is a portion as below:

@@@

Logical firewall: In WMI communication, traffic only initiates on port 135. When two Windows operating systems communicate with WMI, they actually negotiate unused high ports to finish the conversation. This presents a problem for logical firewalls in Windows systems. Normally, firewalls allow port 135 to be seen as it is with the Discovery port scan probe, but block the high ports that Discovery needs to communicate. To overcome this, use either of the these options:

• Configure firewalls to allow any port to use any protocol from the MID Server's host, using the WMI script that is run locally.
• Lock down WMI to specific ports.

@@@

If you have firewall on target Windows server, can you try disable it and check if that make any different?

Regards,

Kar Meng

[Ronald Lucas]

Hi Kar.

I was aware of the other WMI ports used, but wouldn't that come into play after Shazzam?   In my case, the problem is simply with Shazzam detecting 135 is open.   From my understanding, communication between the MID server and the target device during Shazzam doesn't use WMI.   Is that correct?

Thanks,

Ron

[karmeng]

Hi Ron,

Shazzam probe is basically determine what devices are active by doing a targeted port scanning.

In your case, I suspect the problem is Shazzam proble unable to find the targeted port (ie: 135) and therefore no further WMI communication.

I agree with you that WMI communication come after Shazzam so the Logical firewall part that I pointed out earlier (ServiceNow KB: Troubleshooting the Shazzam phase in Discovery (KB0535234) ) is just to test if that make any different after disable firewall (if you have any).

As per my update earlier,

###

If you test that Shazzam probe by limit to the target Window server only with GenericTCP_waitForConnectMS=1000, does it return no result?

###

In this way, we can isolate if the problem can be reproduce even with run each ip independently.

In general, increase the parameter (GenericTCP_waitForConnectMS) helps to resolve the issue means that MID server did not get response before shazzam moved on. It exceed the default connection timeout (1000ms) and therefore no result.

One thing I can't tell is whether the powershell test-netconnection is a similarity on how Shazzam work to detect the port.

P.S. Based on the impact hit like, helpful or correct

Regards,

Kar Meng