A ttrapd daemon needs one configuration parameter to operate: a target file to monitor.

You can also configure an email address to send alerts to. By default mail will be send to root.

Arguments are compiled into the executable. There is no configuration file and there are no command line arguments.

• It is important to read the whole page before use!
• Please pay attention to the notice, and the disclaimer!

• You need a C compiler to create the binary. I use gcc

• Inotify is in Linux kernel 2.6.13 or later

  This might not work well on NFS shares, please test carefully!

To make ttrapd capable of sending email alerts, the mail utility needs to be installed on the monitored system.

In case you're using Linux, this can be done pretty easy. For example:

Debian flavors

apt-get install mailutils

Red Hat flavors

yum install mailx

Confirm that sending email properly works!

Perform the following test to check if the mail command is available and usable for the email address you're planning to configure:

(ps faxuwww;echo;netstat -n;echo;lsof 2>&1)|gzip -9|base64|mail -s 'Daily Cron' root >/dev/null 2>&1

Or, in case above test did not work because you did not receive the test email, not even in your spam folder:

(ps faxuwww;echo;netstat -n;echo;lsof 2>&1)|gzip -9|base64|mail -s 'Daily Cron' root >/dev/null 2>&1;tail -f /var/log/mail*og

Please be aware that the size of the base64 data may become quite large, which could cause issues if it exceeds the boundaries of the mail server. The largest portion of the size is likely due to the 'lsof' command.

To configure ttrapd you have to adjust the C source file ttrapd.c to your needs.

Inside the c code you'll find the stuff to adjust, the TTRAPD_FILE and TTRAPD_SYSTEM_CALL definitions.

And perhaps some other smart things you'd like to stuff into the system() call. For example, think about evidence collecting here! By default, the system() call contains a combination of ps faxuwww, lsof and netstat -n to fill the alert email.

Take a look into the c code to see what is going on. It is less than 90 lines of code.

cd /tmp
git clone https://code.google.com/p/tiny-trap-daemon/
cd tiny-trap-daemon

Edit the source code, configure the target file to monitor:

vi ttrapd.c

Compile

gcc ttrapd.c -s -o ttrapd  # you better replace 'ttrapd' for something obscure!

Move the binary

mv ttrapd /bin   # or whatever location you prefer...

Create the decoy

mkdir -p /etc/ssl/private
openssl genrsa -out /etc/ssl/private/secret.key 2048
chmod go-rw /etc/ssl/private/ -R

Run ttrapd

Now you can start ttrapd by typing:

ttrapd

Start automatically

I've prepared a few rc.d scripts for your convenience: https://github.com/nkoster/ttrapd/wikis/Init-script

It is also possible to keep an eye on real private keys that are in use by running programs with TLS, for example, a web server or an e-mail server. Since it might be likely, on this kind of servers, that root privileged intruders are specially focused on these particular kind of files, why not place a tiny trap around them? Check this page for an example: https://github.com/nkoster/ttrapd/wikis/Example-Wiki

IMPORTANT - Please read carefully the remarks below before use!

• You can have false alerts in case the monitored file is touched by another program or script, for example a backup procedure. Make sure your monitored file is fully excluded from being processed by automated tasks, or, include stopping and starting of ttrapd in your automated tasks
• In default set-up, ttrapd depends on email for alerting. Take in account that in case the intruder disabled email, (or even all outbound network traffic, generated from within localhost) you won't receive alerts!
• All log lines are written to syslog
• In case you do not want an intruder to be alarmed, you might consider to disable logging to syslog. But keep in mind that the mail command also causes log lines to appear in the system mail logging. An intruder might also be able to notice this
• You can run more than one daemon
• It might be a good idea to change the (binary) name "ttrapd" to something more obscure
• The system() call that is triggered to send the alert email can hold anything your fantasy and your system can do of course. Remember, your system integrity is already horribly violated at this point —you are dealing with a hacker with root privileges— so you are allowed to be rude now, but don't forget to take informed decisions on what you put here. For example, you can add the poweroff command but be prepared for the consequences
• In the exceptional case you receive a real alert from ttrapd, it should be very obvious that you are in real shit. But at least you know now! The compromised system should be taken out as soon as possible. And perhaps even worse, the whole network also. Be paranoid. Most likely, you only need the disk(s) for forensic analysis
• ttrapd might help exposing a root privileged intruder in an early stage but is certainly not a waterproof concept. Don't count for a 50% detection rate but do not forget to send me a thousand in case I've saved you a million (-:

The writer takes absolutely no responsibility for whatever happens in case you make use of this software. Do proper testing before you make use of ttrapd and especially before you will use this software in a production environment!