Let's ship mail logs from the MX servers to ELK.
There we can build visualizations, monitor trends, report on envelope details, etc.
Let's ship mail logs from the MX servers to ELK.
There we can build visualizations, monitor trends, report on envelope details, etc.
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Open | None | T370005 Email improvements round two (FY 2024/25) | |||
Open | None | T197171 Graph outbound mail volume on per-service or hostgroup level | |||
Resolved | fgiunchedi | T205849 Begin the implementation of Q1's Logging Infrastructure design (2018-19 Q2 Goal) | |||
Resolved | fgiunchedi | T205855 Investigate approaches to ingest sensitive log producers | |||
Resolved | fgiunchedi | T213157 Increase utilization of application logging pipeline (FY2018-2019 Q3 TEC6) | |||
Resolved | fgiunchedi | T220103 TEC6: Logging infrastructure (Q4 2018/19 goal) | |||
Open | colewhite | T213902 Implement sensitive logstash access control | |||
Open | None | T197173 Ship MX logs to ELK |
Our email logs can be pretty sensitive, especially since they include our corporate emails passing through (senders, recipients, timestamps etc.).
So, I'm a bit concerned about both whether our access controls are sufficient, and also whether the security of this platform is good enough to protect us against privilege escalation attacks.
Is this something that has been considered already? I'm not objecting this per se -- I'd just like for this to be carefully planned and reviewed because of the sensitivity of this particular log stream :)
That makes sense, and likely applies to other types of logs as well. It seems to me like something worth solving in the ELK stack.
Do we have an X-Pack subscription from elastic? If so we could use that to configure role based acls and segment access to various types of logs based on ldap group membership natively in Elasticsearch and Kibana.
If not, another potential approach is to...
Today we have Logstash outputting to Elasticsearch indices prefixed with logstash- and Kibana is configured to query logstash-*. We could change the prefix something like logstash-all- for unprivileged logs, and logstash-root- for "root only" logs.
IIRC each Kibana instance has it's own ES index for config storage, meaning visualizations, dashboards, etc would not kept in sync between two instances with differing search prefix configs. So that's a compromise to think about when separating log access this way. Maybe there's a way around it. Worst case these could be exported/imported between instances.