Honeypot as a Service (HaaS) Part 2

In the second Post of this series, we create the Log File Reporting which we will send to vRealize Log Insight.

 

After our samba server is configured (in Part 1) we have to deal with our logfiles and report them to our vRealize Log Insight.

In our Samba Server we already configured the logging which is done in the path /var/log/samba. There files are created for every client which tries to access our server. As long as no client tried to access the file the director should log like this:

When you already accessed your server, you will have a log entry like log.192.168.157.10 or similar.

I will create an event every time a client is accessing the share. Therefore, I will use the inotify-tools. unfortunately, these program is not included the standard CentOS Repository so we have to add an additional repo. I use the fedoraproject repo where we download the Repo configuration and install it.


wget http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-10.noarch.rpm

rpm -ivh epel-release-7-10.noarch.rpm

After that we can install the inotify-tools with yum.


yum -y install inotify-tools-devel.x86_64

After that we create the string to monitor the samba server for client access.


inotifywait -mrq -e create -e modify -e delete /var/log/samba

In this monitoring we ignore changes to the log.smbd file, due the circumstance that this a a standard file form the samba service. The output of this monitoring locks like this:


/var/log/samba/ MODIFY log log.client1-vcoportal

As we want the information on a remote server, we have to extend our logging string with logger to send the information to a remote server.


inotifywait -mrq -e create -e modify -e delete /var/log/samba  | while read file; do ( logger -n loginsight.vcoportal.de-t securitybreak $file ) done

I send my string to a vRealize Log Insight server and tag the log entry with the word “securitybreak”. In Log Insight we can filter for that word……

So, if you use the interactive analyses you can search for your string.

For me the is still room for improvement. The only relevant information for me is the client name. So, let’s modify the monitoring string.


inotifywait -mrq -e create -e modify -e delete /var/log/samba/host | while read file; do hostname=$(echo $file | cut -d '.' -f2,3,4,5 ); (logger -n loginisght.vcoportal.de -t securitybreak $hostname) done

 

We strip done the string we send to our Log Insight Server to just the Client name. I guess there is a better way to create the string but for me this one work fine.

Now we get only the Client name reported in our Log Insight

How cool is that?

The last thing we have to do is to create a startup script for our monitoring string.

In our case, we will want to run inotifywait as a service and create an init script. First we will create our configuration file:


# specify log file

LOGFILE=/var/log/inotify.log

# specify target directory for monitoring

MONITOR=/var/log/samba

# specify target events for monitoring ( comma separated )

# refer ro man inotifywait for kinds of events

EVENT=create,delete,modify

# Log Insight or SNMP Server

SNMPSERVER=loginsight.vcoportal.de

# Security tag

SECURITYTAG=securitybreak

 

Next, we will create the init script where we use the config file we created before as input for the variables.


#!/bin/bash

# inotifywait: Start/Stop inotifywait

#

# chkconfig: 2345 10 90

# description: inotifywait waits for changes to files using inotify.

#

# processname: inotifywait

. /etc/rc.d/init.d/functions

. /etc/sysconfig/network

. /etc/inotifywait.conf

LOCK=/var/lock/subsys/inotifywait

RETVAL=0

start() {

echo -n $Starting inotifywait:

# Clear Log File

if [ -e $LOGFILE ];then /usr/bin/truncate -s0 $LOGFILE;fi

# Start the Monitoring

/usr/bin/inotifywait -e $EVENT -dmrq $MONITOR --exclude ‘\(log.smbd\)*’ -o $LOGFILE | cut -d '.' -f2,3,4,5 $LOGFILE | while read file; do (/usr/bin/logger -n $SNMPSERVER -t $SECURITYTAG $file) done

RETVAL=$?

echo [ $RETVAL -eq 0 ] && touch $LOCK return $RETVAL

}

stop() {

echo -n $Stopping inotifywait:

killproc inotifywait

RETVAL=$?

echo [ $RETVAL -eq 0 ] && rm -f $LOCK return $RETVAL

}

case $1 in start)

start;;

stop)

stop;;

status)

status inotifywait;;

restart)

stop

start;;

*)

echo $Usage: $0 {start|stop|status|restart}

exit 1

esac

exit $?

 

The permissions need to be 755:


chmod 755 /etc/rc.d/init.d/inotifywait

 

We can start the service now:


/etc/rc.d/init.d/inotifywait start

 

The result will be like this:


[root@backup ~]# /etc/rc.d/init.d/inotifywait start

Starting inotifywait (via systemctl):                      [  OK  ]

 

We need to ensure that the service starts when the server boots, so we need to add it to chkconfig


chkconfig --add inotifywait

chkconfig inotifywait on

 

The log entry is written in the /var/log/inotify.log file and from there they were cut down to post the to the log insight server. We have to use this loop due the circumstance, that in our start script inotiywait is used in daemon mode. There a logfile is mandatory.

That’s it for Part 2

 

Honeypot as a Service (HaaS) Part 1 Link: http://wp.me/p7tsEp-C1
Honeypot as a Service (HaaS) Part 3 Link: http://wp.me/p7tsEp-Cl