Looking for the recommended way to protect the root and user history logs. We had an instance where a user logged in as root and then ran malicious commands but then deleted the trace of these commands. What is the best way to prevent this? Also, is there a way to print/report for example who logged in as root over the past 30 days?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Protect Linux root or user history log 1
- Thread starter jlaw10
- Start date
AvayaTier3
Technical User
you prevent this only by changing root password and not letting multiple users have this type access.
A user with root access cannot prevented from doing anything they are smart enough to do.
A great teacher, does not provide answers, but methods to teach others "How and where to find the answers"
bsh
36 years Bell, AT&T, Lucent, Avaya
Tier 3 for 26 years and counting
A user with root access cannot prevented from doing anything they are smart enough to do.
A great teacher, does not provide answers, but methods to teach others "How and where to find the answers"
bsh
36 years Bell, AT&T, Lucent, Avaya
Tier 3 for 26 years and counting
If you find that a total lock down of root is too restrictive, you should take a look at the sudo concept. It allows you to give root privilege to certain users that can use it on a per command basis with their user password rather than logging in as root. This is how Ubuntu gets away with not having a root account. Of course, it could be used to remove the log entries. If this is a concern, you may be able to remotely log to another system where that user can't access them.
- Thread starter
- #4
Annihilannic
MIS
The last command, which displays the data stored in /var/log/wtmp.
Annihilannic.
Annihilannic.
KenCunningham
Technical User
...as long as wtmp hasn't been truncated by the same malicious user!
The internet - allowing those who don't know what they're talking about to have their say.
The internet - allowing those who don't know what they're talking about to have their say.
-
1
- #7
To be honest with you, it sounds like your server got hacked and it's not compromised.
If I were you, I would cut my losses and reload from scratch, that's the best way to go (if you can of course).
Otherwise you don't know what the intruder left behind in the order of some type of backdoor, trojan, etc...
Also, one other thing you want to look for is known issues with your web apps that you can fix with patches. I assume you're running a web server. Most likely that's how you got it. Someone managed to drop a shell in your box and eventually got your root password.
Remember, always use alphanumeric, long passwords. It is always a good idea to use at least 1 or 2 upper case characters in it. You don't have to change it very often if it's strong enough.
The way linux passwords are encrypted, they cannot be decrypted but they can be brute-forced, thus if you use a really strong password the chances are slim to none.
Chances are your logs are gone because that's the least the intruder would do - delete logs to cover their tracks.
You may also want to look at your router's logs (during that time frame) and see what its logs may revel to you about the potential intruder. Remember, getting his/her IP address won't do you any good. Most attacks come from several chained proxies so forget about finding the original IP of the attacker.
I don't want to scare you or anything, this may not be the case, maybe you had to deal with a disgruntle employee or whatever, however I would take no chances.
One last thing to keep in mind is that if this is not the only machine you own, but seems to be the only machine affected by this, you may want to take a closer look at the rest (if this applies to you).
Let me know how you make out or if you need help.
If I were you, I would cut my losses and reload from scratch, that's the best way to go (if you can of course).
Otherwise you don't know what the intruder left behind in the order of some type of backdoor, trojan, etc...
Also, one other thing you want to look for is known issues with your web apps that you can fix with patches. I assume you're running a web server. Most likely that's how you got it. Someone managed to drop a shell in your box and eventually got your root password.
Remember, always use alphanumeric, long passwords. It is always a good idea to use at least 1 or 2 upper case characters in it. You don't have to change it very often if it's strong enough.
The way linux passwords are encrypted, they cannot be decrypted but they can be brute-forced, thus if you use a really strong password the chances are slim to none.
Chances are your logs are gone because that's the least the intruder would do - delete logs to cover their tracks.
You may also want to look at your router's logs (during that time frame) and see what its logs may revel to you about the potential intruder. Remember, getting his/her IP address won't do you any good. Most attacks come from several chained proxies so forget about finding the original IP of the attacker.
I don't want to scare you or anything, this may not be the case, maybe you had to deal with a disgruntle employee or whatever, however I would take no chances.
One last thing to keep in mind is that if this is not the only machine you own, but seems to be the only machine affected by this, you may want to take a closer look at the rest (if this applies to you).
Let me know how you make out or if you need help.
KenCunningham
Technical User
A star for 3t0n1c's sage advice.
The internet - allowing those who don't know what they're talking about to have their say.
The internet - allowing those who don't know what they're talking about to have their say.
Back to the question of protecting the history files, I have done something like this in the past. It doesn't protect the files, but it does give you a record of a root login that can't be deleted. Kind of a notification "trip wire".
Put a command like this in the system profile, or root's .profile...
Any time someone logs in as root, you'll get an email. The "who -m" on some systems gives the system they logged in from, so it's a little bit of an audit trail.
You could also use the "logger" command to send something like this to the system log, but that's only protected if you have set up another system to be the log host. That way it's logging to another system and can't be deleted unless they have access to that system too.
Put a command like this in the system profile, or root's .profile...
Code:
who -m | mailx -s "root login" someone@somewhere.comYou could also use the "logger" command to send something like this to the system log, but that's only protected if you have set up another system to be the log host. That way it's logging to another system and can't be deleted unless they have access to that system too.
@SamBones - That would only work if the intruder logs in directly as root. Most systems (should) have that option disabled.
Having said that, if any regular user's password is compromised and the attacker uses it to login and only then they issue "su -" to become root, the "who" command would not show the root as being logged in, rather will show the original user. Not very useful now is it?
Thus someone@somewhere.com would never, ever get an email sent out.
There are some workarounds, and with a bit of shell scripting there are some things that could be locked down.
Moreover, services should be jailed when possible.
Remember, 99% of time when a server gets owned is because of administrative negligence.
Good post though!
Having said that, if any regular user's password is compromised and the attacker uses it to login and only then they issue "su -" to become root, the "who" command would not show the root as being logged in, rather will show the original user. Not very useful now is it?
Thus someone@somewhere.com would never, ever get an email sent out.
There are some workarounds, and with a bit of shell scripting there are some things that could be locked down.
Moreover, services should be jailed when possible.
Remember, 99% of time when a server gets owned is because of administrative negligence.
Good post though!
- Thread starter
- #11
Process Accounting is ok for what it does. It all really depends on how much load you have on your box on average, how many people are logged in at any given time, and of course if the machine itself its powerful enough to not be bothered by the additional processes this entails.
Again, regarding how often you rotate your logs and how to keep the size down is directly impacted by how much "stuff" happens on the server.
As a rule of thumb is a good idea to rotate logs on a weekly basis and archive them in .gz files or what-have-you.
You may also want to move logs off the server every once in-a-while, or even better yet setup a dedicated log-server and have all of your servers not log anything locally, but store it all remotely.
There are many things you can do, many ways to go, but if nothing else remember this: security is only as good as your weakest link.
The more you learn, the more you realize how much you don't know.
Again, regarding how often you rotate your logs and how to keep the size down is directly impacted by how much "stuff" happens on the server.
As a rule of thumb is a good idea to rotate logs on a weekly basis and archive them in .gz files or what-have-you.
You may also want to move logs off the server every once in-a-while, or even better yet setup a dedicated log-server and have all of your servers not log anything locally, but store it all remotely.
There are many things you can do, many ways to go, but if nothing else remember this: security is only as good as your weakest link.
The more you learn, the more you realize how much you don't know.
Annihilannic
MIS
Has anyone reading this thread ever used process accounting for this sort of security auditing? How good is it?
My impression at a glance is that it generated far too much data which made finding anything useful in it extremely difficult... and meant allocating extra gigabytes to /var to store it all.
Annihilannic.
My impression at a glance is that it generated far too much data which made finding anything useful in it extremely difficult... and meant allocating extra gigabytes to /var to store it all.
Annihilannic.
- Status
Similar threads
