1 of 1 people found this helpful
- Always use Multi-Factor Authentication. Unauthorized people must NEVER be able to access your SolarWinds environment.
- Create a Remote Access environment that allows authorized people to go to a web site that uses something like the Citrix Secure Gateway's Virtual Desktop and an F5 Portal.
- The CSG provides isolation from anything on their computers and it relies on Active Directory and MFA for access.
- The F5 Portal allows you to present users with as many remotely accessible resources as you wish (e.g.: A virtual desktop, O365, e-mail, customer-specific applications, a Web Browser, and more). Let them use the virtual desktop to open a web browser to your SolarWinds environment.
We don't allow staff or customers to VPN into us for SolarWinds access anymore unless they use our MFA solution for VPN, and we encourage them to use the Virtual Desktop Portal instead of VPN.
Anything else is insecure.
Thanks for the recommendations.
but what if the customer is not using the Citrix VDI or F5 products??
Also, my concern is not related to the access to the Solarwinds server itself. The Solarwinds access is through AD, so that is not an issue.
My problem is when I get the alerts, I have the direct links to that alerts in Solarwinds WebGUI. When I click the link, it will redirect me to the Solarwinds WebGUI, but I don't see the web page. My connection times out and I get the error saying "This page can't be reached"
You'll have to provide a virtual desktop environment to give secure access into your internal network for SW access--or do without, apparently.
Sure, you could write a firewall rule that would allow you direct access from a specific IP address into your network, and have it redirect to the NPM home page. But from there the rule would also have to allow all the subpages of SolarWinds.
I bet others have alternate suggestions, but a secure portal or an AnyConnect clientless connection, either using MFA, is the only way to go.
The problem I find using a smart phone to remotely access anything SolarWinds is the scale is too small. I work around that by modifying my alerts so they include more than the basic data--they must include enough data for me to make decisions and act on what I see in my Inbox without having to remotely access SolarWinds. Things I include in alerts include, but are not limited to:
- Node Name
- Interface Name
- Time stamp
- Node IP address
- SolarWinds polling engine monitoring the node or interface
- System Location (from the switch or router or UPS)
- Condition--this goes right into the subject of e-mailed alerts, and is a huge time saver. Some examples
- ALERT: <node name redacted for security> rebooted at Tuesday, January 8, 2019 12:07 PM
- Node Up (or Node Down) <node name redacted for security> at <IP address redacted for security> Tuesday, November 27, 2018 10:15 AM
- ALERT: Stack Ring Broken on <node name redacted for security>
The sky's the limit for the useful information you put into an alert's subject line, and it makes it so I don't even have to open the e-mail to know what's going on. This helps me avoid needing to remote into work to discover the network's condition and to be able to talk intelligently about the situation with my peers and support staff.
To get to your specific point about changing the URL that comes across in the email alerts, see this KB article
I second the other recommendations to be very careful about exposing the orion server itself to the public internet without at least passing it through some kind of DMZ/proxy.
The polling engines will have typically holes punched through all your ACL's so if it were compromised in any way it has extremely wide reach, not to mention having a mountain of information regarding the structure of the environment, and saved credentials that could be potentially hijacked if someone were to gain access to the server, it's often white listed from many types security alerts since it is not unusual for the Orion server to be doing things like port scans and reaching into servers and network gear all over the place. It is the ideal recon and attack location if it were to be compromised through something like an unknown bug in Orion itself or something in IIS. There is a reason that DMZ's are a standard part of the security layers for organizations that present public facing websites.
They need to fix this. This issue with putting in the website URL is that many of the built-in health checks fail because it thinks that URL is a real server and is missing services.
3 of 3 people found this helpful
While there's nothing (that I can see) that would stop your configuration from working, a better (more robust) way to do it is to use the Additional Web Server. This server (which can be a VM) exists anywhere on your network (including in a DMZ) and uses minimal ports to connect back to the primary poller on the "inside" of your environment.
Alerts will need to be slightly modified to point to this server, but once you do, the links will send the recipient to the AWE rather than the primary poller.
Let me know if I'm on the right track here.
Can you guys fix this: Configure website URL for Alerts and Reports - SolarWinds Worldwide, LLC. Help and Support
If you use this to configure your URL for a load balancer, then the health check on "My Orion Deployment" fail because it thinks that URL is a real server and can't find the services running on it.
If you use Azure AD you can setup an Azure AD app proxy. Very easy and not additional network configuration is required.
I know I had one client who was setting that AD proxy up while i was working with them. He had said he got it working as far as a POC but I never sat down with him to see all the details.
To be fair I haven't done a lot of in depth testing, but it does work. Also if you have Azure MFA turned on it requires you to use MFA to login before you launch the web app.
MFA has proven fast and reliable for my organization (so far). I rely on it for ALL external access into my organization and it hasn't let me down since implementing it over a year ago.
hpatelow what you have configured should work fine. I have a single Orion server set up with a NAT to an external ip address. Port 443 (https) is allowed through the firewall. Make sure you use the same FQDN for internal and external DNS. Then go to Settings->All Settings->Web Console Settings and set your Orion Web Server Address to the FQDN.
Let me know if you have any questions and I'll try to answer them.
We have 2 additional web servers and load balance then with an F5 load balancer to give access to SolarWinds. We secure it with the load balancer. About to put DUO on it for 2-factor auth.