What do you think about zsh? I really like zsh history.
Also, on pentests the ~/.bash_history file is literally the first thing we look at. It's lovely: in an instant, you know exactly which files on the system are important, why they're being used, and what the high-priority targets might be for pivoting to a different box. In some cases it cuts hours off the job. So to keep hackers happy, please don't delete your bash history on production servers.
I mean, it's really clever talking like a mafia enforcer making vague threats but everyone here is treating you respectfully and you're not responding in kind. It's not cool, man. If you don't feel like engaging, don't.
The hassle of not having a history file every day is a much bigger cost than having it on an already pwned machine, isn't it?
Stop being an ass, that's why most people don't listen to security experts, instead of educating people in a kind way and making the world more secure most of you like to live on your high ivory towers with snark comments, passive-aggressiveness doesn't help anyone or any discourse.
Please, learn some social skills.
You have already pwned the machine, what disabling history is gonna do to save someone's ass after that?
The hassle of not having a history file every day is a much bigger cost than having it on an already pwned machine, isn't it?
This is why most people don't listen to security experts, instead of educating people in a kind way and making the world more secure most of you like to just point out how bad we are.
Or passed in a password as an argument to any programs? (e.g. mysql -uusername -ppassword -hprod.db.com)
Plus, if the commands are important as they appear to be (with the need to be referenced days or weeks later), assuming they don't contain passwords, why not put them into a protected team wiki (or a private Github Gist)?
As an attacker, your goal is to get the most amount of privilege and credentials in a brief amount of time without being detected while it's happening. So you grab .bash_history, .bashrc, .bash_profile, .aws/credentials, .ssh/config, .ssh/id_*, .ssh/known_hosts, .pgpass, .psql_history, .mysql_history, .gitconfig, and then get out before a second has even elasped.
As a target, your goal is to limit the blast radius as much as possible, and by following certain practices, if/when you are compromised you can accurately state what the attackers could or could not have had access to.
This isn't about being 100% hackproof, it's about limiting the damage when you are hacked.
If a server is 'compromised' I delete it from the stack, spin up another and provision it all within 60's. The goal is not preventing being hacked, its being in a position where it does not matter.
If your server is compromised, you shouldn't be back in business in 60s. You need to rotate EVERY secret on that instance and everything it connected to. Your main database that coordinates 50 servers? One of the 50 gets compromised, you need to change the pw on all 50. That should include 3rd party API keys and other fun stuff too.
And PS all of that needs to happen _after_ you find out how they got in.
Of course. Promptly followed by export HISTFILE=
Thank you! I didn't realize I could do that (:
With the history file already there, you don't have to wait for it to populate.
Restrictions on what people want to do are always a bad idea. Removing history where people actually use it means that you'll get shadow IT. That means snippets of commands in home directories, "manual" history equivalents, and expect scripts with passwords embedded shared between teams.
Instead of trying to restrict what people want, you can make it easier - spend time automating tasks, providing simple interface to need information, and make sure you can take hosts out of live system for debugging (and then rebuild instead of returning). If there's important stuff in the history file, that means there's a need for history access. Working on solving that will give you more benefits than killing history files.
In a perfect world most things are done via config management, leaving only debugging to be done on prod servers, which should be transient in nature.
In the real world, prod servers should still get treated as transiently as possible.
Authenticated wiki or documentation repo is fine. Automation for tasks, external log shopping, error collection, separate db interface even better. Complete mirror of production in a separate, debuggable environment is the bees knees. But they all take time to achieve. In the meantime, with one or two VMs running your business, I bet you're glad to have a command history, especially if something's down at 3am :-) It all depends on your size and system.
Sure, I might fail a pentest, but what I'm concerned with is protecting against actual real-world attacks without disrupting business operations. Protecting against a pentest just looks good on the pentester's checklist, what really matters is "did we get hacked?".
A good penetration tester will look around a bit with their elevated privileges and maybe find some other things and write those up too.
A great penetration tester will own everything, document how they did it initially, use their elevated access to gain an advanced understanding of your environment, document this understanding, and find as many nooks and crannies as they can in their assessment time frame. They will document these issues realistically and label things like auditing and clearing bash_history as defense in depth.
But the parent also has a point. These little things are accelerators on a pen test. No they aren't going to be the thing that gets you owned.
To be fair I have seen plenty of pen testers that wield findings like this as a hammer making it seem very important while missing the forest (for the tree in front of them) so to speak. Also, the best question probably isn't "did we get hacked?" but "how badly are we hacked right now?", because you are certainly "hacked", just maybe not at a nuclear melt down level.
The idea of any security system should be to compliment normal business operations, not to hinder them.
I really wish it weren't, and a decent penetration tester will know what to do with the known hosts machine on a machine with IP 192.168.0.83 anyway (which is the common case for me), or can just feed it to one of those botnets that ssh's to every public IPv4 address on earth every 60 seconds or so.
But, like password restrictions, the important thing is is inconveniences everyone, so it looks like the security team is doing something.
#soon
http://wiki.bash-hackers.org/syntax/shellvars#histtimeformat