Posts by chrissmith

Hi-

That is a great question. To connect the two fabrics, a bridge must be created that connects to both fabrics. This can be done with any of the clients (Python, etc.) or Node-RED.

Let me know if you would like an example, and I will put one together.

Thanks,

Chris

Hi-

Unfortunately, that particular use case is not currently supported via the DXL interface that is exposed by TIE.

However, you might (I am not a TIE expert) be able to take advantage of TIE’s ability to have a “reporting” DB node, which is a read-only replica of the primary DB. At that point, you could potentially access the DB directly and extract the information you are looking for.

Hope this helps,

Chris

chrissmith added a new solution:

Quote

McAfee Active Response delivers continuous detection of and response to advanced security threats to help security practitioners monitor security posture, improve threat detection, and expand incident response capabilities through forward-looking discovery, detailed analysis, forensic investigation, comprehensive reporting, and prioritized alerts and actions

McAfee Active Response is proof of the effectiveness of the integrated McAfee security architecture, which is designed to resolve more threats faster and with fewer resources in a more complex world. McAfee Active Response gives you continuous visibility and powerful insights into your endpoints so you can identify breaches faster. And it provides you with the tools you need to correct issues faster and in the way that makes the most sense for your business. All of this power is managed via McAfee® ePolicy Orchestrator® (McAfee ePO™) software leveraging McAfee Data Exchange Layer—this provides unified scalability and extensibility without the need for incremental staff to administer the product.

chrissmith added a new version:

Quote

MISP DXL Python Service 0.1.3 Release

• Pinned PyMISP to previous version as it was causing test cases to fail

New article posted that walks through the process of installing, provisioning, and running a subset of the samples that are included with the OpenDXL Java Client.

The Java client has been released:

Thanks,

Chris

Quote from brian:

Thanks, that's very helpful. If I understood correctly, it sounds like a hub consisting of 2 brokers would act very similar to just bridging 2 brokers with a parentId.

Unfortunately, you can't bridge two brokers and have them bridge to the same parent identifier. A broker can only have one outgoing bridge (it can have an unlimited number of incoming, aka brokers bridging to it). That is the reason the hub exists, the brokers are able to dynamically change who they bridge to based on the presence (or absence) of the other broker in the hub.

Quote from brian:

For a simple deployment of just 2 or 3 brokers, would there be any reason to introduce a hub? Is that more of an advanced configuration, once you start to scale out to many brokers across different sites and you want the resilience between hubs?

For two brokers, no.

For three brokers, yes.

By having a hub comprised of two brokers and a single spoke, if a single broker goes down, you are still guaranteed to have the remaining two brokers connected. If you had three brokers connected to each other without a hub, if the middle broker went down, the remaining two would be unable to communicate with each other.

Hope this helps,

Chris

Hi Brian-

That is a great question.

Typically fabrics are scaled out in a hub-and-spoke pattern. To add further scalability (support additional client connections, etc.) you can add more spokes (brokers) to a hub.

The image above is an example of a hub-and-spoke deployment of a DXL fabric. Each of the hubs might reside in a different geographic location. The top hub might be the "global" hub that connects the various regions.

Hubs are critical pieces of the fabric due to the fact that if they fail, the fabric will split. This isn't the case with the lower level brokers as they are there to provide scalability. If any particular broker fails, the fabric as a whole is still connected.

So, to reduce the possibility of a fabric split, DXL introduced the concept of a hub that can contain two brokers. A hub is not something that is physically deployed, it is just a set of rules that the brokers comprising the hub follow. If one of the brokers goes down, the other will bridge to the parent hub or broker, retaining the connected state of the overall fabric. It is also important to note that both of the brokers are active. They connect to each other, and only one of them is connected to their parent at any given time. The children of the hub will select one of the two brokers to connect to.

Hopefully that helps. Please let me know if you have any additional questions.

Thanks a lot,

Chris

Hi-

The integration tests are part of the Java client which is currently being updated to be released as an open source project (should be released fairly soon). The Python tests do perform a subset of the integration tests. Until the Java client releases, the Python tests probably serve as the best integration tests available at this time.

Thanks,

Chris

Hi-

That is a great question. Unfortunately, at this point there is not a specification for developing a custom broker, but that is definitely something that we should work to address in the future.

As far as what can be done today, it really depends on what you are wanting to achieve. An OpenDXL client can connect to an MQTT broker today (and send events), but none of the added functionality will be available.

At a very high-level the main additions to a standard MQTT broker are as follows:

• RESTful-like service-based model with load-balancing and failover
• Broker-based filtering of messages to specific clients and brokers
• Multi-broker hubs to support failover
• Client and CA-based certificate topic authorization
• Topic-based routing
• Multi-tenancy

See this page for a more detailed comparison between an OpenDXL broker and a standards-based MQTT broker.

So, one interesting place to start would be to add RESTful-like services support to a standard broker. In the future, other features such as multi-broker fabrics, filtering, routing, etc. could be added.

The implementation of the service registry in the OpenDXL broker can be found here. The service registry is used to track the services that are available throughout the fabric (as well as those that are on the local broker).

One of the key aspects of an integration with a broker is that you need to be able to hook into the various points of the message processing flow.

For Mosquitto, the flow stages for a message are as follows:

Publish => Store => Insert (per client) => Finalize

The OpenDXL Broker is able to hook at all these points in a message flow. The majority of the work in the OpenDXL broker occurs in the "Store" stage. At this point the broker can respond to particular topics. For example, it is able to handle service registration messages, and add them to the registry. It is also able to handle service look-ups when a client is attempting to invoke a service.

All of the handlers can be found in the following location:

https://github.com/opendxl/ope…brokerlib/message/handler

Some of the critical classes to look at related to services are as follows:

ServiceRegistryRegisterRequestHandler: Handles an incoming service registration request

ServiceLookupHandler: Handles an incoming request from a client to invoke a service

This is obviously just a starting point, and I totally agree that we need to put together a specification for both brokers and clients. We have been working on putting together specifications that can be used by OpenDXL solutions to document the functionality that they expose (more on this in the near future). After that, we can look at adding specifications for the client and brokers themselves.

Thanks again for the great question,

Chris

Over the past couple months, several projects have been developed that support using OpenDXL within the Node-RED flow-based programming tool.

Quote from Node-RED About Page:

Node-RED consists of a Node.js-based runtime that you point a web browser at to access the flow editor. Within the browser you create your application by dragging nodes from your palette into a workspace and start to wire them together. With a single click, the application is deployed back to the runtime where it is run.

The palette of nodes can be easily extended by installing new nodes created by the community and the flows you create can be easily shared as JSON files.

The purpose of this post is to summarize the different projects and efforts that have been made to support the integration of OpenDXL into Node-RED. This post will be updated as additional projects are developed.

Video: Using OpenDXL with Node-RED

• This video demonstrates using OpenDXL within Node-RED

OpenDXL Node-RED Docker Image

• A Docker image that consists of the Node-RED installation along with the core OpenDXL Node-RED extensions

OpenDXL Node-RED Extensions

• Core collection of DXL Node-RED nodes
• McAfee ePolicy Orchestrator (ePO) nodes for Node-RED using DXL
• McAfee Active Response (MAR) nodes for Node-RED using DXL
• McAfee Threat Intelligence Exchange (TIE) nodes for Node-RED using DXL
• Cisco pxGrid nodes for Node-RED using DXL

Node-RED Solution Categories on OpenDXL.com

• General Category
  • General Node-RED OpenDXL solutions (Docker images, etc.)
• Modules Category
  • Contains OpenDXL modules for Node-RED (ePO, TIE, MAR, pxGrid, etc.)
• Flows Category
  • Contains pre-built Node-RED flows that can be imported into Node-RED

The issue is that you are attempting to use your client (not the DXL client) with the Python with keyword.

Your code should resemble the following example (from the TIE client):

Basic Get Reputation Example

Your client (IRFlowApiClient) should be created in the same manner as the TieClient shown above.

Hope this helps.

Thanks,

Chris

Bootstrap will generate the initial documentation. You will want to update it with information that is specific to the solution you are developing.

This following portion of the bootstrap tutorial walks through creating a distribution, which includes building the documentation via Sphinx (generating HTML from the documentation source files).

Tutorial Part 5: Package Distributions

Thanks,

Chris

Actually, that is not the process I use.

Basically, what I do is the following (there are multiple ways, but I will describe this via the GitHub UI).

1.) Navigate to your repository on GitHub

2.) Click the "branch" pulldown (master by default)

3.) Type in "gh-pages" and click "create branch: gh-pages"

4.) Clone the "gh-pages" branch and delete the existing content. Add the content you want to host (pydocs, etc.).

5.) Click on "settings" in your repository on GitHub

6.) Scroll to the "GitHub Pages" section. Ensure "source" is set to "gh-pages branch"

Again, there are many ways to do this, but this is essentially what I do.

Thanks,

Chris

chrissmith added a new solution:

Quote

When a MISP event is published, the flow examines the event to determine if it contains hash-based attributes. If it does, a MAR search is performed to determine if any active endpoints contain the hashes. For each endpoint containing a hash, a sighting is added to the MISP event in addition to a comment that includes the associated endpoint information.

Prerequisites

• The Node-RED DXL client configuration step has been completed (see Client Configuration).
• A McAfee Active Response (MAR) service is available on the DXL fabric.
• The Node-RED DXL client is authorized to perform MAR searches (see Authorize Client to Perform MAR Search).
• The MISP DXL Service is running and connected to the DXL fabric.
  • The service is configured to connect to ZeroMQ (zeroMqPort) and the notification topic misp_json is being forwarded.
  • The service exposes the sighting API
• The following Node-RED modules have been installed:
  • Node-RED config node (included in OpenDXL Node-RED Docker image)
  • DXL Node-RED nodes (included in OpenDXL Node-RED Docker image)
  • McAfee Active Response (MAR) DXL nodes for Node-RED

The Node-RED flow content for this solution:

Code: Node-RED Flow

1. [
2. {
3. "id": "3bcf37ef.a9d108",
4. "type": "tab",
5. "label": "Add Hash Sightings to MISP Event using MAR",
6. "disabled": false,
7. "info": "This flow utilizes McAfee Active Response (MAR) to adds sightings to MISP \r\npublished events containing hash-based attributes.\r\n\r\nWhen a MISP event is published, the flow examines the event to determine if \r\nit contains hash-based attributes. If it does, a MAR search is performed \r\nto determine if any active endpoints contain the hashes. For each endpoint\r\ncontaining a hash, a sighting is added to the MISP event in addition to a \r\ncomment that includes the associated endpoint information.\r\n\r\n### Prerequisites\r\n\r\n* The Node-RED DXL client configuration step has been completed (see\r\n [Client Configuration](https://opendxl.github.io/node-red-contrib-dxl/jsdoc/tutorial-configuration.html)).\r\n* A McAfee Active Response (MAR) service is available on the DXL fabric.\r\n* The Node-RED DXL client is authorized to perform MAR searches\r\n (see [Authorize Client to Perform MAR Search](https://opendxl.github.io/opendxl-client-python/pydoc/marsendauth.html)).\r\n* The [MISP DXL Service](https://github.com/opendxl/opendxl-misp-service-python) is running and connected to the DXL fabric.\r\n * The service is configured to connect to ZeroMQ (`zeroMqPort`) and the notification topic `misp_json` is being forwarded.\r\n * The service exposes the `sighting` API \r\n* The following Node-RED modules have been installed:\r\n * [Node-RED config node](https://flows.nodered.org/node/node-red-contrib-config) (included in OpenDXL Node-RED Docker image)\r\n * [DXL Node-RED nodes](https://flows.nodered.org/node/@opendxl/node-red-contrib-dxl) (included in OpenDXL Node-RED Docker image)\r\n * [McAfee Active Response (MAR) DXL nodes for Node-RED](https://flows.nodered.org/node/@opendxl/node-red-contrib-dxl-mar-client)\r\n \r\n"
8. },
9. {
10. "id": "3d363a67.a36dd6",
11. "type": "dxl-core-event in",
12. "z": "3bcf37ef.a9d108",
13. "name": "Receive MISP Event Publish Notifications",
14. "topic": "/opendxl-misp/event/zeromq-notifications/misp_json",
15. "client": "cc766472.7a4b28",
16. "payloadType": "obj",
17. "x": 180,
18. "y": 60,
19. "wires": [
20. [
21. "9e6420fb.a4d33",
22. "945c3d8c.86648"
23. ]
24. ]
25. },
26. {
27. "id": "5fb31223.b5578c",
28. "type": "debug",
29. "z": "3bcf37ef.a9d108",
30. "name": "Debug: Sighting Request",
31. "active": true,
32. "tosidebar": true,
33. "console": false,
34. "tostatus": false,
35. "complete": "payload",
36. "x": 770,
37. "y": 414,
38. "wires": []
39. },
40. {
41. "id": "9e6420fb.a4d33",
42. "type": "function",
43. "z": "3bcf37ef.a9d108",
44. "name": "Extract Hash-based Attributes",
45. "func": "var output = []\n\nif(msg.payload && \n msg.payload.Event &&\n msg.payload.Event.Attribute) {\n var attribs = msg.payload.Event.Attribute\n attribs.forEach(function(entry) {\n if(entry.type == \"md5\" ||\n entry.type == \"sha1\" ||\n entry.type == \"sha256\") {\n output.push({\n \"uuid\": entry.uuid,\n \"type\": entry.type,\n \"value\": entry.value\n });\n }\n });\n}\nmsg.payload = output;\nreturn msg;",
46. "outputs": 1,
47. "noerr": 0,
48. "x": 210,
49. "y": 140,
50. "wires": [
51. [
52. "28fb53c3.5229cc"
53. ]
54. ]
55. },
56. {
57. "id": "8e254ff0.db295",
58. "type": "function",
59. "z": "3bcf37ef.a9d108",
60. "name": "Extract Found Host IP Addresses",
61. "func": "msg.payload = \n msg.payload.map(function (processEntry) {\n return processEntry.output[\"HostInfo|ip_address\"]\n })\nreturn msg",
62. "outputs": 1,
63. "noerr": 0,
64. "x": 360,
65. "y": 294,
66. "wires": [
67. [
68. "cbbd0543.94c9e8"
69. ]
70. ]
71. },
72. {
73. "id": "cbbd0543.94c9e8",
74. "type": "split",
75. "z": "3bcf37ef.a9d108",
76. "name": "Execute for each IP address",
77. "splt": "\\n",
78. "spltType": "str",
79. "arraySplt": 1,
80. "arraySpltType": "len",
81. "stream": false,
82. "addname": "",
83. "x": 420,
84. "y": 354,
85. "wires": [
86. [
87. "2166f5bc.f4597a"
88. ]
89. ]
90. },
91. {
92. "id": "51a75203.b4424c",
93. "type": "function",
94. "z": "3bcf37ef.a9d108",
95. "name": "Compose MAR Search Condition",
96. "func": "msg.mispHash = msg.payload;\nmsg.conditions = {\n \"or\": [{\n \"and\": [{\n \"name\": \"Files\",\n \"output\": msg.mispHash.type,\n \"op\": \"EQUALS\",\n \"value\": msg.mispHash.value\n }]\n }]\n};\n\nreturn msg;\n",
97. "outputs": 1,
98. "noerr": 0,
99. "x": 620,
100. "y": 200,
101. "wires": [
102. [
103. "354b7393.e9e4ac"
104. ]
105. ]
106. },
107. {
108. "id": "d95da896.6b2648",
109. "type": "dxl-core-request",
110. "z": "3bcf37ef.a9d108",
111. "name": "Add Sighting to MISP Event",
112. "topic": "/opendxl-misp/service/misp-api/sighting",
113. "client": "cc766472.7a4b28",
114. "returnType": "txt",
115. "x": 780,
116. "y": 474,
117. "wires": [
118. [
119. "7fd94d76.8ea7d4"
120. ]
121. ]
122. },
123. {
124. "id": "2166f5bc.f4597a",
125. "type": "template",
126. "z": "3bcf37ef.a9d108",
127. "name": "Format Add Sighting Request",
128. "field": "payload",
129. "fieldType": "msg",
130. "format": "handlebars",
131. "syntax": "mustache",
132. "template": "{\n \"uuid\": \"{{mispHash.uuid}}\",\n \"type\": \"0\",\n \"source\": \"Observed on system {{payload}}\"\n}",
133. "output": "json",
134. "x": 470,
135. "y": 474,
136. "wires": [
137. [
138. "d95da896.6b2648",
139. "5fb31223.b5578c"
140. ]
141. ]
142. },
143. {
144. "id": "28fb53c3.5229cc",
145. "type": "split",
146. "z": "3bcf37ef.a9d108",
147. "name": "Execute MAR Search for each Hash",
148. "splt": "\\n",
149. "spltType": "str",
150. "arraySplt": 1,
151. "arraySpltType": "len",
152. "stream": false,
153. "addname": "",
154. "x": 290,
155. "y": 200,
156. "wires": [
157. [
158. "51a75203.b4424c"
159. ]
160. ]
161. },
162. {
163. "id": "7fd94d76.8ea7d4",
164. "type": "debug",
165. "z": "3bcf37ef.a9d108",
166. "name": "Debug: Response",
167. "active": true,
168. "tosidebar": true,
169. "console": false,
170. "tostatus": false,
171. "complete": "payload",
172. "x": 1030,
173. "y": 474,
174. "wires": []
175. },
176. {
177. "id": "945c3d8c.86648",
178. "type": "debug",
179. "z": "3bcf37ef.a9d108",
180. "name": "Debug: Received Event",
181. "active": true,
182. "tosidebar": true,
183. "console": false,
184. "tostatus": false,
185. "complete": "payload",
186. "x": 570,
187. "y": 60,
188. "wires": []
189. },
190. {
191. "id": "354b7393.e9e4ac",
192. "type": "dxl-mar-search",
193. "z": "3bcf37ef.a9d108",
194. "name": "",
195. "pollInterval": 5,
196. "client": "cc766472.7a4b28",
197. "projections": "[\n {\n \"name\": \"HostInfo\", \n \"outputs\": [\"ip_address\"]\n }\n]",
198. "limit": "",
199. "textFilter": "",
200. "sortBy": "",
201. "sortDirection": "",
202. "returnType": "obj",
203. "x": 870,
204. "y": 200,
205. "wires": [
206. [
207. "8e254ff0.db295"
208. ]
209. ]
210. }
211. ]

Display More

chrissmith added a new solution:

Quote

Prerequisites

• The Node-RED DXL client configuration step has been completed (see Client Configuration).
• The DXL fabric to which the Node-RED DXL client will connect has been bridged to Cisco pxGrid.
• An ePO DXL service is running and available on the DXL fabric. If version 5.0 or later of the DXL ePO extensions are installed on your ePO server, an ePO DXL service should already be running on the fabric. If you are using an earlier version of the DXL ePO extensions, you can use the ePO DXL Python Service.
• The Node-RED DXL client is authorized to perform the apply tag, clear tag, and find system operations within ePO (see Client Authorization).
• The Node-RED DXL client is authorized to perform DXL Cisco pxGrid Queries (see Authorize Client to Use Cisco pxGrid via DXL)
• The following Node-RED modules have been installed (Node-RED palette):
  • Node-RED config node (included in OpenDXL Node-RED Docker image)
  • DXL Node-RED nodes (included in OpenDXL Node-RED Docker image)
  • McAfee ePolicy Orchestrator (ePO) DXL nodes for Node-RED
  • Cisco pxGrid DXL nodes for Node-RED

Setup

Configure the Configure: ISE Policy to ePO Tag Mapping node. This node contains a mapping that maps between the ISE policy name and the corresponding tag name within ePO (see below).

JavaScript: ISE Policy to ePO Tag Mapping

1. {
2. "shut_down_policy": "ISE_shut_down_policy",
3. "port_bounce_policy": "ISE_port_bounce_policy",
4. "quarantine_policy": "ISE_quarantine_policy"
5. }

This mapping should be updated to reflect your Cisco ISE ANC policy names and corresponding tag names within ePO. Each of the ePO tag names must be created within ePO (they are not automatically created).

The Node-RED flow content for this solution:

Code: Node-RED Flow

1. [
2. {
3. "id": "454f293f.10a098",
4. "type": "tab",
5. "label": "Tag System when ISE Policy Applied",
6. "disabled": false,
7. "info": "This flow ensures that systems within McAfee ePO are tagged to indicate\r\nwhat policies are currently applied within Cisco ISE Adaptive Network \r\nControl (ANC). When an ANC policy is applied, the corresponding system is\r\nlocated within ePO and tagged approriately. When an ANC policy is removed,\r\nthe corresponding system is located within ePO and untagged appropriately.\r\n\r\n### Prerequisites\r\n\r\n* The Node-RED DXL client configuration step has been completed (see\r\n [Client Configuration](https://opendxl.github.io/node-red-contrib-dxl/jsdoc/tutorial-configuration.html)).\r\n* The DXL fabric to which the Node-RED DXL client will connect has been bridged to Cisco\r\n pxGrid.\r\n* An ePO DXL service is running and available on the DXL fabric. If version 5.0\r\n or later of the DXL ePO extensions are installed on your ePO server, an ePO\r\n DXL service should already be running on the fabric. If you are using an\r\n earlier version of the DXL ePO extensions, you can use the\r\n [ePO DXL Python Service](https://github.com/opendxl/opendxl-epo-service-python).\r\n* The Node-RED DXL client is authorized to perform the `apply tag`, `clear tag`,\r\n and `find system` operations within ePO (see\r\n [Client Authorization](https://opendxl.github.io/opendxl-epo-client-python/pydoc/authorization.html)).\r\n* The Node-RED DXL client is authorized to perform `DXL Cisco pxGrid Queries`\r\n (see [Authorize Client to Use Cisco pxGrid via DXL](https://opendxl.github.io/opendxl-pxgrid-client-python/pydoc/pxgridauth.html))\r\n* The following Node-RED modules have been installed:\r\n * [Node-RED config node](https://flows.nodered.org/node/node-red-contrib-config) (included in OpenDXL Node-RED Docker image)\r\n * [DXL Node-RED nodes](https://flows.nodered.org/node/@opendxl/node-red-contrib-dxl) (included in OpenDXL Node-RED Docker image)\r\n * [McAfee ePolicy Orchestrator (ePO) DXL nodes for Node-RED](https://flows.nodered.org/node/@opendxl/node-red-contrib-dxl-epo-client)\r\n * [Cisco pxGrid DXL nodes for Node-RED](https://flows.nodered.org/node/@opendxl/node-red-contrib-dxl-pxgrid-client) \r\n\r\n### Setup\r\n\r\n* Configure the `Configure: ISE Policy to ePO Tag Mapping` node. This node \r\n contains a mapping that maps between the ISE policy name and the \r\n corresponding tag name within ePO (see below).\r\n\r\n```javascript\r\n{\r\n \"shut_down_policy\": \"ISE_shut_down_policy\",\r\n \"port_bounce_policy\": \"ISE_port_bounce_policy\",\r\n \"quarantine_policy\": \"ISE_quarantine_policy\"\r\n}\r\n```\r\n\r\nThis mapping should be updated to reflect your Cisco ISE ANC policy names and corresponding tag\r\nnames within ePO. Each of the ePO tag names must be created within ePO (they \r\nare not automatically created).\r\n"
8. },
9. {
10. "id": "74ea78ed.44fa38",
11. "type": "function",
12. "z": "454f293f.10a098",
13. "name": "Extract IP Address from Result",
14. "func": "if(msg.payload.length)\n msg.names = msg.payload[0]['EPOComputerProperties.IPAddress'];\n\nif(msg.names)\n node.send(msg);\nelse\n node.warn(\"Unable to find IP address for: \" + msg.macAddress);",
15. "outputs": 1,
16. "noerr": 0,
17. "x": 490,
18. "y": 740,
19. "wires": [
20. [
21. "fc467203.f8911"
22. ]
23. ]
24. },
25. {
26. "id": "326a995c.504086",
27. "type": "function",
28. "z": "454f293f.10a098",
29. "name": "Format System Find Request",
30. "func": "msg.macAddress = msg.payload.macAddress;\nmsg.searchText = msg.macAddress.replace(/:/g,'');\nreturn msg;",
31. "outputs": 1,
32. "noerr": 0,
33. "x": 480,
34. "y": 580,
35. "wires": [
36. [
37. "d3a40a6d.61e2d8"
38. ]
39. ]
40. },
41. {
42. "id": "4951c6c3.245d58",
43. "type": "switch",
44. "z": "454f293f.10a098",
45. "name": "Determine if event contains IP or MAC",
46. "property": "payload.ipAddress",
47. "propertyType": "msg",
48. "rules": [
49. {
50. "t": "nnull"
51. },
52. {
53. "t": "null"
54. }
55. ],
56. "checkall": "true",
57. "repair": false,
58. "outputs": 2,
59. "x": 250,
60. "y": 500,
61. "wires": [
62. [
63. "7538913a.f122e"
64. ],
65. [
66. "326a995c.504086"
67. ]
68. ],
69. "outputLabels": [
70. "IP Address",
71. "MAC Address"
72. ]
73. },
74. {
75. "id": "94e79ef.7e98e6",
76. "type": "debug",
77. "z": "454f293f.10a098",
78. "name": "Debug: Response",
79. "active": true,
80. "tosidebar": true,
81. "console": false,
82. "tostatus": false,
83. "complete": "payload",
84. "x": 990,
85. "y": 640,
86. "wires": []
87. },
88. {
89. "id": "4b4e0ddd.ebc784",
90. "type": "debug",
91. "z": "454f293f.10a098",
92. "name": "Debug: ISE Apply Notification",
93. "active": true,
94. "tosidebar": true,
95. "console": false,
96. "tostatus": false,
97. "complete": "payload",
98. "x": 590,
99. "y": 240,
100. "wires": []
101. },
102. {
103. "id": "808becbf.b6432",
104. "type": "function",
105. "z": "454f293f.10a098",
106. "name": "Set Tag Name to Apply",
107. "func": "msg.tagName = flow.get(\"policyToTagMap\")[msg.payload.policyName]\n\nif(msg.tagName)\n node.send(msg);\nelse\n node.warn(\"Tag not found for policy: \" + msg.payload.policyName);\n",
108. "outputs": 1,
109. "noerr": 0,
110. "x": 210,
111. "y": 340,
112. "wires": [
113. [
114. "4951c6c3.245d58"
115. ]
116. ]
117. },
118. {
119. "id": "7538913a.f122e",
120. "type": "change",
121. "z": "454f293f.10a098",
122. "name": "Extract IP Address from ISE Event",
123. "rules": [
124. {
125. "t": "set",
126. "p": "names",
127. "pt": "msg",
128. "to": "payload.ipAddress",
129. "tot": "msg"
130. }
131. ],
132. "action": "",
133. "property": "",
134. "from": "",
135. "to": "",
136. "reg": false,
137. "x": 500,
138. "y": 420,
139. "wires": [
140. [
141. "fc467203.f8911"
142. ]
143. ]
144. },
145. {
146. "id": "73eca8ff.3b6c58",
147. "type": "comment",
148. "z": "454f293f.10a098",
149. "name": "Tag ePO System based on Cisco ISE Apply Endpoint Policy Notification",
150. "info": "",
151. "x": 270,
152. "y": 180,
153. "wires": []
154. },
155. {
156. "id": "fc467203.f8911",
157. "type": "function",
158. "z": "454f293f.10a098",
159. "name": "Join",
160. "func": "\nreturn msg;",
161. "outputs": 1,
162. "noerr": 0,
163. "x": 730,
164. "y": 540,
165. "wires": [
166. [
167. "a22897d6.bdac58",
168. "27004ecc.2bda12",
169. "df83f27a.76672"
170. ]
171. ]
172. },
173. {
174. "id": "27004ecc.2bda12",
175. "type": "debug",
176. "z": "454f293f.10a098",
177. "name": "Debug: System to Tag",
178. "active": true,
179. "tosidebar": true,
180. "console": false,
181. "tostatus": false,
182. "complete": "names",
183. "x": 1000,
184. "y": 400,
185. "wires": []
186. },
187. {
188. "id": "df83f27a.76672",
189. "type": "debug",
190. "z": "454f293f.10a098",
191. "name": "Debug: Tag to Apply",
192. "active": true,
193. "tosidebar": true,
194. "console": false,
195. "tostatus": false,
196. "complete": "tagName",
197. "x": 1000,
198. "y": 440,
199. "wires": []
200. },
201. {
202. "id": "dc275431.b559f8",
203. "type": "function",
204. "z": "454f293f.10a098",
205. "name": "Extract IP Address from Result",
206. "func": "if(msg.payload.length)\n msg.names = msg.payload[0]['EPOComputerProperties.IPAddress'];\n\nif(msg.names)\n node.send(msg);\nelse\n node.warn(\"Unable to find IP address for: \" + msg.macAddress);",
207. "outputs": 1,
208. "noerr": 0,
209. "x": 490,
210. "y": 1340,
211. "wires": [
212. [
213. "fc1db5f3.3f4618"
214. ]
215. ]
216. },
217. {
218. "id": "e584c1a8.3c522",
219. "type": "function",
220. "z": "454f293f.10a098",
221. "name": "Format System Find Request",
222. "func": "msg.macAddress = msg.payload.macAddress;\nmsg.searchText = msg.macAddress.replace(/:/g,'');\nreturn msg;",
223. "outputs": 1,
224. "noerr": 0,
225. "x": 480,
226. "y": 1180,
227. "wires": [
228. [
229. "6b7a54f6.756f3c"
230. ]
231. ]
232. },
233. {
234. "id": "612d3d71.615f14",
235. "type": "switch",
236. "z": "454f293f.10a098",
237. "name": "Determine if event contains IP or MAC",
238. "property": "payload.ipAddress",
239. "propertyType": "msg",
240. "rules": [
241. {
242. "t": "nnull"
243. },
244. {
245. "t": "null"
246. }
247. ],
248. "checkall": "true",
249. "repair": false,
250. "outputs": 2,
251. "x": 250,
252. "y": 1080,
253. "wires": [
254. [
255. "722d6752.477ea8"
256. ],
257. [
258. "e584c1a8.3c522"
259. ]
260. ],
261. "outputLabels": [
262. "IP Address",
263. "MAC Address"
264. ]
265. },
266. {
267. "id": "4a2cf3e9.47dcac",
268. "type": "debug",
269. "z": "454f293f.10a098",
270. "name": "Debug: Response",
271. "active": true,
272. "tosidebar": true,
273. "console": false,
274. "tostatus": false,
275. "complete": "payload",
276. "x": 850,
277. "y": 1580,
278. "wires": []
279. },
280. {
281. "id": "824b2f3b.c4cb",
282. "type": "debug",
283. "z": "454f293f.10a098",
284. "name": "Debug: ISE Clear Notification",
285. "active": true,
286. "tosidebar": true,
287. "console": false,
288. "tostatus": false,
289. "complete": "payload",
290. "x": 580,
291. "y": 900,
292. "wires": []
293. },
294. {
295. "id": "722d6752.477ea8",
296. "type": "change",
297. "z": "454f293f.10a098",
298. "name": "Extract IP Address from ISE Event",
299. "rules": [
300. {
301. "t": "set",
302. "p": "names",
303. "pt": "msg",
304. "to": "payload.ipAddress",
305. "tot": "msg"
306. }
307. ],
308. "action": "",
309. "property": "",
310. "from": "",
311. "to": "",
312. "reg": false,
313. "x": 520,
314. "y": 980,
315. "wires": [
316. [
317. "fc1db5f3.3f4618"
318. ]
319. ]
320. },
321. {
322. "id": "60beb4e6.67beac",
323. "type": "comment",
324. "z": "454f293f.10a098",
325. "name": "Clear ePO System Tag based on Cisco ISE Clear Endpoint Policy Notification",
326. "info": "",
327. "x": 290,
328. "y": 840,
329. "wires": []
330. },
331. {
332. "id": "fc1db5f3.3f4618",
333. "type": "function",
334. "z": "454f293f.10a098",
335. "name": "Collect ISE Tag Names to Clear",
336. "func": "var policyMap = flow.get(\"policyToTagMap\");\nvar keys = Object.keys(policyMap);\nmsg.payload = keys.map(function(key){\n return policyMap[key]; \n});\nreturn msg;",
337. "outputs": 1,
338. "noerr": 0,
339. "x": 850,
340. "y": 1340,
341. "wires": [
342. [
343. "98dc07a7.a3fda8"
344. ]
345. ]
346. },
347. {
348. "id": "98dc07a7.a3fda8",
349. "type": "split",
350. "z": "454f293f.10a098",
351. "name": "Execute for each Tag Name",
352. "splt": "\\n",
353. "spltType": "str",
354. "arraySplt": 1,
355. "arraySpltType": "len",
356. "stream": false,
357. "addname": "",
358. "x": 260,
359. "y": 1500,
360. "wires": [
361. [
362. "e1607375.f97fd"
363. ]
364. ]
365. },
366. {
367. "id": "e1607375.f97fd",
368. "type": "change",
369. "z": "454f293f.10a098",
370. "name": "Set Tag Name to Clear",
371. "rules": [
372. {
373. "t": "set",
374. "p": "tagName",
375. "pt": "msg",
376. "to": "payload",
377. "tot": "msg"
378. }
379. ],
380. "action": "",
381. "property": "",
382. "from": "",
383. "to": "",
384. "reg": false,
385. "x": 340,
386. "y": 1580,
387. "wires": [
388. [
389. "f4184ca2.2bd89",
390. "f9e49855.aba888",
391. "8f4516f2.cbc7c8"
392. ]
393. ]
394. },
395. {
396. "id": "f9e49855.aba888",
397. "type": "debug",
398. "z": "454f293f.10a098",
399. "name": "Debug: Tag to Clear",
400. "active": true,
401. "tosidebar": true,
402. "console": false,
403. "tostatus": false,
404. "complete": "tagName",
405. "x": 620,
406. "y": 1520,
407. "wires": []
408. },
409. {
410. "id": "8f4516f2.cbc7c8",
411. "type": "debug",
412. "z": "454f293f.10a098",
413. "name": "Debug: System to Clear Tag",
414. "active": true,
415. "tosidebar": true,
416. "console": false,
417. "tostatus": false,
418. "complete": "names",
419. "x": 640,
420. "y": 1480,
421. "wires": []
422. },
423. {
424. "id": "30525000.94864",
425. "type": "dxl-ise-anc-apply-endpoint-policy in",
426. "z": "454f293f.10a098",
427. "name": "",
428. "client": "92f8ab5f.08f1b8",
429. "payloadType": "obj",
430. "x": 220,
431. "y": 240,
432. "wires": [
433. [
434. "4b4e0ddd.ebc784",
435. "808becbf.b6432"
436. ]
437. ]
438. },
439. {
440. "id": "79ef6e3b.3fdd5",
441. "type": "dxl-ise-anc-clear-endpoint-policy in",
442. "z": "454f293f.10a098",
443. "name": "",
444. "client": "92f8ab5f.08f1b8",
445. "payloadType": "obj",
446. "x": 220,
447. "y": 900,
448. "wires": [
449. [
450. "824b2f3b.c4cb",
451. "612d3d71.615f14"
452. ]
453. ]
454. },
455. {
456. "id": "a22897d6.bdac58",
457. "type": "dxl-epo-system-apply-tag",
458. "z": "454f293f.10a098",
459. "name": "",
460. "tagName": "",
461. "client": "92f8ab5f.08f1b8",
462. "epoUniqueId": "",
463. "returnType": "obj",
464. "x": 970,
465. "y": 540,
466. "wires": [
467. [
468. "94e79ef.7e98e6"
469. ]
470. ]
471. },
472. {
473. "id": "d3a40a6d.61e2d8",
474. "type": "dxl-epo-system-find",
475. "z": "454f293f.10a098",
476. "name": "",
477. "client": "92f8ab5f.08f1b8",
478. "searchNameOnly": false,
479. "epoUniqueId": "",
480. "returnType": "obj",
481. "x": 460,
482. "y": 660,
483. "wires": [
484. [
485. "74ea78ed.44fa38"
486. ]
487. ]
488. },
489. {
490. "id": "6b7a54f6.756f3c",
491. "type": "dxl-epo-system-find",
492. "z": "454f293f.10a098",
493. "name": "",
494. "client": "92f8ab5f.08f1b8",
495. "searchNameOnly": false,
496. "epoUniqueId": "",
497. "returnType": "obj",
498. "x": 460,
499. "y": 1260,
500. "wires": [
501. [
502. "dc275431.b559f8"
503. ]
504. ]
505. },
506. {
507. "id": "f4184ca2.2bd89",
508. "type": "dxl-epo-system-clear-tag",
509. "z": "454f293f.10a098",
510. "name": "",
511. "tagName": "",
512. "client": "92f8ab5f.08f1b8",
513. "epoUniqueId": "",
514. "returnType": "obj",
515. "x": 600,
516. "y": 1580,
517. "wires": [
518. [
519. "4a2cf3e9.47dcac"
520. ]
521. ]
522. },
523. {
524. "id": "6a9f1e60.07926",
525. "type": "config",
526. "z": "454f293f.10a098",
527. "name": "Configure: ISE Policy to ePO Tag Mapping",
528. "properties": [
529. {
530. "p": "policyToTagMap",
531. "pt": "flow",
532. "to": "{\"shut_down_policy\":\"ISE_shut_down_policy\",\"port_bounce_policy\":\"ISE_port_bounce_policy\",\"quarantine_policy\":\"ISE_quarantine_policy\"}",
533. "tot": "json"
534. }
535. ],
536. "active": true,
537. "x": 250,
538. "y": 100,
539. "wires": []
540. },
541. {
542. "id": "2500153e.3895ca",
543. "type": "comment",
544. "z": "454f293f.10a098",
545. "name": "MANDATORY STEP: Update ISE Policy to ePO Tag Mapping",
546. "info": " This node \n contains a mapping that maps between the ISE policy name and the \n corresponding tag name within ePO (see below).\n\n```javascript\n{\n \"shut_down_policy\": \"ISE_shut_down_policy\",\n \"port_bounce_policy\": \"ISE_port_bounce_policy\",\n \"quarantine_policy\": \"ISE_quarantine_policy\"\n}\n```\n\nThis mapping should be updated to reflect your Cisco ISE ANC policy names and corresponding tag\nnames within ePO. Each of the ePO tag names must be created within ePO (they \nare not automatically created).\n",
547. "x": 240,
548. "y": 60,
549. "wires": []
550. }
551. ]

Display More

Display More

No problem, glad to hear it is working.

Thanks,

Chris

Yeah, that is definitely worth a shot. I updated the basic service sample (see code below) included with the client to allow for setting the number of services to register. With the latest version of the client I am able to register all of the services consistently (without any deadlocks).

Thanks,

Chris

Ok, thanks.

I am thinking at this point it might be an issue with the Python Client as there were some recent changes related to subscriptions locking. What version of the client are you using?

Thanks,

Chris

Odd, not sure what is happening. Can you please try the following:

For the "external" entry, replace 127.0.0.1 with the actual IP address of that host. 127.0.0.1 is referring to the container itself.

Also, remove the "local" line altogether.

So, the brokers section should appear as follows (with the host IP address being the actual IP address of the Docker host system):

Thanks,

Chris