Orion URLs for Firewall Whitelisting

There are significant advantages to having Orion able to access the Internet, however the last few days have shown that blanket access is not the best security stance to have.

I have collated the following list of URL's with my fellow MVP's assistance in order to help you put whitelist entries in to your firewall policies to give controlled external resource access to Orion.

I have broken these into categories, as some are module specific, and clearly you have the choice to replace many of these with a *.solarwinds.com, but I wanted to provide the full URL list for those that wish to be granular in their ruleset.

Function URL Detail
Core

https://downloads.solarwinds.com
https://api.solarwinds.com
https://installer.solarwinds.com
https://licenseserver.solarwinds.com
https://licensestatusserver.solarwinds.com
https://www.solarwinds.com
https://documentation.solarwinds.com
https://www.documentation.solarwinds.com
https://customerportal.solarwinds.com
static.solarwinds.com

These will allow centralised upgrades and license registrations to be performed
Core - THWACK 

http(s)://thwackfeeds.solarwinds.com
http(s)://thwack.api.solarwinds.com

To allow display of THWACK feeds in widgets and direct import/export of templates
Core - WorldWide Map

http://open.mapquestapi.com/
https://api.openstreetmap.org/

For rendering the Worldwide map and for performing Geo lookups from SNMP data
NCM

https://nvd.nist.gov/feeds/json/cve/1.1
https://nvd.nist.gov/feeds/json/cpematch/1.0

Configuration Vulnerability Analysis
NCM

https://wsgx.cisco.com 

Cisco Smart Advisor
SAM

https://api.dell.com
https://support.hpe.com
https://*.ibm.com
https://supportapi.lenovo.com
http://support.lenovo.com

SAM hardware warranty lookups
Alerting (ServiceNow integration) https://<API-SubDomain>.service-now.com

If using ServiceNow alert integration. Replace API-SubDomain with your configured API URL

Add your own HelpDesk API URLS if you are using the GET/POST to URL or script actions to integrate your alerts

Alerting (SolarWinds Service Desk integration)

https://api.samanage.com (for non-EU customers)
https://apieu.samanage.com (for EU customers)

SolarWinds Service Desk Integration

Cloud Monitoring AWS

https://amazonaws.com
https://aws.amazon.com
autoscaling.*.amazonaws.com

https://*.awsstatic.com
https://*.amazontrust.com
https://ec2.*.amazonaws.com
https://events.*.amazonaws.com
monitoring.*.amazonaws.com
thwack-static.s3.amazonaws.com
thwack-admin.thwack-apps.solarwinds.com

Azure
https://login.microsoftonline.com
https://management.azure.com
https://management.core.windows.net

 

For monitoring AWS and Azure clouds in Orion core. List was taken from this previous post
Meraki

https://dashboard.meraki.com
https://api.meraki.com

For polling your Meraki infrastructure via central cloud management platform
NetPath

https://stat.ripe.net

Used to perform BGP data lookups
AppOptics

http://my.appoptics.com
https://my.appoptics.com
https://api.appoptics.com

If you have the integration to the SolarWinds AppOptics SaaS APM solution
Discovery Agent

https://opendns.com (to obtain external IP)
https://agt.samanage.com (for non-EU customers)
https://agteu.samanage.com (for EU customers)

SolarWinds Service Desk Discovery Agent for SolarWinds Orion

You will also need to be conscious of the monitoring targets you configure in Orion and add those to your whitelist policy, where for example in SAM, if you wish to monitor your Salesforce instance via HTTPS monitors in WPM or SAM, add your Salesforce FQDN, to monitor O365 then https://*.office365.com and https://ps.outlook.com would be necessary. Ensure you bake your whitelist updates into your monitoring definition process.

If I have missed anything here, then please let me know via the comments, and I will update.

  •  Firstly, I have never come across a web filters solution that cannot support hostnames for whitelist and this is a perfect example of why that should be the case. DNS poisoning issues can be dealt with by the security device having its own DNS server settings and protections.

    However, if this is the case then you will have to research the IP blocks owned by the domains and use those, which you will need to either monitor for change or script to auto update the firewall.

  • That would be VMware NSX-V Distributed Firewall, or so I am told by our team that provide me a VM to host Solarwinds onto.

    I can't agree with the reasoning DNS would protect me against DNS Poisoning, especially when the current rule set only allows communication with Solarwinds controlled/owned IP space.  Regardless, it would be a much more desirable position to simply have a ruleset that just allows the above URL list.

    It's something I need to follow up and do some reading into myself on NSX-V, as it's not my area of day to day responsibility and lack the time to do so, I'll take their word for it for now.

  • Thanks for this list. This is exactly what I was hoping to find.

  • Guys, please help. Can't download shared templates from thwack:

    thwack1.JPG
    Which exact IP we must add to our allow list?
    This one is already in the list, but still cant reach thwack share:

    THWACK

    https://thwack.com

    74.115.13.195

    UPDATE: there resources are also need to be whitelisted:

    74.115.13.122 (thwackfeeds.solarwinds.com)

    104.27.150.17 (twhack.com)

    74.115.13.97 (thwack.api.solarwinds.com)

    99.84.233.181 (thwack.solarwinds.com)

    99.83.191.119 (thwackfeeds.solawinds.com)

  • Has anyone had any luck with getting their O365 / Azure monitored services showing up again after blocking Orion's access to the internet?

    We permitted the respective domains, but I'm still having trouble getting the scripts monitoring our Sharepoint online and Azure database instances to run. Fails with "unable to connect to remote server", but I have confirmed Orion can contact "login.microsoftonline.com", "portal.azure.com" and our Sharepoint site "Company1.sharepoint.com". Not sure where or what else might need to be permitted?

    Edit: Apparently this just needed time...even after initiating a "poll now". Also needed to permit graph.microsoft.com for our Sharepoint scripts.

    Edit 2: I take back my previous edit. The monitored application is still in an unknown state and tells me that it's "unable to connect to remote server". Not sure what else could need permitted at this point. 

  • Anyone having issues with scheduled reports after applying Firewall Whitelisting?

    The scheduled report runs successfully but for those that include a chart the chart data is missing in the PDF that is received, all other data including a Custom Table appears as expected.

    grizzlyferrett_0-1610619477922.png

    If I run the same report through the web console all data is displayed as expected.

  • What about sftpsupport.solarwinds.com for uploading diagnostics?

    Customerportal needed for anything?

    In the Core above, do those URLs include what is necessary to populate the updates available in "My Orion Deployment"?

    Kevin

  •   if you are uploading directly from the Orion server, then yes you will need to add the file upload URL's to your whitelist. Note that with the ability to generate diags via the Orion web UI now, downloading them to your local PC then uploading may be used.

    Yes, the 'Core' URL's above should allow your Orion to be managed via My Orion Deployment for upgrades.

     What happens when you view the Orion web page the scheduled report is from via a browser on the Orion primary server, do you get the same issues?

  • When viewing from the Orion Web Page the report appears as I would expect with data in the charts. Its only when the report is scheduled to run and email the report that the data is missing from the chart.

    Since the Security Incident we now block all Outbound HTTP and HTTPS traffic from our SolarWinds environment unless we can determine the destination, the change in functionality of the scheduled reports ties in with this change.