There might be a misconception from my side on wether I should worry about this or not. But if I should, what measures should I take to secure my terminal logs / command history?
One of things largely mentioned is to not type passwords as part of the command params. And instead let the command prompt for the password.
What other practices should be put in place?
This depends on what you mean by "secure". Security is composed of the CIA triad, which stands for Confidentiality, Integrity, and Availability. Violating one or more of those properties is a violation of security. However depending on your threat model, some of those may be more important than others. You might not care if an attacker can delete the logs, as long as they can't tamper with them. Or maybe you don't care about modification at all, and only want to prevent someone from finding sensitive information. Specifying that is important in answering this question.
I will be assuming you are using bash.
Confidentiality is the property that information will only be disclosed to authorized entities.
Anyone running as your user or a more privileged user will be able to read your shell history. If the history contains anything sensitive, then they can read that as well. The practice you mention of not passing passwords to commands in arguments is a good practice. Not only does this prevent it from being logged in your shell history, but it also ensures it will not be visible in the process tree.
There are a few solutions for eliminating command line history:
unset HISTFILE.set +o history..bash_history to /dev/null.This can be done before or after you inadvertently or intentionally enter something sensitive into the shell. As your shell writes history when it exits, disabling history at any time while it is running will prevent it from writing it to the history file. A function you can define to replace the regular exit keyword that allows you to close a session without saving any history for that session could be:
_exit() {
set +o history
exit $1
}
Reducing the amount of history that is kept at any one time can also be valuable. This can be done by setting and exporting the environmental variables HISTFILESIZE or HISTSIZE, which define the limits for the maximum size of the history file, and the maximum number of lines stored in the history file, respectively. Note that a sophisticated attacker with root access may still be able to recover previous history, as old lines are not securely overwritten on the filesystem level.
You can also limit the types of commands that will be logged in the first place. The HISTCONTROL environmental variable can be given the ignorespace value, which will ignore and not log any commands with a leading space. That provides an easy way to prevent a specific command from being logged without disabling logging for the entire session.
The HISTIGNORE file is a colon-delimited list of patterns which should not be logged. For example, to ignore all lines beginning with openssl and ssh, you would set the following:
export HISTIGNORE="openssl*:ssh*"
One thing you should be aware of is that some utilities keep their own log/history files. The less utility keeps history of keywords you have searched for. If you open a file with it, and then search for something sensitive such as a password, it will be saved to .lesshst. The same applies to more sophisticated applications like vim and mysql. Changing this behavior is application-specific.
Integrity is the assurance that the information you are seeing is what was originally saved.
Integrity often provides only a limited subset of this guarantee, even if it is formally defined in ISO 27000 as the property of protecting the accuracy and completeness of information. Information with protected integrity may still be modified, have lines selectively redacted, etc., but it will be impossible for an attacker to convince you that the file is genuine. In other words, integrity is often closer to tamper-evidence than it is to tamper-resistance. No shells I am aware of which are capable of preserving integrity.
Some techniques, such as Forward Secure Sealing as implemented for systemd, can grant integrity to system log files. This is implemented by periodically signing the log files, giving them a digital signature that cannot be forged. An attacker can still do two things:
However, any modification at all will result in the digital signature failing verification, making the fact of tampering completely evident. You will never be left wondering if the log files are genuine.
While systemd does not keep shell history logs, this same general technique can, in theory, be applied to shell history as well. I am not aware of any extant implementations of this. Additionally, the sealing is done immediately, and an attacker may be able to modify the last 15 minutes (in the case of systemd) of logs. It is theoretically possible to have each line individually signed, but that would add overhead.
Availability is the ability of information to be accessed on demand.
Destruction of any of the data (selectively or haphazardly) or denying access to it would violate this property. Like with integrity, I am not aware of any shell which goes to any lengths to ensure availability of the logs.
Ensuring availability of information as it applies to history files can be done in a few ways:
Any of these techniques will prevent an attacker from deleting history, or otherwise making it unavailable for later use. Using the append-only filesystem attribute is the easiest, but a local privileged attacker can disable it. Directing logs to an external server is the most advanced, but is industry-standard for ensuring availability.
Use a logging server. Have all your servers immediately send all events to a common logging server. Then the hacker can delete all your files, but its to late the logged events are already out the hackers immediate reach.
Then, your next concern is making sure the logging server doesn't get compromised. The logging server should ONLY be a logging server with all other services turned off. All other ports beside the incoming log traffic should be dropped. Ideally, another network interface on a private lan would be the only way to talk to this server.
