rabbitmqctl authenticate_user is not being logged in rabbitmq-diagnostics consume_event_stream

[simplepad]

Describe the bug

rabbitmqctl authenticate_user is not being logged in rabbitmq-diagnostics consume_event_stream

Reproduction steps

1. set up rabbitmq in a docker (latest)
2. execute rabbitmq-diagnostics consume_event_stream --pattern user.* and leave it running
3. execute rabbitmqctl add_user testuser and rabbitmqctl authenticate_user testuser
4. check the output of the command from step 2

Expected behavior

both commands from step 3 produce events

Additional context

actual:
only the add_user command produces an event, while authentication attemps are not getting logged at all (both successful and unsuccessful)

[michaelklishin]

@simplepad I'm not sure why you expect rabbitmqctl authenticate_user to produce internal events.

That command is nothing more than a troubleshooting tool. It is not a client connection and after authenticating, it cannot publish, consume, or modify the schema. Therefore it does not generate any internal events.

[michaelklishin]

@simplepad I completely fail to see why you consider rabbitmq add_user (a command that, in combination with granted permissions, can allow a client to connect) and rabbitmqctl authenticate_user (a troubleshooting helper that does not create a connection) to be comparable.

[simplepad]

Oh, thank you so much for the explanation! I was testing the internal event logger and expected the rabbitmqctl authenticate_user to produce a user.authentication.success or user.authentication.failure management events, so I was puzzled as to why it didn't give me any logs. If that command doesn't create a connection, it is logical that no events will appear there.

[michaelklishin]

To be clear, authenticate_user does contact the node using the CLI/internode communication mechanism. But it is not a client connection, so it leaves no usual traces.

[michaelklishin]

One more thing worth mentioning: if someone has access to rabbitmqctl and can run rabbitmqctl authenticate_user, they will also be able to run rabbitmqctl change_password and such.

Therefore repeated authentication_user calls make no sense as an attack tactic. The attacker would have enough permissions to change the password (assuming the internal authN backend is used, not LDAP , OAuth 2 or an external HTTPS-based service), so why bother with brute force iteration.