Deceive and monitor by honeypot systems

Ritratto di jdaemon

It's intrinsically impossible coping with all possible threats, including those not yet known.

In traditional systems you try to avoid attacks but sooner or later it will happen. With the introduction of NIDS monitoring function was added. Then with IPS, the systems became reactive through attempts to block network traffic from the malicious suspected source but it was still defending production value.

Thanks to the honeypot system the perspective changes radically because it has no production value. Rather it pretends to have it.



What is it?


General Definition


A honeypot is an information system resource whose value lies in unauthorized or illicit use of that resource[0]


Being devoid of production value one is led to consider suspicius any attempt to access these resources. Indeed statistically honeypots have a low false positive[1] rate.

In practice honeypots aim to achieve two objectives:

  • divert the attacker from production systems (deception)
  • monitoring, detecting and analyzing attacks (research)

Honeypots are used in both the business world and in the scientific research. The goal of deception is a prerequisite for all honeypots. Detecting vulnerabilities that are not yet understood and study the attacker behaviour are the main goals of the research.


Glossary of other key terms

  • Honeypot: Go to What is a Honeypot?
  • Honeynet: Simulated computer network using a decoy server
  • Honeypotting: Practice of setting up a server or network device whose sole purpose is to attract and trap
  • Honey Potter: One that implements the honeypots


Classifications


We distinguish honeypots according to the following classification by level of interaction:

High-interaction Involve real operating systems and applications. Nothing is emulated.

Advantages: You can capture extensive amounts of information: unexpected behavior of attacker; new techniques; new vulnerabilities in the system and services.
Disadvantages: Real systems and services increase the risk that attackers can use them to attack non-honeypot systems. (harm risk)
Low-interaction Work by emulating services and operating systems. Attacker activity is limited to the level of emulation by the honeypot. Usually it's not an Operating System but rather a software that allows to select the operating systems and services you want to emulate and monitor.

Advantages: Simplicity to deploy and maintain. The emulated services mitigate risk by containing the attacker's activity.
Disadvantages: Logs are limited. It can be detected by the attacker because emulation is not credible. (detection risk)
Medium-interaction Work by emulating services and operating systems bind to scripts or programs.


Other classification by implemetation:

Physical Real hardware and software
Virtual Simulation of hardware and software


Honeypot solutions


The following page you will find a good link list of honeypot solutions and utilities that allow you to build your own honeypots:

http://www.tracking-hackers.com/solutions/

----------------
--------
----
--
-

Experiment with Honeyd virtual honeypot


As this topic is vast when you venture with the honeypot is good to know how to choose right away the solution that suits their own. Of all those available I wanted to focus on an easy to set up (virtual honeypot), powerful (thanks to the extensibility of medium-interaction) and widespread enough (is in many GNU/Linux Distros Repositories). In one words – Honeyd –

Honeyd is a small daemon that creates virtual hosts on a network. The hosts can be configured to run arbitrary services, and their personality can be adapted so that they appear to be running certain operating systems. Honeyd enables a single host to claim multiple addresses.

For documentation of honeyd visit http://www.honeyd.org/links.php


Getting and Installation


Assumes you want to deploy honeyd in any GNU/Linux environment. If it's possible downloading honeyd packages from repository, I urge you to do so. For example, in Debian-like GNU/Linux the packages required are honeyd and honeyd-common. Alternatively you can download the version you want on Honeyd Official Web Site.

If it doesn't exists, create user and group honeyd with few privileges to launch the honeyd program safely:

# useradd -m -s /sbin/nologin -d /home/honeyd honeyd

If it doesn't exists, create the log directory /var/log/honeypot/. In directory /usr/share/honeyd/scripts/ should be scripts that emulate services, characteristic of medium-interaction honeypots.


Honeypot configuration


Below is an example of the configuration file (myHoneyd.conf) to be saved in the directory /etc/honeypot:

### Configuration of honeypot

# Router entry point and addresses reachable
route entry 10.0.0.1 network 10.0.0.0/21

# IP class reachable from 10.0.0.1 (router)
route 10.0.0.1 link 10.0.0.0/24

# Other IP classes directly reachable from router
route 10.0.0.1 add net 10.0.1.0/24 10.0.1.1
route 10.0.0.1 add net 10.0.2.0/24 10.0.2.1

# IP classes reachable from other two network devices on the router
route 10.0.1.1 link 10.0.1.0/24
route 10.0.2.1 link 10.0.2.0/24

# Other two routers ...
route 10.0.1.2 add net 10.0.4.0/24 10.0.4.1
route 10.0.2.2 add net 10.0.3.0/24 10.0.3.1

# ... with their IP classes directly reachable
route 10.0.3.1 link 10.0.3.0/24
route 10.0.4.1 link 10.0.4.0/24

# Route from subnet 10.0.0.x to subnet 10.0.4.x
route 10.0.0.1 add net 10.0.4.0/24 10.0.1.2

# Route from subnet 10.0.0.x to subnet 10.0.3.x
route 10.0.0.1 add net 10.0.3.0/24 10.0.2.2

# Windows NT4 web server
create windows
set windows personality "Microsoft Windows NT 4.0 Server SP5-SP6"
add windows tcp port 80 proxy localhost:80
add windows tcp port 139 open
add windows udp port 138 open
add windows udp port 137 open
add windows tcp port 135 open
set windows default tcp action reset
set windows default udp action reset

# Windows 2000 Client
create winclient
set winclient personality "Microsoft Windows 2000 SP3"
add winclient tcp port 445 open
add winclient tcp port 139 open
add winclient udp port 138 open
add winclient udp port 137 open
add winclient tcp port 135 open
set winclient default tcp action reset
set winclient default udp action reset

# Default behavior -> no computer
create default
set default default tcp action block
set default default udp action block
set default default icmp action block

# Servers in the subnet 10.0.1.x
bind 10.0.1.10 windows
bind 10.0.1.11 windows
bind 10.0.1.12 windows
bind 10.0.1.13 windows
bind 10.0.1.14 windows

# Servers in the subnet 10.0.2.x
bind 10.0.2.10 windows
bind 10.0.2.11 windows
bind 10.0.2.12 windows
bind 10.0.2.13 windows
bind 10.0.2.14 windows

# Servers in the subnet 10.0.3.x
bind 10.0.3.10 windows
bind 10.0.3.11 windows
bind 10.0.3.12 windows
bind 10.0.3.13 windows
bind 10.0.3.14 windows

# Servers in the subnet 10.0.4.x
bind 10.0.4.10 windows
bind 10.0.4.11 windows
bind 10.0.4.12 windows
bind 10.0.4.13 windows
bind 10.0.4.14 windows

# Clients in the subnet 10.0.4.x
bind 10.0.4.100 winclient
bind 10.0.4.101 winclient
bind 10.0.4.102 winclient
bind 10.0.4.103 winclient
bind 10.0.4.104 winclient
bind 10.0.4.105 winclient
bind 10.0.4.106 winclient
bind 10.0.4.107 winclient
bind 10.0.4.108 winclient
bind 10.0.4.109 winclient

# Cisco Router with telnet server
create router
set router personality "Cisco IOS 11.3 - 12.0(11)"
set router default tcp action reset
set router default udp action reset
add router tcp port 23 "/usr/bin/perl /usr/share/honeyd/scripts/router-telnet.pl"
set router uid 122 gid 132
set router uptime 1327650

bind 10.0.0.1 router
bind 10.0.1.1 router
bind 10.0.1.2 router
bind 10.0.2.1 router
bind 10.0.2.2 router
bind 10.0.3.1 router
bind 10.0.4.1 router


Service scripts


In the example above I used only one script that emulates the behavior of a real telnet server opened on port 23. Specifically I created a "router Cisco IOS 11.3 - 12.0(11)" virtual host to which I engaged a "telnet server" script emulation. For other scripts can visit http://www.honeyd.org/contrib.php.


Deployment


Active loopback interface and route the packets destined to the virtual hosts in loopback (is required to be root):
# ifconfig lo up
# route add -net 10.0.0.0/21 gw 127.0.0.1

When you start the daemon need to impersonate safest user and group honeyd using specific parameters. To know UID (User ID) and GID (Group ID) of honeyd you can find them via the id command:
$ id honeyd

In my case the output is
uid=122(honeyd) gid=132(honeyd) groups=132(honeyd)


Now, run honeyd daemon as root (for information about the parameters refer to the honeyd manual):

# honeyd -f /etc/honeypot/myHoneyd.conf -u 122 -g 132 -l /var/log/honeypot/connectionsLoopback.log -s /var/log/honeypot/registerLoopback.log --disable-webserver -d -i lo 10.0.0.0/21

whereupon fun test the honeynet using network tools as ping, traceroute, nmap and so on.

Then check log files in /var/log/honeypot. ^^


NOTES
[0] Definition by Lance Spitzner
[1] False positive: false alarm. It leads one to conclude that a thing or relationship exists when really it doesn't