7

I'd like to catch events when bash history is cleaned or some lines are deleted. Are there any best practices or auditing tools with this capability?

inx
  • 71
  • 3
  • 2
    Is there a specific reason you're asking for bash history and not just any file? I'm not sure how this relates to security. – Elias Jul 24 '17 at 15:15
  • 1
    Idea behind is to forward this events into SIEM to detect wiping and modification done by attacker at a post-exploitation phase. – inx Jul 24 '17 at 15:31
  • 3
    Are you sure that this is useful? There are plenty of ways to keep commands out of the bash history in the first place. – Elias Jul 24 '17 at 15:39
  • Indeed, but that's why they call it "defence in depth", I think. Better to have something rather than nothing. – inx Jul 24 '17 at 15:47
  • 3
    Not really, if your detection method causes more false positives and clutters the logs or takes up a lot of time to build which you could have used for other things in total you will end up hurting security. – Elias Jul 24 '17 at 15:51
  • In general "defense in depth" is imho a dangerous mantra.It often leads to lots of crappy "solutions" being used together hoping that one of them will trip up an attacker while focusing on one strong defense would often be better. – Elias Jul 24 '17 at 15:53
  • Of course the people selling security solutions will always advertise "defense in depth" because it means they can sell you more things. ;) – Elias Jul 24 '17 at 15:54
  • 1
    You're shifting my paradigm, thanks for your thoughts. :) – inx Jul 24 '17 at 16:03

2 Answers2

9

Monitoring the Bash history is easily done with a shell script, but just checking it for unexpected changes might not be an effective security measure but rather clutter your logs with false-positives.

One obvious way to monitor file system events associated with your .bash_history file would be by using the inotify API. E.g., this triggers on file modification events:

$ inotifywait -m -e modify ~/.bash_history

You could then compare the contents each time to determine changes, or just compare the number of lines to detect if entries have been deleted with a smaller overhead. (Just checking the file size won't work if the history has reached its maximum length and old entries are dropped.)

But note that it's trivial for an attacker to work around that. You have to expect that any reasonably skilled intruder immediately disables the history, rather than removing suspicious entries afterwards. Also, there are many cheap ways to bypass Bash entirely without provoking log entries (change to Bourne shell, execute from within vi, etc.).

Generally, I'd consider monitoring the Bash history for possible tampering too unreliable and error-prone to be a useful security measure. Instead, I'd first make sure to cover the logs where it's easier to identify security-relevant incidents (/var/log/auth.log, etc.).

Arminius
  • 43,922
  • 13
  • 140
  • 136
  • Thanks a lot for this. I'm going to consider checks with more added value. Would be great if you could point me out in right direction. – inx Jul 24 '17 at 18:12
3

I'm assuming that you want to detect when people have entered some kind of private information into their shell and are now trying to remove it from the bash history.

From an attacker point of view it would be easy to simply constantly create copies of the .bash_history file and check for entries being removed.

If you are doing this to prevent accidental data leakage I suggest that you solve this by policy and make users report such errors and invalidate the information. So if a password was entered accidentally the password should be changed.

If you really want to go ahead with this there are non-security related tools to monitor changes to files.

Edit: I think for detecting attackers wiping their tracks this is a pretty weak method as it is pretty easy to disable or avoid the bash history.

Elias
  • 1,915
  • 1
  • 9
  • 17
  • Thanks a lot Elias. Monitoring file for changes means getting a false positive every time history is flushed. I thought there should be something to check if new file size is lower than previous etc. – inx Jul 24 '17 at 15:37
  • Okay, I'm not aware of any tool to specifically only detect deletions in the .bash_history. Sorry. – Elias Jul 24 '17 at 15:42
  • 1
    @inx Checking if the file got smaller will still produce a lot of false positives. Normally, .bash_history contains the last N commands entered, for whatever value of N the user's environment determines. Until the file contains N lines, each legitimate change will indeed make it bigger. But, after that, it can legitimately get bigger or smaller, depending on whether the newly added commands are bigger or smaller than the old ones that got deleted. – David Richerby Jul 24 '17 at 21:34
  • @DavidRicherby Yeah, and depending on HISTCONTROL old entries will be removed when they are typed again and such. That's why I only stated that I don't know a tool that detects deletions in .bash_history. In general a tool for detecting deletions is not that hard to write but bash might even use something like a ring buffer when history is full or god knows what. – Elias Jul 24 '17 at 21:37