I stumbled across an interesting security package in the Ubuntu Repositories, Ninja
From the Ninja Home Page
Ninja is a privilege escalation detection and prevention
system for GNU/Linux hosts. While running, it will monitor
process activity on the local host, and keep track of all
processes running as root. If a process is spawned with
UID or GID zero (root), ninja will log necessary informa-
tion about this process, and optionally kill the process
if it was spawned by an unauthorized user.
What this means in “non-geek speak” is that ninja monitors your system for unauthorized root access (ie user privilege escalation) and, if discovered, logs and terminates (kills) the process.
Installation and configuration is fairly straight forward, but I made a few (small) modifications.
Install ninja
sudo apt-get install ninja
Configure ninja
Most important, read the documentation. These are the adjustments I made (for Ubuntu).
1. Move the configuration files into /etc
sudo mkdir /etc/ninja
sudo cp /usr/share/doc/ninja/examples/default.conf /etc/ninja/ninja.conf
sudo cp /usr/share/doc/ninja/examples/simple.wlist /etc/ninja/whitelist
sudo chmod -R o-rwx /etc/ninja
2. Make a log file.
sudo touch /var/log/ninja.log
sudo chmod o-rwx /var/log/ninja.log
3. Add a “magic” group (one allowed root access). Here I called it ninja. Take note of the group id (gid or number).
sudo addgroup ninja
Adding group `ninja’ (GID 1003) …
Done.
Take not of the group id (gid or number), in this example 1003
And add your user (and root) to the “magic” group.
addgroup ninja
usermod -a -G ninja bodhi
usermod -a -G ninja root
usermod -a -G ninja messagebus
4. Using any editor, open /etc/ninja/ninja.conf and make some changes.
group=1003
daemon = yes
interval = 0
logfile = /var/log/ninja.log
whitelist = /etc/ninja/whitelist
external_command = /root/bin/alert
Notes:
- Change group “0″ to the group you wish to allow root access . In this example I used the group “ninja” which was assigned a gid of 1003.
- To find the gid, use “grep ninja /etc/groups”
- interval = 0 – If this option consumes too much CPU, change it to 1.
- external_command = /root/bin/alert – YOU must write this script if you wish to use it.
- Examples might include :
#!/bin/bash
echo “Ninja attack” | mail -s “Alert” you@secret-service.com
echo “Ninja attack” > /root/ALERT
echo “Ninja attack” > /home/bodhi/ALERT - Now add this to the end of .bashrc (assuming you have defined the color red in .bashrc)
#Ninja alert
if [ -e $HOME/ALERT ]; then
clear
echo ”
echo -e “${RED}NINJA ATTACK”
echo ”
fi
- Examples might include :
5. Edit /etc/ninja/whitelist
Since ubutnu does not use su, remove the su line
on passwd, allow users
add in other normal system processes:
/bin/fusermount:users:
/usr/bin/passwd:users:
/usr/bin/pulseaudio:users:
/usr/sbin/hald:haldaemon:
/usr/lib/hal/hald-runner:haldaemon:
6. Start ninja at boot. I did this with a single line in /etc/rc.local
/usr/sbin/ninja /etc/ninja/ninja.conf
Ninja in action
root@karmic# sudo -u nobody /bin/bash
bash: /root/.bashrc: Permission denied
nobody@karmic$ whoami
nobody
nobody@karmic$ sudo -i
[sudo] password for nobody: Killed
nobody@karmic$ Killed
root@karmic#
Notice how ninja killed not only the sudo attempt, but the bash shell as well.
Please provide the full post contents in your RSS feed.
I constantly get die: got signal SIGSEGV — segmentation fault errors :S
ninja segfaults intermittently (varies by system) when you use a log file.
It will work if you comment out the line referring to a log file in /etc/ninja/ninja.conf
I have reported the bug and sent debugging information to the developer.
cool
Pingback: El Blog de Marcelo! » Dos herramientas para Sysadmins: Ninja y KSplice
Hey!
Found your feed on planet (ubuntu).
Nice tutorial! I’m loving my ninjas :D!
Hi,
Nice extra security measure!
I followed your guide. Installed it on my home server and it started eating 25% of my cpu cycles!
So i set the interval to 1. Now it just eats 2%.
This is on a 1.2Ghz Celeron.
Does this mean that processes that execute as root an die immediately could go unnoticed?
My understanding is that an interval of 1 instructs ninja to scan all active processes every 1 second (0 = continuous or no delay).
As with all security measures, best to test it out.
In terms of the log, I believe there will be a log of the process as it is started, but again check it out. I fyou wish, you can change the logging options.
Hopefully this procedure will be simpler in future versions of the package:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550545
neat!
Awesome! nice ninja tutorial
Thank you for sharing this howto, I liked the tool and working properly.
log:
[Sun Jan 10 07:01:57 2010] NEW ROOT PROCESS: su[21536] ppid=21414 uid=0 gid=1000
[Sun Jan 10 07:01:57 2010] – ppid uid=1000(xxxxx ) gid=1000 ppid=17568
[Sun Jan 10 07:01:57 2010] + xxxxx is in magic group, all OK!
;)—-
My /var/log/ninja.log is blank or empty. Is that correct?
Running your:
root@karmic# sudo -u nobody /bin/bash
bash: /root/.bashrc: Permission denied
nobody@karmic$ whoami
nobody
nobody@karmic$ sudo -i
[sudo] password for nobody: Killed
nobody@karmic$ Killed
root@karmic#
gave me slightly different results than what you show.
Pingback: Shadows of epiphany » Blog Archive » How to Ninja – Ubuntu 10.04
@ Mark_in_Hollywood :
The Ubuntu/Debian ninja package has been updated, so after reviewing your post, I posted an updated how to ninja :
http://blog.bodhizazen.net/linux/how-to-ninja-ubuntu-10-04/
Pingback: Add a ninja to help protect your server | Linux Shtuff
Pingback: Dos herramientas para Sysadmins: Ninja y KSplice : Revistalinux.net, Linux, software libre, Ubuntu, programación
I’ve been using Ninja for a few months, and only recently had a problem that I can’t figure out. I am trying to run a script that does an update for me (updates a series of databases from NCBI, it’s a public script called update_blastdb.pl) and every time I execute this script it gets killed. I’m an authorized user, but I suspect the script launches things and IT isn’t an authorized user. I’ve appended the relevant ninja.log entries; I just can’t figure out what I need to modify to get this script to execute when I want it to without disabling Ninja! Help!
[Tue Mar 22 18:04:55 2011] NEW ROOT PROCESS: update_blastdb.[11693] ppid=11655 uid=0 gid=0
[Tue Mar 22 18:04:55 2011] – ppid uid=1001(wolfgang) gid=1001 ppid=11654
[Tue Mar 22 18:04:55 2011] + wolfgang is in magic group, all OK!
[Tue Mar 22 18:04:56 2011] NEW ROOT PROCESS: sh[11704] ppid=11695 uid=65534 gid=0
[Tue Mar 22 18:04:56 2011] – ppid uid=65534(nobody) gid=0 ppid=11693
[Tue Mar 22 18:04:56 2011] + UNAUTHORIZED PROCESS DETECTED: sh[11704] (parent: perldoc[11695])
[Tue Mar 22 18:04:56 2011] – sending signal SIGKILL to pid 11704
[Tue Mar 22 18:04:56 2011] * offending process(es) terminated
[Tue Mar 22 18:04:57 2011] NEW ROOT PROCESS: pager[11706] ppid=11705 uid=65534 gid=0
[Tue Mar 22 18:04:57 2011] – ppid uid=65534(nobody) gid=0 ppid=1
[Tue Mar 22 18:04:57 2011] + UNAUTHORIZED PROCESS DETECTED: pager[11706] (parent: sensible-pager[11705])
[Tue Mar 22 18:04:57 2011] – sending signal SIGKILL to pid 11706
[Tue Mar 22 18:04:57 2011] * offending process(es) terminated
[Tue Mar 22 18:04:57 2011] NEW ROOT PROCESS: sh[11707] ppid=11695 uid=65534 gid=0
[Tue Mar 22 18:04:57 2011] – ppid uid=65534(nobody) gid=0 ppid=11693
[Tue Mar 22 18:04:57 2011] + UNAUTHORIZED PROCESS DETECTED: sh[11707] (parent: perldoc[11695])
[Tue Mar 22 18:04:57 2011] – sending signal SIGKILL to pid 11707
[Tue Mar 22 18:04:57 2011] * offending process(es) terminated
[Tue Mar 22 18:04:58 2011] NEW ROOT PROCESS: sh[11709] ppid=11695 uid=65534 gid=0
[Tue Mar 22 18:04:58 2011] – ppid uid=65534(nobody) gid=0 ppid=11693
[Tue Mar 22 18:04:58 2011] + UNAUTHORIZED PROCESS DETECTED: sh[11709] (parent: perldoc[11695])
[Tue Mar 22 18:04:58 2011] – sending signal SIGKILL to pid 11709
[Tue Mar 22 18:04:58 2011] * offending process(es) terminated
[Tue Mar 22 18:04:59 2011] NEW ROOT PROCESS: sh[11711] ppid=11695 uid=65534 gid=0
[Tue Mar 22 18:04:59 2011] – ppid uid=65534(nobody) gid=0 ppid=11693
[Tue Mar 22 18:04:59 2011] + UNAUTHORIZED PROCESS DETECTED: sh[11711] (parent: perldoc[11695])
[Tue Mar 22 18:04:59 2011] – sending signal SIGKILL to pid 11711
[Tue Mar 22 18:04:59 2011] * offending process(es) terminated
[Tue Mar 22 18:05:00 2011] NEW ROOT PROCESS: sh[11713] ppid=11695 uid=65534 gid=0
[Tue Mar 22 18:05:00 2011] – ppid uid=65534(nobody) gid=0 ppid=11693
[Tue Mar 22 18:05:00 2011] + UNAUTHORIZED PROCESS DETECTED: sh[11713] (parent: perldoc[11695])
[Tue Mar 22 18:05:00 2011] – sending signal SIGKILL to pid 11713
[Tue Mar 22 18:05:00 2011] * offending process(es) terminated
@Wolfgang
I would post the script in question as well as those logs on the appropriate (ubuntu) forums to see if you can get some advice. If you do , send me a PM on the forums and I will look at what you post.
I honestly don’t think such a tool will do much for security.
1) If an attacker has a code path to a vulnerable kernel process (let’s say he taps your ntp daemon which, by default, must run as root), then this tool would do nothing to stop him from getting root (assuming he has a working exploit). Nothing whatsoever can stop kernel exploits. It’s game over. SELinux and AppArmor can provide some protection (i.e. containment after the fact), but neither is perfect because they run at the same privilege level as the kernel itself. This means in some cases an attacker can find a way out of the confinement. This is a problem with monolithic kernels (as Joanna Rutowska loves to point out on her blog).
2) If an attacker cracks into your user account, he will already, by default, be allowed to run any suid process that you can. From there it’s just a matter of him finding a vulnerable kernel process and running an exploit. Bam, root shell.
The only benefit I see of this tool is stopping some random user (who is not running under your UID) on the local machine from escalating to root. But that attack vector is so rare that it’s not even worth mentioning. Most of the time if an attacker compromises your machine, he will compromise your user account first. And since your user account will be whitelisted to run the usual suid binaries, ninja provides no protection.
The most security that can be had on Linux today is running Grsecurity. Those mitigations (strong memory hardening protections) are the only ones I am aware of that will stop exploits. And of course, even those protections are not perfect as it is a continual arms race between the crackers finding ways around ASLR et al and the defenders finding new methods to stop them. But I would say that is the first line of defense, with a good MAC system being second.
@rookcifer – Nice post. Yes it is always a game of cat an mouse. More and more I confine the account I use on a daily basis, user_u on Fedora.
grsecurity is a great tool, but it also comes with a learning curve and it is more then “simply” applying the patch compiling a custom kernel. Most applications are NOT confined by PaX by default and RBAC takes a bit of time to configure as well.