Highlighted
Absent Member.. Absent Member..
Absent Member..
254 views

Inconsistent port discovery

I'm finding precious little documentation on port discivery.  I don't find I get IpServiceEndpoint CIs created from the scanner-based inventory jobs.  Should I or do they only get created by the script-based inventory jobs?

As for the script-based jobs, I find that in most cases I have processes actively listening to ports on a target server and the job doesn't create IpServiceEndpoint Cis for them.  I mean, it finds some, but not all.  And yes, I have gone into the Management Zone configuration and told it to scan for all the defined ports.

Is there a step I'm missing somewhere?  Are IpServiceEndpoint CIs only created according to some criteria I'm missing?

0 Likes
8 Replies
Highlighted
Micro Focus Expert
Micro Focus Expert

Re: Inconsistent port discovery

Hi There,

globalSettings.xml for default:

    <!--Application signature-->
    <property name="discovereAllListenPorts">false</property>

this could be reason to discover all ports.

Let me know, this helps.

Thanks,

Yilmaz

0 Likes
Highlighted
Absent Member.. Absent Member..
Absent Member..

Re: Inconsistent port discovery

Nope.  I have that property set to true as well.  Anything else I should look for?

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

Re: Inconsistent port discovery

can you specify which job you are running to discover port?

Thanks,

Yilmaz

0 Likes
Highlighted
Absent Member.. Absent Member..
Absent Member..

Re: Inconsistent port discovery

Typically it's the Host Resources and Applications by Shell.

But then, one of my original questions, should the scanner-based inventory jobs not also be discovering ports that have processes listening on them?  I would think that the scanner would likely be more accurate at discovering them.  However, I don't get IpServiceEndpoint CIs created by that job.  Should I be getting them from scanner-based inventory?

0 Likes
Highlighted
Outstanding Contributor.
Outstanding Contributor.

Re: Inconsistent port discovery


@cbowditch wrote:

But then, one of my original questions, should the scanner-based inventory jobs not also be discovering ports that have processes listening on them?  I would think that the scanner would likely be more accurate at discovering them.  However, I don't get IpServiceEndpoint CIs created by that job.  Should I be getting them from scanner-based inventory?


To have scanner based discovery add those CIs first make sure that you are collecting the Running Software and TCP/IP connectivity information. Here are the settings in the scan generator:

You will also want to configure which application signatures are matched. This will vary depending on whether you are using zone based or advanced discovery.

Here is the setting for Advanced discovery:
You want to override the default applications and add to the comma separated list of software signatures you want to match based on the application signature name in the applicationSignature.xml document.

To troubleshoot the port discovery refer to the probe server log called probeMgr-adaptersDebug.log. Look for lines like the following:

Registered connection 'jdbc:postgresql://localhost/dataflowprobe, UserName=mamprobe, PostgreSQL Native Driver' (total 3) on framework Inventory_Discovery_by_Scanner2c4bfdd1c1d02333f9eae0a7332eecde
Known Listening Ports:None
Requested services:*
Build process map by SQL:
            with p2p as ( 
            select SrcAddr, SrcPort, Prot, lpr.listen SrcListen, lpr.hostid srchid, lpr.pid srcpid, lpr.processname srcname,
                   rpr.hostid dsthid, rpr.pid dstpid, DstAddr, DstPort, rpr.listen DstListen, rpr.processname dstname
            from Agg_V5 agg
            join Port_Process lpr on lpr.hostid = agg.hostid
                                and lpr.ipaddress = agg.SrcAddr
                                and lpr.port = agg.SrcPort
                                and lpr.Protocol = agg.Prot
            left join Port_Process rpr on rpr.ipaddress = agg.DstAddr
                                and rpr.port = agg.DstPort
                                and lpr.Protocol = agg.Prot
            where agg.hostid = '2c4bfdd1c1d02333f9eae0a7332eecde' and ('1' or SrcAddr <> DstAddr) and ((rpr.hostid is null) or (lpr.hostid <> rpr.hostid) or (lpr.pid < rpr.pid))
            order by srcpid
     )
            select hostid, pid, name, cmdline, path, params, owner, startuptime
            from processes
            where (hostid, pid) in (
                select distinct srchid hostid, srcpid pid from p2p
                union
                select distinct dsthid hostid, dstpid pid from p2p where dsthid is not null
            )
    
0 processes loaded.

            select SrcAddr, SrcPort, Prot, lpr.listen SrcListen, lpr.hostid srchid, lpr.pid srcpid, lpr.processname srcname,
                   rpr.hostid dsthid, rpr.pid dstpid, DstAddr, DstPort, rpr.listen DstListen, rpr.processname dstname
            from Agg_V5 agg
            join Port_Process lpr on lpr.hostid = agg.hostid
                                and lpr.ipaddress = agg.SrcAddr
                                and lpr.port = agg.SrcPort
                                and lpr.Protocol = agg.Prot
            left join Port_Process rpr on rpr.ipaddress = agg.DstAddr
                                and rpr.port = agg.DstPort
                                and lpr.Protocol = agg.Prot
            where agg.hostid = '2c4bfdd1c1d02333f9eae0a7332eecde' and ('1' or SrcAddr <> DstAddr) and ((rpr.hostid is null) or (lpr.hostid <> rpr.hostid) or (lpr.pid < rpr.pid))
            order by srcpid
    
Running software OSH created!
0 Likes
Highlighted
Contributor.
Contributor.

Re: Inconsistent port discovery

Yes the scanner collects and creates IP service endpoints. It is done with the settings of the scanner to collect running processes and tcp/ip conncetivity. I am attaching the scanner configuration--Hardware options page for reference.

HP Support
If you find that this or any post has resolved your issues please mark it as solved.
0 Likes
Highlighted
Absent Member.. Absent Member..
Absent Member..

Re: Inconsistent port discovery

I finally had a chance to get back to this and try some of the suggestions.  First, it turns out I already had the Running Software and TCP/IP options selected in my scanner options.  So that wasn't it.  I haven't had a chance to look at Application Signatures just yet.  I decided to work on the script-based discovery first since the activity takes so much less time to run.

What I've been able to piece together from digging through the Python scripts is that they are running a netstat command against the target server and then walking through each line of the output.  I've added debug statements to follow that so I know its processing each and every line of that netstat output.  I just can't see where or why it only results in the creation of a select few IpServiceEndpoint objects.

Maybe I need to step back a bit and ask a simpler question.  Am I looking for the right object?  My customer is expecting UCMDB to show them a list of all processes that are actively listening to TCP and UDP ports on the target system, regardless of whether anything happens to be connected to that port/process when the scan runs.  Is that what the script-based discovery activity should be collecting?  Should those ports be represented by IpServiceEndpoint objects or some other object?

0 Likes
Highlighted
Absent Member.. Absent Member..
Absent Member..

Re: Inconsistent port discovery

Further debugging of the Python script has shown that the IpServiceEndpoint objects are only being created for connections listed in the netstat output where there is an active state connection between two IP addresses.  The listening state entries in the netstat output with no actual connection at the time of the scan are not translated into UCMDB objects.

Looks like we need to modify the Python script to include those listening state entries as well.

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.