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

[karmeng]

Hi Ron,

Following responses to your questions based on my research.

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

Port that responds doesn't mean the port is open. There are couple of scanning involved (Port scanner - Wikipedia ) that allow the sensor detect which port is respond but not open.

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

Success telnet means the port is responding and open.

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

I suspect the "Port Probe" for wmi is not active causing the issue. Make sure the "wmi" (screenshot attached: bottom in the list) is active.

Regards,

Kar Meng

[karmeng]

Hi Ron,

Just want to touch base on this thread whether my reply helps to answer your questions.

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

Thank you.

Regards,

Kar Meng

[doug_schulze]

Ron,

To add to Kar's excellent response Ive always found it easy to think of active and alive as this...

If I see one of our classification ports in a state of OPEN then we consider that IP to be Active, we can actively attempt to continue the conversation.. These ports are outlined by the triggers probe value.. its how we move on from a port being checked..

Now if we find these or ANY other ports checked and they gave us a response 'other' than open then we can consider them 'alive', there is something there but we cant talk to it.   Friends here will hear a familiar line here.. think of walking upto a house and checking to see if a door with the label 'port 22' is open.   If it opens, great, Im 'Actively' going to try and discover it.   If I turn that door handle and a grumpy old man yells from behind ..."get off my lawn!" , well we are being 'refused' in the response so someone is there, its 'Alive', but we aren't invited back   ...

We have the 'include Alive' check box because years ago we had (and still have ) friends at a major healthcare business that had to deal with a lot of vendor equipment, they didn't want to deal with the errors of trying to talk to equipment that didn't want to talk to them. Big MRI machines, test tube spinners that kinda thing.   So by having this opt-out of devices that were responsive but out of their control , allowed them to better refine their troubleshooting efforts to devices they actually cared about..

And lastly what if no port responds at all? Well then you see nothing.   We know when something is open, we know when it tells us to go away, but if that door just doesnt exist in the first place?   Well, we got nothing to say about its status. the line will be empty. So if you scan an IP and checking our classification port of 135 as you ask and there is NO response well there was nothing there. You would check your parameters in the payload to double check that you are trying that port, but if an IP says nothing?   Well look to FW rules to ensure the midserver has full TCP access to the host.

Hope this helps and again, paired with Kar's excellent response you should be right, let us know...

[karmeng]

Hi Dough,

Thanks for the information. I like the "live" examples that you gave. Certainly it helps me to understand the concept better.

Regards,

Kar Meng