evilghost
Premium
join:2003-11-22
Springville, AL
 ·Windstream
| Securing .bash_history
The SSH honeypot detected an actual human user, the first command they ran was "unset HISTFILE" which will unset the environment variable for the location of the bash history file. While this is a quite old technique evidently this is the first time I had seen it.
In an effort to educate others I'm creating this topic and providing methods to mitigate this.
To prevent this you can edit /etc/profile and set these variables as read-only. If you're using an ext filesystem you can also chattr .bash_history so it can only be opened in append mode; preventing users from erasing/clobbering the file.
|
|
bky
Premium
join:2002-07-05
Austin, TX | Excellent hardening tip, thanks. Also keeps the user from exporting a different value for histfile, such as /dev/null. |
|
BeesTea
Network Janitor
Premium,VIP
join:2003-03-08
00000
| reply to evilghost
Excellent post.
It's important to note that this only stops the intruder from remapping the history file and doesn't stop the filesystem based vectors to achieve the same goal. Linking ~/.bash_history to /dev/null is still possible, etc.
Not trying to dissuade anyone from following the profile hardening method, just trying to encourage people to view the attack from all vantage points.
Thanks!
--
Overpower, overcome. |
|
evilghost
Premium
join:2003-11-22
Springville, AL
·Windstream
edit:
April 11th, @12:53PM
| said by BeesTea  :Excellent post. It's important to note that this only stops the intruder from remapping the history file and doesn't stop the filesystem based vectors to achieve the same goal. Linking ~/.bash_history to /dev/null is still possible, etc. Not trying to dissuade anyone from following the profile hardening method, just trying to encourage people to view the attack from all vantage points. Thanks! Can you expand on that? I was under the impression the chattr +a would cover that (or are you speaking with regard to the readonly export settings)? Thanks for your input
|
|
bky
Premium
join:2002-07-05
Austin, TX
 ·AT&T U-Verse
| reply to BeesTea
said by BeesTea :It's important to note that this only stops the intruder from remapping the history file and doesn't stop the filesystem based vectors to achieve the same goal. Linking ~/.bash_history to /dev/null is still possible, etc. Actually, an append-only attribute would prevent the user from doing this. |
|
BeesTea
Network Janitor
Premium,VIP
join:2003-03-08
00000 | reply to evilghost
Sorry, skimmed the chattr sentence and went to the first code block. Not enough coffee this morning I guess.
Again, great post.
--
Overpower, overcome. |
|
evilghost
Premium
join:2003-11-22
Springville, AL
·Windstream
| said by BeesTea :Sorry, skimmed the chattr sentence and went to the first code block. Not enough coffee this morning I guess. Again, great post. Thanks again, glad I understood chattr to be what it is. Obviously chattr is only going to be applicable to an ext filesystem. I would assume ReiserFS and XFS have similar fs attribute settings... |
|
bky
Premium
join:2002-07-05
Austin, TX | Yep. ext(all versions), jfs, xfs, and reiser all support extended attributes. |
|
