It's just a delay. Are you really suggesting that making work harder on a daily basis is worth it to slow down by a few hours (not preventing!) lateral movement in an already exploited system? Because that's why users hate security restrictions.
Also, you shouldn't really be running sensitive commands on a production server ever. And if you are you really should clear the bash_history. Sensitive data leaks into that file and I don't see a clear argument that it really makes your life any faster. Use something like etckeeper and document the important stuff on an internal, authenticated, Wiki or some other more secure central note repository. Often you don't need the whole history for prod, but the few important commands.
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.
You shouldn't, but you will. Especially in small companies. The production with no access is a holy grail that is both a good idea and harder to achieve the bigger you get. Almost nobody starts a new service (unless you're already in a company where a framework for this exists) with "I'll use an immutable architecture with staging environment and simple traffic failover and database I can easily clone for debugging and...". They start with "I'll get a VM and put my app on it".
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.
By all means, steam ahead. It's certainly your right as a developer not to be slowed down by pesky restrictions. The easiest marks were always the companies that had a culture of hating security restrictions.
Wait a minute. If you've owned my user, what's to stop you from setting the histfile even if I turned it off? Not to speak of how you can just listen to my pty.
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.
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?
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.
Attempted to make a shorter version that says most of the important points:
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.
I guess you've never typed a password into the command line by accident? (sudo apt-get install<forget to hit enter>hunter2)
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.
As a team member with promises to keep my only goals are getting my job done and meeting my KPI's. I cannot afford to not have bash history or any other history. And I certainly don't have time to do the securistatsi's job for them.
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.
Meeting your KPIs has to happen within the InfoSec framework of your company. The "securistatsi" exist for a reason - not to slow you down, but to protect the company from you. If your only goal is hitting your target then _someone_ has to make sure you're not doing it the wrong way, as you clearly don't care - full speed ahead, security be damned.
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.
> I guess you've never typed a password into the command line by accident? (sudo apt-get install<forget to hit enter>hunter2)
> Or passed in a password as an argument to any programs? (e.g. mysql -uusername -ppassword -hprod.db.com)
I'm legitimately curious about their question so I'll phrase it differently: have you ever found something in the shell history that you wouldn't have discovered on your own? Is it more of a delay tactic or real deterrent?
I have done my share of internals. Some of the time you find valuable clues in administrative audit logs and bash_history. Clues that mean you make a good and impactful finding within the timeframe of your timebox. Reality is an attacker with this level of access is going to have more time than I will, but it still means a measurable impact to security because it decreased the time it took to find something. So in that sense the OP is correct, it comes down to a risk reward trade off and is it worth clearing the history to potentially buy yourself more time in the event you are owned. It isn't as black and white as "well, the server is owned, of course you have my bash_history, that is the least of my worries now..." it is, but it could also be the one thing that gives you 3 extra hours to detect and shut down an attack.
I'm not a developer. I'm actually an ex security engineer, but thanks.
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.
