-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Discuss] provide action whitelist information to UI clients #51784
Comments
Pinging @elastic/kibana-stack-services (Team:Stack Services) |
I suppose there are some security considerations as well. Should we really even be exposing the whitelist as an API as this issue suggests? My gut says this isn't a security issue with this, but I would't bet any money that my gut is right ... |
There are a few issues this addresses, summarizing some of the discussions to date:
Overall we want to balance easy-setup with ability-to-secure.
|
Peter's suggestion in the comment above makes sense to me. Only worried about the default being '*', think it we should note this behavior in general setup and/or security docs. And we'd need to document the "known" hosts for PagerDuty, Slack, etc. |
Would be curious to get @elastic/kibana-security thoughts on the proposal to whitelist all hosts for actions, and rely on feature controls to restrict access to actions created. |
I'm hesitant for us to whitelist all hosts for actions, and release functionality that takes advantage of it in a minor version upgrade. Actions can be abused to perform a SSRF, which depends on the specifics of the actions for how unconstrained this is and what an attacker can do. A considerably large number of users will be authorized to create actions because it's quite common for roles to use the base privileges which will grant access to all current and future features, therefore allowing them to create actions. |
The equivalent watcher setting https://www.elastic.co/guide/en/elasticsearch/reference/7.4/notification-settings.html
|
I think webhook is probably the only one prone to SSRF? email, slack, pagerduty, log, indexing are not zero-risk, but at least they are not open ended. If we're primarily worried about SSRF and webhook, what if we turn off webhook by default, and document how to properly secure it before enabling? I would rather do that than force all users to configure the whitelist in order to use actions. I think there are other options like giving base-privielge users read-only access to actions until 8.0, but that also involves an additional setup step and does nothing to mitigate risk after 8.0. |
I think this really depends on the environment in which Kibana is running, and the particulars of the way the actions are implemented. Kibana is used in countless network topologies with any possibility of internal services being available. With regard to e-mail, Kibana could access an internal SMTP server which allows spoofing the from address which could be used in a phishing attack. If the SMTP server includes the originating |
That is a great start. Webhook is a more dangerous action than others since it allows arbitrary urls and bodies, whereas the other actions typically have "fixed" sets of urls and bodies. Email is likely the next most dangerous, but for that I think that auto-whitelisting the existing nodemailer "well-defined" service hosts would be safe-ish. So what about then a config
The "aggravation" factor here comes from having to restart Kibana to pick up new settings. If I understand correctly, NP plugins can be sensitive to config changes "live" as opposed to just via restarting Kibana. In that world, you probably want a single |
That "richer" set of config in the comment ^^^ is smelling a bit rich to me this morning, and doesn't capture all the secure + least-aggravating cases anyway. Thinking we just go with the original single |
Will the single |
Currently If we want to allow whitelisting the well-known email hosts, for the email action, I think we'd want a separate setting, kinda independent of
|
OK, it seems like I agree with @pmuellr then, lets go forward with I think the That brings things back to @pmuellr original concern: given we have a blank whitelist - which means no actions other than logging and indexing are allowed out-of-the box - what APIs can we provide that can show an action's whitelist status to users? Perhaps a validation API? At least then the affected actions (webhook, email, slack, pagerduty ...) can check against the whitelist proactively when the action is being set up display a warning/messaging before someone clicks the 'save' button and gets an error. |
With our server-side CRUD apis, you'll get whitelisting validation on C and U, but not R nor D, which makes sense. A message will get returned from the create/update request, indicating that the relevant server is not in the whitelist (message could be improved from what they are today though). And then also when an action that was previously created, and passed whitelist validation, but since then, the whitelist has changed to not allow that server, and then the action is executed, it will also fail the validation. An error message returned with appropriate messaging (need to check that we do this, but pretty sure we do). That's all server-side. If we want the client to be able to make intelligent decisions re: whitelisting without waiting for the create/update http requests to fail, it will need to somehow get the whitelist information, and interpret it. I think we could eventually make this happen, don't think it's required immediately tho. |
For an example of what a whitelisting error might look like in a UI, see the following (which isn't a whitelisting error, but an execution time error with bad user/password, same kind of situation though) - #49219 (comment) Note, the conversation there is leading to extending the error information returned from action execution, not sure if extending error info for CRUD operations will be required. |
It's mostly the client experience I'm worried about. My concern is UI gives people the impression they can create actions, all the way up through configuring a connector, only to have them click 'save' and get an error message. The error message tells them to edit kibana.yml, whitelist, restart the server and try again. And that's in the best case assuming they have access to kibana.yml and the opportunity to restart. As a user you have been "set up to fail". If we allow no hosts by default, I think the 'least-worst' experience would be:
Say I now have a whitelist setup, and slack, pagerduty, webhook and email are now options.
|
cc @mdefazio , perhaps there are better ways to mitigate the impact on the user experience. |
Elasticsearch has the concept of "production mode" vs "dev mode" that they use for their bootstrap checks. If we could figure out a way to differentiate between "production mode" and "dev mode" for Kibana, perhaps we could provide a looser default whitelist in "dev mode"? I haven't been able to think of a great way to differentiate between "production mode" and "dev mode" for Kibana though... This is what Elasticsearch does:
One idea I had was to treat Kibana as being in production mode when |
I think we need to provide something more out-of-the-box than an empty whitelist array, specifically thinking about the email action. In the stack monitoring PR for alerting, we have a dropdown for selecting a known nodemailer email service - it feels like an extremely awkward situation to allow the user to select one of these specific services and then tell them later they can't create the email action because they need to whitelist one of these known email services hosts (which requires access and edits to the kibana config file). I don't know the right answer on the security side of things, but this empty whitelist (especially in regards to email actions) feels like a step backwards for the user. |
Design request would be to start with I'd go so far as to recommend that we set it as Main preference beyond that would be to make whitelists configurable through the UI so we could handle all this during an initial Kibana setup screen. Barring those options, the only way to solve this is by disabling portions of the UI and providing callouts in a bunch of places that link over to documentation, which we can do, but it won't be elegant. |
I dunno, that sounds equally aggravating :-) Let me riff a little on changing the whitelist to changes:
|
Updating the status here after internal discussions: Let's move forward assuming the whitelist will be empty by default at least for 7.6. This is the most secure scenario and we should design and code for it, regardless of what the default ultimately is. I think @pmuellr suggested changes above all make sense regardless of the default. In the meantime I'll review the options with the elastic security team for 7.x, as there needs to be a security discussion for other deployment scenarios like ESS. I still think there's room to satisfy both security and usability concerns, but security must be on board before we relax the whitelist. |
The whitelist conversation here has pretty much died down, so I'm going to close it. I've opened a new umbrella issue for actions whitelisting for Kibana 7.6 - #52595 We can use that for further discussion, or in the individual issues in it's task list. |
Currently actions have a plugin configuration that allows customers to provide a list of white-listed hostnames that can be used to access 3rd party services. Currently only webhooks makes use of this, but there's a PR to add whitelisting support for email as well. Slack and Pagerduty are considered "whitelisted by default" for now, for their respective actions.
Unfortunately, we don't have a way of exposing this to the UI at present, though it's possible that it could be passed through via "injected vars" (or the NP equivalent, when we move actions to NP).
But there's another wrinkle with emails. When configuring an email action, you can provide EITHER a host/port, or a "well known service name" (as defined by the nodemailer plugin). The UI won't have access to the nodemailer well known service name list either, nor what hosts those service names end up being dereferenced to. And ... you could imagine a UI that would show all the email services possible, with an indicator of which are whitelisted and which aren't.
Again, it's possible we could somehow get this info into the client via an injected vars type scheme, but I'm wondering if an explicit API to handle this might be the best route. This could then be used by other clients that didn't have special access to the Kibana inner bits that the alerting UI will have.
This would presumably be a
GET /api/action/whitelist-info
sort of API (just read, no update), that would provide the whitelisted hosts, and perhaps a list of whitelisted email services, and perhaps a list of all the potential email services (including those not whitelisted). Probably design it so that we could add a peer ofemail
(say, issue tracking services) in the future.We're currently thinking some kind of link to some help describing the service names, and how to add entries to the whitelist, near any UI that would let a customer enter a email host/service may be good enough for now, not certainly not ideal.
The text was updated successfully, but these errors were encountered: