Agent to and from Beacon Communication

mcavanagh
Flexera
Flexera
8 5 569

Agent to and from Beacon Communication 

Below is a breakdown of files transferred from the Agent to the Beacon and the Beacon to the Agent. Your diagram should look like this. Minus any load balancers or proxies, as this will be covered separately below. 

agent to beacon.PNG

NOTE: This communication will be over port 80 or 443 by default, and both directions need to be open for communication to happen. 

 

Incoming (To agent) from ManageSoftDL on the Beacon 

The files generated by the Beacon are based on the Beacon policy file that will be discussed next. Several files will be transferred from the Beacon to the Agent. These Files include: 

  • Policy(.npl): 
    • Location: C:\ProgramData\ManageSoft Corp\ManageSoft\Policy Client\Policies\Merged\Machine 

This is the initial file that an Agent will download; it contains the client files listed below. 

NOTE: If during a fresh installation, this file fails to download, it will not retry. To resolve this, you will need to either restart the agent service or restart the device. 

  • Schedule (.osd + .nds) 

This is the file that controls when the Agent will update Machine Policy, Client Settings, and Client Files. The settings that control this are located within Discovery & Inventory> Settings> Agent Schedule. 

NOTE: This is also the exact location where the setting is held to generate the Inventory of the device that has the Agent installed. 

  • Settings (.osd + .nds) 

These files control what is being inventoried, such as including/excluding folders, file types. The settings govern this within Discovery & Inventory> Settings> File Evidence. 

  • Failover (.osd + .nds) 

These settings are if you have additional Beacons set up. Suppose the agent cannot communicate with one of the Beacons. In that case, it can send or receive packages from another Beacon on your Estate. These Beacons can be seen from the Discovery & Inventory> Beacons page, and you can also view these within Regedit under. 

  • HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\ManageSoft Corp\ManageSoft \Common\ DownloadSettings 
  • HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\ManageSoft Corp\ManageSoft\Common\UploadSettings 
  • Upgrade Packages (.OSD + .NDS + .NDC) 

These upgrade packages are there if you wish to upgrade the agent to a newer version than what it is currently on. 

  • Outgoing (To Beacon) – To ManageSoftRL on the beacon 

These are the files needed to inventory the machine; these come from the locations listed in each subsection. 

  • Logs 
    • Location: C:\ProgramData\ManageSoft Corp\ManageSoft\Common\Uploads\Logs 

There are a few additional files such as VDI and Security Service Logs that get sent to The Beacon 

  • Inventory (.ndi) 
    • Local Location: C:\ProgramData\ManageSoft Corp\ManageSoft\Common\Uploads\Inventories 

These Files are the generated inventory of the device in question. There are different kinds of. NDI files are dependent on what is being run. i.e., Oracle. These files contain the hardware and software data from the device. If file evidence is installed, it will also grab oracle applications. NDI files will include what option packs are installed on what oracle instance. 

  • Usage (.mmi) 
    • Location: C:\ProgramData\ManageSoft Corp\ManageSoft\Common\Uploads\UsageData 

Captures events from the Usage Agent, which captures application usage information. The usage agent runs under the  'Flexera Inventory Manager security service' Windows Service. 

  

Outgoing (To Beacon) – To ManageSoftRL on the beacon 

These are the files needed to inventory the machine; these come from the locations listed in each subsection. 

  • Logs 
    • Location: C:\ProgramData\ManageSoft Corp\ManageSoft\Common\Uploads\Logs 

A few additional files such as VDI and Security Service Logs get sent to the Beacon. 

  • Inventory (.ndi) 
    • Local Location: C:\ProgramData\ManageSoft Corp\ManageSoft\Common\Uploads\Inventories 

These Files are the generated inventory of the device in question. There are different kinds of.NDI files are dependent on what is being run. i.e., Oracle. These files contain the hardware and software data from the device. If file evidence is installed, it will also grab oracle applications.NDI files will include what option packs are installed on what oracle instance. 

  • Usage (.mmi) 
    • Location: C:\ProgramData\ManageSoft Corp\ManageSoft\Common\Uploads\UsageData 

Captures events from the user agent, which captures application usage information. The usage agent runs under the 'Flexera Inventory Manager security service' Windows Service. 

 

5 Comments
pavol_holes
Level 6

Hi @mcavanagh, can you verify if this statement is right?

"NOTE: This communication will be over port 80 or 443 by default, and both directions need to be open for communication to happen. "

I think all communication is happening only from the Agent to the Beacon, so there is actually need only for one-way communication from the Agent to the Beacons.

So the policy files and schedules are pulled by the Agent from the Beacon (so the network communication is started by the Agent = outgoing from the Agent and the policy/schedule is downloaded from the Beacon).

And the inventory files are pushed by the Agent to the Beacon (again the network communication is started by the Agent = outgoing from the Agent and the inventory files are uploaded to the Beacon).

In both cases the network traffic is initiated by the Agent and the network communication session is kept open from the Agent to the Beacon for download or upload. So in both cases the communication (from the firewalls perspective) is only one-way from the Agent to the Beacon.

This design is correct as we can have remote Agents deployed on the PCs anywhere in the world which needs to send scans over the internet to the on-premise Beacon. For this the Beacon would have the firewall opened (of course secured) for incoming connections. But the Agent doesn't have to have any incoming connections opened and that's important from the cybersecurity perspective.

 

And please also verify if this article is correct: https://community.flexera.com/t5/FlexNet-Manager-Blog/Data-Flow-Considerations/ba-p/195968. That one has the same language used as is used in this article.

 

Thank you.

Have a great day.

Regards,

Pavol

kclausen
Flexera
Flexera

2-way communication is correct.  Assuming that HTTP/Port 80 is configured, then the agent will initiate an HTTP PUT to upload inventory files TO the beacon.  This uploads inventory files from the end point to the beacon.

Do download policies FROM the beacon, the agent will initiate an HTTP GET.  This downloads policy files from the beacon to the end point.

Therefore, the direction is 2-ways, even though the Agent is initiating all communication.

And when secure communication is configured, the agent will initiate HTTPS PUT and HTTPS GET.

pavol_holes
Level 6

Hello @kclausen, thank you for your insight. I believe you confirmed what I wrote:

"Assuming that HTTP/Port 80 is configured, then the agent will initiate an HTTP PUT to upload inventory files TO the beacon.  This uploads inventory files from the end point to the beacon.

Do download policies FROM the beacon, the agent will initiate an HTTP GET.  This downloads policy files from the beacon to the end point."

So you confirmed that both PUT and GET are initiated from the Agent. And according to my knowledge that's important from the firewalls perspective to tell if the communication is one-way or bi-directional. Since in both cases the communication is initiated by the Agent then according to my knowledge it's considered as one-way from the Agent to the Beacon. And so the incoming firewall rules on the device running the Agent are not needed to be adjusted.

It's not important what will happen after the connection is initiated, if it's download or upload, the connection was initiated and secured in case of HTTPS and it can go on.

Don't get me wrong, I'm just trying to help other others and clear things out.

kclausen
Flexera
Flexera

It is 2-way.  In one case a data packet goes from the end point to the beacon.  In the other case, a data package goes from the beacon to the end point.  From a firewall/proxy perspective, data packets on the network are going in both directions.

bmaudlin
Level 8

@pavol_holes

You are correct in your assumption, the key thing here is how the firewall is configured. As long as the Firewall is set for Stateful. The firewall is intelligent enough to return the data back to the original request IP. So you would only have to have the firewall open one one way.

So it would look like this >

SourceDestinationPort
192.168.1.110.10.10.1

80/443

 

If you had a Stateless Firewall as communications are technically bi-directional, those type of firewalls would refuse the connection back to the source or to the destination so you would have to firewall both ways for agent connectivity to work correctly.

Like this >

SourceDestinationPort
192.168.1.110.10.10.180/443
10.10.10.1192.168.1.180/443

*IP's used are for reference.

Hope this helps.