Ok, since we're having such a great discussion on root level security, I'm going to offer up a one trick pony for you all.. I routinely add one single line to my /root/.bashrc to help me keep an eye on the root shell:
who ; who | sendmail -f "rootalert@myhostname.com" -F "Root Login Alert" 1234567890@sms.mysmsgateway.com
Of course, you'd replace the recipient address with your SMS-enabled cellphone number and the hostname of your cellular provider's email to text message gateway. So, the instant the root shell is touched, you get an instant alert including who is logged in from what IP. If I see one of those alerts show up without good reason, WHACK!, there goes the Slice (I personally don't bother wondering what an unauthorized rooter may have fiddled with AND I have backups!) .. I also have a record of the IP in my cell phone. This may or may not be useful to you, depending on how many people have access to your root shell, and whether your cell provider supports email to your phone. Obviously, your Slice needs to be email enabled. The first "who" in the line is just so I see who else is logged in as soon as I log in to the root shell. It's not necessary, but it's just nice knowing! You can of course teach this trick to any other user account you wish. I'm posting this as a new thread, in case anyone has any comments or other cool one-liners to add..
Of course, one line of code doesn't *really* make your root shell *secure*, but it is still a cool one trick pony!
Posted By: GadgetThe first "who" in the line is just so I see who else is logged in as soon as I log in to the root shell. It's not necessary, but it's just nice knowing!
That's just another way to keep an eye on who is logged in. When you log in to the shell, you automagically get your 'who' listing on the console.. First thing I always do when I log in is to see 'who' else is there anyway, so I just chose to put that in there with the notification part.. I just like to know, in case there is someone there who isn't supposed to be there, or in case there is an orphaned login kicking around that needs to be killed off..
Well, I was noticing the Code Exchange was looking really slim, and I figured there's a few people who like code around here, seeing as how so many of you liked this one humble line, so here's another tricky bit of code for you in the Code Exchange: Simple Slice Monitoring Script in 90 Lines of Code. This one is a multi-trick pony! Thought maybe it might encourage other some other posts to the exchange.
It does, provided that the particular exploit invokes a root shell. The malicious user generally wants to execute some sort of command as root, and one of the best ways for them to do that is through gaining a command shell. It is certainly the most attractive target. But, of course, nothing can be 100% guaranteed in a situation where your system has been compromised. Think of this as just another layer in a multi-layered security approach, not a cure-all. It is merely an example of a possible, and simple, tripwire notification. You could just as easily take this one line of code, turn it into an Error403.cgi and point your Apache error handler to it and get notification of attempts to bypass web restrictions. There are plenty of other places to place a tripwire such as this, which is certainly a good practice followed many network security professionals. I personally have this particular piece of code scattered in about 10 different places. In the case of the kernel exploit recently discussed in another thread, the code presented did invoke a shell and it did in fact trigger this particular tripwire when tested on my quarantine red box. I may make the hype sound nifty, but you certainly should not rely only on this one line to protect the henhouse! Please remember, this is a one-trick pony and you need many tricks to match the bad guys' vast collection of tricks! I just offered this as another weapon to add to your, I hope, collection of weapons. So, to answer your questions:
Does this really get triggered by root shell exploits? - Yes, MANY will trigger this, as long as they are SHELL exploits.. Or are you just guessing that it does? - Yes, I am... Everything is a guessing game when a compromise is in place!
It will execute as long as your attacker launches an *interactive bash* root shell (without --norc or --rcfile or changing ~root/.bashrc first). I don't find that terribly likely except with a proof of concept exploit like the other thread.