I have searched the available documentation, but I can’t find any description on how to make the audit data (in my case in syslog) readable for the purpose of detecting which signed key is generated by who. Can you please point me to either the documentation where this is explained, or a blogpost? If there isn’t such a thing, I am happy to create that blogpost if it’s explained to me how it’s done.
I have also been frustrated by this. I found some info around disabling hmac of specific values but either I have the path wrong or it doesn’t work as expected.
vault write /sys/config/auditing/request-headers/accessor hmac=false
I ended up configuring the audit log with raw_log=true for debugging in my lab. https://www.vaultproject.io/docs/audit/syslog.html#log_raw
If you figure out how to selectively disable hmac on things please do share.
Blake
That’s exactly what I have done too; I set raw_log=true, because if I can’t read/use the audit data, it simply doesn’t make sense.
This clearly hints that there must be something that can make these hashes readable, and thus the audit being usable, but currently I haven’t found anything that does or helps with that. Please hashicorp, tell us how this works and what the idea is here!
To selectively disable hashing of request or response fields in audit data, you need to tune the appropriate mount(s) with the audit_non_hmac_request_keys or audit_non_hmac_response_keys settings. See tune API docs.
Alternatively, you can leave it hashed and use the audit-hash API to work out what the hash for a given string is, and search for that.
1 Like
Thank you Nick for your response.
The point for me for the auditing is to have an administration who signed which key, so I would say that I want the audit data available in case I need to look it up, so partial disabled hashing does not sound like a solution to me.
It might be me, but the documentation for the audit-hash API is not enough for me to work out a workflow (if any, that is not even clear to me) for “unhashing” the hashes in case I need to find an audit record.
Or isn’t that the purpose, and does it mean that if I need audit records to be searchable and available, I need to leave them unhashed as I do currently?
The audit-hash API does not allow for unhashing anything. Let’s say you found that one of your users (“Joe”) has his credentials stolen, and now you want to determine what the attacker might have done with them. Using the audit-hash endpoint you ask for the hashed version of “Joe” and then search the hashed audit log for that.
What field(s) are you using in the audit log to determine who generated a signed key?
the workflow that I currently use is:
- look up the serial of the signed key in data of the /var/log/secure file.
- transform the serial to hexadecimal.
- search for the serial in the audit logfile on the vault server.
- determine user identity based on the certificate that is used to authenticate.
that means that I need time, certificate metadata and response serial to get all data I think I currently need.
For response serial you would tune the pki mount to give it audit_non_hmac_response_keys = ["serial_number"]. As to the certificate metadata: can you give me an example excerpt from your audit log (with sensitive data scrubbed if you’ve still got hashing disabled)?
I got a lab setup, so there are is no data that is considered sensitive.
For (authorization) certificate metadata: this is how that looks like:
“auth”: {
“client_token”: “s.yr6lGhRxwK8ySc4cgEC6HBIi”,
“accessor”: “w4Q5bVyabJ9c3hfgeG1gdyuS”,
“display_name”: “cert-Test User”,
“policies”: [
“default”,
“policy_ssh-client”
],
“token_policies”: [
“default”,
“policy_ssh-client”
],
“metadata”: {
“authority_key_id”: “f5:02:c8:54:6b:bd:36:66:1f:55:d2:4d:60:a8:0c:d0:19:32:e0:bb”,
“cert_name”: “test_user”,
“common_name”: “testuser”,
“serial_number”: “12954687727334453172”,
“subject_key_id”: “f5:02:c8:54:6b:bd:36:66:1f:55:d2:4d:60:a8:0c:d0:19:32:e0:bb”
},
“entity_id”: “64cd1dd1-f94e-6370-8f8d-bc9ae68babf3”,
“token_type”: “service”
},
The metadata and serial are used to identify the certificate/user.
When I remove raw logging, this the auth.metadata is still visible.
I tuned the ssh mount with:
vault secrets tune -audit-non-hmac-response-keys=serial_number ssh-client/
And now the serial is readable in the audit, and the signed key isn’t, so a possible steal of the signed key via the audit log is not possible anymore.
This should be enough information for me to have vault provide me enough information to audit, but not spill excess information which would allow a reader to use that.
Is obfuscating sensitive information, and enabling the needed information the actual idea of the obfuscation? It might be obvious once you get your head around it, but it’s quite abstract when you’re learning it.
Is a hash (for example for signed_key in the response) de-hashable at will? Can you give an example of how to do that?
Is obfuscating sensitive information, and enabling the needed information the actual idea of the obfuscation?
Yes. We err on the side of caution and hash basically everything, and allow people to exclude items from hashing if they feel it’s needed and not excessively risky.
Is a hash (for example for signed_key in the response) de-hashable at will? Can you give an example of how to do that?
No, there’s no way to de-hash. The only option is the one I explained earlier in the thread: we provide the audit-hash API which lets you hash a known value (e.g. one of your user names) in order to get a hashed string you can search for.
Hey! Would you mind sharing your commands to achieve the following?
search for the serial in the audit logfile on the vault server.