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 Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Send email when root logs in

Status
Not open for further replies.

timgerr

IS-IT--Management
Jan 22, 2004
364
US
Hey all,
I have a dedicated server and the hosting company has root to my box. If there is a support problem they log in to the server (via ssh) with the root account. I know that it is a bad thing to have root log in to ssh but this is their policy. I have installed denyhosts to stop ssh hammering.

I was wondering if there was a way to send an email out when root logs into the system vi ssh or a su.

Thanks,
timgerr

-How important does a person have to be before they are considered assassinated instead of just murdered?
-Need more cow bell!!!

 
It's not very subtle, but you could just send an email from root's .profile or .bash_profile perhaps?

Annihilannic.
 
No guaranteed method to have alerts of a root login more than 1x without MAC (that negates root's superuser privilege to some degree). That or a really stealthy rootkit (not advocating this).
 
I think one fairly reliable method would be a PAM module, but if no such module already exists it would require a little development.

Annihilannic.
 
Yeah, I was thinking of a hook to a PAM module/event as well.

If the timing of the notice wasn't super critical, you could cron something or use logwatch to monitor the /var/log/secure log file to find records of 'root' logins and email that output.

D.E.R. Management - IT Project Management Consulting
 
PAM is how much better than a 'mail-me' line in the core shell configuration files in /etc/skel (or wherever the LSB states global (\.*rc|\.*ofile*) files should be now) if root still retains total control over the system?

The core issue is that any configuration that is modifiable by the superuser is a no fix. It is obscurity. If this non-existent PAM solution is any sort of compliant implementation then simply removing it or adding a 'dry-run' type parameter to its discrete invocations in the pam configuration will make the whole exercise fruitless.

Any alert is a 1x exercise with an alert and savvy root user. The PAM solution is a lot of work when a single firewall rule added by an alert root user negates the exercise external to any auth/login mechanism whatsoever.



 
PAM would be better than, say, my .profile suggestion because it would catch more situations (i.e. an su instead of an su -).

No-one said this had to be foolproof from a security point of view; of course root would always have the capability to undo whatever we suggest. I'm presuming this is purely for informational purposes; hopefully the OP can trust his hosting company at least that much!

Annihilannic.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top