[Auditbeat] Handle different bad login types#10865
Merged
cwurm merged 5 commits intoelastic:masterfrom Feb 22, 2019
Merged
Conversation
added 2 commits
February 20, 2019 17:57
Contributor
|
Pinging @elastic/secops |
andrewkroh
approved these changes
Feb 21, 2019
Member
|
I'm still thinking about the deduplication part. My first thought is that we shouldn't change the log stream in the dataset, but this isn't Filebeat, it's a dedicated tool for getting login records. If the tool knows that it's a duplicate it might was well discard it. It could even set a field like |
Contributor
|
I like the idea of I also agree philosophically on doing deduplication in Auditbeat, when the case is clear like this |
webmat
approved these changes
Feb 22, 2019
added 2 commits
February 22, 2019 17:10
Contributor
Author
|
Thanks @andrewkroh, @webmat - I've opened #10901 as a follow-up to address the de-duplication. |
cwurm
pushed a commit
to cwurm/beats
that referenced
this pull request
Feb 22, 2019
Depending on the distro and the type of login attempt (e.g. ssh, local login) the `ut_type` value in `/var/log/btmp` is different. So far, the login dataset only responded to the rarer login type `7` (`USER_PROCESS`). The more common one (seems to be exclusively used on Fedora 29, but also used on Ubuntu 18.04 for failed SSH login attempts) is `6` (`LOGIN_PROCESS`) that we are currently ignoring. This changes the code to have a separate function to process UTMP records from btmp files that treats both `USER_PROCESS` and `LOGIN_PROCESS` the same. It also adds a unit test for failed logins including a btmp test file from Ubuntu 18.04 with three bad login attempts. (cherry picked from commit 94666a8)
cwurm
pushed a commit
to cwurm/beats
that referenced
this pull request
Feb 22, 2019
Depending on the distro and the type of login attempt (e.g. ssh, local login) the `ut_type` value in `/var/log/btmp` is different. So far, the login dataset only responded to the rarer login type `7` (`USER_PROCESS`). The more common one (seems to be exclusively used on Fedora 29, but also used on Ubuntu 18.04 for failed SSH login attempts) is `6` (`LOGIN_PROCESS`) that we are currently ignoring. This changes the code to have a separate function to process UTMP records from btmp files that treats both `USER_PROCESS` and `LOGIN_PROCESS` the same. It also adds a unit test for failed logins including a btmp test file from Ubuntu 18.04 with three bad login attempts. (cherry picked from commit 94666a8)
cwurm
pushed a commit
to cwurm/beats
that referenced
this pull request
Feb 22, 2019
Depending on the distro and the type of login attempt (e.g. ssh, local login) the `ut_type` value in `/var/log/btmp` is different. So far, the login dataset only responded to the rarer login type `7` (`USER_PROCESS`). The more common one (seems to be exclusively used on Fedora 29, but also used on Ubuntu 18.04 for failed SSH login attempts) is `6` (`LOGIN_PROCESS`) that we are currently ignoring. This changes the code to have a separate function to process UTMP records from btmp files that treats both `USER_PROCESS` and `LOGIN_PROCESS` the same. It also adds a unit test for failed logins including a btmp test file from Ubuntu 18.04 with three bad login attempts. (cherry picked from commit 94666a8)
cwurm
pushed a commit
that referenced
this pull request
Feb 25, 2019
Depending on the distro and the type of login attempt (e.g. ssh, local login) the `ut_type` value in `/var/log/btmp` is different. So far, the login dataset only responded to the rarer login type `7` (`USER_PROCESS`). The more common one (seems to be exclusively used on Fedora 29, but also used on Ubuntu 18.04 for failed SSH login attempts) is `6` (`LOGIN_PROCESS`) that we are currently ignoring. This changes the code to have a separate function to process UTMP records from btmp files that treats both `USER_PROCESS` and `LOGIN_PROCESS` the same. It also adds a unit test for failed logins including a btmp test file from Ubuntu 18.04 with three bad login attempts. (cherry picked from commit 94666a8)
cwurm
pushed a commit
that referenced
this pull request
Feb 25, 2019
…es (#10910) Cherry-pick of PR #10865 to 7.x branch. Original message: Depending on the distro and the type of login attempt (e.g. ssh, local login) the `ut_type` value in `/var/log/btmp` is different. So far, the login dataset only responded to the rarer login type `7` (`USER_PROCESS`). The more common one (seems to be exclusively used on Fedora 29, but also used on Ubuntu 18.04 for failed SSH login attempts) is `6` (`LOGIN_PROCESS`) that we are currently ignoring. This changes the code to have a separate function to process UTMP records from btmp files that treats both `USER_PROCESS` and `LOGIN_PROCESS` the same. It also adds a unit test for failed logins including a btmp test file from Ubuntu 18.04 with three bad login attempts.
cwurm
pushed a commit
that referenced
this pull request
Feb 25, 2019
…es (#10909) Cherry-pick of PR #10865 to 7.0 branch. Original message: Depending on the distro and the type of login attempt (e.g. ssh, local login) the `ut_type` value in `/var/log/btmp` is different. So far, the login dataset only responded to the rarer login type `7` (`USER_PROCESS`). The more common one (seems to be exclusively used on Fedora 29, but also used on Ubuntu 18.04 for failed SSH login attempts) is `6` (`LOGIN_PROCESS`) that we are currently ignoring. This changes the code to have a separate function to process UTMP records from btmp files that treats both `USER_PROCESS` and `LOGIN_PROCESS` the same. It also adds a unit test for failed logins including a btmp test file from Ubuntu 18.04 with three bad login attempts.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Depending on the distro and the type of login attempt (e.g. ssh, local login) the
ut_typevalue in/var/log/btmpis different. So far, the login dataset only responded to the rarer login type7(USER_PROCESS). The more common one (seems to be exclusively used on Fedora 29, but also used on Ubuntu 18.04 for failed SSH login attempts) is6(LOGIN_PROCESS) that we are currently ignoring.This changes the code to have a separate function to process UTMP records from btmp files that treats both
USER_PROCESSandLOGIN_PROCESSthe same.It also adds a unit test for failed logins including a btmp test file from Ubuntu 18.04 with three bad login attempts.
This new test also highlights an issue of reading btmp files. For some reason, on Ubuntu 18.04 a failed SSH login attempt leads to two identical entries (including the timestamps) being written into the btmp file. I don't know why this is, it could be that somewhere in the chain of login logic two parts decide to write the same entry. This is easy for a human to recognize, but it can lead to inaccurate aggregation results on the Elasticsearch/Kibana side (e.g. for total number of failed login attempts). I suppose that since they are exactly identical we could de-duplicate them easily on the Beats side. The data sent to Elasticsearch would then no longer be an exact representation of what is present on the host, but that might be fine since in reality, only one attempt happened. Curious what others think - @andrewkroh @tsg?