MetaFlows Honeypots

From The MetaFlows Security System Documentation
Jump to: navigation, search

This section is currently under development, proceed with caution!

Overview

MetaFlows honeypots are run as independent sensors with the purpose of attracting or seeking out malware and malicious activity rather than monitoring a network's normal traffic. A sensor configured as a honeypot acts as a host for one or more virtual machines which provide high interaction environments for collecting data on security events. The virtual machine communicates with the sensor over a private network and the sensor collects all of the snort, service, and log events that are generated. When the virtual machine is compromised, events associated with that compromise are sent to the MetaFlows global correlation engine with a higher ranking. Once a compromised virtual machine is detected by its host sensor, it will reset to a clean state after a short timer expires allowing the sensor to collect data before, during, and after the compromise.

Types of Honeypots

Windows Server

This is thee most common honeypot deployed on a corporate network, used to detect both internal and external threats by acting as an early warning system. Since it is more open/vulnerable than even average windows servers, it is more likely to be attacked.

Windows Client

Primarily used for MetaFlows internal malware research, the client ("monkey") is fed a list of malicious URLs and is automated to crawl them in a way that resembles a normal user's behavior. The monkey will click links, download files, run executables if prompted, play flash videos, and load java applets.

CentOS Linux Server

Hosting few truly vulnerable services, the CentOS honeypot is mainly for detecting/researching scanning and brute force events. It is configured with a number of services that appear attractive to automated scripts and bots that search for a means to log into systems via traditional means (username/password).

Ubuntu Metasploitable Server

With the creation of the Metasploit team for testing and training with their own exploit software, the Metasploitable server also serves as an excellent example of a Linux server that has many holes available for potential attackers. As it is also configured for researching integration of OSSEC, that functionality is now being deployed in the other images as well.

Requirements

  • Centos 6.3
  • Two Public IP addresses
  • A Minimum 4GB of memory
  • A VMware Workstation 8
  • A VMware virtual machine provided by MetaFlows
  • A TightVNC Server or an X Environment

Adding a Sensor to the Honeypot

  • Set Home_Net to the public IP that will be used for the honeypot and the 192.168.148.0/24 network.
  • If you are using a second interface, use that for the promiscuous interface.
  • If you are not using a second interface, use eth0 for the promiscuous interface and create a filter that limits the traffic only to the honeypot IP and the internal network.
  • Select the honeypot type - this is usually xp_server.

Preparing the Host System

  • Set the secondary interface to the public IP to used for the honeypot.
  • Alternatively create an alias of eth0 with the public IP to used for the honeypot.
  • Install VMware Workstation 8 if not already installed.
  • Run VMware-netcfg and change vmnet0 to be host only for the network 192.168.148.0/24.
  • Restart the VMware service and make sure that vmnet0 is 192.168.148.1.
  • Create the directory /hp.
  • Download the honeypot image and extract it under /hp, usually the honeypot folder will be named "monkey" or "no monkey".
  • Download and install the sensor.
  • Allow connections to the vmhp listener: iptables -I INPUT -s 192.168.148.0/24 -p tcp --dport 7070 -j ACCEPT.
  • Optional add iptables to prevent outbound abuse:
    • iptables -A FORWARD -s 192.168.148.0/24 -p tcp --dport 25 -j DROP
    • iptables -A FORWARD -s 192.168.148.0/24 -p tcp --dport 445 -j DROP
    • iptables -A FORWARD -s 192.168.148.0/24 -p tcp --dport 135 -j DROP
    • iptables -A FORWARD -s 192.168.148.0/24 -p tcp --dport 139 -j DROP

Additional Notes

  • Make sure that the .vmx file shows the setting "independent-nonpersistant" before running the sensor for the first time. If this value is not "nonpersistant" the image could become permanently compromised.
  • Make sure to save your changes to iptables '/etc/init.d/iptables save'

Complications

- It may be necessary to edit /etc/vmware/vmnet0/dhcpd/dhcpd.leases if there is an address or interface problem within the virtual machine

- VMware can be tricky to kill, add 'vmrun stop /hp/monkey/monkey.vmx' to the stop and start sections of /nsm/etc/mss.sh

If Traffic Is Not Reaching the Honeypot

- The cat /proc/sys/net/ipv4/ip_forward should equal 1

- Make sure the masquerade rule is present "iptables -t nat -A POSTROUTING -s 192.168.148.103 -j MASQUERADE"

- Confirm that the dnat rule is present "iptables -t nat -A PREROUTING -d <the public ip of the honeypot> -j DNAT --to 192.168.148.103"

Viewing the Honeypot as a Guest

Sometimes it is useful to be able to see the virtual machine and interact with it directly. If you are running this on a local system with an X environment, then that should not be a problem. However, if you are running this on a remote system you will need to use VNC.

- If you installed an X environment you will need to set it up to be accessible via VNC.

- If you simply installed TightVNC server the sensor will run the VNC server automatically for you. Make sure you have set the vnc-passwd.

- The recommended way of connecting to the VNC server is using an SSH tunnel, since VNC does not provide encryption itself:

shell_1# ssh -L 5900:localhost:5900 <sensor ip address> -l root

shell_2# vncviewer localhost

Modifying the Honeypot VMware Image

Advanced users can attempt to modify the honeypot image to add/change services and software or to modify the internal scripts.

1) Shut down the sensor: /nsm/etc/mss.sh stop.

2) Make sure the VMware process stops. If it has not, then kill it with the vmrun command.

3) If there is a DNAT rule in iptables for the honeypot's public IP, remove it (but copy it down, you may need to add it back again)

4) Edit the honeypot .vmx file (probably "/hp/nomonkey/nomonkey.vmx".

5) Change the disk type from "independent-nonpersistant" to "independent-persistent". Note: in this state changes to the machine are permanent.

6) Start the virtual machine by itself "vmplayer nomonkey.vmx".

7) Modify the virtual machine as needed. If it is a client honeypot, IMMEDIATELY close the monkey process before it browses any sites.

8) Shut down the virtual machine.

9) Change the disk type back to "Independent-nonpersistant".

10) Add the DNAT rule back if needed (see step 3).

11) Start the sensor again: /nsm/etc/mss.sh start.

Previous Chapter
Retrieved from "https://docs.metaflows.com/index.php?title=MetaFlows_Honeypots&oldid=2657"