Thanks for getting in touch! You are correct, we don't currently write any events to the audit log about authentication attempts/success/failure. We do write a warning message to the Octopus Server logs, but those are intended to be more informational.
At this point, the Audit Log in Octopus is all about recording successful actions which mutate the state of your world due to actions by authorized users. This would be the first set of events we'd start writing for anonymous users, and my concern about that is the potential impact of any anonymous user causing harm.
At this point in time we feel like we are taking a good, if conservative, approach to the problem, and see where we decide to go from there.
I'd be interested to understand if there is anything specific you would need beyond what we are planning to provide. :)
We're currently on 3.17.14. I understand that "When a user fails to authenticate for a certain number of times, the Octopus Server will rate-limit any future requests to authenticate as that user, until a certain time period expires. When this occurs a warning is written to the Octopus Server logs." How many login failures are required in order for this rate-limiting state to be reached? How long is the time expiry period? I want to re-create this scenario so I can verify the functionality and build automated tools to scan the Octopus log.
Hi Michael. What I’m trying to do is build a real world test to ensure that login failures are recorded in the Octopus log. According to the code below, my login activity should be rate limited after 2 consecutive failures and I should be banned after 9 consecutive failures. I’m not having any luck verifying that. I just attempted a moment ago to login to our web portal with my own username and the incorrect password. After 15 attempts, no record was logged in the Octopus log. And the following attempt using the correct password logged me in successfully. What can I do to verify that login failures are logged (even if it takes 9 or so consecutive failures to get there)?
Thanks for keeping in touch. I'll admit I'm a bit confused here too. I've just tested the login rate limiting and ban behaviour on Octopus 2018.2 and it's working as I'd expect.
I get rate limited after 2 failed attempts. I get banned after 10 failed attempts. This lines up with the tests I posted earlier. We haven't changed this code in a very long time (since Octopus 2.6.5) so I would be disappointed if it was broken in 3.17.14 - please let me know if this seems broken in the UI for you.
I've just checked about the logging. When login attempts are banned from a particular IP address we write a Warning into the Octopus Server log file. This has been in place since Octopus 2.6.5. We only added the equivalent audit entry in Octopus 2018.2.7.
Thanks for keeping in touch! This makes a lot more sense now! The rate limiting is only applied when you are using our built-in UsernamePasswordAuthenticationProvider - where Octopus takes care of your credentials and the entire end-to-end authentication flow.
That does make a lot more sense. I am finding the events in the Event Log now and that is excellent.
However now a new concern has been raised. I recall that Octopus is API-first so I would expect the same login failure events for an API call as I would for activity in the web portal. Unfortunately I’m not seeing these events. If a user tried to brute force a connection using an API key (or potentially started with a partial API key) they would not leave a footprint of activity for us to take action on. Do I have that right? Does that concern you?
Thanks for keeping in touch. I'm glad you made progress on the login events for Active Directory. The API Key authentication point you've raised has given us food for thought.
We are generally very cautious of implementing any rate-limiting in Octopus: we have a lot of customers who host Octopus behind HTTP proxy servers where the origin appears as the proxy server for every HTTP request.
The rate limiting for Username/Password authentication is keyed on the request origin IP address and the username. If someone is trying to brute force API key authentication we could only key on the origin's IP address.
At this point we are going to do some more investigation and thinking, and I'll get back to you next week.
If you have some pragmatic thoughts about this I'd appreciate them as it may help sway our decision!
On one side someone could argue that a 25 character API key is too complex to be broken. It would take so long to brute force every possible combination to find a live key that it’s hardly worth worrying about someone trying to iterate through them. On the other side someone could argue that knowledge of the failed attempts would be tremendously valuable. This is the side we lean towards. If someone is trying to break into our systems we want to know about it AND we want to do something about it. Our security staff actively watches our centralized logging system for events such as excessive login failures. If something doesn’t look right they check into it. It’s frowned upon (at best) to use a software suite that doesn’t have this logging capability and at worst we could potentially be asked to find another software suite for automating deployments.
Would it be possible to add some settings to Octopus to allow users (server admins) to toggle logging capability on and off? Maybe have toggle switches for different kinds of events so that admins can choose which events they want to log. We personally like the idea of passing these events to the domain controller (like login events for Active Directory users) although if they were sent to one of the Octopus logs that would be acceptable. Not logging the events at all is a little scary.