Monthly Archives: October 2010

Email alerts whenever someone logs into root via SSH

Want to be notified instantly when someone logs into your server as root? No problem. there was recently a discussion over on the forums after an incident where a user had had several of there servers logged into as root by an unknown source (since resolved) a helpful user (R4Z0R49) posted this helpful guide and I have cleaned it up and added some further notes and caveats.

While I wouldn’t recommend allowing root logins over SSH and prefer to setup non root accounts with sudo access, sometimes for one reason or another, root over ssh is needed. This guide should also log su logins to root as well, because by using su you login to that users enviroment and it loads the users environment which then calls the same file that loads stuff like variables and paths when you login over ssh so you should also get an email in this instance too.

Check out this nice tutorial on email notification for root logins. Keeping track of who logs into your server and when is very important, especially when you’re dealing with the super user account. We recommend that you use an email address not hosted on the server your sending the alert from.

To carry out this tutorial you need to have root level access to your server in some form or another, I assume you have already logged in as root or otherwise escalated your privileges to root level, I will also assume you use the nano text editor, feel free to use any other editor you are comfortable with such as vi or otherwise.

It is recommended to have mailx installed to send the emails, depending on your system you can install it with either one of the following commands on debian/ubuntu (apt) or centos(yum) systems respectively.

apt-get install mailx
yum install mailx

Now we need to make sure we are in root’s home directory (this should be the same on all linux systems)

cd /root

We now want to edit the .bashrc file to add some code to do the emailing this file is the environment file and pretty much all servers use bash for the root user by default. This file will set local environment variables for the user and can also perform some other cool login tasks like we are going to do below – NOTE: .bashrc is a hidden file so you wont normally see this by doing a normal ls command in this directory, if you want to see it on ls you need to use the -a flag to view all files.

nano .bashrc

At the bottom of the file we want to add the following line, replacing YourserverName with a suitable name for your server (I find the system hostname is often the easiest to distinguish particularly if you have several servers) and change [email protected] to a suitable email address – I would recommend using an email address not hosted on the server as it could be intercepted by someone if they were aware of such a system being in place (now is a great time to use google apps!)

echo 'ALERT - Root Shell Access (YourserverName) on:' `date` `who` | mail -s "Alert: Root Access from `who | cut -d'(' -f2 | cut -d')' -f1`" [email protected]

Save and exit the file by pressing Crtl + X and then Y, then hitting Enter

Now logout of SSH, close the connection and log back in! You should receive an email address of the root login alert a few minutes afterwards.


You can do this for any user you want to get email alerts on login for, assuming they are assigned the bash shell then edit there .bashrc file which should be found in /home/username/.bashrc.

If you want to do this for all users you have 2 options. either edit /etc/profile instead of .bashrc or install CSF & LFD and set it up as it has an SSH and SU login detection system that will email upon login without having to make these profile changes. I shall put up a post on how to install and setup CSF & LFD in a further blog post.

SSH Root Security Tips

ok so i thought i would shove a quick techy thing up while its fresh in my head. this post i think is great when you are in an environment where you have to compromise on security and ease of use. I have to admit though, this tip is not my own i read this originally on Jordan Bedwell’s (Envygeeks) site however the site no longer seems to be available and i havent yet found it anywhere else. So i am posting this up for all to benefit as far as i am aware Jordan should recieve credit for it – feel free to correct me if i am wrong.

This article follows the logic that normal users will want to use a password and do not use keys. The truth is folks, most Engineers and Admins have to put up with people who don’t understand key based authentication, and it’s our job to come up with creative ways to secure the server while not being obtrusive to their lives.

Recently we had a spur of clients ask us to enable root for them. Mostly because we don’t allow our clients to root into most of our dedicated servers, we force clients to login as a normal user and then sudo -i into root (root login is completely disabled, no password so no ability to login ~ no su). The problem was, even though we had fail2ban, this would not stop a large bot-net attack as fast as they could cycle, unless we got really strict, which we can’t because of a catch 22. Either be real strict and have to deal with abnormal amount of requests that we could not cover feasibly while keeping up our goal of being efficient or reduce security a tiny bit and come up with a user-name that would be as hard to guess as the password making it twice as hard to haxor up our stuff. The problem here is, as we saw more and more root requests come in and we rejected more and more unlocking (we always tell them they can enable it themselves but we will not cover it ~ if our investigation concludes a brute force into root) we started to take this as a challenge. Not really since we already knew how to do it.

The truth

We are not any different than your host, we generally deny any other way for the sake of sanity. Not really, we are very creative, we just like to keep things uniform too. The truth is, most hosting companies tell you it’s insecure to enable root, and they are right, and wrong. The problem is, we are not a hosting company, we are the company that teaches the engineers at the hosting company how to do their job and does their job when they fail to hard to do it. The real truth is enabling Root is only as secure as you make it and most engineers and admins or at least most that know how to do their job, know ways to enable root while keeping it rather secure from brute force attacks.

The How-To and FixThe dirty dirty, most of you already know it, add a key to root, and then switch the PermitRootLogin, now, before you talk, go on and say what you’re going to say, and then shut up and listen closely. We will not use yes or no for this variable. We will actually use a different value. Lets look at our decked out SSH_CONFIG and see if you can figure it out:

Port 22
ListenAddress IP.GO.HE.RE
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
UsePrivilegeSeparation yes
KeyRegenerationInterval 3600
ServerKeyBits 8192
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 30
PermitRootLogin without-password
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
IgnoreUserKnownHosts yes
PermitEmptyPasswords no
ChallengeResponseAuthentication no
PasswordAuthentication yes
KerberosAuthentication no
KerberosTicketCleanup yes
GSSAPIAuthentication no
GSSAPICleanupCredentials yes
X11Forwarding no
X11DisplayOffset 0
PrintMotd no
PrintLastLog no
TCPKeepAlive yes
MaxStartups 1:5:10
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
UsePAM yes

That’s right boys and girls, we simply change PermitRootLogin to without-password and boom, we can now only login using our key. The good part about this is too, a flaw by design is it still shows a password dialog which can be a nice little trap for idiots who try to brute force into the server or idiots who just want to try and see if they can “guess” the password so they’ll still be caught by fail2ban but will never be able to get in, because interactive passwords have been disabled, unless they magically get in and add their key to root. Go on now, start generating your 8K RSA keys and enabling root only by key login.

Linux Securing your /tmp directory

its recently been noted that lots of people having there servers hacked because they were running vulnerable versions of PHPMyAdmin. obviously the best advice to fix this is to upgrade your PMA install to the latest version or to otherwise protect it with passwords etc (apache passwords not just the db passwords). however this may not always be totally feasible or possible (i am looking at ISPManager Pro installs on debian here mostly)

this is a very short guide that will help you secure your server by locking down the tmp directory more thoroughly and thus hopefully effectively eliminating the access point that this exploit uses.

DISCLAIMER – this does not close the exploit that PMA is open to, it just closes the access point for it, there is still possiblity for it to gain access via other as yet unknown means.
ALSO – messing up your fstab file can lead to an unbootable system, you should make a system backup before making such a change or be able to boot into some form of recovery enviroment to be able to re edit the file to fix

the fix is pretty simple to implement and involves making your server’s tmp directory get mounted with no executable permissions (noexec) or no sticky user id bit settings (nosuid) which is where the exploit does its damage – it executes code from the tmp directory which normally has global write access of some sort, this guide is tested to work with debian systems (with or without ispmanager pro) and should also work on CentOS systems with no issues, see my caveats at the bottom for cpanel servers.

firstly login to your server as root via ssh (or console) if you dont ssh as root, connect as you normally do and get to root level access (you may need to add sudo to the beginning of your commands) – i am assuming you have root access from now on and nano (choose your own text editor if you are more comfortable with it eg vi)

we need to edit fstab to make the temp directory noexec and nosuid, we do this by editing the fstab and using a bind mount to effectively remount a directory as a partition (this is used to often remount folders and make them accessible from different points eg making the folder /bob available at /bobby as a partition (not just a folder/symlink) to do this:

nano /etc/fstab

your text editor will come up now, if you are familiar with the syntax it goes:

<device> <mountpoint> <filesystemtype><options> <dump> <fsckorder>

if you have a line that has /tmp in the second collumn, see my caveats below, otherwise add the following line to your fstab file:

/tmp  /tmp  bind  nosuid,noexec,bind  0  0

this effectively makes the /tmp folder on / (the root partition) available as a partition mounted at /tmp – you can do lots of cool things by mounting other directories over others but thats way beyond the scope of this guide

to make this take effect you can either reboot your server with:


or whatever command/process you do to reboot

or if you are happy to unmount and remount (i dont normally reccomend this for safety sake)

umount /tmp
mount -a


if your fstab file already has a line with /tmp in the second collumn (eg most reasonably up to date cpanel servers) then just simply adding this line will most likely cause issues, you should simply edit the existing line and add the options


to the flags section

eg a default cpanel temp dir line may look like this:

/usr/tmpDSK  /tmp  ext3  defaults,noauto  0 0

just add the flags to make it look similar to:

/usr/tmpDSK  /tmp  ext3  defaults,noauto,noexec,nosuid  0 0

NOTE: nano tends to wrap text when you edit if your window is small and the fstab file is very very sensitive to this and will cause problems if each non commented line is not a fully syntactically correct line. To avoid this issue, either maximise your shell window or load nano in non wrapping mode (-w) eg

nano -w /etc/fstab

again unmounting and remounting or rebooting your server will pickup these new settings