Rest connection to Tenable.SC errors with invalid/unreachabe endpoint

[Sean]

Unable to find a solution for this in discuss so I thought I would ask. I am not entirely sure what information to provide since I am new to both InsightConnect and to Discuss so I am trying to include anything that might be relevant to the issue I am asking for help with. If there is any information I am leaving out, please let me know and sorry for the long post.

I have a workflow that I am building with the goal of creating tickets in ServiceNow for Vulns discovered by Tenable.SC that use trigger from MS Teams. The end game is that we would have a command in Teams that includes the server name and any plugin ids for vulns we want patched. The workflow will create a ticket per-plugin in ServiceNow. The trigger will eventually be !vuln_ticket_sc <server FQDN|IP to be patched> …

The issue i am running into is that when I kick the workflow off from Teams, it fails stating ‘Invalid or unreachable endpoint provided.’.

The entire error message is:

Connect: Configuring REST details
Connect: Connecting…
rapid7/HTTP Requests:6.0.7. Step name: get
Plugin exception instantiated. cause=‘Invalid or unreachable endpoint provided.’, assistance=‘Verify the URLs or endpoints in your configuration are correct.’, data='

404 Not Found

Not Found

The requested URL was not found on this server.

', preset='not_found' An error occurred during plugin execution!

Invalid or unreachable endpoint provided. Verify the URLs or endpoints in your configuration are correct. Response was:

404 Not Found

Not Found

The requested URL was not found on this server.

Traceback (most recent call last): File "/usr/local/lib/python3.9/site-packages/insightconnect_plugin_runtime-5.4.4-py3.9.egg/insightconnect_plugin_runtime/plugin.py", line 413, in handle_step output = self.start_step( File "/usr/local/lib/python3.9/site-packages/insightconnect_plugin_runtime-5.4.4-py3.9.egg/insightconnect_plugin_runtime/plugin.py", line 616, in start_step output = func(params) File "/usr/local/lib/python3.9/site-packages/rest_rapid7_plugin-6.0.7-py3.9.egg/komand_rest/actions/get/action.py", line 23, in run response = self.connection.api.call_api(method="GET", path=path, data=data, headers=headers) File "/usr/local/lib/python3.9/site-packages/rest_rapid7_plugin-6.0.7-py3.9.egg/komand_rest/util/util.py", line 249, in call_api return self.response_handler(response) File "/usr/local/lib/python3.9/site-packages/rest_rapid7_plugin-6.0.7-py3.9.egg/komand_rest/util/util.py", line 199, in response_handler raise PluginException(preset=PluginException.Preset.NOT_FOUND, data=response.text) insightconnect_plugin_runtime.exceptions.PluginException: An error occurred during plugin execution!

Invalid or unreachable endpoint provided. Verify the URLs or endpoints in your configuration are correct. Response was:

404 Not Found

Not Found

The requested URL was not found on this server.

As of now, I removed all of the complexity and whittled the workflow down to a very basic workflow in the hopes of making it easier to troubleshoot this part.

The HTTP Request connection is setup using the current version 6.0.7 and is working:

I have the connection for Tenable.SC setup (using on premises orchestrator) setup to use the base URL of https://<tenable.sc URL>/rest and, for now, the route in the rest action hardcoded as /plugin/155250. This way the request is using the URI of https://<tenable.sc URL>/rest/plugin/155250.
I have verified with Postman that the URI returns valid data as well as logging into the orchestrator and using curl and verified valid data is returned. Side note: Hardcoding the plugin id is only being done for testing, if I can get this working, then I will replace the plugin value I put in with a variable.

I found that I have to delete the rest action when I make changes to it otherwise, I get errors that the keys are invalid. I will be submitting a support request for that issue.

I have done the following:

1. verified the HTTP connection works, i have the base route set with https://<tenable.sc server fqdn>/rest/plugin
2. set the route to be appended in the rest action as /166250 (with plans to replace it with a variable)
3. set the route to be appended in the rest action as {/166250}
4. set the route to be appended in the rest action as {{/166250}}
5. set the route to be appended in the rest action as blank as it would return all plugins
6. confirmed that I can get data from our Tenable.SC server using Postman
7. confirmed that I can get data from our Tenable.SC by remoting into our orchestrator and running using curl
8. recreated the HTTP connection

At this point I feel like I am out of options of what I could try. As I mentioned in the beginning, I am new to InsightConnect so I will not be offended if I am told I am doing it wrong.

Thanks in advance.

[Eric-Wilson]

While it’s good to test a curl from the orchestrator, ultimately actions run within docker containers on a different network. It almost seems like your docker action can’t reach the correct endpoint. Perhaps there could be a conflict between the docker network and your internal network. Per default, Docker CE is using the subnet 172.17. 0.0/16 to assign IP addresses to containers and Docker networks. Sometimes, this network is already in use by other services. Likewise, docker defaults to the /etc/resolv.conf to get DNS servers. If none is provided it will default 1.1.1.1 so it may be best to check this file as well.

If neither of these is the case in your environment it may be best to submit a support case to get down to the bottom of this.

[brandon_mcclure]

can you provide a screen shot of your connection (just the Base URL) and you REST step (Just the Route)
Eric is correct, the REST step is python requests inside a docker container, if you are using a proxy that will need forwarded to the container. But python sometimes does weird things between the base URL and the route that could pass a test, but fail in a step.

[Sean]

Thank you for the advice Eric!

I confirmed that we do not have a 172.17. 0.0/16 network. As for the resolve.conf, I checked the one that lives on the server itself, not docker. I confirmed that we do have entries for our DNS servers as well as a search entry for our domain.

I am not well versed in docker so if I have to check a resolve.conf file for that, I will need to go to support or spend time searching.

[Sean]

Sure thing:

Connection:

Route in rest step:

One thing I did notice is that the headers in the rest step are {}. I confirmed that the input is not getting {}:

Since I have already found what I suspect to be a separate issue with the HTTP connection, I am wondering if I should try the version before 6.0.7.

[brandon_mcclure]

that is what I thought.
Try removing the /rest/plugin from the base url and append it to the begging of the route. I think I had that issue before
for me, I keep base url as domain name and port, then everything else goes in the route

[Sean]

That resolved the issue. Thank you! Here I thought I was being smart by including the /rest/plugin in the connection since it would always be the base. Hopefully using variables will work!

Thank you for your help! I am glad it was something I was doing and not an issue with the plug-in.

[brandon_mcclure]

I only knew, because I did the same thing