Feasibility of audit logging cqlsh exits

[dguymon]

Hello,

Greatly appreciate the ecAudit plugin, which has been helpful for us to meet many of the auditing requirements levied upon us on our older version of Cassandra while we work to upgrade Cassandra to the latest version.

Was wondering if you've had any success being able to capture cqlsh exit events? With Cassandra 2.2, I see how ecAudit effectively captures cqlsh authentication/login events, but looks like nothing gets captured for cqlsh exit events. This might actually be more of a missing feature in cqlsh or Cassandra?

Appreciate any insights or thoughts that you have on the idea!

Regards,

-Danny

[smiklosovic]

Hi @dguymon ,

I am not author of ecaudit, I am just asking ... why would you want to audit this in the first place? What is the use case? Why it is important to know when somebody exited a shell?

[eperott]

Hi @dguymon.

I'm also interested in scenarios for this. In particular, how would we want this to work considering one client can/will setup 1 or more connections to each Cassandra node in the cluster.

Assuming this is related to improved security, then I'm thinking this is something that would have to be implemented at the server side. If it is something that a client (such as cqlsh) could volunteer to do, then a hostile client could simply opt-out from triggering generation of audit log entry. Or worse, trigger generation of log-out audit entry and then continue to perform operations.

I'm not aware of any plug-in points in Cassandra code base which would allow ecAudit to get callbacks when a connection/session is closed, but there may be something that we could hook in to. Did you explore this? Would you be interested to contribute this feature to ecAudit?

[dguymon]

Hi @smiklosovic / @eperott ,

Thanks for posting back, some additional context is that our external security assessment team is referencing a general database STIG (in addition to the Cassandra-specific STIG) to verify that we're able to capture when a user/client disconnects from Cassandra either from cqlsh and/or database driver. We have to show evidence that this event is captured somewhere in a log file generated by either the Cassandra server or connecting client. The specific STIG rule is described here: https://www.stigviewer.com/stig/database_security_requirements_guide/2020-12-16/finding/V-206581

Yeah, based upon the attack vectors you're describing, I also think the implementation would probably have to be server-side and native to Cassandra as well. Haven't taken a look yet to see if there exists a plugin that does this (or if never versions of Cassandra natively capture and log this), but will go ahead and explore.

Will keep you guys posted on what I find and see if it's feasible to help implement in ecAudit.

Thanks,

-Danny

[dguymon]

Hi @smiklosovic / @eperott,

Spent some time playing with Cassandra 4.0 and it looks like it's baked-in audit_logging doesn't capture client disconnects (i.e. doesn't capture an exit command issued from a cqlsh session).

Given that, I'm willing to help out with implementation of the feature in ecAudit (if possible and if agreeable to your project's roadmap). Let me know what you guys think, if not in ecAudit, I can reach out to the Cassandra team for possible paths forward.

Thanks,

-Danny

[smiklosovic]

Hi @dguymon , I am a Cassandra committer so I can cover you here. Feel free to create an issue and so on ... you know the drill. I am dealing with a lot of audit logging recently anyway for 4.0. If we ever implement that, it will end up in 4.1, not in 4. So even we do this, it will take longer to appear there so you might maybe have it sooner in ecAudit if you are in a hurry.

[eperott]

@dguymon, I think this could be a valuable feature for ecAudit.

Long term I hope that features will align between ecAudit and Cassandra code base. Quickest way forward on your part may be to start in ecAudit.

Just to align on expectations: I believe the idea is to capture any scenario where a Cassandra replica determine a client connetion to be closed/broken, and then emit one audit record for this event. You agree?

I'm thinking that it should be possible to whitelist these kind of operations so that an operator can choose not to get these audit records (just as with any other kind of operation). I hope you can work out a proposal on how to manage this as well?

You may want to have a look in CONTRIBUTING.md to get started.

[dguymon]

Hi @eperott / @smiklosovic,

Thanks again for the replies. Spoke with my team again and sounds like we'll actually want to go with the ecAudit approach since one of the COTS products we use (Axway API Gateway) has only been tested up to Cassandra 3.X and our team will want Axway to go through their regression testing with Cassandra 4 before we try to integrate the two products in our environment. Additionally, looks like our timeline is to try to get something implemented by August of this year to meet customer deadlines.

@eperott, agreed on the audit event approach with one audit record per client connection close/break. Whitelist makes sense as well. I'll take a look at the contribution guidelines you sent and will circle back.

Thanks,

-Danny

[dguymon]

Hi @eperott,

Circling back as our team is currently starting work to explore possible solution approaches for our need for client disconnect audit logging. After looking through the ecAudit 2.2 and Cassandra 2.2 code bases, I think being able to get a handle on .close() within Cassandra's SimpleClient class could be a viable option, but I'm wrestling with how we'd actually be able to do so within ecAudit's code base. My mind takes me to an aspect-oriented programming approach, but I've only ever done that from within the target code base, and not necessarily from a plugin.

What are your thoughts on this? Are we barking up the wrong tree?

Thanks,

-Danny

[eperott]

Hepp!

The SimpleClient class seem to be a client, used for testing and such in the Cassandra code base. As ecAudit is a plug-in on the server side of things, I don't think this is the the place where we can integrate. (Though, I could be overlooking details here.)

At this point ecAudit is hooking in to Cassandra by implementing a few plug-in interfaces. Examples are the AuditQueryHandler and the AuditRoleManager. This way ecAudit specific implementation will get invoked which allow us to emit audit logs. I believe you have to explore Cassandra code base to see if there are any plug-in points related to client connections on the server-side which allow ecAudit to replace default implementation in Cassandra, or register for callbacks.

An aspect oriented programmig approach would perhaps allow ecAudit to pick and choose in more detail when to get invoked. However, I'm not sure if Cassandra itself provide a framework for this. If it does, please elaborate!

[dguymon]

Ok yeah that makes more sense, and I believe you're correct about the usage of SimpleClient after taking a closer look.

With the new understanding of ecAudit's plug-in approach, I'll take another look at the Cassandra code base to see if there's a possible solution that way.

Regarding the aspect-oriented approach, I've used AspectJ in the past to annotate various method calls that get "interrupted" in order to construct and generate audit logs, and then "resumed" once the audit log is written to a log file for out-of-band delivery. I don't believe Cassandra currently has the AOP dependency bundled up, so it would have to be an enhancement in Cassandra. (At that point, Cassandra could probably natively log client disconnects rather than implementing AOP).

I like your plug-in approach better, if possible, as I think it'll be simpler and hopefully not have to introduce an additional design pattern with AOP.

Thanks,

-Danny