Kojoney2 is a medium interaction SSH honeypot written in Python. Using a honeypot to collect security intelligence data is vital as it can demonstrate attacker methods as well as expose post compromise artifacts (otherwise known as Indicators of Compromise or IoC). Kojoney2 is included as a part of the HECTOR install process (it is downloaded from GitHub - https://github.com/madirish/kojoney2) but isn't actually installed.
To install Kojoney2 you should use a dedicated CentOS 6 machine. As of this writing CentOS 7 doesn't include some of the necessary libraries (mainly Twisted Conch, which is a Python based SSH server that Kojoney2 is built upon). A virtual machine is optimal for hosting Kojoney2. You won't need much memory or hard drive as the program is quite small.
Once Kojoney2 is installed it tracks data in it's own SQLite database, which makes integration with HECTOR a little tricky. Luckily the Kojoney2 server also writes its own log file to /var/log/honeypot.log, and OSSEC can be configured to monitor this log.
When HECTOR installs it creates new OSSEC decoders and rules that can be used with Kojoney2 log files. These rules are installed on the OSSEC server (which is also the HECTOR server).
In order to integrate Kojoney2 and HECTOR you need only install an OSSEC agent on the Kojoney2 machine, configure it to monitor the honeypot.log file, and connect it to the HECTOR based OSSEC server.
There is ample documentation on the OSSEC website about installing OSSEC clients. You can use the same installer that was used for HECTOR by copying it over to the Kojoney2 machine (it's located in the HECTOR Git repository under app/software/ossec-hids-2.7.tar.gz). You should be sure to use the same version of OSSEC that's running on the HECTOR server.
Once OSSEC is installed on the Kojoney2 machine simply edit the OSSEC configuration file at /var/ossec/etc/ossec.conf and add the following stanza:
<localfile> <log_format>syslog</log_format> <location>/var/log/honeypot.log</location> </localfile> <localfile>
Be sure to restart the OSSEC client once this is added. Once this is done you should be able to see OSSEC alerts being generated in HECTOR from the Kojoney2 honeypot.
HECTOR also relies on darknet data collected via iptables dropped packets. Sensors are configured with OSSEC in client mode to monitor syslog, to which iptables logs dropped packets. By specifying a unique identifying string in the iptables configuration, OSSEC is able to identify these dropped packets with custom rules in /var/ossec/rules/local_rules.xml.
The first step to configuring a darknet sensor is to install OSSEC in client mode (a fresh virtual machine is perfect for this task) and configure it to report to the HECTOR main OSSEC server. Note that CentOS 7 moved from iptables to firewalld, so again, a CentOS 6 virtual machine is your best bet. Once the virtual machine setup is complete with iptables installed simply configure iptables to log dropped packets using a configuration file such as the listing below.
The important part of the iptables alteration is the final line that will LOG dropped packets. Below is an example iptables configuration file (which can be found in /etc/sysconfig/iptables on a CentOS host):
Firewall configuration written by system-config-firewall # Manual customization of this file is not recommended. *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -d 126.96.36.199 -j REJECT -m comment --comment "Ignore multicast packets" -A INPUT -d 188.8.131.52 -j REJECT -m comment --comment "Ignore multicast packets" -A INPUT -d 10.0.0.2 -m state --state NEW -j LOG --log-ip-options --log-prefix "iptables " -m comment --comment "Log dropped packets" -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j REJECT --reject-with icmp-host-prohibited COMMIT
Once iptables is installed be sure to install OSSEC in client mode and connect it to the HECTOR server. Once iptables and OSSEC clint are configured they may need to be restarted using:
# /etc/rc.d/init.d/ossec restart # service iptables restart
Once done you can test the configuration by attempting to telnet to the darknet sensor from another machine. The connect attempt should fail and you can check to ensure that the dropped packet is logged by looking at the end of the darknet sensor's syslog with the following command:
# tail /var/log/syslog
You should see an entry for a dropped packed to destination port 23. If not then check your system logs for indications of what might have gone wrong.